Your process can prevent collaboration. The language you use in your problem statements can stop collaboration too. When you use proxy variables instead of economic measures of outcome you prevent your teams from collaborating and you reduce the likelihood of achieving product success.
This article is the second in a three-part deeper-dive on the importance of using economic measures when writing the problem statements which are the key unit of shaping and operationalizing a product strategy.
- Undermining Your Ability to Prioritize Your Portfolio
- Stunting Collaboration which Undermines Your Effectiveness (this article)
- Mismatching Your Scope of Effort with Your Level of Ambition
Collaboration, Commitment, and Consequences
To imagine and execute a successful product you have to identify and deliver the right things to build to realize your desired outcome. You create outputs in hopes of creating outcomes. You control the outputs you choose to create but you only influence the outcomes you achieve. You will develop two hypotheses to stitch the red thread from outputs to outcomes – the solution hypothesis and the outcome hypothesis.
The solution hypothesis is the one closest to the outputs and the easiest one for teams to start thinking through, using a couple simple questions. Start with one output you plan to build. This could be a new or improved capability, product feature, product, service, marketing copy, imagery, etc. Any THING you invest to create or improve. The first question is “Why do we need this THING?” The reason is consistently to address a particular need. The NEED, or proximate problem, is fairly self-evident. “We need to update the database to track product pairings because without the change we don’t know which products are sold together.” “We need to add a safety switch to the treadmill so that it stops immediately if someone falls.”
So far this is only an assumption, you need more to develop it into a disprovable hypothesis. This is done through the next question – “How will you know if it worked?” Or more formally, what do you expect to observe which indicates you’ve sufficiently addressed the NEED? There is an OBSERVABLE CHANGE which you would expect to see as a result of addressing the NEED by correctly building the THING. This is your solution hypothesis.
This OBSERVABLE CHANGE is not, however, an outcome. You still have to make another jump. It is not an outcome because it is not an economic benefit to the company. The change is a consequence of having addressed a need by building a thing. The OBSERVABLE CHANGE is a leading indicator of an OUTCOME – there is a second assumption – achieving this particular change will lead to the desired outcome. This is your outcome hypothesis.
You must treat these as hypotheses, because there is uncertainty within each assumption. Will the THING you build sufficiently address the NEED? Are you addressing the right NEED to the right degree to achieve the OBSERVABLE CHANGE? Will causing or enabling that OBSERVABLE CHANGE lead to the desired OUTCOME?
Language Anchors
With this model there are three key conceptual attractors for collaboration
- The THINGS you build
- The OBSERVABLE CHANGES you strive to create
- The OUTCOMES you hope to realize.
In James Gleick’s The Information, I was introduced to a key concept – the languages people use to communicate influences the nature of their thinking. The expressiveness of a language and the concepts within the language both influence what you can think. I believe this extends to organizations and how communication and collaboration happen. Every organization I’ve worked with has a process focusing operationally on one of these three attractors; THINGS, OBSERVABLE CHANGES, or OUTCOMES. This choice of focus starts for people with the language in problem statements. Teams stick with this choice as they operationalize the creation of products. The language which teams use determines everything; the concepts of success and effectiveness, the definitions of done, and the sense of purpose people embrace.
The three different operational patterns
- The Builders of Things pattern – when your team fixates on the THINGS they have decided to build.
- The Makers of Change pattern – when your team focuses on the OBSERVABLE CHANGES as the driver of choice of which THINGS to build.
- The Creators of Value pattern – when your team aligns their purpose to the desired OUTCOME which they hope to achieve through creating OBSERVABLE CHANGES.
It is important in any system to establish clarity of purpose for your teams. You can establish clarity of purpose using any of these three languages – one choice is bad, one is not good enough, and one is good. Operating as Builders of Things is a problem for a number of reasons – I want to focus right now on the reason why the Makers of Change pattern is problematic.
Constraints
The concept you use to describe your purpose (the outcome, the change, or the things) is the concept you use to collaborate and ideate. Builders of things are given a list of things to do. Presence (or absence) on the list is effectively fixed. Teams are not equipped, not empowered, and not expected to question the scope of work they have been given. The benefit to the teams is in their lack of accountability for the consequences of what they built. The hidden cost for these teams is that they are unable to influence the effectiveness of their products for their customers or their employer. They are uninvolved. The process drives execution against the list and erects barriers to improving the list.
Collaboration is constrained to discussing the best way to do the things, from planning to designing to delivering. The team’s talents go untapped.
While the OBSERVABLE CHANGE is the expected result of the solution hypothesis, it is the only the input to the outcome hypothesis. The OBSERVABLE CHANGE is a leading indicator of the desired outcome, the outcome is not assured. In the Makers of Change pattern, teams have advance beyond the list of outputs and fully embrace the perspective of operating within a solution hypothesis. This shift from what they can control to what they can only influence (the targeted changes) is a great one. Engineers make things because they want to help people and solve problems. The solution hypothesis encapsulates the proximate problem or need which must be addressed to cause change.
When you use proxy variables in your problem statement, you are using the language of change but not the language of outcomes. The language of change empowers your team to explore solution approaches to deliver on the solution hypothesis. The team is unfortunately not invited to participate in the decision about which changes are required.
Barry Staw first explored the cognitive bias known as Commitment Bias where people struggle to deviate from previous commitments even when they know the commitments should be changed. With a problem statement using the language of change, your frame for commitment is to achieve the change. Even if you get smarter along the way and realize either more or less – or an entirely different – change would be better. If you start with an effort to achieve a higher conversion rate, and later realize you should be trying to create a larger average transaction amount instead, the commitment bias makes it hard to make that change.
Where I’ve seen this happen in organizations is where product people act as order-givers, directing the teams towards creating changes in a “build it and they will come” type pattern. There can be cross-functional collaboration about different approaches to achieving a desired change, but again – no collaboration to refine the thinking on desired changes. Without making space to consider the possibility that a different change is needed, the system operationally will not explore the possibility.
The underlying concept is simple – at the start of a project, you don’t know what the right approach to achieving success might be. This is why you should develop hypotheses. This is important not only for describing your understanding of cause and effect, but to make it possible to question that underlying causality. Without questioning, there is no possibility of learning. Without learning, there is no possibility of course correcting. Without course correcting, there is no possibility of improving the odds of succeeding.
Conclusion
The ability to collaborate on the approach to achieving the desired change of the solution hypothesis is necessary to improve the odds of success. The ability to collaborate on the approach to achieving the desired outcome of the outcome hypothesis is necessary to further improve the likelihood of success. When you are anchored in a language which biases you away from exploring either hypothesis you are limiting your ability to deliver a successful product.
The language which permeates operations starts with the problem statement. You need to use economic measures to describe the problems and benefits which come from addressing them in order to propagate the orientation throughout the organization. This is what best positions you for product success.
