A hideous solution that doesn’t scale is sometimes the best option
Even when you feel like a puppet on strings, you still have options
I’ve been a Product Owner for more than 5 years, but I’ve never been the Product Owner — that single illustrious person with complete and final say over the whole product.
As a Product Owner, I’ve had to navigate complex stakeholder landscapes. This means often being at the whims of people with way more power in the organizational chart.
Even while ‘Product Owner’ is in your job title and the Scrum Guide bestows you with full authority over the product, you are rarely afforded this luxury in the real world. A title of ‘Product Whisperer’ would often be more apt in practice. I also think it is unreasonable to believe you can act in a complete vacuum and disregard powerful stakeholders at the top of the company.
When stakeholders propose something I consider a bad idea, I’ll try to listen first and hear them out. If I still believe it’s a bad idea after getting their perspective, I’ll try to reason with them we shouldn’t be doing this. But sometimes, power trumps reason.
Another reality is that sometimes your stakeholders are right, and you’re wrong. The problem is you don’t know when that’s the case. But this isn’t an article about stakeholders or about influencing powerful people. I am only setting the stage so you can better understand the story I am about to tell.
I’m telling this story so that even when you feel like a puppet with strings, you should realize you still have options to make a difference. You probably won’t make as big of a difference as you’d like. It also won’t necessarily lead to appreciation either, apart from the comfort of knowing you did the right thing.
Forced to deliver something pointless without value
Many years back, I was working for a highly political organization. The powers that be had decided we had to integrate with a third party to deliver a new capability. The business case looked amazing on paper, but that didn’t even matter. By the time the business case reached me, it had already been decided we had to build it.
Before I discussed the development of this fancy new capability with the Scrum Team, I looked up competitors who already were working with this tool, and I tried to look up reviews from customers.
What I found was shocking. Without exception, all online reviews from customers who experienced the third-party tool were horrible. Customers hated it and thought the experience sucked. At this moment, I realized all those fancy numbers on the spreadsheet didn’t matter.
The first thing I did was raise my findings in a meeting with management present. They didn’t care because the people above them wanted to do it anyway. Our leadership said, “This is a strategic project decided by the people high-up in the food chain.”
Somehow the word strategic, combined with C-level fairy dust, made it okay to do something that made zero sense.
Briefing the team on the integration
It was difficult for me to get fired up and brief what we had to do in a way that would inspire our developers. My heart and mind were no longer in it. But, given there was no way I could dodge this bullet, I gave it my best shot.
I presented the business case to the developers and explained why the integration would make a big difference for the company. We discussed our part in the large project involving many different Scrum Teams and the key touchpoints we would need to integrate with. Everybody seemed excited about the project.
The Developers did some whiteboarding and came up with a beautiful technical solution that would take at least 3 months to build. I was shocked and told the team we should never spend this much time on it.
Then I let the Development Team in on a little secret: “Look, I could be wrong, but I believe this project is going to be a massive failure. What is the simplest and worst technical solution we can build? It should be able to handle max 5 orders per day. If we get more than 5 orders per day, I’m fine with rebuilding it completely.”
I also followed this up with: “I understand the way I’m presenting this isn’t very appealing or motivating. I can’t help we have to work on this project, and I’ve tried to stop it. However, if we need to pull the plug on something we worked on for 3 months, that is far more demotivating than killing something we built in a few weeks. Plus, if I’m wrong, then we’ll rebuild it, and I’ll take full blame for having to do this.”
By now, you’re probably curious about what happened. Let’s get right to it!
Launching the integration
We built the integration in a few weeks without utilizing the capacity of the whole team. Testing is what took most of the time. We built a simple solution that wouldn’t scale beyond a few orders. Other teams went all-in and built scalable, future-proof solutions spending many man-months worth of effort.
When we put the integration live, here’s what happened: the first few days, we didn’t receive any orders at all! Now and then, we’d receive a single order, and if we had a really busy day, we’d receive two orders.
Yeah, imagine that: people getting excited over two orders a day at a big multi-million dollar company. That’s how infrequent and low-volume the orders were.
Then, the customer complaints started coming in (which had nothing to do with how poorly we built our solution). I researched and found out that more than half the orders coming through this integration would result in a customer complaint. This was several orders of magnitude greater than a regular order coming through our main e-commerce platform.
As I expected, customers hated the solution. 6 months later, we pulled the plug on the whole project. We lost a significant amount of money (and opportunity cost) by building such a pointless integration across all our Scrum Teams.
I was sad we lost money and wasted everyone’s time, but in the end, I was proud we spent less time on it than any of the other teams.
Did anyone in the leadership team realize the money, effort, and time I saved? Nope. I also couldn’t rub it in their faces without hurting their egos. Regardless, given the limited options, I am still happy I saved the company a significant amount of money.
Unfortunately, it was peanuts compared to the total cost of the whole project. But pulling the plug on the whole project wasn’t something I could influence. Sometimes you gotta roll with the shitty cards you’re dealt, go for a small win, and cling on to that in an attempt to find solace.
