What I learned from 9 months of being a PM in a Decacorn (Part 1)

I’m not going to lie, 9 months is not a long time. But it was an enough time for me to grow from taking baby steps to adolescent strides. Having started with half-managing 1 engineering team to, at one point, managing 3 full teams by myself (though this is not a good practice), I had a rare chance to scale and learn exponentially with the teams’ size. I distilled some of the key lessons I learned last year during the process.

1. Train yourselves to make reasonable decisions fast and consistently, at least in most cases

As a Product Manager, you would often imagine that you will be making big, shiny, and new features like the NFT Profile in Twitter. Well you do. But even when you do, behind every feature, lurks hundreds, if not thousands, of small decisions that you need to make. For instance, in API, which is one of my product, when we try to implement a new endpoint, I need to decide what each and every request and response body will look like.

This includes “petty” details like, “Should I name the field ‘SMS’, ‘Sms’, or ‘sms’? in the request body?” or “Have we used this field in any other endpoint?”

Yes they are small, but you can also argue that these small details add up to create a good user experience and great API product. Here’s how I think about it. Both are correct. So what you need to actually do is come up with consistent frameworks of how your product should be built. For instance, in the above example, it could be something like, “We’ll capitalize all acronyms”.

Of course one framework may not apply to all, so you would need to constantly invent new ones as needed and wield them at necessary times as you go. This way you will be able to make reasonably sound (at least consistent) decisions in an effortless and speedy manner. And because by nature they are small, it will be okay for you to miss some and get them wrong sometimes.

Ultimately what you need to do is save your mental capacity to make big decisions that will matter.

2. Don’t over-rely on data

I’m not saying you shouldn’t research or run SQL queries. On the contrary, you should be really good at them. There are no better ways to find out what you should build and how you should build (though I’m far from being good myself as well). What I’m saying is that there will be *gaps* in when you can’t find the right proprietary data to back your claim.

Let’s say, you are in charge of adding a new payment method to your app. You only have Apple Pay and credit card. What would you add next?

Obviously, you don’t know how many of your users wanted to use other means of payment. If you are lucky, you will have number of customer support tickets where those customers asked for other payment methods. So what will you do? You can look into what other applications do or what are the common payment methods in your region. What if there are two new e-wallets that are growing toe-to-toe?

Here your data won’t help you decide which to integrate first. You need to make that call with limited information you currently have; you also cannot wait for the data to somehow magically materialize because it’s not going to. Data will never make that last jump for you, they can certainly make that jump easier. But they will never be able to make that decision for you.

Do not blame lack of data for your lack of conviction. It’s okay to not have one, you just need to ship fast enough for market to judge and iterate on it. Don’t just do nothing.

3. Plant seeds for big changes

“One simple little idea, that changed everything.”
Cobb from Inception

If you want to make a sizeable change in the user flow or drive a new feature that have many dependencies across different teams, you should realize that it will take months, if not quarters. Worse, you might never get all the buy-ins. Even if you do, due to organizational inertia and each team prioritizing their own set of KPIs, your big change has a good chance of being one of the forgotten tickets in the backlog. (The bigger the item is, the harder time even your managers would have in unblocking)

Before you get all excited about your new flow even before talking to relevant stakeholders, how about you start with sharing the problem that you saw? Even better if you don’t share your solution. How about we just focus on educating our stakeholders on why you see it as a problem and why we as a company must see it as a problem? It does’t have to be in a formal setting and could be in any casual chat. Then how about we let them sleep on it? How about we come back in another week or so and talk about it again? How about we repeat?

I realized that, rather than bulldozing through different dependencies and barking one-way at different teams for not “getting” your proposal, it’s always better to problematize the problem first. I used the word problematize here because most of your peers may not even see your problem as a problem. So what you actually need to do is to get everyone in the same page first. Solutions can always come later.

So if you are embarking on a large feature and if it’s not a top-down initiative where people will automatically prioritize, then you have to plant the “seed” first. Then as Cobb said, that seed will slowly grow to help you and make your problem into their problem as well. As time-consuming as this sounds, if you are planned, this will be the most effective.

For the longest time, I assumed that Product Managers would have to decide every feature in an almost solitary endeavor. They would have to go in a room, think hard, dig copious amount of data, talk to customers for hours, and come up with a nice polished solution. It was reinforced when I commonly overheard engineers saying that they hate vague PRDs.

Nothing could have been farther from the truth. What engineers did hate was when they had to commit to a timeline when they couldn’t properly estimate because the feature wasn’t completely thought out. Because they were hold accountable to finish by the committed date and evaluated by how often they missed it, their frustration made lot of sense.

No one enjoys just being told what to do. And obviously that goes same for your engineering team as well. Even when you have a solution or flow in mind, share the problem you see with them and discuss. See what they come up with. Direct their creative energy to a solution that both parties can support. You can nudge them to your idea. But you will be surprised how often you and the team actually think similarly. But this time, since you’ve aligned with them from the start, engineers would have a much better grasp of how to fill the missing holes even if you have somehow missed them. Bring them in earlier and think together.

I have yet to find a better way to give engineers agency and motivation.

Edit1: You sometimes are lost as well and don’t know what to do. Share your conundrum with your teams. It’s okay for you to not know; your job is not to know everything in advance, but to polish different ideas and wrap them into customer-friendly features

Sang Ha Park