Estimating Project Costs

Cagan argues that cost estimation in software stays confusing because management needs cost figures very early, while engineering can only produce accurate estimates after the solution is detailed. This mismatch leads either to wildly wrong early numbers or to sticker shock once the real estimate arrives. He proposes a two-stage approach tied to the product process: a rough T-shirt-size estimate during opportunity assessment, then a detailed, high-confidence estimate alongside the final prototype-based product spec. Engineering should participate throughout the solution work so costs inform design choices. Making the estimate at each stage explicit lets leaders decide with real information. He also suggests tracking the cost of spec and schedule changes, called churn.

01Key takeaways

• Give leadership only Small, Medium, or Large estimates during opportunity assessment, since no solution is defined yet.
• Bring an engineer into solution definition so cost trade-offs shape design decisions as they happen.
• Require a detailed, high-confidence estimate tied to the final spec before committing to build.
• Make the proposed product and its cost explicit so the whole team knows what the investment buys.
• Track the cost of spec and schedule changes (churn) to learn how change affects delivery and reduce it over time.

02Key sections

The core estimation problem

Management needs cost information early, but engineering can't estimate accurately until the solution is well defined. The gap produces either inaccurate early numbers or surprises later.

Rough estimates at opportunity assessment

Before a solution exists, estimates should be limited to Small, Medium, or Large. This granularity is enough for management to judge whether the opportunity is worth pursuing.

Solution definition with engineering involved

The product manager and designer work on a prototype-based spec while an engineer evaluates alternatives and costs them. The product is adjusted based on that input.

Detailed estimate with the final spec

The finished spec comes with a detailed, high-confidence cost estimate, giving leadership a clear basis for the final build decision.

Tracking churn

Changes to the spec and schedule should be measured as churn so the organization understands what change costs and can work to reduce it.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.