Product Management Debt and What to Do About It

“…I try not to borrow. First you borrow. Then you beg.”

— Santiago, The Old Man and the Sea

Who here hasn’t been awaken by the technical debt collector? Your team ends up scrambling over Thanksgiving weekend to mitigate a surprise DDoS attack. Oh, and Amazon just sent you a bill for $257,873. Damn. Should have hired a Dev Ops guy.

Ben Horowitz in The Hard Thing About Hard Things refers to another species of debt: management debt. Suppose an employee comes to you, the manager, with an offer to work elsewhere. You match or exceed the offer. The next thing you know, the whole office learns that the best way to get a raise is to go get an offer somewhere else. Ouch.

I write this to extend the concept of debt to the realm of Product Management. If you have any of these symptoms, you probably owe Product Management debt:

• Sales: They come to you with question after question regarding your product. Demos rely on you because Sales can’t evaluate a good use case.
• Marketing: They come to you because they need collateral but are insufficiently familiar with the product to take the first step. Or you look at a list of MQLs disqualify them all immediately.
• Support: They don’t know enough about it to troubleshoot, so they involve you to handle every bug or support call.
• QA: They frequently ask you whether this or that is expected behavior. A good portion of your bugs turn out to be user error.
• Executives: They come to you for explanations for release dates, updates, and high priority bugs.

How and why does this happen? I posit that the cause is rooted in temptation; it’s tempting to bend over backwards for the other departments. With intimate knowledge of the product, it’s tempting to resolve issues more efficiently than anyone else in the company. You can get away with it for a while, but if and when your product grows, you’ll find that you’re so busy doing everything that you can get exactly nothing done. As a result, you haven’t spoken much to clients or groomed your backlog. (What the hell’s going in the next release?)

Fundamentally, the problem is a lack of knowledge transfer. There are several insidious consequences:

• A young product manager may not recognize that this is an issue. He or she may think, “My product is growing, and so it’s expected that I burn the candle at both ends to ensure its success.” This is a recipe for burnout.
• From a distance, Sally may appear to be a great product manager. She’s a bona fide workaholic that cares deeply about the product. In reality, Sally has failed to create an optimal environment for supporting and scaling her product.
• When management finally figures out what’s going on, a lot of the damage is already done. It’s hard to a replace the product manager because the company was dependent on him or her to perform multiple job functions. The next product manager better be a senior level guy or gal to right the ship.

Some debt is normal for a nascent product or POC. Product managers are expected to do a little bit of everything in the early days. Nonetheless, it’s important to recall Patton’s prescription that a pint of sweat saves a gallon blood. How can one prevent or reduce Product Management debt?

• Manage Just Enough: From the start, you should only be assigned to discrete features or products small enough for you to effectively manage. As your competence grows, so too does your ability to manage larger products or feature sets.
• A Visible Roadmap: Keep the vision and roadmap highly visible. Stress this vision to ensure there’s a high level understanding of what your product is and where it’s going.
• Meet, Meet, Meet: Put time on the calendar to meet with Sales, Marketing, Support and QA. Hold regular sessions with these groups in the time leading up to a release. In addition, send your executives frequent updates.
• Documentation: Ensure your documentation is posted and updated in the same location. Refer to it frequently in your meetings.
• Training Material: Have a variety of demos, documents, videos, slide decks and so on. These should be posted early and consistently in the same location.

At its core, enablement is about teaching. It requires several modalities and a lot of repetition. If you feel like a broken record repeating yourself in meeting after meeting, you’re doing it right. Creating the proper structure ensures you spend less time reacting to fires. Consequently, you can spend more time speaking to clients, researching the market, and pitching innovative ideas. And that’s the absolute best use of a product manager’s time.