2 Months into Product Management: Here’s What I Learned
Background info: This is my 5th co-op as part of the University of Waterloo’s co-op system. This is my first time interning as a Product Manager, where I work on the Yelp Reservations team. We’re responsible for providing a restaurant reservation process within Yelp and an online restaurant waitlist system called NoWait within the mobile app; some restaurants operate on a paper-and-pen basis, and NoWait allows you to join their waitlist system, without having to be at the restaurant in person.
At the halfway point of my internship at Yelp, I took it upon myself to summarize and condense pages of observational notes that I had written over the past 2 months, into a single page titled key learnings.
These observational notes were inspired from conversations with other PMs, self reflections about how I handled difficult situations, and advice and lessons from my talented mentor.
I want to share 3 key learnings that would have made my first few weeks in product management easier had I internalized these lessons in the beginning.
1. The goal of experimental product features is to learn as much as possible within the shortest time span with an *acceptable user experience*
In teams focused on delivering new product features, you’re constantly running a series of experiments to test out multiple hypotheses on how to grow your key metrics without a baseline already set.
Key Objective: Each experimental product feature is a hypothetical solution that will solve a core problem. Your main goal is to learn as much as possible to either validate or invalidate your hypothesis, in the fastest time possible.
One mistake that I made early on was spending too much time on optimizing the user experience.
Project: I worked on a Yelp notification push, aimed at increasing user awareness of the NoWait online waitlist feature. You would receive this push if you were recently at a restaurant that uses NoWait.
Problem: A limitation of the underlying tech was that sometimes they would get the push at the restaurant or sometimes when they have left the restaurant. I had spent a lot of time trying to optimize the whole experiment based on which use-case they would fall under, instead of creating an acceptable user experience that would have been good enough for both use-cases.
This time and energy spent on optimizing the user experience might have been more beneficial if we already knew
1) The impact of the push experiment
2) How it would affect users
3) How they would respond
But we don’t. In fact, our experiment should be answering those very questions, that I made assumptions on.
Project Goal: If our push experiment showed that users are more engaged with NoWait restaurants and that their NoWait feature task success metrics achieved higher lift, this would be an opportunity that we would want to double-down on and optimize the user experience for. To achieve our goal, we initially need an acceptable user experience, not a perfect one.
Areas for Future Optimization: We would also track a bunch of other metrics while we launch this experiment. This way, we could see if certain actions correlated with the success metrics we defined for the experiment. As an example, if we see a high correlation between the completion rate of the NoWait waitlist feature and bookmarking the business for users who get the push, we could then modify the copy of our push to persuade them to also bookmark the business, in addition to informing them of the NoWait feature. This will then become the new hypothesis to test out.
The reasoning behind this logic is if they do A, they will most likely do B. B is the result we want — B is not an action that they can take right now, but A is. Therefore, we prime them to take action on A.
Think About This Situation: If you were able to make 80% of the learnings within a week’s worth of experimental product development, but will take next week’s worth of effort to optimize for the remaining 20%, you should not do it. This will allow you to spend that extra week on another project solving a different core problem in your product roadmap; even if that new project would yield 50% learnings, that 50% is still greater than the remaining 20%.
2. Before every meeting, ask yourself “what do I want to accomplish by the end of it”?
You should explicitly list out the goal of every meeting and what result you would like to see happen. Once you’ve had the objective of the meeting defined, a great way I’ve found to structure a meeting is as follows:
Background
Provide the problem you’re trying to solve and any context required for that problem. This can involve a few different people presenting facts around the situation. The more people you can pull in here the better as you can start the meeting by having people involved.Goals
Clarify, up front, the goals of the meetingDiscussion Points
Put the things front-of-mind that you want to discuss in order to have people be able to come to a decision.Action Items
After you’ve gone through discussion points, you should be able to write down action items and assign owners for those action items.
Personal Tactic: Before the meeting, send out a brief email detailing the purpose of the meeting and any background information needed for the meeting to run smoothly. At the beginning of the meeting, you should reiterate the goal of the meeting to everybody, again.
When you have a clear picture of the end goal in mind and state that to the collective group, your discussion becomes more intentional and you can drive the conversation more effectively to that end goal.
Keep in Mind: You should also ask yourself, what input is required from you to achieve your desired output.
Especially between cross-functional and cross-team collaboration, you should be extra wary of the objective of the communication line. Ask yourself these 3 questions repeatedly to gain clarity for your communication line’s purpose:
1) Why do we need to talk?
2) What do I want from them?
3) What do they want from me?
3. Its okay to not know the answer
It’s the worst thing to make a declarative statement that has to be later retracted because it was proven to be incorrect.
I, personally, make this mistake when I decide to value speed over understanding. As a result, you end up making snap decisions in an effort to optimize your current situation.
PM Pressure: PMs, early on, misconstrue the job responsibilities of being the product’s center point of knowledge with being expected to know the answer to every question at any given time. This leads to an unhealthy belief that not knowing the answer to every question is a failure of their job.
Although you should strive to know as much as possible about your problem, your solution, and the execution of it, the conversation we should be having is that its an unrealistic expectation to know absolutely everything that is going on.
Do This Next Time: If someone asks you to make a decision or inquires about how something works, on the spot, it’s perfectly okay to say:
“That’s a great question, but I don’t know. Give me some time to do some research, ask around, and think about it. I’ll get back to you.”
Ambiguity occurs when you have too many questions but not enough answers. Whenever you feel you have reached a confused state, dump out all the questions that you have on your mind, on a piece of paper. Then aim to gain clarity on each of those situations from individual research or by asking subject matter experts for answers.
It’s not a failure of your job to not know the answer at that exact time. It’s a failure of your job to not follow up.
