Estimation vs. appetite
Estimation belongs to engineering. And yet I end up doing a lot of it, accurately, and people are often confused about whether that's product’s place. I think they're seeing it as black and white when it isn't.
First, let's agree on the obvious: if you're not technical or you haven't spent years on product teams, you're probably not a good estimator. We've all met the cofounder who thinks a major database migration is a two-day project, or the sales lead who insists a UI improvement that takes minutes, especially with AI now, is jumping ahead of the roadmap, when both fit because the roadmap are big rocks and the change is a few grains of sand.
But for those who have been working with teams for years, two different things are going on.
The first is pattern matching. Knowing how long things take because you've shipped those things. Knowing the difference a stack makes, or the level of complexity. Having put work into sprints and watched, time after time, year after year, it land in roughly the same window.
The second is a negotiation disguised as an estimate, which is called appetite. In Shape Up, the development methodology from Basecamp, appetite is defined as the amount of time you're willing to spend on something. I don't subscribe to Shape Up wholesale, but this idea is essential for roadmaps, sequencing, urgency, all of it.
Regardless of whether anyone in your organization uses the word (in my experience, they rarely do), I practice appetite-driven development. I know from experience how long we’re willing for a project to take, and I scope it accordingly. When my team tells me the work will take longer than I've scoped—which, let's be real, is the only direction estimates ever go—I slim down the scope. Revolutionary, I know. I talk with the team, stakeholders, and use my own product sense about what's essential and what's optional, cut the optional, preserve the appetite, and schedule the rest for later.
This came up on my team recently, and there was some surprise that engineering agreed with my estimation. But by the time I gave it, I'd written several iterations of the scope, spent time understanding the backend and its complexity, and had teams shipping my projects for 11 years. Being right about how long something takes shouldn't be the surprising part.
So if your estimations feel like guesswork, here's what I'd ask you:
Are you tracking how long your bugs, one-off tickets, and projects of different shapes (UI-only, new backend, tech debt) actually take to ship?
When you start requirements for a new project, do you write them straight through, or do you first sit down with your engineers to learn the current state of things?
After you've drafted a PRD, do you present it as "this is what we're doing," or is it a conversation, many conversations? Does your team push back? Do you incorporate what they say? Do they help you add and remove scope? If not, the problem may be how you lead and the relationships you've built.
Are you accounting for the actual people on your team? The ones who consistently ship fast versus the ones who reliably take twice as long? If you're not, your estimates are too generic to match reality. And if you don't know who'll be assigned yet, ask your engineering manager to soft-assign someone, even if it changes later.
Do you ask your stakeholders what their appetite is?