Back to Garden
stream

Don't estimate

Stop estimating. It's barely useful in product development. Especially when you're trying to figure out what the hell to focus on next.

https://peppesilletti.io/content/stream-1/

Stop estimating. It’s barely useful in product development. Especially when you’re trying to figure out what the hell to focus on next.

And that really smell like waterfall. Bleah.

The very nature of product development is often exploring unknown territory. We’re trying to solve problems for users in ways that might not have been done before. This inherent uncertainty means that any attempt to quantify the “amount of work/complexity” upfront is, at best, a guess and, at worst, a misleading commitment.

The “work” in product development isn’t just writing code or designing interfaces. A significant part of the work is learning: understanding the problem better, validating assumptions with users, discovering technical challenges, and iterating based on feedback. These learning cycles are unpredictable in their duration and impact on subsequent work.

Since we learn as we go, the scope of what’s needed to solve the problem is likely to change. We might discover a simpler solution, a more complex edge case, or that a planned feature isn’t needed at all. Trying to estimate a fixed “amount of scope” for a moving target is futile.

And no, adding a “buffer” doesn’t help. How much buffer do you choose? A random multiplication by 10?

Try this instead:

  1. Start with a business problem and understand what outcome you want
  2. Gather your team, engineers, product managers, designers, and key stakeholders to understand the problem together from diverse perspectives, redefine it if needed, research, validate assumptions, prototype, and experiment quickly in the agile spirit
  3. From this discussion, multiple solutions with varying complexity may emerge. This is the only place where “estimating” complexity makes sense: to understand which solutions are more challenging to build and how to split that complexity in manageable pieces
  4. Focus on scope, not time. Decide the minimum functionality that solves the problem, build it, and ship it
  5. Measure impact, gather feedback, and iterate. You could just stop at the first iteration if that works

Estimations ignore all the work required to create something truly valuable for users.

So please, for your business’s sake, stop estimating. hashtag#noestimations