Inspired

by Marty Cagan
Aug 24, 2026 · 5.0 · 26 min read

Part I: Lessons from Top Tech Companies

We need to discover the product to be built, and we need to deliver that product to market.
Product Discovery - 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. Specifically, this means getting answers to four critical questions:
1. Will the user buy this (or choose to use it)?
2. Can the user figure out how to use this?
3. Can our engineers build this?
4. Can our stakeholders support this?
I 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.

Part II: The Right People

We need teams of missionaries, not teams of mercenaries.
The honest truth is that the product manager needs to be among the strongest talent in the company. If the product manager doesn’t have the technology sophistication, doesn’t have the business savvy, doesn’t have the credibility with the key executives, doesn’t have the deep customer knowledge, doesn’t have the passion for the product, or doesn’t have the respect of their product team, then it’s a sure recipe for failure.
At one level, the responsibilities of the product manager are pretty straightforward. He or she is responsible for evaluating opportunities and determining what gets built and delivered to customers.
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.
There are four key responsibilities of a strong product manager;
1. Deep Knowledge of the Customer
  - To make this explicit, you need to become an acknowledged expert on the customer: their issues, pains, desires, how they think—and for business products, how they work, and how they decide to buy.
2. Deep Knowledge of the Data
  - A big part of knowing your customer is understanding what they’re doing with your product. Most product managers start their day with half an hour or so in the analytics tools, understanding what’s been happening in the past 24 hours. They’re looking at sales analytics and usage analytics. They’re looking at the results of A/ B tests.
3. Deep Knowledge of Your Business
  - The third critical contribution—and the one that is often considered the most difficult by many product managers—is a deep understanding of your business and how it works, and the role your product plays in your business. This is tougher than it sounds.
  - Successful products are not only loved by your customers, but they work for your business.
  - This means knowing who your various stakeholders are and especially learning the constraints they operate under. There are usually key stakeholders representing general management, sales, marketing, finance, legal, business development, and customer service. Your CEO is usually a very important stakeholder as well.
  - 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.
4. Deep Knowledge of Your Market and Industry
  - The fourth critical contribution is 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.
Industry is constantly moving, and we must create products for where the market will be tomorrow, not where it was yesterday.
The successful product manager must be the very best versions of smart, creative, and persistent.
- By smart, I don’t just mean raw IQ. 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 solve business problems.
- By persistent, I mean pushing companies way beyond their comfort zone with compelling evidence, constant communication, and building bridges across functions in the face of stubborn resistance.
Start by becoming an expert in your users and customers. Share very openly what you learn, both the good and the bad. Become your team’s and your company’s go‐ to person for understanding anything about your customer—quantitative and qualitative.
Work to establish a strong relationship with your key stakeholders and business partners. Convince them of two things: (1) You understand the constraints they operate under. (2) You will only bring to them solutions that you believe will work within those constraints.
Become an undisputed expert on your product and your industry. Again, share your knowledge openly and generously.
Finally, work very hard to build and nurture the strong collaborative relationship with your product team.
The big points I hope you take away from these examples are:
1. Product management is absolutely distinct from the other disciplines. It’s clearly different than the contribution of the designers, and it’s also clearly not a project manager. There is some amount of project management inevitably involved, just as there is for all leadership positions. But to characterize this as a project manager is to completely miss the essence of the role. The role I would argue the product manager is most similar to is the role of the CEO. But with the obvious difference that, unlike the CEO, the product manager is not the boss of anyone.
2. Like a CEO, the product manager must deeply understand all aspects of the business. The product manager must ensure a business outcome, not just ensure a product gets defined. This requires a good understanding of the many interrelated parts and constraints of the business—financial, marketing, sales, legal, partnership, service, the customer environment, the technical capabilities, the user’s experience—and figure out a solution that works for the customers as well as for the business. But don’t think this means an MBA is required—not one of the impressive product managers I feature in this book has an MBA—or that you need to have all these skills yourself. You must simply have a broad understanding of how a product can affect a business and work with people from your team and across your company to cover everything that’s important.
3. In every one of these examples, the winning solutions didn’t come from users, customers, or sales. Rather, great products require an intense collaboration with design and engineering to solve real problems for your users and customers, in ways that meet the needs of your business.
4. True leadership is a big part of what separates the great product people from the merely good ones.

The Product Designer

Modern product designers are responsible for the following:
1. Product Discovery
2. Holistic User Experience Design
3. Prototyping
4. User Testing
5. Interaction and Visual Design
Rather than being measured on the output of their design work, the product designer is measured on the success of the product.
Good product designers use prototypes as their primary canvas for communicating ideas, both internally and externally. They are generally comfortable with many different prototyping tools and are able to apply the correct one for the task at hand.
We need design—not just as a service to make our product beautiful—but to discover the right product.
Once you get a designer dedicated to your product team, here are five keys to a successful and healthy relationship with your designer:
1. Do whatever you need to do to have your designer sit next to you.
2. Include your designer from the very inception of every idea.
3. Include your designer in as many customer and user interactions as possible.
4. Learn about the users and customers together.
5. 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.
6. Encourage your designer to iterate early and often. The best way you can encourage this is to not get all nitpicky about design details with the very early iterations. More generally, encourage your designer to feel free not to just iterate on the particular design approach but to explore alternative solutions to the problem.

The Engineers

There’s probably no more important relationship for a successful product manager than the one with your engineers.
If your relationship is strong, with mutual and sincere respect both ways, then the product manager job is great. If your relationship is not strong, your days as product manager will be brutal (and probably numbered). Therefore, this is a relationship worth taking very seriously and doing everything you can to nurture.
The single most important responsibility of any VP product is to develop a strong team of product managers and designers. This means making recruiting, training, and ongoing coaching the top priority.

Principles of Structuring Product Teams

Principles of Structuring Product Teams
1. Alignment with investment strategy
2. Minimize Dependencies
3. Ownership and Autonomy
4. Maximize Leverage
5. Product Vision and Strategy
6. Team Size
7. Alignment with Architecture
8. Alignment with User or Customer
9. Alignment with Business
10. Structure Is a Moving Target
The minimum size for a product team is usually two engineers and a product manager, and if the team is responsible for user‐ facing technology, then a product designer is needed, too.

Part III: The Right Product

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

The Problems with Product Roadmaps

The issue is that anytime you put a list of ideas on a document entitled “roadmap,” no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment.
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.

The Alternative to Roadmaps

The idea behind business objectives is simple enough: tell the team what you need them to accomplish and how the results will be measured, and let the team figure out the best way to solve the problems.
It is management’s responsibility to provide each product team with the specific business objectives they need to tackle.
There are a few product teams out there that have modified their product roadmaps 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. These are called outcome‐based roadmaps.
In general, when I see these, I’m pretty happy because I know the product teams are stepping up to solve business problems rather than build features. Outcome‐ based roadmaps are essentially equivalent to using a business objective–based system such as the OKR system. It’s the format that’s different more than the content.

Product Vision and Product Strategy

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.
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.
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.
For a product team to be empowered and act with any meaningful degree of autonomy, the team must have a deep understanding of the broader context. This starts with a clear and compelling product vision, and the path to achieving that vision is the product strategy.
The more product teams you have, the more essential it is to have this unifying vision and strategy for each team to be able to make good choices.
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.
Most important, the product vision should be inspiring, and the product strategy should be focused.

Principles of Product Vision

Start with why.
Fall in love with the problem, not with the solution.
Don’t be afraid to think big with vision.
Don’t be afraid to disrupt yourselves because, if you don’t, someone else will.
The product vision needs to inspire.
Determine and embrace relevant and meaningful trends.
Skate to where the puck is heading, not to where it was.
Be stubborn on vision but flexible on the details.
Realize that any product vision is a leap of faith.
Evangelize continuously and relentlessly.

Principles of Product Strategy

Principles of Product Strategy
1. Focus on one target market or persona at a time.
2. Product strategy needs to be aligned with business strategy.
3. Product strategy needs to be aligned with sales and go‐ to‐ market strategy.
4. Obsess over customers, not over competitors.
5. Communicate the strategy across the organization.
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.
Too many companies completely forget about their product strategy once they encounter a serious competitor. They panic and then find themselves chasing their competitor’s actions and no longer focusing on their customers. We can’t ignore the market, but remember that customers rarely leave us for our competitors. They leave us because we stop taking care of them.

Product Principles

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.
Product principles are not a list of features, and they are not tied to any one product release. The principles are aligned with the product vision for an entire product line.

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

The OKR Technique

Objectives should be qualitative; key results need to be quantitative/ measurable.
Key results should be a measure of business results, not output or tasks.
Don’t let personal objectives or functional team objectives dilute or confuse the focus.
Find a good cadence for your organization (typically, annually for an organization’s objectives and quarterly for a team’s objectives).
Keep the number of objectives and key results for the organization and for each team small
It’s critical that every product team track their active progress against their objectives
The objectives do not need to cover every little thing the team does, but they should cover what the team needs to accomplish.
It’s important that, one way or another, teams feel accountable to achieving their objectives.
Agree as an organization on how you will be evaluating or scoring your key results.
Establish very clear and consistent ways to indicate when a key result is in reality a high‐ integrity commitment (described earlier) rather than a normal objective.
Be very transparent (across the product and technology organization) on what objectives each product team is working on and their current progress.
Senior management (CEO and executive team) is responsible for the organization’s objectives and key results. The heads of product and technology are responsible for the product team objectives (and ensuring they deliver on the organization’s objectives). The individual product teams are responsible for proposing the key results for each objective they’ve been assigned.

Product Team Objectives

If you deploy OKRs for your product organization, the key is to focus your OKRs at the product team level.

Product Evangelism

Here are my top‐ 10 pieces of advice for product managers to sell the dream:
1. Use a prototype.
2. Share the pain.
3. Share the vision.
4. Share learnings generously.
5. Share credit generously.
6. Learn how to give a great demo.
7. Do your homework.
8. Be genuinely excited.
9. Learn to show some enthusiasm.
10. Spend time with your team.

Part IV: The Right Process

We need to learn fast, yet also release with confidence.

Principles of Product Discovery

The purpose of product discovery is to address these critical risks:
1. Will the customer buy this, or choose to use it? (Value risk)
2. Can the user figure out how to use it? (Usability risk)
3. Can we build it? (Feasibility risk)
4. Does this solution work for our business? (Business viability risk)
When it comes to how we do product discovery, there are a set of core principles that drive how we work. If you understand these, you will understand not only how to work well today but also how to easily incorporate new techniques as they emerge in the future.
1. We know we can’t count on our customers (or our executives or stakeholders) to tell us what to build.
2. The most important thing is to establish compelling value. It’s all hard, but the hardest part of all is creating the necessary value so that customers ultimately choose to buy or to use.
3. As hard and important as the engineering is, coming up with a good user experience is usually even harder, and more critical to success.
4. Functionality, design, and technology are inherently intertwined.
5. We expect that many of our ideas won’t work out, and the ones that do will require several iterations.
6. We must validate our ideas on real users and customers.
7. Our goal in discovery is to validate our ideas the fastest, cheapest way possible.
8. We need to validate the feasibility of our ideas during discovery, not after.
9. We need to validate the business viability of our ideas during discovery, not after.
10. It’s about shared learning.
I encourage product teams to consider the ethical implications of their solutions, too. When a significant ethical risk is identified, see if you can find alternative solutions that solve the problem in a way that doesn’t have negative consequences.
Customers don’t know what’s possible, and with technology products, none of us know what we really want until we actually see it.
We can survive for a while with usability issues or performance issues, but without the core value, we really have nothing. As a result, this is generally where we’ll need to spend most of our discovery time.
There’s the often‐messy business risk, where we have to make sure that the solution we come up with in discovery works for the different parts of our company. Here are some common examples of that:
1. Financial risk—can we afford this solution?
2. Business development risk—does this solution work for our partners?
3. Marketing risk—is this solution consistent with our brand?
4. Sales risk—is this solution something our sales staff is equipped to sell?
5. Legal risk—is this something we can do from a legal or compliance perspective?
6. Ethical risk—is this solution something we should do?

Fall in love with the problem, not the solution.

Opportunity Assessment Technique

What business objective is this work intended to address? (Objective)
How will you know if you’ve succeeded? (Key results)
What problem will this solve for our customers? (Customer problem)
What type of customer are we focused on? (Target market)

Product/ market fit shows up in terms of happier customers, lower churn rates, shortened sales cycles, and rapid organic growth.

Customer Interviews

But in every user or customer interaction, we always have the opportunity to learn some valuable insights. Here’s what I’m always trying to understand:
1. Are your customers who you think they are?
2. Do they really have the problems you think they have?
3. How does the customer solve this problem today?
4. What would be required for them to switch?
Here are some tips for getting the most out of these learning opportunities:
- Frequency - Establish a regular cadence of customer interviews. This should not be a once‐ in‐ a‐ while thing. A bare minimum would be two to three hours of customer interviews per week, every week.
- Purpose - You are not trying to prove anything during these interviews, one way or the other. You’re just trying to understand and learn quickly. This mindset is critical and needs to be sincere.
- Recruiting users and customers.
- Location.
- Preparation - Be clear beforehand what problem it is you think they have, and think about how you’ll either confirm or contradict that.
- Who should attend - Bring three people to these interviews: the product manager, the product designer, and one of the engineers from the team (we normally rotate among those that want to attend). Usually, the designer drives (because they’ve usually been trained how to do this well), the product manager takes notes, and the developer observes.
- Interview - Work to keep things natural and informal, ask open‐ended questions, and try to learn what they’re doing today
- Afterward - Debrief with your colleagues to see if you’ve all heard the same things and had the same learnings. If you made any promises to the customer during that session, be sure you keep them.

Principles of Prototypes

The overarching purpose of any form of prototype is to learn something at a much lower cost in terms of time and effort than building out a product.
Realize that one of the key benefits of any form of prototype is to force you to think through a problem at a substantially deeper level than if we just talk about it or write something down. This is why the very act of creating a prototype so often exposes major issues otherwise left uncovered until much later.
Similarly, a prototype is also a powerful tool for team collaboration. Members of the product team and business partners can all experience the prototype to develop shared understanding.
There are many different possible levels of fidelity for a prototype. The fidelity primarily refers to how realistic the prototype looks. There is no such thing as one appropriate level of fidelity. Sometimes we don’t need the prototype to look realistic at all, and other times it needs to be very realistic. The principle is that we create the right level of fidelity for its intended purpose, and we acknowledge that lower fidelity is faster and cheaper than higher fidelity, so we only do higher fidelity when we need to.
The primary purpose of a prototype is to tackle one or more product risks (value, usability, feasibility, or viability) in discovery; 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.

Discovery Testing Technique

We think of four types of questions we’re trying to answer during discovery:
1. Will the user or customer choose to use or buy this? (Value)
2. Can the user figure out how to use this? (Usability)
3. Can we build this? (Feasibility)
4. Is this solution viable for our business? (Business viability)

Testing Your Prototype

We want to learn whether the user or customer really has the problems we think they have, and how they solve those problems today, and what it would take for them to switch.
Testing Your Prototype
- When you first start the actual usability test, make sure to tell your subject that this is just a prototype, it’s a very early product idea, and it’s not real. Explain that she won’t be hurting your feelings by giving her candid feedback, good or bad. You’re testing the ideas in the prototype, you’re not testing her. She can’t pass or fail—only the prototype can pass or fail.
- One more thing before you jump into your tasks: See if they can tell from the landing page of your prototype what it is that you do, and especially what might be valuable or appealing to them. Again, once they jump into tasks, you’ll lose that first‐ time visitor context, so don’t waste the opportunity. You’ll find that landing pages are incredibly important to bridging the gap between expectations and what the product does.
- When testing, you’ll want to do everything you can to keep your users in use mode and out of critique mode. What matters is whether users can easily do the tasks they need to do. It really doesn’t matter if the user thinks something on the page is ugly or should be moved or changed. Sometimes misguided testers will ask users questions like “What three things on the page would you change?” To me, unless that user happens to be a product designer, I’m not really interested in that. 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.
- During the testing, the main skill you have to learn is to keep quiet. When we see someone struggle, most of us have a natural urge to help the person out. You need to suppress that urge. It’s your job to turn into a horrible conversationalist. Get comfortable with silence—it’s your friend.
- In general, you’ll want to avoid giving any help or leading the witness in any way. If you see the user scrolling the page up and down and clearly looking for something, it’s okay to ask the user what specifically she’s looking for, as that information is very valuable to you. Some people ask users to keep a running narration of what they’re thinking, but I find this tends to put people in critique mode, as it’s not a natural behavior.
The most important point for technology companies: If you stop innovating, you will die.

Quantitative Value Testing Techniques

While qualitative testing is all about fast learning and big insights, quantitative techniques are all about collecting evidence.
A/ B Testing - The gold standard for this type of testing is an A/ B test. The reason we love A/ B tests is because the user doesn’t know which version of the product she is seeing. This yields data that is very predictive, which is what we ideally want.
Invite‐ Only Testing - This is where you identify a set of users or customers that you contact and invite to try the new version. You tell them that it is an experimental version, so they are effectively opting in if they choose to run it.
Customer Discovery Program - A variation of the invite‐ only test is to use the members of the customer discovery program we discussed in the section on ideation techniques. These companies have already opted in to testing new versions, and you already have a close relationship with them so you can follow up with them easily.

Testing Feasibility

Do we know how to build this? Do we have the skills on the team to build this?
Do we have enough time to build this? Do we need any architectural changes to build this?
Do we have on hand all the components we need to build this?
Do we understand the dependencies involved in building this?
Will the performance be acceptable? Will it scale to the levels we need?
Do we have the infrastructure necessary to test and run this?
Can we afford the cost to provision this?

Pilot Team Technique

One of the simplest techniques for facilitating moving to new ways of working is the use of pilot teams. Pilot teams allow the roll out of change to a limited part of the organization before implementing it more broadly. The idea is that you look for a product team to volunteer to try out some new techniques. You let them run for a while (usually a quarter or two) with this new way of working and see how this goes.

Part V: The Right Culture

Good Product Team/Bad Product Team

Good teams have a compelling product vision that they pursue with a missionary‐ like passion. Bad teams are mercenaries.
Good teams get their inspiration and product ideas from their vision and objectives, from observing customers’ struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.
Good teams understand who each of their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that work not just for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders.
Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps.
Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something.
Good teams have product, design, and engineering sit side by side, and they embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective silos, and ask that others make requests for their services in the form of documents and scheduling meetings.
Good teams are constantly trying out new ideas to innovate, but doing so in ways that protect the revenue and protect the brand. Bad teams are still waiting for permission to run a test.
Good teams insist they have the skill sets on their team, such as strong product design, necessary to create winning products. Bad teams don’t even know what product designers are.
Good teams ensure that their engineers have time to try out the prototypes in discovery every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate.
Good teams engage directly with end users and customers every week, to better understand their customers, and to see the customer’s response to their latest ideas. Bad teams think they are the customer.
Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap, and are satisfied with meeting dates and ensuring quality.
Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough.
Good teams make high‐integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will work for the customer and the business. Bad teams complain about being a sales‐ driven company.
Good teams instrument their work so they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a nice to have.
Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful integration phase and then release everything at once.
Good teams obsess over their reference customers. Bad teams obsess over their competitors.
Good teams celebrate when they achieve a significant impact to the business results. Bad teams celebrate when they finally release something.

Top Reasons for Loss of Innovation

Organizations that lose the ability to innovate at scale are inevitably missing one or more of the following attributes:
1. Customer‐ centric culture.
2. Compelling product vision.
3. Focused product strategy.
4. Strong product managers.
5. Stable product teams.
6. Engineers in discovery.
7. Corporate courage.
8. Empowered product teams.
9. Product mindset.
10. Time to innovate.
One of the surest paths to product failure is to try to please everyone at once.
So often the key to innovation is the engineers on the team, but this means (a) including them from the very beginning, and not just at the end and (b) exposing them directly to the customer pain.
Remember that empowerment means the teams are able to tackle and solve the business problems they’ve been assigned in the best way they see fit.

Top Reasons for Loss of Velocity

Technical debt.
Lack of strong product managers.
Lack of delivery management.
Infrequent release cycles.
Lack of product vision and strategy.
Lack of co‐ located, durable product teams.
Not including engineers early enough during product discovery.
Not utilizing product design in discovery and instead having them try to do their work at the same time the engineers are trying to build.
Changing priorities.
A consensus culture.

Establishing a Strong Product Culture

What does it really mean to have a strong innovation culture?
1. Culture of experimentation—teams know they can run tests; some will succeed and many will fail, and this is acceptable and understood.
2. Culture of open minds—teams know that good ideas can come from anywhere and aren’t always obvious at the outset.
3. Culture of empowerment—individuals and teams feel empowered to be able to try out an idea.
4. Culture of technology—teams realize that true innovation can be inspired by new technology and analysis of data, as well as by customers.
5. Culture of business‐ and customer‐savvy teams—teams, including developers, have a deep understanding of the business needs and constraints, and understanding of (and access to) the users and customers.
6. Culture of skill‐ set and staff diversity—teams appreciate that different skills and backgrounds contribute to innovative solutions—especially engineering, design, and product.
7. Culture of discovery techniques—the mechanisms are in place for ideas to be tested out quickly and safely (protecting brand, revenue, customers, and colleagues).
What does it really mean to have a strong execution culture?
1. Culture of urgency—people feel like they are in wartime, and that if they don’t find a way to move fast, then bad things could happen.
2. Culture of high‐ integrity commitments—teams understand the need for (and power of) commitments, but they also insist on high‐ integrity commitments.
3. Culture of empowerment—teams feel as though they have the tools, resources, and permission to do whatever is necessary to meet their commitments.
4. Culture of accountability—people and teams feel a deep responsibility to meet their commitments. Accountability also implies consequences—not necessarily being terminated, except in extreme and repeated situations, but more likely consequences to their reputations among their peers.
5. Culture of collaboration—while team autonomy and empowerment is important, teams understand their even higher need to work together to accomplish many of the biggest and most meaningful objectives.
6. Culture of results—is the focus on output or is the focus on results?
7. Culture of recognition—teams often take their cues from what is rewarded and what is accepted. Is it just the team that comes up with the great new idea that gets rewarded, or the team that delivered on a brutally tough commitment? And what is the message if missing a commitment is seen as easily excusable?