Watch out for the Build Trap!
What is it? The symptom is simple: doing tons of work but unclear about WHY.
The team keeps themselves busy with new requirements. They are clear about how many hours of work were tracked, how many files were created, how many iterations, new releases, new functions, user stories, or tickets were completed. But — — after the launch, they are clueless about what to measure and can’t confidently answer how the functions are contributing to the big business goals.
I believe most of you are super busy. However, at the end of the day, did you ask yourself: WHY? What’s it for? Do you have a clear answer? What users’ problems are you solving? What business benefit can this solution bring?
If you don’t have a clear answer to why it matters to users and businesses. You need to watch out not to fall into the Build Trap.
Background info
“Build Trap” is a concept from the book called “Escaping the Build Trap: How Effective Product Management Creates Real Value” written by Melissa Perri.
“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. ”
— — Melissa Perri
How to get out of Build Trap? The answer is a product-led organization. Yes, not just you, or a product team, but the whole organization level to address.
How the company is evaluating the employees’ performance and giving bonuses? How the company is doing the yearly budget planning and asking team leaders to submit the project plan? Those organizational approaches are fundamental and decisive. The wrong company culture and setup will inevitably drag the team into the build trap.
The book breaks the how into 4 parts: Role, Strategy, Process, and Organization.
Role
From a Product Manager to Chief Product Officer, it is a career path from an individual perspective, but also a way to form a proper product team from an organizational perspective. Each role has its own responsibilities, with different percentages of Tactical, Operational, and Strategic work as shown below.
The executive team focus on strategy, defining overall directions; while the PMs work closely with designers and engineers to plan under the strategic constraints and take actions to work on solutions, and adjust autonomously based on the user’s feedback and business outcome for a better fit solution.
Clear definition and separation of strategic and tactical work is the way to make your team happy and feel autonomous.
What is & What is not
- Vs. UX designer: User experience is only one piece of building a great product. The other parts PMs need to cover are the value propositions, the business model, the pricing and the integrations, etc.
- Vs. Product Owner in Agile/scrum: POs typically define and prioritize the backlog, and accept the completed user stories. If a PO spends so much time on “user stories”, does he or she have time to think about “if we are building the right product”, “how to measure the success of our products in the market”? And questions “how do we price and package our product?”, “how do we bring our product to different markets?” are completely out of scrum POs’ radar.
- Vs. Project manager: Project managers are responsible for the when. When will a project finish? Will we hit our deadline? Product managers are responsible for the why? Why are we building this?
Strategy
There should be four major levels in strategy deployment
- Vision
- Strategic intent
- Product initiatives
- Options
You can view the four levels as a big tree, a way how the entire organization connects in a system and grows organically towards one direction: the company vision.
Vision and Strategy are at the company level and long term, whereas Product initiatives and Options are specific to individual products, in short term like project based or even sprint based.
But the key is to have the 4 levels working together. Even for a small project, the project team should be able to see the path from their work all the way to company vision, how the value they are delivering can contribute to the overall business. So the team can set the right priority and evaluate autonomously. The vision is the “North Star” guiding the team. That’s the balance of being autonomous and having appropriate constraints.
At different levels of organizations, we tell stories with different scales of time (timespans), about our work and why we are doing it. …Agile teams are really good at telling two- to four-week stories. That’s what they deal with on a daily basis. As you go up in the organization, you tell stories with longer timespans. Executives are really good at telling five-year stories, but a team cannot act on a five-year story when they’re used to thinking in two to four weeks.
— — Jabe Bloom
It is about work split, telling the same story in different time spans and heading towards the same direction throughout the organization. From the table below, you can also see who is responsible for answering what questions.
Another key is making things measurable. You should define key outcomes to measure Strategy intents, e.g. “Increase revenue from $5 million a year to $60 million a year in three years”. When defining the Product initiatives, the team should also make an estimation of the expected KPIs.
The example in the book is as followed:
- Strategic intent: double revenue growth from individual users.
- Key outcome: increase revenue growth from 15% to 30% from individual users
- Product initiatives 01: We believe that by increasing the amount of content in key areas of interest, we can acquire more individual users and retain existing users, resulting in a potential revenue increase of $ xxx
- Product initiatives 02: We believe that by creating a way for students to prove their skills to employers, we can increase acquisition, resulting in a revenue increase of $ xxx
Strategy can be a pretty intricate system. If you don’t have a strategy yet, it is not possible to just have a 2 or 3 day workshop and suddenly have a strategy in place. It is the most important task for the leadership team to architect and embed in the organization.
Process
This chapter collects and explains some interesting tools, frameworks and concepts useful to structure the work process.
Melissa introduced “Product Kata” as the overarching process. She borrowed the name “Kata” from Toyota’s Continuous Improvement framework.
The first 3 steps are part of Strategy creation & deployment. For Direction setting & evaluation→ Two common product metrics measures:
- Pirate Metrics （by Dave McClure）
- HEART metrics.（by Kerry Rodden from Google）
The 4th step is Execution, including:
- Problem Exploration → Generative research, talk with real users, to find the problem you want to solve
- Solution Exploration → Ways to experiment and simulate the solutions without high cost to build, like: Prototyping, Concierge, Wizard of Oz
- Solution Optimization→ Tools/frameworks to help prioritization
Organization
Product teams want to experiment and iterate and sales teams need to have a confirmed version to promise clients. Defining a clear roadmap and phase definition as followed can help solve potential conflicts.
Four phases/stages of a product:
- Experiment: This phase is to understand the problem and to determine whether it’s worth solving. Teams in this phase are conducting problem exploration and solution exploration activities. No production code is being created.
- Alpha: This phase is to determine whether the solution is desirable to the customers. This is a minimum feature set or a robust solution experiment, but built in production code and live for a small set of users.
- Beta: This phase is to determine whether the solution is scalable, from a technical standpoint. Although not always needed, this is a good phase to reduce risk. This release is available to more customers than the Alpha phase, but is still only a smaller subset of the entire population, since we are still testing.
- Generally Available (GA): This phase means that the solution is widely available to all of our clients. Sales teams can talk openly about GA products and can sell as much as possible to the target market.
In this chapter, Melissa also dives into Incentives, Risk management and Budgeting. Those are decisive aspects to shape the company core culture and operation model. Worthwhile for you to read and reflect if you are already in a product-led organization, or actions are needed to take your team and company out of the Build Trap!
