How to Estimate Effort Without Engineering Input

TL;DR

• Use analogy to similar past work as your primary anchor, not a guess from scratch.
• Look for specific complexity signals (new systems, integrations, unclear requirements) that reliably increase effort.
• Always label the estimate as rough and preliminary, replacing it with real engineering input as soon as it's available.

Product managers sometimes need a rough effort estimate before engineering is available to weigh in — during early roadmap planning, a stakeholder conversation, or initial prioritization triage. This is never a substitute for real engineering estimation once it's available, but a structured, honest rough estimate is still more useful than either guessing randomly or refusing to provide any number at all.

Quick facts

• Analogy to similar past work is generally the most reliable technique available without direct engineering input.
• A rough pre-engineering estimate should always be clearly labeled as preliminary, not treated as a firm commitment.
• This connects to T-Shirt Sizing vs Story Points, a fitting format for this kind of rough, early estimation.

How to estimate effort without engineering input, step by step

1. Look for a similar past project or feature as an anchor. If your team or a comparable team has built something reasonably similar before, its actual effort (even if imperfectly matched) is a far more grounded starting point than an estimate built from nothing.
2. Identify specific complexity signals in the new work. Does it involve a new third-party integration, touch a system known to be fragile or poorly documented, or have genuinely unclear requirements? Each of these reliably increases effort relative to a simpler, well-understood equivalent.
3. Use a broad relative sizing scale (like T-shirt sizes) rather than a precise number. Given the inherent uncertainty of estimating without real engineering input, a rough "this feels like a Large" is more honest than a specific number of days that implies false precision.
4. Account for unknowns explicitly, rather than assuming a best case. Work involving genuine uncertainty (new technology, unclear scope) should be sized with that uncertainty reflected — err toward a larger, not smaller, rough estimate when genuinely unsure.
5. Clearly label the estimate as rough and preliminary whenever you share it, explicitly noting it will be refined once engineering has a chance to properly assess it.
6. Use the rough estimate only for early, low-stakes purposes — like initial roadmap-level prioritization triage — not for firm commitments to stakeholders or customers.
7. Replace the rough estimate with a real engineering estimate as soon as reasonably possible, and communicate any significant difference between the two transparently.

Why analogy works better than estimating from scratch

Trying to estimate effort for a completely unfamiliar type of work, with no reference point, is essentially guessing — there's little genuine basis for the number produced. Anchoring to a similar past project, even an imperfect match, grounds the estimate in real, observed data rather than pure speculation. The estimate still needs adjustment for how the new work differs from the anchor, but starting from a real reference point produces a meaningfully more defensible rough number than starting from nothing.

A worked example

A PM needs a rough effort estimate for a proposed "export data to PDF" feature during early roadmap planning, before engineering has capacity to weigh in. They recall that a similar past feature — "export data to CSV" — took the team roughly two weeks to build. They reason through the difference: PDF generation typically involves more complex formatting and layout logic than CSV export, and the team hasn't built PDF generation before (a genuine complexity signal, since there's no existing pattern to follow). Based on this, they roughly size it as "Large" relative to the "Medium" CSV feature, explicitly noting in their roadmap notes: "Rough pre-engineering estimate: Large, based on analogy to CSV export plus added complexity of new PDF generation capability — to be refined once engineering scopes it properly."

Common mistakes when estimating without engineering input

• Presenting a rough, pre-engineering estimate as if it were a firm commitment, setting up expectations that may not hold once real engineering input arrives.
• Estimating from scratch without any analogous reference point, producing a number with little real grounding.
• Ignoring genuine complexity signals (new integrations, unclear requirements, fragile systems) that would predictably increase effort.
• Failing to update stakeholders once a real engineering estimate becomes available, letting an outdated rough number linger as if it were still accurate.

FAQ

Is it ever appropriate to give stakeholders a rough estimate without engineering input? Yes, for early, low-stakes purposes like initial roadmap prioritization — as long as it's clearly labeled as rough and preliminary, and stakeholders understand it will be refined once engineering weighs in.

How much should a rough pre-engineering estimate be trusted? Treat it as directionally useful for early triage, not as a reliable number for firm planning or external commitments — the margin of error without real engineering input can be substantial.

What if there's no similar past project to use as an analogy? In this case, be especially conservative and explicit about the uncertainty, potentially sizing the item as a broad range or flagging it as "unknown, needs engineering scoping" rather than forcing a specific number with little basis.

Should PMs try to develop technical estimation skills to reduce reliance on engineering? Building general technical fluency helps produce better-informed rough estimates, but it shouldn't be seen as reducing the genuine need for real engineering input on anything beyond early, rough prioritization purposes.