Nobody Asks for the Feature. They Show You the Workaround.

Thirty-eight minutes into a kickoff call, two things we thought were settled stopped being settled.

The project was small and clean on paper. Four weeks, a defined set of screens, a scope we had already talked through with the person who signed the contract. Then a second stakeholder joined the call for the first time. She had been on the project from the beginning in the sense that mattered most, which is that the whole idea had originally been hers, but she had never been in a meeting with us. Discovery had left a blank next to her name.

She asked two questions. By the end of the call, the admin side of the product had a capability nobody had scoped, and we had a much better picture of what the thing actually needed to do.

I have been in enough of these to know it is a pattern, not luck. The person who buys the software and the person who uses it every day are frequently not the same person, and the second one is the one holding the requirements.

The feature request is a guess. The workaround is evidence.

The most useful thing she said was not a request at all. She described what people do today when they need to find something they read a while ago. They take a screenshot of it. They save the picture so they can find the information again later.

That is not a feature request. It is a person telling you, without meaning to, exactly where the current system fails and exactly how much they care. Nobody builds a workaround for a problem they do not have. The effort is the measurement.

Feature requests are guesses. They are a user's attempt to imagine the solution, filtered through whatever software they happen to have used before. They are useful, but they are secondhand. A workaround is firsthand. Somebody hit a wall, and instead of filing a complaint they went around it, and the shape of the path they wore into the ground tells you where the wall is.

So when we are scoping, the question that gets the best answer is not "what do you want it to do." It is "what are you doing right now instead."

Listen for the tells. People saving copies of things. People keeping a second tool open next to the one they are supposed to be using. People re-typing something that already exists somewhere else. People asking a colleague a question that software should have answered. Every one of those is a requirement wearing a disguise, and every one of them is more reliable than a line in a spec, because it already happened.

The quiet stakeholder usually knows more

There is a reason the daily user is often not in the room when scope gets written.

The person who hires you is usually the one with budget, urgency, and a clear enough picture of the outcome to sign something. That is a real skill and it is why projects start. But that person is frequently one step removed from the grind. They know the problem exists. They do not always know the fourteen specific places it bites.

The daily user knows the seams. They know which step everyone skips. They know the thing that looks fine in a demo and falls apart in month three. They also tend to be less certain that their opinion is wanted, which is exactly why nobody thinks to invite them.

On that call, the moment that changed our build was a question about whether old records could be organized after the fact. On paper it sounded like a small ask. In practice it meant an admin needed to be able to create their own labels and apply them retroactively across two years of existing material, which is a real piece of work and was not in the plan.

But what made it obviously correct instead of merely expensive was the next thing she said. She knew, immediately, that the labels needed to be specific rather than broad, because broad ones return a thousand results and a thousand results is the same as zero. We would not have written that down. We would have built the general version, watched it get used badly, and fixed it in a later phase for more money.

Ten seconds of the right person's instinct beat a week of our guessing.

Yes, this changes your scope. That is the whole point.

The obvious objection is that this is how projects get expensive. You invite more people, you get more opinions, the four weeks turn into eight.

That is only true if you invite everyone. It is not true if you invite the one person who will open the thing every single day.

And the alternative is not a cheaper project. The alternative is the same conversation happening later, after the screens are built, after the data model has hardened around the wrong assumption, when changing it is not a scoping decision anymore but a rebuild. Scope discovered on day two is a line item. Scope discovered in week five is a fight about whose fault it is.

We would rather absorb a surprise at the kickoff than discover one at the demo. So we go looking for it. If a build has a second admin, a power user, a dispatcher, a foreman, a person whose whole job is inside the tool, that person gets invited to the meeting where scope is set. Not the meeting where scope is presented. The meeting where it is still soft.

What to do before your kickoff

If you are a founder about to start a build, three things are worth doing this week.

Name the daily user out loud. Not the department. The person. If you cannot name them, that is the first finding, and it means nobody has confirmed this product has a user yet.

Get them in the kickoff, not the demo. A demo is a place to react. A kickoff is a place to decide. Putting your daily user in the reacting seat and yourself in the deciding seat is backwards, and you pay for it in change orders.

Then, before anyone talks about features, ask them to walk you through their current workaround, start to finish, with the actual clicks. Where do they save things. What do they keep open. What do they copy and paste. What do they ask someone else because the system will not tell them. Write those down as your requirements list and treat the feature ideas as commentary.

The thing you are replacing is not nothing

The competition for a new internal product is almost never another product. It is the workaround. It is the spreadsheet somebody has kept alive for five years, the folder of saved images, the group chat where the real answers live.

Those things are ugly and they are fragile and people trust them completely, because they built them and they work. That is the bar. Not "does the new thing have more features." Does the new thing beat the screenshot.

You find that out by asking the person who takes the screenshots. Preferably before you have written the first line of code.