Inspired how to create tech products customers love

Book review: “Inspired: How To Create Tech Products Customers Love”

About four years ago I read and reviewed Inspired: How To Create Products Customers Love by Marty Cagan, who I regard almost as the ‘founder’ of modern tech product management — along with Steve Jobs of course 🙂 Cagan has now released a second edition of “Inspired” in which he captures two aspects he’s uncovered since writing the first edition.

The first aspect is a critical need to focus on the specific job of the product manager, aiming to clarify which elements constitute the role of a product manager in a tech company. The second aspect is the importance of creating the right product culture for success, and understanding the range of product discovery and delivery techniques available to solve customer and business problems.

Whilst the book contains a wealth of valuable content about product management and how to create great products; in this review I’ll primarily focus on Cagan’s recommendations with respect to product discovery and delivery. Before I do that, it’s important to first look at Cagan’s take on the “root causes of failed product efforts” (Fig. 1).

Cagan sees a very sequential, “Waterfall” type approach as the underlying reason why many products fail. This approaches comes down to companies using a ‘feature heavy’ and preplanned roadmaps, as well as and using regular planning sessions to negotiate and prioritise the roadmap. Cagan shares some home truths to explain why this approach is now obsolete (Fig. 2).

Fig. 2–10 problems that companies using a Waterfall type approach suffer — Adapted from: Marty Cagan, Inspired: How To Create Tech Products Customers Love, pp. 17–21

Cagan offers three overarching principles which help overcome the aforementioned root causes of failed product efforts:

“Continuous Discovery and Delivery” is a great way to translate these three principles into a process and mindset for people to adhere too (Fig. 3). You can see how Cagan has taken the eight steps involved in the traditional waterfall approach (Fig. 1) and condensed them into to three, continuous stages: Objectives — Discovery — Delivery (Fig. 3).

Ultimately, this process enables you to to get answers to four critical questions:

Apart from these four critical questions, I like the emphasis Cagan puts on business context over a traditional product roadmap. In the book, Cagan covers two main components that provide this business context:

The “risk” aspect feels like a crucial one to me, and thinking about ways to identify and mitigate risks early and often. For example, I’ve found the pre-mortem technique to be a great way to unearth key risks right at the outset. Cagan describes some common risks to consider:

Cagan then goes on to describe three of his favourite discovery framing techniques:

1. Opportunity Assessment

The idea is to answer four key questions about the discovery work you’re about to undertake:

2. Customer Letter

Cagan refers to Amazon and their working backward process, where you start the product effort with a fictitious press release.

3. Startup Canvas

The “Startup Canvas” is particularly useful when you work at an early stage startup and are staring from scratch, both with the business and your product or service. There are lots of these canvases around for you to have a closer look at; I’d suggest having a look at the Business Model Canvas (by Alex Osterwalder) and the Lean Canvas (by Ash Maurya; Fig. 4).

Cagan explains how you can use a canvas for any product change, no matter the size, but you would likely quickly find a risk of duplication once you’ve got an existing business and product. I agree that the law of diminishing returns kicks in once you’ve already established your business and products, since you’ll have already figured out things like your cost structure or distribution strategy.

Finally, Cagan explains about “testing value” as a key thing to consider when planning your customer discovery. The main thing here, Cagan stresses, is to learn whether customers perceive your product to be substantially better than the competition. So many companies and product teams think all they need to do is match the features of the competitive alternatives. This idea of “feature parity” being enough to woo customers has proven to be a false one. The reality is that for customers to switch from an existing product, they need to perceive the new product as a much better alternative.

For example, sometimes it’s not clear whether customer want what it is that we’re going to build and it can be very risky to simply think “we’ll build it and customers will come.” In the book, Cagan talks about how you can quickly and cheaply test whether there’s demand for instance through launching just a landing page. On the landing page, we describe the new offering exactly as we would if we were really launching the service. The difference is that if the user clicks the call to action, rather than getting the expected outcome, the users sees a message that explains that you’re thinking of launching the new service and that you’d love to get initial input from the user. It all falls under the mantra “Do Things that Don’t Scale”, first introduced by Y Combinator Founder Paul Graham. A good example is this one from Buffer:

Main learning point: Marty Cagan has written a great followup to his first edition of “Inspired”. In this edition, he offers valuable tips and examples in relation to important themes as product discovery and delivery. Whether you’re new to product management or have got some good product management experience under your belt, “Inspired: How To Create Tech Products Customers Love” is a great and valuable read.

INSPIRED: HOW TO CREATE TECH PRODUCTS CUSTOMERS LOVE

AUTHOR: Marty Cagan (Silicon Valley Product Group)

The book has five parts.

Part 1: Lessons from Top Tech Companies

Behind every strong product is a strong product manager who leads the product team to combine technology and design to solve real customer problems in a way that meet the needs of the business. There are three categories of businesses: Startups: getting to product/market fit, Growth stage: Scaling for success and Enterprise: Consistent product innovation. The Author goes on to write about the root causes of failed product efforts which in summary is the Traditional water fall. Unfortunately what we consider agile today at many organisations is still a modified version of the traditional water fall process — Ideas, Biz case, roadmaps, requirements, design, build, test, deploy. This leads to a lot of problems:

This part goes on to talk about some important concepts: Product discovery, Prototypes, Continuous discovery and continuous delivery, Product vision, Product and Product/Market fit. To summarise these concepts, i’m going to just copy this here: “We use prototypes to conduct rapid experiments in product discovery and then in delivery, we build and release, in a c ontinuous delivery process, products in hopes of achieving product/market fit which is a key step on the way to delivering the company’s product vision.

Part 2: The Right People

Product teams must be missionaries and not mercenaries. The reporting structure of product teams should be flat. A typical core product team should consist of a Product manager, a Product designer and 2–10 engineers. It’s generally encouraged that product teams co-locate. Product teams are best if they have the requisite autonomy — this means they are able to solve the problems they are assigned in the best way they see fit. It’s very important that a company is set up around dedicated product teams. Fixing this fixes a lot of other issues for the organisation.

I really love this chapter as it throws a lot of light into the work i have been doing with my product teams: Getting them to have a product vision, dedicated teams, focusing on their market, owning their products, inspiring others et.c. Simply all i have been doing is turning my product teams into missionaries and not mercenaries! Hum…

The author goes on to talk about the key responsibilities and attributes of:

There are no recipes for structuring the right product teams. They are however a few principles that can provide guidance:

Part 3: The Right Product

This part focuses on what the product teams should be working on. The Author argues that typical product roadmaps are the root cause of most waste and failed efforts in the product organisations. This is because product roadmaps typically lead to very poor business results. There are two inconvenient truths that drives home this point:

What then is the alternatives to product roadmaps: Business Objectives. Focus on business outcomes and not outputs from the product roadmaps. How can product teams be more focused on meeting overall business objectives, while giving high integrity commitments when required. Can product road maps be modified so that each item is stated as a business problem to solve rather than the feature or project that may or may not solve it. This alternative as proposed by the author is called the outcome based roadmaps. This helps ensure product teams are focused on solving problems and not building features.

The author goes on to talk about Product Visions and Product Strategy. Simply put, the product vision is a compiling and inspiring narrative that describes the future we are trying to create typically between 2 to 5 years. The product strategy is the sequence of product or product releases we plan to deliver on the path to realising the product vision. Product team empowerment and their ability to work with a good degree of autonomy comes from having a clear product and compelling product vision and the path to achieving that vision is the product strategy. The principles of Product visioning, principles of Product strategy and general product principles were discussed. The concept of OKRs was also discussed further and how product team objectives should be addressed. You can read more here.

Part 4: The Right Process

This was probably the most enlightening part of this book for me. The product discovery process was discussed in detail. Summary: If you want to discover great products, it really is essential you get your ideas in front of real users and customers early and often.

There are ten principles of product discovery:

There are a number of techniques the author advocates including —

i. Discovery framing techniques; This includes the opportunity assessment technique (know the objective, key results, customer problem and target market clearly), the customer letter technique and the start-up canvas technique.

ii. Discovery planning techniques: This includes the story map technique (using low fidelity to high fidelity prototypes) and customer discovery technique.

iii. Discovery ideation techniques: This includes using customer interviews (are my customers who they really are, do they really have the problem i think they have, how do they solve their problem today, what would be required to get them to switch), concierge test technique (similar to hotel concierge; do the actual work your customers are doing), customer misbehaviors (do we watch closely the way our customers use our products differently from how we intend for them to use it? Public APIs for developers is also an amazing tool to use customer misbehavior to drive discovery ideation) and Hack days.

iv. Discovery prototyping techniques: This includes Feasibility prototypes (lightweight codes written by engineers), user prototypes, live data prototypes and hybrid prototypes

v. Discovery testing techniques: this includes testing usability (user researchers using high fidelity prototypes, testing value (test demand using the fake door demand test, qualitative value testing (A/B testing, invite only testing and use the customer discovery technique described above) and qualitative value testings — you can use money, reputation, time or access to demonstrate value), testing feasibility using feasibility prototyping, and testing business viability (managing and getting input all stakeholders — marketing, sales, customer success, finance, legal, security, CEO/COO/GM et.c) and finally,

vi. Transformation technique: This includes the Discovery sprint technique which is a one week time box of product discovery work designed to tackle a substantial problem or risk your product team is facing, the pilot team technique — which helps to ensure the entire organisation is not thrown into an upheaval and considerations are given for laggers.

Now that we are familiar with the alternative to product roadmaps — with is the outcome based roadmaps, how do we wean organisation off the concept of product roadmaps — the easiest way is to begin to include business objectives against each feature release. What problem precisely would that feature solve or what’s the business outcome of this feature release.

How are stakeholders managed? — The product manager has the responsibility to understand the considerations and constraints of the various stakeholders and to bring this knowledge into the product team. Don’t show your stakeholders the product after it has been built. Its a big mistake. Avoid designs by committees, they yield mediocre results.

Part 5: The right culture

The final part of the book focuses on ensuring there is a right and sustainable product culture. A long list of difference between good product teams and bad product teams were stated here. I’ll mention a few and you can read more here;

Top reasons for loss of innovation in companies and loss of velocity were also discussed. Good teams should release no less frequently than every two weeks.

The final chapter focuses on establishing a strong product culture which combines innovation and execution — A culture of innovation means rapid experimentations, open minds, new technology/data analysis, deep understanding of business needs and constraints and customer savvy teams, skillset and staff diversity and a culture of discovery techniques. A culture of execution mean urgency, high integrity commitments, empowerments, accountability, collaboration, results and recognition.

As an organisation you must choose and be deliberate to be strong at both.

And there you have it. Hope you enjoyed reading!

Inspired — How To Create Tech Products Customers Love

from the book authored by Marty Cagan

PART 1: LESSONS FROM TOP TECH COMPANIES

The job of a product manager is to lead the product team to combine technology and design to solve real customer problems in a way that meets the needs of the business.

You need to know two things about each idea:

Two inconvenient truths about product

There is simply no escaping these inconvenient truths no matter how smart you might be. The real difference is how you deal with theses truths.

Best practices

Risk management

In modern teams, risks are tackled up front, rather than at the end and prior to deciding to build anything. These risks include:

Co-creation

Products should be defined and designed collaboratively, rather than sequentially.

Solving problems

Finally, it’s all about solving problems, not implementing features.

Continuous discovery and delivery

We are always working in parallel to both discover the necessary products to be built — which is primarily what the product manager and designer work on every day — while the engineers work to deliver production-quality product. The engineers are also helping daily on discovery (and many of the best innovations come from that participation, so this is not a minor point), and the product manager and designer are also helping daily on delivery (mainly to clarify intended behavior).

In discovery, we are tackling the various risks before we write even one line of production software. 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. Strong teams normally test many product ideas each week — on the order of 10 to 20 or more per week.

While the P in MVP stands for product, an MVP should never be an actual product (where product is defined as something that your developers can release with confidence, that your customers can run their business on, and that you can sell and support). The MVP should be a prototype, not a product.

PART 2: THE RIGHT PEOPLE

Team Scope

It’s more common today that the product is the full customer experience, and each team is responsible for some smaller but meaningful piece of that experience. Sometimes we have each team focus on:

There is never a perfect way to carve up the pie. Realize that when you optimize for one thing, it comes at the expense of something else. So, decide what’s most important to you and go with that.

The Product Managers

4 critical contributions that you need to bring to your team — a deep knowledge of:

The successful product manager must be the very best versions of:

The Designers

Good product designers think about the customer’s journey over time as they interact with the product and with the company as a whole. Depending on the product, the list of touch points could be very long, considering questions as:

How will customers first learn about the product? How will we onboard a first-time user and (perhaps gradually) reveal new functionality? How might users interact at different times during their day? What other things are competing for the user’s attention? How might things be different for a one-month-old customer versus a one-year-old customer? How will we motivate a user to a higher level of commitment to the product? How will we create moments of gratification? How will a user share his experience with others? How will customers receive an offline service? What is the perceived responsiveness of the product?

We need design — not just as a service to make our product beautiful — but to discover the right product. For this to happen, we need to make design a first-class member of the product team, sitting side by side with the product manager, and not a supporting service.

The Engineers

There are typically two types of discussion going on each day.

The morale of the engineers is very much a function of you as the product manager. It is your job to make sure they feel like missionaries and not mercenaries. You do this by involving them deeply in the customer pain you are trying to solve and in the business problems you face. Don’t try to shelter them from this — instead, share these problems and challenges very openly with them.

Not every engineer or even senior engineer wants to participate in discovery activities, and this is fine. What’s not okay is to have a team of engineers in which none of them wants to engage in discovery activities.

Product Marketing

Modern product marketing managers 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.

User Research

Especially with the qualitative learning, research is either

Head of Product

This role is often called a player-coach role because of this dynamic of leading your own team, in addition to being responsible for coaching and developing one to three other PMs. 4 key competencies:

PART 3: THE RIGHT PRODUCT

The alternative to roadmap

Roadmaps have existed for so long because they serve two purposes and these needs don’t go away.

Product vision and strategy

The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there.

The vision is mainly a persuasive piece that might be in the form of a storyboard, a narrative such as a white paper, or a special type of prototype referred to as a vision type. Its primary purpose is to communicate this vision and inspire the teams (and stakeholders, investors, partners — and in many cases prospective customers) to want to help make this vision a reality.

The product strategy is our sequence of products or releases we plan to deliver on the path to realizing the product vision. For most types of businesses, I encourage teams to construct product strategy around a series of product/market fits.

For business-focused companies, you might have each product/market fit focus on a different vertical market (e.g., financial services, manufacturing, automotive.) For consumer-focused companies, we often structure each product/market fit around a different customer or user persona.

Outcome-based roadmaps

They are essentially equivalent to using a business objective-based system such as the OKR system. The compromise is straightforward: the product teams asks for a little time to do product discovery before commitments are made, and then after discovery, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.

Product evangelism

PART 4: THE RIGHT PROCESS

We need to learn fast, yet also release with confidence. It’s understandable that many people might naturally view these two difficult goals as at odds with each other.

The purpose of product discovery is to make sure we have some evidence that when we ask the engineers to build a production — quality product, it won’t be wasted effort. And, this is why we have so many different techniques in product discovery.

Set of core principles

It is our job to make sure the solution we deliver solves the underlying problem. This is probably the most fundamental principle in all of modern product: historically, in the vast majority of innovations in our industry, the customers had no idea that what they now love was even a possibility.

Without the core value, we really have nothing (will customers buy or use it?). As a result, this is generally where we’ll spend most of our discovery time.

This is the reason we push so hard for the product manager, product designer and tech lead to sit physically adjacent to each other

We need to do this before we spend the time and expense to build an actual product, and not after.

Teams competent in modern discovery techniques can generally test on the order of 10–20 iterations per week. As a rule of thumb, an iteration in discovery should be at least an order of magnitude less time and effort than an iteration in delivery.

Discovery Techniques Overview

They include : Framing, Planning, Ideation, Prototyping, Testing (feasibility, usability, value, business viability), Transformation

Framing: Understanding Underlying Issues

a/ Opportunity assessment technique

b/ Customer letter — for larger projects that often have multiple goals and a more complicated desired outcome

Technique from Amazon, the “working backward”: start the effort with a pretend press release. How does it improve the life of our customers? What are the real benefits to them? Include a customer quote as well.

One variation of this technique: rather than communicate the benefits in a press release format, you describe them in the format of a customer letter written from the hypothetical perspective of one of your product’s well-defined user or customer personas. The letter — sent to the CEO from a very happy and impressed customer — explains why he or she is so happy and grateful for the new product or redesign. The customer describes how it has changed/improved her life. The letter also includes an imagined congratulatory response from the CEO to the product team explaining how this has helped the business.

c/ A startup canvas — entirely new product line or new business

NB: unique value proposition, pricing, channels and costs are all real risks which are part of assessing business viability. But the biggest reason that startups and new products fail is the value risk. If you can discover a solution that your customers love, then you can tackle the risks of monetization and scale. However, without that solution, the rest of your work is very likely going to be wasted.The point is that you don’t need to spend your time doing pricing optimization testing, sales tools, marketing programs and cutting costs until and unless you have discovered a truly valuable product.

Conclusion on framing techniques

The most important lesson in our industry is to fall in love with the problem, not the solution. It’s our job in the product organization to tease out the underlying problem and ensure that whatever solution we deliver solves that underlying problem.

A small amount of time up front framing the problem to be solved — and communicating this framing — can make a dramatic difference in the results.

Planning: Identifying The Bigger Challenges & Planning How You’ll Attack This Work

a/ Story Map Technique, introduced by Jeff Patton

The origin of story maps came from frustration with the typical flat backlog of user stories. There’s no context, just a prioritized list of stories. How can the team know how one story fits in with the big picture? What does it mean to even prioritize at that granularity with so little context? And what set of stories constitutes a meaningful milestone or a release?

If you lay out your system this way, you can, at a glance, get the holistic view and consider where to draw the line in terms of different releases and their associated objectives.

To go further, read: User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton

b/ Customer Discovery Programme Technique — for larger efforts

We are discovering and developing a set of reference customers in parallel with discovering and developing the actual product. Remember that this technique is not designed to discover the necessary product — that comes next. Rather it is designed to give you direct access to the target customers where you’ll find the product ideas necessary to generate reference customers.

A reference customer is: a real customer, who is running your product in production, who has paid real money for the product, and most important, who is willing to tell others how much they love your product.

Benefit to the prospective customer: get real input to the solution, and most important get a solution that truly works for them.

Benefit to the product team: get ready access to a set of users and customers that you can go deep with, have agreed to test early versions, and most important they have agreed to buy the product and sere as a public reference if the resulting product works for them.

If you find you are having real trouble recruiting even four or five prospective customers for this effort, this is one of the very first reality checks (aka demand validation) to make sure you’re spending your time on something worthwhile.

Defining product/market fit

One of the most common technique (mostly relevant for consumer products and services) is the Sean Ellis test: if more than 40 percent of the users would be “very disappointed” if they could no longer use the product, then there is a good chance you’re at product/market fit.

For products for businesses, the discovery program will give you a very practical and effective definition of product/market fit.

Ideation: To Provide The Product Team With a Wealth of Promising Solutions Aimed at the Problems We’re Focused On Now

a/ Customer interviews

Here’s what we are trying to understand:

Frequency: a bare minimum would be 2 to 3 hours of customer interviews, per week

Attendees: ideally the product manager, the product designer and one of the engineers

b/ Concierge Test Technique

This test requires going out to the actual users and customers and asking them to show you how they work so that you can learn how to do their job, and so that you can work on providing them a much better solution.

This is similar, but not the same, as spending some time with your customer service or customer success staff. That is also valuable and often a good source of product ideas as well, but that is helping customers once they call with a problem.

c/ The Power of Customer Misbehavior

If you find your customers using your product in ways you didn’t predict, this is potentially very valuable information. Dig in a little and learn what problem they are trying to solve and why they believe your product might provide the right foundation. Do this enough and you’ll soon see patterns and potentially some very big product opportunities.

The goal is for the self-organizing groups to explore their ideas and create some form of prototype that can be evaluated, and if appropriate, tested on actual users.

Prototyping: Our Go-to Tool For Product Discovery

“ Plan to throw one away; you will, anyhow. “

a/ Feasibility prototype technique (for the engineers)

The idea is to write just enough code to mitigate the feasibility risk. This typically represents just a small percentage of the work for the eventual shippable product (usually just a day or two of time).

b/ User prototype technique, from low-fidelity (wireframes) to high-fidelity

NB: The big limitation of a user prototype is that it’s not good for proving anything — like whether or not your product will sell ie validating value.

c/ Live-data prototype technique, to collect actual data so we can prove something

The key is to is to be able to send some limited amount of traffic, and to collect analytics on how this live-data prototype is being used. Actual users will use the live-data prototype for real work, and this will generate real data (analytics) that we can compare to our current product or to our expectations to see if this new approach performs better. Examples: game dynamics, search result relevance, social features, product funnel work.

Two big limitations to keep in mind:

d/ Hybrid prototype technique

Great examples of the “build things that don’t scale” philosophy of product discovery. Admittedly, it’s mainly qualitative learning, but that’s often where our biggest insights come from anyway.

One example is a Wizard of Oz prototype: it combines the front-end user experience of a high-fidelity user prototype but with an actual person behind the scenes performing manually what would ultimately be handled by automation. It is absolutely not scalable but the benefit from our perspective is that we can create this very quickly and easily and from the user’s perspective it looks and behaves like a real product.

Testing: Trying to Separate Quickly the Good Ideas from the Bad

We usually assess usability and value with the same users at the same time.

a/ Testing Usability: Designed for the Designers to Address Areas Where They Identify Concerns

We likely will need to address usability before the user of customer can even recognize the value.

b/ Testing Value: To Ensure The Customers Will Choose To Use Or Buy Our Product

This is often the toughest — and most important — question to answer and if the value is not there, not much else matters.

F ake door demand test : we put the button or menu item into the user experience exactly where we believe it should be. But when the user clicks that button, it takes her to a special page that explains that you are studying the possibility of adding this new feature and you are seeking customers to talk to about this. The page also provides a way for the user to volunteer (email or phone number).

L anding page demand test: if the user clicks the call to action, rather than signing up, the user sees a page that explains that you are studying the possibility of adding this new offering and you’d like to talk with them.

Testing Value Qualitatively

Qualitative testing is about understanding the why — fast learning and big insights. It is probably the single most important discovery activity for product teams. Do it at least two or three times every single week.

Testing Value Quantitatively

Quantitative testing is about collecting evidence, with live-data prototypes.

5 main uses of analytics in strong product teams

Remarkably, too many product teams either aren’t instrumenting their product to collect analytics or they do it as such a minor level that they don’t know if and how their product is being used

c/ Testing Feasibility: Designed for the Engineers to Address Areas Where They Identify Concerns

Holding a weekly planning meeting where you throw a bunch of ideas at the engineers — and demand they give you some sort of estimate — is almost certain to go badly.

If however then engineers have been following along as the team has tried out these ideas with customers (using prototypes) and seen what the issues are and how people feel about these ideas, the engineers have probably already been considering the issues for some time. You need to give the engineers time to investigate and consider it.

The question isn’t “Can you do this?”. Rather you are asking them to look into it and answer the question “What’s the best way to do this and how long would it take?”

d/ Testing Business Viability: Costs, Finance, Business Development, Marketing, Legal, Sales, Ethics

We’ll often address these business risks last because we don’t want to stir up the organization unless we’re confident it’s worthwhile.

The last thing you want to have happen is that your team moves forward and takes the time to commercialize the solution and deliver a shippable product, only to find out that you can’t ship because you are violating one of these constraints.

User Test vs Product Demo vs Walkthrough

Transformation: Improving The Way We Work As a Team

a/ Discovery/Design Sprint Technique

A discovery sprint (or design sprint) is a one-week time box of product discovery work, designed to tackle a substantial problem or risk your product team is facing, cf the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, by Jake Knapp, John Zeratsky, Braden Kowitz.

It starts with framing the problem by mapping the problem space, picking the problem to be solved and the target customer, and then progresses into pursuing several different approaches to the solution. The team next narrows down and fleshes out the different potential solutions, then creates a high-fidelity user prototype — finally putting it in front of actual target users.

b/ Pilot Team Technique

The technology adoption curve also applied to our own organization. Some people love change, some want to see someone else use it successfully first, some need more time to digest changes, and a few hate change and will only change if they’re forced to do it.

Pilot teams allow the roll out of change to a limited part of the organization before implementing it more broadly. You’re looking to compare the team’s effectiveness in delivering business outcomes.

c/ Weaning an Organization Off Roadmaps

The goal is that over time, the organization moves its focus from specific features launching on specific dates to business results.

Teams work on the prioritized business objectives determined by the leaders; we share our key results transparently; and we commit to high-integrity commitments when critical delivery dates are needed.

Managing Stakeholders

The product manager has the responsibility to understand the considerations and constraints of the various stakeholders, and to bring this knowledge into the product team.

Success in terms of stakeholder management means that your stakeholders respect you and your contribution. They trust that you understand their concerns and will ensure solutions work well for them too. They trust that you will keep them informed of important decisions or changes. And, most of all, they give you the room to come up with the best solutions possible, even when those solutions end up being quite different from what they might have originally envisioned.

Key technique: one-on-ones (weekly lunch or coffee) ; commit to previewing your solutions during discovery with the key stakeholders before you put this work on the product backlog

Communicating Product Learnings

A good technique is for the head of product at a company all-hands or similar meeting every week or two, to take 15 to 30 min to highlight what has been learned in product discovery across the various product teams.

One cultural benefit of the product organization being transparent and generous in what they learn and how they work is to help the broader organization understand that the product organization is not there to “serve the business” but rather to solve problems for our customers in ways that work for our business.

PART 5: THE RIGHT CULTURE

It’s much more about culture than it is about process — or anything else.

A strong product culture means that the team understands the importance of continuous and rapid testing and learning. They understand that they need to make mistakes in order to learn, but they need to make them quickly and mitigate the risks. They understand the need for continuous innovation. They know that great products are the result of true collaboration. They respect and value their designers and engineers. They understand the power of a motivated product team.

In an IT-mindset organization, the product teams exist to serve the needs of the business. In contrast, in a product-mindset organization, the product teams exist to serve the company’s customers in ways that meet the needs of the business. The resulting differences between these mindsets are many and profound.

Top Reasons For Loss of Innovation

Top Reasons For Loss of Velocity

Establishing a Strong Product Culture

We can think of product culture along two dimensions:

Only a few companies are strong at both innovation and execution.

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:

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.

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.

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.

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.

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:

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:

Tips and strategies for defining the 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)!

Марти Каган: Вдохновленные. Все, что нужно знать продакт-менеджеру

Inspired: how to create tech products customers love

Аннотация к книге «Вдохновленные. Все, что нужно знать продакт-менеджеру»

О книге
Руководство по продуктовому управлению для продакт-менеджеров.

В этой книге представлены основные принципы проектирования и запуска прорывных продуктов, описаны роли членов команды и процесс создания маркетинговой стратегии и продаж.

Инвесторы, владельцы компаний, менеджеры продуктов, маркетологи и продавцы, программисты и дизайнеры обогатятся интересными идеями и инструментами, которые смогут использовать для создания прорывных продуктов и в реализации стратегии бизнеса.

Изучив главы, посвященные созданию эффективной команды.

О книге
Руководство по продуктовому управлению для продакт-менеджеров.

В этой книге представлены основные принципы проектирования и запуска прорывных продуктов, описаны роли членов команды и процесс создания маркетинговой стратегии и продаж.

Инвесторы, владельцы компаний, менеджеры продуктов, маркетологи и продавцы, программисты и дизайнеры обогатятся интересными идеями и инструментами, которые смогут использовать для создания прорывных продуктов и в реализации стратегии бизнеса.

Изучив главы, посвященные созданию эффективной команды, методологии прорывных продуктов, внедрению сильной культуры управления продуктами, вы сможете сразу применить эти знания в своей компании.

Первое издание этой книги, вышедшее десять лет назад, стало популярным справочником у менеджеров по технологическим продуктам, его можно найти практически в каждой успешной компании из сферы высоких технологий. Второе, полностью обновленное издание призвано стать ценным источником знаний для менеджеров по высокотехнологичным продуктам.

От автора
Я писал первое издание, когда методология гибкой разработки продуктов Agile еще не вошла в практику продуктовых компаний прочно и надежно, как теперь, а концепции «Развитие клиента» (Customer Development) и «Бережливый стартап» (Lean Startup) не были еще популярны. Сегодня большинство команд используют их уже не первый год и больше интересуются выходящим за рамки подходом Lean и Agile, на чем я и сосредоточился в этом издании.

Основную структуру книги я сохранил, но методы, которые тут описываются, за последнее десятилетие существенно развились и улучшились.

В этом издании я решил сосредоточиться на работе этих менеджеров. Если вы работаете менеджером по продукту в технологической компании или только мечтаете стать одними из них, очень надеюсь, что данная книга будет для вас полезным практическим ресурсом.

Работа менеджера по высокотехнологическим продуктам сегодня считается одной из самых желанных в нашей отрасли; а еще это главный испытательный полигон и основной источник руководителей стартапов. Так что, если и у вас есть желание преуспеть на этом поприще, и вы готовы приложить необходимые усилия, буду счастлив помочь вам это сделать.

Для кого книга
Для инвесторов и владельцев, менеджеров продуктов и стартаперов, маркетологов и продажников, разработчиков программного обеспечения.

Для всех, чья работа связана с созданием продуктов.