In my time as a product manager, I’ve found myself in a variety of situations that some of the best minds in product management have long warned about. I’ve tried to make the most of these situations, even if what transpired wasn’t the best possible outcome. They’re called pitfalls for a reason: it’s easy to get caught up in doing what seems right, only to wind up dealing with the fallout and entanglement of your best intentions. Simple product management mistakes often have long term ramifications, or just take a long time to undo. Before you find yourself stuck in these traps, I hope these points help you do better for your teams and your products.
Note: I can’t take credit for many original ideas here, and can certainly identify references for most of them. To that end, there’s some recommended reading at the end of this post.
Timing the Roadmap
There’s two schools of thought with a product roadmap: include timelines on your roadmap, and don’t include them. I firmly fall in the “no timelines” camp, for a key reason: a product roadmap is not a project plan. Projects have identified scope, budget, outcomes, and estimated timelines. A product roadmap can include aspects of these (especially problem/scope identification and key outcomes to influence), but shouldn’t be a list of hard and fast initiatives with due dates. A good product manager should work with a project delivery team to shore up all these elements and build project plans and backlogs, when necessary, but that’s not the same thing as the roadmap proper.
Within a very short period of time, a product manager who commits to providing timelines will find themselves answering questions like, “When will that feature be out?” instead of asked to measure problem opportunity and value. The role of the product manager will morph into pushing the team to deliver on a set date, rather than toward a set outcome. Achieving business outcomes are always more valuable than specific dates. (But yes, an outcome may sometimes require hitting a particular date — more on that below)
I find that roadmapping tools like ProdPad provide a great platform to measure user need/impact, business value, and priorities. Aha! allows for specific quarters and actual dates - be careful there. I much prefer the ProdPad method or a rough sorting of priorities in team, like Now, Next, Near, and Horizon. A product manager can use these labels to show a team’s current focus, and update on priorities to leadership, without having to commit the entire team to a specific due date.
Commitments
On that note, it’s worth reiterating: make NO commitments for the team without involving the team in the decision. A product manager may find themselves in discovery sessions, client meetings, or executive summits, and be asked to deliver a particular feature or functionality, or to have something done by a particular date. You, alongside your counterparts in technology and project management, will have to play a defensive role to protect your team. Personally, I’ve found myself in more then a few awkward moments when I won’t commit to something and slow down the momentum of a productive client or stakeholder encounter. It’s worth suffering these difficult moments to prevent weeks or months of pain.
How should this commitment work? Include the team! Invite as many as possible to discovery sessions or workshops. Hold round table requirements review sessions, and work with them on a comfortable form of estimating (spoiler: no estimation process is perfect). Work with project management to appropriately pad all estimates for error, and include for planning, design, copy, QA, marketing and training. Only then can you provide solid dates and milestones to your stakeholders, and only then can they see just how much goes into every project your team embarks upon.
Crunch Time
If your team has committed themselves to completing a project by a certain time, and realizes extra effort is needed, you can choose a crunch time window or two to get things done. Crunch time is a short term thing, and should rarely be deployed. This is typically a bloated sprint with extra work, requiring longer hours, weekend work, or even an offsite retreat together to get the work done together. I hope it’s clear that “together” also includes product management and any leadership affiliated with the crunch time project: you should be invested, too. When getting into crunch time, have clear expectations of the goal, the time requirements, and allow as much volunteering as possible. When getting out of crunch time, hold a post-mortem session to talk about what happened, and how the team can work to avoid or make the most of crunch time in the future.
This is not meant to be a sustainable working pace, but something your team might only do once or twice per year, if that. Once your team has made it past this crunch time window, expect a similar but opposite decompression period where work output is decreased and productivity or time working is reduced. Your team will need time to balance out the extra work they’ve put in. If you don’t allow for this, or you continually push for crunch time month after month, you will burn people out and they’ll either leave, or worse — they’ll stay and become bitter or unproductive. Their work output will almost certainly be subpar and their attitude may turn toxic. Sadly, this is not their fault, but a result of pushing the team to constantly hit artificial deadlines or due dates.
Decision Making
As your team chooses what to work on next, refer back to your prioritized roadmap often (and don’t change priorities more than once a quarter). Repeat yourself in terms of these priorities — become annoying in your sameness of your priorities. Your team can only work on a handful of things at a time, and that includes planning, ideating, and estimating. Leadership and the business needs to be comfortable with certain things sitting on ice. You should limit your focus as well, and spend time researching, talking to users, and writing towad your priorities.
When building a roadmap, brief, or spec, I’m a believer in the phrase, “Strong Opinions Weakly Held”. Use your experience, insights, and research to stand up confident plans to that future world of what your product should be. In this confident stance, a good product manager holds a few things in mind:
Strong Opinions, But…
The “Weakly Held” part of the phrase means you’ll quickly change decisions, specs, or requirements when presented with compelling data, evidence or just good sense. You have to make sure your team knows this, or else you’ll find them following along with your plan but quietly disagreeing with its tenets. Make sure your team is well aware they can make your plans better, and that they are just as responsible as you are for the successful outcomes you’re driving toward.
Decentralize Decision Making
Not every decision needs to run through the hands of the product manager. Push them to think about outcomes, not specific actions, and release them to do what they do best. The team is smart, subject matter experts and can go off and figure things out without you. Give feedback when they delay because you weren’t around to approve a small but logically solid change. Otherwise, you will become a bottleneck to the creative process, and you will limit the creative potential of the members of your team. Just ensure they remain focused on priorities and goals, and they’ll help you get there.
Comfortable with Uncertainty
As a product manager, your job is to measure the business value and the user need, and express these problems and goals to your delivery teams. With these three disparate areas intersecting, you will be wrong. Often. You need to learn to be comfortable in this wrongness, and learn to pivot toward correct thinking. It’s ok to be wrong, as long as the team knows your intent and is there to help move to the right place together.
Similarly, your team needs to be comfortable with this uncertainty. Your spec may not be intensely detailed. You may not have completed all the research you’d have liked to. The team should be comfortable knowing that you haven’t figured it all out yet, and should get excited with the gaps they get to fill in along the way. Encourage them to participate (not just in planning a sprint or a list of dev tasks, but planning how to achieve your goals) and watch their investment in the product grow.
Going Forward
I’ve touched on just a few tactics and issues faced in the role of product management, but they’ve all got common touchpoints. Every day, the product manager spends time moving the product, the team, and the business forward. There’s always room for improvement in decision making, process, and people skills. I hope you’ll find this useful as you tackle these issues and grow in your role and in your company.