I built an app for two users. It changed how I think about product work.
Most of our craft exists to manage distance. Ask what happens when there isn't any.
Last weekend I built an app with two users. Me and my husband. It is the third product I have built for myself, and the first that has changed how I think about my actual job. Not because of how quickly it came together, but because of how much I removed.
The product in question
It is called Diario. It takes everything the school already sends us, the schedule, the homework, the lunch, what happened during the day, and puts it in one place we can actually read on a phone before we have had coffee. It is private, it is for the two of us, and it is not going anywhere else.
I have spent my career on products used by hundreds of thousands of people. Building for an audience I actually live with is a different job, and the difference has been sitting with me all week.
Most of our craft exists to manage distance from the user. When that distance goes to zero, you can see what the apparatus was actually for.
2
users the product was designed for
Built over one weekend
0
distance between the team and the person using it
The condition almost no product team works in
What actually changed
Three things surfaced over the week. None of them are about tooling, and all three transfer back into client work.
Every question already had an answer in the room
Questions that normally take weeks to settle were answered immediately, because the person who lives the problem was the person making the call.
The surprise was subtraction, not speed
When you carry the cost of everything you add, you stop adding. Nothing shipped because it was on a list.
The apparatus became visible
With no distance to manage, it was suddenly clear how much of the standard process exists to compensate for distance rather than to create understanding.
01 — Every question already had an answer in the room
Should this be on the first screen? I knew, because I am the one looking for it at seven in the morning with a child asking whether he needs his swimming kit. Does anyone actually need this feature? I could feel the answer instead of debating it.
That is not only a difference in speed. It is a different kind of question. In most product work, "should this be on the first screen" is a proxy. We answer it with research, with analytics, with an argument about which persona opens the app first. Those are all attempts to reconstruct a moment nobody in the room was present for. Here there was nothing to reconstruct. The moment was mine.
02 — When you are the user, you subtract
What surprised me was not the speed. It was how much I removed.
When you are the user, you feel the cost of everything you add, so you stop adding. Nothing shipped because it was on a list. Nothing survived because someone senior was attached to it. Every feature had to pass the only test available: does this make the seven in the morning version of me calmer, or busier?
Nothing shipped because it was on a list. Nothing survived because someone senior was attached to it.
Most roadmaps have no equivalent test. Features accumulate because removing one requires an argument and keeping it does not. That asymmetry is invisible from inside the process, and entirely visible to the person who has to live with the result.
03 — Separating understanding from scaffolding
Research. Personas. Discovery. Prioritisation frameworks. Quarterly planning.
All of it is a way of reconstructing something we cannot reach directly. It is real work, and I will keep doing it. Distance from the user is the normal condition of building software at any scale, and these are the instruments we have built to work well in spite of it.
But when the distance went to zero, I could see how much of the apparatus was compensating for that distance rather than adding anything on its own. That distinction is worth being able to make. Some of what we do genuinely creates understanding that would not otherwise exist. Some of it is scaffolding around a gap. From inside a normal product process the two look identical, cost roughly the same, and get defended with the same language.
Go deeper
We have written separately about the timing of learning: why growth stalls when teams commit before they understand, and how to move evidence into decisions before resources are locked.
Learning before commitment: the hidden constraint on growth →
But most products cannot have two users
A fair objection. Almost no commercial product gets to be built by the person who uses it, and scale is usually the entire point of the business. This is not a transferable situation.
True. The lesson is not build only for yourself. It is that closeness is a variable you can move, and most organisations treat it as fixed.
There is a long way between a team that has never watched anyone use the thing and a team that sits with real users every month. Neither of them is at zero. But one of them can feel the cost of what it adds, and the other one is guessing at it. That difference compounds across every decision on the roadmap.
So the question is not how do we get to zero. It is how much closer can we get than we are now, and what would we build differently if we could feel the problem the way the person living with it does.
04 — The standard is moving
The part I think matters most right now is what this does to expectations.
The gap between generic software and software that fits is becoming visible to ordinary people. Building something for your own situation is no longer a specialist activity, and once someone has lived with a thing made precisely for their circumstances, they can name exactly what is wrong with everything else they use. They stop accepting the average quietly.
Once someone has lived with software built for their exact situation, they stop accepting the average quietly.
Products built on a real, specific, felt need are getting stronger for it. Products built on an averaged need across a segment are getting weaker. The numbers will not show it for a while, which is precisely why it is worth paying attention to now rather than later.
Measure how far you actually are from the user. Distance is a variable, not a fixed condition of the work. Name your current distance honestly before planning anything to close it.
Notice which questions are proxies. If a decision is being settled by argument about a moment nobody in the room has witnessed, that is a signal about access, not about analysis.
Make subtraction as cheap as addition. Features accumulate because removing one requires an argument and keeping it does not. Give removal an owner and a standing slot.
Separate understanding from scaffolding. Some of the process creates insight. Some of it compensates for distance. Both feel like rigour. Only one survives getting closer.
Assume the standard is rising. Your users are increasingly people who have experienced software built exactly for them. Averaged-out products will lose ground before the metrics say so.
Somewhere in the middle of the week I noticed I was not building software. I was solving a small daily problem in my family's life, and the software was the by-product.
That is the order most roadmaps have backwards.
Start with the problem you can feel. The product is what is left over.
