Introduction

The tagline of this book by Marty Cagan sounds ambitious: “How to create tech products customers love”. Marty Cagan brings a lot of credibility as an author as he has worked with some of the early pioneers of our industry (Hewlett-Packard, Netscape, eBay) and now heads the Silicon Valley Product Group and is considered to be one of the thought-leaders of technology product management.

Structure of the book (and the review)

The book is divided in five major parts:

• Part I: Lessons from top tech companies
• Part II: The right people
• Part III: The right product
• Part IV: The right process
• Part V: The right culture

From a CTO’s perspective and assuming that you don’t want to go too deep into the weeds in terms of discovery techniques and the likes, I recommend to focus on Parts I, II, and V, which this article will do as well.

Lessons from top tech companies (Part I)

The book begins with the “well known basics” - by stating that there’s a huge difference between the good and the great companies and the three major phases you can find yourself in and what you should focus on:

• Early stage companies/products: Focus on finding product/market fit
• Growth companies: Scaling successfully
• Big companies: Make sure to still allow for innovation

Marty identifies the root cause of failed product efforts in the way the product process works in an average company. According to him, usually product development is seen as a linear process with the following steps:

1. Somewhere inside the company, ideas are being generated
2. A business case is created for those ideas
3. Based on this, a roadmap of ideas is put up
4. The product managers then flesh out these ideas with requirements
5. These requirements are passed on to the designers
6. Finally, the requirements along with the design is passed on to the developers to build it
7. Then, usually QA kicks in to double check on what has been built
8. Eventually, the thing is deployed and released

Marty points out 10 major problems with this way of working, of which I want to highlight four that seem most important to me (Marty seems to like superlatives, so for him every single one of those 10 is the most important one - I assume that’s an American thing :)

Problem 1: Team empowerment & Innovation from the teams Working in this linear style makes the development teams pure implementation teams - teams of mercenaries, rather than teams of missionaries. Utilizing your engineers in this way makes them realize only a fraction of their full potential in terms of creating great solutions, being highly motivated and really understanding which problems they are asked to solve. Marty says that engineers are typically the best single source of innovation.

Problem 2: Focus out output rather than outcome Marty points out that this style of working often leads to roadmaps full of prioritized features and projects. This tends to lead to the impression that the success of products is a predictable thing that can be planned for. The fundamental truths he is referring to however are, that a) Half of our ideas just don’t work out at all, and b) The others need several iterations until they yield the desired outcome.

Product roadmaps that focus on outputs (features, projects) rather than outcomes tend to neglect this fact, often times leading stakeholders to belief that it’s enough to deliver the feature, rather than iterating until the desired outcome is completed.

Problem 3: Role of product management In this style of working, product management rather should be called project management, as it is about taking requirements and documenting them for the engineers. Which is simply the opposite of what every successful tech product company is doing.

Problem 4: Validation happens way too late Finding out that a particular idea does not work takes a very long time in this model, as the first real customer feedback is only incorporated once the product is released. Until then, it’s merely the opinions within the company, its management and the assumptions of the business case that are used to justify the effort.

So what to do instead?

Marty suggests to look at the essence of Lean and Agile to address those problems. In fact, he notes that it seems to be in fashion nowadays to criticize Agile and Lean as buzzwords - and for sure there are a lot of people bending the scope, the original ideas or mis-using those words to sell their books, services and products. So he offers us the essence of what he things we should learn from Lean and Agile:

1. Tackle risks upfront rather than at the end 2. Design products collaboratively, rather than sequentially 3. Focus on solving problems, not on implementing features

Based on this, Marty suggests the following main activities as an alternative to the linear model:

• Continuous discovery and delivery: Always work in parallel on discovering what is of value to the customer and delivering it in small batches in a continuous fashion
• Take product discovery seriously: Make sure to validate the key risks (will users use/buy it? do users understand it? can engineering build it? does it have the support of all stakeholders?). The output of this activity should be a validated backlog
• Build prototypes: Marty’s definition of a prototype is something super light-weight that just served the one single purpose of testing one of the key risks. In his view, a strong team should be able to test 10 to 20 of them per week, which makes it obvious that he’s not talking about big pieces of work here.
• Distinguish between prototyping and delivery: Delivering a production-quality product is clearly a task that requires much more work (e.g. proper testing, scalability, reliability, fault tolerance, security,..). So it should clearly be divided between prototyping work and product delivery. For Marty, an MVP should not be a delivery quality product, but rather a prototype.
• Create a proper product vision: The product vision is central concept for Marty as well. It’s main purpose though should be to properly communicate within and outside of the team and create the right mindset for all people rather than giving concrete advise on how a feature should look like.

Part II - The right people

To me it seems a bit like a platitude to say, that strong product teams are at the heart of strong product organizations. So what exactly makes strong product teams? According to Marty it’s:

• A team that has all the different skills it needs
• A team that feels real ownership for a product (or a substantial piece of it)
• A team that behaves like missionaries, not mercenaries
• A team sized at a minimum of 2-3 people, and a maximum of 10-12 people
• A team that is given clear objectives, with ownership of delivering to those objectives
• A team that does not have the Product Owner as the boss of anyone in the team
• A team that is co-located, with a preference to actual employees instead of contractors or agencies
• A team that has responsibility for all the necessary work (projects, features, bug fixes, performance, …)
• A team that is long-lived, not just put together for a project or feature
• A team that only has minimal dependencies to other teams (minimal does not mean none, usually)

He argues that these characteristics work especially well, because the collaboration that we want to create is built on relationships and people, which simply works best in a co-located, stable environment. Secondly, creating good solutions requires a certain degree of expertise that first needs to grow, which makes durable teams much more effective. And third, creating those solutions to the business objectives within the teams creates a great sense of ownership and responsibility for the outcome: the team is not “off the hook” just because they shipped a feature. They need to follow up on the desired outcome and see whether their approach really worked.

Marty gives a short overview about the different roles in the setup and what he thinks should be their key tasks and focus:

The product manager

Marty mentions two anti-patterns to be aware of as a product manager. He warns not to become a “backlog administrator” (which is a common pattern of people who just got a Certified Scrum Product Owner). And he warns not to try to create stakeholder consensus on everything, ending up in a “design by committee” style as a “roadmap administrator”. Instead, Marty describes the responsibilities of a product manager as simple as evaluate opportunities and determine what’s getting built, with an emphasis on making sure that what is getting build is really worth building. He lists a couple of traits that are needed to succeed in this role, which include:

• A deep knowledge of the customer, the business and the data
• Deep knowledge of the market and the industry
• Smartness, Creativity and Persistence

Another common anti-pattern is to split the roles of product managers and product owners. Marty argues, that you will lose the team’s ability to innovate if you split those two roles. He sees the product owners responsibilities as a subset of the product manager’s responsibilities, but according to him it’s essential that the product manager covers both.

The product designer

The book points this out nicely: “In the old model, designers took requirements or specifications from product managers and used that to create their designs. In contrast, modern product designers continuously collaborate with product managers and engineers - from discovery to delivery.” Marty argues, that even in B2B products design starts being a differentiator. He advocates to co-locate the designer with the team to make them participate as full team members rather than just as a supporting role.

The engineers

An interesting point that Marty brings up is how interactions between product managers and engineers look like in high performing teams. They are usually twofold:

• One part is to get their ideas and input for things in the discovery phase
• The other part is to clarify questions that pop up along the implementation of things in the delivery phase

The product marketing manager

The term “marketing” is confusing to many people, as its definition has changed a lot over the years. Some see their role as pure “promotion” department (where all the fancy T-Shirts and mugs with the company logo are created), some see them as the ones defining the product, whereas product management is then responsible to deliver that product together with engineering. Marty defines the role of marketing as the ones who “represent the market to the product team - the positioning, the messaging, and a winning go-to-market plan. They are deeply engaged with the sales channel and know their capabilities, limitations, and current competitive issues.”

The head of product / CPO role

The assumption here is, that this person is the most senior product role in the organization. Key responsibilities of this role are: * Team development * Product Vision * Execution * Production Culture

Team development is hereby seen as the most important of the four. How strong of a product visionary the CPO needs to be is determined a lot by how strong of a product visionary the CEO is. The CPO should be a complement to the CEO, i.e. with a very product focused CEO the focus shifts more towards execution. For the execution part it is essential, that the CPO is an expert in modern forms of product planning, customer discovery, product discovery and the product development process. To get from good to great, the product culture aspect is key. “A strong product culture means that the team understands the importance of continuous and rapid testing and learning.”

The head of technology / CTO role

“The hallmark of a great CTO is a commitment to continually strive for technology as a strategic enabler for the business and the products.”

The key concerns of the tech organization include:

• Leadership: Representing technology in the overall strategic directions and decisions (e.g. helping to inform M&A activity, build vs. buy decisions, …)
• Architecture: Simply put, this means to orchestrate the company-wide technology strategy
• Discovery: The goal here is to make sure that engineering is participating in product discovery activities
• Evangelize: Being the spokesperson for engineering, internally and externally
• Organization: Making sure the skills of the engineers are developed, resulting in high retention rates and a great tech culture
• Delivery: Making sure software can consistently and frequently be delivered at the proper quality

Structure of product teams

Marty explains that there is no recipe for a perfect product team structure. But there are some principles Marty discovered to be useful of which I want to mention the ones I think are most relevant:

1. Minimize Dependencies: Less dependencies allow teams to move faster and feel more autonomy.
2. Ownership and Empowerment: Design your team structure in a way that makes the team members missionaries, not mercenaries. “A team should feel empowered, yet accountable for some significant part of the product offering.”
3. Carefully think about shared services:Creating shared services teams can gain speed and increase reliability. But it also creates dependencies and can have negative effects on team autonomy. So be careful with shared services teams and make sure to staff them with very technical product managers (“platform product managers”)

Part III - The right product

This chapter deals with the question what the product teams should be working on. Marty starts off with an explanation why roadmaps are a dangerous tool. The problem Marty sees in using roadmaps is, that they are mainly focuses on output, while we should rather ask our teams for business results (outcome rather than output). He acknowledges the underlying demands of management to make sure that the teams work on the highest value items first, and to establish a certain level of predictability and plan-ability. Creating roadmaps, however, tends to neglect the “two fundamental truths” of product development:

• The fact that half of the product development ideas just don’t work out, and
• That it typically takes several iterations to get ideas to the point where they deliver the expected value

“It’s worth pointing out that it isn’t the list of ideas on the roadmap that’s the problem. If it was just ideas, there’s not much harm in that. The issue is that anytime you put a list of ideas on a document entitled “roadmap”, no matter how many disclaimers you put on it, people across the company will interpret the items as commitment. And that’s the crux of the problem, because now you’re committed to building and delivering the thing, even when it doesn’t solve the underlying problem.

As an alternative to those kinds of roadmaps, Marty suggests to emphasize the product vision and to set business objectives for every team (OKRs to be mentioned as one way of doing that). Sometimes the need to commit something for a certain date is inevitable, but this should be reduced the the absolute bare minimum and treated as an exception rather than as the norm.

Marty explains the fundamentals of getting to a product vision and a proper product strategy on pages 129 - 153, so that’s a recommended read if you want to dig deeper on this.

Part IV - The right process

Chapter IV is a great read if you want some hands-on advice on how to properly do product discovery, ideation, testing, prototyping and evaluation. It does show a wide variety of techniques, so read it if you are facing this as one of your challenges.

Part V - The right culture

“It’s easy to get hung up on the minutiae of all this, but what’s really important here is creating the right product culture for success.”

Marty shares his learning, that there is a big difference between how the very best tech companies create products versus all the rest. He provides a list of key differences between strong and weak product teams, of which I want to highlight a few:

• Good teams have a strong product vision and a “missionary-like passion”. Weak teams behave like mercenaries.

• Good teams create their ideas from the vision, their objectives and direct customer interaction (feeling the customer’s struggle). Weak teams gather requirements from sales.

• Good teams have “product, design, and engineering sit side by side”. Weak teams sit in their silos and prefer to communicate through documents and work orders instead of direct interaction.

• Good teams make sure that their engineers participate in product discovery every day and try out the PO’s and designer’s prototypes every day. In weak teams, engineers are only involved when it comes to estimating effort.

Finally, Marty points out the cultural differences of what it takes to be great executors versus great innovators. While a culture of innovation is characterized by a culture of experimentation, open minds, empowerment and business- and customer-savvy teams, a culture of execution is rather built on a culture of urgency, commitments, accountability and results. Obviously, this is extremely tough to achieve in one and the same organizations.

“I can tell you that there do exist companies that are very strong at both consistent innovation and execution. Amazon is one of the best examples. However, it’s also well known that the Amazon work environment is not for the faint heart. I’ve found that most companies that are exceptionally strong at execution are pretty tough places to work.”

Curious for more?

• Read the book, I can really recommend the full version - Buy it on Amazon
• Don’t miss my article on Misunderstandings in innovation cultures