Many organizations we work with care deeply about their customers and recognize the link between delighting customers and business growth. The question is how best to determine what will delight customers? How do you arrive at a definitive picture of your customers’ needs and the problems or opportunities that can be addressed? Making guesses about customer needs based on intuition or personal experience is well-intentioned, but indeterminate. To be customer obsessed, organizations need to move from imagining to knowing.
We take a broad view of the customer experience across their lifecycle: not just how they use a product, but how they arrive at a buying decision, how they’re onboarded, or how they might reach out for support if needed. Then we “work backwards” from that broad knowledge base to clearly characterize who the customer is, the specific challenge or opportunity we’re addressing, and how their experience could be improved to benefit them. This process is something we do consistently and programmatically at scale: we call it Working Backwards.
To begin – before we ever request a budget, assemble a team, or write a line of code – we write a press release (PR) for what we imagine this final product will accomplish. Because it must fit on a single page, this is an exercise in simplifying and focusing our big ideas into a compelling and concise narrative that will resonate with the end customer. All relevant stakeholders, including leadership, are engaged in this process. The PR serves as our North Star for innovation.
We also produce an FAQ that addresses key questions about this product-to-be. This first half of the FAQ focuses on customer questions such as, “What happens when the product breaks?” “Will my data be secure?” “Why would I choose this over another product?” forcing us to think through the product from the customer’s point of view.
The second half addresses our questions, like, “Will this product be profitable?” “Might it cannibalize other products?” “Do we have the resources to make this work?”. We don’t include every possible question. We start with the most important first, working until we are comfortable that we’ve answered enough questions to make decisions quickly and effectively throughout the product lifecycle.
These documents are some of our most valuable mechanisms for innovation. They force product teams to prioritize what is most important, identify what features to invest in, uncover issues before they occur, and create organizational alignment, all before product development begins. The PR and FAQ ensure that ideas remain firmly rooted in compelling customer value and becomes an essential tool for testing assumptions and evaluating the potential impact of a new product. It enables product teams to be stubborn on vision while flexible on the details, experimenting rapidly to identify the best ways to deliver on that vision.
This approach creates an environment where the product teams focus on the customer need or opportunity rather than a particular solution. Then the work of developing a product begins, experimenting and iterating in order to narrow the available options until we arrive at the simplest and most effective way to deliver a solution.
We prefer to co-design our products and their features with customers, testing product iterations in real life. We break our releases into “minimum lovable products.” Each iteration addresses a significant customer need that they’re excited to buy and use. And we promptly tweak the product as needed based on feedback. The goal is to treat any idea we have — no matter how experienced we are in the market, how high in the organization the idea generator sits, or how valuable we think the innovation is — as a hypothesis. The emphasis is on learning from customers, not just by asking them what they think, but by exposing them to our products in development and measuring the impact. This approach reduces the risks related to product or market fit and avoids excessive opportunity costs.
The approach the AWS team took to launch the first version of a flagship product called EC2 is a good demonstration of this process in practice. The team was forced to make difficult early product decisions, launching a more limited version earlier, and then applying an iterative approach to flesh out the rest of the features that we felt even more confident about over time based on data.
link