The Difference Between Shipping Features
and Solving Problems

Look at most quarterly reviews and you'll see a list of things that shipped. Twelve features. Velocity up. Burndown clean. It reads like progress. Then someone opens the support queue and the thing customers kept asking for at the start of the quarter is still sitting there, unsolved, under a pile of things nobody asked for.

This is the quiet failure mode of productive teams. Not shipping too little, shipping steadily, and still not moving the thing that mattered.

A feature is legible. A problem isn't.

The reason teams drift toward features is that features are easy to see. A feature has a name, a demo, a line on the changelog, a moment in the standup where someone says 'done.' A solved problem has none of that. It shows up as an absence, a ticket that stops arriving, a workaround people no longer need, a question that stops being asked. You can't screenshot an absence.

So the work that's visible gets rewarded, and the work that's visible is output. Over time the team optimises for the thing it can point at.

People don't want the drill

The oldest framing of this is still the best. Theodore Levitt's line, popularised by Clayton Christensen: people don't want a quarter-inch drill, they want a quarter-inch hole. Nobody wants your export button. They want the report in their inbox before the 9am meeting. Nobody wants your dashboard. They want to stop being surprised by numbers.

When you build the drill and call it done, you've shipped a feature. Whether you made the hole is a separate question, and it's the only one that counts.

Assign problems, not features

The teams that avoid this tend to be structured differently. Marty Cagan's group at SVPG draws the line cleanly: strong product teams are handed problems to solve and outcomes to hit, not a list of features to build. It's a small change in wording with a large change in behaviour. 'Build a bulk-import tool' has one acceptable ending. 'Make it painless to bring existing data in' has many, and most of them are cheaper than the tool.

The test is simple, and you apply it after you ship, not before. Did the user's behaviour change? Did the ticket stop coming? Did the number move? If you can't tell, you shipped a feature. If you can, you solved a problem.

Ship less. Solve more. The changelog will look quieter and the product will get better, which is the trade every good team should be willing to make.