A guide to building better products by visualizing the end game, lessons learned from using Amazon’s Working Backwards approach.Visualizing the end game

There are many blog posts out there outlining Amazon’s approach to Product Development. It focuses on visualizing the end state before you introduce any other (often more complex) validation techniques to your ideas.

These are lessons learned from testing these ideas with cross-functional product teams.

What’s your ideal end state? — The Press Release

Let me start by saying I believe in product vision. Not crystal-ball-type vision. But in a belief that you are the sum of your knowledge and insights — which can lead you to visualize an end state for your product or company that’s unique to yourself and can thus go against the status quo and that of incumbents.

We used the Lean Startup terminology and called that a Leap Of Faith Assumption (LOFA, read loafer in a British accent, for bonus points). When you use Working backwards you start by expressing your vision in the form of a Press Release. This Press Release should be focused on why you’re doing this, what the benefits of what you’re creating will be, and who will benefit from them.

Try to answer this: How will the world be a better place for my customer once I’m done?

If you can’t do that convincingly and understandably, it’s likely you don’t have a real problem in your hands.

Is this a real problem?

The next step is to put that Press Release to the test. Assemble your team and let them read it. Include the skeptical senior engineer and the excited junior grad. Let them ask questions about the Press Release - Call this process the Frequently Asked Questions — when your product is live, this could be that section of your website / app.

Anything that comes to mind. Ask them to wear the hat of the customer.

This will put the benefits you conveyed in check. Are these problems real? Can they understand the pains of the customer? Is it clear what we will have achieved when we get there? Can they spot the cracks in your (non-existent) plan? You’re sharing a vision — is it exciting enough that they want to be on board?End the FAQs exercise by clustering the questions. Identify common themes, general pain points or areas of influence of your product. This should surface a connection to your main Jobs To Be Done.

(Remind the team that we are not our customers but we can try to understand them — this is an exercise in empathy)

What will it look like?

You starting going into the solution space here. If this thing is to become real, what will it look like? How can its benefits be expressed in an way people will understand it? Is it a car or a motorbike? Is it a native app, a progressive web app or, god help us, a chat bot? Is it a REST API or an SDK?

We’ve now done this for both user-facing and technical products. For the former you can sketch some rough wireframes — discuss the details, be nit picky, but don’t get to high-fidelity. Remember, this hasn’t really been put in front of users, so you don’t want to get attached to a beautiful design that won’t work. You want to find the fault lines, identify hypotheses you need to test, portray the impact you’re going to have and create a mental picture of where you’ll get to.

For technical products, create rough representations of them. A draft of your architecture, a sample response from your API, a set of endpoints you’ll expose, a data pipeline or a flow diagram for your voice-first assistant.

The special sauce — Does this solve your problems?

Now this step isn’t exactly described in the methodology, but I’ve used the with the teams to let ourselves be critical of the solution we’re envisioning. Pick up each of the FAQs and assign them to a part of your designs — I recommend actual post-its glued to a paper/whiteboard prototypes.

Can you map them all? Does your solution address the biggest problems you think exist? Are there questions you can’t map right now, ask yourself: how impactful are they? If the answer is “pretty impactful”, you should probably validate those first.

How will people use it?

Finally, the User Manual.

This one has a pretty scary name for someone (like me) who believes world-class products shouldn’t need user manuals. They should be self explanatory. However, all products will have some sort of reference, technical documentation or even a proper manual (Are you building a washing machine?) At this point, my suggestion is to just do the Table of Contents. Imagine that your customer found himself in a weird place and is now reading the help section. What will it look like? How should it be organized? Would you understand it if you were him? This works just as well for complex technical challenges.

“Now the whole team here”

When you’re done, the goal is alignment on the problem. You had a vision that has been challenged, questioned, you’ve identified its riskiest assumptions and even began sketching out a solution.

It’s time to get out there and start over. What’s the cheapest way to prove you’re right (or wrong)? Does the solution you thought work? (hint: it won’t) Can you identify, test and validate the underlying assumptions of what you want to build?

Your journey has just begun… But “now the whole team here” (Thanks, Drake). You’ve rallied around a common understanding of the problem. Every time there is a fork in the road, you can go back to your working backwards session: How will this bring us closer to the vision, our Unique Value Proposition?

If you’ve done it right, the whole team will be asking themselves that.