On Bureaucrats and Product Failure
The story of product stifled by process
Here’s a typical scenario in many early-stage startups.
A small-to-medium sized company has only one product team. Sometimes that also includes product design and engineering. Occasionally they are separate from engineering. Design sometimes doesn’t exist.
All product planning and decision making is centralized. Even in environments where the team does its own planning, either the product lead or a senior engineer calls the shots. Prioritization is an exercise in convoluted framework exhaustion, with much decided by consensus until overruled from above.
The team is doing an exceptionally rigid version of Scrum, but in the process performing Waterfall-style product development. Specs are handed down from function to function, and feedback loops are slow. Strategic interaction is irregular. Although there are daily standups, they operate as status reports, so little strategizing happens. That usually comes once every 3 months, if at all.
Shipping is hard, slow, cumbersome, and often results in a lack of adoption. This steers it in the direction of fulfilling every customer desire, but the org takes months to ship even the simplest of optimizations or improvements. Rudderless in the storm, the product grows feature bloat, and slowly but surely becomes unusable. There is no concept other than obeying the customer.
RANDOM THOUGHT #1
What Do Customers Know?
The truth is — more than some product folks like to admit. But as product people, we have the luxury of examining all the possible solutions. It’s our job to understand the diversity of options. That gives us a critical advantage.
While listening to customer desires is vitally important, working out how to solve the underlying problem they themselves are seeking to overcome in a novel, unexpected way that perhaps additionally solves an adjacent problem — that’s when the “wow” factor of great product management converts even the B2C skeptics or B2B saboteurs.
Because we created value.
The unusable product causes churn. Revenue is lost, cash position threatened, and burn rates are high. The product has failed. The business is on the verge of collapse. What to do?
What I’ve observed many companies do immediately after that is — rationalize. They let go of some staff, cut down on cost, and restructure their organization.
They break out their large centralized product, engineering, and design team into several product teams. They all start doing Scrum individually. Everyone owns features or product areas. No one is clear on what their product outcome is supposed to be.
The increase in focus for smaller groups of people produces initial results.
Teams coalesce around domains. They are able to move faster and make decisions more quickly. They feel free to experiment, which they do. Some of these experiments work better than others.
RANDOM THOUGHT #2
Experiments without Experimentation
New product teams often engage in experiments — once. But if they lack the appropriate training and guidance, their experiments are prone to failure. Hypothesis-driven experimentation is part of science and demands relative rigor. Failure leads many teams to give up after one go.
While we can often simplify how we approach experiments, one thing must always be true — and that is continued experimentation. We must keep trying and learning until we get it right. Or at least get close enough.
For teams that experience failure and give up on experimentation as an approach, it can be hard to bounce back. And some will give up.
The org gives up on the attempt altogether. Teams are no longer encouraged to experiment.
What Happened Here?
What we are talking about is not a mere feature factory. It is a process-driven environment governed by ruling bureaucrats on multiple levels of the corporate and product hierarchy.
Centralizing a product org means consolidating power and decision-making ability on the top. Bottom-down input may be heard and sometimes considered, but the design of the organization makes it easier to flow information downstream. This creates a communication imbalance.
Rigid interpretations of various development frameworks and methodologies stifles innovation, as it overfocuses product teams on the process of development instead of the product.
Bureaucrats introduce administrative hurdles, as the direct outgrowth of process is documenting process and introducing process steps, checks, gates, and unavoidable approvals.
In a struggling org, everything demands approval, thereby slowing down movement and making teams sluggish and unable to quickly solve problems. Teams become less responsive, which in turn creates frustrated customers.
It’s a snowball effect that can be hard to stop from swallowing the entire organization.
Light at the End of the Tunnel
But there is a way out of this situation. It requires some radical changes to an org, but above all — collaboration.
The organization needs to collect all knowledge, research, insight, opinions, questions, problems, and ideas and analyze, structure, and categorize them. This can be done through a series of workshops and interviews that result in a summary of the data.
This summary (and ideally visualization) of the findings should be shared with the entire organization. Findings can also be shared progressively as the research continues.
At one point, functional leaders and most senior individual contributors in all departments should come together and discuss how to transform their findings into a product strategy.
They will agree on a hypothesis about the overarching problem they are trying to solve — a unique business problem.
They will then transform that into a product outcome they need to generate in order to solve that problem. They’ll agree on a way to measure success on that product outcome beyond a binary “achieved/not achieved.”
They’ll break that down into a series of bets:
We bet that by doing [this], we will achieve [outcome], because [condition or situation].
A talent management system:
“We bet that by enabling users to filter their candidate management view by location, we will achieve greater daily usage of the view, because our users need to confirm applicable candidates in locations where they are looking to hire.”
A travel booking site:
“We bet that by decreasing the latency of our search page by 10ms, we will achieve a booking conversion rate (BCR) uptick of +5pp over a 28-day period, because we observe lower BCR during latency spikes.”
Teams will co-design the bets and own one each, at the beginning. They will engage in product discovery activities to try to validate the problem and prove the hypothesis behind the bet.
They will rally around this singular goal. By focusing on one problem at a time, teams become serial success creators.
ON BUREAUCRACY
The German sociologist Max Weber (1864-1920) argued that bureaucracy constitutes the most efficient and rational way in which human activity can be organized and that systematic processes and organized hierarchies are necessary to maintain order, to maximize efficiency, and to eliminate favoritism. On the other hand, Weber also saw unfettered bureaucracy as a threat to individual freedom, with the potential of trapping individuals in an impersonal "iron cage" of rule-based, rational control.
(Source: Wikipedia)
How Did We Get Here?
What we’ve actually done is remove layers of bureaucracy by decentralizing the product org into discrete teams, all with a unique outcome of their own to pursue. We’ve moved decision-making into the domain of actual, on-the-ground expertise.
Through a shared planning process, we’ve created common ground. By involving everyone equally, we’ve distributed power, shared knowledge, and engendered a renewed sense of ownership, and hopefully ambition and drive.
This approach drives teams to succeed. It empowers teams by enabling individuals and giving them space to experiment, but within boundaries, and with a clear goal in sight.
Process is differentiated and made much smaller, and therefore less overwhelming. Distributed decision-making makes it easier to simplify process, particularly in smaller groups.
Any framework or methodology will do as long as these basic conditions are met.
The rest is up to you.