Product Management By Magic
Think about products in terms of solutions rather than capabilities. This leads to magical products that surprise and delight customers.
In One Strategy, Sinofsky writes about anchoring product plans using scenarios. He uses an example from Windows 7, arguably the greatest Windows release ever: when the customer’s laptop disconnects from their work network and connects to their home network, and go to print something, the default printer is their home printer. And when they reconnect their laptop to their work network, the default printer is the one down the hall from their office.
During product planning for Windows 7, the team defined cross-cutting scenarios like this printer one that reflected the product strategy. These are solutions to a customer problem, rather than tools to solve the customer problem. Tools to solve the problem would be building the capability to define networks, and the ability to associate default printers with networks. But that’s not going far enough. The magic is in Windows knowing when you set your default printer while you’re on this network, and the implied relationship between networks and default printers, and just doing it. No customer is surprised or delighted when we give them a capability to do something useful. Satisfied, maybe, but not surprised or delighted. They are only surprised and delighted when we do something useful for them.
The “default printer” scenario might seem obvious in hindsight. But when we are designing and building products, how often do we stop short of the magic and merely build the capability? It’s easy to imagine an alternate world where the network team delivered the capability to name networks, and the printer team delivered an enhancement to the “default printer” config dialog, with a capability to set a different default printer per named network. Both teams delivered their part of the contract, and buried in the Windows user manual is a section on “how to have the default printer change based on which network you’ve joined” that almost nobody would read.
At Amazon we think hard about “jobs to be done” and “undifferentiated heavy lifting”. They are related concepts and used together make a magical product. A job to be done is “what an individual really seeks to accomplish in a given circumstance.” That’s almost always harder to figure out than it seems: people are carrying lots of conscious and unconscious details about what they want and what they need that are specific to their life in that moment. They aren’t thinking about our products (or at least, they don’t want to). The job to be done is differentiated: achieving it is uniquely valuable to the individual, either to them personally or because the job they are doing employs their unique knowledge and skills that are valuable to others. Undifferentiated heavy lifting is all the “stuff“ that needs to be done to achieve the job. Doing it poorly may ruin the desired outcome, but doing it well doesn’t improve the desired outcome; it just has to be done. Switching default printers is a simple example: the job to be done is that specific person having a hard copy of that specific document on their computer. Whatever went into writing or choosing that document, what makes it important to them and what they will do with a hard copy, are all unique to them. Differentiated. Stopping to select the “right” nearby printer - when the “wrong” printers aren’t even available - is toil. Getting it wrong will ruin the task, but getting it right won’t improve the outcome of printing or the quality or usefulness of what got printed.
Where teams and product leaders often lose their way is focusing on the tasks customers perform along their journey, and asking “how can we make that task easier?”. But making it easier to switch my default printer, while still requiring me to do it, isn’t magical. It’s not fundamentally changing the value proposition of the product. Removing the undifferentiated heavy lifting along the path to the job to be done is what separates mediocre products from magical ones. Focus on solving the specific scenarios that a customer will actually encounter along the journey to their job, not merely providing easier capabilities to solve it themselves.
We do this regularly as part of our continuous planning process:
Figure out what your solutions are going to be, with the whole team in the room. Product, design, user research, and engineering all need to be involved in the entire process.
Start from what we know: where do customers get stuck and frustrated? What are the biggest ways we can change their life for the better? User research can provide data, PMs can provide framing, design can provide solutions, and engineers can provide reality.
Ask how do we remove these problems by solving them? Don’t stop the brainstorming at new capabilities, or making existing processes easier. Make problems go away.