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.

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 rewarded 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 pervasive.

To realize the maximum value, organizations need to have the right individuals, the right processes, the right policies, the right strategy, and the right culture.

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. This is a prime example of a company that is optimized for outputs, instead of outcomes.

To be strategic and to have people operate strategically, we need to stop judging teams based on the quantity of features shipped. We should instead define and measure value and then celebrate them for delivering on outcomes for our business and users. Then we should build products that help to achieve this.

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.

Product managers are the key to becoming product-led. Yet so many companies put people without these capabilities into this role.

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.

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

the work required to gather data and prove the solution takes time. This is where people usually become confused between what Agile calls a product owner and a product manager.

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.

If you take your Scrum team away, and Scrum as a process, you are still a product manager. Product management and Scrum can work well together, but product management is not dependent on Scrum. This role should exist with any framework or process, and companies need to understand that in order to set their people up for success.

Most organizations do not give their people the necessary time to do product vision and research work. They would rather hold them responsible for a steady stream of outputs and measure success based on stacking backlogs and writing stories.

With a Scrum team, you might be more focused on the execution of solutions.

Scaled Agile Framework (SAFe) teaches this differently, and I think it’s one of the weakest points in the entire framework.

I’ve trained dozens of teams who are using SAFe, and I have never seen it work well. Although the appeal of having a framework that lays out everything you need to do technology-wise in nice neat boxes sounds appealing, in practice it usually breaks down. The product owners are disconnected from their users and incapable of creating effective solutions because they do not understand the problems well. The product managers are essentially Waterfalling down the requirements, and the teams are not allowed to prove whether these are the right things to build. No one is doing validation work.

After we validate the direction, we create larger Scrum teams around these people and build out solutions. It’s important to have this flexibility in team size, as well, depending on the stage of your product.

Dynamic reteaming & FAST Agile

remind your people to think like product managers. They might be playing the role of a product owner on a Scrum team most days, but you need them to think like a product manager in order to validate that you are building the right things.

product management is not something you can learn in a two-day course, as so many Agile consultancies would like you to believe.

I believe it’s best, as an industry, that we forgo product owner as a title and call everyone in this position a product manager so that there is a consistent and meaningful career path.

To organize teams effectively, you need to balance the coverage and scope of teams with the goals you are trying to achieve.

FAST Agile

products are vehicles for value. So, 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 for value delivery and creation.

Pandora, a subscription music service, is an example of a company that found the constraint of having a small team actually an opportunity for success. They were able to scale to 70 million monthly users with just 40 engineers,1 by ruthlessly prioritizing the work the company was doing

FAST Tribe!

When we’re developing software, we often think of the details and neglect the big picture. What feature can we build? How do we optimize that feature? When will it be delivered? When a company thinks only about the feature-level model, it loses track of the outcomes those features should produce. That is what lands you in the build trap.

The CTO didn’t want a strategy. He wanted a plan.

Good strategy isn’t a detailed plan. It’s a framework that helps you make decisions. Too often, people think of their product strategy as a document made up of a stakeholder’s wish list of features and detailed information on how those wishes should be accomplished.

Communicating the end state of a product is not inherently wrong. You should be striving toward a vision. However, it becomes dangerous when we commit to these visions and lofty feature sets without validation.

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.

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.

Lack of leadership alignment is by far the biggest issue I see standing in the way of successful product management.

One experienced product manager told me, “I keep having leaders tell me to own the vision of my product, but I’m not allowed. My manager keeps handing me solutions. Every time I try to suggest something different, I’m shut down. When we went Agile, we were told that our Scrum teams were supposed to be autonomous. This is definitely not autonomy.”

Luckily, the leadership team of Marquetly had bought in on getting on the same page so that they could be a more powerful organization. “We want to lead the market, we don’t want to play catch-up,” Chris, the CEO, told me. He originally thought the issues were with the development teams. “They aren’t going fast enough, they are slacking off.” Chris was a huge fan of Objectives and Key Results (OKRs) and had implemented them throughout the company, but they were very output-oriented instead of outcome-oriented. “Ship the first version of the new teacher platform,” was how one objective was described. And “Deliver by June 2018” was considered a key result. They weren’t tied to any outcome — either business or user-oriented.

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.

Tying budgeting, strategy, and product development to this artificial yearly time cycle only creates lack of focus and follow-through. Instead, companies should be continuously evaluating where they are and where they need to take action, and then fund those decisions.

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. Executives will get too far into the weeds, managing by authority and not allowing autonomy.

fall in love with the problem you are solving.

The company had rushed into building features for the sake of getting something out the door rather than trying to understand what its customers wanted and needed.

In many companies, it’s difficult — or even impossible — to talk to the customer, usually due to corporate bureaucracy.

“I was told by two separate clients that whatever is built in the first release is an MVP.” 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. Thus, we sacrifice the amount we can learn from it. The most important piece of the MVP is the learning, which is why my definition has always been “the minimum amount of effort to learn.” This keeps us anchored on outcomes rather than outputs. Due to the misconception of this term, I have stopped using MVP altogether. Instead, I talk more about solution experimentation.

There are many ways to experiment to learn. Concierge, Wizard of Oz, and concept testing are three examples of solution experiments,

The team used a technique called story mapping, created by product management veteran and consultant Jeff Patton, to make sure they all understood the work and to prioritize the first release. They then prioritized the work, cutting out a few less-critical components in the first version.

Story mapping and North Star documents are two ways to help teams find alignment around the vision. A North Star document explains the product in a way that can be visualized by the entire team and company. This includes the problem it is solving, the proposed solution, the solution factors that matter for success, and the outcomes the product will result in. North Stars are great for providing context to a wide audience. They should be evolved over time, as you learn more about your product. It’s important to note that this is not an action plan — it does not include how the team will be building the product. That is where story mapping comes in. Story mapping helps teams break down their work and align around goals.

Christa’s team used story mapping to think through all the factors needed to deliver a successful solution. This included breaking down each desired action from the user standpoint. Building understanding as a team helps you develop product faster, which means getting value out to the customers faster.

Building understanding as a team helps you develop product faster, which means getting value out to the customers faster.

You need to always start at that big picture — the North Star — to do this well, though. Otherwise, there is nothing to anchor you, and you end up leading yourself into the build trap.

If you understand the desired outcomes from a strategic perspective, you can use Cost of Delay to help you determine what to ship sooner.

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.

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.

the product roadmap should be updated constantly, especially at the team levels. This is why, at Produx Labs, we call them Living Roadmaps.

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.