Every problem in your working life can usually be boiled down to one thing: misaligned incentives.
To find the source of these misaligned incentives, so you can start understanding and doing something about them, you’ve first got to understand the root of the problem.
The Iron Triangle of constraints – the root of the incentives problem
You might be familiar with the Iron Triangle of time, cost, scope, and quality. For any one of these factors to give, we’ve got to be willing to give on another front.
We rarely have the spare budget or all the time in the world to play with, so time or cost is often flexed, in exchange for scope and quality.
This is exactly what we’re doing when we run experiments using quick prototypes and MVPs—we’re trading off our requirement for perfect quality or 100% full scope in order to gain back a chunk of valuable time and cost.
Those time and cost-saving are hugely valuable to any company looking to move quickly and iterate what it learns from experimentation.
As product people, we make these trade-offs all the time, often without even realizing it. These trade-off decisions help us achieve the best balance of speed and quality of output needed to achieve the outcomes we are aiming for.
The problem comes when different stakeholders in the business are incentivized to see different outcomes and yet are still bound by the constraints of the Iron Triangle.
Misaligned incentives spell trouble for product teams
One of the most common sources of tension in a team is a situation just like this: A person in your tech team and a person in your sales team are in a disagreement about something that you’re trying to deliver. It’s not a personal thing. They’ve just got different ideas of what the outcome should be for the initiative and bending their will to the other means going against what they’re incentivized to do.
More often than not, it’s your developer who’s advocating for the quality and scope side of the equation. They want it done fully and done right. The salesperson wants it out the door sooner rather than later and is annoyed they aren’t getting clarity on when that is or why it keeps changing.
They’re both feeling the pressure to give in. If it’s an engineering-led organization, the salesperson usually has to back down. If it’s a sales-led organization, the engineer often loses their footing here.
As the product manager, you’re stuck in the middle as the mediator, trying to find the best balance that meets the needs of the business, and doesn’t lose the trust of either stakeholder!
How to fix problems stemming from misaligned incentives
Fixing this requires trust and a shared vocabulary. These team members need to be able to speak honestly about their incentives, and the trade-offs they are and aren’t willing to make.
Talk to the salesperson. What’s at risk if this misses the original deadline they were hoping to see this done by?
Sometimes there’s nothing truly at risk, though it gives a sense of eroded trust as they can’t see the value of the last mile of development (we all know how long that last 20% can take!). Enlightening them in the process, and showing them the value of having good quality, stable, secure, and documented code can often win them on to your side.
Sometimes their livelihood is at risk. Perhaps they’ve been unable to sell the current iteration of the product, and they are depending on this new release to be able to unlock sales and therefore unlock their commission. It’s a horrible thought to think that someone’s paycheck could dry up based on someone else’s pace of work elsewhere in the business, but it does happen. In this case, it’s important to escalate this issue, as that pressure does not belong with the development team alone. That’s a problem with how the sales team is being incentivized and the tools they are being given. The executive team should be aware of the issue and look to fix the issue. If the current product isn’t sellable, the sales team shouldn’t be on commission-based pay for sales on it, or else they will be incentivized to sell things that don’t yet exist! If the current product is sellable, the salesperson locked in this fight about hitting this deadline needs to be sufficiently trained in how to sell it, and refocused on those efforts rather than in places where they cause further tension.
If you don’t get support from your execs and salespeople in this tough conversation, there’s a possibility that your company is actually stuck in the Agency Trap, where the misaligned incentives go straight through to the core of the business model.
Talk to the developer. What’s at risk if you were to release a portion of what’s ready in the next release? This isn’t a threat, but a thought exercise. It’s a way to explore how work can be broken up into smaller chunks, if at all, or if it needs to go out in one piece. It helps to illuminate insights into what’s done and what’s likely to be left out. It’s important to listen carefully to your developer here, as they have expertise that’s usually not matched by others in their domain. Your job will be to help them translate these requirements into something that the other stakeholders can understand, and buy them time and space to crack on and get the important parts of their job done.
This doesn’t mean a middle ground can’t be found. These conversations illuminate where common ground is found, and a compromise can be reached that works for the business.
Perhaps the stakeholders agree on a time-limited experiment to be run, where some of the code is released so that it can be tested, but with the agreement that time is carved out so that the engineers can refactor afterward, based on how the initial piece of work fares. Perhaps the conversations help to realign the salesperson’s expectations and allow them to see a little bit more of how the product is built. Or maybe it’s just an agreement to get the engineer in on the conversations earlier next time so that these misunderstandings are avoided in the future.
Incentives run deep in our companies’ cultures
This might seem like a simplistic situation that you’d chalk up to a misunderstanding, but it’s fundamentally tied back to how the company is asking them to operate, and indeed how the company itself operates.
See, some companies get stuck in a real short-term-ism mindset. They want to see results quarter-on-quarter, but don’t think about the long-term health or viability of their business.
This results in, frankly, bad decisions being made about how to run things.
For example, think about your publicly traded, extra-large organizations. These companies have a fiduciary duty to maximize shareholder value. What this means in practice is that they want to see that stock going steadily up and to the right. It doesn’t have to be fast, it just has to be steady and predictable. After all, predictable is something you can invest in, and that’s really the value of a publicly-traded company, if you’re an investment manager.
So these companies are incentivized to keep those numbers moving steadily upwards. Any blips in performance—a few bad quarters—and the CEO is often turfed! That CEO has no incentive to try new, risky moves that might help them explore exciting opportunities or fend off growing competition. Their job is to keep the ship afloat and sailing straight— Maximize the revenues from the areas that already generate revenue, and keep costs down across the board.
The best way that these companies know how to maximize revenues in each area and keep costs down is to break things up into siloes. That way, they can measure each thing independently and push and pull on levers where needed.
But we all know siloes are not the way forward—they stifle innovation!
Furthermore, they get divisions in a tight spot where they often start working against each other. You might have one team tasked with getting support call time down, and they are perfectly capable of doing that!…. Except that it makes another team’s customer satisfaction scores also dive bomb. Or have one team tasked with cutting travel and expenses, with the knock-on effect that sales and product people meet with customers less and therefore pick up less market knowledge.
Are you working in a profit center or a cost center?
Some of the way that organizations treat their divisions comes down to whether they regard that division as a profit center or a cost center.
Profit centers are areas of the business where they know that they put money in, and revenue predictably comes back out. At the enterprise level, generally, the aim is to keep this engine running smoothly, and keep chucking more funding in. More sales, more marketing. As long as it’s working and they are seeing profit out the other side of the equation, the business will continue to invest heavily in this division.
Cost centers are necessary divisions that keep the business running, but aren’t seen as revenue generators. You put money in purely for the aim of keeping the rest of the business going, but you don’t expect a big return to come out of these investments. Typically, divisions like HR and operations are considered cost centers.
And us in product and tech? Well, of course, we’re regarded as a cost center. Our R&D and discovery work is rarely thought of as an investment in the future for potential revenue growth, but a necessary evil, required to just keep the lights on for sales and marketing to do their job.
And it Explains. So. Much.
The job of the CTO often isn’t to maximize value to the user. It’s to keep costs down in the tech division.
Think about all the measurements we’ve all lived by. Velocity. Burn down. Story points. These measure output, not outcomes. They are useful if you’re trying to squeeze as much productivity out of a tech team as possible, as quickly and cheaply as possible. They’re not going to help you figure out if you’re actually building the right things.
After all, you could finish lots of story points! Incredible velocity! Burn down charts like no where else! But all that’s saying is that you probably built a lot of features, at best. And everyone knows that a lot of features don’t make the best product.
This way of working might control costs, but it optimizes for building features, not for solving problems.
It’s focused on output, when it should be focused on outcome.
The team is rarely left with room for discovery, and leads to the company often being blind to the bigger problems or opportunities in the space.
Think back to the likes of Blockbuster, who could have taken a risk and had the chance to acquire Netflix, but they didn’t dare take the leap. They were incentivized to stay the course.
Think back even further. Kodak themselves had the technology to take a real crack at digital photography, but didn’t have the incentive to do anything with it. They saw the revenue from their existing line of film products, and continued down their predictable track of investing in sales and marketing in those areas.
Neither of these companies, and many others like them, felt the need to explore what the future might hold. The way the companies were structured and how the execs got their jobs and their bonuses and their pay, there was no baked-in incentive to even consider it. Efforts to innovate from within were smothered, and eventually, these companies died.
Ultimately, incentives were the problem here. Incentives are almost always the problem.
So whenever something doesn’t feel right or isn’t running as well as it could in your company, really dive in to figure out what might be in the driving seat. Who is being incentivized by what, and how is that playing out in the dynamics of the situation? Use this information in your favor, to pull the right levers and present more compelling arguments—it might just save your business from a Blockbuster fate.
The post The Incentives Problem appeared first on ProdPad | Product Management Software.
