Working Backwards

I build software for a living. It has been 20 years now. It’s a lot of fun but a huge amount of work. With a two-pizza team, building a new feature should take roughly 12 months from ideation to delivery. So if you build a new major feature or start a new product from scratch you will probably spend the next 6 to 18 months working on this project. It’s a lot of time and energy. Nothing is more frustrating than launching a product nobody cares about. It is deflating and definitely can burn you out. Been there, done that. I don’t recommend it.
It particularly struck me when I was the co-founder and CTO/CPO of allmyapps. After our $1M series A, we invested most of our time and money in product development to emerge as the leading Microsoft-dedicated app store. After months of hard work, we proudly launched our new product. Unfortunately, user adoption never really took off (at the level expected) which in turn prevented us to raise a series B and forced me to pivot and change the nature of my company. It’s hard to describe, even today 10 years later, how tough it has been. The frustration never completely vanished.
Since then, I have been driven by learning the craft of building technological products. Over the years, I’ve been impressed by how Amazon reinvented itself to innovate on behalf of its customers. I clearly remember when Amazon launched AWS EC2 and S3 in 2006, I told myself: “This is crazy! How could an e-commerce company be able to disrupt the cloud computing market?”. It became clear that Amazon was a company I’d like to work for at some point.

I’ve been working for AWS for 4 years now. I came in precisely for this reason — to learn and apply an innovation framework that helps me build great tech products. At Amazon, we call this framework the Working Backwards (also called Product Discovery in other companies). Working Backwards is Amazon's product development process. It is a common framework for innovation and customer obsession that we use for every type of innovation both big and small. This is the process that is behind every game-changing big idea like Alexa, Kindle or AWS but also for smaller, simple features that have a meaningful impact on customers.

As a PM, your job is to know your customers and understand deeply the problems they have. You need to focus on the most important ones and identify the prevailing benefits of solving them. Then you want to prototype a solution to test and learn as fast as you can. As a result, you collect strong evidence, validate/invalidate the hypothesis, and finally gain (or loose...) confidence that you are on the right track. At Amazon, we carry out this process with the Working Backwards framework.

Let me walk you through the process and see how it can help you when you start a new project. There are 5 stages to the Working Backwards process:

1. Start with the customer - Who is the customer and what insights do we have about them? The goal of this stage is to explore, discover and learn as much as possible about the customer. You can use different techniques to get to know your customers better. You can do customer interviews, run roundtables, and do focus groups and workshops. You can also analyze the quantitative data sets you have at your disposal and examine qualitative data.
   During my time at allmyapps, every morning I looked at our user dashboard which aggregated the most important customer usage data such as the number of new users, number of active users, number of paying users and user average lifetime value (LTV). If something was odd or surprising I planned deep dive sessions to elucidate the situation. After that, I usually observed customer anecdotes by reading reviews from our in-app customer feedback mechanism. I always focused on negative reviews and tried to engage with these customers. It helped me stay connected to them, understand their main pain points, and identify/prioritize the next problems to solve.
   I found that focusing on direct customer interactions and internal data was way better to learn about customers than relying on proxies such as external market research or customer surveys.
   As Jeff Bezos explained in his 2016 shareholder letter: “Good inventors and designers deeply understand their customers. They spend tremendous energy developing that intuition. They study and understand many anecdotes rather than only the averages you’ll find on surveys. They live with the design.”
2. Focus on the most important problem - What is the prevailing customer problem/ opportunity? What data informed this? The goal here is to identify the key problem or opportunity we want to solve for our customers. The outcome should be a succinct and precise problem statement. Something that you could summarize with the following sentence: “Today, [customers] have to [problem/opportunity] when [situation]. Customers need a way to [insert need].”
   Be careful not to problem-solve before you have a solid handle on the problem. As the saying goes: “fall in love with the problem, not the solution”. It is crucial to stay with the problem as long as you need it. Otherwise, you run the risk of not solving a real customer problem or addressing the core customer need which can lead to significant waste of time down the road.
   One of the techniques I use and like to deeply understand a problem is to analyze what customers are doing with the existing solutions they have at hand. For example, how do they currently work around the problem? What is the step-by-step process they use to overcome the problem? How many steps do they have to do to perform a certain task? I try to observe and feel how painful and time-consuming it is.
   When I’m done with this and I feel confident I have a solid grasp on the customer problem. I write a two-page document that describes thoroughly the problem. I then review it with my team to debate and align with project stakeholders, and make sure we are crystal clear on the problem we are trying to solve. This document is backed with all the customer research data I have gathered so far.
   
3. Find the right solution - What is the solution? Why is it the right solution versus other alternatives? It’s time to be creative and think big. Now, you need to think about what is the best solution for the customer. There are many different ways to generate ideas, you can brainstorm, organize Hackathons or use the “How Might We (HMW)” statements technique. The goal is to turn research from previous stages into solutions.
   Work with the broader team. Generate as many potential solutions as possible and encourage creativity and out-of-the-box thinking within your team. Once you have a set of potential solutions, evaluate and refine them. Finally, assess the feasibility and T-shirt size your project. Refine until you have a feasible solution that will delight your customer.
   Usually, I try to come up with at least two solutions for the problem. I want to have a plan B if something falls through the crack with my preferred option. In one of my projects, we discovered pretty late down the road that we had a critical security issue in the technical design. It was a blocker and we had to stop development. Having another solution already designed and sized by the engineers helped me change direction quickly and move forward with the alternative solution. Not ideal but way better than having to redo everything from scratch
   
4. Define the customer experience – How would we describe the end-to-end customer experience? What is the most important customer benefit? The goal of this stage is to dive into the details and describe how the solution work. Start by developing a concise 'elevator pitch' that can describe your idea in 30 seconds or less. Then, articulate how the customer will experience using your product. Consider what it will look or feel like for the customer to engage with it and identify the primary benefit for the customer. Work with your designers. build mock-ups, wireframes and user flow.
   At Amazon, we summarize and refine the information and learnings from the previous stages in a document called a PRFAQ. The PRFAQ is a fundamental document at Amazon. Its primary focus is to demonstrate the value proposition of your product and showcase the customer experience. It includes a Press Release (PR), Frequently Asked Questions (FAQs), and Visuals. PRFAQs are used for every innovation at Amazon both big and small. It is the company-wise mechanism to get the green light from leadership and start building.
   
5. Start building - How will we define and measure success? The goal of this stage is to prototype a solution and start gathering data with real customers. Measure and track your metrics. Use them alongside user feedback and anecdotes to refine the solution and iterate until you have a solution that your customers truly like.
   
   Over the years, I went through the process many times. Every time it proved to be extremely efficient. Here are some of the reasons why I like the process and also some things you should be careful of:
   
   What I like

• Working Backwards focus is to validate the product value proposition — whether customers will use the product — and maximize the chance to reach product-market fit. In other words, make sure you have enough evidence to confidentially say “I know the customer will use/ buy my product”. This is, without a doubt, the most important aspect of your project and you want to validate that firsthand.
• Working Backwards places a strong emphasis on the user experience. At Amazon, senior leaders frequently ask for mock-ups to get a better sense of how customers will interact with the product. They want to experience the product themselves and evaluate its usability and value. Working Backwards will help you thoroughly examine each aspect of the customer journey and fine-tune the experience to make it as engaging and satisfying as possible.
• Working Backwards helps avoid problem-solving too early. It’s easy to come up with a solution to an undefined problem. Working Backwards forces you to stay laser-focused on the customer, take the time you need to truly listen to your customers and understand the problems they face.
• Working Backwards help you shift your focus away from solely considering the business benefits to your company and instead look at things from a customer's perspective. I've worked for companies that wanted me to sell new product ideas based on market opportunity, with a heavy emphasis on financial models, market size evaluation, competitor analysis, and cost calculations. While this approach worked on occasion, I never found it personally satisfying.
• Working Backwards is data-driven and data-backed and it’s a written process. The combination of data and writing is a powerful recipe for success.
• Working Backwards is a company-wide process. It’s a cross-functionally process that encourages collaboration and communication across all teams involved in product development, including design, engineering, marketing, and legal. It is the cornerstone of the Amazon culture of innovation.

Things you should be careful about

• Working Backwards is not intended to be a waterfall. Technical designs, first estimates and project sizing should be done as early as possible. You shouldn’t wait to have a full-fledged PRFAQ before involving engineers. You don’t want to start coding a half-baked product but it’s critical as well to have engineers involved in the Working Backwards process as early as possible. If not, it can lead to discovering technical roadblocks too late down the road.
• Working Backwards primary focus is to validate product value proposition and customer experience. However, it is equally important to make your project works for the business and address business aspects such as mitigating legal, marketing or partnership risks early in the process. A solid PRFAQ should have dedicated FAQs for this.
• Take the necessary time to do a thorough product discovery. Working Backwards discovery stages (stages 1 and 2 above) are critical for your project but sometimes done too quickly. We know time matters in business. Leadership pushes hard for new features. PMs and senior engineers get a lot of pressure to launch fast and often. All of this is fair but as a PM the right thing to do is to push back until you are firmly convinced that you have a solution the customer really wants. It can be tempting to shortcut product discovery to accelerate delivery but in the end it’s never a good bet in my opinion.
• If you are a PM or someone who innovates in your organisation you should spend most of your time Working Backwards (or working on the innovation process of your company). Yes, we all have a ton of other things to do but it’s not an excuse, be cautious to prioritize Product Discovery. At the end of the day, this is your value add.

There are many different ways you can choose to innovate, you could focus on competitors, or on new technologies. You can also innovate around business models and there are many, many more. And all these approaches could lead to successful products. At Amazon, we focus on the customer. I like it! I find it enjoyable and fulfilling and it proved to work pretty well for my projects.

I hope you enjoy this article. If you have questions please reach out, I’d be happy to help!

Let’s build something great together!
Arnaud