In 2017, Lazada held its inaugural hackathon. I had the priceless opportunity to observe it up-close. How the teams planned, prototyped, and pitched; how the judges evaluated ideas; how an unexpected idea won.
It was a lesson on shipping bottom-up innovation to the customer. Another fortuitous lesson I gained was how to evaluate ideas. This lesson shaped my view on how best to contribute as a data scientist.
In most companies, getting buy-in and resources (from management) to execute your idea is a challenge; Lazada was no exception. Thus, when the hackathon offered the grand prize of prioritizing and implementing the winning idea, teams across the region jumped on it. From the 80+ ideas submitted, 12 teams were invited to the hackathon offsite at the Vietnam tech hub.
The sophistication and potentially high impact of the ideas blew me away. One idea was real-time location-based recommendations to bridge online and offline. Another involved social listening for customer next best action, to reduce friction in the customer journey. Ambitious and useful for customers!
Hardworking rockstars filled the teams. They were a mix of full-stack engineers, data engineers and scientists, with some designers and project managers sprinkled in. They worked hard; most teams started before the hackathon—I learnt this was par for the course. The hackathon venue probably had the highest tech talent per square feet (in Vietnam) at that time—they could have founded companies there and then.
Ideas and teams were assessed on requirements, feasibility, execution plans, and potential impact. After all, the winning idea would get precious prioritisation and resources—some other project would be de-prioritized. The winning team was expected to really execute, and execute really well.
“Trim the fat, cut the BS.” - Most heard advice from hackathon judges
For the final pitch, teams had seven minutes to present and three minutes for Q&A. It was nerve-wracking yet insightful. The panel of 10+ judges were battle-hardened executives who fought, lost, and won many battles—we got a rare glimpse into their thinking process.
The judges pulled no punches with their questions.
I still feel the pain of ill-prepared teams.
With such strong teams, you would think the winning idea was sophisticated and high tech.
I’m sorry to disappoint you. The winning idea was a dinky one. It took an existing feature, the wish list, and added a simple tweak—notifications.
Through their analysis, the team found that a majority of wish-listed items were out-of-stock or relatively pricier. They hypothesised that interest in these items was high and believed customers would buy if the items were back in stock or had a price reduction.
The idea—within the idea—was to facilitate the marketplace. They would inform sellers of product demand so sellers could take action (by restocking or reducing price). Then, buyers are informed via notifications if an item is restocked or reduced in price. Beautifully simple.
The potential impact? Given the high value of items added to wish lists daily, the team estimated double-digit percentage gains.
I was surprised the judges loved the idea.
“Why did this idea win?”, I asked some of the judges over drinks. It was a tech hackathon, wasn’t it? All the other ideas had more ambitious features, better-polished prototypes, and deeper tech talent. Why this idea?
Their response surprised me, but on hindsight, makes sense. They felt that one focused feature tweak could do more than five ambitious, though less feasible, new features.
The idea and execution was the simplest by a mile. A minimal implementation would take a few weeks and the hypothesis could be quickly tested.
“Complexity is the enemy of execution.” - Tony Robbins
The impact was potentially the biggest. The team came prepared with the numbers. How many items were wish-listed? What was their total value? What proportion was out of stock? What was the average price of items wish-listed? What was the most common category? What was the conversion rate relative to other screens? The judges probed from multiple angles till they were convinced of the team’s estimates—some judges had even more bullish forecasts.
The team was the most diverse—this reason came as a surprise to me. Most teams had strong tech backgrounds. They were organised around the same division such as mobile app, seller centre, home page; after all, prior experience working together is an advantage. The winning team was different. Its members were sole representatives of functions across the organization—marketplace, customer experience, design, engineering, data engineering, and data science.
The judges saw that this team had the widest connections across the organization. Thus, among the teams, the judges had the highest confidence in the winning team to succeed. They could bring together the various divisions (i.e., business, product, engineering, data) to ship. The diversity—and relatively lower tech focus—was viewed as a strength, not a weakness.
From that hackathon, I learnt a bit about how decision-makers think and decide. They didn’t care for sophisticated ideas and designs, cutting edge tech (or machine learning 😔), or deep technical expertise and experience. What they cared about was the ability to create business value.
Business value is created by increasing revenue or reducing costs. In most businesses, those are the only goals. Beautiful design, solving complex technical problems, or using the latest and greatest tech are secondary. (Note: This mostly applies to business. If you’re in research or academia, there would be different measures of value, such as intellectual property). The winning idea had immense business value if customers and sellers took to it.
How should the value be created? As simply and efficiently as possible (read: low cost, low effort, short timeline). If the project will fail, we want to know sooner rather than later, with little investment rather than more. To do this, you need to ship. Always. Be. Shipping. One good approach is the lean start-up method. It aims to shorten development and experiment cycles to rapidly figure out if an idea or product is viable. The winning idea had a simple, low-cost plan and short timeline to test their minimum viable feature.
What does ability look like? Beyond technical skills (which people overly focus on), what else matters? For the hackathon, the judges valued networks and the ability to facilitate across divisions. Another cliche, but no less true, skill is verbal and written communication. Critical thinking is also essential. Being able to frame the right problem correctly and make quick decisions based on minimal—often conflicting—data is a competitive advantage. Though not a skill per se, reputation also matters.
Learning to write is much more important than learning to code.— Sahil Lavingia (@shl) May 3, 2020
My key takeaway was this—what matters (to most companies) is my ability to create value. What I enjoy, such as experimenting with bleeding-edge tech and machine learning techniques, building beautiful scalable systems, are a means to that end. They’re the approach, not the goal.
Don’t build to build. Build to create value.
What other lessons have you drawn from your experience? Reach out via Twitter (@eugeneyan) or share in the comments below!
Thanks to Yang Xinyi and Yang Huiyi for reading drafts of this.
I write about how to be effective in data science, learning, and career. Get weekly updates.
Welcome gift: A 5-day email course on How to be an Effective Data Scientist 🚀