Wednesday, February 13, 2013

Building Your MVP as a Non-Technical Founder

I did a presentation this week at Coloft that looked at how Non-Technical Founders can go about getting their MVP built.  It had a passionate group of 50 people attending.  I promised to do this post as a follow-up to the session to provide additional links and information.  It should also give a sense of what I covered to people who were not there.

Here is the outline of the talk and some links from prior posts that talk to the issues that I discussed in the talk.

Purpose of an MVP and Defining the Right MVP

I've really not talked as much about this in my blog even though its hugely important.  I generally hear the following as reasons for founders building their MVP:

  • I need it to get investors interested (NOT VALID)
  • I need it to see how early customers use it to get feedback (RARELY VALID)
  • I need it to test/prove aspects of the product such as (VALID)
    • Cost of Customer Acquisition
    • Conversion Rates / Pricing
    • Viral Coefficient

My claim is that the first bullet, although extremely common, is a misguided reason to build the MVP.  Investors my tell you that, but what they can look at your product on paper and tell what it does and they will understand if it can be built.  Once you build it, they will now ask you about the key metrics that they need proven in order to see if you really are a good investment.

The second bullet, getting feedback from customers is most often not valid either.  Again, putting something down on paper (wireframes, graphic comps) and getting feedback from potential users can tell you most of what you would learn from a working MVP.  There are a few cases where you somewhat need to see the system operating to have a sense of the value.  Examples might be a recommendation engine, search engine, matching engine or something with a complex interface.  Even with these, you will have paper-tested your MVP, but the reality is that customers will not be able to assess the value to them until they actually use it. 

The real reason to build an MVP is to do early tests of key Startup Metrics for the business.  To prove/disprove a hypothesis.  One of the questions in the session was "How do you know what to put in your MVP?"  Once you have the metrics defined, it focuses your effort.

Ways to Make Your MVP More Minimum

We spent quite a bit of time talking about a complexity scale and the kinds of resources you can viably use at different levels of complexity.

image

Simple MVPs get built with less the 3 Programmer Months worth of effort (that's 3 months a single programmer working full-time).  More complex MVPs are going to be 12+ Programmer months.  There are some MVPs that are unavoidably complex.  eHarmony for me fell into that camp.  We needed the matching algorithm.  Many MVPs can be made to be very simple.

  • Paper Prototype or a Smoke and Mirrors Prototype - you can just build something on paper or even just one that you can click through and get a lot of the feedback you need.
  • Fake Site - you can have what looks to be a real site, even take "orders" but not actually have anything able to run it.
  • Leverage Existing Platforms or Third Party Products - you want to test your social network, grab Drupal and whip something together, or even just use a hosted service.
  • WordPress - we spent quite a bit of time talking about how you could do a lot with WordPress to provide simple forms of lots of functionality.  WordPress is pretty easy to hack.  And the back-end is something that a non-technical founder can manage.  We end up using WordPress a lot as the marketing front-end of our web sites.

The bottom line is that you should first look to make your Minimum as Minimum as possible.

Here are some important and relevant posts that relate to the topic of defining the right MVP.  The "Questions" post is probably the most important. 

What Do you Need to Get Your MVP Built

From the graphic above, you can see the kind of resource you might need to be able to build your MVP.  If you are on the lower complexity end, the key is defining small chunks of work that can be done quickly by a developer.  If you do not break it down into small pieces, its hard to make progress with part-time resources, freelancers, etc.

Founder / Developer Gap

I've spent a lot of time on the Startup Founder Developer Gap and knowing what you need in terms of a Startup CTO or Developer. 

In this talk, we spent most of our time on Technical Advisors: Every Web/Mobile Startup Must Have One and how they should be helping you:

  • 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.

Finding and Selecting a Technical Cofounder / Developers

Development Challenges

Technology Choices

Choosing a Programming Language and Framework for Your Startup

 

Finally, if you made it this far, then take a look at: Free Startup CTO Consulting Sessions.  I'm always happy to try to help startups figure out how to go after creating their MVP.

Posted by at 7:34 AM 4 comments

Subscribe to: Posts (Atom)