How to Prioritize Features When Engineering Says “That'll Take Three Months”

The pattern is almost always the same. Engineering gives you an estimate that feels too long. You push back — “can we get it down to six weeks?” — and eventually the number comes down. Three months later, the feature ships late anyway, the original estimate turns out to have been closer to right, and you're left wondering whether your team is just bad at estimating. They're usually not. What happened is that you compressed a timeline without changing the underlying scope, and the estimate became a commitment that engineering couldn't keep.

Engineers aren't sandbagging when they give long estimates. They're doing something more complicated: translating uncertain work into a number that has to survive contact with reality. An estimate contains invisible structure — the work that's well-understood, the work that's uncertain, the dependencies on other systems, the coordination overhead, and the expected interruptions. When you push back on the number without understanding the structure, you're not removing any of that work. You're just creating optimistic fiction that the team then has to live inside.

The expensive mistake isn't building features slowly. It's building the wrong scope at the right speed while convincing yourself you're moving fast. Founders who understand how estimates work can have real conversations about scope reduction — often discovering that a version of the feature that takes 20% of the time solves 80% of the user problem. That's a legitimate prioritization decision. Pressuring the team to compress the timeline without changing scope isn't.

Engineers build estimates by estimating uncertainty, not just work. A rough order-of-magnitude estimate — the kind given in a planning meeting when you ask about a feature you haven't fully scoped — carries roughly three times the error range. If someone says “that's probably a two-week thing,” the actual range is one to six weeks. A refined estimate, done after the feature is reasonably well-specified, carries about 1.5x uncertainty. A fixed-scope bid, where every technical decision has been made and the work is fully broken down, approaches near-certainty — but getting there requires a level of upfront specification that most startups don't do. When you hear an estimate, your first question should be: what type of estimate is this?

Technical dependencies are the single most common source of estimate surprises. When an engineer says a feature “depends on” another system, they mean that the feature can't be completed until some other piece of work — either already in progress, not yet started, or owned by a different team — is in a specific state. These dependencies aren't always visible in the estimate number; they're often embedded in the assumptions underneath it. An estimate that says “six weeks” might actually mean “six weeks after the authentication system supports multi-tenancy,” which itself takes four weeks. Without surfacing that dependency, you're planning against a ten-week timeline that looks like six.

When you receive an estimate that feels wrong, don't start with “can we do it faster?” Start with “walk me through what's in this estimate.” That framing signals that you're trying to understand, not negotiate — and engineers respond very differently to those two postures. What you're looking for in that conversation: the scope the engineer assumed (often broader than what you intended), the dependencies underneath the estimate, and the single most likely thing that would make it take longer than estimated.

Ask specifically about the “happy path” versus the full feature. A surprising amount of engineering time goes into edge cases, error handling, and the states that users don't normally see but that need to be handled gracefully. If the estimate includes all of that and you only need the happy path working for a limited beta, you can often get to a usable version in a fraction of the time — but only if you explicitly agree that the rest will come later. “Ship something now and clean it up later” is a legitimate product decision, but it needs to be made consciously, not by accident.

Ask what the most uncertain part of the estimate is. Engineers almost always know where the unknowns live. If they say “the third-party API integration is the uncertain part,” that's information you can use — you might be able to build a version of the feature without that integration first, reducing uncertainty before you commit to a timeline. Surfacing the uncertain components lets you make sequencing decisions that reduce your overall exposure, rather than committing to a complete estimate that carries concentrated risk.

You have exactly three levers that actually affect how long something takes: scope, sequence, and resources. Scope is the most powerful: build less feature, build it faster. This requires a real conversation about what the feature needs to do for users on day one versus what it would ideally do, and it requires the discipline to ship the narrower version without immediately expanding it. Sequence lets you reduce uncertainty before committing to a timeline — build the risky or unclear parts first, learn from them, and plan the rest of the work with better information. Resources — adding people — rarely helps as much as expected on in-flight work, because new engineers need ramp time and require existing engineers to context-switch to support them. Adding people at the start of a project is different from adding them mid-project.

Technical debt changes the real cost of all three levers. A team carrying significant technical debt will give you longer estimates for everything, because every new feature has to thread through existing complexity. When your team says “the MVP will take three months,” part of what they're telling you is how much debt they're carrying. If you've been building fast without refactoring, the compounding cost of that debt shows up in every subsequent estimate. Addressing debt isn't a distraction from shipping — at some point it's the only way to get estimates that feel reasonable again.