Imagine planning a house down to the last screw, signing off on it, and opening the doors a year later. Except in that year you have a second child, your work moves home, and suddenly you need a completely different house than the one being built. With software this happens all the time. A big plan up front looks like certainty, but it’s really a bet that nothing will change in a year. And that never happens.
This lesson is about how, instead of a big plan, to write a brief that holds up, cut it down to the smallest useful piece, and build in steps you’ll actually finish.
Why “let’s plan everything up front” projects fail
The classic scenario: six months spent writing a fat spec, everyone signs off, then a year of quiet coding, and the result gets unveiled at the end. This is called waterfall, and in software it works miserably. The reason is simple: that document goes stale before you’ve finished writing it.
In the meantime the market shifts, a new competitor shows up, customers start wanting something else, and you yourself realize you don’t even need what you imagined at the start. But the contract and the code are already running on the old plan.
- Risk piles up at the end. When the first real users are a year away, you spend that year not knowing whether you’re building the right thing. That’s the most expensive possible way to be wrong.
- Change gets punished. With a fixed spec, every tweak is “extra work” and a negotiation. People would rather stay quiet and let something they didn’t want get built than pick a fight.
- Done doesn’t mean useful. You can tick off every point in the brief and still end up with software nobody uses.
A good brief describes the problem, not the solution
The most common mistake in a brief is that it dictates the solution straight away: “we want a button that exports orders to Excel.” That’s an answer, not a question. Tell whoever is building the software two things above all: what the outcome should be, and why.
In this case the real problem is something like: “every Friday our bookkeeper spends two hours manually re-typing orders and makes mistakes doing it.” That brief is priceless, because a good problem-solver will pull a better idea out of it than your export ever was. Maybe the data should be sent straight into the accounting system, and no Excel and no button are needed at all.
A good brief reads: (who) needs (to achieve what), because today (what’s holding them back). Constraints: (budget, deadline, what can’t be missing).
Add the guardrails, not the steps. So: by when you need it, how much you have for it, what it has to play nicely with, and what is clearly out of scope. Exactly how it gets built, leave to the people who know how to build. That’s what you’re paying them for.
MVP: the smallest useful step someone can actually touch
An MVP isn’t a “half-finished version.” It’s the smallest piece that already solves a real problem for a real user, and that teaches you something from being used. You don’t build a whole company system just to find out whether you’re even aiming the right way. You build the one thing that hurts the most and you take it all the way to done.
Take that bookkeeper. The MVP isn’t a complete company system. It’s a single screen where Friday’s twenty orders get dropped in, and a button that hands them off correctly. No user roles, no reports, no dashboard. Just that one pain, solved.
The point is that you can touch an MVP. The bookkeeper uses it for a month and you learn things that would never have made it into any spec: that half the orders still come in by email, that sometimes they need correcting, that the Friday routine is actually a Wednesday one. You can’t dream this up at a desk. You can only find it out in real use and then build on it.
A roadmap isn’t set in stone, it’s a sorted list
Once the MVP is alive, ideas start pouring in. From you, from colleagues, from users. A roadmap is a living list of what comes next, sorted by the one honest criterion: how much it delivers versus how much work it costs.
- Big payoff, little work. You do it right away. This is where most of the hidden value lives.
- Big payoff, lots of work. You plan it properly and slice it into smaller pieces.
- Small payoff, little work. When there’s time left over. Possibly never.
- Small payoff, lots of work. This is where most “brilliant ideas” belong. Say no out loud.
That “out loud” matters. Unspoken promises (“we’ll get to that eventually”) are poison, because they hang around like a debt nobody ever repays. It’s much healthier to say: not this, not now, and here’s why. A roadmap you haven’t changed in six months isn’t a roadmap, it’s a wish list. It should move every time real use teaches you something new.
Prioritizing hurts. It means saying no to things someone on the team is itching to build. But without it, software bloats into something nobody can carry or afford.
How you know it’s done: agree on a metric up front
A goal without a metric is just a wish. Before the first line gets written, agree on how you’ll know it worked. For the bookkeeper, say: “the Friday re-typing drops from two hours to under fifteen minutes, and the errors in amounts disappear.” That’s a number you can point at.
And then there’s the way of working we swear by at FRGTN: seeing progress every week beats a big reveal after three months, every time. A weekly demo you can actually touch does two things. It keeps the project grounded in reality, because you immediately see whether it’s heading the right way. And it kills risk in small pieces instead of hiding it all until the end.
Software is never “done” in the sense of closing the door on it. It’s done when it does its job and you know what the next step is. That’s all there is to it. Start with a small brief of the problem, build the smallest useful piece, and let the market show you the rest.