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.

Technical Advisors: Every Web/Mobile Startup Must Have One

I did a presentation recently for a graduate class from The Founder Institute around getting online/mobile products out the door.  I LOVED it because, the presenting part was over quickly and we got into specific issues that the founders had in terms of getting things built.  It was like having a bunch of mini-Free Startup CTO Consulting Sessions all in one room.  But what was interesting to me was that I found myself recommending that each of them should have a technical adviser.

Why?  Roughly, they needed to make sure:

• Specify the right things to be built. 
• Third party products are used appropriately.
• Structure development contracts appropriately or directing the in-house team appropriately.
• Plan for past the initial MVP.
• Review the code being built.

This is exactly the kind of thing I'm doing as a Part-Time CTO or Technical Advisor for startups.  It just didn't dawn on me how common this need is.  And it made me come to a new realization:

Every early-stage web/mobile/online startup should have at least one technical advisor, probably two.

There are two kinds of advisors that are commonly needed.

Strategic Technical Advisor

Look at the business and determine what's going to make sense from a development perspective in the short-term, longer-term.

They need to be able to know the key Questions Developers May Have Forgot to Ask a Startup Founder, figure out where/when/how to bring on development talent (Hiring Developers Before Product/Market Fit? , How to Hunt Programmers for Your Startup - A Field Guide), how to manage development resources (Startups and a Common Misunderstanding in Agile Software Development, Poor Software Developers - Pull the Plug Early, Symptoms of a Weak Development Team), choosing technical frameworks (Choosing a Programming Language and Framework for Your Startup), and other aspects of making broader choices about what will get developed, how it will be built, and making sure that you ultimately deliver the right stuff at the right time.

I was very worried for several startup in the room.  They were making some significant choices that were going to have lasting impact on their company.  Why do this without the right technical advisor?  Would you create contracts without an attorney? 

Tactical Technical Advisor

There's also a tactical level for technical advisors.  We are producing the right functionality, but is the code that's being produced the right product?  Is this something that's scalable and extensible?  This kind of advisor should be looking at the code on a fairly regular basis to make sure that the team is building the right thing.  This is important whether you are outsourcing or building it in-house.  If you are outsourcing, then this person will also be protecting you from issues like being able to access the source code and making sure can bring it in-house at a later time.  Do you really have control of the development?  If you don't have this kind of person and you are not personally looking at the code, then you don't really have control.

There are some technical advisors who can do both strategic and tactical, but its common to find a tactical advisor separately.

CTO Founder - Do they really still need a technical advisor?

I know relatively few people who are good at both a strategic and tactical level.  Most early-stage, in-house teams needs to be hands on developers, not strategic.  It's rare to find a person who is good at both strategic level thinking and is still a rock star, cranking out code.  Early-on, bring people on who can produce volume.  You can get strategy level on a part-time basis.  I've talked about this before in Startup CTO or Developer.  Is this person a CTO or a developer?  Likely they will have gaps in one or the other.  Get an advisor to help supplement where there are gaps.

By the way, do you know that most development teams use peer review of code to help ensure good development practices.  Who's doing that for your CTO?

Where Do I Find a Technical Advisor

You are looking for part-time people in these rolls so you often are finding people who already are employed somewhere else.  In Los Angeles, I have easy access to a bunch of potential strategic technical advisors through the LA CTO Forum.  If you need a strategic advisor, contact me and I will connect you with someone from the group.  Another avenue is looking for CTOs/VP Engineering via LinkedIn.  It's going to be a numbers game to find the right person that way, but still quite doable.

Tactical advisors are also going to be already developing or leading development full-time at a startup.  They will have the title Lead or Manager.  They should only be a year or two removed from full-time hands on.  Ideally they have experience with your full technology stack, but in some cases, having them learn about best practices will be necessary.

Compensation

This is going to depend on the specifics of the work.  When advisors need to jump in and spend significant hours on a particular issue, then likely cash compensation is going to be required.  If it stays at a few hours per month, then using something like Founder Institute's FAST agreement probably makes sense.  Just make sure its clear what the expectations are going into any engagement.

Why Investors Should Demand This

I quite often get a call where a founder raised $150K of initial money and has spend $120K on in-house or outsourced development and the software is 90% done.  But they are having a tough time getting it all the way done.  As I mention in Symptoms of a Weak Development Team, the number one reason I get calls relates to an old software engineering adage:

The first 90% of a project takes 90% of the time.  The last 10% takes the other 90%.

In the case of these calls where the initial money has mostly been spent, it can be very tough to recover.  Most often the failure is both a result of the founder not doing the right things and because the developer over-promised and failed to ask the right questions.  Having a strategic and tactical advisor can greatly reduce the chance that this is going to happen.

What's funny is that once software has been built and you move from Seed to A or B round, I often get calls by investors about reviewing the existing product to see if it has reasonable quality and if the team is going to be able to continue to produce going forward.   Why a Seed level investor doesn't insist on a technical advisor, I don't know.

Bottom line - if you are an early-stage startup with online or mobile technology as part of your solution, you ABSOLUTELY NEED a technical advisor.