Most people working in Product Management will recognise what Melissa describes – building features to satisfy stakeholders or meet output deliverables on a roadmap. But how do you change from an output team to an outcome focused team? This book goes through the steps to get there.
It’s a good read. Although like many business-related books, it feels too long, and a long-form article would have sufficed. But still, Escaping the Build Trap is one of the better books for product managers.
The following are the highlights I made while reading the book.
Part 1: The Build Trap
The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It’s when they focus more on shipping and developing features rather than on the actual value those things produce.
“A lot of it is due to having too many priorities. Everything is number one on your project list. You are peanut-buttering your strategy – meaning that you have so many strategic initiatives spread over very few people.”
To get out of the build trap, you need to look at the entire company, not just at the development team. Are you optimizing your organization to continually produce value? Are you set up to grow and sustain products as a company? This is what a product-led organization does.
In this book, I go into detail on how you can set up a product management organization to look for opportunities that maximize business and customer value.
Chapter 1. The Value Exchange System
When companies do not understand their customers’ or users’ problems well, they cannot possibly define value for them. Instead of doing the work to learn this information about customers, they create a proxy that is easy to measure. “Value” becomes the quantity of features that are delivered, and, as a result, the number of features shipped becomes the primary metric of success.
The company also overpromised during the sales process, giving customers whatever it took to get the contract signed. The result was a ton of one-off features that satisfied the needs of only one client, rather than a strategic choice to build what would scale for many clients.
Instead of analyzing how each of these features provided unique value to its customers and moving the company strategy forward, the organization was stuck in reactive mode. It was not building with intent. And yet, it thought of itself as a successful company because it had a million features to talk about at user conferences. The company lost sight of what made its product attractive to customers – what made the company special.
Chapter 2. Constraints on the Value Exchange System
For example, many companies follow such a rigid development process and cadence that there is no opportunity to experiment. Whenever I start a new training or workshop, I say to product managers, “Raise your hand if you went back and iterated on the last thing you shipped.” Normally, 15-20% of the people raise their hands. My next question is, “How do you know that what you shipped was successful?” The answers here usually revolve around meeting a deadline and finishing with bug-free code.
Yet most companies I encounter are stuck in output mode, and their entire organization is optimized to increase the output. Their processes are driven by deadlines by checking off as many features on a list as possible. Teams are rewarded and incentivized to build more.
Most companies are unaware of the detrimental impact these factors have on their value production, and it’s because they are not actually measuring the outcomes of their actions. They lose track of their strategy and vision, and they end up in the build trap.
Chapter 3. Projects Versus Products Versus Services
Many companies operate on a project-based development cycle, in which they scope out work to be done, create deadlines and milestones, and then have the teams get to work. When the project is over, they move on to the next project. Many of these projects have their own measures of outcomes, but there is no aligning strategy above them.
Products, as I said before, are vehicles of value. They deliver value repeatedly to customers and users, without requiring the company to build something new every time.
Companies that optimize their products to achieve value are called product-led organizations. These organizations are characterized by product-driven growth, scaling their organization through software products, and optimizing until they reach the desired outcomes.
Chapter 4. The Product-Led Organization
But, if you’re not product-led, what are you? Many companies are, instead, led by sales, visionaries, or technology. All of these ways of organizing can land you in the build trap.
Sales-led companies let their contracts define their product strategy … The product roadmap and direction were driven by what was promised to customers, without aligning back to the overall strategy.
Many small companies start off as sales-led, and that can be okay. As a startup, it’s necessary to close that first big client and get the revenue needed to continue operating.
But this way of working does not scale for long. When you have 50 to 100 customers or more, you cannot build everything uniquely to match the needs of each one, unless you want to be a bespoke agency. If that is not in the cards for you, you need to change your strategy to building features that apply to everyone, without customization.
Yet many companies that do not want to go the bespoke route operate as sales-led for far longer than they should. Their sales process gets ahead of their product strategy, and they continually need to play catch-up to make their commitments. This leaves no room for product teams to strategize or explore what could push the company further.
Product-led companies optimize for their business outcomes, align their product strategy to these goals, and then prioritize the most effective projects that will help develop those products into sustainable drivers of growth.
The good thing is that it’s not that technically difficult to make this change. You don’t need to hire an entire new team. You don’t need to scape all your products and start over. What is needed, though, can sometimes be even more challenging to implement – and that’s the mindset shift.
Chapter 5. What We Know and What We Don’t
Product management is the domain of recognizing and investigating the known unknowns and of reducing the universe around the unknown unknowns. Anyone can run with solutions based on known knowns. Those facts are readily available. But it takes a certain skill to be able to sift through the massive amounts of information and to identify the right questions to ask and when to ask them.
Product managers identify features and products that will solve customer problems while achieving business goals. They optimize the Value Exchange System.
Part 2: The Role of the Product Manager
They keep the team focused on the why – why are we building this product, and what outcomes will it produce? The chief product officer is the cornerstone of the product team in companies, helping to tie together the business outcomes to the roadmap and to represent its impact to the board.
Chapter 6. Bad Product Manager Archetypes
There are few paths available today to learn product management. It isn’t taught at college. Training programs on the job are usually lacking. Microsoft and Google are two of the only major companies that actually have an entry-level career path for product managers. Internships are few and far between. And most product managers you meet have made either a lateral move inside their company or have been “promoted” from software development.
Agile does indeed promote a better way of collaboration and a faster method of building software, but it largely ignores how to do effective product management. Agile assumed that someone was doing that front-of-funnel part, generating and validating ideas, and instead optimized the production of software. Yet, that piece has been lost along the way, as companies believe that Agile is all you need to do successful software development. So, many product managers in Agile organizations still operate with this Waterfall mindset.
To understand what the product manager’s role is not, you need to understand the common archetypes of bad product managers.
The Mini-CEO
Product managers are not the mini-CEOs of a product, yet 90% of the job postings I have seen for product managers describe them as being the mini-CEO.
Out of this wonderful CEO myth emerged an archetype of a very arrogant product manager who thinks they rule the world.
The Waiter
The waiter is a product manager who, at heart, is an order taker. They go to their stakeholders, customers, or managers, ask for what they want, and turn those wants into a list of items to be developed. There is no goal. There is no vision. There is no decision making involved.
The most common question I get from product managers in this position is, “How do I prioritize?” Because they have no goal in which to provide context for trade-offs, it becomes a popularity contest for whomever is making the request. More often than not, the most important person gets their features prioritized.
The product death cycle is a specific form of the build trap. You are implementing ideas without validating them. It’s not the customer’s job to come up with their own solutions. That is your job. You need to deeply understand their problems and then determine the best solutions for them.
The Former Project Manager
Project managers are responsible for the when. When will a project finish. Is everyone on track? Will we hit our deadline?
Product managers are responsible for the why? Why are we building this? How does it deliver value to our customers? How does it help meet the goals of the business?
Answering why is very different than answering when. It requires a strategic mindset that understands the customer, business, market, and organization. This is a critical skill set for a great product manager.
Chapter 7. A Great Product Manager
They need to understand the market and how the business works. They need to truly understand the vision and goal of the company. They also need deep empathy for the users for whom they are building products, to understand their needs.
One of the biggest misconceptions about the role of a product manager is that they own the entire product and therefore can tell everyone what to build. Act this way, and you will only alienate the rest of your team. Product managers really own the “why” of what they are building.
One of the worst traits a product manager can have is the lone wolf mentality – the idea that they are the only one responsible for the success of their product.
One of the biggest mistakes companies make in hiring a product manager is trying to find either a technical or market export. Product managers are not experts in either of these domains; they are experts in product management.
That doesn’t mean they don’t need knowledge in either of these areas. They need to know just enough to talk with an engineer or a business person and to understand enough to make informed decisions. A product manager must be tech literate, not tech fluent.
“The biggest thing I’ve learned in product management is to always focus on the problem. If you anchor yourself with the why, you will be more likely to build the right thing.”
When you look at the role of the product owner in most Scrum literature, the three responsibilities of the position include the following:
- Define the product backlog and create actionable user stories for the development teams.
- Groom and prioritize the work in the backlog.
- Accept the completed user stories to make sure the work fulfils the criteria.
Although Scrum has a lot of information on the processes and rituals of what to do as a product owner, it leaves lots of questions unanswered and these questions are important for creating successful products:
- How do we determine value?
- How do we measure the success of our products in the market?
- How do we make sure we are building the right thing?
- How do we price and package our product?
- How do we bring our product to market?
- What makes sense to build versus buy?
- How can we integrate with third-party software to enter new markets?
Product ownership is just a piece of product management. A good product manager is taught how to prioritize work against clear, outcome-oriented goals, to define and discover real customer and business value, and to determine what processes are needed to reduce the uncertainty about the product’s success in the market.
In other words, product owner is a role you play on a Scrum team. Product manager is a career.
Product management and Scrum can work well together, but product management is not dependent on Scrum.
Product managers ultimately play a few key roles, but one of the most important ones is being able to marry the business goals with the customer goals, to achieve value. Good product managers are able to figure out how to achieve goals for the business by creating or optimizing products, all with a view toward solving actual customer problems. This is a very important skill set.
I’ve trained dozens of teams who are using SAFe, and I have never seen it work well. Although the appear of having a framework that lays out everything you need to do technology-wise in nice near boxes sounds appealing, in practice it usually breaks down.
I teach my clients that product managers in senior roles (VPs, product leads, or middle managers) concentrate on defining the vision and strategy for the teams based on market research, an understanding of company goals and strategy, and by looking at the current state of success of their products.
Chapter 8. The Product Manager Career Path
The foundations of working with a development team, diving into individual user needs and problems, and measuring data will always be relevant skills for a product manager at any level.
Typical product management career path:
- Associate product manager
- Product manager
- Senior product manager
- Director of product
- VP of product
- Chief product officer (CPO)
It’s important to remember that this is a discipline that must be mastered as a career. As I’ve explained in this chapter, product management is not something you can learn in a two-day course, as so many Agile consultancies would like you to believe.
Senior product managers are critical to the success of companies of all sizes because they can operate more independently than many product managers. They are also usually entrepreneurial, which is a great trait, since these people are usually the ones who will start new product lines for businesses.
A director of product is usually found only at larger companies and is a critical role for scaling.
In large, enterprise companies, VPs of product are also directly responsible for the financial success of their product line, not just the delivery of product feature. All the VPs of product in a large company must be aligned in their strategy and purpose, to ensure a successful portfolio of products.
The CPO is a fairly new yet critical role for organizations. A CPO oversees a company’s entire product portfolio. This is the highest role of a product manager, and it represents a seat at the executive table of a company.
A company should think about adding a CPO when it starts to develop its second product, expands into another geography, or merges with another company. This role is critical to ensure that the entire portfolio is working together to achieve the company goals.
…those that make the best chief product officers also have three key traits that set them apart: they inspire confidence, empathize, and are relentless and resilient.
Chapter 9. Organizing Your Teams
The way you structure your product teams and organize them around the work that needs to be done on features and products is incredibly important for the success of your product development. Companies tend to organize in three main ways: value streams, features, and technical components.
TransferWise has a reletively small number of product teams at around 12. The way they organize their teams – around strategic goals – allows them to stay small and still get an immense amount of work done.
One team is focused on retention, another on implementing new currencies, and another on acquiring new users. Each of the teams has ownership of their goal and is judged for success based on their outcomes. They are also allowed to work across all products to do whatever is needed to reach those goals … Even though the coordination might seem like a handful, having fewer teams makes them ruthlessly prioritize around the most important initiatives. There’s no useless work.
A value stream is all of the activities needed to deliver value to the customer … To do that, it makes sense to organize your teams around the value stream. How do you organize this way? First you begin with the customer or user – whomever is consuming your product at the end of the day. What is the value that you are providing them? Then work backward.
This often happens when teams restructure around value instead of components. They find they do not need as many people to accomplish their goals.
This gets to what we were talking about earlier – organizing teams around your strategy, which is the most important work for your business.
When organizations lack a coherent product strategy that is ruthlessly prioritized around a few key goals, they end up spreading themselves thin.
Part 3: Strategy
Strategy creation is the process of determining the direction of the company and developing the framework in which people make decisions.
“We started investing 1% to 2% of revenue every year in downloading, and I think it’s tremendously exciting because it will fundamentally lower our mailing costs. We want to be ready when video-on-demand happens. That’s why the company is called Netflix, not DVD-by-Mail.” [Reed Hastings]
“After we eventually won the Blockbuster battle, I looked back and realized all those things distracted us. They didn’t help, and they marginally hurt. The reason we won is because we improved our everyday service of shipping and delivering. That experience grounded us. Executing better on the core mission is the way to win.” [Reed Hastings]
That guideline was to “delight customers, in margin-enhancing, hard-to-copy ways.” He set goals that would accomplish this and would help Netflix execute on the company vision around key initiatives including personalization, instant access to entertainment, and ease of use. Teams were then able to explore tactics to accomplish these goals, and they were held accountable to success metrics for each.
Netflix can change tactics or kill ideas because it commits itself not to the solutions they are building but rather to the outcomes these solutions produce.
Chapter 10. What is Strategy?
Teams that lock themselves into these plans of action before gathering actual evidence will build useless features that do not matter to their customers.
Thinking of strategy as a plan is what gets us into the build trap. We keep adding new features to the list but have no way to evaluate whether they are the right features in the holistic context of our company.
A good strategy should sustain an organization for years. If you are changing strategy yearly or monthly, without good reason from data or the market, you are treating your strategy as a plan rather than as a framework.
Chapter 11. Strategic Gaps
- The knowledge gap
- The alignment gap
- The effects gap
At one company, I walked around asking all of the product managers on the hundred or so teams why they were working on their current project. I then asked their leaders the same question. I got two different answers from these two different levels. They could not connect the activities of the teams back to the outcomes of the companies because leadership had passed down feature requests rather than expected outcomes and goals.
When these teams realized that customers did not want the consultant-proposed solution, they should have had the freedom to explore alternative options. That is how a product-led organization would operate. This is what keeps us out of the build trap. Instead, their adherence to pre-determined meetings and formalities trapped them into staying quiet. Product teams need the freedom to explore solutions and to adjust their actions according to the data they receive. As long as they are aligned with the overall strategic intents and vision for the company, management should feel comfortable granting the necessary autonomy to capable teams.
But why do we care about strategy being something that enables action? Well, that is how you scale an organization – by enabling action through autonomous teams.
In the world of software, we don’t work this way. We’re hiring incredibly smart people and paying them hundreds of thousands of dollars to make the decisions on how to grow companies by making complex software that customers love. When you have that sort of talent, you need to give them the room to make decisions so that you can get the full benefit of their knowledge skill.
That’s what a strategic framework promotes. If you’re aligned coherently and you have a good strategic framework, you can then allow people to make decisions without a lot of management oversight.
Chapter 12. Creating a Good Strategic Framework
It was reacting to the customer that screamed the loudest instead of evaluating whether those requests matched the strategic objectives. The morale of the company was low, and, because of that, employees were not producing.
So the company decided to change. It decided to create and deploy a strategy that would work with modern product management methods.
One of the biggest issues I hear from executives is that they do not have the data they need to make decisions. People ask them to create a vision, but they do not continuously surface information in a way that helps inform the strategic decisions that enable the organization to achieve the vision. The teams should be out there, analyzing, testing, and learning and then communicating what they discover back to their peers and their management teams. This is how we set strategy. [Bloom]
Chapter 13. Company-Level Vision and Strategic Intents
“What is the most important thing we can do to reach our vision, based on where we are now?” There should not be laundry list of desires or goals – just a few key things that need to happen to make a big leap forward. Keeping the list of strategic intends small focuses everyone.
One intent is usually good for a small company, and three are plenty for a large organization. Yes, three. I know that sounds like very few goals for an organization of thousands of people, but that is key. This is also where the level and time frame matters.
That’s the point. The strategic intents are about the whole company, not just the product solution.
Chapter 14. Product Vision and Portfolio
All of these solutions, which I call options, were aligned to this product initiative. Options are your bets, as Spotify would cal them. They represent the possible solutions that teams will explore to solve the product initiative.
To get there, the CPO answers these questions for their teams:
- How do all of our products work as a system to provide value to our customers?
- What unique value does each of the product lines offer that makes this a compelling system?
- What overall values and guidelines should we consider when deciding on new product solutions?
- What should we stop doing or building because it does not serve this vision?
Amazon is the king of building innovation into its portfolio. It spins up teams in secret labs, and these teams spend years figuring out how to expand the company’s business.
Amazon set the time and space aside that it needed in product initiatives to go after and explore how to enter this new market.
Part 4: Product Management Process
Chapter 15. The Product Kata
After we have set the goal, we begin walking through the Product Kata. We ask ourselves the following:
- What is the goal?
- Where are we now in relation to that goal?
- What is the biggest problem or obstacle standing in the way of me reaching that goal?
- How do I try to solve that problem?
- What do I expect to happen (hypothesis)?
- What actually happened, and what did we learn?
One of the biggest mistakes I’ve seen in product management is teams rushing into apply a tool or practice at the wrong stage. Many times, they are experimenting unnecessarily when the problem is not yet known or when there is already a good idea about the solution.
Chapter 16. Understanding the Direction and Setting Success Metrics
Product metrics tell you how healthy your product is, and, ultimately, your business, given that a healthy product contributes to overall health of the business. They are the lifeblood of every product manager. Keeping a pulse on your product is crucial for knowing when you should act and where. This is how we set direction.
To make sure you have enough data to act on, it’s important to implement tools that make it easy to measure these things. This is one of the first things every company should do – implement a metrics platform. Amplitude, Pendo.io, Mixpanel, Intercom, and Google Analytics are all data platforms. Some, like Intercom and Pendo.io, also implement good customer feedback loops, because they provide tools to reach out to customers and ask questions. Having a metrics platform implemented, whether it’s homegrown or third party, is essential for a product-led company because it enables product managers to make well-informed decisions.
You won’t be able to set success metrics without investigating the problem. This is why we first need problem exploration, a process we explain in the next chapter.
Chapter 17. Problem Exploration
Product managers are often spoken about as the “voice of the customer,” yet too many of us are not getting out and talking to customers as much as we should. Why? Because it involves talking to (gasp) people. It takes a lot of effort to line up the interviews, and sometimes that can seem more daunting than staying inside and jumping right into A/B testing or sifting through data. Although data analysis is important, it can’t tell the entire story.
If you don’t have an underlying understanding of the problem, you can never deliberately create the right solution.
Instead, fall in love with the problem you are solving.
People often immediately jump into telling you the solution. “Oh, I just need a button here that lets me do X,” they say. As a product manager, you need to back up and ask, “Okay, but why? Why do you need a button? Why do you think a button is the right thing? What are you trying to accomplish?” It is understanding the user’s need – not the button – that helps you to get closer to understanding the root of the problem.
Remember, it’s not the customer’s job to solve their own problems. It’s your job to ask them the right questions.
Chapter 18. Solution Exploration
Companies often confuse the building to learn and building to earn. Experimentation is all about building to learn. It allows you to understand your customers better and to prove whether there is value in solving a problem. Experiments should not be designed to last for a long time.
Concierge experiments are particularly interesting for B2B companies because this is how many of these companies got started – by taking on the work for the customers and then later automating it. By taking on the work yourself, you can learn how to build the software correctly the first time. And it’s far faster and less expensive to iterate on a service than on a coded feature. I frequently used this type of experiment to learn about my customers when I worked as a product manager.
Zappos actually started with this Wizard of Oz method. Back in the way, founder Nick Swinmurn wanted to see whether people would really buy shoes online. He put a simple website up on WordPress. Visitors could view and then buy the shoes online. But, on the backend, it was just Nick, singlehandedly running around, buying shoes from Sears and shipping them out from UPS himself.
Every industry and product has unknowns – getting creative about how you answer these unknowns is key.
Chapter 19. Building and Optimizing Your Solution
After the direction is set for the product vision, it’s important to make sure everyone understands the context and work that needs to be done. Story mapping and North Star documents are two ways to help teams find alignment around the vision.
We are done developing or iterating on a feature only when it has reached its goals. Often, teams ship a first version of the feature and then move on to the next, without measuring the outcomes for the user. As Jeff Gothelf, the author of Sense & Respond, once said, “Version 2 is the biggest lie in software development.” This mentality always leads to the build trap.
When you have success criteria set for the launch, you can use them in the Product Kata and repeat the steps we went through in this section: set the direction with your success criteria, understand what problems are standing in the way of you reaching it, and systematically tackle them through experimentation.
This is how you build with intent and get out of the build trap. But, in addition to having a solid process and strategy, you need a company that supports good product management efforts. Christa’s team was able to succeed only because their environment allowed it to. They were able to talk to customers. The team was oriented around outcomes, and then the leadership team gave it the space to figure out how to achieve those outcomes.
These are the marks of a product-led company. Process and frameworks get you only so far on your way to success. Culture, policies, and structure are the things that really set a company apart to thrive in product management.
Part 5. The Product-Led Organization
The product-led organization is characterized by a culture that understands and organizes around outcomes over outputs, including a company cadence that revolves around evaluating its strategy in accordance to meeting outcomes. In product-led organizations, people are rewarded for learning and achieving goals. Management encourages product teams to get close to their customers, and product management is seen as a critical function that furthers the business.
Its philosophy as an organization was not set up to succeed in the world of rapid innovation that emerged during the early 2000s.
Many companies are in danger of becoming just like Kodak, but this fate can be avoided by adopting a product-led mindset.
Chapter 20. Outcome-Focused Communication
If there is one main reason I have seen companies fail to make a transition, it’s the lack of leadership buy-in to move to an outcome-oriented company. Leaders will say that they want to achieve results, but, at the end of the day, they still measure success by features shipped. Why? There’s so much satisfaction in seeing things move, at both a leadership and a team level. People want to feel like they are accomplishing things. Checking off the boxes of finished work feels good, but we need to remember that this is not the only measure of success.
Instead of thinking of roadmaps as a Gantt chart, you should view them as an explanation of strategy and the current stage of your product. This combines the strategic goals with the themes of work and the emerging product deliverables from it. To do this, the product roadmap should be updated constantly, especially at the team levels. This is why, at Produx Labs, we call them Living Roadmaps.
Roadmaps are not one-size-fits-all. You need to communicate them differently, depending on whether you are talking internally to your team about uncertainty or to the sales team about features that it can communicate to customers. You should design your communication to match your audience.
One great resource for determining how to set a roadmap is C. Todd Lombardo and Bruce McCarthy’s book, Product Roadmaps Relaunched. It’s an in-depth, practical guide on how to create great roadmaps for your company.
Usually, our roadmaps consist of a few key parts:
- The theme
- Hypothsis
- Goals and success metrics
- Stage of development
- Any important milestones
Chapter 21. Rewards and Incentives
[No notes]
Chapter 22. Safety and Learning
Marquetly was successful because the CEO and leaders held back while the teams were experimenting, even if that made them squirm a bit. Product managers need a certain amount of trust from the organization to have room to explore different options. To really push boundaries, teams are going to have to try some perceivably wild stuff. It might not be the solution you originally thought of and the teams might not have all the answers at the beginning, but if they are not allowed to explore these weird paths, they will never push the status quo. The status quo is safe. The status quo keeps you from innovating.
Learning should be at the core of every product-led organization. It should be what drives us as an organization.
Ideally, product managers should be risk mitigators who say, “Hey, I think the most costly thing we can do is build this product without knowing it’s the right product to build. How do I test it and ensure that this is actually what we want? How do I become more confident that we’re on the right path before I invest money in this?” Leaders who give people the room to do that see the best results and avoid the build trap.
Chapter 23. Budgeting
One of the factors that leads to the output-over-outcome mindset in organizations is the way that they do budgeting.
It’s far wiser to look at funding product development like a venture capitalist.
Product-led companies invest in and budget for work based on their portfolio distribution and the stage of their work.
They then allocate more and more funds to grow the opportunities as they become validated.
But the idea is that all budgeting should be tied to getting a product to the next stage. It’s an effective way to both focus the teams and make sure you’re not overspending.
Chapter 24. Customer Centricity
Many of the top companies today, such as Amazon, Netflix, Zappos, Dollar Shave Club, and Disney, have gotten where they are by focusing on the customer. You can see this attitude manifest in the way that executives talk about and treat their customers.
This is the core of what it means to be customer-centric – to put yourself into your customers’ shoes and ask, “What would make my customers happy and move our business forward?”
This is what it means to be customer centric: knowing that the most important thing you can do to create great products is to deeply understand your customers. This is also the core of what it means to be product-led.
Chapter 25. Marquetly: The Product-Led Company
Getting out of the build trap is possible, but it takes time and effort. It’s not something that you can easily achieve in a year. It requires not only changing how you work but also how you think as an organization. It needs the participation of everyone in the organization, from the leaders in the C-Suite to the product managers on the teams. Reading this book is your first step. Setting up a fully-functioning product organization will be your first step.
Afterword: Escaping the build trap to become product-led
Consulting also taught me that one of the quickest ways to kill the spirit of a great employee is to put them in an environment where they can’t succeed. That’s when most people leave. Even good product managers become tied of waking up and going to war every day. They spend too much time trying to change the policies so that they can succeed at their job rather than building the best product they can.
The truth is that most organizations out there are not product-led. And yet, being product-led is a winning strategy. If you look at some of the best companies out there today – Amazon, Netflix, and Google, for example – they are not reactively building whatever customer request comes their way. They are not following Agile processes blindly to build whatever features they can, as fast as they can. Instead, they are developing products with the intent to deliver value to their customers.
Six questions to determine whether a company is product-led
- Who came up with the last feature or product idea you built?
- What was the last product you decided to kill?
- When’s the last time you talked with your customers?
- What is your goal?
- What are you currently working on?
- What are your product managers like?
Tim Woods 