The difference between a feature and a solution.

Strategy · 6 min read

Nearly everyone who comes to me starts the same way. They've got a list. "I want it to do this, and this, and this, and also this." The list is usually long. Sometimes it's a spreadsheet. Sometimes it's a four-page document. Sometimes it's a notes app with fifty bullet points.

And I get it. You've been thinking about this app for months, maybe years. Every time you noticed a problem or had a new idea, you added it to the list. That's natural. But here's the thing most people don't realise until we sit down together: most of that list doesn't need to be in the first version. And a lot of it might not need to be there at all.

The reason? Features aren't solutions. They're two completely different things. And understanding the difference is one of the most important steps in building an app that actually works.

A feature is a what. A solution is a why.

A feature is a thing your app does. A chat function. A dashboard. Push notifications. A social feed. These are all features. They're the "what."

A solution is the reason your app exists. It's the core problem you're solving for the people who are going to use it. That's the "why."

Here's an example. Someone tells me they want a chat feature in their app. Okay, but why? Because their users need to communicate quickly within a specific workflow without leaving the app. That's the solution. The chat feature is just one possible way to deliver it. Maybe a chat is the right tool. Maybe a simple notification system does the job better. Maybe a quick-reply flow is more appropriate. You don't know until you understand the why.

When you start with the why, the right features design themselves. When you start with the what, you end up with a bloated app that does twenty things but solves nothing well.

The feature list trap

Here's the practical problem with a long feature list. Every single feature costs money to design and build. Every extra screen, every extra flow, every extra interaction adds to development time and cost. It's not just the feature itself. It's the edge cases around it, the error states, the empty states, the settings, the permissions, the way it interacts with everything else in the app.

A single feature that sounds simple on paper can add weeks to a development timeline. Multiply that by thirty features and you've got a project that's blown out on budget, stretched past its deadline, and still isn't done.

Feature creep is the number one reason app projects go sideways. Not bad developers. Not bad designs. Just too much scope, because nobody stopped to ask whether each feature was genuinely necessary for the first version. The Project Management Institute found that 52% of projects experience scope creep. And according to the Standish Group's research, only 31% of software projects are delivered on time, on budget, and with satisfactory results.

The more features you add, the more complex the app becomes. And complexity doesn't just cost more to build. It makes the app harder to use. More screens, more buttons, more choices, more cognitive load on the user. People don't want more options. They want the right option, fast.

How I handle the feature list

When someone brings me a list of thirty features, we don't throw it away. That list represents real thinking and real experience. It matters.

But what we do is go through it together and ask one question for each item: does this directly help solve the core problem for the user?

If the answer is yes, it might make the MVP. If the answer is no, or "sort of," or "well, it would be nice to have," it goes on the "later" list.

Most things end up on the later list. And I know that can feel like a loss. Like we're cutting corners or leaving good ideas on the table. But it's not a loss. It's focus. It's the difference between building something that launches and something that never gets finished.

This is one of the first things we work through in the discovery phase. Getting clear on the core problem, identifying what actually needs to be in version one, and putting everything else in a prioritised roadmap for later. It's not about saying no. It's about saying not yet.

A real example

Let's say someone comes to me wanting to build a booking app for tradies. They've thought about it for a while. They've talked to mates in the industry. They've got a list:

Booking system. Invoicing. Client messaging. Review system. Job tracking. Photo gallery for completed work. Material calculator.

All good ideas. Every single one of those is useful. But if we build all seven for the first version, the project is going to take a long time and cost a lot of money. And worse, the app is going to launch trying to do everything at once, which usually means it doesn't do any of those things particularly well.

So we go back to the core problem. After doing the homework, talking to actual tradies, understanding their day, we discover something specific: tradies lose jobs because they're too slow to respond to enquiries. A potential customer sends a message, and by the time the tradie gets back to them at the end of the day, they've already booked someone else.

That's the core problem. Speed of response.

So what's the MVP solution? Instant booking requests with push notifications. A customer submits a request. The tradie gets a notification immediately. They can accept, decline, or respond with availability in seconds, right from their phone, even if they're on a job site.

That's it. That's the first version. Invoicing, job tracking, reviews, photo galleries, the material calculator. All good. All later. The first version needs to prove that solving the speed problem is valuable enough that tradies will actually use it and customers will actually book through it.

Fewer features, better product

The best apps in the world started by doing one thing brilliantly.

Instagram launched as photo sharing with filters. That's it. No stories, no reels, no shopping, no messaging. Just take a photo, make it look good, share it. The simplicity is what made it work. People understood it in seconds.

Uber started as "push a button, get a car." No Uber Eats, no freight, no package delivery. Just one thing, done so well that it changed an entire industry.

These companies didn't start simple because they lacked ideas. They started simple because they understood that proving the core value is what matters first. Complexity came later, after millions of users had validated the core. They earned the right to add features by proving the solution worked.

Your app doesn't need to serve millions to apply the same principle. Whether you're building for a niche industry or a broad market, the logic is the same. Solve one problem really well. Prove it works. Then expand.

Your feature list isn't wrong. It's just not first.

I want to be clear about this, because I know how it feels to have someone tell you to scale back your vision. All those ideas you've been collecting? They're probably good. They come from real experience, real frustration, and a genuine understanding of the problem you're trying to solve.

They're just not all version one. Some of them are version two. Some are version three. Some might be version five. And that's perfectly fine. In fact, that's how every successful app is built. In stages. Each version better than the last, shaped by what you learned from the one before it.

The MVP is version one. And version one needs to be focused. It needs to do the core thing so well that people use it, talk about it, and come back to it. That's the foundation everything else gets built on.

If you try to build the full vision in one go, you risk running out of budget before launch, burning out on the process, or launching something so complex that nobody understands what it actually does. I've seen all three happen, and none of them are fun.

But if you launch focused, learn from real users, and build from there? That's how you end up with an app that people genuinely rely on. And that later list? It becomes your roadmap. Every feature on it is a future improvement waiting for the right time.

Sources
Pulse of the Profession 2018 (Project Management Institute) - 52% of projects experience scope creep. Uncontrolled scope is the leading reason app projects go sideways.

Related blog posts:

What is an MVP and why should your first app be one? →

The real cost of designing and building an app →