Sang Ha Park

If you want to read from the start, check out Part 1.

5. Objective really matters

You will have to rarely choose between an unreasonable feature and a reasonable one. Rather in most cases, certainly in almost every case, you would have to choose among the reasonable ones. If not, then you should seriously consider going back and starting from step 0 again. That’s why being a good PM is difficult! It’s a battle between reasonable candidates.

So how do you decide when all choices make sense? Here I like to step back and understand why we are trying to do what we are trying to do right now.

For instance, let’s say you are a PM working in Uber working on charging cancellation fees to cancelled rides. And you have to decide what message to show and how to display it when users try to cancel, or whether to display such message at all

You can argue that “Of course, we need to display it before they cancel. Users should be always properly informed at all times”. Ok good, that was an easy one. How about what to display? Will you show the cancellation fee? If so, how big? What about any message that goes with the fee? In a matter of moments, you will be quickly flooded by reasonable candidates that all make sense.

• Option 1: “Cancellation fee will be used to compensate the drivers”
• Option 2: “Keep your order by not cancelling”
• Option 3: “You are charged because the driver is already on the way. Do you still want to cancel?”
• Option 4: “You will be charged with $5 fee for cancelling”
• Option 5: “Driving being late? How about changing the driver without any fee?”

All of these above options can be valid messages, (obviously with better wording 😆). Now let’s go back to why. The CEO and you agree that we are charging cancellation fees because we want to properly compensate the drivers. Then you will quickly see that some combination of Option 1 and 3 is more aligned with the why. If you say that we are trying to reduce the rate of cancellation and capture more rides, then Option 5 will make more sense.

Of course, even why can be multi-faceted and often have contradictory-looking goals. But in a nutshell, what we are doing is transporting the decision space into a higher dimension that is more business critical. Technically we can repeat such process indefinitely, by moving to subsequent higher dimensions. Company’s guiding principle or vision can be one. But in my experience, most candidates were hashed out when you deeply focused on why.

6. Focus on big levers

All problems are hard to solve. It’s the degree of how you intend to solve them that are different. Even seemingly small problems like, “how can I improve this toast message to give more assurance to users?” can take months if you want to do it “right”. You can spent months digging through data, benchmarking with competitors, going through various options, running A/B tests, and rolling out in a canary release to checkout users’ reaction. After months of work, you would think how much difference would that improved toast message make?

If it is indeed something as small as a toast message without any CTA, then I think you should generally assume that it will have a marginal impact. I’m not saying that it will, what I’m saying is that it likely will not be worth your effort. Yes, there will be times when you want to take it easy and have some free time in between bigger projects, then that’s fine.

However you shouldn’t shy away from bigger problems just because they look harder, have more dependencies, and/or are less popular. Because in the end, if you are that kind of PM that will do their best in solving even the tiniest problem, you will have easily spent same amount of effort. You might have had less conflict, but you might have easily substituted that lack of conflict with overthinking and overfitting.

So unless you absolute don’t have any choice, go for bigger problems, bigger levers that can impact your North Star metrics. They will take same amount of effort and be more rewarding.

7. Focus on what is right, rather than who is right

You should have heard that PM needs to lead without authority. “Lead” because you need to inspire and move different teams in a direction that you point to, “without authority” because you actually don’t manage those different teams. For me, they are usually tech, sales, and design. In other words, you are not their bosses. Their bosses decide their yearly bonus and promotion. You don’t. Yet you should be leading them. So how?

One way is to be wickedly smarter than everyone else and be right for many times. Added bonus point when you have a contrarian view that turns out to be right. But we can’t be on top of everything all the time. We can’t always be confident to understand clients the best when it’s the sales team that interact with them the most. Hence if you push through a contentious idea and it miserably fails and stakeholders get upset, then it’s not hard to imagine that your next feature will be much more painful, if there is one.

I’m not saying that you shouldn’t push your own idea about product. You always should, 100%. What I’m saying is that you shouldn’t be tied to your “own” idea. You should be always receptive to other people’s ideas and willing to make the switch almost instantaneously. (“Quantum thought” in Naval Ravikant & Nick Szabo’s words). Your job is not to come up with right idea every time, but to discern one–whoever and wherever that is from–and lead the team into that direction. Also that means you don’t have to be right every time, which is much much easier. Let that obsession go and focus on, as a team, what we find out and how we can always strive to find a better solution.

8. Sometimes you have to enforce

I’ve seen several PMs stressing over small subset of users that do not perform necessary actions. Let’s say, you are an Uber driver for instance, and for some reason after you pick up your passenger and you don’t bother to swipe and mark that journey has started. On a more extreme case, you just turn on airplane mode presumably to save battery.

From PM’s perspective, these are clearly unexpected behaviors that do not follow how your app is built. Then what do you do? Your job is not to be discouraged that certain users won’t follow standard rules of interaction but to find creative ways to make sure they are back on the track. Of course, you cannot close all gaps, but you can at least close the gap once they are back in the system (e.g., turns off airplane mode). Your job is to encourage them to interact with your app with the rules that you set.

Worse, you cannot say that just because of several edge cases that you cannot fully control, you will create looser systems for all positive actors. In Uber’s example, that might be not marking start of the ride and allowing such action for all drivers; In Doordash, that might be not signaling that you’ve arrived at the restaurant and allowing that for all Dashers. When user’s experience, which is critical to your business, relies on those key actions by another party, you must do your best to encourage that party to perform that action. And if they don’t, you must do everything you can with operations team to make sure that behavior is enforced.

---

That’s it! Hope I can come up with better and more concrete examples / anecdotes next year. In the mean time, I will zoom into learnings that I haven’t mentioned here and elaborate them in more detail in coming months.