Product Management Scenario- Based Questions and Answers: Volume 1

The types of questions you can expect to be asked in a Product Management interview are pretty vast and varied. But in general, you’ll probably be asked some of these listed here.

Questions will vary depending on the type of Product Manager role, level, company, or industry, and the types of questions you’ll be asked will change as you move through the interview process.

What do Companies Look For in a New Product Manager?

Lol — I won’t say I know what they look for precisely as I am also curious and still trying to break into one of the FAANG and Global Companies.

Aside from intellect, smarts, the power to adapt, think, and act on their feet? All companies want a person who is motivated to do the job, can work with different teams, and can prioritize features that they already know users are looking for.

A Product Manager has to be resilient, strategic, and insightful. This means the hiring company will ask a multitude of questions to figure out if you are the one. Even if you’re not overly technical, the best way to prepare is to thoroughly read through the description of the role you’re applying for,

Please note that these questions were asked ,when I interviewed for a role as a Senior Product Manager in an African startup. The responses are summarized versions of my responses. I decided to share them here to help other PMs and also help myself by sharing knowledge.

Section 1

Prioritization

You are a product manager for Facebook Groups. Can you talk through your prioritization process?

• I usually use a prioritization method called the MOSCOW method The MOSCOW method is commonly used to help key stakeholders understand the significance of initiatives in a specific release.
• Moscow stands for four different categories of initiatives: must-haves, should-haves, could-haves, and will not have. Sometimes, the “W” in Moscow is used to stand for “wish” instead of “will not have right now.”
• Must-Have Requirements: Another way to refer to this is as the minimum usable subset (MUS) or what the product or sprint must deliver. In other words, it must deliver these on the target date for the project to remain on track. No delay is acceptable. A way to understand if you’re dealing with a MUS is by asking yourself, “What happens if this isn’t met?” If the answer is, “The project fails,” then you have a MUS. Any workaround that can be devised to continue with the project and not jeopardize its success, means this isn’t a MUS.
• Should-Have Requirements: This type of requirement is almost as important as a MUS, but it’s not vital to the success of the project. In other words, the project doesn’t depend on this requirement. You might not want to leave it out, as it could have a great impact on the project, but in the end, it can be done without causing any irreparable harm.
• Could-Have Requirements: The difference between a should-have requirement and a could-have requirement is simply figuring out the degree of pain that would be caused by not meeting it. That is, how will it impact the business value of the project, how many people would be affected, etc. Therefore, a could-have requirement is something you’d like but is less important than a should-have requirement. There will be an impact if it’s left out of the project, but less than the impact of a should-have requirement.
• What We Will Not Have This Time: Here is where can I collect those requirements that are not feasible for a specific release. Maybe next time, but the project remains strong without them. This is a great way to avoid project scope creep. Once initiatives are placed in the not have time category, teams know that they’re not a priority for this go-around and can place them on the back burner and out of their mind. This allows them to focus more sharply on those requirements that are important to the project.

Section 2

Roadmap

How do you communicate your roadmap to other teams? To management teams?

• I communicate my roadmap through sprint planning sessions, general product meetings, and internal communication emails to other teams.
• Planning and creating: I usually ensure the teams I work with evaluate the Roapmap every week. Milestones are planned monthly, but sometimes also during bi-weekly meetings with management. With the team, it’s okay to show them the work-in-progress
• Communication: Biweekly meetings with relevant stakeholders to show the change and answer questions about it. After this meeting, the roadmap gets published in our Confluence or Aha or internal comms document. With management, I usually ensure all I show them is actual work-in-progress

Section 3

Communication

Your latest release shipped a bug that drastically affected 0.1% of your user base and those users have been sending in angry feedback about their product experience. How do you structure your communication to them to help appease them until you have time to ship a hot-fix within the next few days?

• I will work with the marketing and communications team to send out a mail to all our customers and offer them some kind of coupon or discount that would help keep the frustration of the customer at a minimum and explain the whole reason for the impact and all the actions we are/have taken to keep them in a position where they also feel like part of something big.

Section 4

Cross-Functional Teamwork

Tell me about a time when a designer disagreed with you. How did you work through the issue?

• Designers are usually opinionated thus they always have their own opinions on why they did what they did — Occasionally, they may create a design that is more personal than what is best for the organization and would disagree with other opinions including me, the Product Manager. In a situation like this,

” I do not try to win but be logical in my approach to discussing the issue and so, I usually bring in a 3rd party to also hear their point of view on the designer’s viewpoint and then merge everyone’s opinion to come up with what is best for us as an organization than a personal decision.”

Talk me through a time when you had to work with several different teams to coordinate a product launch.

I usually work with various teams to ensure a smooth launch

• Product Development Team: This team includes engineering, design, and testers — To ensure, we have an actual working product and all tests have been done to ensure there are no unplanned bugs and all is well.
• Marketing: To discuss the launch with them and run them through a demo of the product so we can plan for the launch accordingly.
• Key Stakeholders: For the overall expectation guide

Your engineering team has proposed a technical design that you don’t agree with. How do you go about figuring the best path forward?

• I communicate with each engineer individually to understand the design that was created.
• I also ask questions in communities of other experts to hear their views correlate responses and then make a decision based on all that is aggregated.

If you enjoyed reading this, then please like, share, and follow me on LinkedIn, Twitter, and Email for more product management-related posts, articles, and conversations

Here is a link to Volume 2 and my on — Volume 3 on Product Strategy .