On Collaborative Estimating with Product Functions🤝
When dates can't move, we aim to "deliver the best thing we can, by that time."
When dates are unreasonable, we push back on areas that matter, and be willing to find creative solutions for those that can wait.
Good estimating requires everyone to be on the same team, focused on the customer.
The Two Paths to Dysfunction
There are two ways engineering-product relationships break down around estimation, and I've seen both destroy otherwise talented teams.
Path 1: The Padded Estimate
Engineers feel pressure. Product always pushes for faster delivery. Deadlines feel arbitrary. So we start padding.
"This will take 2 weeks" becomes "This will take 4 weeks" becomes "This will take 6 weeks, and we'll still probably need more time."
We tell ourselves we're being protective. We're being realistic. We're accounting for unknowns.
But here's what actually happens:
Eventually your estimates will be "unpadded" for you.
You may lose true ownership of your estimates. The process will change around you. Someone else will be asked to do your estimates for you. Leadership will start applying their own "conversion factors" to your numbers.
And now the trust is completely broken.
Path 2: The Pressure Cooker
Product has commitments. Sales made promises. Leadership set expectations. So Product starts pushing.
"Can we get this faster?" becomes "We really need this by Friday" becomes "I told the CEO it would be done today."
Product tells themselves they're being customer-focused. They're being realistic about business needs. They're pushing for excellence.
But here's what actually happens:
Engineers start giving optimistic estimates to avoid conflict, then missing them.
Quality suffers. Technical debt accumulates. Burnout sets in. And when everything inevitably slips, the trust is completely broken.
What We Lose When Trust Breaks Down
Both of these paths lead to the same place: lower quality and extended timelines.
When engineers pad estimates:
- Product can't roadmap effectively
- Real bottlenecks get hidden in the padding
- We deliver slower than we actually could
- Innovation gets stifled (why suggest a faster approach when you've already committed to 6 weeks?)
When product pressures engineers:
- Estimates become meaningless guesses
- Technical decisions get rushed
- Quality issues compound over time
- Engineers stop caring about accuracy (if you won't believe me anyway, why bother?)
I've watched teams spend more time arguing about estimates than it would have taken to just build the thing.
The Collaborative Estimation Framework
Here's what works. I've seen this transform dysfunctional teams into high-performing ones.
1. Start with the Objective
Not: "How long will this take?"
Instead: "What are we trying to achieve for the customer, and by when do they need it?"
This frames the conversation correctly from the start. We're on the same team, solving for the customer.
Real example: Product wanted a new dashboard feature. Instead of asking "how long?", they asked "We have customers asking for visibility into their usage patterns. What's the fastest we could get them something useful?"
That changed everything. Now we could discuss:
- MVP vs full solution
- Which metrics matter most
- What could wait for v2
- Technical tradeoffs and their timeline implications
2. Acknowledge Constraints Honestly
When dates truly can't move:
Product: "We have a hard deadline for [concrete business reason]. What's the best thing we can deliver by then?"
Engineering: "We can deliver X by that date. Y and Z would need to wait for the next iteration."
When dates are negotiable:
Engineering: "To do this right takes N weeks. We could cut corners and do it in M weeks, but here are the specific tradeoffs..."
Product: "Let me check if we can move the date. If not, let's discuss which corners are acceptable to cut."
3. Make Tradeoffs Visible
This is where the magic happens. Instead of "impossible" or "I need 6 weeks," we map the terrain:
- Core functionality: 2 weeks
- Edge case handling: 1 week
- Performance optimization: 1 week
- Polish and UX refinement: 1 week
Total: 5 weeks for "done done." But now we can have a real conversation.
Maybe we ship with known edge cases documented. Maybe we plan a performance sprint after initial launch. Maybe the UX is "good enough" for v1.
The key: Engineering owns the technical assessment. Product owns the priority calls.
4. Build in Learning
Here's what senior engineers know that junior engineers often don't: estimates are learning opportunities.
After each project:
- How did our estimate compare to reality?
- What did we miss?
- What took longer than expected and why?
- What was faster than expected and why?
Share this with Product. Let them see your process improving. Let them understand what drives complexity.
This builds trust both ways.
Moving Forward
Next time you're in an estimation discussion, ask yourself:
As an Engineer:
- Am I padding this estimate to protect myself, or am I giving my honest best assessment?
- Have I explained the tradeoffs clearly enough for Product to make informed priority calls?
- Am I treating Product as a partner or an adversary?
As a Product Manager:
- Am I pressuring for a number I want to hear, or am I listening to understand?
- Have I explained the customer need and business context clearly enough for Engineering to optimize?
- Am I treating Engineering as a partner or a resource to be managed?
The best estimates come from trust. Trust comes from transparency. Transparency comes from collaboration.
When we're all on the same team, focused on delivering value to customers, estimation becomes what it should be: a tool for planning, not a battleground for competing priorities.
And when that happens? We soar.