What we want from our leaders is for them to set a direction. To inspire us to advance a strategy or realize a vision. What we get too often is dictation, where they tell us what they want us to build. Changing this relationship requires us to change how we interact. As product managers we can change the conversation. Just as you change collaboration patterns through changing how you develop roadmaps, you change the conversation with leaders through how you orient towards supporting them.
I use two characteristics to differentiate giving dictation from setting direction. First, the scope of work has already been defined and the team is being asked to deliver it. This is an order-giver / order-taker pattern. The thinking has been done up-front, and only the doing remains. There’s a not-so-subtle flaw in the first clause, however. The work is never sufficiently defined. Second, there is no invitation to discuss if it is in fact the right work. There are two ways the product manager and team can think about the work. “This is the work we’ve been told to do, so we will do it” which is contrasted with “this is the purpose of the work we’ve been told to do, so we will achieve it.” Is the team given the agency and responsibility to achieve the purpose (usually “solve the problem”), which requires an invitation to discuss the purpose. When there’s no discussion of purpose, there is no setting of direction, there is only dictating.
Note that I never said “solution” even though that is the language I see universally applied in this situation. You cannot have a solution without a problem. You only have work, or deliverables; scope or outputs; things.
The Dictation Cycle
“Build me {this thing}. When can I have it?” Some dictators are benevolent dictators, who care about their people, but who “see the light” and operate with an authoritarian clarity about what needs to be done. They may ask “When can you build me {this thing}?” In my experience in business, people dictating to their teams are usually well-intentioned. I once heard the advice to assume that all of the people you encounter are smart people trying to do the right thing. While I have been proven wrong a few times, this isn’t a discussion about bad actors. This is an exploration about how the nature of this conversation undermines those smart people, and can even prevent them from discovering if what they are requesting is the wrong thing to request. This isn’t about name-calling a leader as a dictator, it is about honestly acknowledging that the dialog is a dictation – orders are given and orders are taken, without more than a superficial interaction.
Dictation feels like micro-management, where the person setting direction is also telling you how to do your job. As a product owner, you would never tell your developers to add a new feature, to write the code in Haskell, to use CamelCase variable names, to indent code with 3 spaces instead of tabs for each line. This is clearly insane. When a leader who is responsible for setting direction tells you what to build, I assert that they are doing your job every bit as much as the product owner (PO) who requires developers to type one-handed.
The framing of a dictation conversation bypasses “Should we build this thing?” and instead teleports to “What is this thing?” and “How should we build this thing?” There is a progression of framing which is healthy – why, what, and how. In dictation, the product manager is uninvited to the ‘why’ conversation, is asked to participate in the ‘what’ conversation with the dictator, and participation in some version of the ‘how’ conversation is complicated because the ‘what’ conversation is always incomplete.
With dictation, there is no ‘why’ conversation involving product managers. The ‘why’ conversation happens behind closed doors or inside a single person’s head. This is a problem, because the double-diamond is a lie. The lie is that our ability to navigate the problem space can be decoupled from our navigation of the solution space. In language we talk about first understanding the problem, and then working to imagine and execute a solution to the problem. The dictator believes they have already navigated the problem space, and are engaging the team to then begin navigating in the solution space.
To quote Will Hass Evans, Author of Designing Resilience, “So neat. So simple. So wrong.” It is through the exploration of possible solution approaches that we truly develop an understanding of the problem. Janson and Smith explore this in their research on design fixation and describe the concept space and configuration space as interdependent, where spending time in each affects your understanding of the other.
Imagining how you would solve a problem changes your understanding of the problem.
When leaders force a decoupling – when their process looks like the double diamond, everyone else is excluded from collaboration. The emergence phase does not happen. The leader doesn’t get to participate, the product manager doesn’t contribute, the rest of the team don’t contribute. It is the act of trying to solve a problem which drives not only an improved understanding of the problem, but the discovery of ways to improve the framing of the problem. This collaboration is the necessary activity to increase the potential value of the work to be undertaken.
The product manager is responsible for shaping the work to be done. The product manager is responsible for increasing the potential value of the work being undertaken, not merely fulfilling orders for deliverables.
Signs of Dictation
Understanding how the system is operating starts with understanding how work gets done, what individuals are expected to do and not do. When sitting with a product manager, I will ask if individual success for them is defined as solving the problem behind a request, or if their performance is assessed in terms of delivering what was requested (on time and on budget, at quality, of course). When success is tied to “did we finish?” the dictation pattern is almost certainly in place. Operational metrics (flow metrics) are typically in place, and “did we finish?” is not a bad question. The problem arises when it is the dominant question. So I continue my exploration with the following:
What should you be willing to spend to deliver this project?
There’s only one reasonable line of reasoning to get to an answer for this question. Some version of “This project is intended to solve that problem, which is worth $X to the company, so we should be willing to spend up to Y% of $X to solve it.” When the product manager can answer this question, and the rest of the team knows where to find the answer to this question, you’re in great shape because you’re not trapped in the dictation antipattern. You’re in a world of delegation if not autonomy, where direction-setting is integral to how work gets done. Based on my experiences over the years, you are unlikely to be in this situation.
What I commonly hear when asking about value is explanations that the team was just told to get it done. It is a mandate, a must-do, or the most important thing to some stakeholder (or their boss). What I regularly hear is people answering this question based on the cost estimate. The project must be done, the team has estimated the cost of doing it, budget has been allocated. So the team should be willing to spend whatever budget was allocated. In a lot of organizations, approaching this question with a frame for economic decision-making is simply a foreign concept.
You should not be willing to spend more to deliver the project than the benefit expected from the project.
When people lack the data, or lack the agency, or lack the safety to have this conversation, this organization is operating in the dictation antipattern. The consequence is a double-whammy; the work takes longer to elaborate and costs more to execute, and the works is less valuable than it could have been.
Shifting the Dialogue
What a lot of teams, and expert project managers, have done is harden the existing process with higher expectations about the state the work should be in before advancing to the next step. These are potential improvements to the flow of the process which fail to address the underlying issues. To improve this situation and break from the dictation antipattern, the organization needs to change to a direction-setting pattern. One of my best early recommendations to product managers who find themselves in this situation is to introduce a coherence check into the conversation with stakeholders.
It isn’t helpful for a product manager to jump up on the table and declare the team won’t work on a project without knowing how much benefit is expected from the project. A product manager is responsible for understanding the value of the project. The product manager needs to provide clarity of purpose to their team. The cool thing is that even in the absence of direction and purpose coming from the stakeholders who asked for the work, the product manager has the ability to create this clarity. I would argue the product manager has the responsibility to create clarity around the benefit, value, or outcome expected for any given body of work.
The common dialog, when responding to dictation, is to ask for clarification. A dictation request comes in to build something, or even to enable something to happen. The clarification questions will feel familiar
- What about this situation, or that situation?
- When scenario 1 happens, how should the system respond?
In the old days, we wrote use cases instead of user stories, to describe how we intended the system to respond to stimulus. This is inside-out thinking. The classic “build it and they will come” failure, Costner movies notwithstanding. All of the clarification questions reinforce the design fixation issue, making it harder to course correct and eliminating opportunities to learn.
Different conversational techniques can be used to get to the underlying purpose. Writing a problem statement is the grown-up version of the toddler’s five whys. In a world of unicorns and rainbows, the project request would come with a problem statement which could be evaluated and improved. The next best thing would be to collaborate to write the problem statement together with the stakeholder as part of reviewing the project request. What most product managers have to do – at least initially – is attempt to write a problem statement on their own.
This is where product managers need to understand how the business runs. The product manager will leverage their understanding of the mechanisms of value creation to reverse engineer the project by asking “and then what happens?” Attempting to populate the four fields of a good problem statement template is a fantastic prompt for the necessary critical thinking.
The Problem of…
Affects Whom…
The Impact of Which is…
The Benefits of a Solution are…
The first two fields, describing the framing of the problem and who it affects, are really effective focusing lenses. Attempting to answer the economic questions is where the coherence check comes to life. By quantifying how much value the project is trying to capture, as well as how much potential value exists (by quantifying the impact of the unaddressed problem), you gain so much insight into the potential outcome. Even being able to have a dialog about trying to solve the totality of a problem, or addressing part of the problem incrementally – this is a compelling realization.
This is a critical element of the emergence portion of understanding problems and solutions. There is now a frame for understanding the project. “If” that is the scope, what is the potential benefit? You now have an approach to matching the scope of the work with the (unexpressed) level of ambition underlying the project. You can have a dialog to make sure they match. You are connecting a couple things.
- Your belief about the outcome a project will yield, given an understanding of the scope of work.
- Your belief about the mechanism of value creation, through which a scope of work will yield value.
- Your stakeholder’s belief about intended outcomes with your belief about expected outcomes.
Coherence
This is where coherence comes into play. By comparing your expected outcome with the stakeholder’s intended outcome, you can see where there is misalignment and how to address it. It may be that the stakeholder has a different understanding of how value is created. This is great – you get a better understanding, refining your beliefs. You update your expression of the expected outcome, in the ‘benefits of a solution’ field. Now the entire team can align to this updated belief.
It may be that the stakeholder, with a bigger picture view, is informed with an improved appreciation of how the scope associated with the project is likely to lead to a different level of value than what they intended. The project might deliver more than they intended – allowing them to refine to a smaller project without undermining their original intent. It may be that the project – the implementation originally defined – will fall short of the intended outcome. What the product manager brings to bear is a deeper understanding of the specific mechanism of value creation being potentially exercised. Combining this depth of insight with the breadth of perspective of the stakeholder allows the two together to collaborate to reshape. This reshaping can both alter an understanding of the problem and alter the imagining of a solution approach.
Conclusion
This coherence, matching scope to ambition, refines the shared understanding of the underlying problem through simultaneous exploration of the problem and the solution. This coherence provides better clarity of purpose to the team, useful to inform decisions during execution. This coherence provides clarity of purpose to the stakeholder, who can now express prioritization, selection, and sequencing desires against an economic frame. Both of these changes lead to an increase in the potential value of the work being done. Both of these changes lead to an increase in value realization which results from the work.
