How Product Managers can help their Engineers make Better Estimates

23 January 2024

1 Comment

“When is that going to ship?”

If you’ve been a PM for more than 5 minutes, you’ve heard this question, which is much easier to ask than answer.

Making matters worse, the question is central to what you do as a Product Manager, while largely being beyond your control; you don’t write the code, nor fix the bugs. The best you can do is help with scope, testing, and relaying information when everyone needs it.

Yet, there’s more you can do to help ship features on time than you may think, which is what we’re covering today.

How to Help Your Engineers make Better Feature Delivery Estimates

When you make the lives of the engineers and designers you work with easier, everything gets better; they enjoy working with you more, it becomes easier to make requests of them, and delivery often happens on a more consistent basis.

And to get all those benefits, it starts with YOU.

Before you start pointing fingers at engineers who “can’t hit a deadline” or “stink at estimating”, try some of these approaches to do your part.

You may be surprised how much this boosts your product team’s morale, and how much more accurate the estimate you receive from engineering become.

1) Break your tasks and projects into smaller pieces.

One of the biggest mistakes I see inexperienced product managers make is to plan for grandiose, multi-month (or multi-quarter!) projects. They have a grand vision of solving every little problem possible and completely re-imaging a part of the product that they own.

While this may feel great for your ego, and even be a bit inspiring to others, it’s a recipe for disaster in practice.

Big Projects = Big Misses.

The fact is, it’s very hard to estimate big projects; the larger the span or reach of the project, the more things that can go wrong unexpectedly, and the more dependencies start to stack up. No matter how experienced an engineer is, it’s hard to accurately estimate massive projects. No one can foresee everything that will come up at that point.

That’s why breaking your projects into smaller pieces is so valuable.

Think about it: If I give you a roughly day long task, and you’re off by 50%, that’s only half a day.

That isn’t that big a deal, and is unlikely to sink your plans and other commitments.

Yet, if I estimate a project will take a month and I’m off by 50%, well, now we have to spend an extra 2 weeks on it. That does start to impact the rest of your roadmap and best laid plans.

Best of all, by breaking your projects up into smaller pieces it forces you to:

  • Prioritize the most important work: You can’t have everything, but you can make sure you get the most important things done.
  • Have real discussions about tradeoffs: Smaller projects means fewer points in your project management tool, so you open up discussions about real tradeoffs instead of simply piling on more to do.
  • Think about big projects in phases: Do you really need to wait to have *everything* you can dream of, or can you launch in phases, possibly even pausing work between phases to give attention to other needy parts of your product?

All of these are good discussions and thought experiments to have as a product leader. By practicing them proactively, you’ll improve your relationship with the engineers you work with, because now your requests won’t feel like you’re always asking for mountains to be moved.

2) Give your Engineers a heads up for unknowns and complex projects.

Quick: You have 5 minutes to think through all the consequences of a massive project that will probably take 3 or more months. Make accurate estimates, and start making project tickets now, because this conference room is reserved for someone else in 22 minutes.

Sounds unreasonable, right?

Yet, that’s exactly what a lot of PMs do. They come to sprint planning meetings with enormous projects that are only defined at a high level.

No wonder engineers miss deadlines. They’re given an impossible task.

Start your discussion well before sprint planning.

You know who the tech lead, scrum master, or other lead planner is on your product team. That means you should start the discussion with them early when it comes to bigger projects or greater uncertainty.

I’ve always found that if I come to the right engineer with a sticky problem or complex question, they’re excited to dig in and see what they can figure out. They’ll then come back with:

  • What the hard parts about that task/project are
  • What they think is reasonably possible
  • Approaches they suggest are hard vs. easy
  • Rough time estimates for various part of the work
  • Suggestions for further research and discussion

The key to all of this though is timing.

While coming the day before sprint planning is better than not coming at all, what you really want to do is give them a week or two warning.

That gives them more flexibility on when they look into it, and it gives them time to really marinate on their answer.

I often find the best engineers will do this over multiple days, talk to some friends and coworkers, test a few things, read some docs, and ultimately come back with a super informed answer IF I give them enough forewarning so that they have time to do it (while completing the rest of their work commitments, of course).

As Ben Franklin said, “an ounce of prevention is worth a pound of cure.” You can save your team a lot of headaches from poor estimations by given your engineers a heads up so they can do more research for your larger and more complex asks.

3) Be flexible on scope, but firm on outcomes.

To be successful long term, product managers have to be pragmatic. If you try to control every detail, and you’re rigid in your approach, don’t expect to deliver a lot. You’ll also frustrate your engineers and designer to no end.

One of the best ways to lead your product team to successful outcomes that are delivered reasonably close to on schedule is to be flexible on how you solve problems, while holding firm to solving the most important problems for your customers.

The truth is, customers do not care how hard or easy what you delivered was. All they care about is if you solved their problem.

Know what to fight for.

Surprises happen. Timelines slip. Fires come up that have to be dealt with. You can’t let projects drag on month over month or quarter over quarter.

When issues inevitably come up, you have to find the right things to compromise on. That means knowing what to fight for and what you can be flexible on. Be prepared to answer questions like:

  • What outcomes are must-have for your customers? There are times where not having something defeats the entire purpose of the feature. You can’t cut that. Fight to keep it in your plans, and explain why so everyone understands your resistance.
  • What is the 80/20 (Pareto principle) of this feature? Yes, we’d all LOVE to build everything we can dream of, but when racing to product/market fit, or simply overrun by roadmap demands, you have to focus on the highest impact aspects. What will add the most value for the least effort or number of features?
  • What can wait? It helps if you already have a few things in your back pocket that you’re okay de-scoping from a project. Maybe it can fit in a “Phase 2” of a project, or you can squeeze it in as part of a quick iteration post launch.

The beauty of a high performing product team is that you don’t have to have all the answers. Engaged engineers and designers want to help you get the best outcomes for customers. When you get stuck, they can help you come up with the best solutions given your constraints on time, resources, and tech challenges.

Through all those discussions, it’s your job to keep things anchored in the reality of what needs done. That means remembering the metrics and outcomes you’re driving towards so you cut and keep the right things.

4) Write clear, concise, effective product specs 

You know what often precedes a poorly planned sprint? A poorly written product spec.

You get out what you put in, and too many PMs shortchange their product specs. They either rush them, so they only have half of the information needed, or they bloat them with so much fluff and fill that no one wants to read them.

Both of those extremes are recipes for disaster.

Great product specs are a precursor to accurate estimates.

When you give your engineers and designers a product spec that covers everything they need to know, and makes clear the priorities, it’s much easier for your product team to come up with the best possible solution within the constraints you have.

Unfortunately, a lot of product specs shortchange this kind of information, sometimes even spending a lot of time dictating the solution to their engineers and designers instead.

Don’t do that.

Instead, make sure your product spec includes key information including:

  • Why are we working on this? This sets the narrative and should share the hard data that justifies making this the priority to work on.
  • What problems do we need to solve? These should clearly lay out what this project should address. They should be ranked so you’re all on the same page, and know what can and can’t be cut.
  • What are future considerations for this? You can’t always build everything you want, but by having a section for this, you help your team make better decisions anticipating these things coming. This will save you time & frustration later, and gives you a clear place to move things that get descoped.
  • What is our KPI/OKR/Metric for this? This ties back to your why. It helps measure success or failure and keeps everyone focused on what you’re trying to do. Remember: shipping is not success as a PM. Driving successful business outcomes is.

Creating a succinct, clear, and effective product spec is a big challenge and an important skill for every PM to master. If you think yours could use a tune up, check out How to write a Product Thesis, which I learned from Silicon Valley investor and product leader, Josh Elman.

Product specs are a high leverage activity for product managers; when you do the work to have the right information and then organize it well into a quality spec, you may be surprised how much easier it is to work with your engineers and designer. Your improvement in this area will then set up your team to give you better estimates.

5) Talk about estimates and scope before you plan a sprint

Yeah, I know. Who wants another meeting?!? In this case you do.

One of the most powerful meetings you can have comes from the meeting before the sprint planning meeting.

In this meeting, you go over your product spec, talk about the project goals, and then bounce ideas around until you settle on what’s possible given the needs, constraints, and possibilities everyone comes up with.

This is literally my favorite part of being a product manager, yet it seems many people don’t know about it nor do it.

Thankfully, Steve Jobs led the way on these.

Steve Jobs and the Cauldron

No, this isn’t some kitschy Product Manager’s children’s book. It’s a real thing that Steve Jobs did at Apple regularly. As shared by Glenn Reid, who worked with Jobs at both NeXT and Apple, cauldrons are a magical small group meeting where great products are born:

"When I worked with Steve on product design, there was kind of an approach we took, unconsciously, which I characterize in my mind as a "cauldron." 

There might be 3 or 4 or even 10 of us in the room, looking at, say, an iteration of iPhoto. Ideas would come forth, suggestions, observations, whatever. We would "throw them into the cauldron", and stir it, and soon nobody remembered exactly whose ideas were which. 

This let us make a great soup, a great potion, without worrying about who had what idea. This was critically important, in retrospect, to decouple the CEO from the ideas. If an idea was good, we'd all eventually agree on it, and if it was bad, it just kind of sank to the bottom of the pot. We didn't really remember whose ideas were which -- it just didn't matter."

Most importantly, this small group discussion focused on creating the best possible outcomes for customers:

"...it wasn't magic, it was hard work, thoughtful design, and constant iteration. Doing the best we knew how with what was available, shaping each release into a credible, solid, useful, product, as simple and direct as we could make it. And we shipped those products, most importantly."

You have great engineering and design resources on your team. Why would you not want to involve them in coming up with the best possible features?!?

When you know you have constraints to work within, and want to create the best product, then you should be like Jobs and leave your ego at the door. It should not matter if YOU came up with the idea; it should matter only that your product team delivered the best possible product to your customers.

And that comes by meeting to discuss ideas in a free form, creative way, like the cauldrons Steve Jobs used to have.

Then, once you have all the best ideas, and have accounted for the goals, constraints, deadlines, and demands of the project, now, you can move to the nitty gritty details of sprint plans and detailed estimates.

By having this discussion before any estimating, you give you and your team room to consider a variety of ideas. The end result will turn out to be better than anything you or any peer could have come up with alone.

Better solutions, better outcomes, all with better estimates. What more could you ask for?

You have more control over engineering estimates than you think.

You’ll notice none of these suggestions involve playing project manager. None of them involve standing over your engineers barking orders, nor criticizing and complaining, either.

Instead, it gives you ownership over a process that addresses the issues that often exist upstream of engineering estimate issues.

When these areas are done well, you’ll often find a lot of your other problems go away; not only will your engineers improve their estimation ability, but your working relationships will improve, morale goes up, and you will likely start shipping more product with better outcomes.

Do you need help with your product team?

I help VPs of Product, Heads of Product, and 1st PMs at early stage startups that are struggling with critical issues like churn, growth, product velocity, product team dynamics, and stakeholder relationships.

If you’re a founder who would like a coach to help your VP / 1st PM, or you’re a product leader who wants help, learn more about the work I do & happy clients here, or sign up for a free call to discuss your challenges here.

Image credits: Icons by noomtah at Flaticon