MVP Series 2: Writing a Spec

MVP Series 2: Writing a Spec

Writing a basic specification will take a significant amount of time and resources. But it’s really worth it because the process combined with customer development will narrow the scope.

First off, write the Summary of the Problem. This context should let a developer, designer or other vendor understand what you are doing and why you are doing it. You should be able to limit it to a paragraph, maybe two. If it takes two pages – it’s more than one problem. Unpack the topics and pick your starting problem. ONE problem. Not six! If you have six problems you can’t build a MVP.

State your hypothesis. It’s going to change as the document changes, but you need to write it down. Again, being concise is important:

We believe that customer X has a problem of Y that we can fix with Z. We think they will pay $$.

Identify Stakeholders

When you identify stakeholder you’re identifying the key user profiles and the naming conventions of the specific use cases. This is where you avoid the word “customer” and instead opt for a Defining MVP Stakeholdersmore defined profile. As my former Executive Assistant told me once, “Pronouns are not your friends” (Thanks @PCub3d). In our case, we have four types of stakeholders.  The lawyer, the Back Office Team, the Client and our team at Legal apps – the “Super User”. Super users need to be able to login to make changes to payments, emails, subscriptions, etc.

Writing a Specification

If you’ve never written a specification document before, don’t freak. For my technical friends, this outline is overly simplistic. However, they’d rather have use case written down then the “hand waving” of a founder who’s product is stuck in their head.

Begin with naming that doc and assigning Version 1.0. Every significant document will include a 1.1 or 1.2 reference change. I’d suggest Google Docs for two reasons, it makes for easy collaboration and revision history. Also, when you invite comments, make those notes in Suggestion mode vs having multiple primary editors.

Using the bullet structure type out the features in the use case based on your hypothesis. Next, move onto the layout of the document itself. You’re going to need nested/numbered bullet points.

  1. This isn’t a feature that WordPress does well
    1. Unless you want to use a plugin WordPress.org
      1. Or type all of your document in HTML or Markup

This will allow you to refer to sections based on numbers and sub-bullets.

In our case with Legal App it started with Section 1 – Mobile App

  1. New use registration
    1. Email
    2. PW
  2. User sign in
  3. Use case 1 – signing up a new client

Section 2 – Web App

  1. New use registration
    1. Email
    2. PW
  2. User sign in
  3. Use case 1 – signing up a new client
  4. And so on…

Take the time no to write out the use cases.

Future Features

Add a new Section 3 – Future Features. This is a section of bullet point ideas, ranked in no particular order of ideas you might add to the application in the future. Push all non-mvp features to this list. You aren’t going to launch a product with all features included, so ruthlessly move non-required features to this list.

If you don’t you can quickly move from “Scope Creep” to “Scope Leap”. Even if you’re a repeat entrepreneur, you still need to limit scope so you can ship a product in a reasonable timeline. The other option, the historical “pre-lean” option is to spend 2 months (or years) building a product.  Remember, Reid Hoffman (Founder of LinkedIn) quote:

If you are not embarrassed by the first version of your product, you’ve launched too late.

Finally, give it a look again, did you move those features into the future section? Or did you jam all of the features into the first version? I hope you have more cash to spend and more time to wait.

The next thing to think about is how to build these features into two-week sprints – we’ll talk about that in the next post.

Leave a Reply

Your email address will not be published. Required fields are marked *