Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group)

by Marty Cagan

the need to know two things about each idea: (1) How much money or value will it make? and (2) How much money or time will it cost?

We can't know how much money we'll make because that depends entirely on how good the solution turns out to be.

The first truth is that at least half of our ideas are just not going to work.

the second inconvenient truth is that even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it delivers the necessary business value.

biggest missed opportunity in this model is the fact that engineering gets brought in way too late.

Not only is engineering brought in way too late, but the principles and key benefits of Agile enter the picture far too late. Teams using Agile in this way are getting maybe 20 percent of the actual value and potential of Agile methods. What you're really seeing is Agile for delivery, but the rest of the organization and context is anything but Agile.

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.

I meet countless teams that claim to be following Lean principles; yet, they work for months on what they call an MVP,

Risks are tackled up front, rather than at the end.

Products are defined and designed collaboratively, rather than sequentially.

Finally, it's all about solving problems, not implementing features. Conventional product roadmaps are all about output. Strong teams know it's not only about implementing a solution. They must ensure that solution solves the underlying problem. It's about business results.

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.

Will the user buy this (or choose to use it)?

Can the user figure out how to use this?

Can our engineers bu...

Can our stakeholders sup...

So, we use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company's product vision.

think the root of the issue is that 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.

“We need teams of missionaries, not teams of mercenaries.”

To be absolutely clear, the product manager is not the boss of anyone on the product team.

In any case, what's critically important is alignment between product management and engineering. This is why the head of product and the head of engineering normally get together to define the size and scope of the teams.

It also means we try to minimize dependencies between teams. Notice that I said “minimize” and not “eliminate.” At scale, it's just not possible to eliminate all dependencies, but we can work hard to continuously minimize them.

First, collaboration is built on relationships, and product teams—especially co‐located teams—are designed to nurture these relationships.

Second, to innovate you need expertise, and the durable nature of product teams lets people go deep enough to gain that expertise.

Third, instead of just building what others determine might be valuable, in the product team model the full team understands—needs to understand—the business objectives and context. And most important, the full...

When a product succeeds, it's because everyone on the team did what they needed to do. But when a product fails, it's the product manager's fault.

This requires both qualitative learning (to understand why our users and customers behave the way they do), and quantitative learning (to understand what they are doing), which is what we'll talk about next.

the product manager must also be an undisputed expert on your actual product.

the analysis of the data and understanding you get of your customer is not something you can delegate.

Succeeding in the job of product means convincing each key stakeholder that you understand their constraints and that you are committed to only delivering solutions that you believe are consistent with those constraints.

deep knowledge of the market and industry in which you're competing. This includes not only your competitors but also key trends in technology, customer behaviors and expectations, following the relevant industry analysts, and understanding the role of social media for your market and customers.

By smart,

I especially mean intellectually curious, quickly learning and applying new technologies to solve problems for customers, to reach new audiences, or to enable new business models.

By creative, I mean thinking outside the normal product box of features to s...

By persistent, I mean pushing companies way beyond their comfort zone with compelling evidence, constant communication, and building bridges across fun...

product owner is the name of the role on an Agile team for the person responsible for the product backlog.

To summarize, product owner responsibilities are a small subset of product management responsibilities, but it's critical that the product manager covers both.

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

In the first type of discussion, you're soliciting their ideas and input for the items you're working on in discovery.

In the second type of discussion, they're asking you clarifying questions on the items they're workin...

the morale of the engineers is very much a function of you as the product manager.

In the best tech product companies, product marketing plays an essential role in discovery, delivery, and, ultimately, go‐to‐market, which is why they are important members of the product team.

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.

Some people like to think of holistic view as connecting the dots between the teams.

a dedicated principal product manager is able to focus on the product itself and is readily accessible as a critical resource to all the product managers, product designers, engineers, and test automation staff.

Specifically, you are looking for someone who is proved to be strong in four key competencies: (1) team development, (2) product vision, (3) execution, and (4) product culture.

The hallmark of a great CTO is a commitment to continually strive for technology as a strategic enabler for the business and the products. Removing technology as a barrier, as well as broadening the art of the possible for business and product leaders, is the overarching objective.

there are six major responsibilities of a CTO.