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 while it’s in my head….and before I delete the email in which I decided to capture it.

1) What Problem is Being Solved: The overarching product summary should start with a definition of the problem(s) being solved.  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.  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.

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.

I’m currently running a large development project which is transitioning at the 2/3 mark from waterfall to agile.

Now that I have that out of the way, a little background.  The project was defined in terms of discrete requirements, originally tied together with a few key workflows and wireframes, and involves an n-tier architecture with a number of moving parts.  Though much of the underlying architecture was completed, we weren’t clear enough about the workflows and stories and the project was not producing tangible results fast enough.  So, while we recognize we should have started with agile, the company hadn’t adopted the agile methodology at inception.  To achieve our goal of better predictability and periodic peer review of the software, after it became possible in the corporate environment, we moved to agile.

Note that in the first half of the project, we erred on the side of providing requirements that stopped at the “what,” rather than providing the team enough about the “how.”  The move to agile has exposed that we weren’t providing enough context around each requirement (story) to enable the development team to build the product.  In this case, the complexity of the project and an unfortunate number of unknowns has made it useful for product management to collaborate with user experience well before presenting user stories to the development team, as advocated by others, rather than attempting to involve UX on an “as-needed” basis for each story.  In prior attempts to provide only the agile user story in “As a ___, I need ___ so ____” format, it quickly became apparent that the story wasn’t nearly enough.  We had to deliver the agile user story with the workflow steps (including interaction design) — only that seemed to eliminate enough uncertainty to proceed.

From a higher level, there’s another lesson here that operating under both paradigms has exposed.  It was quickly clear that for a complex system, providing the complete user stories and supporting material (including workflow steps, interaction design and wireframes) enables undesrstanding and fast action.   Though it was in some ways coincidental that we had wireframes before our sprints kicked off, it already appears to have sped things up significantly.

Hopefully the ramp-up will expand as we continue down this path, and we’ll reach the finish line quicker than we might have otherwise.

1) What is your product used for?
2) What are the steps that compose that task, and can any of them be removed?
3) What is the next thing the cusotmer will do after using your product?

Hauptly points out in the book that there are two types of innovation, essentially incremental and wholesale, and this type of three-step process is more applicable to incremental innovations.  The small (incremental) innovaiton is not necessarily less valuable to a company, and it is more likely to be teachable.  By honing one’s focus on the purpose of products and the specific steps of the tasks they enable, attention is being focused on workflows and on looking for opportunities to optimize.

How does one reach life-changing innovation?  Is it the same as incremental, but just a better target for optimization?  Or is it something existential that may only happen to people in a hightened state of mind or with higher skills?  I suppose if I truly knew the answer, I’d be a more successful innovator!  That said, while I think creativity and skill plays a great part in it, innovation is probably not as likely if one doesn’t focus attention on the steps required to accomplish tasks, and the tasks which come before and after a task–which is what this book helps to do.  For communication of that mindset, I find it valuable.