“What are the problems you are trying to solve? Why do you solve them now? How can you validate these are real customer problems?”

These are some of the most fundamental and frequent questions we asked each other on the Product team at GOGOVAN.

While many product teams are obsessed with building solutions, we choose to focus more on defining and prioritizing problems instead. Why? Because we believe that a solution can only be as good as our understanding of the problem we’re addressing.

In fact, it’s easy to build things exactly the way our users described but it usually misses the mark because the actual problem is buried a few layers deeper. By digging deeper into the problem (the “Why”), we can mitigate the risk of building something not valuable to users before putting in any design or engineering time to develop the solution (the “What”).

At a high growth startup, with more at stake, understanding the “Why” is even more important. There is no bigger waste than spending months to build something that is not valuable at all.

Over the last four years, GOGOVAN has grown from a small Hong Kong startup to Asia’s leading online logistics service platform with more than 180,000 registered drivers and millions of orders, serving hundreds of thousands of customers across Southeast Asia.

Not surprisingly, we faced the challenge of sorting through tons of ideas that we can potentially work on to solve the age-old logistic problem. And it’s very easy to fall into the trap of doing too many things but not delivering any results.

To avoid that, our team always prioritize solving problems that create the most customer value first, and we need to do so in a way that’s consistent with each other as the team grows. That’s where a well crafted product process comes in — to give the team a way to consistently evaluate the “Why” and rapidly iterate the “What”. So we don’t have to rely on luck to build great products.

Our product process has evolved over the years as we’ve learned many lessons along the way. Some things have worked really well, some less so. To try and learn how to replicate our product successes as we scale, we’ve been doing a lot of reflecting on how we worked and how we want to work in the future. We thought it would be valuable to share what our ideal flow looks like today.

Currently, our process has four phases:

1. Product Discovery — to define and prioritize problems
   
   
2. Product Validation — to design and test prototypes
   
   
3. Product Delivery — to build and ship solutions
   
   
4. Product Iteration — to measure and iterate solutions
   
   

   Product Discovery

   
   
   

At GOGOVAN, our development always starts with our mission: “Move with Simplicity”. We strive to provide excellent logistics services through the most user-friendly experience. Based on this mission, our founders came up with a product vision that describes the future we are trying to create over a 2-5 year timeframe.

With this high-level vision, it not only lets everyone know what direction the team is going but also helps people understand what activities are beneficial and which ones are distractions.

To help make the vision a reality, we’ve established a theme-based approach in roadmap planning. By organizing initiatives around themes, or high-level strategic objectives, it helps keep everyone focused on the business outcome and customer experience rather than features.

All of our projects currently can be linked to one of our nine strategic themes, which are key elements in our user journey, and each of them has outcome-based objectives to help us move towards our goal. To put it another way, these are the areas that we will continue to bring innovation to our users. Right now we are structuring our product team in a way that product managers are assigned to these thematic areas that they get to own, invent and test within. As a result, they can gradually develop subject matter expertise and become the best mind in the company on areas like how to improve driver experience across all platforms without limited by products or countries.

After interviewing customers, talking to sales team, and reviewing usage metrics, we will create a document called Problem Brief to list out all the high-impact problems, their definitions and their priorities in each theme. So we know which problems to address first once we’ve decided which themes to focus on based on our company’s OKRs and latest business strategies.

Oftentimes, figuring out the problem statements and their priorities turn out to be the hardest part. Why are the users having these problems? How important those problems are? What is the business opportunity for us to solve this problem? If we get that right, we’re more than halfway there.

That’s why our product managers and designers are required to develop a deep empathy for our users. And the best way to develop it is to truly immerse yourself in their lives. Some of the things that we’ve done include conducting customer interviews, day-long shadowing our drivers, working as drivers for a day, working as CS reps to talk to customers over the phone…etc.

Product Validation

Once we’ve defined and prioritized all the problems, we try to bring in designers and engineers early in the development process so we can maximize their values. In fact, they are often the best source of innovation. If you are just using designers to make things look pretty and engineers to write codes, you are only getting about half of their value. Right from the start, we make sure product, design and engineering teams are all aligned on the problems and expected outcomes (e.g. improving driver’s retention, increase conversion in onboarding…etc). After that, we bounce ideas off each other to get feedback on potential solutions and understand the implementation complexity, allowing us to make informed product decisions balancing benefits and costs.

Depending on the feature we’re working on, our designers will determine the right level of fidelity for their works, from rough sketch on paper to static wireframes to interactive prototypes. The goal is to remove the risk and speed up the learning by somehow previewing the solution in a cheaper form. For example, it’s common for our designers to run user testing sessions to gain insights and gather feedback on their prototypes.

Afterwards, if we are happy with the ideal solution, which we called v3, PMs will move on to scoping, where we cut the v3 down to a small cupcake sized v1, which is what we are going to build in the first iteration. In most cases, we try to keep the scope as small as possible so we can quickly validate the product direction with minimal cost.

Product Delivery

Now it’s time for execution. At this stage, we should be able to develop the solutions with enough confidence as they are based on previously validated ideas. Here we just follow the typical agile development process such as sprint planning, 2-week sprint, daily scrum, sprint retrospective, quality control, release planning…etc. Nothing fancy here.

Product Iteration

Finally, we need to figure out whether we have solved the problem successfully. It may sound obvious but it is a critical step that many startups neglect.

According to Marty Cagan, a legendary product expert, there are “two inconvenient truths about product.”

First, at least half of our ideas are not going to work as we expected after a feature is built. Secondly, even with the ideas that do prove to be valuable, it typically requires several iterations to improve this idea until it can deliver the expected business value. While there is no way to escape these truths, how you deal with these truths will distinguish your team from others.

After witnessing countless startups struggling in the build-build-build loop, we take Marty’s lesson to heart.

That’s why we make sure success metrics are clearly defined before implementation. And once a feature is shipped, we work closely with our Analytics Team to analyze the data and then talk to our users to understand the stories behind those numbers. How can we evolve to v2 to better solve the problem? Is the solution good enough for now? Or is it a complete failure that we should consider cutting it?

If the moment your product gets out the door, your team just moves on to the next project, you’ll not only miss a critical window for learning, but also a great chance to unlock new opportunities.

Launching a product is just the beginning, not the end. Product team should own the business outcome, not the output.

Note: This is not a linear process. The sequence/steps may vary on a case-by-case basis. (PDF with reference links)

The takeaway: what got us here won’t get us there.

We landed on this process after taking a ton of inspiration from people much smarter than we are to find an approach that sticks. Our biggest influence are Airbnb, Intercom, SVPG and the Double Diamond model.

However, our process is not perfect for everyone. It is heavily influenced by our culture, goals and team conditions.

This process is working well for GOGOVAN today with our current team size. It’s not how we worked in our early days, and it may not work for us anymore next year.

We are constantly examining and iterating our process. Some of our future challenges will revolve around how to keep the process lightweight so that we can speed up the iteration cycles, shorten the feedback loop and reduce risk for the company at the same time.

Other things that we will try out in the future, such as adopting Dual-Track Scrum to enable continuous product discovery, adding one more step (Product Growth) in the process to drive new feature usage and engagement, running a Design Sprint to kickstart a big project…etc.

If you are interested in tackling these challenges and using technology to transform the last mile in logistics, we are actively hiring new talents to join our analytics, design, engineering and product teams. Check out our careers page for details or refer your talented friends to join GOGOVAN and get a HK$20,000 reward!

Source: medium.com