Summary of Inspired 2 by Marty Cagan - Part 1/3

I picked up Marty Cagan's second part of Inspired - How to Create Tech Products Customers Love. We all know about his first book, Inspired, which was written ten years ago and became a gold standard of reference for all product managers - new and experienced alike.

Why did Marty write a new edition of the book?

When the first edition of Inspired was published, Agile was not well established in product companies. That was also before Customer Development and Lean Startup was popularised. First edition was focused more on startups. For this edition, the focus is on challenges of growth stage companies and large enterprise companies.  

Why should we heed to what Marty Cagan say?

Marty led product management in HP in 1980s. After that for over 30 years, he worked on some of the most successful hi-tech products of our time - VP, Products at Netscape, Sr VP, Products at eBay, and advisor to many startups and Fortune 500 companies in Silicon Valley. He has his head and ear close to the ground in Silicon Valley product community where he spends most of his time training and consulting with some of the best product companies. He is one of the few sought after thought leaders in the industry on product management.

How is the book structured?

The new book has a total of 67 chapters and is divided into 5 parts:

1. Part 1- Lessons from Top Tech Companies

2. Part 2-The Right People

3. Part 3- The Right Product

4. Part 4-The Right Process

5. Part 5-- The Right Culture

In this post, I will summarize the first two parts and will follow up with two more posts to summarise the rest of the book.

Part 1 - Lessons from Top Tech Companies

Marty Cagan realised that there was a tremendous difference between how the best companies produced products and how most companies produced them. 

Chapter 1: Behind Every Great Product

Marty realized that behind every great product there is someone-usually someone behind the scenes, working tirelessly- who led the product team to combine technology and design to solve real customer problem in a way that meets the needs of the business. Usually, this someone is the product manager. 

Chapter 3: Startups: Getting to Product/Market fit

In tech world, there are three stages of companies: 

• Startups

• Growth stage

• Enterprise 

Startup is any new product company that has not achieved product/market fit. In a startup, a product managers role is covered by one of the co-founders. 

The reality of a startup life is that you are in a race to achieve product/market fit before you run out of money. Nothing else much matters unless you can come up with a strong product that meets the needs of the initial market. 

There is high failure rate for tech startups- The few that succeed are good in product discovery, which is a major topic of the book. 

Chapter 4: Growth Stage Companies: Scaling to Success

These startups achieve product market fit and are ready to tackle the next difficult challenge - how to effectively grow and scale. 

Even though its challenging its a good problem to have. 

In this stage, hiring is key, and figuring out how to replicate the earlier success with new adjacent products and services. And at the same time, growing the core business as fast as possible 

Typically has 25 to several hundred engineers. There are many people to help but Signs of organisational stress are everywhere. 

Chapter 5: Enterprise Companies: Consistent Product Innovation

Strong product companies know they need to ensure consistent product innovation. This means constantly creating new value for their customers and for their business. Not just tweaking and optimising existing products (refereed to as value capture) but rather developing each product to reach its full potential. 

When a company is young, it likely had a clear and compelling vision. When it achieves enterprise stage, the company has largely achieved the original vision and now people aren’t sure whats next, product teams complain about lack of vision, lack of empowerment, takes forever to get a decision made, and product work is turning into design by committee. 

Leadership is likely frustrated too with the lack of innovation from the product teams. All too often they resort to acquisitions or creating separate “innovation centres” to incubate new businesses in a protected environment. Yet, it rarely results in innovation. 

Chapter 6: The Root Causes of failed Product Efforts

What do average companies do that great successful tech companies dont?

• Most companies start with ideas that come from inside (executives, key stakeholders, business owners) or outside (current or prospective customers)

• Most companies prioritize these ideas into roadmaps. 

• They want to work on the most important ideas first and want to be able to predict when things will be ready. 

• To accomplish this, they have some form of quarterly or annual planning session. But in order to prioritise, they first need a business case for each item. 

• The business case srtrives to address twi things:

• How much money or value will it make?

• How much money or time it will cost?

• The information is then used to come up with roadmap, usually for the next quarter, or an entire year. 

This is how most average companies operate. 

What are the problems with this kind of approach?

1. With regards to source of ideas, this model leads to sales—driven and stakeholders-driven products. This is not the source of best product ideas. Another consequence is the lack of team empowerment. 

2. The flaw in business case is that we cant know how much money we will make because that depends upon how good the solution turns out to be. Also we have no idea how much will it cost to build. The two inconvenient truths about our product by Marty Cagan - 1) At least half of our ideas are just not going to work. 2) Even with the ideas that do prove to be valuable, usable and feasible, it will take several iterations to actually deliver the expected business value. The real difference is how you deal with these truths.

3. This is not real product management— gathering requirements and documenting them for engineers.

4. The entire process is very project centric - The company funds projects, staffs projects, pushes projects through the organization, and finally launches projects. Unfortunately, projects are all about outputs, and product is all about outcome.

5. In this process, customer validation happens way too late.

The best product organization dont follow the above steps. 

Chapter 7: Beyond Lean and Agile

The best product teams have three overarching principles: 

1. Risks are tackled upfront rather than at the end. - In modern teams, we tackle these risks prior to deciding to build anything. These risks include value risks (whether customers will buy it), usability risks (whether users can figure out how to use it), feasibility risks (whether our engineers can build what we need with the time, skills, and technology we have)'

2. Products are defined and designed collaboratively rather than sequentially - In strong teams, product, design, and engineering work side by side, to come up with solutions that our customers love. 

3. Finally, its all about solving problems, not implementing features. — conventional product roadmaps are all about output. String teams know that solution must solve the underlying problem. Its all about business results. 

Chapter 8: Key Concepts 

This chapter lays out a set of concepts that form the foundation of modern product work. 

1. Holistic Product: This is what he was trying to say -https://www.linkedin.com/pulse/primer-whole-product-model-ravi-kumar-sapata/

2. Continous discovery and delivery - Read more here - https://www.linkedin.com/pulse/what-did-i-learn-from-talking-product-discovery-coach-sapata/

3. Product discovery: The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog. Specifically this means ´, getting answers to four critical questions: 1) Will the user buy this (or choose to use it?) 2. Can the user figure out how to use this? 3) Can our engineers build this? 4) Can our stakeholders support this?  

4. Prototypes: Product discovery involves running a series of very quick experiments, and to do these experiments quickly and inexpensively, we use prototypes, rather than products. 

Part 2- The Right People

In this section, Marty describes the key roles and responsibilities of modern technology powered product teams. According to him, every product begins with the people on the cross- functional product team. How you define the roles, and the people you select to staff the team, plays a determining factor in its success and failure.

Principles of Strong Product Teams:

• Teams of missionaries, not teams of mercenaries:Mercenaries build whatever they are told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.

• Team composition: A typical product team comprises of a product manager, a product designer, and somewhat between 10-12 engineers.

• Team empowerment and accountability: They are given clear objectives and they own delivering on those objectives. They are empowered to figure out the best way to meet those objectives, and they are accountable for the results. 

• Team size: The upper bound of a team is around 8-12 engineers. Remember the 2 pizza rule. More important is the balance of skills needed to ensure we build things right and build right things. 

• Team reporting structure: A product team has intentionally flat org structure. Everyone is an individual contributor and no people managers.

• Team Collaboration: True collaboration literally means product, design, and engineering working out solutions together.

• Team location: The best companies have learned the value of co-locating and sitting together as a team.

• Team scope

• Team duration:The bottom line is to keep teams together and fairly stable.

• Team autonomy: If we want teams to feel empowered and have missionary like passion for solving customer problems, we need to give them a significant degree of autonomy.

The Product Manager

This is one of the most important chapters since the role is managed in so many varied ways in different organisations.

"The honest truth is that the PM needs to be amongst the strongest talent in the company. “

Key Responsibilities:

• Deep knowledge of the Customer

• Deep knowledge of data

• Deep knowledge of your business

• Deep knowledge of your market and industry

• Smart, creative and persistent

Instead of providing theoretical characteristics, Marty also provides profiles of real PMs from the best products in the industry, like Google, Microsoft, Netflix etc who match these aforementioned characteristics.

The key takeaways from all these PMs are the following:

• Like a CEO, the PM must deeply understand all aspects of the business. He must ensure a business outcome, not just define product. Includes understanding interrelated parts and constraints of business - financial, sales, legal, UX etc. 

• True leadership is a big part of what separates the great product people from the merely good ones.

According to Marty, PMs should take two specific academic courses:

• Introduction to Computer Programming

• Introduction to Business Accounting/Finance

The Role of Leadership

The primary job of leadership in any technology organization is to recruit, to develop, and to retain strong talent. However, as per Marty, the role of leadership goes beyond people development and into what is called holistic view of product.

For a startup, there is just one or two product teams. So its not too hard to keep a holistic view. But as the company scales, first to a larger product and then to many product teams, keeping a holistic view becomes difficult. 

Holistic view leadership roles:

There are three critical roles to maintain the holistic view of the product: 

• Leaders of product management: To ensure a holistic view of how the entire system fits together from a business point of view (vision, strategy, functionality, business rules, and business logic), we need either the leaders of PM organization (VP product, Director of products) or Principal Product Manager. 

• Leaders of product design: These leaders are responsible for holistic user experience. These leaders must ensure a consistent and effective user experience systemwide. It must be someone with very strong in holistic product design. 

• Leaders of technology organization 

Chapter 17: The Head of Product Role

Marty wrote this chapter for three different audiences: 

• If you are a CEO and are looking for a head of product. 

• If you are already a head of product 

• If you aspirations of leading a product organisation

The roles can be interchangeablly titled as VP, Products or Chief Product Officer. This role managers product managers and product designers and reports to CEO. It is important that this role peers with CTO and VP, Marketing. 

This is a difficult role to perform well and those who succeed, make a dramatic difference for their companies. Great product leaders are highly valued and go on to found their own companies. 

Some of the best VCs invest in founders who have already proved themselves as great product leaders. 

Proven to be strong in four key Competencies: 

• Team development: The single most important responsibility of any VP product is to develop a strong team of product managers and designers. This means making recruiting, training and ongoing coaching the top priority. Realise that developing great people require a different set of skills than developing great products. 

• Product vision and strategy:  

• Execution: You need a product leader who knows how to get things done and has absolutely proved their ability to do so. There are many aspects that contribute to a team’s ability to execute consistently, rapidly, and effectively. The product leader should be expert on modern forms of product planning, customer discovery, product discovery, and product development process. The bigger the organization, the more critical it is that the person has proven, strong skills - especially in stakeholder management, and internal evangelism. The product leader must be able to motivate and inspire the company and get everyone move in the same direction. 

• Product culture: Good product organizations have a strong team, a solid vision, and consistent execution. A great product organization adds a dimension of a strong culture. A strong VP, Product will understand the importance of a strong product culture, be able to give real examples of his or her own experiences with product culture, and have concrete plans to instil this culture in their company. 

Chapter 20: Principles of Structuring Product Team

One of the most difficult issues facing every product organisation at scale is just how to split up your product across your many product teams. 

As you scale, it becomes a significant factor in the company’s ability to move quickly. Its also a significant factor in keeping teams feeling empowered and accountable for something meaningful, yet contributing to a bigger vision. 

There is no single recipe for structuring product teams.

However, there are some critical core principles: 

1. Alignment with investment strategy: Many organisations have teams that are merely reflections of their ongoing investments. Best practice is to reduce investments in our cash cow products so that we can invest more in future sources of revenue and growth. 

2. Maximize leverage: As organization grows, we often find common needs and increased importance of shared services. This is done for speed and reliability. However, creating shared services also creates dependencies. 

3. Product Vision and Strategy: Once you have your vision and strategy, ensure you have structured the teams to be well positioned to deliver on them.

4. Alignment with architecture: In practice, for many organizations, the primary principle for structuring the product teams is architecture. Many will start with product vision, come up with architectural approach to deliver on that vision, and then design the teams around that architecture. There are good reasons for this. Architectures drive technologies which drive skill sets. While we would love for every team to be a full stack team that can work on any layer of architecture, in practice thats often not an option. Different engineers are trained in different technologies. If you dont pay attention to architecture when assembling the teams, interdependencies between teams seem disproportionate. For larger companies, its typical to have one or more teams that provide common services to other product teams. We often label them as common services, core services or platform teams. These teams are often formed to enable the other teams. They are led by highly technical product managers (often called platform product managers). 

5. Alignment with User or Customer: Aligning with user or customers has very real benefits  for product and the team. If for example, your company provides a two-sided marketplace with buyers on one side and sellers on another side, there are real advantages to having some teams focus on buyers and others on sellers. Each product team can go very deep with their type of customers rather than have them try to learn about all types of customers. 

6. Structure is a moving target: The optimal structure of the product organization is a moving target. The organisation needs should and will change over time. Reviewing your team structure every year or so makes sense. 

There is a never a perfect way to structure a team. As with most things in products, it involves tradeoffs and choices.