Monday, 8 November 2021

A Simple Rule for Product Decision Making

A good alternative job title for most product roles would be 'professional decision maker'. Whether deciding priorities, experiments or potential features, pretty much every action a product manager takes is to decide between conflicting options. I saw a great talk by Geoff Watts a few years ago on decisions being the essence of Product Management - Geoff explained that, while decisions may work out well or badly, at least by making a decision you progress and learn. Inaction through fear of making the wrong decision, on the other hand, will inevitably lead to eventual failure, by which time it may be too late to recover.

The hardest decisions for many product people revolve around whether to take the quicker route to short term value or tackle larger scale improvements associated with longer term strategy. I'd never suggest there's an infallible rule here, but there is a guiding principle that I try to adopt which has served me well both in product decision making, and also my own personal career choices.

Don't pass up an opportunity to progress to where you want to be long term

That's it. If there's an opportunity to step closer to where your strategy is pointing you should try to take it, even if there's a quick and dirty option available.

It sounds obvious but it isn’t

Simple as it may sound, it's sometimes hard for product people to take the steps they know are needed to improve

  • Making decisions that appear to delay features can be difficult to justify with stakeholders who have more focus on short term financial performance when easier paths to value are available
  • A false sense of urgency is the biggest risk I’ve seen play out more than once. This occurs when a team is pushed to implement a capability using the shortest route possible - usually leveraging technology that wasn’t designed for the purpose.
  • Not knowing where you’re heading is another genuine risk. If the product and development teams don’t have an understanding of the longer term company vision and objectives then it is hard to know whether their decisions are moving them in the right direction or not.

These triggers can lead to short-termism on an individual decision basis, however it's collectively where the impact is most apparent.

Multiple small decisions have a major impact

Knowing why this simple rule is so fundamental requires an understanding of the power of iteration. Although each small decision may appear to have isolated impact, the combination of months or years of 'tactical' decisions can be crippling

  • A previous employer had a desire to move into the web, however due to a strong push from sales they took the quick route of prototyping and building their new scheduling interface in the existing rich desktop instead. This missed a huge opportunity to establish a more modern web platform which would have set the precedent for the migration to web that they needed for long term growth, instead the decision committed them to significant further investment into a desktop application which they wanted to move away from.
  • In another business I once encountered the legacy business rules engine had been incrementally added to to the point that it was not designed for the range of purposes it now met. Rather than using the creation of new products as an opprtunity to build out a well architected replacement, they kept creating new features leveraging on the old one. The resulting maintenance needs then slowed them down and added more pressure which made it even harder to move away as time went on.
  • A database company I worked for created a script based prototype to manage multi-server synchronisation. Rather than use this as a starting point to refractor and create a robust product, the quicker path was taken to progress into full production with a resulting mass of maintenance and testing challenges that slowed innovation elsewhere and committed more development and testing effort to maintaining a script based solution.

Each of these decisions probably seemed sensible in the context of the individual event. It is the combination of repeat decisions of this nature that can leave a company two or three years down the line with a mass of unmaintainable code and a sinking feeling when looking at how they have progressed against their longer term plans.

The first step in the right direction is the hardest

The good news is that the same principle works in the opposite direction too. Each step in the right direction builds on the last and accelerates progress towards a long term goal.

A former team of mine were delivering a capability to track customer segments from a marketing database. The shortest route would have been to use existing segment definitions from the legacy document store for their selection criteria, however they knew that long term we wanted a full segmentation tool in the web. Creating a very simple definition API capability to serve the web allowed the team to deliver a basic feature, and at the same time break one of the biggest technical barriers in our larger web migration.

The key here is that in itself this was a limited piece, but paved the way for further steps. There was an overhead in some extra effort over the easier option, but the reward for this was that the next feature that needed segment capability in the web had a great start to build on. It would have been hard to justify anything other than progressing the capability when addressing future needs. If instead we’d taken the easy route we’d still have been at the 'foot of the mountain' with the temptation to again take the easy path the next time a need arose.

Not every step is forwards, just don't go backwards

I’m a pragmatist and I know that not every decision provides the opportunity to progress longer term strategy. Even indirect steps can help as long as they don’t take you backwards. Work such as having to fix up legacy code, add a feature to stay competitive or address burning customer needs will always need prioritisation.

The problem is when the temptation then comes up to build a brand new feature on that legacy code, or push that prototype into production, as it’s quicker than biting off the architectural or product changes you know are needed. Taking the easy option here isn't just missing a change to move forward, it's adding to your problems and making it harder to progress in future. If you're facing such a decision I recommend that you ask yourself whether you're missing an opportunity to move in the right direction - and be honest about the answer. Your future self will thank you for it.

Photo by Vladislav Babienko on Unsplash

Whatsapp Button works on Mobile Device only

Start typing and press Enter to search