Help, my Product Owner wants a broken car
PO: Hey team, what would it cost to build a car?
Team: approximately somewhere between 50 and 60K
PO: The thing is, I need the car tomorrow to get to a valuable job and I only have 30K. But I really really need it.
Team: sorry mate, can’t be done
PO: what if we’d put in that old engine we have laying around?
Team: might reduce the total with 7K, but it’s not reliable
PO: okay but I need it tomorrow, it will last. How about the seats, can we drive without those?
Team: sure, but the experience will be horrible, how will you sit?
PO: no worries I just need to get there, how ‘bout them breaks, I know they are severely worn out, but we don’t need new ones, we’ll only drive 2km
Team: oh dear…
Understand the dynamics
The PO is basically the client. He or she asks the team for an offer on the requested functionality. Based on the offer, he prioritises his decisions. He might or might not want to proceed with his request, making it an ‘invoice’. That’s the moment of committing.
If you look at it from this perspective and take it outside of a technical / digital context, a lot of things start making sense. The product owner needs his car to be able to make money. But the team has the responsibility to make sure the car is of a good quality or it will break.
Responsibilities
It’s the responsibility of the PO to make the most out of the development time and the product he owns. But this knife cuts on two ends. On the one hand he has to be sensitive for short term gains. But on the other he has to guard there are no long term risks.
It’s okay to force the car to do those 2km on fumes every now and then, but don’t expect the car to drive any further afterwards unless you are willing to improve it.
In software development this is rarely honoured. We often build something and we roll with it until it breaks. On the long term, more and more of these projects entangle with each other, creating an environment that’s hard to break out of.
He who buys, only partly knows
When your PO asks you for an offer on functionality, make sure you factor in the effort needed to make it safe and durable. This is just part of the price, and it’s not negotiable without a strategy. Weighing in those factors is the very craftsmanship you are hired for to perform.
This is why I have an aversion to the term technical debt. While it’s true that technical debt exists, it’s often a misused term. Asking your technicians to ‘not replace the brakes’, is not a choice made by the technician. It’s a choice made by the maintainer of the car. Therefore it’s rather a product debt. It’s a choice, which should also be solved by the owner of the car.
I think that we often overlook our responsibilities on both ends here.
It is to the responsibility of the team to provide the flexibility to reach targets. But it is also the responsibility of the team to make super clear that this solution doesn’t hold for the long run, and will break down sooner or later.
Accordingly, it is to the responsibility of the Product Owner to be fully aware of the real price, rather than the bargain for the short term. This can mean two things.
- You get the car, do the transaction and upgrade it as you make more kilometers with it.
In other words: take the short route, but commit to the long route. Immediately add the taken shortcuts to the backlog to be able to work on them and have them in sight so you exactly know where your product might break and how it will become more stable in time. - You get the car, do the transaction, but trash the car afterwards and learn from it.
In other words: Take the short route, and remove the half baked solution from the product and learn what the value proposition of the feature is. This can help when you make the next investment.
Key takeaways
Making sure you have a stable, consistent and safe product should always be on the top of mind.
Not the feature that’s added to the product, but the product itself that holds all the features should be the focus.
- Abandon unmaintained risks. If the cost of the stability, security and performance cannot be afforded, the initial value proposition should be discarded.
- Improve long term valuable functionality proactively
- Technical Debt is owned by the product owner
- Enable your PO for short term gains
- Trust your team for long term stability
