Slicing and dicing the curate's egg

High on my list of things that product developers don’t talk about enough is feature slicing.

Contrary to our usual beliefs, some agile methods take practice to get right. Dividing functionality into meaningful slices is one of those for me.

The motivation is straightforward: in order to get valid and valuable feedback on real product development as early as possible, build a thin slice of production functionality that cuts across the full stack, and do all the work needed to release it.

The opposite of this is to spend months specifying the whole system and then build it tier by tier, database first.

In other words, build an MVP. Get feedback. Iterate. Etc, etc.

You may have seen this diagram used to illustrate the idea:

I have no idea how to credit this image, because it’s been duplicated in so many places.

Let me be blunt. I don’t like this diagram. Or at least, I dislike when it’s presented without further explanation. It’s just not useful. It doesn’t have an x-axis label. There are other layers we also need. It doesn’t help us decide how to slice or work. It’s simplistic.

For example, we can’t really guess how to make our thin slice valuable up front, let alone usable or delightful. For that we have to get lots of feedback from users and iterate, right?

As well as slicing vertically (the scope of what you are building now), we’re going to have to slice horizontally. Otherwise we’re still just guessing most of the time.

Start by asking how your tiny sliver of functionality can be made feasible. In other words, what’s the cheapest, quickest way of getting it in front of users for the purposes of research? A spreadsheet? A piece of paper? A phone call?

How do you make it valuable? Automate it so that it’s not done on a piece of paper in person any longer? Will they buy it like that? Do you continue working on it?

As you go, you’ll be getting insights into how to make it usable and delightful, but those characteristics may not be as important for the current slice.

You might decide to move on. Sometimes just barely usable is good enough. Sometimes you need to keep plugging away because delightful details matter.

But the key point is for everyone on the team to understand what they’re trying to achieve at each point. This makes it much easier to limit scope in short sprints, and focus on the goal at hand.

Our default seems to be to work towards a constant fidelity, to assume that our work is of a consistent quality throughout a product. This can lead us to spend far too much time on low-value features. Once we discover where the value is, we should be directing most of our efforts there. Pareto applies everywhere, after all.

That’s why many successful products out there can be somewhat of a curate’s egg. They are delightful in small doses where they need to be, but also have lots of dark, ugly, unloved corners.

All the best,

– Jim