This One Thing Will Help You Stop Building Excess Product Features

Apply it today in 8 simple steps.

80% of features go unused. $29.5 billion wasted. Why do we keep building what users don’t need? Imagine if we used that effort and money to solve real problems.

Feature bloat. It’s a rampant problem and has been for a long time.

Study after study depicts how poor we are at delivering features users need. The stats above are from Pendo.io. ^1 I came across their report last week on the product results of 615 publicly traded cloud software companies in 2019. This was when they discovered that 80% of features deployed were rarely or never used. A low adoption rate like this came at a staggering cost of $29.5 billion flushed down the drain. To put that dollar amount in perspective, it’s equal to the GDP of Iceland. 

Yikes. These depressing numbers might surprise you, but they don’t phase me. While this data is from 2019, it remains just as relevant today. I don’t need a study to tell me this. I live it every day.

And after a few decades in the software industry, I haven’t seen our collective track record improve. If anything, it has become worse. Even though many will admit we have this problem, I find most don’t course correct. It’s as if we have accepted this as the fate of all product professionals. It’s so ingrained that most don’t even realize anymore that they apply their focus to the wrong thing.

But we don’t have to accept runaway feature bloat as our burden to bear.

I’d like to tell you there’s a secret sauce for reversing our pattern of delivering what users don’t need. But I wouldn’t call the solution to feature bloat a secret. It’s actually well-known. Yet, it’s not well-practiced.

Let me explain the problem and the not-so-mysterious solution.

The Problem: We Can’t Help But Tinker With the Imperfect, Even If It’s Not Relevant.

Humans are suckers for solving problems.

I’ve seen firsthand how this causes features to proliferate out of control. We have an innate drive to tackle any challenge before us, almost a compulsion. I mean, take my writing as an example. When I write, I dig to see what others have said about the topic. That opens another avenue. And another. Before long, I’ve written 5000 words when 1000 would have answered the question for the reader.

In many ways, this is what makes us human and is our strength. But it can also be a vulnerability. We fall into the trap of chasing down every problem we see with equal vigor.

I find this more true in software product development than in most endeavors.

In product work, we are prone to getting lost in the weeds. In turn, we lose the plot of the product story we are trying to tell. We end up perfecting the unimportant. We overbuild the things that don’t matter and neglect the things that do. Before long, we exhaust our energy, time, and money on a beautiful but useless masterpiece.

Let’s take a common product scenario I see playing out:

1. We have a 5-step flow we are aiming to automate.
2. Logically, we start with step 1.
3. At first, we outline a simple version of step 1.
4. But then, we start thinking about “what if” scenarios.
5. We spend days or weeks outlining every possible angle for step 1.
6. Finally, we build step 1 and run into unanticipated snags and new problems to solve.
7. Before we realize it, we have spent all our time and budget (and sanity) on step 1 of our flow.
   

A perfect step 1 of 5 does not produce a valuable product feature. Users can’t use it. Step 1 on its own accomplishes nothing. Even if we are lucky and get more money and time to continue, we keep following the same pattern. We perfect each step in order, crafting our exquisite masterpiece.

All the while, nothing is usable. It takes forever to deliver version 1. We have no learning in the wild to use to iterate and no return on our investment. Product failure is imminent.

We can see the cracks when we step back and look at this play out. Yet, we keep repeating this behavior. We can’t seem to resist solving a problem when it’s right in front of us. Even if it means neglecting the goal we are trying to achieve.

But a simple solution exists. I bet you already see it.

The Solution: Slice It Thin.

Instead of going deep and narrow, we should go shallow and wide.

This requires us to stop perfecting one step at a time in an end-to-end user flow. Rather, we create simple end-to-end slices of basic functionality through every step. Each slice layers more and more functionality. This provides quick, usable, and insightful value potential for each slice.

Go a mile wide and an inch deep rather than an inch wide and a mile deep.

I told you it was obvious. But common sense doesn’t equate to common use. It’s not our nature to leave things incomplete. We chase the trivial to please our penchant for precision.

But it’s difficult to ignore thin slices once you see and acknowledge (and experience) the benefit.

Why Thin Slices?

Developing end-to-end product features in thin, minimal slices carries significant benefits. It gives you optionality. And this saves you time and money.

I know because I have seen its value firsthand.

1. I’ve seen how it helps you harvest early value and learning.
2. I’ve seen how it enables you to shift when faced with change.
3. I’ve seen how it provides you a lever to evaluate your next move.
4. And I’ve seen how it helps you avoid chasing down the inessential.
   

This has saved many of my product teams tremendous time and money. Slices take my teams days or weeks to complete instead of months and years. We can learn, earn, and shift much faster.

Let’s explore these 4 benefits of thin slicing.

Benefit 1: You can deploy to earn or to learn.

If you develop end-to-end in thin slices, you can deploy early.

Deploying early has two distinct value advantages.

One, you can test your solution in the wild. No amount of research and prototyping before deployment can substitute for real-world application. You start learning what is working (and what isn’t). Then, you can adjust course early to improve.

Two, you can start reaping a return on your investment. Your early, end-to-end slices will not be perfect. They are incomplete. But they can start solving the problem for your user. All you have to do is put your incomplete but better solution than available today out for use. Then, you start harvesting value now, not tomorrow.

I’ve used both deploy to earn and to learn, but it’s a hard nut to crack mentally.

You must quiet your inner perfectionist. And you must be content with deploying incomplete, early solutions. I see many struggle with this. They have a habit of perfecting every bell and whistle before deploying for use. But one truth tends to get them to try it: it’s difficult to deny the possibility of early value.

Slicing thin allows you to harvest value as you build, rather than after you build everything. Who wouldn’t want that?

Benefit 2: You can step in any direction after you finish.

When contexts change, you need to be ready to pivot. Then, thin slicing makes it easier to shift direction.

Many things can trigger the need to pivot.

• New knowledge of a better path.
• New priorities that have a higher value.
• Emergency scenarios that require a shift in focus.
  

Too often, when these events occur, we are knee-deep in our current work. We would rather not leave our current focus undone to do something else. Staying focused and finishing creates friction that prevents us from pivoting. We can’t get value out of our work until we finish. Putting our half-done work on the shelf to do something else is demoralizing, and we don’t want to do it. Plus, incomplete work is difficult to pick back up later.

When you work in thin slices, this difficult choice ceases to be a problem.

Thin slices finish faster. So, when a need to pivot arrives, you are more ready to embrace it. Every time a slice finishes, you can pivot. You don’t mind doing it because you have finished. You can deploy it and reap value even if you leave to do something else. Or you can feel safe leaving it. You will find it easy to pick up fresh when you return to a clean slate after the pivot ends.

With thin slices, you are more poised to change course.

Benefit 3: You can choose to do more or throw out what you just did without remorse.

With software development, one thing remains true.

You don’t know much of anything until you do it.

• You don’t know the exact problem until you talk to users.
• You don’t know the best solution until you build and test many.
• You don’t know how hard you will have to work until you try to do it.
• You don’t know how long it will take to solve the problem until you try.
  

Answering what you don’t know requires you to operate in a way to answer your unknowns faster and cheaper. Slicing thin does this. Not slicing thin doesn’t.

When I tackle a thin, end-to-end slice, I find it natural to engage more with my users along the way to learn what they need. I gain a deeper and broader understanding of the nuances of their situation. I see the forest, not the trees.

Thin slicing allows me to test simple solutions. And because it is thin, it should be inexpensive and demand less effort. I don’t mind throwing out what doesn’t work if I haven’t thrown tons of money and effort at it. Or I might get into the thin slice and find even it is a painful, tedious, expensive effort. That’s great news. I can now stop and rethink my solution options.

But if the first slice goes smooth, and my users like it with a few enhancements, I simply build another slice to do more. Or, here’s the killer benefit: the first slice ends up being just what my users need, and I deploy it right away.

The rapid (inexpensive) knowledge we gain with thin slices is invaluable.

Benefit 4: You avoid wasting time and money building more than your users need.

When you build what’s needed and nothing more, you give yourself time back.

Think of all the things you can’t do today because you are busy building features no user needs.

• Experimenting with new technologies you want to try out.
• Paying off technical debt that is slowing you down.
• Improving the way you work to flow value sooner.
• Building another feature your users need.
• Solving other problems your users have.
  

What would you do with more time? I’m sure you can think of something. There are always more things to do than we have time or money to finish. If there’s one truth in software product development, it’s this. Thin slices help you spend your limited time on what matters.

So, now that we’ve covered the benefits, let’s turn our attention to how we slice thin. It’s quite simple.

8 Steps for Slicing Thin and Harvesting Value Sooner.

I’ll keep this fast and tight. It won’t surprise you that user engagement is crucial to the process.

Let’s dive in.

1. Understand your user’s journey. The best way to know your users is to talk to them and observe them. Watch them perform their workflow. Ask questions. Observe frustrations. Understand the root cause of pain. This doesn’t take much effort or time. And it helps you start slicing thin with better knowledge of the problem space. Just do it.
   
2. Create a foundational learning slice. Your first slice of a solution is likely for learning, not earning. Learning is valuable, too. Remember, we don’t know many things in product work. Our ignorance is the highest upfront. Keep that first slice paper thin. Make it like a practice run, a “Hello World” of your solution. Then, throw it out, take the learning, and run (to the first real pain-solving slice).
   
3. Add a slice to improve a primary pain area. Since you met with your users in step 1, you know what pains them. Pick one of the hairy pains and devise and try a simple, end-to-end solution for it. Remember, keep it basic and devoid of frills. You might even test a low-fidelity prototype to pressure test your slice before you build it.
   
4. Test the slice with your user. Most folks will wait until finishing a slice to get user input. But I’ve found it better to involve them both during and after the slice building. I keep the evaluation focused on solving the simple problem of the slice and getting it working. It’s natural for enhancements that go beyond the goals of the slice to emerge. I use these new needs to inform future slices.
   
5. Decide to iterate or deploy for use. You have reached an exciting moment in the slicing process. When you finish the slice, you get to decide your next move. You can deploy it if the user sees it improving on their existing situation. Or you can choose to solve more pain before deploying. This option is unique to thin slicing and rare to many product teams. You can take a moment to reflect on how good it feels to be in the 1%.
   
6. Reassess remaining pain. Even if you deployed your last slice, you can keep solving more pain and improving the solution. Here’s what’s cool: if you deploy, your user will be getting value while you are building more. You (and your user) reap returns as you continue to invest. Nice, huh?
   
7. Keep Iterating (and launching) thin slices for remaining pain. Now, we are cooking with gas. We are fanning the flames with each thin slice, delighting our users and reaping the rewards. This is a fun time. But even good times need to end, which takes us to the final step.
   
8. Stop when your user loves it (even if minor pain remains). You will reach a point in the thin slicing when your users become thrilled with what they have. Likely some existing minor pain remains. But this remaining pain is so minor it’s not worth your time. You can move to other higher-priority problems to solve. Claim victory and bask in your win.
   

---

And that’s it. Thin slicing in a nutshell.

It’s a simple shift in technique that helps you:

• Deploy and learn early.
• Respond easier to change.
• Throw out (don’t chase) bad ideas.
• Build less to solve user problems.
  

You only have to think and act in thin, end-to-end slices that are an inch deep and a mile wide.

While this article focused on software product development, it applies broader. I have used it to learn new skills, write, manage home projects, and help companies change behavior. Any time you are solving a problem, thin slicing can help.

Remember, most teams don’t do thin slicing. If you do it, you will be ahead of most. We are all looking for an advantage in today’s ultra-competitive environment. And here it is. Thin slicing will give you a leg up. Why not try it today?

Good luck out there. If you try it, please let me know how it goes in the comments.

---

➡️ Sign up for weekly insights like this. Learn about returning to the fundamentals that make product teams unstoppable. Join a community of like-minded professionals committed to achieving outcomes sooner.

---

References

1. Thomas, S. (2019). 2019 Feature Adoption Report. Pendo.io. Retrieved from https://go.pendo.io/rs/185-LQW-370/images/2019%20Feature%20Adoption%20Report%20Digital.pdf