What Product Managers Can Do About Technical Debt
If you‘re a Product manager, then you’ve probably heard developers talking about “code debt” or “technical debt”. It gets brought up a lot when engineering is asked to develop some big new feature (e.g. “Building this feature is going to require a big refactor”) As a Product Manager, it’s really frustrating to hear that your feature is infeasible due to something that seems totally outside of your control. What most PM’s don’t realize is that there’s a lot they can do from their side to avoid technical debt in the first place.
To understand technical debt and its sources, we need to talk a little bit about how software development works. Software development is much more art than science. It’s a lot more like writing a book than building a house. A developer can code a feature in infinite different ways and achieve the same result. The art is coming up with a design that will accommodate future changes in requirements.
Imagine you’re designing a human arm. Your requirement is that it be able to grab and raise a glass of water 18 inches above a table. As a Jr. Developer, your MVP architecture might include two fingers connected by a hinge joint to grab the glass and a single arm bone connected to the shoulder by a hinge to elevate the glass. That solution is cheap and reliable. Unfortunately, the next story off the backlog asks you to bring that glass to the mouth and you can’t do it without breaking a few bones. Refactoring is painful.
Sophomore developers, who’ve been burned by their lack of foresight, future-proof their design by putting ball and socket joints along every inch of the arm, allowing the user to twist their arm into a pretzel if they want to. Unfortunately, the user never wanted a pretzel-arm, the arm is massively expensive to build, and never works because it’s so complex it’s always sprained. You want too much, you get nothing.
An experienced developer knows where they need to invest in flexibility and where they can gain efficiency and reliability through rigidity.
This is where you, our heroic product manager enters the picture. The only way your developers can design an architecture that doesn’t need to be re-written is if they can anticipate future requirements. There are two things you can do as a PM to give your developers, and yourself, the best chance of avoiding pain.
Make sure your developers understand the business domain
The word “coding” is a misnomer. It makes it sound like a developer’s job is to take your human language specs and translate them into computer speak (bleep bleep blorp…). What they’re actually doing is writing your specs.
Code is nothing more than an unambiguous specification of how something works. Until your requirements document compiles, it’s not a complete spec and it’s your developers’ job to fill in the gaps.
Developers are writing your specs
Let that sink in. You would never let a product manager who doesn’t understand the business or product write specs, yet you may be asking developers to do just that.
If your engineering team doesn’t understand the business, they’re going to write code that’s incorrect, inefficient, and ultimately paint themselves into a corner from which only a painful refactor can save them.
If you suspect your developers don’t get your business, run some workshops. Do a product demo. Run some lunch n’ learns. Invite them to sit in on customer interviews. Ask for help on a competitive analysis. Create some sprint tasks for them to read the user training docs. Help them become better developers by making them better product managers.
Articulate your vision
Developers can’t anticipate requirements until they understand the product vision. One of the many tragedies of the Agile (read: Scrum) movement is the misconception that developers only need to consider two weeks’ worth of requirements to write great code.
Developers need to know where the product is going if you expect them to create designs that accommodate future needs.
As a Product Manager you know that you should ALWAYS be selling your vision to every part of the company. Make sure your sales work includes lots of attention to the engineering team. Don’t wait until you suspect that developers don’t understand your vision. By that point it’s too late.
You can tackle this head-on by including engineers, both managers and some individual contributors, in your product strategy sessions. Nothing generates more sustained buy-in from people than giving them a hand in creating the vision.
Ultimately, technical debt is an organizational problem. If development is moving slowly and you hear your engineers talking about code debt, take a close look at your product team. There’s a good chance that breakdowns in Product are just as responsible for those development challenges as anything that’s happening in engineering. Make sure you are articulating a clear product vision and that your engineers are spending the time necessary to understand the domain they’re working in.
