Ankle Biters: Project Management
This is the first post in a new series I’m entitling Ankle Biters. Ankle Biters are the little tactical things that you need to do to keep the lights on, but aren’t strategic to Product Management and consume resources from the most important job, being the Vox Mercati. I’ll use this series to talk about why Ankle Biters are bad (obvious) and tactics to turn Ankle Biters into time well spent (non-obvious).
The first ankle biter is one that most Product Managers should be familiar with: Project Management. You can’t be both the Product Manager and the Project Manager, because the goals of those two roles are not always in alignment. A good Product Manager is concerned with customer problems and good requirements - and you need to maintain a solid relationship with Development to solve these problems. A good Project Manager is concerned with schedules, tradeoffs, risk measurement, and accountability. Sometimes those goals will align, often times they won’t.
It is extremely difficult to beat up the Development Lead for dates, ask why they are behind, why can’t they schedule accurately, where are the roadblocks, etc - and then turn around and facilitate a discussion about customer problems. Project Management is a valuable skillset; it takes a special person to maniacally drive schedules and tradeoffs without making the schedule and inevitable slips personal - after all, it’s about the schedule, not the people. When the Product Manager drives this discussion it alters the relationship between the PM and the Developer. The PM is no longer seen as a collaborator but as a blame agent.
So when you find yourself working at a smaller company and you’re tasked with Project Management and now “own the date,” how do you handle this situation and make the best of it? First, explain to your Executive the pitfalls of maintaining a good working relationship with Development and driving them to hit a specific date. Second, if you haven’t already broken your Roadmap from your Release Plan, consider doing that, as it can alleviate some of the pressure on dates since Release Plan items are by their nature resource-committed. Next, if you’re writing good requirements that are embodied in use case which are backed by customer problems, stack-rank the customer problems and use cases before you meet with Development so you know where you can acceptably trade off. At the same time, huddle with Marketing/Sales and understand the date pressure so you know if there is a tradeshow or some other immediate event driving a specific date.
Last, weigh the use cases and the date and make a cost vs. features vs. time-to-market recommendation to the business. Now you know which hat to wear: Good Cop - Product Manager driving for feature completeness, or Bad Cop - Project Manager driving the team to a date.
Also see: Discussion of how RTS Games Teach Product Managers Resource Management and Tradeoff Skills
Leave a Reply