The timeless art of slicing, part 1: slicing the problem

A practical guide to creating focus before you build

“8,5 years.”

I was startled. The first thought that came to mind: “…wait, what?”

“You’ve been building this solution for 8,5 years?” I retorted. My instinctive follow-up question was: “During these years, how many times did you meet customers to validate the solution?”

They paused for a moment, growing increasingly wary.

“3 times.”

Right there, I knew what had gone wrong. The company had been working on this solution, on and off, for 8,5 years. Multiple product teams cranking away at code, delivering user stories, doing internal demos, showing progress. And yet, the fundamental flaw remained: hardly ever exposing the concepts to actual customers. When it was time for launch, it failed.

Unfortunately, many companies I meet still operate this way. This is the modus operandi: a solution is defined by a stakeholder and handed over to teams to build. And what do the teams do? You guessed it. They build, and build, and build. The stakeholder is in the loop. And who’s not? The customer¹.

Years ago, Marty Cagan referred to this way of working as the “root cause of product failure.” I agree.

Teams march toward delivering what someone else defined, without questioning whether it’s valuable or not.

So, what’s the alternative?

The most successful product teams I’ve worked with are vigilant about their feedback loops. They constantly question whether their work is worthwhile. They interact with users, expose their ideas, prototypes, thinking, and solutions early and often. They learn. Discuss. Tweak. Debate. Refine.

And they slice.

The topic at hand. One, if not the most essential skill of a product team. The ability to pause, reflect, and slice.

Let’s jump in.

What’s slicing?

Who doesn’t love food analogies? The pomodoro technique, two pizza teams, spaghetti code. And, now, let’s talk about something equally mouthwatering.

Imagine a cake. It looks absolutely delicious with all the flavors you love. Unfortunately, because of the stomach pain that would ensue, you can’t eat the entire cake at once, sadly. You start with one slice. And naturally, you want that slice to be the most delectable part of the cake.

That’s the simple metaphor.

In product development, the equivalent may not be as delicious, but the thinking is the same. You have a big thing to build. Something that could take months or years. But what could be the tastiest slice of value you could bring to the market first to learn whether you are on the right track? Here’s the thinking: what if you created just enough to learn whether this is the right solution?

You create something small. You learn. You refine. You build some more.

That’s slicing.

The fundamental purpose of slicing is to speed up learning, learning whether you’re creating value, solving a real problem and tackling product risks.

And the beauty of it: everyone wins with slicing.

Nothing makes teams happier than putting code into production and seeing the fruits of their labor benefit real people. Stakeholders are happier because they see faster returns on their investment. Customers are happier because they receive value sooner.

It’s a habit. It’s a mantra.

Can we slice it?

The different ways you can slice

Here’s a big idea. Slicing isn’t just something you do to plan a big chunk of work. It’s multifaceted. In every mode of product development, from a newly hatched idea to production-ready code, you can always make things smaller and create focus.

You can slice the problem, the solution and the delivery.

Problem slicing

To kick-off this article series, let’s start with slicing the problem. In the upcoming article, we’ll dive deeper into solution and delivery slicing.

So, without much further ado, let’s unpack what problem slicing means.

Let’s bring to light two common scenarios:

• You’ve received a big thing to build from a stakeholder

• Your “problem to solve,” framed as an OKR or strategic bet, is too fuzzy and too broad in scope

So, imagine this.

You’re in a workshop, about to begin the work. The aim is to really sink your teeth into the challenge at hand. There’s excitement, but also an uncomfortable feeling: “Where do we start?” The blank slate. What should the first step be? The team is scratching their heads.

From here, there are two possible paths.

The easy path. You start planning delivery. User stories. Timelines. Plans. As a team, you focus on “getting it done.” This path is filled with question marks, pitfalls, risks, and assumptions, quietly pushed to the side. It feels easier because you don’t need to be challenged. You can plan the next few months, or even the whole year, with very little input from outside the team.

Then there’s the hard path. And it feels awkward. Instead of planning everything at once, you treat each piece of the puzzle as an experiment that needs validation. You adopt the mindset of a scientist. This path opens up questions and pushes you to reflect. It may sound harder, but it’s infinitely more rewarding, because you learn whether your time and energy are being spent on the right things.

Which path will you choose?

So, in that first meeting or workshop, resist the urge to plan what to get done. Instead, go deeper. To create focus, ask yourselves these powerful questions:

• For whom? Which user or customer segments are most promising to focus on?

• What problem? Which problems are most valuable to solve for those segments? What are their pain-points? Can we create more focus by decomposing the problem?

• What data? Which existing data sources will help users solve their problems? Which can you avoid?

• What business rules? Which rules are absolutely necessary? Which can you avoid to keep the scope lean?

• What dependencies? What dependencies exist? How can you set yourselves up for flow when it’s time to start building?

The purpose of these questions is to shape your thinking before doing any work related to the task at hand. You’ll be surprised by the discussions and the alignment it creates.

Example: video streaming service

To make this even more tangible, here’s an example from a fictional team at a video streaming service working with the fuzzy objective: “Improve content discovery and start watching faster.”

As you can see, through their conversations, they create focus by slicing each category and deliberately narrowing it down to a “tastiest slice” to start with.

Facilitation guide

Try this with your team.

First, gather the entire team. One hour should be enough. At the start of the workshop, explain the purpose: to slice the problem you’ve been asked to solve into something more actionable.

Step one

Ask everyone to write down possible answers to each question. Quantity over quality at this point. The outcome will be many possible answers for each question.

Step two

Next, select only a few post-its that are absolutely essential for the first slice of value you want to discover and deliver. This will spark a healthy debate. You’ve now created focus.

As a next step, validate that you’re solving the right problem for the chosen segment by doing user research or testing a rough prototype to stimulate reactions, ultimately leading to deeper insights into the user’s context.

In addition, create transparency by sharing what you’ve defined with stakeholders around you, and validate that they feel you’re on the right track.

Prompt library

Below are examples of useful prompts you can collaboratively use during or after a workshop. Use your GenAI tool of choice as a thinking partner to sharpen your understanding. The goal is not to get answers, but to improve the quality of your thinking.

Example prompt: user or customer segment

• “Here is our current definition of the target user or customer: [paste]. Make it more specific. What meaningful subsegments exist within this group?”

• “What behaviors distinguish high-value users from low-value users in this domain?”

Example prompt: problems to solve

• “Here are the top problems we believe this user is facing: [paste]. Rewrite them using clear, user-centric language rather than business or internal jargon.”

• “Which of these problems might be symptoms rather than root causes? What deeper needs could sit underneath?”

• “What important problems might we be overlooking for this user or customer segment?”

• “What problems could matter in situations or contexts we haven’t explicitly considered yet?”

Using these prompts will help create even more focus and open up your thinking, setting you on a trajectory of deeper learning.

Conclusion

Slicing is all about speed of learning. Don’t take that easy path. Take the more meaningful, hard path. Resist the urge to jump straight into planning and delivery. Instead, start by discussing, debating, brainstorming, and tweaking your understanding of the problem to solve.

Use this guide with your team to twist and turn the fundamentals of that “big thing to build.” Find that delicious first slice of value. Find that problem worth solving.

Let’s slice it?

1. I’ll use the term “user” throughout this article. By that, I mean the person actually using the solution. In some cases, the user and the customer, the person paying, are the same. In others, they’re not. The distinction matters, but for the sake of clarity, I’ll default to “user” moving forward.