You’ve probably heard the old adage “success is not a destination, but a journey.” Clearly its authors were not product managers. Product teams aren’t measured on the winding road and applauded for the many steps taken—it’s all about results. Yet, we’re often so consumed with the process, routine, and endless cycle of building that we can forget none of that matters if the end result doesn’t meet our goals.
That’s why the best plans start with the final outcome. Productivity gurus FranklinCovey even trademarked this as one of their seven habits: Begin with the end in mind.
Many innovative companies have adopted this working backwards mindset to keep people from being distracted during the development process and maintain a singular focus on the ultimate goal.
For example, Amazon starts every project with the product manager authoring a press release articulating the current problem. They explore why other solutions aren’t cutting it, and how they’re solving things for the customer with their not-yet-built product. Throughout the entire product development process, anyone can refer back to that document as a guidepost, ensuring everything they do is making that press release a reality.
What is working backwards?
Working backwards is all about starting with the desired end result in mind and then figuring out how to get there. Although everyone should already do this, there are plenty of times when this isn’t the case.
The key to working backwards is crystalizing where you want to end up. This means diving into the details of what the desired end result should be (more sales, happier customers, easier workflows, etc.), what the product must be capable of to achieve those goals, and what success would look like.
Looking at Apple’s slick and popular product line, it’s obvious they were listening when Steve Jobs said “you have to start with the customer experience and work backwards towards the technology.”
With an agreed upon vision, the product team can then break down all of the required steps to reach that final destination. This differs from taking a more exploratory, iterative, “let’s see where this takes us” approach, or simply building stuff for the sake of building it.
Why the best product teams work backwards
Working backwards creates a more efficient and focused product development process. With a clearly articulated endpoint in mind, teams don’t get distracted or build the wrong things as they fumble forward. Instead, they know exactly what the finished product must be capable of, so they’re far more likely to get it right the first time.
This approach also prevents the team from getting lost in the weeds and worrying about implementation instead of results. As we’ve heard many times from our engineering counterparts: “Don’t tell me HOW to build it, just tell me WHAT to build.”
When you’re working backwards, the WHAT has already been very well-defined and no one will have any questions about whether the final product meets expectations. This not only gives clear guidelines to product development; it also provides QA with precise things to look for during their testing and gives a head start for sales and marketing since they know what they’re getting.
Prioritization also benefits from this approach; if a particular item doesn’t move the product closer to the desired finish line, then it takes a backseat to the items that do. It hones everyone in on satisfying customers and delivering value accordingly.
How to get your team to work backwards
Working backwards may be a state of mind, but getting the rest of the team on board might require something a little more tangible to wrap their heads around. Here are three methods for hitting “rewind” instead of “fast forward.”
Starting with a press release
Made famous by Amazon, the working backwards strategy is a favorite among many product teams and thought leaders. A press release is usually the very last step in the product development and launch process. It tells the world: “Here I am, this is what I can do, and this is why you should care.”
To be effective, the author must step back from the technobabble trap and communicate in terms that resonate with the target customer.
“One important element of the press release is that it is written in so-called ‘Oprah-speak’. Or in other words, a way that is easy to understand,” says Nikki Gilliard of Econsultancy. “This essentially allows Amazon to cut through tech-jargon and any descriptions that would only confuse the customer, in order to deliver a mainstream product.”
The starting point for the product definition is a customer-centric document, unconcerned with implementation details, technology or user interface design. Then, the focus shifts to what encompasses a truly great solution for the customer. If the press release is compelling, then you’re onto something.
“Iterating on a press release is a lot quicker and less expensive than iterating on the product itself,” says Amazon’s Ian McAllister. “If the press release is hard to write, then the product is probably going to suck. Keep working at it until the outline for each paragraph flows.”
But struggling to get the press release right is part of the process—if you could bang it out in an afternoon then you haven’t done the homework and made it bulletproof enough to drive an entire product development cycle.
“I created a couple of them in the past and it took me a lot of time; several weeks or even months actually, as the amount of time you need to dedicate on research is high, and trying to explain your idea like you would to real customers requires a lot of effort and dedication,” says Andrea Marchiotto of Unilever.
And because the press release is intended to declare the company’s success with the product—not just its availability—there must be a significant business case for it as well, which matches Amazon’s approach to selecting new features. For example, 90% of Amazon Web Services roadmap is driven by broad customer requests, indicating advance knowledge of a clear demand.
Conducting a pre-mortem
A post-mortem (or after-the-fact review of everything that went right or wrong during a project) is a common method for organizations to learn from previous mistakes and successes to perform even better the next time around. It’s a group affair where representatives from the entire organization chime in on what worked well and what went astray.
A pre-mortem essentially places that same group of stakeholders in a time machine and asks them to imagine everything that could happen before a single line of code is written or design is mocked up. The goal is anticipating and wargaming the situation, spotting all possible scenarios so the team has already anticipated potential stumbling blocks and land mines.
These sessions begin by brainstorming every possible calamity that could befall your product, from total market rejection to compromising user data to sluggish performance and inability to scale. It’s a chance to surface every fear and doubt lurking in people’s minds and determining which are more likely to actually occur.
“Once you’ve collectively established your highest risks, you can start thinking about ways to mitigate these risks. Realistically, you might not be able to stop all risks from happening,” says Marc Abraham of Settled. “In these scenarios, you can still figure out how to best reduce the impact of a risk happening and come up with a ‘plan B’.”
If the mitigation strategy isn’t obvious, a sub-team can be assigned to each outstanding item. Then, the team can work out how to deal with it if it arises (or fully preventing it from occurring at all). And with all potential horror show endings in view, the product team can work backwards minimizing or avoiding as much as possible.
Believe it or not, this might even serve as a bonding exercise for the team, forced to identify and grapple with possible unpleasantness and tap their problem-solving skills.
Begin with your Product Hunt page
Similar to the press release tactic, this method also requires the product team to identify its ideal output and work backwards from there.
Product Hunt is one of the leading showcases for new products and a semi-meritorious platform for building buzz and traffic from early adopters. A Product Hunt page includes a 60-character-max tagline, a thumbnail image, a gallery, a two-sentence description, three or four topics that your product fits into and then finally a “maker comment,” which according to the Product Hunt blog should:
“Briefly introduce yourself, the team, and the problem that you’re solving. In a total of 3–4 sentences explain what the value prop is, what’s the use case, who its for, and why you are building it. If this is the second time you’re launching on PH (i.e. a big product update or huge feature announcement), explain what’s changed. Tip: Make it as easy as possible for people to care.”
In total, you’ve got about seven or eight sentences and a few visuals to communicate what your product does, who would want to use it, why they should use it and what makes your product and team so special. Distilling your grand product vision down to this tiny bit of text is not only a great exercise in editing and brevity, but it also forces the team to really lock in on what’s most important.
With your faux Product Hunt page already authored, this artifact can be used to gain consensus in the organization and serve as ongoing inspiration during the product development. It’s conciseness and focus on the customer experience and value proposition is a great point to work backwards from.
Conclusion
Regardless of how you bring a working backwards mentality to your product team, the ingredient pulling everything together is truly understanding what customers need before you begin working on everything. If you haven’t done your homework in that department then your perfect final product may miss the mark, leading to a post-mortem that doesn’t do the product team any favors.
