Inspired

While almost everyone today claims to be Agile, what I've just described is very much a waterfall process.

In any case, one of the most critical lessons in product is knowing what we can't know, and we just can't know at this stage how much money we'll make.

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. We call that time to money.

Maybe the biggest missed opportunity in this model is the fact that engineering gets brought in way too late. We say if you're just using your engineers to code, you're only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process.

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.

The key principle in Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test, and deploy a feature or product only to find out it is not what was needed.

In strong teams, product, design, and engineering work side by side, in a give‐and‐take way, to come up with technology‐powered solutions that our customers love and that work for our business.

To set your expectations, strong teams normally test many product ideas each week—on the order of 10 to 20 or more per

“We need teams of missionaries, not teams of mercenaries.” Mercenaries build whatever they're told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.

there is a special dynamic that occurs when the team sits together, eats lunch together, and builds personal relationships with one another.

All other things being equal, a co‐located team is going to substantially outperform a dispersed team. That's just the way it is.

While things do come up, and people change jobs and teams, once the members of a team get to know one another, and learn how to work well together, it's honestly a beautiful and powerful thing, and we try hard not to mess up that dynamic.

They are able to try to solve the problems they are assigned in the best way they see fit.

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.

companies understand the value in making products that are sticky, and this means that it can be difficult for prospective customers to move from your competitor to you. This is one of the big reasons why it is not enough to have feature parity with a competitor. Rather, you need to be substantially better to motivate a user or customer to switch.

Rather than being measured on the output of their design work, the product designer is measured on the success of the product.

UX is any way that customers and end users realize the value provided by your product.

We need design—not just as a service to make our product beautiful—but to discover the right product.

Fight your temptation to provide your designer with your own design ideas. Give your designer as much room as possible to solve the design challenges him or herself.

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.

It's remarkable to me how many companies I find in which the teams are simply reflections of their ongoing investments. They have certain teams because they have always had those teams. But, of course, we need to be investing in our future as well.

big goal is to minimize dependencies. This helps teams move faster and feel much more autonomous. While we can never entirely eliminate dependencies, we can work to reduce and minimize them.

Architectures drive technologies, which drive skill sets. While we'd love for every team to be a full stack team that can work on any layer of the architecture, in practice that's often not an option.

I will also confess here that, while I love the core notion of autonomous, empowered teams, I am also a big fan of investing in a high‐leverage foundation.

As is so often the case with product, things boil down to a tradeoff—in this case between the team's autonomy and leverage of the foundation.

The further on the spectrum that the company pushes toward leverage, the more this can be perceived by the teams as chipping away at their level of autonomy.

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.

that's not bad enough, 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.

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.

If we can prototype and test ideas with users, customers, engineers, and business stakeholders in hours and days—rather than in weeks and months—it changes the dynamics, and most important, the results.

Sometimes, we do need to commit to a delivery on a date. We try to minimize those cases, but there are always some. But we need to make what is called a high‐integrity commitment.

the team is not off the hook just by delivering a requested feature or project. The feature must solve the business problem (as measured by the key results); otherwise, the team needs to

the team is not off the hook just by delivering a requested feature or project. The feature must solve the business problem (as measured by the key results); otherwise, the team needs to try a different approach to the solution.

In a custom software environment, you might just be able to iterate until the business is satisfied with the software (or they just give up on it). In a product company, this won't fly.

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.

In the continuous discovery and delivery model, the discovery work is all about answering these questions before we spend the time and money to build production‐quality products.

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 vision describes the future we are trying to create, typically somewhere between two and five years out. For hardware or device‐centric companies, it's usually five to 10 years out.

Mission statements are useful, but they don't say anything about how we plan on accomplishing that. That's what the product vision is for.

Note also that the vision is not in any sense a spec. It's 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 visiontype.

There's no single approach to product strategy that is ideal for everyone, and you can never know how things might have gone if you sequenced your product work differently. I tell teams that the most important benefit is just that you decided to focus your product work on a single target market at a time.

I tell teams that the most important benefit is just that you decided to focus your product work on a single target market at a time.

Ideas that come up that pertain to other types of customers or markets are saved for future consideration.

Most important, the product vision should be inspiring, and the product strategy should be focused.

Fall in love with the problem, not with the solution. I hope you've heard this before, as it's been said many times, in many ways, by many people. But it's very true and something a great many product people struggle with.

Don't be afraid to think big with vision. Too often I see product visions that are not nearly ambitious enough, the kind of thing we can pull off in six months to a year or so, and not substantial enough to inspire anyone.

Don't be afraid to disrupt yourselves because, if you don't, someone else will. So many companies focus their efforts on protecting what they have rather than constantly creating new value for their customers.

Determine and embrace relevant and meaningful trends. Too many companies ignore important trends for far too long. It is not very hard to identify the important trends. What's hard is to help the organization understand how those trends can be leveraged by your products to solve customer problems in new and better ways.

The product vision needs to inspire. Remember that we need product teams of missionaries, not mercenaries. More than anything else, it is the product vision that will inspire missionary‐like passion in the organization. Create something you can get excited about. You can make any product vision meaningful if you focus on how you genuinely help your users and customers.

Skate to where the puck is heading, not to where it was. An important element to product vision is identifying the things that are changing—as well as the things that likely won't be changing—in the time frame of the product vision. Some product visions are wildly optimistic and unrealistic about how fast things will change, and others are far too conservative. This is usually the most difficult aspect of a good product vision.

Be stubborn on vision but flexible on the details. This Jeff Bezos line is very important. So many teams give up on their product vision far too soon. This is usually called a vision pivot, but mostly it's a sign of a weak product organization. It is never easy, so prepare yourself for that. But, also be careful you don't get attached to details. It is very possible that you may have to adjust course to reach your desired destination. That's called a discovery pivot, and there's nothing wrong with that.

Realize that any product vision is a leap of faith. If you could truly validate a vision, then your vision prob ably isn't ambitious enough. It will take several years to know. So, make sure what you're working on is meaningful, and recruit people to the product teams who also feel passionate about this problem and then be willing to work for several years to realize the vision.

Evangelize continuously and relentlessly. There is no such thing as over‐communicating when it comes to explaining and selling the vision. Especially in larger organizations, there is simply no escaping the need for near‐constant evangelization. You'll find that people in all corners of the company will at random times get nervous or scared about something they see or hear. Quickly reassure them before their fear infects others.

Focus on one target market or persona at a time. Don't try to please everyone in a single release. Focus on one new target market, or one new target persona, for each release. You'll find that the product will still likely be useful to others, but at least it will be loved by some, and that's key.

Product strategy needs to be aligned with business strategy. The vision is meant to inspire the organization, but the organization ultimately is there to come up with solutions that deliver on the business strategy. So, for example, if that business strategy involves a change in monetization strategy or business model, then the product strategy needs to be aligned with this.

Obsess over customers, not over competitors.

Communicate the strategy across the organization. This is part of evangelizing the vision. It's important that all key business partners in the company know the customers we're focused on now and which are planned for later. Stay especially closely synced with sales, marketing, finance, and service.

Where the product vision describes the future you want to create, and the product strategy describes your path to achieving that vision, the product principles speak to the nature of the products you want to create.

“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”

“When performance is measured by results.” The idea here is that you can release all the features you want, but if it doesn't solve the underlying business problem, you haven't really solved anything.

The first principle is fundamentally about how to empower and motivate people to get them to do their best work, and the second is about how to meaningfully measure progress.

Agree as an organization on how you will be evaluating or scoring your key results.

It's amazing how far you can get by focusing on meeting the needs of some early customers.

Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it.

To quote Marc Andreessen, “The most important thing is to know what you can't know,” and we can't know in advance which of our ideas will work with customers and which won't. So, we approach discovery with the mindset that many, if not most, of our ideas won't work out.