Paul Drummond

P1 - The build trap is when organisations become stuck measuring their success by outputs rather than outcomes.
P5 - Your company is not set up for that type of feedback. People are afraid to talk with you or their managers. You tie people’s bonuses to shipping software, not to solving problems.
P5 - You’re stuck in the build trap. To get out, you need to change the way you approach software development, both as a company and as a leader. You have to become product-led. That involves shifting the entire mentality of the organisation from delivering to achieving outcomes. You will have to change your structure, your strategy, and not only the way you work but also the policies and rewards governing it.
P6 - The build trap is a terrifying place for companies because it distracts them. Everyone is so focussed on shipping software that they lose sight of what is important: producing value for customers, hitting business goals, and innovating against competitors.
P6 - To get out of the build trap, you have to look at the entire company, not just the development team.
P8 - Products and services are not inherently valuable. It’s what they do for the customer or user that has the value - solving a problem, for example, or fulfilling a desire or need. Doing this repeatedly and reliably is what guides a company to success.
P8 - These companies then motivate their employees and judge them for success with the same proxies. Developers are rewarded for writing tons of functional code. Designers are rewards for fine-tuning interactions and creating pixel-perfect designs. Product managers are rewarded for writing long specification documents or, in an Agile world, creating extensive backlogs. The team is rewarded for shipping massive quantities of features. This way of thinking is detrimental yet persuasive.
P12 - Outcomes are the things that result when we finally deliver features and the customer problems are solved.
P14 - Projects are an essential part of product development, but the mentality of thinking on in projects will cause damage.
P15 - Sales-led companies let their contracts define their product strategy.
P16 - The problem is that Technology-led companies often suffer from a lack of market-facing, value-led strategy.
P17 - Product-led companies optimise for their business outcomes, align their product strategies to these goals, and then prioritise the most effective projects that will help develop those products into sustainable drivers of growth.
P20 - Product managers are the key to becoming product-led. Yet so many companies put people without these capabilities into this role.
P29 - Project managers who are put into product management roles often become waiters waving a calendar.
P29 - Product managers are not project managers, although a little project management is needed to execute on the role correctly.
P29 - 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?
P30 - Many companies still think that the project manager and product manager are one and the same.
P31 - The title “product manager” is misleading in itself. An effective product manager is not a manager. The position doesn’t come with much direct authority.
P31 - 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.
P31 - Product managers really own the why of what they are building.
P32 - At the end of the day, it’s the team, collectively, that really owns the product, the what.
P33 - One of the biggest mistakes companies make in hiring a product manager is trying to find either a technical or market expert. Product managers are not experts in either of these domains: they are experts in product management.
P33 - A product manager must be tech literate, not tech fluent.
P37 - This is where people usually become confused between what Agile calls a product owner and a product manager.
P38 - 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 customers goals to achieve value.
P38 - Too often, companies don’t know what product managers are supposed to do or why they’re important. I’m routinely told that people don’t even think their company needs product managers. “The CEO comes up with everything”. I hear that alot.
P39 - If you want to get out of the build trap and begin focusing on sustainable solutions and products that customers need and want, you must embrace product management.
P39 - I’ve trained dozens of teams who are using SAFe, and I have never seen it work well.
P50 - Each of the teams has ownership of their goal and is judged for success based on their outcomes.
P51 - A value stream is all of the activities needed to deliver value to the customer.
P51 - Many companies are confused by the word product. If your app, interface or feature is not inherently adding value on its own, it’s just a piece of the entire product. That doesn’t mean no one needs to manage it. It just means you have to look beyond just that piece to understand how to manage value delivery and creation.
P61 - Good strategy isn’t a detailed plan. It’s a framework that helps you make decisions.
P61 - Teams that lock themselves into these plans of action before gathering actual evidence will build useless features that do not matter to their customers.
P62 - Thinking of a strategy as a plan is what gets us into the build trap.
P66 - Instead of seeking more detailed information, upper management should be limiting its direction to defining and communicating the strategic intent, or the goals of the business.
P67 - The product managers could not connect the activities of the teams back to the outcomes because leadership has passed down feature requests rather than expected outcomes and goals.
P68 - When leadership is not aligned at the top, the issues trickle all the way down to the teams. The lack of meaning and focus spreads, and, at the end of the year, the company will look at their target goals and ask “what happened?” Lack of leadership alignment is by far the biggest issue I see standing in the way of successful product management.
P70 - Autonomy is what allows organisations to scale. The alternative is hiring hundreds or thousands of middle managers that lead by authority, telling people what to do.
P70 - Leading by authority is a relic of industrial-age methodologies - when low-skilled workers were supervised closely so that their output was maximised. In the world of software, we don’t work this way.
P70 - When you have talented people, you have to give them the room to make decisions so that you can get the full benefit of their knowledge and skill.
P74 - Not having the right level of direction lands us in the build trap. Teams are given instructions that are either too prescriptive or too broad.
P80 - A good mission explains why the company exists. A vision, on the other hand, explains where the company is going based on that purpose.
P82 - Instead of dictating solutions to the teams, leadership should be focused on creating strategic intents.
P84 - The strategic intents are about the whole company, not just the product solution.
P99 - Don’t spend your time over designing and creating unique, innovative solutions for things that are not core to your value proposition.
P104 - It’s easy to become stuck measuring the wrong things. Frequently, teams turn to measuring what we call vanity metrics. This concept, introduced in Lean Startup, is about goals that look shiny and impressive because they always get bigger. People are excited to share how many users are their product, how many daily views they have, or how many logins their system has.
P105 - You can easily turn a vanity metric into an actionable metric by adding a time component to it.
P105 - I often see product teams measuring output-oriented metrics, such as the number of features shipped, story points complete, or user stories worked on. Although these are good productivity metrics, they are not product metrics. They cannot tie the results of the product development back to the business.
P111 - 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.
P111 - It’s essential that we all go talk to actual humans to get to the heart of their problems.
P111 - User research is not to be mistaken for usability testing. Usability testing is showing a prototype or website and directing people to complete actions.
P111 - Problem-based user research is generative research, meaning that its purpose is to find the problem you want to solve.
P111 - It’s easy to fall into the trap of solving problems before you find their root causes. We’re all prone to problem solving, even if we don’t know what the problem is. Our brains love thinking in terms of solutions.
P114 - In many companies, it’s difficult - or even impossible - to talk to the customer, usually due to corporate bureaucracy. IN these situations, you need to get creative.
P114 - In a B2B environment, you can work with the sales or account managers to have them be your research spies - asking the questions you might need to know during their sales calls or follow-up meetings.
P115 - Remember, it’s not the customer’s job to solve their own problems. It’s your job to ask them the right questions.
P116 - This type of thinking is exactly what lands us in the build trap. When we use an MVP only to get a feature out quicker, we’re usually cutting corners on a great experience in the process.
P116 - The most important piece of the MVP is the learning.
P116 - Due to the misconception of this term, I have stopped using MVP altogether. Instead, I talk more about solution experimentation.
P126 - When I introduce the concept of experimenting to learn, I am frequently met by the same response: “That sounds nice, but we just can’t do that here.”
P126 - Making known the unknowns reduces risk, and that goes for large, bureaucratic companies like banks, as well as for industries with long product development timelines like aviation.
P126 - There is no excuse for not learning.
P126 - Even the most seemingly Waterfall projects can be experimental. Consider developing a space shuttle. Even though it takes years to build this complex system, and it involves hardware, there are still possible experiments along the way.
P129 - Learning reduces risk. The goal of solution exploration is to get faster feedback.
P130 - Internal tools are often neglected, but they still matter to the company. They need to be treated the same way as any other product.
P139 - Although “Definition of Done” is definitely a useful concept to make sure the team finished what it needs to do, it sets the wrong expectation about what a finished feature is.
P139 - 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 onto the next, without measuring the outcomes for the user.
P139 - Instead, teams should be setting the success criteria before launch, while measuring and iterating until they reach it.
P139 - If we launch the feature and it's not hitting its goals, we need to be comfortable rolling it back and trying something else.
P147 - Marquetly was a classic example of a company stuck in the build trap. It was project-oriented, spinning up team to tackle whatever was prioritised by the CEO. There were no product managers in the organisation. Teams never talked to customers and were rewarded for shipping finished software.
P148 - That is usually where companies get stuck in the build trap. They are not patient enough to see outcomes emerge, so they instead measure progress by the number of features shipped.
P155 - It would shock you the number of times I’ve heard product managers say “It doesn't matter what the goal is. We just have to deliver this feature”. These are the good product managers, too. They want to build great products - they just don’t believe they can do so in their current environment. They are being forced into the build trap by company policy, even when they know it's the wrong way to build things.
P156 - Tying livelihoods to the fact that you shipped product at all, instead of learning or solving problems for customers, is what gets people into the build trap.
P156 - Even though it’s difficult to change many of the policies, if you don’t have the right seniority, you can still try to change the minds of the people who can bring those messages up the chain. This can start the right dialogue.
P157 - I’ve worked on teams that had a sales department which oversold the roadmaps so much that we were two years behind in development. Customers were angry, and we had high churn. I also saw sales teams target the wrong customers in order to make the numbers. These customers left quickly.
P157 - If you are a leader at a company, it’s time to reevaluate how you are incentivising people. You should be rewarding people for moving the business forward - achieving outcomes, learning about your users, and finding the right business opportunities.
P159 - Product managers need to have a certain amount of trust from the organisation to have room to explore different options.
P159 - With the rise of Lean Startup, we began to focus on outcomes, yes, but we also started to celebrate failure. I want to be clear here: it is not success if you fail and do not learn.
P159 - Learning should be at the core of every product-led organisation. It should be what drives us as an organisation.
P159 - It’s better to fail in smaller ways, earlier, and to learn what will succeed, rather than spending all the time and money failing in a publicly large way. This is why we have problem and solution exploration in product management - to de-risk failing in the market.
P160 - Netflix could have tested the waters with Qwikster. Instead, it went in full force on an idea that hadn’t been validated.
P160 - So many companies fail slowly. They release products and never measure whether those products do anything. They just let them sit there, collecting dust in a sea of endless features, never knowing whether they are producing value.
P160 - Instead, if you adopt a great product mindset and you give people the freedom to fail, what you’re doing is allowing them to fail quickly, quietly, and at a lower cost because they’re testing things early. That’s the type of failure you want to encourage. That’s the type of failure from which we can recover.
P166 - 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.
P169 - People will get in the way of a good product every time. Even if it is the best idea for the company, if it doesn’t meet the personal agendas of senior stakeholders it can be squashed.
P170 - The truth is that most organisations out there are not product-led. And yet, being product-led is a winning strategy.
P170 - If you look at some of the best companies today, 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.
P170 - Product led companies do not just build things for the sake of checking boxes. They build things to further their business.
P173 - A good product manager knows that getting buy-in from the whole team is crucial.
P173 - It's a bad sign when product managers are seen as weak in the organisation because they are beaten down by stakeholders and management.
P173 - When product managers are seen as project managers, they hold no decision making power. Stakeholders and management use them to just usher their own ideas through. Product managers don't feel like they can say no because of the potential for strong backlash.

Escaping the Build Trap (Book Notes)