You have an idea for an app. What do you do first?

You don’t need to know anything about software to get started. Bring the idea or the problem, and tell it to someone who listens.

When you come to me, I listen first. Below are the questions I ask and why I ask them, because that is how a vague idea becomes concrete, one step at a time. You can already answer them yourself, before you talk to anyone.

What do you need?

Say it in your own words. “My customers should be able to book an appointment themselves” is a good answer. You don’t need to know yet whether that takes an app, a web app or something else. We work that out later, and App, web app or website: which one do you need? explains how I make that choice.

Why do you need it?

An app that has to save your team time looks different from an app that has to bring in new customers. In the first case you count the hours you win back. In the second you look at whether people find the app and keep using it. As long as the reason isn’t clear, it is hard to choose what should come first.

How do you do it now?

By hand? In Excel? Over email and the phone? The way you do it today says a lot about what the software has to do. Your current work holds all the steps and exceptions, along with the small tricks nobody ever wrote down. You want to know those before anything gets built.

Then I ask why you want to move away from it. Sometimes that is obvious straight away: you copy the same thing from one place to another every day, or the work takes a quarter of an hour or an hour each time. Those signs are worked out in When has your spreadsheet grown too big?

I learn your jargon

Every sector has its own words. At WTN App, an app for waste transfer notes in the UK, it was about producers, carriers and receivers. At Eagl it is about the month-end close and reconciling accounts.

Ordinary words can also mean something very specific inside a business. A “customer” or an “order” can be something different for you than for the business next door. If that stays unsaid, you can end up with software that looks right and still doesn’t fit.

When is it a success?

I ask what it takes to call this a success, what can be cut and what is non-negotiable. The answer can be simple. Maybe you want your team to spend less time on a task that comes back every week, with fewer errors creeping into your admin. Or your first customers should be able to use the app without you having to help them.

An answer like that helps with every choice later on. If a feature doesn’t contribute to that goal, it can wait.

Then we talk about features

We go through the product feature by feature, from the user’s side. If you press this, this pops up. For that appointments app it could look like this:

• You open the app. What do you see first?
• You press “New appointment”. What do you have to fill in?
• Something goes wrong, or you have no signal. What do you see then?
• The appointment is booked. Who gets a message about it?

That way we speak the same language. You can read a feature list in different ways, and “manage appointments” can mean something different to you than to me. When we walk through the steps one by one, those differences come up by themselves.

While I listen, I adapt the feature list and I already think about a roadmap. A roadmap is the order in which things get built: what comes first, what comes next and what can come later.

Does it fit the product?

Every feature has to fit the product. Felix, my own product, helps a boutique bring good customers back with personal messages. In one conversation, someone asked for a newsletter feature. I said no, because Felix should not become a newsletter. Where I draw that line is in Building Felix for boutiques.

What does it cost?

Founders sometimes think an app costs a lot of money. When that comes up, I first want to know what “a lot” means to you, because that differs widely from person to person.

The price depends on what gets built. A few things weigh in: how many features the first version gets, whether it has to work on iPhone and Android or in the browser, and whether it has to connect to software you already use. What makes an app expensive or cheap? goes further into this.

I want to build value for the right price.

What do you get next?

When we have talked it through, I get to work. You get a written plan: what it will cost you and what you get for it.

If you go ahead, quick sketches and prototypes come next, so wrong ideas get thrown away cheaply. Then we build in small steps, and you can try it as we go.

What can you do now?

Write down your answers to these questions. A few sentences per question is enough, and it doesn’t have to look good.

1. What do you need?
2. Why do you need it?
3. How do you do it now, and why do you want to move away from that?
4. When would you call it a success?