How I keep features focused

The paradox of unlimited possibilities

When it comes to building software products, one of the biggest challenges is that software can do almost anything. As long as it's possible within the realms of software and the internet - nothing too funky - pretty much anything is achievable. But when you have virtually unlimited options for what your product can do, how it can look, and what it can achieve, it's remarkably easy to make your feature list overly large, overly complicated, and therefore overly expensive.

When things become complicated and expensive, they typically take much longer to develop. Suddenly, you're looking at months or even years before getting something into the wild. This is a fundamental problem because one of the most critical factors in successful software products is getting users on the platform early, collecting feedback, and ideally generating some revenue.

Why building everything is building nothing

The temptation to build everything users might want is strong, but it's a trap. Instead, we need to build a minimal feature set and get it live. You may have seen me mention the 80/20 principle in other articles - it's the powerhouse methodology behind everything I build and do in business. It works remarkably well as a general principle to live by.

In this context, 80% of the results your customers receive - the value your product achieves - will come from just 20% of the features you build. If we try to build everything, most of it will be waste. We didn't need to do it. There's always going to be a core feature set that delivers the majority of the value.

The art of identifying the vital 20%

My job when working with clients is to help identify that crucial 20% that's going to make all the difference. We can add a few bells and whistles, some nice-to-haves, but we keep them absolutely minimal. This requires discipline and sometimes difficult conversations.

People sometimes misunderstand this approach. This isn't about building something that's not good, something scrappy, or something that doesn't look professional. We can - and should - build something polished but focused using professional development practices. The product needs to be focused, what we're trying to achieve needs to be focused, and we need to be ruthlessly strict about wasteful features.

The value of saying no

A more junior version of myself, like many companies you might work with, would respond to every idea with enthusiasm: "Great! Yeah, we can do that! We can do that! We can do that!" They say yes to everything, eager to please and win the work.

What you actually need - and I'm pitching myself a bit here, but it doesn't have to be me - is someone with enough experience and confidence to say no. You need someone who will tell you when you're barking up the wrong tree, when something is a bad idea from a technical perspective, or when a feature will derail your project.

I've seen and been brought into numerous projects where things have spiralled out of control. Teams try to make their products fly before they've even taken their first steps. It's a recipe for huge costs and usually disappointing results.

The feedback loop advantage

There's another crucial reason we focus on that 20% - what I call version one of the system. We want to get it live as soon as possible so customers can test it and provide feedback. No matter how smart you are or how well you understand your customers, you won't know everything they want. More importantly, they won't know everything they want until they have it in front of them.

I promise you, within the first week of someone using your product, they'll say things like: "It would be great if it did this," or "It'd be really nice if this could happen." They'll suggest features you and I would never have thought of. Getting that feedback is essential to building a great product.

The myth of the perfect launch

You cannot one-shot a software project. It simply doesn't happen. That's not to say we don't plan or design carefully - we absolutely do. We approach every project with serious thought and a logical, pragmatic strategy. But we do this within a limited, focused scope.

This approach has proven successful across dozens of projects. Building an MVP in 8 weeks is only possible when we maintain this discipline. It's also how we keep projects within budget - by not building features that won't deliver proportional value.

Practical focus strategies

Here's how I maintain feature focus in practice:

The Value Filter: Every feature request must pass three tests:

• Does it serve the core user need?
• Will at least 80% of users benefit?
• Can we measure its impact?

If any answer is no, the feature waits for a future version.

Feature Budgets: Each release has a strict feature budget. Adding something new means removing something else. This forces genuine prioritisation and prevents scope creep.

Pattern Recognition: Individual user requests are noted but not immediately acted upon. When multiple users request similar functionality, that's a signal worth investigating.

Jobs to be Done: We identify the specific job users hire your product to do, then evaluate every feature against that job. Features that don't directly support the core job get cut or deferred.

The compound benefits of focus

Focused products succeed because they:

• Launch faster, generating revenue sooner
• Are easier for users to understand and adopt
• Cost less to build and maintain
• Can pivot more easily based on feedback
• Build reputation for doing one thing exceptionally well

The alternative - trying to be everything to everyone - creates bloated products that please no one. In SaaS development, focus isn't just beneficial; it's essential for survival.

Getting the balance right

If you have a project in mind and you're not sure what that 20% or version one should look like, that's perfectly normal. Identifying the vital few features from the trivial many requires experience and objectivity - something that's hard to have for your own project.

This is where external expertise becomes valuable. Someone who's built numerous products can spot patterns, identify what's truly essential, and help you avoid costly mistakes. They can be the voice of reason when enthusiasm threatens to derail pragmatism.