The Well Rounded Product Manager

Writing

Have you ever had a good idea for a movie, then thought about it for thirty seconds only to conclude it wouldn't work? What about that other idea that made it past the thirty-second thought stage? Did you start writing to flesh out the idea only to realize it wouldn't work? Then maybe you revised your idea and got further along, or perhaps that idea was bad, too. Ultimately, you arrived at what you thought was a good idea, or it's more likely that you abandoned your movie-producing dreams.

What you've done is put your thoughts through a series of smell tests and logic gates. The further the idea got, the more well-thought-out it was. Notice that the thing that popped into your head is likely very different from the idea you went with (or from which you walked away).

This happens because the act of writing forces you to rethink everything with a skeptical eye. Why? Because you're not writing for yourself. You're writing for someone else. The ideas in your head don't exist in anyone else's. So now you have to communicate those ideas to others. You now need to create the 'aha' moment in their brain.

When discussing product management, new product ideas, product structure changes, and other details have a material impact on a company's bottom line and standing within the market. And decisions are primarily zero-sum. If we do X, we can't do Y (right now). As a product leader, you must communicate effectively and efficiently. If nothing else, you are a clarity-generating machine. The best way to scale this capability is through deep, asynchronous communication—mostly writing. Some people view writing as a challenge or a waste of time. Sometimes, they view it as overkill. This is because they 1) don't have the muscle or 2) haven't been on the receiving end of a well-thought-out product narrative.

The Writing Muscle

In my younger days, I trained as a powerlifter (although not competitively). At my strongest, I could deadlift about 430 pounds. While not earth-shattering, this was respectable for someone who sat at his computer all day. Obviously, I started much lower than 430 pounds and utilized progressive overload to increase my strength gradually. The operative word here is "progressive": I needed to practice. Initially, lifting 225 pounds was tough and was the weight for my last set (when I lifted the most). At my strongest, 225 pounds was like a warm-up—I'd quickly run through a set of ten reps so I could add more weight.

Writing works like this—it becomes easier with repetition. You must "get buff" so you can competently make a case for shifting resources when you need to alter the product roadmap's direction. When you fail to do this, you give the team whiplash by incomprehensibly pulling their time and attention in different directions. Not knowing what to build is okay, but neglecting the time and attention required to produce the correct answer is not.

Context

If writing is your sword, then context is your shield. One's goals should be rooted in strategic narratives—the why. Use narrative writing to set context, but don't overthink this. Context is mutable, changing as we add data. Engineers make many micro-decisions daily. How will they know which ones are right? Here is where context is handy.?

If the team is building a data pipeline, implementation details can depend on context. Streaming device telemetry for 200 million smartphones differs significantly from pulling appraisal data for 1 million single-family homes once a month. However, while both these use cases can be described as data pipelines, experienced engineers will immediately understand the broad challenges inherent to both builds. This is an extreme example, of course, but say, for instance, you've received user complaints about your mobile app's battery consumption. The team will need to know that this issue will likely be a key constraint for the build. You may need to send data less often unless connected to an external power source. For the engineering team, this context is more important than the exact solution.

You may ask yourself, 'How do I know what's useful to share?'. You obviously can't re-articulate every decision about a product before proposing a change. This is where dividends are paid, and tooling helps. If you create the habit of narratives, you can account for changes in said narratives in a natural way. Keep your writing organized by creating a metadata taxonomy that allows for discovery. That way, if a consumer needs more (past) context, they can filter their search using tags or keywords, allowing them to go back in time and replay the narrative changes. I don't want to get too deep into tooling and tactics here, but let me know if you want a future post about this. This is a solved problem.

Influence

Keep commitments, own missteps, be transparent, compromise, and support others.

Most product managers are ICs and don't have direct authority over people. Therefore, PMs must get things done primarily through influence. Your influence is closely related to your reputation, so maintain a healthy reputation to maximize your positive influence. How can one maintain a healthy reputation? It's generally obtained through trust and respect. I may not have the authority to make you do something, but if you trust and respect me, there's a good chance you'll do something for me. How does one achieve trust? Keep commitments, own missteps, be transparent, compromise, and support others. This influence is most handy when working directly with engineering teams. Excellent engineers can be the worst to work with if those needs aren't met. Context is critical because it makes tiny decisions easier to make. Without it, engineers may feel like they're building a road that goes nowhere. Without a destination and known path, you wouldn't have someone start building a road. You'd have to tell them where it starts and ends and how many lanes are needed. Will there be trucks? Will there be pedestrians? In fact, resist the urge to ask for a road. Instead, set the context and say you have two cities that are hard to get to from each other. Maybe you need a road, but maybe high-speed rail is better. Maybe below ground? Maybe it's cheaper to just build things in town A, in town B, and vice versa. The solution aperture is likely broader than you imagine when applying the proper context.

Final Thoughts

There's much more to being a good product manager than communication skills and the ability to garner influence (data analysis, critical thinking, creativity, leadership, etc.). However, those are the skills I've seen overlooked the most. Understanding how to sharpen these skills within the context of your organization is critical, but the investment starts with you.