Document Your MVP for a Developer

I was talking with an early-stage founder who has a product vision and wants to get a Minimum Viable Product (MVP) built.  He is not a technical person, but is somewhat web savvy.  He wanted to get input from me on what he's doing, and he wants to begin to ask developers what it would take to build his product.  I asked some of the same questions I ask in my Free Startup CTO Consulting Sessions and then I get to a very common conversation:

Me:  Do you have specs?
Founder:  Ummm ... <embarrased look> ... what do you mean?
Me:  Product definition, use cases, feature list, wireframes, comps, really whatever you have.
Founder:  Umm ... <still embarrassed> ... what format would you and the developer want that in? 

I'm never trying to embarrass someone.  I know how it feels.  It's the same as when I've created financial models and then have it reviewed by a hard-core CFO, sophisticated investor or similar kind of expert.  And in the case of defining mobile/web/software, there is even more variability in terms of form and format.
So, I promised this founder to do a post talking about how you go about create specifications of your MVP.

First Relax

Before you begin reading all of the stuff below, it's going to be new, different, confusing.  You likely are writing your first one of these.  Don't stress over format.  Don't stress if you are doing it right. 
This should be an iterative process with advisors and customers providing feedback on the product. 
Conversations with a technical advisors or possible developers should be iterative. 
In fact, let me provide an important warning:

If you create these documents, don't have input from a technical resource, take it to a development shop and they provide you a price.  Go find a new technical resource. 

So, just get down what you can in a form that works for you.  I don't expect you to provide all of these things.  Part of what I like to find out is where you are relative to capturing these things.

Business Concept

The key first part of the conversation with a developer is having a good capture of the business more broadly.  The  business canvas model is a good short list.  Or you can have a pitch deck.   You might also have a business plan, marketing plan, financials, competitor analysis or other kinds of background document.
Ideally you are also able to say what you are really trying to prove to get to the next level.  For example, if you are trying to determine viral coefficient (see Startup Metrics), then the focus should be around those aspects of the MVP.  It's important to know where the business is today and what you are really trying to achieve.
Quite often these things get old quickly.  It's fine to send out documents that have older information.  Just make note of it in the document and/or in an email when you send it.  Seeing the evolution of thinking is not a bad thing.

Customer Development Notes

I'm assuming founders are having customer development conversations.  It would be great to get notes and summaries from these.  See also: 12 Tips for Early Customer Development Interviews, 12 tips for customer development, tips for customer development.

Prioritized User Stories

Define the customer problems and beginnings of the solution through user stories (see user stories, user story).  Prioritize these stories.
Examples:

• http://www.westborosystems.com/2010/02/user-story-examples/
• http://en.wikipedia.org/wiki/User_story#Examples

Product Feature List

Create a prioritized high level product feature list (see Product Backlog).  Make sure you look at 32 Questions Developers Should Ask a Startup Founder to spark possible additional features.  Make sure you keep focused on your key business drivers and prioritize the features aggressively based on those drivers.
Examples:

• http://www.mountaingoatsoftware.com/scrum/product-backlog-example/
• http://epf.eclipse.org/wikis/scrumpt/Scrum/guidances/examples/example_product_backlog_B6A03674.html

Functional Details

For the higher priority features, begin to capture additional level of detail of those features particularly focusing on the behavior of the application.  See User Story is Worthless - Behavior is What We Need although you don't need your behavior description to be as formal as what is presented.  Really this begins to be a Functional Specification.  Developers don't need everything to be fully documented.  Rather are just looking for more detailed description of the features/functions.
Examples (these are going to be more detailed than you need to get to at this point):

• Sample Spec
• Functional Specification Example

Wireframes, Comps, Clickable Prototype

Create wireframes for a few key screens that sketch your concept using a tool like Balsamiq. 
Send across any graphic designs you currently have. 
If you happen to have a clickable prototype, that's great.  That's fairly uncommon.

Other Documentation

Here are other things you might be told about and try to capture:

• Personas - Examples: http://www.uiaccess.com/accessucd/personas_eg.html;
• Use cases
• Software Requirements

Additional Resources

Here are a bunch of additional resources

• What is the minimum viable product?
• Minimum Viable Product: a guide, Lessons Learned, Eric Ries, August 3, 2009
• 10 examples of minimum viable products
• Minimum Viable Product revisited – the MVP Curve?
• Don't Let the Minimum Win Over the Viable
• Minimum Desirable Product
• How I built my Minimum Viable Product
• The Death of the Wireframe? Towards An Integrated Approach to UX Design

You should definitely look at Steve Blank's book and review his blog.