Do You Know Where You Are Headed?

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:

• Product Visioning
• Product Press Release

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:

• The problem of (describe the problem)
• Affects (who are affected by the problem)
• The impact of which is (what is the impact of the problem)
• A successful solution would (list some key benefits of a successful solution)

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.

• What is the problem? Is this a problem you are trying to solve for your customer? Is this a problem you are solving for your company through the creation of a product for a customer?
• Who are affected by the problem? Is it a problem that impacts customers or potential customers? Is this a problem that affects the success of your company?
• What is the impact? If a customer, are they spending too much time and effort to solve the problem? Are they unable to solve the problem at all? If the company, what are the drivers that cause us to want to solve this problem?
• What does a successful solution look like? Is this solving a problem that has never been solved before? Are we solving a problem with better, existing solutions? What are the differentiators that would compel someone to use our solution to the problem?

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?

Product Position

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:

• For (target customer)
• Who (statement of the need or opportunity)
• The (product name) is a (product category)
• That (key benefit, compelling reason to buy)
• Unlike (primary competitive alternative)
• Our product (statement of primary differentiation)

Again, a simple format but one that takes an interesting amount of time and focus to define.

• One of the goals of the product position is to clearly define what differentiates our solution. Why does our solution solve the problem better than existing solutions? Why would our product be picked over some competitor’s product?
• The target customer helps frame up whose problem we’re solving for–often in the form of a persona that describes the role and characteristics of the people for which we’re solving the problem.
• The statement of need really helps tie our product to the problem to being solved.
• The key benefits will often drive a list of features that we intend to deliver in the product that will solve the problem.
• The competitive alternative may be an existing solution in the market, or maybe that no solution exists at all.
• The final item in the product position is stating what makes our product the one to pick. Why is it better than the competition or the existing solutions?

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.

Alignment

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.