INSPIRED

A guide on how to manage technology product development based on what customers want, signed by Marty Cagan, one of Silicon Valley’s leading experts on the subject

Central Ideas:

1 – The purpose of product discovery is to quickly separate good ideas from bad ones. This means getting answers to four crucial questions: 1. will the user buy this? 2. can the user understand this? 3) Can our engineers develop this? 4. can our stakeholder’s support and afford it?

2 – Every business depends on customers. And what customers buy – or choose to use – is your product. The product is the result of what the product team develops, and the product manager is responsible for what the product team will develop.

3 – One of the key principles for an effective product vision: start with the why. This is coincidentally the name of a great book by Simon Sinek. The central notion here is to use the product vision to articulate your purpose. Everything stems from that.

4 – Reference customer is a real customer (not family friends), who is operating your product in production (not a test or prototype) who has paid real money for the product and is willing to tell others about the excellence of your product.

5 – Good product teams get inspiration and product ideas from their vision and goals, from observing customer difficulties, from analyzing the data that customers generate from product use, and from constantly seeking new technologies. Bad teams collect demands from sales and customers.

About the author:

Marty Cagan is widely recognized as a leading technology product management thought leader. He is the founder of the Silicon Valley Product Group. He has worked to develop products for iconic companies: Hewlett-Packard, Netscape Communications, and e-Bay.

Part 1 – Lessons from top technology companies

In the mid-1980s, I was a young software engineer working for Hewlett-Packard on a mainstream product. It was a time (the first time) when artificial intelligence was the latest fad, and I was lucky enough to work at what was then one of the top technology companies in the industry, as part of a very strong software engineering team (several members of that team had substantial success at companies in the field).

In trying to trace the cause of project failure at HP, I learned that the decisions about what to develop came from a product manager – someone who is usually in marketing and who was responsible for defining the products we developed. But I also learned that HP was not good at product management. I learned later that many companies were not good at it either and, in fact, many still are not.

I chose this career because I wanted to work with products that customers love – products that inspire and provide real value. I think most product leaders also want to create inspiring and successful products. But most products are not inspiring and life is too short for bad products.

Technology-driven services and products. There are many types of products out there, but in this book, I focus exclusively on products that are technology-driven. Some of what we explore in this book may help you if you are developing non-technology products, but there are no guarantees in that case. Frankly, there is already a wide range of readily accessible information for non-technology products, such as most consumer packaged goods, and for managers of these non-technology products.

My focus is on the unique challenges and problems associated with building technology-driven products, services, and experiences.

The best product teams I know have already advanced beyond how many teams practice these methods – leveraging the core principles of Lean and Agile, but raising the bar on what they are trying to achieve and how they work.

When I analyze these product teams, I see three overarching principles at work:

Risks are addressed in advance, rather than at the end. In modern teams, we address these risks before we decide to develop anything. These risks include value risk (whether customers will buy it), usability risk (whether users can understand how to use it), feasibility risk (whether our engineers can develop what we need with the time, skills, and technology we have), and business viability risk (whether this solution also works for the various aspects of our business – sales, marketing, finance, legal, etc.).

Products are defined and designed collaboratively, rather than sequentially. They have finally moved beyond the old model where a product manager defines requirements, a designer designs a solution that delivers on those requirements, and then engineering implements those requirements, with each person living with constraints and decisions of those who preceded. In strong teams, product, design, and engineering work side by side in a reciprocal mode to find technology-driven solutions that our customers love and that work for our business.

Finally, the issue is about problem-solving, not feature implementation. Conventional product roadmaps are only about delivering solutions. Strong teams know that it’s not just about implementing a solution. They must ensure that the solution solves the underlying problem. It’s all about business results.

Product discovery. The purpose of product discovery is to quickly separate good ideas from bad ones. Its purpose is a validated product backlog. Specifically, this means getting answers to four crucial questions:

Will the user buy this (or choose to use this)?

Can the user understand how to use this?

Can our engineers develop this?

Can our stakeholders support this?

Prototyping. Product discovery must perform a series of rapid experiments, and to do these experiments quickly and economically we use prototypes instead of products. At this point it is worth saying that there are several types of prototypes, each for different situations and risks, but they all require at least an order of magnitude less time and effort than developing a product.

Part II – The Right People

Every product starts with the people on the multidisciplinary product team. The way you define the roles and the people you select to join the team will most likely prove to be a determining factor in its success or failure.

Team composition. A typical product team consists of a product manager, a product designer, and anywhere from 2 to 10 or 12 engineers.

Of course, if the product you are working on does not have a user-oriented experience – as with a set of programmatic APIs – you probably don’t need the product designer. But many product teams need this person on board, and throughout this book I will generally assume that your team does, too.

Hierarchical structure of the team. A product team has no hierarchical relationships – it has an intentionally horizontal organizational structure. Generally, everyone in a product team is an individual contributor, and there are no people managers.

People in the team typically continue to report to their functional manager. For example, the engineers report to an engineering manager. Likewise, the designer typically reports to a design head and the product manager reports to a product head. So it is not a hierarchical relationship.

Product Manager. At one level, the product manager’s responsibilities are very straightforward. He or she is responsible for evaluating opportunities and determining what is developed and delivered to customers. We usually describe what we need to be developed in the product backlog.

Every business depends on the customers. And what customers buy – or choose to use – is your product. The product is the result of what the product team develops, and the product manager is responsible for what the product team will develop.

Product teams. I know that many people long for a recipe for structuring product teams, but I always explain to them that there is no recipe. Instead there are some core principles:

Alignment with investment strategies. It is remarkable to me how many companies I meet where the teams are simply reflections of their ongoing investments. They have certain teams because they always have. But, of course, we need to invest in our future as well. We can eliminate products that no longer carry their own weight, and we can often reduce investments in our “gold mine” products so that we can invest more in products that are sources of revenue and growth.
Minimize dependencies. A big goal is to minimize dependencies. This helps teams move faster and feel much more autonomous. Despite the fact that we can never eliminate dependencies entirely, we can work to reduce and minimize them.
Maximize leverage. As organizations grow, we often find common needs and the increasing importance of shared services. We do this for speed and reliability. We don’t want every team to reinvent the wheel.
Product vision and strategy. The product vision describes where we as a company are trying to get to, and the product strategy describes the major milestones to get there. Several organizations, large and old, no longer have a relevant strategy and vision, but this is the key.
Team size. This is a very practical principle. The minimum size for a product team is usually two engineers and a product manager, and if the team is responsible for user-facing technology, then a product designer is needed as well. Less than this is considered below critical mass for a product team.
User and customer alignment. User and customer alignment has very real benefits for the product and the team. If, for example, your company provides a two-sided marketplace with buyers on one side and sellers on the other, there are real benefits for some teams to focus on buyers and others on sellers.
Alignment with business. In larger companies we often have multiple lines of business, but a common foundation for our products. If the technology is truly independent of the business areas, then we could just essentially treat them as different companies while structuring product teams. However, for the most part this is not the case. We have multiple lines of business, but all are developed on a common and often integrated foundation.

Part III – The Right Product

Now that we have strong product teams, we need to answer this fundamental question: what should our product team work on?

One of the themes of this book is to focus on outcome, not delivery. Notice that typical product roadmaps are all about delivery. However, good teams should deliver business results. However, typical roadmaps are the root cause of much waste and failed efforts in product companies. Thus, roadmaps are problematic and we need to look at alternatives.

Earlier, I said that we needed to recognize the two factors for conventional style roadmaps. The first is the desire to work on the highest value business items first.

In the model I am describing, it is management’s responsibility to provide the specific business objectives that each product team needs to address. The difference is that they now prioritize business outcomes, rather than product ideas. And, yes, it is a bit ironic that sometimes we need to convince management to focus on business outcomes. The second factor is the occasional need to commit to an inflexible date.

For a product team to be empowered and act with any significant degree of autonomy, it must have a deep understanding of the broader context. This starts with a clear and persuasive product vision, and the path to achieving this vision is the product strategy.

These are some key principles for having an effective product vision:

– Start with the why. This is coincidentally the name of a great book on product value by Simon Sinek. The central notion here is to use the product vision to articulate your purpose. Everything stems from that.

– Don’t be afraid to think big about the vision. Too often, I see product visions that are not ambitious enough, the kind of thing that we can succeed at in six months or a year or so, and not considerable enough to inspire someone.

– Determine relevant and significant trends. Many companies ignore important trends for too long. It is not very difficult to identify important trends. What is difficult is helping the organization understand how these trends can be leveraged by their products to solve customer problems in a variety of ways.

– Go where things are going, not where they were. An important element to the product vision is the identification of what is changing – as well as what is not likely to change – in the time frame and timeframe of the product vision. Some product visions are wildly optimistic and unrealistic about how quickly things will change, and others are overly conservative. This is usually the most difficult aspect of a good product vision.

– Evangelize continuously and relentlessly. There is no such thing as over-communication when it comes to explaining and selling the vision. Especially in larger organizations, there is no getting away from the need for almost constant evangelization. Before the radio-peanuts start spreading, reassure people.

Part IV – The Right Process

We explored product teams in Part Two and described how to decide what each team needs to focus on in Part Three. In Part Four, I explain how product teams do their work. We will look at the techniques, activities, and best practices used to repeatedly discover and deliver successful products.

Although this part is titled “The Right Process,” I hope you will soon realize that the right process is not any single process. Rather, it is more accurately described as a combination of techniques, mindset, and culture.

I mostly emphasize discovery techniques, given that our focus is on product managers and that is their initial responsibility.

Principles of product discovery. We talk about how we do product discovery, there is a set of core principles that direct how we work. If you understand them, you will know not only how to work well today, but also how to easily incorporate new techniques as they emerge in the future.

We know that we cannot rely on our clients (or our executives or stakeholders) to tell us what to develop.
Customers don’t know what’s possible, and with technology products, none of us know what we really want until we actually see it. It’s not that the customers or our executives are necessarily wrong. It’s just our job to make sure that the solution we deliver solves the underlying problem. This is probably the most fundamental principle in every modern product.
The most important thing is to establish persuasive value. It’s all difficult, but the most difficult part of all is to create the value necessary for customers to finally choose to buy or use. We can get by for a while with usability or performance issues, but without the core value, we really have nothing.
We must validate our ideas with real customers and users. One of the most common pitfalls in product is to believe that we can anticipate the real customer response to our products. We could base this on customer research or our own experiences, but either way, we know today that we must validate our ideas with real customers and real users.

Startup Canvas. For decades, people have created dense business plans to try to detail these topics and how they intend to address them. But several people, including me, have written about the various reasons why these old business plans were often more damaging than real.

A startup canvas, a close cousin of the business model canvas, and the lean canvas are designed to be lightweight tools to expose these risks early and encourage the team to address them early.

I prefer the startup canvas to outdated business plans, but I have also observed that several startup teams still spend too much time on their canvas and keep putting off that pesky little problem of a solution that people want to buy.

Referring customers. Let’s be clear about what it means to be a referral customer: it’s a real customer (not family friends), who is running your product in production (not a test or prototype) who has paid with real money for the product (not given to convince you to use it) and, most importantly, who is willing to tell others how much he loves your product (willingly and sincerely)

I love the customer discovery program technique so much because it is designed to produce these referral customers. We discover and develop a set of reference customers in parallel with the discovery and development of the product itself.

Be aware that this technique demands considerable effort, primarily from the product manager. I wish it were easy. But I will also say that if you follow this technique, I consider it the best predictor of future product success.

Principles of prototyping. There are several forms of prototyping. The best choice for you depends on the specific risk being addressed and the type of product. But all forms of prototyping have certain characteristics and benefits in common. Here are five key principles behind their use.

The overarching purpose of any form of prototyping is to learn something at a much lower cost in terms of time and effort than developing a product. All forms of prototyping should require at least an order of magnitude less time and effort as the eventual product.
Realize that one of the key benefits of any form of prototype is that it forces you to analyze a problem at a substantially deeper level than if we talked about it or wrote something down.
A prototype is also a powerful tool for team collaboration. Members of a product team and business partners can all try out the prototype to develop a shared understanding.
There are several different possible levels of fidelity for a prototype. Fundamental fidelity refers to how realistic the prototype looks. There is no such thing as an appropriate level of fidelity. Sometimes the prototype doesn’t need to look realistic and sometimes it needs to be very realistic. The principle is that we create the right level of fidelity for an intended purpose.
The initial purpose of a prototype is to address one or more product risks (value, usability, practicality or feasibility) in discovery. However, in many cases the prototype goes on to provide a second benefit, which is to communicate to engineers and the wider organization what needs to be developed.

Usability testing. We have several good techniques for testing value qualitatively, but they all rely on the user first understanding what your product is and how it works. This is why a value test is always preceded by a usability test.

During the test we check that the user can figure out how to operate our product, but the most important thing is that after a usability test the user knows what your product is about and how it should be used. Only then can we have a conversation with the user about value (or lack thereof).

A/B testing. The gold standard for this type of testing is an A/B test. We love A/B testing because the user doesn’t know which product version he is seeing. This yields data that is very predictive, which is what we ideally want.

Keep in mind that this A/B testing is slightly different from optimization A/B testing. It is in optimization testing that we experiment with different calls to action for the user, different color treatments on a button, and so on. Conceptually they are the same, but in practice there are some differences. Optimization testing usually stays on the surface with low-risk changes, which we often test in a split test (50:50). In the discovery A/B test, we usually have a current product showing up for 99% of our users and the real-time data prototype showing up for 1% of our users or less.

Discovery Sprint. A discovery sprint is a week-long team box of product discovery work, designed to address a considerable risk or problem that your product team is facing.

A discovery sprint is definitely useful for more than just transformation. It could easily be considered a discovery planning technique or a discovery prototyping technique. But it is more useful to bring all these things together, so I choose to include it here.

In any case, during this week of intense discovery work, you and your team will probably explore dozens of different product ideas and approaches, with the goal of solving some significant business problem. You will always end your week by validating your potential solution with real users and customers. And in my experience, the result is consistently great learning and insights – the kind that can change the course of your product or your company.

Part V – The Right Culture

In this final part, I will incite your focus on what is most important to your success. In particular, how does a great product team perform and how do strong product companies provide these teams with an environment where they can thrive?

With a gratifying nod to Ben Horowitz’s classic post “Good Product Manager/Bad Product Manager”, for those who have not yet had the opportunity to participate in or observe a strong product team up close, I provide you with a glimpse into some of the important differences between strong and weak teams:

– Good teams have a persuasive product vision that they pursue with a missionary passion. Bad teams are mercenary.

– Good teams get their inspiration and product ideas from their vision and goals, from observing customer difficulties, from analyzing the data that customers generate from using their product, and from constantly seeking to apply new technology to solve real problems.

– Bad teams collect demands from sales and customers.

– Good teams love to have brainstorming discussions with smart company leaders. Bad teams are offended when someone outside their team dares to suggest that they do something.

– Good teams are constantly trying out new ideas to innovate, but they do it in a way that protects the revenue and the brand. Bad teams are still waiting for permission to run a test.

– Good teams make high integrity commitments after evaluating the request and ensuring they have a viable solution that will work for the customer and the business. Bad teams complain about being a sales-driven company.

– Good teams obsess over their reference customers. Bad teams obsess about their competitors.

– I think of product culture along two dimensions. The first is whether the company can consistently innovate to discover valuable solutions for its customers. This is where product discovery comes in.

– The second is execution. It doesn’t matter how great the ideas are if you can’t deliver a launchable version of your product to your customers. This is where product delivery comes in.

What does a strong innovation culture really mean?

– Culture of experimentation – teams know they can run tests; some will succeed and several will fail and that is acceptable and understandable.

– Culture of empowerment – individuals and teams feel empowered to test an idea.

– Culture of skill diversity and team diversity – teams appreciate that different skills and backgrounds contribute to innovate solutions – especially engineering, design and product.

What does it mean to have a strong execution culture?

– Culture of sense of urgency – people feel that they are in a time of war and that if they don’t find a way to move quickly, bad things can happen.

– Culture of empowerment – teams feel like they have the tools, resources, and permission to do whatever it takes to meet their commitments.

– Culture of collaboration – while team empowerment and autonomy are important, teams understand the even greater need to work together to accomplish several of the biggest and most significant goals.

I can tell you that there really are companies that are very strong in both execution and consistent innovation. Amazon is one of the best examples. However, it is also well known that the work environment at Amazon is not for faint hearts. I have found that many companies that are exceptionally strong in execution are very difficult places to work.

In my experience with companies, only a few are strong in both execution and innovation. Several are good at execution but weak on innovation; some are strong on innovation and just right on execution; and a depressing number are weak on both execution and innovation, such as older companies that have lost their way with the product but still have a strong brand.

Review: Rogério H. Jönck

Photos: Unsplash and reproduction