Someone's team at work recently launched a feature. The feature itself is quite straightforward, and solves a small design problem for the team it originated from. Unfortunately, it also mandates significant changes in how every other team in the company interacts with the core interface of our internal infrastructure, degrading the (internal) user experience to such a degree that I expect this small feature to cost us multiple man-days of productivity before the end of the year.
Having studied research economics, I am familiar with the law of unintended consequences, which is something most people in product management instinctively internalize to varying degrees of understanding, but doesn't get talked about nearly enough for the ones who don't.
The law of unintended consequences for a product driven organization states that every idea that is shipped to production will have a permanent negative effect on at least one other idea that was or is currently being shipped to production.
The law of unintended consequences is, generally speaking, good news: it means whatever place you're working at is innovating or pivoting fast enough that a lot of employees feel empowered and have the necessary tools to deliver new products and push the business forward.
Unfortunately, whenever the law is invoked, it also means that not many employees fully understand the big picture with sufficient detail to pull the brakes when needed. When this happens too many times, every step forward means two steps back are taken trying to fix everything that unintendedly broke, and the product roadmap grinds to a halt.
Breaking the law of unintended consequences - that is, shipping brilliant products without breaking someone else's stuff - is one of the most important things a product manager should focus on.
I personally try to use three very simple guiding principles to reduce unintended consequences at work. They are simple and easy to practice, but also quite comprehensive, and more than enough to reduce the level of negative consequences some of the worst offenders I've met in my career brought with them. In teams that practice these simple rules, we ship fast and usually don't break anyone else's stuff. Without further ado:
Own what you break. This is not the first principle in terms of logical progression, but it is the very first rule that needs to be aggressively enforced. In software development, if your change is preventing the code to merge to production, it's up to you to work on your code and its surrounding context until all tests are green.
But in product management, shipping the feature is more often than not the culmination of your relevant milestones - and there is no automated tests telling you that the finished product's interaction are problematic for the company.
In ill-functioning companies, this becomes a moral hazard as teams celebrate their quick and dirty product launches while shifting their own technical debt onto other teams in the form of unintended consequences.
That's why it is important for product teams who launch fast to not just own their own launches, but also everything else that unintendedly breaks after their release. This works as such a brilliant nuclear deterrent that fixes become rarely needed; it fosters ownership, and helps the company scale by ensuring people think their products thoroughly instead of taking shortcuts.
Which leads us to the second principle: test early, roll-back quickly. Big products might warrant big releases, but that doesn't mean you shouldn't have sufficient time to test them beforehand and the ability to roll back to an 'unlaunched' or 'beta' state where needed.
Testing should start early and ramp up in scale, from the first MVP up to final release, and included as wide an audience as possible. Unless you're working on the next super-secret iPhone, you shouldn't be afraid to show your features to people outside your team anyways.
If you're working on digital products you might even have brilliant A/B testing tools at your disposal. But even the classic two-pillars of user testing (ramping up a certain feature or product on a selected percentage of traffic or to a selected group of users) can be more than enough to get some feedback.
And of course you should act on that feedback by aggressively rolling back (or going back to the drawing board) instead of ignoring your users and trying to bend their feedback into your product vision. The feature I described at the beginning of the post received overwhelming negative feedback from the beta users - yet still went through release.
Why does something like that happen? Because roll-back are costly, both in terms of time and money; they break havoc on roadmaps and lower team morale. That's why teams should have full agency to choose when and where to roll-back to, and a strong incentive to do so whenever needed.
The third principle is simple: let your peers know what you're doing - and ask them what they think of it. If you don't work at a secretive company or on a secretive product line, you probably have a Jira-like ticketing system, regular product demo days, one or more product planning meetings per year. And of course, if you get along with your colleagues you probably have plenty of informal get togethers - either in person or (during this wretched pandemic) over Zoom.
Well, tell them what you're doing. Ask for help. 'Hey, I'm working on this feature! What do you think of it?'. This is not part of your testing or product design or project management schedule. It's a mechanism to find those elusive people who pull the brakes when needed, and get them to point out red flags early enough into the product's lifecycle.
On top of that, it creates a positive environment for growth (especially effective in surfacing ambitious, young PM, with great intentions and the willingness and fresh ideas to innovate - but not enough knowledge of the big picture - to the 'old crowd') and generally speaking drives product cohesion across the company.
In the end, if teams ask each other what they think of your product before getting too attached, unintended consequences become less likely. If testing starts early enough, and roll-backs are allowed and even encouraged, unintended consequences become smaller. And if teams are forced to own what they break, whatever little unintended outcomes there are become part of the product themselves.
And that, in my experience, is how you defuse the law of unintended consequences in product management.
