Product Case Analysis: Improve Google Meet for Corporates
In this series, we will cover different product cases that can help you in your next product management interview. So subscribe for 'free' to get access to all of these articles.
Whenever we are given with a case, we would need to first ensure that we understand completely and give a brief about it to the interviewer, before we start on solving the case.
So an example would be like this:
“Google Meet is a video communication service that is developed by Google, whose mission is to organize the world’s information and make it universally accessible & useful. This industry saw a boom in its usage after the advent of COVID19, ranging from personal to professional purposes. However since it caused a huge transition for professionals to work remotely from their homes, video communication services became a necessity to handle day-to-day meetings.”
Explanation:
Make sure you understand the mission statement of the company before attending its interview. This will make them perceive that you have done your homework and read about their company.
Give a small brief about what you know about the product/company/industry before going further, because '“storytelling is key” if you want to stand out from the crowd.
This is step 0: Giving the interviewer your understanding about the problem statement.
#1 Ask Clarifying questions
We can see that this question is pretty open ended.
They haven’t mentioned anything for us to solve, apart from giving us a customer type: “Corporates”.
So what do we do? We ask questions!
So in this case, when the question says we have to “improve” G-meet for corporates, we need to understand what they exact mean by the word “improve”.
Is it improvement in engagement? revenue? retention? adoption? We are not sure about it since we need more info!
So the first step in solving this in a case interview would be to clarify with the interviewer on what exactly they mean by the word “improve”.
In our case, lets assume that the interviewer asks us to focus only on “engagement”.
Then we ask any other questions that we have in our mind, so that we can drive the case discussion based on our thought process.
My next question would be to ask whether the solutioning required should be short-term focused or long-term focused, because it will help me in understanding whether I would need to focus on quick wins or Major projects. Lets assume that the interviewer says this is up to us (Normally they would want us to drive the case discussion and they would just intervene whenever we are going off track).
Finally I would ask one last question, which is whether this improvement in adoption should be focused on any particular geographic region, considering how there are certain geographies which is multilingual. This would help us in deciding whether providing multilingual support or not. Let us assume that the interviewer says us to the solution to ‘not’ be geographic specific.
Now with all of this, we will start with the next step.
#2 Create User Personas
Lets look at some user personas we can define for corporate users.
Meeting host: Someone who sends out the meeting invite and starts it
Active attendees: People who actively participate in the call, sharing their screen etc.
Passive attendees: People who don’t actively participate, and sometimes just switches their screen to do some other work.
So while defining user personas, ensure that they are mutually exclusive and collectively exhaustive, such that addition of any other persona will result in an overlap.
While creating this list, make sure to not take much time. There is no hard stop that can be defined here since its all subjective and depends on the interview, however taking a max of 45 to 60 seconds to make the personas is safe.
Also a small thing that you can ensure is to first tell the interview the “number” of user personas you have identified, before you mention them and give a short brief about all of them. This is just a good storytelling practice.
#3 Identify Pain Points
Now in this step, you got to identify the pain points of each of the user persona, that will aid you in the next step, i.e. solutioning.
Meeting Host
They have to admit the attendees one-by-one who are in the virtual waiting room (which also needs a redesign). Suppose if the meeting is of a big number, then it will be difficult for them to admit every single of the attendees.
If the meeting host is sharing their screen, they wont be able to see the participants video. Having no video feedback in a video communication service while sharing screen is a big drawback.
If they are hosting a session to a large number of attendees, and if there is noise coming out of someone’s microphone because they didn’t mute it, then it disrupts the flow of the meeting.
Active Attendees
If they are sharing their screen, they wont be able to see the participants video. This is the same pain point that the meeting host will also have.
The chat is not much user friendly since it doesn’t allow us to send images, videos, files, emojis etc.
Passive Attendees
They would be passive because they might need to switch between multiple meetings in the same timeslot.
Now that we have a good understanding of what the pain points of each of the user personas are, we can now explain this to the interviewer and ask who we should focus on.
The occasional questions that we ask the interviewer is to engage them in the case discussion, and not make it totally one sided. Also there will be cases, where the interviewer would want solution for only a particular segment of user persona rather than all of the, so its a good practice to ask here.
#4 Solutioning phase
For the sake of simplicity, lets assume that the interviewer asked us to focus only on ‘Meeting Host’ persona.
Now we will brainstorm on the features that we should roll out for these pain points. They are:
“Mute all” and “Admit all” feature: Since this helps in easing the Meeting Host to manage the meeting, when it has a large number of participants.
“Auto Admit everyone” toggle: This will come along with the ‘Admit all’ feature, where the host can change the ensure that everyone who is joining after the feature is enabled, won’t be required to be put in the waiting room.
“Participants Overlay” feature: This gives the screen sharers a live relay of the top active attendees in the meeting. Host can also pin any number of attendees they want to. Also host will be able to see the participants who have raised their hand, replied/asked something or even reacted to the presentation at the participants overlay. This can be a vertical or horizontal bar at the top/left/right side of the screen, based on the participants choice.
Now that we have defined the list of features that can be developed, we would need to prioritize them in the order of deliverables.
#5 Feature Prioritization
There are many frameworks you can follow here like: RICE, ICE, Value VS Effort, MoSCoW f/w etc., however its up to you which you want to follow. This is because whatever you end up following, the major requirement here is the “reasoning” behind your feature prioritization.
Basically your reasoning should make common sense, because you can’t fool interviewer :)
I will be using the ICE framework, which stands for Impact, Confidence and Ease, to prioritize the features.
Lets take the “Participants overlay” feature as an example.
The “Impact” that this feature will have will be lots because it will give a boost in the engagement of the attendees within the meeting. Also, it will reduce the expectation bias which people might have when they compare Google Meet with Zoom or Teams. So I would give this a 9/10.
The “Confidence” that I have with this feature having a 9/10 impact is around 80%. This is because we are developing a big feature, and it would require a lot of effort to pull this off without releasing any bugs. Also listening and responding to user feedback is crucial.
Building this feature doesn’t come at “Ease”, because its a big feature, and hence it would take a lot of time as well. Hence I would give this a 5/10.
So the total ICE score = 9 * 80% * 5 = 36
Similarly you can have your own reasoning for the other two features.
For Mute all & Admit all feature: ICE Score = 7 * 100% * 9 = 63
For Admit everyone feature: ICE Score = 7 * 100% * 9 = 63
The scores are same because there is just a lot of commonality in developing these two features.
With this we will prioritize them like this:
Phase 1 development:
Mute all & Admit all feature
Admit everyone feature
Phase 2 development:
Participants Overlay feature
#6 Metrics Tracking
To ensure the success of each of the product features, it is important that we track the metrics. This can help us measure the growth and help us understand if our target objectives are met.
Also since all the features promote engagement (which is the focus of our problem statement), we need to pick its related metrics as well. Our goal here to be to drive engagement, so we need to check if we are succeeding in that mission.
Mute all & Admit all feature:
Average # of “Mute all” clicked per hundred meetings (with participants more than 15)
Average # of “Admit all” clicked per hundred meetings (with participants more than 15)
Queue wait time (To understand if the wait time for the participants who are in the virtual waiting room is reduced)
Admit everyone feature:
Average # of “Admit everyone” clicked per hundred meetings (with participants more than 15)
Queue wait time
Participants overlay feature:
Since this is a ‘visual only’ feature, we cant track the right metrics to ensure the success. Hence we can ask for user feedback after ending every call as a pop up to rate the feature out of 5.
And that brings us to the end of the case.
Follow for more such prodman articles!
It might just be a click of a button for you, but it shows your support and motivates me to write a lot of these informative stories out there to you and help you in your product management journey.
Until next time! :)