The Product Management Vacuum and the Three Vs
The thing about any vacuum is that it has an innate need to be filled.
If you are not careful, the Product Management Vacuum will get filled with meaningless busy work and extensive task management, often guided by project metrics as described earlier. All the layers of budgeting, project charters, handoffs, and tasks breakdown mask the true intention of the initiative. You run the risk of being busy without a clear direction.
The bigger the vacuum:
the more disconnected the technology groups are from the business;
the less engaged the people on the ground become;
the more reliance there is on project and task management;
the more hierarchies and handoffs emerge;
the more complexity is introduced;
the harder it is to shift directions when the business climate changes;
the more “busy work” is created;
the more waste and rework occurs; and
the less value is delivered to customers.
True product management is about embodying agility throughout the whole organization from the top down to the bottom and thereby filling the Product Management Vacuum. Done right, this creates a true competitive advantage.
Figure 1-5 The three Vs
Figure 1-6 How Vision, Value, and Validation fill the Product Management Vacuum
Let’s take a brief look at each of the Vs.
Vision creates Transparency.
The successful Product Owner establishes a clear product vision for her team, much like a military commander establishes clear intent for his subordinates. Doing so allows subordinates to act without direct orders if necessary to carry out the commander’s intent.
From the book Auftragstaktik: The Basis for Modern Military Command? by Major Michael J. Gunther:
The use of mission tactics [Auftragstaktik] allow[s] subordinate commanders . . . to interpret how best to achieve the commander’s intent based upon their understanding of the tactical situation. . . . The success of the doctrine rests upon the recipient of orders understanding the intent of the issuer and acting to achieve the goal even if their actions violate other guidance or orders they have received.1
Self-organization does not just happen. Much like in the military, the two main ingredients are shared vision and clear boundaries.
In the context of product development, the boundaries are provided by Scrum and the vision is provided through the Product Owner’s strong leadership and communication.
The product vision anchors everything in the process. This vision creates transparency because it forms the basis for all following conversations, leading to a common understanding for why you are building the product and what your customers’ needs are. According to Richard Hackman, 30 percent of a team’s success depends on how it was launched.2 A great and well-communicated vision is paramount for a successful launch.
You need to communicate the product vision again and again to keep everyone on board and honest. Never forget that this vision represents the voice of the customer. If you stop listening to your customers, the resulting product will be of less value or even alienate them.
Making the connection to the product’s (or even the organization’s) vision helps team members make goal-driven commitments and feel like they are a part of something bigger than themselves. So how do you create a clear vision? Techniques are explored in Chapter 2, “Vision.”
Defining value provides you with something to Inspect.
Imagine the vision as a long thread. Value is the individual pearls you attach as you progress. Vision provides a foundation and direction, but without the pearls attached to it, there is no value. A Scrum Team’s job is to identify and then attach pearls (value) to the thread (vision).
The first pearl could be either a large business initiative or a smaller distinct feature. Aim for the most valuable item first and attach it completely before moving on to the next one. In other words, always be in a position to deliver value.
“If you could have only one thing, what would it be?” is often a good opening question when identifying the most valuable.
If everything is important, then nothing is.
Once you get this answer, often after persistent digging, try to truly understand the other person’s view; try to grasp the underlying why. You might even go so far as to question the product’s utility. Eventually, when you have narrowed it down and are convinced, go ahead and define how the value will manifest. Would a process take fewer clicks? How many? Will the behavior of a user change? How? Will a transaction be faster? How much faster? You need to provide more leadership than simply saying “let’s do this!” If you are not able to quantify success or to prove the realization of value, then the chances of being on the wrong track are rather high. Do not forget that the only real proof, though, is through the customer. Everything before is nothing but a hypothesis.
So how do you measure value? Techniques are explored in Chapter 3, “Value.”
Validation causes Adaptation.
Most business assumptions are plainly wrong.4 They look good on paper but do not hold up in the real world. Each valuable idea has to be validated as soon as possible. One place this is done in Scrum is the Sprint Review. The Sprint Review is the chance for all stakeholders to review the current state of the product and to get an insight into next steps. The closer the reviewers are to actual customers and the closer the Increment is to being released, the more realistic the feedback and subsequent adaptations.
Even if the Sprint Reviews go well and everyone seems happy, you still do not have true validation until the product or feature is in production and used. In Scrum, “Done” means the Increment is potentially releasable. However, to have ultimate validation and reduce the overall product risk, you need to establish a feedback loop with the marketplace. For this you need to release as frequently as the business can support.
The two core feedback loops in Scrum are on the process side and the product side:
Process validation is about inspecting and adapting how the Scrum Team is working.
Product validation is about inspecting and adapting what the Scrum Team is building.
Validation in the context of product management and the three Vs is about the latter: product validation.
Chapter 4, “Validation,” describes this in more detail.