Feature creep is a signal problem

Feature creep creates a lot of problems. The usual suspects are real: lengthening time to release, overstretching the team, technical debt, poor user experiences.

The worst thing that feature creep does is blind you to deep product issues.

Let’s say you’re building some new app and keep packing more and more features in there. You build whole systems and infrastructure. The UI explodes in complexity.

Now, you finally release it. You start hearing about loads of issues. This page doesn’t look right on mobile. This widget doesn’t save correctly. This image doesn’t look right when it loads. The list goes on and on.

So, you start fixing all that. It’s an all-hands-on-deck emergency.

But, you’re ignoring the most critical questions after a new release. Does the app solve a valuable problem? Do people even want this thing? Are people sticking around?

Let’s consider the less likely path. You release and collect user feedback despite all the issues. You get metrics in and review them. You try to answer the core product-market fit questions.

Your attempts will be muddled.

You aren’t the only one blinded by feature overload. Your users are too. As you collect feedback user aren’t talking about whether it solves some problem. They’re telling you about bugs and strange layouts.

The only way to win this game is not to play.

When I’ve seen this happen, it’s always because the product thesis isn’t clear. We know the general shape of the problem we’re trying to solve. Let’s figure it out as we go. So, you build Swiss army knife instead of a corkscrew. Sure there’s a corkscrew in there, but it’s a crappy one.

You shouldn’t be building anything until you know exactly what problem you’re trying to solve or how you plan to evaluate your solution.