Someone asks when the feature will be done. You do some optimistic math in your head and say "two weeks." You know, the moment it leaves your mouth, that it's probably wrong.
Two weeks pass. You're close, but a dependency surprised you. Or scope shifted because a customer conversation revealed something you hadn't considered. Now you're explaining why you missed a date that nobody should have trusted in the first place.
This happens constantly on small teams. Not because the builders are bad at estimating. Because estimation, at the resolution of calendar dates, is a bad tool for the job.
Dates feel precise. That precision is a lie. When a two-person team says "March 14," they're compressing a long list of assumptions into a single number:
Every one of those assumptions is fragile. Multiply them together and the confidence interval around "March 14" is so wide it's meaningless.
But stakeholders—co-founders, early customers, investors—hear the date and write it down. They make plans around it. They feel misled when it slips, even if the underlying work is going well.
The date becomes a social contract you never meant to sign.
When someone asks "when will this ship?" they rarely need a date. They need one of three things:
You can answer all three without naming a date.
A lightweight alternative that works for teams of one to ten.
Publish what's next. Maintain a short, ordered list—three to five items—of what you're building, in the order you plan to build it. Not a roadmap with quarters and color codes. A ranked list. Item one is active. Item two is next. The rest follow.
When someone asks about a feature, point them to the list. They can see where it sits relative to everything else. That answers the priority question immediately.
Show what's done. As work finishes, move it to a "recently shipped" list. Keep it visible. A growing list of completed work builds more trust than any projected date. Momentum is tangible in a way that promises are not.
Talk about scope, not time. Instead of "this will ship in three weeks," say "this has three parts—authentication, the settings page, and the migration path. Part one is done. Part two is in progress." People can follow along. They see the shape of the work and can form their own estimate of how fast you're moving.
Dates create a binary: you hit them or you miss them. Sequence and scope create a gradient. Stakeholders can watch progress accumulate. They see when something takes longer than expected and understand why, because they saw the scope.
This also protects you from a trap that kills focus on small teams: the temptation to cut quality to hit a date. When you've committed to a date publicly, shipping something half-finished on time feels better than shipping something solid two days late. That instinct is backwards, but it's real. Remove the date and you remove the incentive to ship junk.
Dates are appropriate when there's a hard external constraint. A conference demo. A contractual obligation. A regulatory deadline. In those cases, the date is real—it exists in the world independent of your work. Scope should flex to meet it.
But most dates small teams give are self-imposed. They exist because someone asked and the builder felt obligated to answer with a number. That obligation is worth resisting.
The first time you tell an investor or early customer "I don't give ship dates, but here's exactly what we're building and in what order," expect a pause. It sounds unusual. But follow it with a clear sequence, a short scope description, and a pointer to recent work, and most people respect it. Some will prefer it.
You're trading false precision for real transparency. That trade almost always builds more trust over time.
A Gantt chart makes a team look organized. A short list of what's done and what's next makes a team look honest. For small teams, honest wins.
Be the first to comment.
0 comments
Loading comments...