Many companies with product managers don’t practice true product management. Instead, they simply scribe feature requests and relay them on to development teams without doing any of the analytical work necessary to determine what should be built. This analytical work is actually the core function of product management.

In “Escaping The Build Trap”, Melissa Perri explains how companies can get the most value out of the product management and become ”product-led”. The book offers advice on how individual product managers can most effectively play their role, and it also zooms out to look at the big picture of how a company’s organizational structure and strategic alignment mechanisms can help to lay the foundation for effective product management. This post sums-up all of the book’s key pieces of advice.

The Anti-Pattern: Scribing Feature Requests for a Feature Factory

Perri starts by giving a counterexample of what product management is not. She asserts that a product manager is not merely a “waiter” who takes feature requests from various stakeholders and funnels them to engineering teams, much like a waiter relays orders to the kitchen in a restaurant. Rather, the product manager’s role is to identify what needs to be built in order to fulfill a business objective. The focus should be on figuring out how to use the product to drive measurable outcomes, instead of simply facilitating the delivery of requested features.

When companies don’t understand that they should evaluate the performance of their digital teams based primarily on how how effectively they drive business outcomes rather than how efficiently they deliver requested features, they get stuck in the “build trap”. The defining characteristic of the build trap is an excessive focus on building a lot of stuff quickly and an underemphasis on validating how well features drive their intended outcomes. Two red flags that indicate you are in the build trap are if you have never killed a feature because it was not performing well, or if you rarely iterate on features after their initial release.

After giving due treatement to the anti-patterns, Perri moves on to tell us how the role of the product manager should ideally work.

This whole section should be shortened, it’s a bit repetitive.

What The Product Manager Role Should Ideally Entail

Perri summarizes the the role of the PM as figuring out how to deliver something of value to the customer, which will in turn benefit the business. She emphasizes the importance of applying a structured approach to figure out what to build as opposed to prematurely jumping to a solution.

The approach that Perri offers consists of the following 4 steps, which are repeated iteratively:

1. Understanding the direction
2. Problem exploration
3. Solution exploration
4. Solution optimization

The first step is to understand the strategic direction that the company is trying to move in, so that you can grasp what business outcomes the product should be driving. This initial step involves getting a sense of the product’s vision, market positioning, and top goals for the next year or two. Given that the main goal of the product manager is to drive measurable business outcomes, this step guides all subsequent decision-making.

The second step in the process is problem exploration, which involves identifying the main obstacles that are preventing the business from achieving one of it’s specific goals. This step leverages data such as customer interviews, user research, and analytics to pinpoint and size the product’s key improvement opportunities.

Solution exploration is the process of generating and evaluating different solutions that could potentially overcome the obstacles identified in the prior step. This involves examining a wide range of potential alternatives and then collecting data through either user research or small-scale experiments to determine which one warrants further investment. The objective of this phase is to obtain rapid feedback to help drive selection of the best solution.

Solution optimization involves refining the details of the selected solution to make it more effective. This may include conducting moderated user testing on different design variants or running A/B tests in production to compare how slight adjustments might lift performance.

Perri emphasizes that this 4-step process is iterative in nature, such that new information encountered during solution optimization could well lead you to start another cycle of the process, but with a different focus.

Strategic Alignment

Company leadership needs to effectively communicate strategy down the ladder in order to enable product managers to do their job effectively. Because a product manager’s job consists of deciding what to build in order to achieve a desired outcome, it’s critical that they’re 100% clear what outcomes they should be seeking to achieve and how success will be measured.

According to Perri, the build trap often emerges as sort of a misguided strategic alignment mechanism. When leadership tells teams exactly what features to build, and then asks for a detailed plan and periodic status reports, what they’re often really trying to do is ensure that the team is moving in the right direction. Perri believes that a better way to achieve the desired strategic alignment is to give a product team a specific problem to solve, make sure they understand its strategic significance, and then give them space to explore how to solve it.

If this approach is followed, then the product team’s interactions with leadership can look more like productive dialogues than one-way status reports. The product team can share what they’ve learned about how to achieve the business goals that they’ve been tasked with, and then invite feedback. For example, the product team could report in with something like, “We started investigating the problem by looking at user analytics data, and we found a trend which we then dug deeper into by conducting a set of customer interviews. At those interviews, a theme emerged in the customer feedback that the real problem is X, and now we want to experiment with a couple of different prototypes that solve that problem in different ways. We are betting that these new solutions could result in an 8% increase in the key outcome that we’re trying to lift.” I agree with Perri that this approach does a much better job of leveraging the collective intelligence of the team, and achieving strategic alignment.

Organizational Structure

Perri argues that a company needs to have a certain organizational structure in place to enable effective product management.

Perri’s first recommendation on org structure pertains to how each product team’s area of responsibility should be scoped. She starts this recommendation in her signature style, with a warning of what not to do: don’t plan the organizational structure to mirror the technical architecture, where a product team is responsible for a set of technical components, like APIs. This approach does offer the benefit of creating deep subject matter expertise in all parts of the system, but it comes with disadvantages as well. The main disadvantage is that this limits a company’s ability to prioritize work based on value. If there’s 1 fixed capacity team dedicated to each part of the product, then that incentivizes constant work on each part, even though they may not be of equal priority.

The better alternative is to assign each product team with a scope of responsibility that corresponds to a logically-related set of business outcomes. This allows the team the latitude to work on whatever is necessary to drive progress in their area. Reflecting on my own personal experience, I think that this is an effective approach. When I worked at a logistics company, I was a part of a group responsible for all applications used by employee who physically touched shipments.

The second recommendations on org structure is to avoid decoupling the product manager role from a tactical, delivery-oriented product owner. She argues that this division of responsibility is problematic it implies that there’s a discrete point in time where discovery ends and delivery begins. However, the messy truth is that those areas are difficult to disentangle. Attempting to do so can lead to a situation where nobody is doing validation work, because the product owner is responsible for delivery rather than outcomes, and the product manager’s responsibilities end at the hand-off to the delivery team.

While I agree with Perri’s point that the product manager should remain engaged throughout execution to stay apprised of all user research, experimentation, and analytics, I think that a dedicated PO role can still be valuable in cases where the engineering team is expecting to receive comprehensive requirements documentation that includes things like test cases and API details.

Shift in Mindset

One theme that stood out to me from the book is the way in which becoming product-led requires a shift in mindset for a company’s leadership. To be specific, it requires extra humility and trust. Humility is important because a company will never hire PMs to figure out the right thing to build unless its leadership first admits that they can’t intuit the right thing to build. Trust is also a key component, because getting the most value out of product management requires relinquishing some control over the process and delegating decision-making the employees on the front-lines. A product-led organization is certainly more challenging to manage than a feature factory, but the benefits seem worth the effort.