There is a saying that goes something like this: If you don’t know where you’re going, any road will get you there.
When we create new products or add new capabilities to an existing product, we typically do so in an effort to solve a problem. These product updates may often happen by delivery teams being told to go build these features without a clear understanding of the problem being solved. There is a lack of context. I expect this is why we see results noted in the Chaos Report where up to 64% of software features are rarely or never used. Here’s an example:
The context that is often missing is the problem; what we are trying to solve? This lack of context is likely a breakdown in communication between stakeholders and the delivery team. Why is it so important that the delivery teams have a clear understanding of the problem being solved? Delivery teams are made up of people that have years of experience building products and solving problems. We need to tap into this body of knowledge and experience to help us solve problems in better and more simple ways.
Bridging The Gap
What we need is a way to bridge the gap in understanding–some way of providing a clear context for the problem to be solved. There are many approaches we can use, but a couple that I have found to be effective include:
A product vision, in the way I define it, has two parts. The first is framing up a clear understanding of the problem to be solved. The second is the product position. (I’ll cover the Product Press Release in an upcoming post.)
Product Problem Statement
The format that I have used is adapted from Crossing the Chasm, by Geoffrey Moore:
Very concise, right? That being said it is interesting to me at how long it takes to distill a problem statement into this simple format.
Here is an example of a problem statement for making person to person electronic payments:
If you were on a team that is solving this problem, would this problem statement provide context?
The product position is an optional element of the product vision but one that can be worthwhile to define. The format of the product position is:
Again, a simple format but one that takes an interesting amount of time and focus to define.
Here is an example of a product position for the problem statement we saw earlier:
The product position may appear to be duplicative to the problem statement, but I believe there is value in creating both; especially to help frame up the scope of what we intend to solve. Those key benefits really help us focus on the minimally marketable features and eliminate unneeded capabilities.
I have found the product vision to be very effective in setting a context for teams. Understanding the problem we are solving for is super important and helps to create alignment. Not having this clarity creates risk in that teams may not align, and they do not focus on delivering the simplest solution to the problem. In larger enterprises that have many delivery teams working in concert, this alignment becomes even more important.
Having a clear understanding of where we are headed makes it much easier for your teams to navigate to the final destination.Follow @kelly_waters