n rebuilding a product

A couple weeks ago, I sent out an overview of key points product teams should consider when making prioritization decisions. In that overview I promised to explore different scenarios in more depth. So here’s the first scenario - replacing an existing product.

Product replacements are a common activity these days, especially for organizations undergoing a digital transformation.

I’ve had the…opportunity?… to lead at least three product replacement efforts so I’m painfully familiar with helpful, and not so helpful, ways to prioritize what to include and what not to include in the new version of the product

In it’s simplest form you decide what features your product will and will not have. Then for each feature that you decide to include, you dive into details how you’ll deliver that feature.

Yes, I know that’s extremely vague. Don’t worry I’ll get more specific, but first I’d like to level set on some terms commonly used and misused to describe product backlogs.

Words are hard. Here’s what I mean when I say them

First, when I say feature, I mean it in this sense:

I’m explicitly not using feature to refer to a type of backlog item.

Instead I’m going to surrender to the naming convention used by a commonly used (and periodically despised) work tracking tool - Jira.

For the rest of this article, and the subsequent articles in this series, I’m going to use the term epic to represent backlog items with big scope (that often represent the whole effort necessary to implement a feature) and story to represent the smaller backlog items that epics get split into in order to make work manageable.

Epics are at the level that stakeholders, customers, and users care about.

Stories are at the level that the team cares about when trying to build things with a short feedback cycle.

You want to do your first round of prioritization at the epic level, and only split into stories when you’re sure you want to deliver the epic.

Check out Themes vs Epics vs Features vs User Stories for a deeper discussion.

Identify what’s in and out of the rebuilt product

On the surface, identifying what to include in the product should be easy, right?

First of all you don’t have to worry if there’s interest in your product. If there wasn’t surely you wouldn’t expend effort to rebuild it, you should instead turn it off.

Second, you can look to the existing product to determine what to include in the rebuilt product. But there’s more nuance than you might think, and it depends on if the product is customer facing or used internally.

Rebuilding a customer facing product

If your product has been around long enough that the best course of action is to rebuild it, you have an existing group of customers. Chances are those customers span across the product adoption curve. Not just early adopters, but also laggards.

Those laggards may represent a sizable chunk of your user base and may have driven some fairly involved ‘special requests.’

You’ll need to do some extensive discovery to find out the ways your customers use the existing product that you may not be aware of. Prepare yourself to figure out how to support all of those different use cases at some point.

As you’re doing this discovery also look for existing features that your customers don’t use. We all know they’re out there.

You’ll want to design your product to handle those situations, although you may not need to build out the capabilities right away before releasing the new product to a segment of your users.

You can still build an initial version that meets the needs of a subset of your users so that you can get some value out of your work while you continue to flesh out the entire set of capabilities. Think of this as design for breadth, build iteratively.

Your prioritization decision entails deciding what all your product eventually needs to have in it in order to support the customers you want to support. Then, pick the first customer segment you want to support first with the rebuilt product and identify the epics that you need to support that segment. That’s the content of your first version of the rebuilt product.

You may chose an existing customer segment whose retention is threatened by the flaws in your current product. Or, you may choose a customer segment that represents a great opportunity for growth. When you make the decision, include business factors, don’t just pick the customer segment that requires the smallest set of features.

Once you know that, you can start identifying the epics to put in your backlog to realize those features.

Rebuilding an internal facing product

If you’re rebuilding an internal product your mission, should you choose to accept it, is to remove all the cruft that has built up over the years the product has been in existence.

There’s features that made sense at one point that no one uses. There are connections to systems that don’t exist anymore. There’s the workarounds that exist because of unfortunate design decisions 20 years ago.

Prioritization in this case means getting real clear on the intended outcome of the process your product supports. Focus on the outcome itself rather than the nitty gritty details of the process, because those may change (hopefully become simpler) with the rebuilt product.

Then, streamline the process to include the necessary and sufficient steps to achieve that outcome and identify the features your product needs to have.

Once you know that, you can start identifying the epics to put in your backlog to realize those features.

Dive into detail

You can follow the same approach for doing a deep dive when rebuilding customer facing products or internal ones.

Once you’ve identified the epics you want to deliver first, it’s time to slice the epics into stories and sequence those stories. You can use story mapping to guide your slicing and sequencing conversation.

Map the big picture. Lay out the story map using epics as the high- level items across the top of the map. If there are any obvious stories that can be identified for those epic, place them under the appropriate epic at this point.

Explore. Select the epic(s) you believe you will be delivering first and do a deep dive on them via conversation with the interested stakeholders. Sketch models to aid the conversation (you may find those sketches helpful later on when you start delivering those particular stories). As you have those discussions you may find that you will refine your map.

Slice out a release strategy. Look at the stories identified for the features and determine the minimum stories needed to deliver the desired goal. The idea is to identify the minimum output to deliver the maximum outcome. Organize these user stories into a set of releases by moving them vertically.

Identify the items to start with. Once you have identified a set of releases, you may find it helpful to identify the stories you want to start with, as experiments where you are either trying to validate key assumptions or reduce risk. You can use the risk management game to identify those stories.

If you remember nothing else

When you rebuild a product, base your prioritization decisions on what people want to accomplish with the product. Consider what features the current product us, but don’t hesitate to throw those out if they are no longer useful.

To ensure you focus on the right things, prioritize on a broad scope first (again based on what people should be able to accomplish with the product) and only dive deep into those epics you know you need to deliver.

Make sequence decisions based on risks and assumptions.

Thanks for Reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, just reply to this email.

Talk to you next week,

Kent J. McDonald
Founder | KBP.Media