Escaping the Build Trap: How Effective Product Management Creates Real Value

by Melissa Perri

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.

I once worked with a company that made a data platform for enterprise companies. It had a total of 30 features, with about 40 more on the backlog, when I came in. When I measured the customer use of those existing features, we discovered people used only 2% of them consistently. And yet, development was underway to add more, instead of trying to reevaluate what they already had. How did they end up there? A few reasons, and these apply to many companies stuck in the build trap. The company was playing a game of catch-up—trying to fast-follow its competitors on every feature it released. It didn’t even know whether these features were working out well for their competitors, but management insisted on parity. This is the same trap Google+ fell into with Facebook—​never differentiating enough, just copying.

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.

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 them until they reach the desired outcomes.

Visionary-led companies can be very powerful—when you have the right visionary. But, there aren’t too many Steve Jobses floating around. Also, when that visionary leaves, what happens to the product direction? It usually crumbles. This has been something Apple has had to contend with since CEO Tim Cook took over. The world is wondering what is next for Apple, after it has built up its existing products.

Operating as a visionary-led company is not sustainable. Innovation needs to be baked in to the system so that one person is not the weakest link. When you have 5,000 brains working on a problem (as opposed to one), you can harness that power better to succeed.

When kicking off a project, it’s best to begin by identifying what you know to be true about the situation—your known knowns. These are facts that you gather from data or critical requirements from customers. Now not all perceived requirements are necessary, but some of them are. These could be mandated by government regulations, or they could be basic needs that are required to do the job.

Known unknowns are clarified enough that you know which question to ask. They are assumptions that you want to test, data points that you can investigate, or problems that you can identify and explore. You use discovery methods and experimentation to clarify these, turn them into facts, and build to satisfy those facts.

Unknown knowns are those moments when you say, “I feel like this is the right thing to do.” This is intuition from years of experience. Although we should all listen to our intuition, you should also be cautious because this is often where bias thrives. It’s imperative to check and experiment to see whether your intuition is right.

The unknown unknowns are the things that you don’t know you don’t know. You don’t know enough to ask the right questions or identify the knowledge gaps. These are the moments of surprise that need to be discovered. They happen when you are out talking to customers or you are analyzing seemingly unrelated data. They pop up during research. You need to be open to these dis...

Product management is the domain of recognizing and investigating the known unknowns and of reducing the unive...

I was so proud when that “change password” page, my first product, birthed from a 21-page spec, was delivered to customers. My first real feature! Little did I know then that this whole release probably could have been accomplished in just a few conversations with good developers and about a tenth of the documentation or less. But that wasn’t how I was taught product management. And that’s not how most people are taught 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.

“Start listening to your team. Involve them. Listen to your customers and focus on their problems instead of your own solutions. Fall in love with those problems. Also, go seek out data to prove and validate your ideas. Turn to concrete evidence, rather than opinions.”

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. This was the archetype of 90% of the product owner teams at Marquetly.

The product managers go out, with all the right intentions, to talk to their customers and learn what they want. But, instead of discovering problems, waiters ask, “What do you want?” The customer asks for a specific solution, and these product managers implement them. This is where you end up in what my friend David Bland, product advisor and consultant, calls the product death cycle

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.

Waiters are reactive thinkers, not strategic thinkers. There’s usually an amount of learned helplessness that contributes to that. They don’t believe that they can push back on these solutions and dive deeper into problems. But that’s not true.

It’s very possible to find the waiter archetype paired with another one, like project management. Because they are not focused on the why, they tend to focus a lot on the when. Project managers who are put into product management roles often become waiters waving a calendar.

Product managers are not project managers, although a little project management is needed to execute on the role correctly. 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?

Agile methodologies distribute the responsibilities of the project manager across the team. These cross-functional teams have all the key players dedicated to ship a feature, so less coordination is needed across departments. Thus, project management is not needed as much as it once was when all of these people were in different areas of the business, splitting their time on different projects.

An effective product manager must understand many sides of the company in order to do their job effectively. 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. They know the goal at hand and understand which direction the team should be building toward, depending on company strategy. They communicate this direction to the rest of the team.

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. This causes them to become arrogant and dismissive of their teams’ ideas.

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. 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. That means they can discuss enough and understand enough about the technology to talk to developers and to make trade-off decisions. They know the right questions to ask engineers to understand the complexity of certain features or improvements. A product manager doesn’t need to be able to code unless the product is highly technical and it’s essential they understand the technology deeply to make decisions.

The same goes for the market. Although it’s valuable for a product manager to know the market well, this is something they can learn. This is all about balancing the skill sets of your team. If you have highly-skilled market analysts, a great product manager ...

But how did she decide which pain points to solve? Well, Meghan had already worked with her VP of product to identify the business goal that aligned with the vision of her department: to increase the amount of first-time applications that are submitted. At the time, 60% of first-time applicants who started the mortgage process did not finish with this bank and, instead, turned to competitors that handled the process with more grace.

I have listened to many arguments that product owners do not have time to do both roles. In the current context, that’s true. The product owners I speak with spend 40 hours a week writing tons of user stories. At that point, you need to ask, are those user stories even valuable? What are they prioritizing them against? How do they know that they will solve a problem? If you have one person spending that much time writing user stories, every week, you are most certainly in the build trap.

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.

The product managers without Scrum teams or with smaller teams (a UX designer and one developer, for example) help validate and contribute to that strategy for future products.

Tactical work for a product manager focuses on the shorter-term actions of building features and getting them out the door. It includes the daily activities of breaking down and scoping out work with the developers and designers, in addition to crunching the data to determine what to do next.

Strategic work is about positioning the product and the company to win in the market and achieve goals. It looks at the future state of the product and the company and what it will take to get there.

Operational work is about tying the strategy back to the tactical work. Here is where product managers create a roadmap that connects the current state of the product to the future...

The danger is when a product manager is 100% operational, focusing only on the process of shipping products and not on optimizing the feature from a holistic standpoint. When they only optimize for the day-to-day execution of the team, they usually fall behind in the strategy and visioning work that is needed for the success of the features. This is why it’s imperative to push back as much project management effort as possible to the team and trust them to deliver.

Next is a VP of product. Someone in this role oversees the strategy and operations for an entire product line. The VP of product is responsible for connecting the company goals back to the growth of their product line. With inputs from the people on their team and the data they provide, they set the vision and goals for the overall product. 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 features. All the VPs of product in a large company must be aligned in their strategy and purpose, to ensure a successful portfolio of products.

In practice, VPs of product tend to skew either more strategic or more tactical. There are VPs who are great at being a product manager and at doing the work to grow a product themselves. Then there are VPs of product who focus more on the strategy and on figuring out growth plans for the product. A successful VP of product needs to fundamentally be more of a strategic person and to know that, in order to scale their organization, they need to hire in people who take over the tactical and operational components. This also allows them to grow into the role of CPO, which is primarily strategic.

You may notice that there are not 20 people in the organization. Why? When we began breaking the product into value streams and organizing around feature sets that delivered whole value (instead of component areas, like an API), we found that there were not 20 areas. This often happens when teams restructure around value instead of components. They find they do not need as many people to accomplish their goals.

A good strategy is not a plan; it’s a framework that helps you make decisions. Product strategy connects the vision and economic outcomes of the company back to product portfolio, individual product initiatives, and solution options for the teams. Strategy creation is the process of determining the direction of the company and developing the framework in which people make decisions. Strategies are created at each level and then deployed across the organization.

This conflicts with Rumelt’s view, in which a strategy is composed of a diagnosis, guiding principles, *and the plan*. I would therefore frame this as strategic principles or pillars rather than a complete strategy.

When I ask people what their strategy is and they begin reciting their to-do’s, I always ask this follow-up question: “How do you know that this is the right thing to build?” Most of the time, I cannot get a straight answer to that question, or I hear, “I have no idea, but my boss told me to build it.”

Not being one to stop there, I go up a level and ask why the team is building this product. The answers, at this point, become really interesting. They cite market research or the need to have feature parity with competitors, and sometimes the feature is a request (read: mandate) from the CEO. Frequently, I run into another answer that scares me even more: “A large consultancy advised us on what to do.”

We also saw this gap surface with the CTO of Marquetly. He demanded that we lay out every single detail of a not-yet-validated product so that he could feel more certain about what we were doing. A deluge of information isn’t always that helpful for upper management. You need to focus on communicating and asking for just enough information to make a decision.

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. The strategic intents combine to communicate where the company is heading and what it desires to achieve when it gets there. The strategic intent points the team toward the outcomes the businesses wants to achieve.

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.

Instead of sending down mandates, organizations should, instead, turn to aligning every level of the company around the why and should give the next layer down the opportunity to figure out the how and report back. When done this way, product management is successful. 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.

The company was not correctly deploying and creating strategy. The telltale signs were there—​all things Jen picked up on in her first week. The leadership team was prioritizing the work itself, based on what it thought was right to build rather than on feedback from customers. It was reacting to the customers 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.

A good company strategy should be made up of two parts: the operational framework, or how to keep the day-to-day activities of a company moving; and the strategic framework, or how the company realizes the vision through product and service development in the market. Many companies confuse these two frameworks and treat them as one and the same. Although both are important, getting the strategic framework right is essential for developing great products and services.

Strategy deployment is about setting the right level of goals and objectives throughout the organization to narrow the playing field so that teams can act. So, while executives might be looking at a five-year strategy, middle management is thinking in smaller strategies—yearly or quarterly—bounding the teams in a direction that allows them to make decisions on a monthly or weekly basis. When teams are not sufficiently constrained, they become stuck. As Bloom explains: The unconstrained team is the most frightened and scared to act in the organization. They feel like they cannot make a decision because there are too many options. Appropriately constrained teams, ones who have a direction set to the right level for them, feel safe to make decisions because they can see how their stories align to the goals and structure of the organization.

In most product organizations, there should be four major levels in strategy deployment (see Figure 12-1): Vision Strategic intent Product initiatives Options Figure 12-1. Strategy deployment levels The first two are at the company level, whereas the last two are specific to the products or services of the company.