As engineering managers, we are responsible for helping our teams deliver projects. But before we can deliver, we need to decide what to work on and what we can reasonably take on. This is where our working relationship with the product manager becomes important.
The product manager may see an opportunity for our customers while we see the technical work needed to get there. Both matter. If we plan separately and only compare notes when the dates are already promised, we make the job harder for everyone.
Understand what we are trying to do
Before estimating a feature, we need to understand the problem it is meant to solve. Who needs it? What would be different for them if we built it? Why is it more important than the other things we could do?
These aren’t questions for the product manager alone. We need enough product knowledge to help make the decisions. If we understand the goal, we may be able to suggest a simpler approach. If we only have a list of requirements, we can miss that opportunity.
For example, a feature may require a change to how we store data. We should bring that up during planning, not after the work has started. Does the whole feature need that change, or can a smaller version solve the immediate problem? The answer will affect both the scope and the order of the work.
Explain what goes into an estimate
An estimate is based on what we know at the time. Some work is familiar, and some needs investigation. Giving a date without explaining the difference can make both sound equally certain.
We can give a range and explain what might change it. If we are unsure about a database change, say so. We may need to investigate it before making a firmer commitment. That is more useful than adding time without explaining why, or pretending we already know the answer.
Technical work needs the same explanation. Saying that we need time for refactoring doesn’t tell the product manager much. What is difficult about the current code? Is it causing bugs, slowing down changes, or preventing a planned feature? We need to connect the work to the problem it solves. We should also be careful not to promise a precise improvement that we haven’t measured.
Account for the work that is already there
The team doesn’t spend all of its time building new features. There are production issues, maintenance, and requests that come up during the week. If we fill the roadmap as though none of these things will happen, we are likely to fall behind before we get very far.
I don’t think a fixed percentage for each kind of work will fit every team. We can look at what has been taking the team’s time and use that when planning. If there isn’t enough room for everything, we need to decide what can wait. Leaving that decision until later doesn’t make the team have more time.
Make the choices together
When a requested date isn’t realistic, we should explain the options. Can we reduce the scope? Can we move another project? Would a later date let us do the work properly? Each choice has a cost, and the product manager needs to know what it is.
This conversation needs to continue after planning. If we discover a problem that changes the estimate, bring it up early. Explain what we have learned and which choices are still available. Waiting until the deadline leaves everyone with fewer options and makes it harder to trust the next estimate.
Summary
Planning a roadmap requires us to understand the product as well as the engineering work. We can help by asking about the goal, explaining uncertainty, and being honest about how much the team can take on. The plan will change as we learn more. Having a good working relationship with the product manager makes it easier to work through those changes together.