I like to play a game called Monster Hunter: World. As the name suggests, in this game you will take up the role of a monster hunter who travels the world to complete quests for rewards and to gather materials that can be used to craft better weapons or armors. One way you can accept a quest is by talking to your personal handler who is a commonly hated character online allegedly due to her overly cheerful personality, her seemingly insatiable appetite for getting herself into trouble, or the fact that every player’s palico hugs her first in the beginning cutscene. I’ve always pondered the intention that developers of Capcom had when they designed this character and after more than 50 hours of gameplay, a thought suddenly hit me: the handler’s job is actually quite similar to that of a product manager.
Monster Hunter: World - Handler
Be The Voice of Your Team
Either you find it lovely or irritating, the handler’s voice is the one that you will hear the most often in the game and there is a good reason for it. She goes out to every quest with you, points you to directions that can help you achieve the quest objectives, and acts as a liaison person between you and the rest of the members of the fifth fleet to discover next opportunities. You don’t ever hear your own character speak in the game, but you hear the handler many times.
Although the Astera in the game is an imaginary settlement village, I find it resembles many tech companies in that it has dedicated engineers, researchers, salespeople, and leadership teams. Every successful quest is consequently the culmination of collaboration among all these teams and it takes some dedication to make sure that information are communicated clearly from one team to another and to keep track of the results. The PM's job is also to ensure a high level of collaboration among design, engineering, and business teams and to remove impediments along the way. This requires one to:
- Understand perspectives and motives: One lesson I learned in a Lunch & Learn with Yahoo’s Kelly Hirano is that “People are motivated by different things and something that motives one person may not work for the others”. Simple as that may sound, I find it staggering how many times I failed to keep it clearly in the back of my mind during design reviews or progress check-ins. It is far too easy to be become obsessed with either user experience or business outcomes that I sometimes forget to strike a balance between the two. Are people execution-focused? Are people design-focused? Do people want to polish something well before release or do they not care as long as it can be launched quickly to get feedbacks?
- Employ appropriate framework depending on people and task: Another lesson I learned in the same Lunch & Learn is that “When talking with your team, start with the why and then the decision. When talking with your boss, start with the decision and then the why. When using bullets, always use 3-5 of them”. My interpretation is that depending on who you are talking to and the task on hand, you need to decide and choose the best communication method that gives people the most clarity within the shortest amount of time.
- Support your team in front of others, but tell them the brutal truth in private: Although I have not had the chance to apply this lesson to real-life, I can certainly think of one situation where this advice is crucial: telling our team that a feature is not going to launch or be killed after the team has worked on it for a long time. It's paramount that our team members can feel supported and valued during difficult situations like this.
The list can go on but I think one point is already clear: as a PM, many people will hear your voice quite commonly throughout the daily work and consequently, from the perspective of other stakeholders, your voice becomes the voice of the team that conveys directions, progresses, and key results.
Define, Clarify, and Execute
Every time you talk to the handler in Monster Hunter, she will hold up a notebook to show you all the quests on hand, each marked with detailed elaboration of the goal for the quest, expected success condition, expected rewards, resource constraints, and reasons for the quest. The same holds true when you talk to a PM in a feature team who helps to define what the team is building, clarify the goal that the team is trying to accomplish, and accompany the engineering or design team throughout execution to constantly refine any of the above aspects.
Monster Hunter: World Sample Quest Page
Just like how monster hunters can choose which quests to take up, engineers and designers often need a strong reason to commit to a particular feature definition and it takes some compelling rationales before they do. In this partnership between a PM and their feature team, it is the PM's job to influence without authority. This is not a particularly easy task and here are some lessons I learned:
-
Be Ruthless in Prioritization: Despite the seemingly extreme tone, it's important that a PM can think clearly about what to prioritize and have a strong framework which supports the decision. One useful framework I learned from my mentor Mohamed while working on my team's roadmap was the decision stack developed by Martin Eriksson.
Martin Eriksson's Decision Stack
Essentially, every prioritization decision needs to answer three things: what should we do, why are we doing it, and how we want to do it. The decision stack starts by prompting people to understand the why from bottom-up and solve for the how from the top-down.
This process starts with a clearly defined vision that is "customer-centric, concise, and sets an audacious goal". Using Alphabet as an example, Alphabet's vision is "to make the world around you universally accessible and useful" which leads to Google's vision "to provide access to the world's information in one click", Nest's vision "to creat a home that takes care of the people inside it and the world around it", and YouTube's vision "to give everyone a voice and show them the world". You can already start to see how vision helps to create alignment of goals that keeps every team focused.
Because a clear vision helps to identify strategy and objectives, it will eventually lead to specific user stories and design principles. Some examples of design principles include "individuals and interactions over processes and tools" or "customer collaboration over contract negotiation". Prioritization becomes much easier once you have a set of structured principles that are specific, actionable and manifests your vision because now you are able to filter out projects that have the strongest alignment with your principles and weigh them accordingly against the engineering effort. At the end of the process, you will have a preliminary idea of what to tell your team about prioritization and also have a strong reason that can be tested further with team feedbacks and user testings.
-
We are not launching rockets, scope the solution to the problem: Unless your team is really launching a rocket which I believe the statement still stands, it's paramount that a PM can help a team accomplish a goal with as little resources as possible. This requires the PM to think clearly about the MVP during each iteration cycle. Here's a good picture that illustrates what a MVP is:
How to think about MVP
The important connotation to notice here is that while people sometimes think each product release is building a part of the final product, a better practice should be releasing a partial solution. For example, UberEATS is trying to make it effortless to eat well for everyone, and if UberEATS launched its product that only allowed users to order food ahead for pickups, it is a partial solution. It is a complete solution nevertheless because user can finish the order, pickup, eat cycle. In another word, a PM should focus on solving only one aspect of the final problem during each product iteration cycle and solve it well with a focus on execution and gathering feedback.
- Focus on a complete heartbeat for each of your investment areas: This is a lesson I learned from my manager David when I asked how I should think about roadmap planning. David taught me to start by asking what metrics we are trying to achieve as a business and prioritize the backlog with respect to strategy, opportunity, and urgency. Once I have a prioritized backlog, I should organize it by investment areas and make decisions on the roadmap which allows the team to complete a full heartbeat for each of the investment area in the next period. The investment areas should be chosen using a diversified portfolio approach and a complete heartbeat is a full build → test → learn cycle on the prioritized backlog.
Last Thoughts
Now that I am almost at the end of this post and exactly a week away from the last day of my PM internship at Yahoo. It's my intention here to share my learnings with those who are on the same journey towards product management. PM is hard (in fact John Cutler wrote an article here to go into more details on that point) and getting into PM is hard. Yet I had the chance to meet some of the most wonderful people I've ever met because everyone understands how difficult it is. If you are thinking "I don't know if I can ever become a PM", rest assured that you are not alone. After all, I think every day is a first day for product managers or aspiring product managers. The time will come if we keep following our passion and have our heads up.
Happy first day!