The two most important questions when scoping your MVP

Imagine yourself 3 months from now.

You’ve poured your life savings into bringing your app to life. It’s jam packed with all of these features that you just know your users are going to love.

You’ve been working on traction while your team has been building the app so you get a steady stream of users. But wait, something’s wrong.

They’re only using one feature and completely neglecting the rest of your app. And they’re insistent that you need to add a whole host of features you never even thought of.

You wasted hundreds of hours and thousands of dollars. Now you have to scramble to build the thing your customers actually want.

This happens all the time.                                                                    

Don’t believe me? We once spent an entire year building a messaging service. The client wanted it on every platform imaginable, with plenty of “killer” features. At the time we hadn’t developed our scoping process, so we built exactly what he asked for (and that mistake is on us).

The project finally launched and six months later the appointment feature we spent weeks building had been used twice. The iPad and Android tablet apps have 0 total downloads.

Needless to say, we now advise all our clients to start smaller and test early and often. 

Imagine if we had launched on one platform, and held off on the appointments feature. We would have launched months sooner. And if someone needed a tablet version we still could have built it. Only we would have built it with all of the other tweaks we’ve made sense already in place.  

Think of your product as a constant work in progress that is always evolving. Can you hold off on building that feature for a week? If so, do it. Later, if a customer says it’s the only reason they’re not paying, then you can build it. You’ve only lost a week or two. And now, you can show that customer how much you care about them. As a startup, your greatest weapon is your customer service.

You still need to start somewhere, but the key is to start smaller than you think you should. If your app is so small that it makes you feel a little nervous, that’s when you know you’re on the right track.

By waiting to build features until customers ask for them you avoid wasting time and money building things your customers don’t want. In the startup world, time and money are everything                  

Another important question to guide you through scoping your MVP is, “what can I do manually for now?”

Let’s look at payments as an example. Most clients want payments handled automatically. But, depending on your target audience, this may not be necessary right away. 

It’s not uncommon for an enterprise sales cycle to be 1-2 months long (or longer). Now, I'm sure you waited to have a few customers before you built anything. (More on that in an article coming soon.) But even if you’re an incredible salesperson, you’re at most going to have eight customers by six months in. 

It can take weeks and cost more than $10,000 to build out payments infrastructure in an app. A Quickbooks subscription costs $5 per month. Sign your clients up for an annual subscription of your product and this becomes even easier.

This has the added effect of creating another touchpoint between you and your customer. In enterprise sales, this can be a big advantage. And once you have enough customers for it to become a problem, the $10,000 to build a payments system will be a drop in the bucket. 

Consider an even more extreme example. What made Stripe so much better than its competitors was how easy it is to setup a merchant account and start collecting payments. 

“...the way Stripe delivered "instant" merchant accounts to its first users was that the founders manually signed them up for traditional merchant accounts behind the scenes.”

That comes from Paul Graham’s article Do Things that Don’t Scale. If one of the most successful companies of the past decade can launch with manual processes, why can’t you?                       

The two most important questions to ask when scoping your MVP:
1) How long can we hold off on this feature?
2) Can we do this manually for now?                                                              

Now, how do you actually define the scope for your MVP? We use a simple process with all our clients. 

Note: We like to use sticky notes and a whiteboard for this process. The manual aspect can be helpful, but a Trello board will work as well.                                         

Step 1: List out every single feature you could possibly want.

Using one sticky note (or Trello card) per feature, write out every feature you could want in your app. This is your chance to think big, don’t hold back. 

If you have multiple types of users, make sure to include the features for each of them. 

One way to make sure you don’t miss anything is to use user stories. This article from Roman Pichler can help you learn how to use user stories.

The key is to break these up into the smallest pieces possible. “Comments” should not be a feature. Are there user accounts or do users enter their name? Are the comments nested? Can you vote them up and down? There can be a million pieces that go into comments.

It’s okay to start big, but do your best to break these up into smaller and smaller pieces.

A few features that people often forget:

• Forgot password
• Updating your email/password
• Email notifications
• Branding (not a feature but part of your scope)
• Marketing website (same as above)
• Search/pagination
• Empty states
• Project management

Step 2: Move as many features as possible to a V2 list.

Next, go through your list and start pulling sticky notes away. Every feature that you can hold off on, at least for a little while, move to a second list. This list is now your roadmap for future development.

Think of this as a game: for every sticky note you move to V2, you score a point.

Once you’ve moved over everything that you can, go through your V2 list and make sure it’s ordered by priority. This order can change, but this helps to reinforce the idea that these features aren’t going away. You’re just holding off on them for now.

Step 3: Go back through your original list and move any feature that you can do manually to a new list.

Now, go back through your V1 list and look at every single feature. This time, ask yourself, can we do this by hand?

For every sticky note where the answer is yes, move it to a new list called “manual processes.” Or call it “man-hands.” Whatever floats your boat. Again, the goal is to strip away as much as possible.

Step 4: Repeat.

Repeat this process as many times as you need to, until you feel like you can’t take any other sticky notes away. Then, do it one more time.

Step 5: Sketch every screen in your app.

Finally, sketch every screen in your app. If there’s a mobile app and a web app, sketch both interfaces. Don’t worry about making them pretty. Use a fat dry erase marker and limit yourself to 30 seconds or less per thumbnail.

The goal is to create a super rough idea of what the interface will need to have. Is a feature going to need one screen or three? Is there enough data on a page that we’ll need to break it up? Do we need to create a custom element anywhere?

This is a great way to find features you may have forgotten. And visuals help to communicate your ideas. But make sure not to use this as a chance to add a whole new list of features to the scope.

Make sure you sketch every screen, even the little ones. It would surprise you how much you can miss if you don’t.                                                           

How to communicate your scope to developers

As a non-technical founder, you’re going to have to communicate this scope to a developer at some point.

Include your development team in this process. We do this with every new client, even if they’ve done it themselves. Developers and designers will bring a fresh perspective. They often notice things you never would have thought about.

Once you run through the process with your team, transfer your MVP list to a spreadsheet or Trello board (we use both). From here, they can add estimates for each piece. Then, you can either revise your scope based on the estimates or jump into development.

An added bonus of making your MVP as small as possible: it’s easier to create an estimate. Smaller projects are easier to estimate. More accurate estimates keep team morale up and projects moving forward.

You can refer to this list throughout the project to see where you are and make sure you’re staying under budget. At the end of each week, we update our scope spreadsheet with the current hours for each task. This has been hugely helpful for keeping projects moving forward.

Homework

Go through this process yourself. Keep track of how many items you removed from your V1 list and comment below with your results. And as always, let me know if you have any questions.