The Five Dysfunctions of the Product and Engineering Relationship

In any technology company, one of the most important relationships is between product and engineering teams. Typically product managers spend time talking to users and monitoring their market to find new problems. Then they design solutions that engineers will code and add to the product for customers to use.

Like most relationships, the first stage is always like a honeymoon. Product managers and engineers spend all their time together, side by side. When product managers express ideas, they’re already pushed to production by engineers. Communication is almost telepathic. Unfortunately, as organisations grow bigger and older, the relationship changes.

Product managers become more frustrated as it takes longer and longer to code new features. On the other hand, engineers also become more frustrated with requests that don’t make sense or a lack of understanding of the complexity of their work. Communication becomes more difficult. But like most relationships, this is not ineluctable. The post below summarises the five most significant dysfunctions that can happen in the product and engineering relationship so that you can avoid them in your company.

1/ Too much inventory

The most significant difference between a product manager and an engineer is that engineers are bound by physical limitations, like the complexity of the problem to solve, the necessary time to code the solution or the number of available resources to tackle new features. On the other hand, product managers are mainly bound by their creativity. So, in a product-engineering system, the amount of product specifications in input is virtually unlimited, while the number of resources to produce them is limited, creating a never-ending inventory of new features to code.

Increasing the number of resouces on the engineering side would probably solve this problem. But hiring and onboarding new engineers is very costly, and it will only unleash even more the product managers’ creativity. One solution could be to virtually limit the number of new code features using a more stringent specification methodology (like the Amazon 6-pager) or a stricter prioritisation process.

2/ Chinese whispers

In the Chinese whispers game, each player repeats the message they just heard to the next player in the line until it returns to the first one. Although the objective is to pass the message around without altering it, part of the game’s enjoyment is slightly changing it to end up with a different sentence. Like in the game, sometimes features end up completely different than initially envisioned.

This scenario, if recurrent, happens when engineers become less, or not at all, involved in product design. When companies grow, the separation between product and engineering becomes more prominent, and individuals focus on creating or executing tickets. A typical way to solve this problem is to create autonomous “feature teams”, where product managers and engineers work together on creating solutions to solve users’ problems. Whether or not you decide to go for feature teams, it also helps when engineers are frequent users of the product they build, either by themselves (if it’s a consumer product) or by interacting with customers (if it’s a B2B product). It’s a shame that so many engineers never meet the people using the software they build every day.

3/ This is easy to do

Have you ever been in a situation where you have to build an incredibly complex feature, and your product (or business) counterpart just doesn’t understand why it’s taking so long? Unfortunately, this inability to empathise with engineers is commonplace in organisations where business and product people don’t have an engineering background. Because they can only focus on what they see, the front end, they cannot imagine what is required to make a feature work, creating frustration with engineers and sluggishness in the system.

Product managers should ideally have an engineering background or at least some coding training to empathise with engineering complexity. Engineers should also communicate better on the difficulties associated with developing each feature, indicating the difficulties (algorithm, database, system dependencies, complex APIs, etc.) and the difficulty level. Also, creating a system of trust between product managers and engineers is essential. In many companies, product managers and engineers constantly argue overwork estimates, the former thinking that engineers over-estimate features to work less, and the latter thinking that product managers over-promise to customers and don’t anticipate. Basecamp’s Betting Table is one kind of system to solve this problem: engineers commit to constantly supply the required features during a development cycle (6 weeks at Basecamp) as long as product managers commit to freezing new requests and changes during a cycle.

4/ Misaligned goals

When companies grow, it’s common to create product and engineering departments, with C-levels, Heads and middle managers to set objectives and lead teams. In some cases, when the departments grow apart, the objectives can sometimes become conflicting or even antagonistic. For example, conflicts will start if the product team’s current objective is to create more features and the engineering team’s current objective is to focus on platform quality (because of recent outages). These conflicts can become even sharper if different managers use different KPIs to measure their teams’ efficiency.

The best way to align product and engineering teams is simply to get back to the goal of an engineering team, which is to deliver as much value as possible to users as fast as possible. So the only metric that matters, independently of departments’ sizes, is how long it takes to go from a greenlighted idea to positive user feedback. In a previous post, I introduced the TPUF metric (Time to Positive User Feedback), which allows both product managers and engineers to focus on the same goal, customer satisfaction.

The lower the TPUF, the more successful a company since positive user feedback directly impacts growth and profit. If TPUF is not low enough, maybe it’s the product managers who don’t spend enough time analysing the market, or maybe the engineering time is too high. When both product and engineering teams focus on the same metrics, it helps create a sense of unity in the company and avoids conflicts.

5/ New features only

Finally, a typical dysfunction in the product and engineering relationship is the pressure to only build new features, with engineers not spending a single hour on the technical roadmap. This situation is the norm for early-stage startups looking for their product-market fit, but when they have it, many companies forget that they’ve accumulated technical debt and have to pay it back.

In engineering, as in finance, if you accumulate too much debt, you become bankrupt. When a company doesn’t deal with their technical roadmap, it inevitably sacrifices long-term speed for short-term speed. Since today’s shortcut is always tomorrow’s blocker, savvy engineering teams should make sure they deal with technical debt early in the company’s history, but in small numbers. A big, multi-month reengineering project will hardly get prioritised over money-generating features, but smaller, frequent updates will be easier to address. Some companies don’t differentiate the product from the technical roadmap, using the prioritisation process to decide which projects will pass for this development cycle. Others use an arbitrary percentage of time allocated to technical projects. Others, again, dedicate special days or moments in their development cycles just for technical projects. It’s really up to your team to decide what works best for them.

To conclude, my main point here is that, like any relationship, it takes work and continuous alignment to keep the light going between the two, even when time goes by, and organisations grow bigger.