Every company competes in a dynamic market. Staying the course is drifting off course. When you don’t use problem statements to express your intent, there are no signals to help your organization stay on course. Your people lack clarity, and therefore make mistakes.
The Jobs of the Problem Statement
This article continues a series on the three critical flaws in most product development processes a problem statement exists to address.
- To deepen shallow product thinking to identify meaningful outcomes.
- To empower product leaders to shape the product strategy through choosing what to do and choosing what not to do.
- To reduce the confusion, delays, and waste teams face as a result of not knowing why something is being asked for and not knowing what good enough looks like.
Let’s dig in to the third challenge – making teams more efficient by making them more effective.
Lack of Purpose
I’ve spent several years doing organizational transformation work for large enterprises. In the early stages of transformation many companies measure improvement in terms of product operations efficiency and predictability. These companies don’t immediately focus on effectiveness, even though their reason for change is to improve effectiveness. This continues to create cognitive dissonance.
Ineffectiveness, inefficiency, and unpredictability are all consequences of a lack of clarity of purpose. Yes there are opportunities to improve engineering practices, team structures, and project management cadences, but the principle benefits will come from removing the waste associated with building the wrong things. That waste comes from not understanding the reasons why to build things.
Lacking clarity of purpose at the individual level is in effect a lack of purpose in aggregate. Product operations is a complex system, not a clockwork manufacturing system, and it manifests emergent properties. Product operations is not a string of assembly operations, product ops is a network of decisions and choices – about designs, about implementation approaches, and about evaluation criteria.
I have learned the best way to convince people about the importance of clarity of purpose is to talk about what happens when it is missing.
We Value Projects Over Products
Historically, product operations were modeled using metaphors of the assembly line. A project is defined (build this, launch that) in pursuit of some outcome. Once the project is defined, everyone – everyone – stops discussing the outcome to focus on the outputs believed to be necessary to deliver the outcome. The project is broken down into progressively smaller deliverables, often all the way down to a task-level decomposition. Thankfully, people stop short of mandating developers use tabs or spaces to indent their code.
There is great comfort for people in limiting their locus of responsibility to only building what they’ve been asked to build. There is no accountability if it doesn’t work – almost always, there is no discussion about outcomes at all. People are freed to operate more fixedly on the task at hand. The people responsible for managing process in this model are not motivated to improve the process, as the consequences of bad decisions are so delayed as to be decoupled from the process itself. Conway’s law drives organizations to limit their definition of ‘improvement’ of the process to increasing efficiency and not effectiveness.
Perhaps there is a meta-problem statement opportunity here (The problem with product ops is…).
Many teams, when adopting agile, scaled agile, or any agile-at-scale operating model, don’t actually change how they make decisions or how they orient to purpose, they only change planning cadences. Rearranging deck chairs on the Titanic. The teams may be committing at the start of a quarter to a fixed subset of deliverables defined at the start of the project, or they may be ‘late binding’ the set of deliverables as each quarter approaches. Discussion of intent is just not present during continued operations, and description of intent is not captured in the artifacts. The recurring planning events are exclusively and myopically a recurring logistics exercise of allocating available capacity towards building the next set of things.
All of these decisions and choices are either made within a context of clear purpose or made outside of one.
External Sources of Change
Teams cannot control when things change – changing external conditions are the reality to which teams must adapt. It is these inescapable changes which break systems lacking in clarity of purpose.
Consider what happens when things change in a system focused on delivering outputs not outcomes.
- Customer desires are constantly changing, but your backlog of features is not. What would have been perfect yesterday is the wrong thing today.
- Competitive offerings are regularly changing, but your backlog of features is not. The criteria which might have defined good enough yesterday, fall short today.
When the backlog is simply a long list of things to be built, there is no language for discussing if the list of things should be changed due to changes in intention. And there is no discussion of intention without the problem statement. Changes in the market conditions (or product strategy) necessitate changes to the problems to be solved, and therefore changes to the list of things to be built.
When there is no clarity of purpose in the system, the consequence of each of these inevitable scenarios are consistent, predictable, and expected.
- Products fail in the market due to disinterest from customers who wanted more.
- Products fail in the market, because customers choose better offerings from competitors.
When the choices about what to build change necessarily because of externalities, the energy and effort of the people on the teams is redirected as the organization collectively gets smarter. The redirection reduces the likelihood of market failure resulting from delivering the wrong product.
You have to change the plan when you change the goal. How will teams know to change the plan when no one knows the goals have changed?
Changes can Cripple or Catalyze
To make the necessary changes, you need something to act as a beacon – to signal that change is needed. This is a use for the problem statement as a key element of the epic. All of the work in your plan traces to the problems you’re trying to solve. There is a cause and effect relationship between what you choose to build and why you choose to build it. When market conditions and product strategy change, you update the problem statement and the changes in planned approach cascade from there. Different work is necessary to pursue a different goal.
Sometimes, you realize that the approach you are taking is unlikely to work – or you simply come up with a better idea. This is the other pattern I see for wanting to change the plan. Even without changing the problem to be solved, the idea of a better approach to solving it will sometimes happen. In this situation you need a new plan even though you still have the same goal.
Remember, executing yesterday’s plan is not the goal – achieving the goal is the goal.
Clarity of purpose is not only important to building coherent plans, it also affects how changes to the plan are perceived and received. Teams experience change differently when they understand the purpose of the work. When there’s alignment and understanding of the problem to be solved, and the problem gets updated, the new information is – in my experience – positively received, and the cascade of changes is understood and accepted. When a better approach to solving the well-understood problem is imagined, the approach is – again, in my experience – evaluated and embraced. The general tone of change is one of improvement in approach. Improving the plan while executing the plan.
When there is no discussion of purpose, from the team’s perspective, suddenly all of their past work and active plans are capriciously discarded and replaced with a new set of orders and an updated project plan. The dissatisfaction associated with unexplained and dictated changes like this can be palpable. The demotivational effect of realizing you are simply an order-taker, and not a problem-solver is crippling.
One approach to changing conditions in this opaque “service provider model” version of product operations, is to ignore the impetus for change, and keep to the original plan. This is the worst-case scenario for the company. The teams continue to execute in blissful ignorance that all of their effort is now wasted – they are doomed to fail, because the product they are building is no longer good enough, and it is destined to fail.
Failure in the market is so distant in time and space from product operations that teams don’t make the connection. In many organizations, the teams building products are not responsible for the effectiveness of the products. The market-failure is “not their fault.”
The other approach in an opaque system is the worst-case scenario for the employees. Someone somewhere in the organization decides that change is needed, and the teams are surprised and disrupted when the entire plan is thrown out the window. It is a chaotic experience, for the old plan to capriciously be replaced by an entirely new plan. This can be cripplingly demotivating for the team, and is a classic pattern on a small scale. The scrum process was even designed to protect the teams from a high frequency of change by not allowing for changes to the sprint backlog within a sprint boundary – creating tiny two-week pockets of perceived safety.
Make the problem statement an explicit part of discussion and decision making. Stop hiding purpose in a dictatorial and opaque feature-factory model of product operations. Embody the problem statement in your epics, so that the traceability of the plan to purpose is explicit, is reinforced, and is regularly considered.
Lack of Purpose Creates Waste
Products cost more than they should due to wasted effort. Teams build things which don’t help solve the problem which needs to be solved. Usually because they’ve been asked to build the things, instead of being asked to solve the problem.
Products which have been built often require rework, because what was asked for was not what was needed. Without defining the problem to be solved, there is no way to critically evaluate the solution approach. In another moment of cognitive dissonance, I continue to see teams willing to estimate the work to deliver something without ever discussing the problem the product needs to solve. How can someone estimate the work to deliver something “good enough” without a definition of “good enough?”
After delivery, either internally or to customers, someone realizes that what was built was not what was needed, and rework ensues – with added expense, opportunity cost, and delay to the product. And delay to solving the problem the product was needed to help solve.
Problem Statements Embody Purpose
The problem statement, in addition to improving thinking about the solvable problems, and the choices about which problems to solve, also directly informs the work of solving the problems. Embody the problem statement in your epic, establish the causal relationships between everything to be built and every reason why to build. Enable the teams to not only gain a sense of purpose in their work, but to embrace changes to the work positively, in pursuit of purpose.
One thought on “Problem Statements Provide Purpose”