Doing the Wrong Thing the Right Way

You wouldn’t read a book from the end to the beginning, watch a film backwards, or get paid by a restaurant to eat there (at least, generally speaking…); yet these simple facts alone are not enough to stop us, as Product Teams, from being regularly tossed un-validated feature demands over the fence by those who know far more about product development than the digital teams they’re paying large sums of money to deliver to.

Often, as teams, we have the head-space and capacity to push back, challenge, or provide evidence based alternatives. And sometimes, we’re even listened to. This is the happy path. The idyllic world of product management, where our evidence led, outcome based road-maps, grow beautiful opportunity trees that we can test ideas around, unfettered from the harmful effects of opinionated, wild, hippos.

But sometimes there isn’t enough pesticides in the world to protect our garden of opportunities. An invasive species has appeared, and it has root rot. In this dystopic world, a place where Caganism is oppressed and assumptions reign supreme, a team is being forced to deliver on a proposition so wildly devoid of value, that taking refuge in the Metaverse even feels like a step forward in terms and quality of life, and return on investment.

It’s happened to us all at some point, and depending on the type of organisation you work at, it’ll happen to some far more frequently than others. It may be a dystopic vision, but it is far more frequent than we care to admit as a community, and is the reality still in a vast number of organisations. Building a thing that you don’t believe will work makes getting out of bed [significantly] more difficult than it already can be, and as product people, it’s not what motivates us at all.

But when the idea is in mind, promises have been made to the Board (against your better judgement), and the new product or service is the passion project of a fanatical Decision Maker, what can we do as Product Teams to mitigate the risk?

Well, all might not be entirely lost. Depending on your circumstances, there are a number of things you can at least attempt to do - and as my Nan always used to say; “Put can’t in your pocket, and pull out try”.

Document the Risk

I’ve put this first, because with it, the below can tend to follow much easier. It might seem pretty obvious, but it’s one of the most effective ways to handle these kinds of situations. It won’t stop a train that’s already left the station, but it does at least formalise the teams’ view that it isn’t the correct approach, by placing the risk of the spend and investment squarely on the shoulders of the person[s] driving the idea forward.

Don’t forget, it’s important to evidence why you don’t think an idea will have the desired impact, and why it’s considered risky; whether that be misalignment to strategy, lack of evidence that it will address a known user or business need, or another factor.

You need to do this as early as possible, in writing, and to the right people. And if the idea does go ahead, you’ve potentially saved yourself a lot of awkward questioning in the future, and made that the problem of others own making. It does then at least create a barrier that forces solution drivers to acknowledge that they are not taking the professional advice of their digital teams, yet proceeding anyway; and makes them accountable for those decisions. Note though — this does not make a difference if the Unvalidated Solution Requirement Fiend is the owner, and really does depend on your organisational context…

Provide Alternatives

Although the decision has already been made, in the absence of recommended alternatives, all your team is doing is appearing belligerent. We’re paid to both reduce risk and create value. So look at your big bets, the opportunities identified, the metrics to be moved, and propose an alternative reality. Not only is there the sunken cost of a risky idea, but the opportunity cost of not investing in better ones. Hopefully you have some idea of the potential impact and scale of some of the ideas you wish to pursue, and these are incredibly important to socialise.

Providing alternatives (and the reasons for believing in them) helps enforce the [entirely true] narrative that the team is doing a lot of thinking and work around the problem space, and that jumping directly into the solution space misses out a whole load of incredibly important work. You might be ignored this time around, but when the passion project turns out to not be one of the million ideas that succeed by pure luck first time around, and here’s the key, this is where we want people to be looking for the next idea.

Experiment Quickly

You might not be able to influence the value proposition greatly, but you still have time to learn something about the design and execution of it. How quickly can you get designs in front of users? What evidence, data, analytics, or customer data do you have readily available to help inform the design? It’s important to think about how to message some of that feedback to stakeholders, but it can be used to course correct as much as possible. It’s unlikely that this new evidence will sway any heads enormously, but it should at least mean that we can provide some evidence to say ‘this implementation, logic, approach, or design works best for this idea because of X, Y and Z’; whilst hopefully also encouraging and demonstrating the value of rapid experimentation to explore solution ideas.

So we should always ask, what design assumptions do we have that we can easily look to interrogate, most likely as we’re starting to build, to make this bad idea land in the least ineffective way possible.

Severely Limit Scope

For the people demanding these features, ‘MVP’ almost certainly means the ‘first thing we’ll release’, rather than anything more conceptual about assumption testing, achieving an outcome, or things we might need to learn. It’s one of those terms that non-technical stakeholders like to throw about to feel and appear engaged with technology (and I fully endorse these attempts to understand and use our language!). But let’s use that fact, and hopefully the passing off and documenting of risk, to our advantage. The smaller the thing we build, the less we think we’ll have wasted. ‘Ok, we’ll do this, but we’re going to do 30% of what you asked, release, ‘measure and learn’, and then carrying on building it’. Hopefully here we have the opportunity to shelve the remaining 70%, when the next shiny thing comes along, priorities shift, or the person driving the solution gets the promotion that they thought the solution would bring them earlier than expected…

But if we end up building the rest, hopefully we’re starting to gather evidence and insight into how it’s performing, and enough to suggest changing tact somewhat for the remaining scope.

Then, all we have to do is manage the ever increasing tech debt that we never even wanted in the first place. Simple!