by Marty Cagan
Transformation Techniques
When working to migrate your organization from working the way you do today to working the way you believe you need to, there are a set of techniques that have proved to be helpful for transforming how you work.
I am sharing the techniques here that I believe are essential for any modern product team.
So, as you can see, we need quite a range of techniques. Some of the techniques are quantitative, and some are qualitative. Some of the techniques are designed to collect proof (or at least statistically significant results), and some are designed to collect evidence. All are designed to help us learn quickly.
To be clear, I am sharing the techniques here that I believe are essential for any modern product team. Over the course of a year or two, you will probably use each of the techniques at least several times. There are, as you might imagine, many other useful techniques based on specific types of products or situations, and new techniques are always emerging. But, these are your go‐to techniques.
Discovery Framing Techniques
Overview
Much of our product discovery work doesn't require a lot of framing or planning. We need to come up with a solution to a particular problem, and often this is straightforward, and we can proceed directly to delivery work.
But for many efforts, this is decidedly not the case, and some framing and true problem solving becomes critically important. Big projects—and, especially, initiatives (projects spanning multiple teams)—are common examples.
In this section, I consider how we frame our discovery work to ensure alignment and to identify key risks.
There are really two goals here:
The first is to ensure the team is all on the same page in terms of clarity of purpose and alignment. In particular, we need to agree on the business objective we're focused on, the specific problem we are intending to solve for our customers, which user or customers you're solving that problem for, and how you will know if you've succeeded. These should align directly to your product team's objectives and key results.
The second purpose is to identify the big risks that will need to be tackled during the discovery work. I find that most teams tend to gravitate toward a particular type of risk that they are most comfortable with.
Ensure the team is all on the same page in terms of clarity of purpose and alignment.
Two examples I often find are teams that immediately proceed to tackling technology risks—especially performance or scale—and teams that zero in on usability risks. They know this change involves a complex workflow, and they're nervous about that, so they want to dive in right there.
Those are both legitimate risks, but in my experience, they are generally the easier risks to tackle.
We must also consider value risk—do the customers want this particular problem solved and is our proposed solution good enough to get people to switch from what they have now?
And then there's the often‐messy business risk, where we have to make sure that the solution we come up with in discovery works for the different parts of our company. Here are some common examples of that:
Financial risk—can we afford this solution?
Business development risk—does this solution work for our partners?
Marketing risk—is this solution consistent with our brand?
Sales risk—is this solution something our sales staff is equipped to sell?
Legal risk—is this something we can do from a legal or compliance perspective?
Ethical risk—is this solution something we should do?
For many things, we won't have concerns along these dimensions, but, when we do, it's something that we must tackle aggressively.
If the product manager, designer, and tech lead do not feel there's a significant risk in any of these areas, then normally we would just proceed to delivery—fully realizing there's a chance the team will occasionally be proved wrong. This, however, is preferable to the alternative of having the team be extremely conservative and test every assumption.
We like to use our discovery time and validation techniques for those situations in which we know there's a significant risk, or where members of the team disagree.
There are many ways to assess an opportunity. Some companies require significant rigor and analysis, and others just leave it to the product team's judgment.
In this section, I describe three of my favorite techniques, each for different‐sized efforts:
An opportunity assessment is designed for the vast majority of product work, which ranges from a simple optimization to a feature to a medium‐sized project.
A customer letter is designed for larger projects or initiatives that often have multiple goals and a more complicated desired outcome.
A startup canvas for those times you're creating an entirely new product line or a new business.
Note that these techniques are not mutually exclusive. You may find it useful to do both an opportunity assessment and a customer letter, for example.
Problems versus Solutions
There is an underlying theme you'll see in all framing techniques, and the reason is that it's just human nature for people to think and talk in terms of solutions rather than the underlying problems. This applies especially to users and customers but also applies to stakeholders in our business, other company execs, and if we're honest with ourselves, it very often applies to us as well.
More often than not, our initial solutions don't solve the problem—at least not in a way that can power a successful business.
This problem famously applies to startup founders. Founders will often stew on a potential solution for month, if not years, before they get the funding and the nerve to pursue it.
But one of the most important lessons in our industry is to fall in love with the problem, not the solution.
Why is this so important? Because, more often than not, our initial solutions don't solve the problem—at least not in a way that can power a successful business. It usually takes trying out several different approaches to a solution before we find one that solves the underlying problem.
This is another reason why typical product roadmaps are so problematic. They're lists of features and projects where each feature or project is a possible solution. Somebody believes that feature will solve the problem or it wouldn't be on the roadmap, but it's all too possible they are wrong. It's not their fault—there's just no way to know at the stage it's put on the roadmap.
However, there very likely is a legitimate problem behind that potential solution, and it's our job in the product organization to tease out the underlying problem and ensure that whatever solution we deliver solves that underlying problem.
A small amount of time up front framing the problem to be solved—and communicating this framing—can make a dramatic difference in the results.
CHAPTER 35
Opportunity Assessment Technique
An opportunity assessment is an extremely simple technique but can save you a lot of time and grief.
The idea is to answer four key questions about the discovery work you are about to undertake:
What business objective is this work intended to address? (Objective)
How will you know if you've succeeded? (Key results)
What problem will this solve for our customers? (Customer problem)
What type of customer are we focused on? (Target market)
Business Objective
The first question should map to one or more of your team's assigned objectives. For example, if you've been asked to focus on the problem of growth, to reduce the time it takes for a new customer to onboard, or to reduce the percentage of customers that churn each month, then we want to be clear that this work will address at least one of our assigned problems.
Key Results
We want to know at the outset what the measure of success is. For example, if we're trying to reduce churn, would a 1 percent improvement be considered excellent or would be it be
considered a waste of time? The second question should map to at least one of the key results assigned to our product team.
Customer Problem
We want to keep the focus on our customers.
Everything we do is, of course, intended to benefit our own company in some way or we wouldn't do it. But we want to keep the focus on our customers, and this question will clearly articulate the problem we want to solve for our customers. We occasionally do something to help internal users, so if that's the case we can call that out here. But even then, we try to tie it back to the benefits to our end customers.
Target Market
So much product work fails because it tries to please everyone and ends up pleasing no one. This question is intended to make it very clear to the product team who the primary intended beneficiary of this work is. Normally, this is a particular type of user or customer. It might be described as a user or customer persona, a specific target market, or a specific job to be done.
There are other factors you may want to consider when assessing an opportunity, depending on the nature of the opportunity, but I consider these four questions to be the bare minimum. You need to ensure that every member of your product team knows and understands the answers to these four questions before you jump into your product discovery work.
Answering these questions is the responsibility of the product manager, and it normally takes a few minutes to prepare these answers. But then the product manager needs to share them with her product team and with key stakeholders to ensure you are on the same page.
One important caveat: Sometimes the CEO or another senior leader will explain that there's something beyond normal product work that needs to be done. Realize that there are sometimes strategic reasons for doing specific product work, such as support a partnership. If it happens a lot, then that's a different issue, but it's usually infrequent. If that's the case, don't stress over it. Just give the team as much context as you can—these four questions may still be relevant.
CHAPTER 36
Customer Letter Technique
For smaller and more typically sized efforts, the opportunity assessment is usually sufficient. But when embarking on a somewhat larger effort, there may in fact be multiple reasons, several customer problems to be solved, or business objectives to be tackled. To communicate the value effectively, it may take more than the four questions listed in the previous chapter.
A typical example of an effort of this size would be a redesign. There are likely several objectives in the redesign, and maybe it is intended to both improve the experience for current customers and perform better for new customers.
One of my favorite technology‐powered product companies is Amazon. They have consistently innovated—including several truly disruptive innovations—and have shown they can continue to do this at scale. In my view, there are many reasons for this ongoing product success, from leadership, to talent, to culture, and especially to their sincere passion for taking care of customers. But there are a few techniques that are central to how Amazon builds product, and one of them is referred to as the working backward process, where you start the effort with a pretend press release.
When embarking on a somewhat larger effort, there may in fact be multiple reasons, several customer problems to be solved, or business objectives to be tackled.
The idea is that the product manager frames the work ahead of the team by writing an imagined press release of what it would be like once this product launches. How does it improve the life of our customers? What are the real benefits to them? You've all read a press release before—the only difference is that this is entirely imagined. It is describing a future state we want to create.
It's so tempting for product teams to immediately slip into an enumeration of all the features they plan to build, with little real thought into the actual benefits for our customers. This technique is intended to counter that and to keep the team focused on the outcome, not the output.
The actual reader of this press release is the product team, related or impacted teams, and leadership. It's a terrific evangelism technique—if people don't see the value after reading the press release, then the product manager has more work to do, or perhaps should reconsider the effort.
Some people also consider this a demand‐validation technique (if you can't get your team excited, maybe it's not worth doing). It's only validating demand or value with your colleagues rather than with real customers, however, so I think of it primarily as a framing technique.
In any case, Walker Lockhart, a former long‐time Amazonian who joined Nordstrom a couple of years ago, shared with me a variation of this technique that was developed and refined at Nordstrom.
The idea is that rather than communicate the benefits in a press release format, you describe them in the format of a customer letter written from the hypothetical perspective of one of your product's well‐defined user or customer personas.
The letter—sent to the CEO from a very happy and impressed customer—explains why he or she is so happy and grateful for the new product or redesign. The customer describes how it has changed or improved his or her life. The letter also includes an imagined congratulatory response from the CEO to the product team explaining how this has helped the business.
I hope you can see that this customer letter variation is very similar to Amazon's imagined press release, and it is intended to drive much the same type of thinking. A press release version includes a customer quote as well.
I like this customer letter variation even better than the press release style for a couple of reasons. First, the press release format is a bit dated. The press release doesn't play the role it used to in our industry, so it's not something that everyone is familiar with. Second, I think the customer letter does an even better job of creating empathy for the customer's current pain and more clearly emphasizes to the team how their efforts can help the lives of these customers.
I will also admit that I love actual customer letters. I find them to be extremely motivating. And it's worth noting that even when a customer letter is critical of the product, it helps the team to understand the problem viscerally, and they often feel compelled to find a way to help.
CHAPTER 37
Startup Canvas Technique
So far, we've explored techniques for typical‐sized, smaller efforts like adding a new feature, or medium to large‐sized efforts like a redesign. Those cover most of what product teams actually work on.
However, another especially difficult situation requires a more comprehensive framing technique. This is an early stage startup, where you are trying to figure out a new product that can power a new business, or, for those that work at an enterprise size company, when you're asked to tackle an all‐new business opportunity for the company.
In other words, you're not being asked to improve an existing product, you're being asked to invent an entirely new product.
In this situation, you have a much broader set of risks, including validating your value proposition, figuring out how you intend to make money, how you plan to get this product out to your customers and sell to them, how much it will cost to produce and sell this product, and what you will measure to track your progress—not to mention determining whether the market is large enough to sustain a business.
You're not being asked to improve an existing product, you're being asked to invent an entirely new product.
For decades, people would create thick business plans to try to highlight these topics and how they intended to tackle them. But many people, including me, have written about the many reasons those old business plans were often more harmful than helpful.
A startup canvas, its close cousins the business model canvas, and the lean canvas are intended to be lightweight tools to call out these risks early and encourage the team to tackle them up front.
I much prefer the startup canvas to old‐style business plans, but I have also observed that many startup teams still spend too much time
on the canvas and keep postponing that pesky little problem of discovering a solution that people want to buy (see the box “The Biggest Risk”).
You can use a canvas for any product change, no matter the size, but you would likely quickly find that, once you have an existing product and business, the majority of the canvas doesn't change and is only duplicated. You already have a sales or distribution model. You already have a monetization strategy. You have a well‐defined cost structure. You are mainly trying to create more value in your solution. In that case, it probably makes sense for you to look at one of the earlier framing techniques.
That said, you can use the startup canvas for simpler work, especially if you have a new product manager. The startup canvas can help that new product manager get a good holistic understanding of her product and understand the key areas of the affected business.
The Biggest Risk
One of the things I like about a startup canvas is that it helps to quickly highlight the key assumptions and major risks facing a startup or a significant new product in an existing business. This is a good thing. The idea is to tackle the biggest risks first. At least that's the theory.
In practice, I keep running into entrepreneurs and product leaders who are focused on secondary risks rather than primary risks.
It's human nature for people to focus more on those areas they feel they can control and are knowledgeable about.