*This post was written in 2010 and significantly appended in December, 2014.

Recent work on business plans and business cases refocused me on the need to document for a wide audience the purpose and design of a product, within the context of how it would be delivered to market and how it would prove profitable.  As I reflected upon this, it occurred to me that a concise package could be assembled that delivers all the information needed to evaluate a product.

How do you describe a product, before it exists?

When someone on your team asks what you’re trying to achieve, what do you say? When a business leader in another part of the organization says he/she likes what your product looks like and how it functions, but doesn’t really understand its purpose, what do you say?

When someone understands the product’s goal, but you want to quickly review how it will fulfill its value proposition, do you have a document or set of documents you can quickly reference to answer these questions?

I’m sure someone has thought of this before, and there’s probably a formal name for it, but I thought I’d document it because it seems pretty useful.

Looking back on it in the year 2014, the set of artifacts I identified map pretty well to Roman Pichler’s Product Canvas. Pichler’s model includes three of the four items:

  • the product goal, which correlates to what I called the problem being solved,
  • target personas that will be using the system.
  • the sprint goals, which could map to the workflows that must be supported by the product.

The only thing I listed that isn’t explicitly called out by Pichler is the value proposition. I view the value proposition as part of positioning (post coming soon!)–one of the key drivers of product requirements and of product messaging.  As I write this in late 2014, I now believe that one shouldn’t be building a product without knowing how it will win against the competition.

And now for my original list:

1) What Problem is Being Solved: The overarching product summary should start with a definition of the problem(s) being solved.  Note, this is often identified in the early stages when conducting an opportunity assessment. From this definition, anyone reading this package can evaluate whether the proposed solution addresses the problem or problems stated.  Much expense can be saved by not delivering a solution to market that doesn’t address the intended problem.

2) Buyer and User Personas: Who is the primary user for whom a product is to be built, and who is the buyer actually responsible for the decision to purchase?  Often times these are not the same people–a proper user persona can identify the user’s tendencies and the typical person who will be using the product, whereas a buyer persona can help to keep the buyer’s motivations in mind.

3) Value Proposition: A succinct explanation of how the product can provide tangible, financial benefit to the user.  One method is to show the value of the time saved by elimination of manual steps, which can show the value of efficiency.  Increased revenue may be harder to validate, but using reasonable estimates can help to show the exact amount of value that a user will obtain by using the product.  This evaluation is helpful when it comes to pricing the product for the market, and should take into account how the solution solves the stated problem for the buyer and users defined above.

4) Solution Workflows: For a software product, no presentation of the proposed product is complete without a robust set of wireframes weaved together with a good story.  User Flows are a key component of the product’s user experience, and paint a picture of how the product is expected to work.  Packaging this all together helps answer “what are we building, exactly?” and helps build the case that the solution proposed is indeed the best one, for the conditions in items one and two above.

RELATED:  Lessons from 'Crossing the Chasm'

There are other items packaged in a business case — in particular, one that comes to mind is a pricing proposal — but the items listed here are enough to deliver to business people within a large software company to make the case that a particular product is solving a real market need for real users, and to explain exactly what product is proposed to meet that need.