Every failed internal tool we've ever autopsied died of the same disease: it was designed for "the team." The team is not a person. The team doesn't have a Tuesday, doesn't get interrupted by drivers calling about a missing pallet, and doesn't mutter at a screen at 6:40 AM. Designing for "the team" produces software that offends nobody and delights nobody, which is another way of saying software nobody opens twice.
The counterintuitive fix, the one that works with embarrassing consistency: build software for one user first. One actual, named human with an actual, named problem. Not a persona. Not a stakeholder committee. A person whose desk you can find.
Here is the rule, stated plainly: pick one named user with one high-frequency workflow, build the single screen that makes their worst hour disappear, and defer everything else until that person would fight you if you took it away. Generalizing comes later, and it comes faster than you'd think, because a delighted user does your requirements gathering for you.
Why You Build Software for One User First
Designing for one user isn't a compromise on the way to designing for everyone. It's how you find out what "everyone" actually needs, because organizations don't have workflows; people have workflows, and they share them once something works.
There's a second, sneakier benefit: scope discipline. When the target is one person's Tuesday, "should we add a permissions matrix?" answers itself. You'd be amazed how many features evaporate when the bar is "does this help Dana dispatch faster today." The ones that survive that bar are the product. This is the same philosophy behind the forty-eight-hour build sprint, which only works because the target is ruthlessly singular.
A quick clarification, because this gets misread: one user first doesn't mean one user forever, and it doesn't mean ignoring everyone else's opinions. It means those opinions wait in a notebook until user one is delighted, at which point they get re-heard with a working product as evidence. Opinions about hypothetical software are worthless; reactions to real software are data.
Pick Your Person Carefully
Not just anyone will do. The right first user has three traits: their pain is frequent (daily, not quarterly), it's sharp (they've built a spreadsheet or a workaround, which proves both pain and motivation), and they'll answer your texts. That last one matters more than any technical consideration.
Two wrong picks to avoid. The VP sponsor, whose pain is dashboards about other people's pain, which is real but secondhand. And the loudest complainer, whose pain is genuine but often unrepresentative, the edge case with a megaphone. You want the competent, busy operator in the middle of the workflow: the dispatcher, the intake coordinator, the estimator. Dana, not the org chart.
Finding her actual workflow takes one afternoon and zero surveys. Sit next to her with a notebook and say the magic words: "Show me the spreadsheet." There is always a spreadsheet, and it is always the real product spec. It tells you which columns she trusts, which ones she ignores, and which calculations she does in her head because no system earned the right to do them for her. Screenshot nothing, interrupt rarely, and count how many times she alt-tabs. Every alt-tab is a feature request she'd never think to file.
Delight, Then Generalize
The timeline we've seen repeatedly: days 1-2 watching Dana work and building the thinnest version of her worst task, days 3-7 iterating on her feedback until she stops noticing the tool because it just works, week 2 the thing happens. The thing is that Dana mentions it to Marco at the next desk, unprompted, and now you have user number two arriving with his own slightly different workflow.
Be honest about how high the delight bar sits: Dana should be mildly annoyed on the days the tool is down. Not "it's handy." Annoyed at its absence, the way you'd be annoyed if someone took your chair. When a dispatcher reports the tool being broken the way she'd report a truck being broken, you've built something that matters, and not one minute before.
That moment is worth more than any requirements document, because Marco's request is grounded in watching something real instead of imagining something hypothetical. Your job shifts from invention to reconciliation, and reconciliation is a much easier job. The rapid prototyping playbook runs on exactly this engine: one user, one workflow, then expand only when pulled.
Compare that with the org-wide day-one approach, which we've also watched closely, usually while being paid to clean up after it. Six weeks of stakeholder interviews produce a 40-page requirements doc where every department's wish got equal weight, the build takes four months, and launch day reveals that the intake team needed one button and got a cockpit. Usage flatlines by week three. The tool isn't bad, exactly. It's just for everybody, which turns out to be nobody in particular.
What to Defer Without Guilt
Here's the list of things that feel irresponsible to skip and are actually irresponsible to build early:
- Roles and permissions beyond one. Dana needs to see Dana's work. That's the whole permission model for now.
- SSO and enterprise auth. A shared login on the ops computer is fine for week one. Heresy, we know. Ship anyway.
- Reporting for people who haven't asked. Nobody's bonus depends on a chart that doesn't exist yet.
- Edge cases that happen twice a year. Handle them manually with a note in the code, like a professional.
- The settings page. There are no settings. There are Dana's preferences, which you hardcoded after watching her for two days.
If this list makes you nervous, good; it means you've sat in the meetings where all five got added in week one. The scope creep defense playbook exists precisely because these requests arrive dressed as reasonableness.
Keep a parking lot for the deferred items, written down where stakeholders can see it. "Later" lands much better than "no," and half the parking lot quietly dies of old age once user one's tool exists and everyone realizes what the product actually is.
When to Expand the Circle
Three signals tell you it's time. First, user one recruits user two without being asked; organic pull beats rollout plans. Second, requests from new users start contradicting each other, which sounds bad and is actually great, because now you have real variance to design against instead of guesses. Third, the same question shows up three times from three different people, which is the market telling you what feature four is.
Even then, expand one user at a time for as long as you can get away with it. The jump from one user to five is mostly product work. The jump from "the whole org" as a day-one target to anything at all is mostly grief.
What expansion actually looks like: user two gets the same screen with one accommodation, user three gets a filter, and somewhere around user five you finally build the second screen. Permissions show up when two users need to see different things, which is the first moment permissions are a product decision instead of an architecture hobby. SSO shows up when IT sends the polite email. Both arrive pulled by reality, and both cost a fraction of what they'd have cost on day one.
So name your Dana. Find her desk, watch her worst hour, and build the screen that deletes it. When she tells Marco, and she will, you'll know you have a product. Everything before that is rehearsal.