Imagine yourself 3 months from now.

You’ve poured your life savings (or your life) 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 you've 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 (potentially) thousands of dollars. 

Now you have to scramble to build the thing your customers actually want.

This happens all the time.

Credit: http://www.entrepreneurfail.com/2016/12/perfection-rejection.html

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.

We all talk about the Lean Startup, but we often forget to practice what we preach.

Imagine if we had launched that messaging service 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 since 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 of our 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 to build out payments infrastructure in an app. A Quickbooks subscription costs $5 per month. Sign your customers up for an annual subscription of your product and this becomes even easier.

This has the added effect of creating another touch point 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.

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

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.

Key Takeaways

  • If your scope is so small it makes you feel nervous, you're on the right track
  • Break features down into all of the possible sub-features to avoid scope creep
  • Manually handle as many things as possible
  • Build smaller, launch faster!

----

This post originally appeared on Start in the South, the blog about building profitable companies outside of the usual hubs.

Andrew is a Founding Partner at Krit, a product development studio for early stage startups and a co-founder of Albatross. He believes everyone is a nerd about something.