The risk of not being a technical PM

The common rhetoric is being technical makes you a better product manager – but this isn’t always true. Knowing how to code or going to a coding bootcamp doesn’t always guarantee being a better product manager. When someone says “I’m looking for someone technical,” what they’re really looking for is someone who is willing to pay the knowledge tax.

Paying the knowledge tax involves being deep in the details, the documentation, and understanding how the code works. When I think about the leaders who were most effective at Tesla, they leveraged their understanding of the code to bring a technical insight to the team that made the experience better for users, allowing Tesla to stay competitive. Ineffective leaders, on the other hand, tended to gloss over these technical details.

When you’re non-technical, it’s easy to see the technical parts of your product as a black box. You think, “I’ll just have my Engineering Manager (EM) take care of it,” and outsource all the technical decision-making to her. But there’s a hefty price to walking this path. As you start to run up against a creeping product launch, you might feel at a loss about how to deliver and feel like the only thing you can do is to tell your engineering team to go faster.

Case Study: Improving Facebook’s AR filters

It’s easy to see the engineering work as a black box, but the moment you open it, it could be a treasure box.

For example, when Alexis was on Facebook’s AR team, she was tasked with the goal of making it as fast as possible for people to use face filters on Facebook’s mobile app. This was a business-critical goal because when there's no instant gratification because an app is slow, people move away to other apps. People typically use Facebook for short periods of time when they're easily distracted, such as waiting in line or going to the bathroom.

In order to use the AR face filters, users needed to download packets of AR programs and face models. The download time was very slow, making it difficult for users to use, but her team didn’t know how to solve it. Alexis sat down with an engineer and asked, “How should we solve it?” When the engineer replied, “Don’t worry, I’ll take care of it,” Alexis pushed back. She wanted to probe, so she sat down with the engineer and wrote down every step that was taken: from when a user presses a face filter they want to use, all the way to the rendering.

When they wrote down every step along the way, they realized that from the process, there was a big step that wasn’t being logged in the time they were measuring, which meant the perceived rendering time was significantly slower (hundreds of milliseconds) than their measured rendering time. This rendering time made a big difference, especially compared to competitors like Snapchat that were able to render these filters quickly.

From looking at every step in the flow, Alexis identified large chunks of the flow that weren’t being measured and not being optimized. As a result, she was able to work with the engineer to begin measuring these chunks and set product milestones to begin optimizing parts of the flow. She created a framework for her team to talk through the steps they needed to focus on, and set segment-specific goals: “This month we’ll focus on the download step, the next month we’ll focus on the caching step.” 

As a result of her probing, Alexis created more granular and concrete goals, driving her team to be more focused, and accelerating the overall organizational goal to “make using AR face filters as fast as possible,” allowing Facebook to stay competitive with other AR experiences.

How to go from a good PM to a great PM

Goal: Make using AR filters as fast as possible by driving down time spent downloading the filters.

Here’s how you can fill the technical gap

Taking a step to be curious about the engineering constraints and architectural decisions might feel confusing and frustrating at first, but can lead to you have more ideas about how to deliver more user value faster. The next time you feel frustrated and feel that your only lever is telling your engineers to move faster, consider paying the knowledge tax by asking these questions instead:

• What are the components of the system? What are all the steps in the flow?

• Which one has the highest risk?

• What are the unknowns? What are our known unknowns and potential unknown unknowns?

• What does a hacky product vs. a well-made product look like?

It’s normal for engineers to say, “Don’t worry, I got it,” or even when they try, to feel like you’re muddled in a lot of jargon, but don’t get discouraged. Push back and drive to understand. Your knowledge of the systems will grow and have an exponential payoff in the long run.

---

Want more coaching?

If you feel like this still isn’t enough and want more structure and coaching to help guide you to success with your engineering team, we’ve partnered with our friends at Skiplevel to help.

Want to feel more confident working with developers and writing better business requirements? Become more technical in 5 weeks – without learning how to code. Skiplevel is a technical literacy program created by ex-Amazon software engineer Irene Yu, that trains product managers and product teams. Visit our friends at Skiplevel.co to learn more.

For our first 30 subscribers who sign up, use our discount code PMWORK100 for $100 off the course.