Does anyone need the thing you’re building?

A useful patch begins with a problem someone can recognise and reproduce. A product needs a recognisable problem too, although finding it happens in people's work rather than only in a codebase. We have learned ways to make an app behave reliably. Now return to the person it was meant to help and ask whether it belongs in their day.

Let us follow one small example from the first conversation to the first users. Imagine a community garden with shared beds. Volunteers take turns watering, and you have heard that beds sometimes get missed in hot weeks. That is a guess, not a need yet.

The most useful question is about the past. Ask the coordinator: when was the last time a bed got missed? What happened, and what did you do about it? A specific past example gives you a sequence of actions to investigate. Questions about the future, such as whether they would use an app that does this, invite polite answers. A yes can express encouragement without showing whether the person will change how they work.

Listen for the workaround, because it is the most honest thing you will find. Maybe there is a paper sheet on the shed door where volunteers write their names, and a message every Sunday asking who can take Wednesday. Ask to see it. A workaround tells you the problem is real enough that someone already spends effort on it, and it shows you the shape of the job: someone claims a day, someone gets reminded, someone checks that it happened.

If nobody has a workaround, ask why not. Sometimes the problem is rare, or does not cost enough to matter, and that is good news delivered early.

Talk to a handful of people this way, one at a time, instead of sending a survey. A survey only answers the questions you already thought of. In a conversation you can follow the moment someone says, well, actually, the real problem is.

Then ask for something small and concrete: would you try a simple version for two weeks, starting next Monday? Willingness to spend a little time is a far better signal than enthusiasm. Write down who said yes.

Now choose the smallest complete workflow. Complete matters more than small. For the garden, that means a volunteer can claim a watering day, is reminded the evening before, marks it done, and everyone can see which beds are covered. If missed reminders were the problem observed in the pilot, leaving out the reminder would leave that problem unsolved. Without profiles, badges and a weather forecast, it still is.

Decide what success means before you start, in a form you can check: over two weeks, every watering task agreed with the coordinator is claimed and recorded by its due time, without the coordinator sending chase messages. If you cannot say what would count as working, you will not be able to tell whether it did.

The first version can be you. Keep the rota in a spreadsheet and send the reminders by hand for the first week. This manual pilot is not cheating. It shows you which reminders people answer, which time of day works, and what they ask that you did not expect, before any of it is frozen into code. Then build only the parts that turned out to matter.

A note on what counts as a product. If your reminders go out through someone else's messaging service, or your main feature is a well-designed request to a model API, you are building on a borrowed service, and that is normal. Most useful software is assembled from parts other people built. The question is never whether you wrote every layer yourself. It is whether the whole job gets done, from the volunteer's first tap to the bed being watered, including what happens on the day the borrowed service fails.

When the pilot works, launch small and where your users already gather. For the garden that is the notice board on the shed and the group the volunteers already read. After that it might be the coordinators of nearby gardens, introduced by the one you worked with. A small launch to the right people teaches you more than a large one to strangers, because you can still talk to every one of them.

Here is an exercise. Pick one idea you have. Write down the name of a person who has this problem, the last date it happened to them, and what they do about it now. An empty answer tells you what to investigate in the next conversation.