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

by Marty Cagan

Delivery managers are a special type of project manager whose mission is all about removing obstacles—also known as impediments—for the team.

These delivery managers are typically also the Scrum Masters for the team (if they have that role). They are all about helping the team to get stuff live faster, not by cracking the whip but by removing obstacles that get in the way.

I know that many people crave a recipe for structuring product teams, but I always explain to them that there is no recipe. Instead, there are some critical core principles, and the key is to understand those principles and then weigh the options for your particular circumstances.

Alignment with investment strategy

Minimize Dependencies

Ownership and Autonomy

Maximize Leverage

Product Vision and Strategy

Team Size

Alignment with Architecture

Alignment with User or Customer

Alignment with Business

Structure Is a Moving Target

C team—this is a junior team that may not even know what they don't know yet. These teams can unintentionally cause substantial issues without significant coaching.

One frequent problem is to try to standardize on a common foundation prematurely. The foundation isn't yet ready for prime time, in the sense of the leverage it is designed to provide. If you push too hard on leverage before the foundation is ready, you can truly hurt the teams that are counting on this foundation. You're building a house of cards that may collapse at any time.

Assuming the foundation is solid, there's likely more risk in a team not leveraging that foundation. This might be fine for some areas, but with products or initiatives that are business critical, it becomes a question of which battles to pick.

If you find that teams are consistently making poor decisions in this regard, you may need to consider the experience level of the people on the team, but most likely, the teams are missing the full business context.

The critical context is comprised of two things: The overall product vision The specific business objectives assigned to each team

product roadmap as a prioritized list of features and projects your team has been asked to work on.

the two inconvenient truths about product.

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

the second inconvenient truth is that, even with the ideas that do prove to be valuable, usable, feasible, and viable, it typically takes several iterations to get the execution of this idea to the point where it delivers the expected business value that management was hoping for. This is often referred to as time to money.

product discovery as the most important core competency of a product organization.

no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment. And that's the crux of the problem, because now you're committed to building and delivering this thing, even when it doesn't solve the underlying problem.

roadmaps have existed for so long because they serve two purposes, and these needs don't go away:

The first purpose is because the management of the company wants to make sure that teams are working on the highest‐business‐value items first.

The second purpose is because—since they're trying to run a business—there are cases where they need to make date‐based commitments, and the roadmap is where they see and track those commitments (even though ...

The feature must solve the business problem

outcome‐based roadmaps.

there are always some real commitments that need to be made in order to effectively run a company.

The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know whether we can deliver on this obligation, and even more important, whether what we deliver will solve the problem for the customer.

We ask the executives and our other stakeholders to give us a little time in product discovery to investigate the necessary solution. We need the time to validate that solution with customers to ensure it has the necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business.

Once we have come up with a solution that works for our business, we now can make an informed and high‐integrity commitment about when we can deliver and what business results we can expect.

product vision describes the future we are trying to create, typically somewhere between two and five years out.

When done well, the product vision is one of our most effective recruiting tools, and it serves to motivate the people on your teams to come to work every day. Strong technology people are drawn to an inspiring vision—they want to work on something meaningful.

The product strategy is our sequence of products or releases we plan to deliver on the path to realizing the product vision.

And, just to be clear—the idea is not that every product team has its own product vision. That would miss the point. The idea is that our organization has a product vision, and all the product teams in that organization are helping to contribute to making that vision a reality.

The result of the program is a set of reference applications rather than reference customers.

If you find your customers using your product in ways you didn't predict, this is potentially very valuable information.

however, in many cases, the prototype goes on to provide a second benefit, which is to communicate to the engineers and the broader organization what needs to be built. This is often referred to as prototype as spec.

If users knew what they really wanted, software would be a lot easier to create. So, watch what they do more than what they say.

There are three important cases you're looking for:

(1) the user got through the task with no problem at all and no help;

(2) the user struggled and moaned a bit, but he eventual...

(3) he got so frustrated ...

If the value is there, we can fix everything else. If it's not, how good our usability, reliability, or performance is doesn't matter.

One practical test of whether a person is considered a stakeholder is whether or not they have veto power, or can otherwise prevent your work from launching.