2 things we unlearned after PMing at top tech companies
Written by Adrienne* and Alexis
Today’s memo is sponsored by our friends at UserLeap, a tool for PMs to quickly and deeply understand their customers. With UserLeap’s contextual microsurveys, AI text analysis and 75+ research templates, PMs can learn in real time why their customers sign up, engage and retain. Try it for free today.
Most people think that the skills you learn as a PM at Facebook, Google, and Tesla will arm you with skills to succeed anywhere. The truth, however, is that many of the modes of operating didn’t work when we applied them at startups, and we wanted to share some of the things we had to unlearn. Intuitive mental habits that make you successful in a large company must be unlearned, in order to be successful in a smaller company and vice versa. For today’s blog post, we highlight two subtle mental models that could trip you up.
#1: Your conviction level for making a decision changes when you’re building for 100 users vs. 1 billion users
When starting a startup, I* was used to making decisions if I had 90% conviction. At my startup, I had a hypothesis that drug developers could use our algorithms to gain insights about how effective their drugs were performing in trials, and I could only do so much research and user interviews before I needed to simply build something, get it in user’s hands, and test my hunches.
At Tesla, I quickly learned that 90% conviction was not enough. When building Voice Assistant, every decision needed to be airtight. I spent my days constantly thinking of ways to get from 90% to 95% conviction. At an early-stage startup, it might be enough to do a few tests in the car and deem the latency low enough to launch -- but at Tesla I had to think through many scenarios carefully:
How does latency change if the customer is transitioning from Wi-Fi to Cellular service (e.g. backing out of their garage)?
How about if they’re driving from a high cellular reception area to a low reception area?
Every problem had to be decomposed into its smaller constituents and thoroughly investigated. This kind of thinking at a large tech company is non-negotiable, because the cost of a wrong move is higher, whether it’s the safety of millions of users worldwide or the risk of losing the public’s trust on the brand.
This high risk level is the reason a VP might ask, “What’s the user data on this?” or an Engineering Manager, “What’s the tradeoff of doing this project vs. taking on another one?”
#2: The kind of research you do will dramatically vary
The type of documentation at Google vs Tesla also dramatically varied. When I was at Google, it struck me how documentation was the crux of proving your worth as a PM. I’d see PMs get promoted after they’d make a deck on the future of AI in China, or how Gen Z consumption patterns were changing. These are valuable work -- a deck is a representation of months of research boiled down to its essence.
So when I first started at Tesla, naturally, I made decks. Surprisingly, I learned this kind of documentation that was prized at Google was disregarded at Tesla. In a fast-moving environment like Tesla, no one looked at them. ICs in fast-moving environments have less opportunity and time to think long term, and create long-term strategy research decks.
Bad PMs say “Decks are a waste of time here,” while great PMs say “Decks make sense in *this* case but not in *that* case.” The kind of documentation that was useful at Tesla were ones that were more immediately actionable. My engineers would often spend a lot of time getting pulled into emergencies that seemed urgent, making it difficult to work towards launching important products. The kind of documentation most helpful here was a priority guideline, which defined what the Tier 1, 2, and 3 priorities were. This way, when an engineer encountered an emergency or someone randomly assigned her a bug, she could easily use the guideline to quickly triage every issue.
Whenever starting somewhere new, it can be easy to fall into the trap of going through the motions of what you did before, and then failing. There’s nothing wrong with this -- it’s learning by doing -- but it’s helpful to think through why those motions were helpful for that scenario in the first place, so you can adjust quickly your new setting.