Practical advice about backlog items and outcomes

Ideally, you’d express all items on your roadmap and in your backlog as outcomes. In reality, it’s a bit more complicated than that.

Last week I shared some tips for maintaining a manageable backlog, I made the following comment about describing “big” backlog items

And ideally, you’d describe those items as problems to solve. Depending on your context, that may be easier said than done, which is a typic that deserves it’s own article (coming soon).

As promised, here’s more on that topic.

When you work on an internal product you’re usually asked to deliver a solution rather than the empowered team nirvana of given a problem to solve.

In some cases, it makes sense to use that solution to deliver as a starting point to walk back and discover the problem that you need to solve.

In other situations, the change requested and the need for it are clear enough that in service of the broader business goals, it’s more productive to make the change and get on with your life.

And you probably know what’s coming next. The decision whether to dig into the underlying problem is based on context.

Specifically, the nature of your internal product and where it’s at in the product lifecycle are big factors on how you describe items on your roadmap and backlog, even whether they need to show up on the roadmap at all.

I toyed with going down the rabbit holes of describing the different types of internal products that are out there, and adopting the product lifecycle for internal products. But it felt a little forced, and I wasn’t sure how helpful that digression would be. Please let me know if you would find it helpful.

Instead, I thought I’d give a few examples of products I’ve worked on and how I described the associated items. Hopefully these examples prove helpful. If you have a particular example you’d like to discuss, by all means, let me know.

Agile Alliance Search

A few years ago, I was the product person for all of Agile Alliance’s digital products - their website, submission system, membership, and conference registration.

One of the first efforts I worked on in this capacity was the redesign of the Agile Alliance website. The site provide access to the rich treasure trove of resources the non profit had such as conference videos and presentations, experience reports, and other articles.

After we got the new site up and running, we realized that the search functionality of the site (at that time out of the box WordPress search) was… less than optimal. So in 2017 we decided to tackle improving the search functionality. I described the approach we took in an article I wrote about feature refinement.

I used a roadmap to track the main efforts we had for digital products at Agile Alliance and this effort was significant enough to warrant an item on that roadmap. In this case the significance measurement was would the Agile Alliance Board want to know the effort was going on.

I probably labeled the item Website Search Redesign. If I were doing it now, I’d probably label it How might we make it easier for subscribers and members to find content on the agile alliance website?

Then, as we dove into discussions about how to make search better, the backlog items that came as a result of product team discussions represented different aspects of the solution that we wanted to implement. Such as:

• Filter results by type

• Filter results by topic

• Filter by event

• Filter by initiative

• Admin can select Taxonomies and their values to allow users to filter by

In this case, the roadmap item was closely related to a problem to solve, and the backlog items were specific outputs we wanted to deliver in a particular sequence to solve that problem.

Pricing System Rebuild

A couple of years after that search redesign, I had the opportunity to work with a team to rebuild a 20 year old pricing system originally built in Power Builder. In this case the entire product team (including) me were consultants that needed to get up to speed with the product we were replacing, the business process it enabled, and the company we were working with.

I described the approach we used to get up to speed in an article about discovery sessions. Of particular relevance for this topic, we had to determine what functionality we’d include in the new product overall, and what we had to have in place for the go live point, which happened to be April 1, 2020. (Lots going on there).

To get an initial view of Scope, we used a story map to organize what we would include and exclude and a first plan for order of delivery. We started with four high level processes that represented the main things the product needed to do:

• Set Price

• Manage Discard

• Manage Master Data

• Reporting

And then we split down each of these processes into smaller chunks that represented the main steps or main activities. At the time, we referred to those as “features” to fit into the company’s naming conventions.

For example, some feature names under Manage Discard included:

• Manage Fixed Discard Contracts

• Manage Hybrid Discard Contracts

• Manage Discard Deliveries

We originally started with a Now-Next-Later roadmap, to track these features. However the IT department at the company insisted that we have dates, so we switched to tracking things on a release plan. (Which is what I call a roadmap with dates on it).

More often than not, when it was time to work on one of those features, it’d get broken into smaller items on the backlog, such as:

• Edit Fixed Discard Contract

• Delete Fixed Discard Contract

• Validate Fixed Discard Contract

In this case, we were primarily focused on getting the product up and running. As we got the initial version out, we continued to add new capabilities and tweak/fix existing functionality.

In order to decide what items we did and did not do, we were primarily driven by what capabilities we needed to appropriate support the process. We weren’t in an optimization mode like you read about in most product management articles.

That said, we did have some unstated outcomes, top among them reducing pricing errors, that drove how we built the capabilities we provided.

Sites Selling Add on Services

These days I work in an agency setting where the main client has a set of websites that sell value added services for vehicles online. These websites are client facing and have some fairly involved pricing rules so they are in some sense a hybrid between commercial software and internal products.

The other relevant fact with these sites is the client is effectively doing the product management in trying different tweaks to the sites and the pricing inputs in order to grow sales. This is a very common occurrence for product teams working on internal products. The product you work on is often enabling a process that delivers the desired outcome. And if that process is important enough, there will be an owner for that process who is probably not directly working with the product team on a full time basis.

So the items the product team works on takes on a few different flavors. There are direct changes we need to make to tweak prices, there’s adding new functionality such as providing pay over time options, and then there’s feedback we get from customers using the site via the client.

The pricing tweaks are an example of taking the request at face value and making the change, such as changing a fee by a certain dollar amount.

Adding new capabilities often looks like the examples from above with an “Integrate with pay over time vendor” on the roadmap and items on the backlog split that interaction into steps, each of which the team can develop in isolation and test, but all are required to provide a working solution.

Acting on feedback is where there’s some opportunity to attack it from a problem to solve perspective. One example is our check out page where we collect credit card information had some cards showing a summary of the purchase information followed by the credit card form.

Our client had noticed a significant drop off of transactions on this page and noted that the credit card form often was “below the fold” meaning on first glance, people may not notice without scrolling where to enter credit card information.

In response to that feedback, we had a backlog item that was labeled How might we make the credit card form more apparent on the checkout page. The goal with wording it that way was to leave room for the product team to come up with design ideas to do that.

Outcomes are important, and aren’t always directly related

You should always understand what your product is trying to accomplish. In that way, outcomes direct what you do and do not do.

However when you work on internal products, keep in mind that your internal product may not directly relate to that outcome. They may enable a process that ultimately delivers the desired outcome.

So instead of tying yourself into knots trying to phrase things “the right way” consider your context and what is most effective for your product team. Sometimes that is stating things as a problem to solve. Sometimes that’s stating something as a portion of a solution.

The way you approach organizing your work is going to be different if you’re building a new product to support a new process, rebuilding a legacy internal product, adding features to a product, or optimizing an internal product that’s been around for a while.

The key is making sure your product team knows what you’re ultimately trying to accomplish, the constraints that you’re working under and yet has latitude to come up with an effective solution.

Every situation is different, yet similar

Hopefully these ideas give you some ideas on how to handle roadmaps and backlogs in different situations. But if you find you’re still a little perplexed about how to tackle a particular product, I’d be happy to help.

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, let me know.

Talk to you next time,

Kent