My Product Management Interviews (part 1 of 3)

So I decided to move on from my 5 years at a healthcare startup and start a new chapter in my career.

One of my mentors identified a weakness in my skillset which was the fact that I was too comfortable and getting very good at doing product management the same way for 5 years. He told me he specifically lasts only 2–3 years max at any employer because you need to grow yourself to learn how to build businesses and products in various ways so that you can respond swiftly to any situation you face. The only way to do so is by exposing yourself to new problems you have never solved or been exposed to before and learning from your mistakes/failures.

This advice really resonated with me because I have done nothing but deliberately try to rapidly grow in my overall product development experience and suddenly realized … he was right. I was in cruise-control to an extent and my most recent set of challenges and product road-map items were not conducive to my personal career growth and were merely rinse and repeat features. It was time to move on.

Company 1 Interview process Included:

• In person 1:1 interviews
• Mock scenario of “build a product from scratch and there will be 5 people in the room representing various stakeholders”. 60 minute exercise

I was given a large whiteboard and dry erase markers and when the clock starts I’m given the problem to solve via a new product from scratch. I need to go through discovery, design, user story creation and feature roadmap prioritization within 60 minutes.

The objective of the product:

Via the company’s foosball table, introduce a way in which different departments will not only play more foosball but will also play with people from different departments to facilitate cross-departmental interactions.

There are 2 floors of employees and people don’t know each other across floors. The reason this is necessary is because initial research shows facilitating conversation between non-interacting departments greatly increases employee morale and improves company culture perception.

Stakeholder Representation:

1. Engineering
2. Design
3. Executive Leadership
4. HR

I started with basic questions like “how many foosball tables are available?” or “are there any specific KPIs that have been used for measurement in the past?”…etc. Get the foundational questions out of the way to prevent gotchas later (this shows that you think about how to avoid complexity later and you want to keep a focus on the objective).

Discovery Exercise:

I went through the discovery process by utilizing the OGSM model one of my mentors taught me. Each section of the OGSM was a conversation between myself and the representing stakeholders. I took the assumption that I shouldn’t EVER just make a decision but instead ask questions for the table to answer and I decide when its obvious the consensus has been reached.

OGSM

(O)bjective:

• Increase cross departmental interactions between both floors by utilizing one foosball table

(G)oals:

• Provide an incentive for employees to participate and play
• Reward players that play against new players more than repeat matches
• Reward players that play against members of non-interacting departments more than interacting departments (example: sales vs account management rewards less than sales vs software engineering)

(S)trategies:

• Player profiles will be created utilizing the company’s active directory / google directory technology to identify department

— Provide matchmaking capabilities:

• We agreed that a mobile friendly web-app was the fastest and cheapest approach to development over a native mobile app
• Facilitate scheduling matchmaking that works best for each person’s calendar
• Manual matchmaking to challenge opponents via employee name search
• Auto matchmaking that automatically determines the matchup that provides the highest reward (based on department and non-interaction between departments)
• Matchmaking notifications and reminders

— Leaderboard Capabilities

• Publicly display a leaderboard on television screens across the office
• Display leaderboard by individual player score
• Display leaderboard by department
• Admin account required to display leaderboard on televisions

(M)easures:

• For the sake of time, we collectively agreed the algorithm to identify score weight based on department collectively should be skipped but I brought it up as a technology scope of work to identify as a priority based on the product objective. I mentioned that analytics managers are a great resource for this conversation.

Once discovery was complete (took me about 45 minutes or so) I was given 10 minutes to draw mockups.

Thanks to the OGSM model, I was easily able to draw mockups of how matchmaking features would function and how the leaderboard tv screen would look like as well.

I repeatedly reminded them that I personally like to do discovery side-by-side with a UX designer so that collaboration between both of us is faster and the end goal is crystal clear to both of us and we can catch each other on important “must have” detail.

Once the mockups were drawn based off of the OGSM discovery, I was given another 15 minutes to write up user stories on index cards and decide on prioritization.

I wrote the user stories based off the OGSM list on the whiteboard and decided to group them in 3 categories.

• Matchmaking
• TV Screen Leaderboard
• Profile

I then prioritized the user stories from MVP stage down to iteration.

This picture is of the index cards I wrote as user stories. This picture is prior to engineering review.

I asked the engineering representative a lot of questions and asked for opinions when they came back into the room.

I explained that I did my best to prioritize based on the group conversations but I wanted to review them one last time with my engineering team prior to committing the public version of the priorities.

1. Get a match to be scheduled (regardless of leaderboard or department integration)
2. Get a match results to be stored somewhere (regardless of leaderboard or department integration)
3. Player department and profile creation (once matches are confirmed to be functional for scheduling and tracking via MVP)
4. Enable users to find other players by name and schedule a match and track their match results
5. Player notifications (via calendar invite) for scheduled matches
6. Create leaderboard with an admin account to display scores on screens. Display scores by individual players only first.
7. Display scores by department
8. Scoring logic implementation
9. Scoring algorithm prioritized by non-interacting department introduced
10. Auto-match by best possible matchup
11. Player submits times of availability for others to schedule matches towards.

Later that evening I received an offer letter

My advise to anyone going through this type of interview is:

• Don’t get nervous at the fact that you have to solve a problem you weren’t necessarily prepared to solve. The purpose of the exercise is to go through the fact-finding process with them in the room and if you can’t figure something out…raise it as a problem to solve and ask others in the room for their thoughts. Show that you’re comfortable with ambiguity and you make it look good while you deal with it.
• Have fun with it and pretend as if you actually were to use this yourself and provide quick snippets of how you would personally like to approach some solutions but instantly ask others what their thoughts are. Specifically the design, engineering, and leadership representatives.
• Know that there isn’t necessarily a right or wrong solution here.

The wrong answer is simply dictating the whole thing from beginning to end without any collaboration or fact checking with your stakeholders in the room.

I made this mistake in a different interview and I will write about it in a part 2.

I hope this is helpful and let me know your thoughts in comments below or via twitter @officebeats .