If you work in a startup or creating a brand new product in a larger firm, an early decision about certain design bound to be a stumbling block later down the road.

Before we go further, I just want to let you know that this is normal. The decision we make base on incomplete knowledge tend to come back and bite us. There is no way to completely avoid it. Because, to get more information about this incomplete knowledge, we got to launch and iterate base on the user's feedback and detailed analyst. You cannot get either of these without launching first.

In engineering, this is called the Technical Debt. They are the accumulative decision we make base on incomplete knowledge, rushing for a deadline, just getting things done, and sometimes bad engineering practice.

What can a Product Manager do?

If you have read this far, you bound to face a dilemma. Engineers are complaining to you about how the code is unmaintainable. Beside hacking around it, they are afraid of breaking things without knowing it.

Help Everyone See and Understand It

As a product manager, you need to help the engineers to fight for time. You need to help prioritize fixing technical debt like how you would do for building a new feature. Except, this is gonna be difficult. Because management doesn't see it, the client doesn't see it and the user doesn't see it.

So first, you need to help them see it. If it is poor performances, inconsistent bugs, or bad user experience, you need to measure and report it. The engineers bound to use some monitoring tools and reporting tools like Sentry or Datadog. All these are tools that help engineers identify issues, but it can also use to help the Product Manager build a solid case of problem and solution.

So, instead of going to the board and say:

  • we stop building feature and need 2-3 month to fix technical debts

You need to work with the engineers to turn it into something measurable. For example:

  • We are going to improve app performance by X time and that could potentially reduce Y number of customer support ticket for customer's with slow network
  • We are going to improve report generating speed by X time and that could potentially save us Y amount of dollars by consuming less CPU time

If it is something that blocks the whole team from moving forward to build new features, then it can also be something like this:

  • We are going to re-design some parts of the backend architecture to build the next 3 upcoming features. This is going to save X amount of time and cost as compared to hacking it out now.

Everybody is on the same boat

Technical debt is not the fault of the engineer. It is the fault of everybody because issues and optimal solution only become clearer once we start working on it. Management, Product Owners, Product Manager, Designer, and Engineers are all part of the chain who make the decision. Although engineers are closer to the problem because they are the ones who execute it, they should not be the ones who take the blame.

As a product manager, it is our job to help everybody in the company to understand where are the technical debt. We need to highlight, measure, and monitor potential issues before it snowballs bigger.

It will be for everybody good to help engineers crave out time and allow them to plan and fix the technical debt.

Thanks for reading! If you like it, subscribe πŸ‘‡πŸ‘‡

Product lead at Milieu Insight πŸ‘¨β€πŸ’»πŸ‡ΈπŸ‡¬, Engineer, maker, and designer in my free time. I write short posts base on my experience. If you like what I posted, please subscribe.

You can also find me on twitter. Have a nice day!