Let’s face it, technical debt is something that every Product Manager has to deal with on a constant basis — whether it’s making snap decisions that unblock your team so that they can keep working, short-cutting an ideal architectural solution because you have time-to-market pressures, or deciding to put off working on bugs found after a story’s been closed. While the common wisdom may be that you should never take on technical debt, the real world intrudes on such a fantasy each and every day, and if we don’t want to wind up in a death march that never sees the light of day, sometimes we have to make the choice to sacrifice some long-term stability in exchange for short-term gains. But how do you determine when there’s too much technical debt, or when the specific item of debt is too much to bear? That’s what we’re going to discuss today…
It seems to be a pretty common question in the PM world these days — just how technical does a Product Manager really have to be? And what baseline amount of technical knowledge and/or skill does at PM really need to have in order to be successful. Many development teams will tell you that they want a PM who can code — but I’m not sure that’s really a function of their needs, or whether it’s a reflection of them wanting someone who knows their domain and is on “their side.” And many technical businesses short-change the business and strategic knowledge that a good PM can bring to the table, relegating them to “spec-writers” whose interactions are primarily internal.
Having said that, while I don’t believe in any way, shape, or form that all Product Managers must be “technical” — I do believe that all technology Product Managers should have at least a conversational understanding of some key technical topics.
It’s one of the more frustrating parts of being a software Product Manager – you inherit a product that’s been around for awhile, and every time you want to start a new project to change and improve what’s already there, some nasty little issue crops up and takes the spotlight. Maybe the platform was never really designed to scale, maybe some customer is doing something outside the original intent of the product, or maybe the technology is just old and starting to crumble around the edges.
Regardless of the specifics, inevitably the primary cause of these issues is a mountain of technical debt that’s been built up by the teams working on the product over the course of its lifecycle — the shortcuts taken in the name of getting product shipped, the design corners skimmed because it was seen as an “edge case” three years ago, or even the architectural limits imposed by budget or resource constraints.
Regardless, once you realize what’s causing these issues, you need a plan to attack and mitigate the harm that these limitations are causing you — and that’s where you good old friend, The Clever PM, has a few tricks up his sleeve…
There’s a strong trend in Product Management circles to insist that a good Product Manager must be strongly technical in addition to having strong marketing and communication skills. And while this approach is well-meaning, it often results in a weak Product Management role that merely supports Development rather than challenge it.
Now, that’s not to say that a Product Manager can be successful without some basic level of technical competency — in order to have honest discussions with development teams, and to build the trust and respect of those teams, you must have at least a passing familiarity with the technologies that are being used by that team. You have to at least know what the terminology means – not knowing the difference between MySQL and NoSQL at a very high level, for example, can and will negatively affect your ability to write effective user stories.