PM like a DM (part 1)
Software product managers gets to play in many different areas depending on their skill set and the needs of their company. Their day-to-day responsibilities may include stand-ups, one-on-ones, interviews, and any number of other tasks. Their primary role revolves around developing the product requirements, specifications, timelines, marketing strategy, and competitive analysis (1). There are a remarkable number of similarities between good PMs and Dungeon Masters (DM).
As a DM, you get to choose the setting of your campaign. Will you be in a realm of high fantasy with magic, dragons, and elves? Are you playing a cyber-punk themed game of political espionage? Are the players new adventurers meeting in a tavern for the first time, or are they grizzled veterans tempered in the crucible of a thousand sprints…er, I mean dungeons. Either way, you get to select the environment and ruleset that your game will use. Your goal is to have fun with your friends, roll some dice, create puzzles, and ultimately collaborate to tell a story, or in the case of the PM, to build a product.
A product manager will be working within the constraints of the business objectives of their company, the available staff, timeframe, and budget. This is a lot like players rolling up new characters depending on the level cap of a campaign. The PM must decide how to allocate their resources. Do you spend your budget on a couple high-level wizards, a slew of level-1 junior developers, or a few of the mythical full-stack developers? Do you have a choice or is your team fixed? Can you bring in some hired guns to flesh out the team in a pinch? The answer to those questions will directly inform how you design your sprints, user stories, and tasks.
In addition to playing the role of the DM, a good PM will be making individual contributions that help increase the chances of building a successful product. They may take on the role of a neutral-good cleric being the peacemaker on the DevOps team, the archivist collecting and documenting your tasks, and a paladin defending the sanctity of your scope all in one morning. The PM needs to be able to play the utility-player in order to fill the gaps and needs of their team.
Each sprint (dungeon crawl) is timeboxed into however many weeks (gaming sessions) your group has determined works best. The PM should push your team by creating challenging, but achievable goals while accurately tracking time spent, obstacles overcome, unforeseen circumstances, and progress toward a complete product. In D&D, characters gain experience by overcoming monsters, solving riddles, saving kidnapped nobility, and so on. Developers gain experience by programming, reading, reviewing, experimenting, and more programming.
The PM keeps track of their team’s experience in burndown charts, cumulative flow diagrams, completed epics, etc. The overall level of their team can be equated to the velocity at which the stories are being completed. Your army of level-1 barbarians (junior devs) may be able to crush a horde of gnolls (basic tasks) in a reasonable amount of time, but when they hit the BBEG or an ancient red dragon (designing a complex systems) lurking in the shadows you are setting up for a total party kill (zero story points completed, -10 morale). Sending in your group of wizards trained at the University of Dragon Slaying-for-fun-and-Profit for that particular encounter might be the better assignment. Breaking up that enormous task into smaller and more consumable ones is always advisable. There is a limit to how small you can go in dividing tasks before the abstraction becomes meaningless. Knowing when to rely on your team’s strengths to overcome challenges and when to play to their weaknesses to allow them to learn and grow is another critical role of a PM.
Players in D&D are most often the culprits of TPKs, but in software development, the blame rests at the feet of the PM more often than not. The notable exception being projects broken on the Iron Triangle of Scope, Resources, and Schedule like Ixion was by Zeus. Failure in story sizing, coaching team members for success, planning, competitive analysis, and market research will cripple a team, their product, and potentially their company.
Developers are organisms that convert caffeine into code
— Source Unknown
While the above is more or less true, the ultimate goal of the key stakeholders is to turn developer hours into salable features and products. The key stakeholders will most often not care if you measure your tasks in story points, t-shirt sizes, or D&D monsters (how many skeletons make up one lich anyways?). They need to know how long it will take for you to deliver. Turning your knowledge of the skill level, experience, historic performance, tasks, and composition of your team into a workable timeline that you can deliver on should not be sorcery — even if you make it look like magic.
