Book summary: “ Inspired: How To Create Tech Products Customers Love” — Part 1

One Sentence Summary of “The bible for modern product management”

If you are truly looking for some valuable resources to learn and understand about product management, then I strongly recommend you to read this book twice. Buy link — here

About the author:

Marty Cagan — Before founding the Silicon Valley Product Group to pursue his interests in helping others create successful products through his writing, speaking, advising, and coaching, Marty Cagan served as an executive responsible for defining and building products for some of the most successful companies in the world, including Hewlett-Packard, Netscape Communications, and eBay. You can find more details in the SVPG sites and follow him on twitter for the bytes and the updates.

This book covers various horizons and vertices in and around product management with a lot of valuable information. So, I’m trying my best to capture the information and explain it in simpler terms. (Hopefully, that helps!)

I’ve planned to partition the book summary into six segments — One chapter in each blog/ story. This is to reduce the size of the story and with the aim not to cause the reader to feel bored with the lot of things to process and understand at the same time.

Now let’s jump to

Part 1 : Lessons from top tech companies

Firstly, Who is the Product Manager?

• The person who led the product team to combine technology and design to solve the real user’s problems in a way that met the needs of the business.

In the technology world, there are three types of companies:

1. Startup companies
2. Growth — Stage companies
3. Enterprise companies

Now, let’s go to the details of each of the types

Startup companies: Getting to the product/market fit

• A company that is yet to achieve the product/market fit and trying to come up with a product that can power a viable business.
• Usually, one of the co-founders will be playing the role of the PM.
• The reality of startup life is you’re in a race to achieve the product/market fit before you run out of money.
• The closer you come to running out of money, the more desperate the team and the leadership becomes.
• Typically, there are fewer than 25 engineers, covering a range of product teams up to 4 or 5.

Growth-Stage Companies: Scaling to success

• Startup++
• Those Startup which is skilled and fortunate enough to get product/market fit are ready to tackle the next difficult challenge. “How to effectively grow and scale” (Good problem to have)
• The product team complains that they don’t understand the big picture, they don’t see how their work contributes to the larger goals and they are struggling with what it means to be empowered and autonomous teams.
• Sales and Marketing teams often complain that go-to-market worked for the first product does not work for some of the new products in the portfolio.
• Technology infrastructure that was created to meet the first product needs are often busting at the seams and you start hearing the team more often “Technical debt” from every engineer that you interact with.
• This is even though for the leaders because the leadership style and process worked for the young startup often fail to scale. In this case, the leaders are forced to change the roles, behaviors, and mindset.
• Typically, they are somewhere between 25 to several hundred engineers, there are a lot of people to help here.

Enterprise companies: Consistent product innovation

• Growth-Scale ++
• For those companies that succeed in scaling and they want to create a long-lasting business. Strong tech-product companies know they’ll need to ensure consistent product innovation.
• This means constantly creating new value for their customers and the business. Not just tweaking or optimizing the existing product but rather, developing each product to reach its full potential.
• The companies which are failed to do so will get stuck in a slow death spiral. (which doesn’t happen overnight)
• Products teams complain about the lack of vision, lack of empowerment, and the fact that it takes forever to make the decision.
• Leadership is likely frustrated with the product team about the lack of innovation.

The Root causes of failed product efforts

The development process that more companies follow to create products

• As you see, everything starts with the idea 💡 . It could come from Internal (Executives, product teams or key stakeholders) and External — current or potential customers.
• Wherever the ideas originate, there are always a whole bunch of things that different parts of the business need us to do.
• Now, we need to start prioritizing those ideas into the roadmap for two reasons — Work on the most important thing first and Predict when it will be ready.
• Once the idea makes it to the top of the list, PM should be talking to the stakeholders to flesh out the idea and come up with “Set of requirements” (User stories or PRD)
• Once the requirements are outlined, then work with the product designs for making a visual design, wireframe, or prototypes.
• Finally, the requirements and design spec make it to the engineer. This is where the Agile finally enters the picture.
• Now, engineers will break up the work into iterations (Called — Sprint in the Scrum). Deploy the idea to the customer about receiving the green signal from the QA team.

Top 10 biggest problems with this way of working

1. The source of idea

• This model leads to sales and stakeholder-driven products.
• Lack of team empowerment.
• The team is used to just there to implement — they’re mercenaries.

2. Business case

• Leadership looking for the answers to these two questions: How much money you’ll make and how much it will cost?
• We can’t know because it entirely depends on how good the solutions turn out to be. No idea what will be cost to build

3. Product roadmaps

1. Product Roadmap — The prioritized list of products and features
2. The marketing team needs this for a campaign and sales team need this feature for the customer

Two inconvenient truths about the products:

At least half of the idea is just not going to work

With the idea that does prove the market potential, it typically takes several iterations to deliver the necessary business value (Time to money. )

4. Role of product management

5. Role of design

• Similar to above, it’s way too late to the game to get the real value of the design. Mostly what we do is called “Lipstick on the pig” model

6. Engineering bought late to the process

• If you think engineers are only to code, then you are only getting half of their value. Little secret: Engineers are the best source of innovation, and yet they are not invited to the party.

7. Principles and key benefits of agile also entering late

• Teams using Agile in this way are getting only 20% of the actual value and potential. What you are using agile is for delivery!

8. Project centric process

• Projects are output and products are all about outcomes. This often leads to orphaned projects.

9. Agifall process

• The biggest flaw of the old waterfall process has always been, and remains, that all the risk is at the end, which means that customer validation happens way too late.
• And then I point out to them that they are trying out ideas in one of the most expensive, slowest ways we know.

10. Opportunity cost

• The opportunity cost of what the organization could have and should have been doing instead. We can’t get the time and money back lost.

Beyond Lean and Agile: Three overarching principles at work:

1. Risk is tackled upfront rather than at the end.

Value risk — whether the customer will buy it
Usability risk — whether the user can figure out how to use it
Feasibility risk — Whether our engineering can build that we need in the given time, scope, and the technology which we have today.
Business viability risk — Can I stakeholders support this?

2. Products are defined collaboratively not sequentially.

• Product, design, and engineering work side by side, in a give and take way, to come up with the technology-powered solutions that our customers love and that work for our business.

3. It’s about solving the problem, not implementing the features

• They must ensure that solution solves the underlying problem. It’s about business results.

Key concetps

1. Continuous discovery and delivery:

• We need to discover the product to be built, and we need to deliver that product to the market. Discovering and Delivery are two main activities on a cross-functional team and they both are typically ongoing and in — parallel.

2. Product discovery

• The output of the product discovery is the validated product backlog. This means answering these four questions. (Will the user buy this?, Will the user able to figure out how to use this?, Can our engineers build this?, Can our stakeholders support this?)

3. Prototypes

• Product discovers requires running a series of experiments (trial and identity). To do those experiments quickly and inexpensively, Prototypes are used over the products. Usually, Prototype determines if the product is worth building or not.

4. Product / Product-market fit

• Just because we invested time and effort to build the product doesn’t mean anyone will buy it. So in the product world, we strive hard to achieve the product/market fit. The discovery activity determines the necessary product but it’s the delivery that actually does the work necessary to build, test, and release the product.

Disclaimer: At some places, I’ve used the exact phrases from the book to capture the 100% nuances of the information.

If you enjoyed 👌 this story, please click the 👏 button and share it to help others find it! Feel free to leave a comment below ✋.

In the next blog, we can dig deeper into the roles and responsibilities for the product team (each department) and the leadership. Stay tuned ❗️⭐️