What goes in a first version, and what can wait?

A feature list grows by itself. Every time you talk about your idea, something gets added: a loyalty card, a chat, an overview with figures. A first version holds much less than that list, namely what someone needs to carry out the main task from start to finish.

Start with the main task

Say you want an app for a hair salon, where customers book their own appointments. The main task then fits in one sentence: a customer books an appointment, and the salon knows about it. If you can’t write a sentence like that, the idea is still too broad for a first version, and it is better to find that out now than during the build.

Then go through the steps as a user takes them:

1. The customer opens the app and picks a treatment.
2. The app shows which times are free, and the customer picks one.
3. The customer fills in a name and a phone number and confirms.
4. The salon sees the appointment appear in its calendar.
5. The customer can’t make it and cancels.

That is the first version. A loyalty card, reviews, selling shampoo and an overview of the busiest days aren’t in it, however good those ideas are.

What belongs in without anyone asking

A list of steps describes what happens when everything goes well. Then ask what happens when it doesn’t. What does a customer see if someone else has just booked that time? What if the salon closes for a holiday? What if someone gets their phone number wrong?

Those answers are easy to leave off a wish list, and they still belong in a first version, because customers run into them straight away. The same goes for the practical side: if people log in, they need to be able to reset their password, and if you store customers’ details, you need a privacy statement.

How to decide what waits

Two questions get you a long way. Can the main task be done without this feature? Can someone do it by hand for now?

Reminders are a good example. They are useful, but the hairdresser can also send a message herself the day before. You can take an overview of the busiest days from the calendar for a while, or keep it in Excel. That manual work tells you something too. You see how often it is really needed and what exactly it should contain, and once it starts to take too much time, you have a good reason to get it built.

Every feature that waits is also work you don’t pay for now.

Some things you do discuss up front, even if they don’t get built yet. If a second location or a second language is coming later, whoever builds it can already take that into account in how the data is set up. The same goes for working with no signal, because that decides how an app stores and sends its data. Adding things like these afterwards takes more work than planning for them.

A feature that doesn’t fit the product

A feature can sound useful and still not belong in your product. For me it should always fit the product.

Felix, my own product, helps boutiques bring good customers back with personal messages. In one conversation, someone asked for a newsletter feature, and I said no: Felix should not become a newsletter. Bulk messages are in. With those you send a specific message to a chosen group, while a newsletter is a general message to everyone.

You can use that example on your own list. Write in one sentence what your product does and for whom. If a feature doesn’t fit that sentence, look at what need sits behind the request. Sometimes what is already there can cover that need, or a small change is enough. Selling shampoo can be a fine plan for the salon, and it doesn’t belong in an app for booking appointments.

What to do with everything that waits

Keep track of it. The order in which things get built is called a roadmap: what comes first, what comes next and what can come later. As long as an idea is on it, it is easier to leave it for today.

That order doesn’t have to be fixed. On Felix, bulk messages and voice notes came out of sales calls, before the first pilot. Once real people use your first version, you have even more to go on. What they ask for repeatedly moves up, and what nobody misses can come off the list.

If you doubt whether the main task is the right one, you can test that before anything gets built. You can read how in Test your idea before you build it.