Two people drawing on a whiteboard
Photo by Christina Morillo from Pexels

Product Sprawl

iamemera

--

Recently, I’ve become a bit of a product mercenary.

Product sprawl is the enemy in my sights. Not just a case of product debt accumulation, product sprawl is the phenomena that encompasses ideas that were right for the time, but now languish. Be it a redirected team focus; a lack of clear ownership in a product organization, with perhaps a handful of vocal customers still using the service or solution; or a combination of all of those, product sprawl slows you down, distracts you from delivering value, and keeps you up at night with thoughts like: if only there were more hours/engineers/users.

There are a plethora of ways to combat product sprawl, but the steps below are tried and true methods to remedy flare ups and prevent future occurrences.

Become a bit of a mercenary

When we think of ‘product mercenaries’ it’s not an ideal that product managers aim for:

“Teams of mercenaries feel no real sense of empowerment or accountability, no passion for the problem to be solved, and little real connection with the actual users and customers.” (https://svpg.com/missionaries-vs-mercenaries/)

But when it comes to reigning in product sprawl, the description lends some useful guidance. You’re going to kill some products, some of which you may have built or come to really appreciate; however, you need to leave your connection to — and even passion for — the problem they solved out of your processes.

Keep in mind, becoming a mercenary is an analogy for retiring products that are no longer useful, differentiated, or desirable. If you’re working on a team of ”missionaries” then retiring a product or feature at the right time should be a clear part of your strategy; however, we’re human and we get attached to the things we’ve built and launched. Adopting the mindset of a mercenary can be a psychologically safe way to approach the task.

Kill List Criteria

Now that you have your mindset in place, establish product or feature kill list criteria. Whether a team or organization activity, it should be clear & communicated to your immediate team and stakeholders.

Start with a prompt like: “In order to retire this product or feature, we need to:” and consider the following:

  • What usage level (e.g. % of active clients, DAUs/MAUs) is an unacceptable justification of resources?
  • What P&L metric (e.g. gross or net revenue, % of contribution to shared tech & hosting costs) is unacceptable?
  • What industry changes would render this product obsolete?
  • What market changes would dictate you focus your energy elsewhere?

Select a few of these and track them at a cadence — daily, weekly, quarterly — that makes sense for your business. If you’ve found yourself in a mess of product sprawl, use your kill list criteria and the metrics you’ve collected to draft your recommendation to retire the product.

Your kill list criteria likely reflects your product line KPIs and the inverse of your goals for the product. While setting goals is part of product development DNA, it can be tempting to focus only on moving those metrics up and to the right. Taking a moment to reflect on a worse case scenario identifies road signs to watch for to avoid product sprawl.

Two types of decisions

Once you’ve donned your mercenary hat, established your kill list criteria, and have found a product or feature to retire, it’s a good time to pause and think about the two types of decisions. Ask yourself: if we retire this product or feature, is this decision reversible? If it is, go forth, knowing that you’ve put in the due diligence to confirm this, and execute. If it isn’t a reversible decision, treat it as such; seek input from your stakeholders, C-level and board members, and lighthouse clients, before proceeding.

Product sprawl happens in every organization, to technology teams of all sizes. With the steps above in mind, you’ll be empowered to combat product sprawl and introduce preventative measures to avoid it in the future. Combatting product sprawl is never going to be your primary objective as a product manager, but knowing when to recognize it and deal with it will help you and your team go further, faster, together.

--

--

iamemera

Product evangelist. Tactical dreamer. Former office golfing champ. Love the pace, ambiguity, and opportunity of a nascent business model and mission.