Chasing highs that hurt your product

Today's memo is sponsored by Amplitude.

Care about growth? Then you should care about user retention.

Amplitude is an industry leader in product analytics. They built and shared with our readers an adaptable, repeatable strategy that can be put in place for products at all stages of growth, and in all verticals. Check it out. Get the Guide Here.

I've always been fascinated by the indicators of a healthy product organization and how they evolve as a company scales. Here I connect themes from working at product orgs of different sizes – from a Series B company backed by Founders Fund, to Tesla, a rapidly growing company, then Google, a very mature company with billions of users.

I noticed unhealthy product organizations fall into common traps, where team members are chasing highs that are enticing – but these highs are temporary and ultimately end up hurting the success of the product.

Short-term high: Jumping to execution

At the Series B biotech startup for example, engineers would spend months building something that ultimately wasn’t useful for the customer. When I had just arrived at the org, I learned they had spent six months building a platform for scientists to automate their workflow, but when they showed it to the users, they found that the scientists didn't find it useful at all -- in fact, many parts actually added friction because they were out of sequence with users’ existing workflow.

The team was jumping into the thrill of implementation without enough customer discovery to understand whether they were addressing the pain point. Customer discovery is the more emotionally painful path, and also the more ambiguous -- and when something is not well-defined, it's tempting to prioritize building a solution with a clear path, even if it's potentially irrelevant for users.

When engineers don’t have anything compelling to work on in their queue, they’re more tempted to jump on to the next swanky mock. This feels like they’re “doing something.” A good PM stays at least a few weeks ahead of engineers so that engineers are not PM-blocked and become tempted to jump to the next swanky mock. 

Most people think big tech companies have perfect product development processes – but the truth is, whether they're small startups or big corporations, people at both companies are vulnerable to chasing highs.

Short-term High: Playing “hero” to burning fires

When I was at Tesla, it was exciting to be part of a bigger product org at a company that was rapidly growing. When I got there, I noticed engineers were consumed by constantly putting out fires. They’d spend most of their time responding to whichever most recent Jira ticket they were pinged about, or whatever bug Elon or the VP of Software ran into that morning, making those issues the top priority.

Using anecdotes as a prioritization scheme can hurt the success of your product – it can be tempting to build and focus on feature development and forget about data. However, without analytics, it's hard to have a clear picture of where your efforts should be focused. Clear logging moves your team away from prioritization by anecdotes.

The task of creating an exhausting list of events and metrics to log seemed daunting – and boring. Logging was something people didn’t get a high from, but was important, so as a PM, I needed to figure out an incentive mechanism to get people to rally around it.

I found it much easier to get traction when I anchored my focus on the user. What was the baseline path for a Tesla user, and how were we measuring up to users’ expectations of that? In this case, if I had a music system in my car, what would I expect it to do?

Primary analytics:

• I can turn the music system on and off

• I can mute and unmute

Secondary analytics:

• I can connect my phone to the car with Bluetooth

• I can listen to Spotify and Apple Music

Tertiary analytics:

• The car remembers my listening history from previous trips.

• The car makes music recommendations, taking into account my tastes and the kind of trip I’m taking (e.g. morning commute vs. a night out with friends).

Having all of these features on a giant wall sorted by basic and advanced versions of functionality made it easy for me to drive the org from prioritizing ticket by ticket to category by category. And over time, instead of prioritizing individual requests, we prioritized everything in the mission-critical category, and then worked our way down the hierarchy.

Short-term High: Hounding people to get things done

As a PM, pinging people about deadlines feels satisfying in the short term, but in the long-term, it can be a dangerous way to operate. There are several reasons:

1. It’s not a good use of PM’s time if all you’re doing is following up with people in your team about updates.

2. You’re creating overhead for your teammates to give you updates when writing the update itself is a bigger time sink.

3. You are getting dangerously close to micromanaging. 

You can hound people occasionally when you really need it, but should only do it sparingly. Instead, what you want to do is create more efficient systems to drive execution, rather than being a bot that pings people.

For example, recently I noticed that an external partner had emailed my engineer and me a question that hadn’t been responded to in two days. It felt easy to ping him and ask him to respond to the email, but I paused and realized the long-term healthier path is to work together to agree on a set of guidelines so that next time I wouldn’t have to be a ping bot. In this case, it was agreeing on a set of agreements for communicating with external partners, such as a 24-hour response time. Another example of a more efficient system is making your team standup more effective.

It’s impossible to completely remove the toxic highs from your product team – but by being aware, you can course correct and navigate the emotional difficulty of going against your first intuition, and instead do the things that propel your team long-term.