What milkshakes and your product hierarchy have in common

productboard’s product hierarchy allows you to easily capture and organize all your ideas from large to small.

As a Customer Success Manager, I’m often asked: What is the best way to structure the product hierarchy in productboard? While the right answer often depends on each team’s unique product development process, I want to share a fundamental framework that is universally applicable for any team. In future posts, I’ll explore alternative possibilities based on individual needs.

To get in the right mindset to tackle this, let’s start with the methodology we use at productboard and review some principles of agile development.

An epic milkshake

First, let’s talk about how Clay Christensen helped McDonald’s market their milkshakes and grow sales considerably. Sure, it’s a marketing story, but there are strong implications for product managers here as well.

In this video, Christensen talks about the “job” that McDonald’s customers were “hiring” a milkshake to do. By observing customer traffic and conducting unbiased interviews, Christensen and his team determined that a consumer’s milkshake purchase had nothing to do with taste or brand. Rather, customers were looking for a convenient snack to pass the time during their boring morning commute. Understanding this “job” is exactly what helped McDonald’s find the right solution to more effectively drive sales. It’s also the same methodology that we at productboard believe helps product managers make better choices on what to build.

Agile development

Christensen’s milkshake example happens to fit in perfectly with the agile development model. Before we dive into the “how”, let’s quickly review Themes, Epics, and Stories as outlined by Roman Pichler in his book Agile Product Management with Scrum.

• Themes act as placeholders for high-level product functionality that span the organization.
• Epics are large bodies of work or a single shippable functionality that can be broken down into a number of smaller tasks, also called stories.
• Stories, or “user stories,” are end goals or desired outcomes (not features) written from the perspective of an end user.

Your product hierarchy

When thinking about your product hierarchy, start by thinking back to Christensen’s story and ask yourself about the job your current or ideal customers are hiring your product to do. This will be your starting point.

Component

At the top of your product hierarchy is the component. Think of the component like a theme in agile. Components, like themes, are broadly defined and have no real end date or limitations in scope. They generally describe ongoing work, and you can add new ideas to them at any time.

Components don’t offer solutions, but are rather those “jobs” that Christensen talked about. These larger jobs allow you to keep track of or even compare various potential solutions. You can nestle as many layers of components as you need, with each layer leading towards a more specific part of the job you might solve.

In the milkshake example, the component is the “snack for a boring commute.”

Feature

Features are nested below components. Like epics in the agile framework, features are specific shippable solutions that address components in a well-defined timeline. Product managers should aim to prioritize features within productboard. The feature is a solution we (or your end users) would “hire for the job.”

In Christensen’s story, it is the milkshake. Of course, you can have multiple features, and other features from his story could be bagels, bananas, or anything else that would satisfy the job of a snack during a boring commute.

As a side note, one challenge we find (particularly with those teams using Jira) is that product and engineering teams treat epics as open-ended or spanning longer than four sprints — almost like a theme. This isn’t an ideal use for epics, and it certainly isn’t a good way to treat features. We know that this is already an entrenched mindset, and one solution we suggest is to use the correct application of epics in Jira when starting new projects. This can help lay the foundation for a new approach without completely disrupting the organization as you adopt new habits.

Subfeatures

Subfeatures come below features. Think of subfeatures like a story in agile. Subfeatures, like stories, are focused on specific behaviors, motions, or outcomes that come together to create a full feature. They’re often written in the form of requirements based on the details outlined by PMs at the epic level.

Product managers and developers collaborate together to prioritize these subfeatures. The product manager “prioritizes” the stories by clearly specifying the scope and goal of the larger epic. Developers will reference this scope in order to prioritize which stories they work on first or even break into smaller pieces.

Christensen’s story doesn’t explicitly call out anything that could be considered a subfeature, but you can think of them as the motions a customer goes through to order or consume their milkshake. This may be the drive through window experience or drinking through a thick straw.

 

Think about your job

Let’s see if you can find a way to structure your hierarchy so it lines up with agile. It should address the “job” are you trying to get done, the solution(s) you’d “hire” for the job, and what motions your end user would go through while working with that solution.

We’ll be following up soon to discuss more nuanced scenarios, but hopefully this piece provides a simple framework to help you get started. Stay tuned!

. . .

productboard is a product management system that enables teams to get the right products to market faster. Built on top of the Product Excellence framework, productboard serves as the dedicated system of record for product managers and aligns everyone on the right features to build next. Access a free trial of productboard today.