I’ve been a gamer for far longer than I’ve been anything else in my life.  From the early days of playing Combat on my Atari 2600, to Fastball! on my Commodore 64, all the way through to Skyrim on my PC or Destiny on my XBox One, I’ve always been interested in the cutting edge of gaming technology as well as the games that are played on it.

And, as both a gamer and a Product Manager, I can promise you that there are many things that we can learn from any given genre of gaming.  In this installment of the series, I’m going to focus on role-playing games — the Ultimas of the world, the Skyrims of the world, and the Dragon Ages of the world.  So here’s a list of the top 5 things that a Product Manager can stand to learn from the common tropes of role-playing games over time:

1. Know Your Class — And Play to Its Strengths

In most role-playing games, you start out by choosing a character type — often these are archetypes like a fighter, wizard, cleric, or something similar.  Each of these classes has different abilities, different focuses, and overall different strengths and weaknesses.  When you choose one of these characters, you have to accept that they will define how you approach different situations.  If you start off with a wizard who wears cloth armor and can’t use anything more powerful than a staff, you probably aren’t going to to rushing in to every battle waving your stick around like a madman.  Similarly, if you’re a standard stock warrior, you might stand a chance of rushing in without a second thought, but when it comes to unlocking a chest without damaging anything it contains, you’re probably going to be completely out of luck.

In a very true sense, everyone has a “class” in their daily lives and in their jobs.  You have strengths and weaknesses that affect how, when, and where you are able to leverage your talents and skills.  Not everyone is the best when it comes to speaking in front of large groups; not everyone excels in heated and emotional negotiations; and not everyone has the technical expertise to call a developer to the carpet when they make a clam that’s not substantiated.  It’s important as a Product Manager to know what our “class” is, what our strengths are, and where we need to stop and ask for help or assistance from others in our organization.

Which leads us directly to…

2. Create a Party That Complements Itself

In many role-playing games, particularly classics like Baldur’s Gate, players can build a party of characters comprised of non-player characters that they meet in their travels, or that they create at the outset of the game.  When you create such a party, you’re always best off with creating a balanced party – typically around the four archetypes – wizard, fighter, cleric, and thief, or some combination thereof.  The importance of this balance is based on the strengths and weaknesses of the individual party members, which require that you select the group of characters that can, as a whole, approach nearly any situation.  Try to fight the undead without a cleric?  Good luck.  Try to raid a dungeon held by trolls without a fighter to kill them and a mage to burn their bodies?  Good luck.  Run into a series of traps without a thief, bard, or rogue to disarm them?  Game over.

And, in our day-to-day functions as a Product Manager, we’re required to put together “parties” of our own, to tackle the challenges and demands of our daily lives.  We rely on sales teams to bring in information about prospects and renewals; we rely on support teams to tell use the acute pain points of our existing customers; we rely on development teams to execute the hardcore technical work that they excel at.  Each of these groups can be considered part of our “party” as product managers — with the overarching quest of identifying valuable customer problems and creating solutions that they’re willing to pay for.

3. Know Which Choices are Permanent

Depending on the game, some choices that you make cannot be reversed — these may be choices about how to upgrade your hero or your party, or they may be specific plot points in the storyline that have long-term implications for the characters you’re playing, the quests that you’re offered, or even the fictional world as a whole.  It’s important in the game to know which changes are permanent, so that you can achieve the outcome that you want — and so that you know when and where to spend your upgrade “points” to direct your character in the direction that you want it to go.

And, just as some choices in games are permanent, some choices that we make as Product Managers are permanent as well.  Shelving an R&D project so that we can focus on something else that has more promise in the market; sunsetting an aging product so that resources spent maintaining it can be better deployed elsewhere; making the decision to let a long-time customer go because their needs no longer match the needs of the overall market.  We’ve all been faced with these kinds of decisions, but we should bear in mind that, unlike plot points or stat increases in role-playing games, the vast majority of the decisions we make every day are not permanent, and can be changed relatively easily to reflect new information and market knowledge.  But your should always keep your eye out for those decisions that are permanent, and weigh them with more care.

4. Keep an Eye on Your Quest Log

A common trope of role-playing games of all shapes, sizes, and genres is the “quest log” — some collection of tasks that you have chosen to undertake, each of which has a discrete form of reward attached to it.  In online role-playing games, these are often things like “collect 20 wool from the sheep of the valley,” or “collect 15 scalps from your enemies” (yeah, the quests can be rather gruesome sometimes).  In other role-playing games, the quests might be to find something or someone specific, or to explore a new area where — surprise! — you find more quests for your log.  Further, each of these quests often have different priorities, and different levels of the plot that they play to — there are often the mandatory main quests that drive the story itself forward; class- or party-based quests, which are designed specifically to further your character(s) personal stories or abilities; and side quests which are usually entirely optional (and which we’ll get to momentarily).

As Product Managers, we often view our “Quest Log” as strictly our backlog — but that’s not entirely true.  Just as the role-playing game Quest Log has more than one level to it, so should our Product Management Quest Log.  We need to constant be looking at how we are progressing against the overarching storyline that we’re trying to bring to market – the vision, mission, and strategic direction of the company.  Then we need to keep in mind the interim planned steps that we’ve laid out in our product backlogs and in our strategic plans.  And, just like the side-quests, we need to be mindful about how smaller, more incremental improvements to our product can have massive cascading effects on our value to our users.

And, speaking of side-quests…

5. Don’t Ignore the Side-Quests

I’m a side-quest addict. There, I admitted it, and I feel better for it.  Nearly every single role-playing game ever created has side-quests, which are tasks and responsibilities that have absolutely nothing to do with your character, your party, your class, or the overarching storyline.  You might wander into a village and someone will ask you to chop wood for them.  In return, you get 5 gold pieces (nevermind the armor you’re wearing is worth 5,000).  i guarantee you, every time I come across one of these I do it.  Just to see what happens — because sometimes the crafty writers of these games hide storylines from you, or rewards, or even entirely disruptive events, behind something as simple as chopping wood for a villager.

Now, as a Product Manager, the reality is that we can’t chop wood for every villager that we come across, just in case it’s disruptive.  But, we can assess these requests, and when it comes time that there’s a very small gap in the teams’ availability, push something through that we know doesn’t directly address a strategic goal, or a tactical need, or even something on our current backlog — but something that we think might make a difference to our end users.  It’s exceedingly rare for such a small bet to have a big payoff, but when it does, it’s like magic.  So, the next time a stakeholder asks you to chop a bit of wood for them, think about whether or not that’s a nugget of wisdom to store for a later opportunity.