Book Review: INSPIRED - How to create tech products customers love.

INSPIRED

Background

By all accounts, software development has been wildly successful. Simply consider where technology is at today.

Look no further than the internet. We can find ~1,650,000 articles about random topics like Fly Fishing in 0.52 seconds. We can provision a worldwide software infrastructure with a few clicks of a mouse. We can receive precise driving directions and accurate ETA, taking into account current traffic conditions. We can point our cellphone camera at a random dog and find out the breed with 99% accuracy. We pay people in universal currency and store the transaction in a global, distributed, incorruptible ledger. We ask a small cylinder to book movie tickets for Friday night, turn up the thermostat and recommend restaurants. Cars drive billions of miles fully autonomous. Software is handily beating the world’s best Go champion at his game.

And it’s speeding up. AI is advancing ever faster given the petabytes of data being generated daily. At Google’s I/O keynotes from 2015 onward, Sundar Pichai and Google have consistently and relentlessly focused on their AI first mission. Satya Nadella calls today’s AI driven landscape the “4th Industrial Revolution”. It’s the “AI revolution”. And it’s on. It’s been on for a while. It’s so on that governments are publicly and proudly declaring intent to “win” AI. China publicly declared a AI arms race, the US is responding.

There’s nothing that will slow the accelerating and brutally aggressive force of innovation. Software continues to eat the world. Technology continues to eat the world.

But you know what?

Underlying all the success is a trail paved with failed projects.

The unfortunate truth is the vast majority of software projects fail. Judging from random searches for “software project failures”, it appears people have tried to measure failure, but I’m skeptical of the accuracy. Even if you interview 1000’s of people, how could you consistently label projects as successes or failures? I’ve been on individual teams where many hours were spent “defining what success means”. Heck, even “defining what done means” is something I’ve seen teams struggle with.

Still, the trends are clear and indisputable.

The majority of software projects fail.

With that backdrop, let’s dig into what we’re here to talk about: Marty Cagan’s book INSPIRED.

INSPIRED

The single question this book seeks to answer, the holy grail everyone in tech is searching for, is this:

How do you create successful tech products?

We’ve all been involved with and have seen the countless articles about how companies and products succeed. We’ve seen the IPOs. The VC investments. The launch parties. The TechCrunch articles. We read books like INSPIRED, click bait LinkedIn headlines claiming the “5 steps to build a successful startup”.

I’ve heard a bunch of common themes through the years. And in many cases, successful products have come from these approaches:

• Just hire a bunch of smart engineers and let them loose.
• The best products come from “scratching your own itch”. Focus on something in your life that’s broken, fix it, and sell it.
• It’s all about open source. Open source your project and the community will help build it.

While I believe there is a hint of truth to all of those approaches, the bottom line, and INSPIRED agrees, is that there is no magical formula for success. We can’t open our browser and search “best practices for successful software projects”, follow the guidelines, work hard for a few months, and have success. It doesn’t work that way.

INSPIRED distills down the essence of what author Marty Cagan has seen over his career working with mostly tech companies. He focuses on creating tech products, not manufacturing, or how to start a bakery, however the principles behind success are universal. He rightfully focuses on tech because all companies are tech companies. Even your bakery needs to embrace tech.

So, let’s answer the question, shall we?

How do we create successful tech products?

I’ll summarize the main points of the book as a series of “Greats” from the most important to the least important. But truly, they are all important.

1: Great Culture

I’m cheating on this review. I’m starting from the end of the book. The last part of the book, Culture, in my opinion is by *the* most important. I’m not sure why this was left until the end. Perhaps it was for a grand finale, who knows. Save the best for last philosophy. But in it, Cagan agrees that culture is the most important trait for successful tech products.

It’s all about culture.

This, my friends, is so important. The holy grail of successful tech companies. I feel like you could stop reading this post right now and you have so much of what you need to know about how to create great products. Culture is the root from which all things good and bad grow.

I realize that customers don’t buy your culture. They buy your products. A skeptic would say, and on the surface I would agree, if you don’t have a compelling product that customers love, it doesn’t matter how good your culture is. You need to focus on the product vision and the product itself — after all that is what sells!

While I agree you need to make a great product, how does the product get made? Culture is the underlying fabric upon which products are built. How people are hired. How motivated and inspired the team is. How product decisions are made. Culture helps engineers decide if they are going to spend the next few hours digging into a bug or call it quits for the night.

Every company has a culture. Every. One.

So before we start talking about the formula to create great products, we need to define the environment and framework in which those products will be built. You need to ask yourself the hard questions.

• Why does your company exist?
• What’s your North Star?
• What does your company value?
• Does every employee know the company mission and values? Do they live them?

INSPIRED lays out characteristics of “good” and “bad” cultures. Obviously your company doesn’t need to check off every item on the “good” list, but in aggregate they give us a picture of what successful and unsuccessful teams look like.

Good cultures:

• Obsess over their customers.
• Have a product mindset.
• Passionate about the solving the problem.
• Have an attitude that they are “going to war”.
• Have an inspiring product vision they are working towards.
• Are data driven. Instrument their work. Analyze the data.
• Rapidly prototype.
• Measure success by results.

Bad cultures:

• Obsess over their competition.
• Hold roadmap meetings.
• Consider reporting and analytics a nice to have.
• Have lifeless “agile” ceremonies and measure success in “points” and completing the roadmap.
• Design by committee.

2: Great People

I love the quote INSPIRED includes from John Doerr.

We need teams of missionaries, not mercenaries. — John Doerr

Hiring great people is the mark of a great leader. Thankfully, smart people are drawn to great culture. If you build a great culture, chances are you’ll attract great people.

Once you hire great people, you need to set them up for success. Instill in them a product vision they can become a missionary over — something they are passionate to attack.

We also need to organize them. This involves teams, politics, communication, and corporate structure. This is critical to get right. INSPIRED lists traits successful teams have.

Successful teams…

• Are given clear objectives.
• Must be empowered.
• Must be accountable. They need to feel ownership.
• Are responsible for their *outcomes*, not *outputs*.
• Are autonomous.
• Minimize dependencies.
• Stay together. Relationships build and expertise deepens.
• Are co-located (together) when possible.

I feel like if you look at that list, you are really talking about trust and control. You want teams to feel in control of their work. If they are going to take pride in their work, they need control of their destiny.

And if they are in control of a product, you need to *trust* them. Lack of trust tears down the sense of ownership and control that makes teams successful.

3: Great Product Managers

After culture and people, product leaders are critical to success. In order to be successful, projects need strong leadership. In INSPIRED, the product leader is called the “Product Manager”. You may have a preconceived notion of a Product Manager from past projects and companies. It’s important to understand how INSPIRED defines “Product Manager”. It may be radically different than what you are used to.

The Product Manager (PM) INSPIRED discusses is an all-encompassing product visionary who understands the industry, the market, the landscape, competitors, and the product they are building. They are inspiring, have vision, and are completely invested in the product’s success. They analyze data, love the details, and thrive on building the best product the world has ever seen. They dig in. They work hard with the team. They are passionate about their vision, their product, and their team.

I’ve personally worked with multiple versions of Product Managers over the past 20 years. I completely agree with INSPIRED and I really like the picture it paints of a successful PM. It’s hard to describe the inspiration and passion teams have when they are lead by a really good PM.

What I find interesting is that finding great PMs is so difficult. Most product visions are evolutionary, low risk, and quite frankly boring. They aren’t fully invested. INSPIRED talks about that when referring to “enterprise” companies. I agree. Enterprise companies can be risk adverse and evolutionary. The “enterprise” mindset opens up a great opportunity for people like you and I to help these companies adopt INSPIRED like product development.

To reinforce the book’s strong Product Manager thesis, there are many interludes in the book with successful PM’s from Apple, Google, Ebay (where Cagan worked), Netflix, and others. In all the interludes, the general theme is the PM “owned” the product, rallied the company, and delivered.

Here’s a not-so-hidden secret: People *want* to give their lives to a cause. Elite teams have a mission far beyond money. Instilling that mindset the team is “going to war” motivates people to a level you don’t see in many companies. Product Managers are critical for creating and instilling that mindset and vision.

4: Great Outcomes

Most product roadmaps are the root cause of most waste and failed efforts in product organizations.

Many enterprise companies today build roadmaps. INSPIRED spends pages on why roadmaps are uninspiring and ultimately ineffective for creating great products.

Companies and products aren’t measured by how many project roadmaps they complete, how many teams they have, or how many “points” they finish every week. They are measured by outcomes. INSPIRED views today’s “Church of Agile”, where points are measured and “burndown charts” determine a teams productivity as not as important as happy customers, increased sales, increasing usage, you know — actual results.

People, teams, products, and companies must be measured by outcomes, not outputs. INSPIRED really hammers on enterprise companies who are roadmap driven. I completely agree. Let’s get this straight: completing a roadmap is not the goal! Just because you finish a roadmap doesn’t mean a thing. What value have you produced?

I like INSPIRED’s discussion of what’s wrong with product roadmaps:

• Half of the ideas on the roadmap won’t work. The “value” isn’t there.
• When projects are on a roadmap, they become commitments.
• It typically takes several iterations of a feature before it delivers business value. (Time to money)
• In order to tackle these risks, prototype ideas quick.
• You need to solve the underlying business problem, not implement features.

INSPIRED discusses using “Management by Objective” (MBO), where teams and individuals are rewarded based on objectives (Objective Key Results — “OKR”s), not completing projects.

For example, rather than giving a team the objective of “complete the on boarding project”, give teams the quantitive objective of “reduce average on boarding time to less than 2 minutes for a new customer”. Tell the team what the product should do, let the team decide how to do it.

5: Great Process

Oh, here we go. Everyone’s favorite topic. Process. Agile. Scrum. Waterfall. Religion. Scrum masters. Agile coaches.

Thankfully, you’re saved! INSPIRED doesn’t discuss Agile much (thankfully). INSPIRED focuses on the process of product development, not velocity, points, burndown, or team execution. How refreshing! It’s so much more important to discuss the product development process (analyzing the market, understanding competition, creating ideas, testing features, iterating, etc) than the more narrow focused execution process that “Agile” teams typically follow.

I’m not saying that execution and Agile is not important — not at all. It’s very important. It can be life or death. But in the grand scheme of things, we are here to develop products. We could have completely automated, bug free code which ships to customers every 5 minutes. The best agile ceremonies, point tracking, retrospectives, stand ups, “burn down” charts, etc. But if nobody uses the product, none of that matters.

INSPIRED discusses the process of developing products, which feels like is dwarfed in attention by execution and agile by an order of magnitude in today’s “Agile Coach” driven corporate development cultures.

This process is meant strictly for product managers who own products. As engineers, QA, DevOps, or anyone else on the team, these are equally important to understand.

Traits of a great product development process:

• Spend time on discovery. Collect evidence about what will work for the customer, engineering, and business.
• PMs help customers understand what is possible. They think deeply about the problems their software solves and what customers will ultimately want.
• Validate ideas on real customers (prototypes).
• Validate business feasibility. Just because our customers love it, engineers can create it, does it work for our business? Can we sell it, maintain it, does it work for legal, etc.

Tips and strategies for defining the product:

• Pre-write your press release. What would it say?
• Find six reference (prospective) customers.
• Do customer interviews.
• Pretend you are the customer using your product.
• Sponsor hack days.
• Prototype everything!

Reference customers:

• Reference customers are powerful. They provide feedback, act as a reference point for the product team, and helps sales tell stories.
• Reference customers act as a barometer to determine how successful a product will be. If reference customers don’t love your products, nobody will.
• Your product must be proven to make your reference customers successful before taking it to the broad market.
• Reference customers must invest time and partner with you. They must be serious.
• Do not customize your product for any one customer. You are creating a general product.

Overall, I really appreciated the book’s focus on product development. As I was reading, I didn’t have an “ah ha” moment where I learned something radically new. Each point by itself makes complete sense. Yes, we need vision. Yes, culture is critical. Yes, product managers must own their product. Yes, we must collect feedback, analyze the data, and improve.

But taken as a whole, INSPIRED paints a great picture of what characteristics successful products, teams, and companies embody.

For me personally, INSPIRED opened my eyes to the broader context of overall product development and the critical aspects that are missing in so many products today.

For so many years as an engineer I’ve focused on such a small (but still critically important) piece of the product development process — coding. As engineers we typically focus on learning the next library, language, framework, service, component, or database that we miss the broader picture. Successful software products are built with great cultures, by great people, lead by visionary product managers, are outcome focused, and have a holistic product focused process.

Think deeply about the lessons INSPIRED teaches as you approach new teams, projects, products or companies, or even on your current project(s)!