Why Product Managers Should Be Technical
It’s commonly understood that product managers at tech companies should be technical, but the explanation of why typically ends at “because you’re building a software product”. This is true, but its conciseness belies the higher-order benefits that a product manager who understands the technical challenges of a team can provide.
This article presents three areas where a technical understanding can serve as a performance multiplier — more thorough planning, smarter tradeoffs, and developing the sustainability of the team.
Internalize complexity
Product Managers are the API to their product. They are the interface between the external requests of users who want an end result and the internal tradeoffs the team has to make in order to deliver the experience.
An “intuitive” product is high praise, but building an intuitive product is not easy, and is always intentional. The difficulty lies in along the edges, the ghosts of past decisions and assumptions that come back to haunt your team. Being technical allows you to navigate this in two ways:
Translation. The key to an intuitive feature is fully anticipating the needs of the user and building a system that nails every single use case, rather than shrugging at the edges. If a product manager only had one responsibility, it would be to fully represent the best (most intuitive) experience for the user. You enable that experience by layering in the technical details, ensuring an accurate translation of a feature request into a engineering request. The product manager embodies the spirit of a feature, and by internalizing the consequences of necessary tradeoffs, you will ensure the spirit doesn’t get lost between ideation and execution.
Forwarding-facing planning. The more you understand the constraints of a system, the better informed your choices around it will be. That includes taking a roadmap and feature extensions into account when setting initial requirements. Extending your product strategy to include technical architecture will preempt incompatibilities down the line, and give your engineering team a chance to weigh in and collaborate on ways to achieve the product vision.
The same feature can be accomplished by a simple system that just barely meets the requirements, or a more complex one that has room to grow. The right answer depends on your plans, and having the ability to judge which system you’re looking at is necessary to make the decision.
Reality check
The product manager’s understanding of a feature can differ dramatically from an engineer’s perspective on the same feature. Relatively trivial product changes can meaningfully shift the engineering effort, or vice versa. Internalizing your end product goal alongside the engineering challenges leads to more informed decisions on tradeoffs.
Prioritizing a broader scope. No feature is built in isolation. Prioritizing work into the most efficient ordering, to capitalize on shared benefits of code changes, is a productivity multiplier for a team. These decisions are even more impactful when you can make level-of-effort (LOE) estimations, pacing the team’s work to have consistent output to keep up both morale and outward appearances.
Making tradeoffs to keep a product alive. Even with the best engineering team, you’ll have to scale down, descope, and cut features to make an MVP. Project scope decisions consider two dimensions: the importance of a feature and the effort to build it. It’s a simple cost-benefit analysis. Though you’re the champion of the “benefits” side of the equation, having a working knowledge of what’s feasible for the engineering team allows you to explore pivots that can bring a more favorable cost-benefit ratio while keeping the spirit of a feature alive.
Facilitate
An understated aspect of product management is that while end-users are the users of the product the team builds, your immediate team are the users of your product management. No one enjoys working on the same project that’s been dragging on quarter after quarter. Everyone would rather work on the shiny new feature that gets air-time at the end-of-year presentation over the backlog of bug fixes, even if they have an equal impact on metrics.
Develop, prioritize, and execute work in a way that’s engaging for the people who you rely on to actually bring your ideas to life. Sometimes that means delaying a feature that you know will have impact, but will be dreadfully boring for the unlucky engineer who is assigned to it. Sometimes it’s just making sure that your MVP has enough omph to spark energy and excitement, even though a more minimal prototype would’ve been sufficient.
Anybody can come up with product ideas — just open Twitter. A product manager’s role doesn’t end with dreaming up ideas — you have to manage the entire process so that the feature will get shipped. People skills, communication, managing up, leading without authority — these are all essential, but we can’t forget the people we most often take for granted, the engineers who do the actual building.
Product management is about making decisions around tradeoffs. The more fully you internalize the second, third, etc. effects of the tradeoffs you make, the more you can elevate your team and product.
Being technical isn’t about “calling engineers on their BS” or going toe-to-toe with your eng lead to fight for a feature. It’s about empathizing with the actual user of your product management and building a stronger foundation — both for the product and as a team — as a result.
Programming-curious?
I put together a 9-part course on algorithms designed for non-technical readers that's a great, gentle introduction to thinking like a programmer. Get the course for only $5, or download the first chapter.