Back

Feature bloat is the biggest mistake in building apps

New to story mapping? Start with our complete User Story Mapping Guide.

If you’ve sat through a talk about feature bloat, you’ve probably seen the number. 64% of features are rarely or never used.

It comes from Jim Johnson, chairman of the Standish Group, who put it in a keynote at the XP 2002 conference in Sardinia. It has been on slides ever since. Mike Cohn eventually went looking for the data behind it and found a study of four internal applications. As he put it, “Yes, four applications.”

So the most famous statistic about building things nobody uses is itself something almost nobody checked. It was, in its way, rarely or never used.

The number is shaky. The feeling behind it is solid, which is why it spread. Every team has shipped something that just sat there. The usual diagnosis is “we built too much,” and I think the real mistake is narrower than that and a lot easier to see on a map. I know because we made it, and I have the numbers.

Thirty-six cards nobody asked for

From 2022 to 2025, every new user story map in CardBoard started from a fully filled-in example. It was a made-up photo-sharing app called “picstagram,” 36 cards in all: 8 activities across the top and stories under each, every one pre-written at the right level of detail. “Choose your user name.” “Import contacts.” As story maps go, it was a good one.

In July 2026 I went through our production boards. Customers started 10,250 story maps from that example, and 1.8% of them became boards people kept working on. Of the 3,006 they started blank, 28.6% did.

That comparison isn’t perfectly fair. The example was the default and blank was a choice, so part of the gap is about who picked what. Someone who goes out of their way to pick an empty board may already know what they want to put on it.

The next number doesn’t depend on that. 94% of the abandoned example boards were left exactly as they were created. People opened them, looked, and left. Even the people who succeeded with the example deleted about two-thirds of it rather than edit it.

Nothing in the example was built wrong. It was a well-made map of somebody else’s app, and content that isn’t yours is furniture. Thirty-six finished cards stood between a new user and their first one, which is feature bloat at about the smallest scale it comes in.

So the example is gone. New story maps start empty, and CardBoard can offer a one-line prompt that seeds three or four backbone columns from whatever you type about your own product.

Too many features is the symptom

Teams are told the big risk is shipping too much, with bloated scope and late launches to show for it. Those costs are real. They’re also downstream of something else.

The expensive mistake is building past the first place a user can succeed. You add depth for the people who already made it, while most people are still stuck at the point where they feel stupid and stop.

Kathy Sierra, on her Creating Passionate Users blog and later in Badass: Making Users Awesome, called that point the suck threshold. It’s where someone has invested enough to care but isn’t yet competent enough to succeed, and it’s where most people quit. Everything you build beyond it, for an audience that never crosses it, is inventory nobody opens.

What feature bloat looks like from the inside

  • A first release full of options and power-user paths, sitting on top of a core path that still needs a support call
  • Roadmap items that delight retained users while new ones never reach a first win
  • A backlog ranked by stakeholder preference instead of by what moves someone from can’t to can
  • Metrics that move, like feature adoption among people who already succeeded, while competence at the job stays flat

The slow launches and wasted spend follow from this. The cause is aiming the first slice at the wrong altitude.

Cut a shorter path to first success

What you want is the shortest complete path through the product that leaves someone able to do the core thing without help. An MVP feature list asks “what’s the least we can build?” This asks “what’s the least a person needs to succeed once?” The two questions produce different cuts.

A user story map makes the cut visible. The backbone runs left to right in the order the user does things. Under each step sit the stories that make it real, most essential at the top. The first horizontal slice is the band across every step that still adds up to something the user can finish.

Then name that first slice as a capability instead of a schedule.

  • Weak: “Release 1” or “MVP.”
  • Strong: “A new customer creates a board and invites one teammate without contacting support.”

If you can’t name the slice that way, the map and the goal are about different things. Better to find that out before you build.

In CardBoard, that slice is a divider across the story map, and its name can be the capability. Cards above the line ship first. When someone proposes a new card, deciding which side of the line it goes on is the whole prioritization conversation, and everyone in the room can see it.

A CardBoard story map called Weeknight recipes. Five blue activities run across the top, from Find a recipe to Come back tomorrow. Release 1, cook one dinner tonight, and Release 2, plan the whole week, are open with yellow story cards under each activity. Release 3, cook with friends, is collapsed to one row with a chip showing 4 cards.
Release 1 is named for what someone can do by dinnertime. Cooking with friends waits its turn, folded up, four cards deep.

Working the map against feature bloat

Before you prioritize anything, mark the suck thresholds on the backbone. Where do people stall, ask for help, or leave?

Put the first slice through those columns, and get people to a first real success before you deepen any later step. Depth that only serves people who already crossed the threshold can wait until the threshold moves.

When the release ships, judge it by whether someone can do the job. The number of cards that closed is a different measurement, and a much easier one to feel good about.

Once the first slice is set, the rest of the backlog still needs an order. That part is how to prioritize user stories.

The test

Feature bloat is usually a room full of good intentions and no picture of the unfinished path. The map is that picture.

If your next release doesn’t leave someone able to do the core thing without help, adding features won’t fix it. Look at which part of the path you built, and which part people are stuck on.

Ready to try CardBoard for yourself? Create a free account, three boards, no credit card.

Didn’t find what you need? Visit our Help Center to find answers or get in contact with our team.