I'll start with a warning: this is a very contentious topic.
Let's talk about a typical scenario:
A Product Manager or Product Owner is hired to help a team move towards a vision. They do so by making the right prioritisation decisions for their team.
On the other hand, engineers within a product team have the responsibility of not only building and shipping good quality features but also maintaining those features and scaling them as needed.
As the team grows and more features are shipped, two things will happen:
- You will discover that not everything works quite as well as you thought it did. After all, there are now many more users able to discover odd edge-cases your team may have never considered before.
- Your code base will get progressively messier and harder to maintain. Each little shortcut you took to be able to ship a feature faster in the past is now making your codebase look like frankenstein.
At this point, your team may reach an impasse. Your product manager might be pushing to keep shipping new features whilst your engineers might want to stop and fix things.
Sounds familiar?
Throughout my career, this exact scenario played out more times than I can remember. I first experienced it as an engineer very early in my career and remember sharing my frustration with my team: why was the company so happy to prioritize new features over fixing the mess our codebase had become?
Later on, at Hotjar, I got to experience it from a very different angle: as a company co-owner and as an engineering leader who worked with other product leaders. I discovered a very different perspective to the problem.
Engineers would come to me and express frustration at things being broken and not being "allowed" to work on tackling technical debt. On the other hand, product leaders would voice their frustration because they thought engineers were trying to fix things that had almost no impact on the business.
So who was right?
As it turns out, both. The issue stemmed from the fact that engineering issues were often presented as "engineering" problems. Cleaning up code or re-writing part of it was almost always regarded as work that engineers wanted to do but that provided no real impact to the product or the business.
But think about it.
Whilst cleaning up some code today might not provide value to users straight away, it might mean that a planned feature upgrade can be done much more quickly now that the code is well structured. Likewise, a cleaner codebase might mean that a new engineer joining the team next month will get up to speed much faster.
To be clear, the point I'm trying to make isn't that all technical debt needs to be solved – it shouldn't – but the discissions on whether something should be fixed at all needs to be based around the real, long term, benefits to the team and its momentum. To a product manager, having a cleaner codebase means nothing. Being able to work on something twice as fast can be a game-changer.
So you see, it's all about the narrative.
Are engineers taking the time to build business cases around the issues? Are they explaining the real benefits and risks? Or are they just adding tickets and hoping they get added to their backlogs?
Likewise, are product managers/owners taking the time to understand the main issues that are causing the team momentum to slow down over time? Do they have a good understanding of why the technical issues exist in the first place?
And that takes me back to the title of this post: Product and Engineering do, in fact, share the same goals. They both exist to help the company move towards its vision. They both want to build the best product possible, as quickly as possible. Their existence, in fact, is dependent on the company's success. If the product and company fail, so too will the teams.
The first step to an improved relationship between product and engineering is to acknowledge that they both want the same thing – progress towards their company's vision.
Engineers need to understand that the team can only move forward if it adds customer value fast enough to keep customers satisfied and keep the product relevant. Sometimes this might mean having to live with technical debt and instead focusing on new functionality that customers have asked for.
Likewise, anyone working in a product role needs to understand that over time engineering issues will inevitably start to cause the team to slow down, and in turn, make it harder to progress towards the company and product vision. The best product managers proactively enquire about technical debt and often prioritize fixes that impact team momentum.
So how can you do this in practice?
If the friction I've been talking about exists in your company, there are a few things you can do to improve the situation:
1. Engineers in each team should set up periodical meetings to review the list of pending issues and technical debt and keep them prioritized according to their impact on team momentum.
Of course, I'm not talking about critical bugs here – those should be fixed according to severity. What I'm talking about here are all the technical improvements that might not immediately have an impact on your users.
The key here is for engineers to learn how to build business cases. You can think of a business case as a simple, short document explaining the risks and benefits of ignoring or fixing an issue.
You don't need to spend ages working out the exact ROI either. It's usually enough to know what benefit the fix gives you beyond the cosmetic change. Will it make it easier to improve that area of the code? Will it pave the way for a new feature? Will it help you avoid the scaling issues you are likely to get a few months from now? Will it reduce the onboarding period for new team members drastically?
2. Product managers should take the time to periodically review this list and understand it fully by collaborating with the team's engineering lead and engineers.
It's critical for anyone working in a product role to understand as much as they can about the engineering ecosystem. This can only happen if they take the initiative to involve themselves in technical conversations and understand the levers that affect the team's development cycle.
Any experienced product manager will know that product success does not happen overnight. And in the real world, it certainly does not happen by shipping new features non-stop. The best product managers actively seek out technical improvements that can speed up delivery in the long term.
3. Make the prioritisation process as transparent as possible and make sure there's always a clear reason for saying NO.
Even when the ROI of solving technical debt and issues is clear to a product manager, there will be many instances in which they will still not get prioritised. This is absolutely normal. After all, the product manager or owner's role is to always prioritise according to what the business, product and team needs.
With that in mind, it's critical that when an issue is purposely ignored, there's a good reason to do so and that reason is clearly communicated to the rest of the team. This can happen in a planning meeting or can even be documented in a document somewhere, but it must happen.
Engineers will not always agree with prioritisation decisions, but they should never feel like their concerns were either not listened to, or complelely misunderstood. This is where it's important for product managers to reiterate what they're hired for – to take hard decisions and be able to say no in the name of progress.
At Hotjar, we recognised that having Product and Engineering work in isolation would not work, so we decided to merge Product and Engineering (and Design) into one – our Tech department. Naming conventions might sound insignifant, but these are the little things that help to reinforce the notion that product and engineering are working towards a common goal.
If you're a founder, or a product or engineering leader, you need to actively try to break down the wall between your Product and Engineering teams and help them understand they will be much more successful in the long term if they collaborate together.