You know that killer feature you just thought of? You don't need it (probably).

Ideas are cheap — implementing them is not. Indie hackers don't have the luxury of building all the features, and choosing between features is one of the toughest things we have to do.

I looked into how indie hackers are doing it. Here's what I found.

Problems, not features

I'm going to be talking a lot about features, so let me get this out of the way first. Features aren't what matters. Not really, anyway. It's the problems that matter.

@austerberry: Focus on problems, not features, and prioritize them based on how much value solving it would bring to the user and your business. This will make sure you're spending your time wisely and getting the most bang for your buck.

Then, once you have an idea of what problem to solve, you can start exploring solutions/features.

Feature requests

Feature requests are pretty much inevitable once you've got traction. And that's a good thing, so if you aren't getting any, it's probably worth asking for some.

The most important users, when it comes to feature requests, are your ideal customers. The ones who are all about your product. Not the ones who are on the fence. Eventually, you'll want to understand how to bring the stragglers into the fold, but that can wait until you've got more time on your hands.

@chillyorange: Ideally; your application will have actual users who are providing you with feedback based on which you can determine the roadmap for your application.

If you do not have actual users yet; you will need to collect your data based on conversations with your target audience (and you should be doing the absolute minimum to turn these people into users).

If you’ve got neither; no users and no audience, you should not be building any features. At this stage, you should not be thinking about features nor should you be doing any development.

Here's some solid advice on talking to users:.

@reinder: Keep in mind that users own the problem, you own the solution. This means that you should not ask them what to build but question them on the problems they experience and create your backlog based on the solution that you see.

Surveys can help too.

@Fat_Tony: For surveys, make sure you ask:

1. How are you solving the problem currently? (if not solving it then it's not a problem)
2. On a scale of 1-10 how big of a problem is it? (magnitude of the problem by their instinct and helps put the following answers into context)
3. How much money are you spending on the problem? (a lot of money or a little money is all about context. The previous question puts this # into perspective)
4. How much time are you spending on the problem? (same as above)
5. On a scale of 1-10 how satisfied are you with your current solution to the problem?

If 1, and 3 or 4 are in the affirmative then calculate your opportunity score.

Opportunity Score = #2 - #5.

Opportunity Score X Money X Time = Opportunity Gap.

Now make comps to your other Opportunities.

And I know of at least one indie hacker who allows users to vote on new features.

You can also do interviews. If you're going to do that, I'd highly recommend reading The Mom Test first.

Of course, it's important to validate that the all this feedback is actually good. The last thing you want is to build things for a customer that don't actually push the needle for your business. So decide whether it'll help with the specific reason you're building features at this time. And if it will, then run it through one of the frameworks below to see how important it is.

@tom_shaw: Unfortunately, I let my first customer push me around a bit too much. I wasted valuable time. I built features that only they needed. Which ultimately led to me building a product that did not meet the requirements of the rest of the market.

Reasons to build that new feature

Ultimately, there are three good reasons to add a new feature:

• User acquisition
• Paid conversions (free to paid, upsells, etc.)
• Retention

I'd also say that the joy of building a beautiful product is a good reason… but it's not necessarily a good reason from a business perspective.

Don't do it because someone told you to. Even if it's a customer (but not if it's many customers). Don't do it because you're avoiding marketing, which happens more than most would like to admit. Don't do it to keep up with the competition, unless it actually benefits your product. I could go on, but you get the idea.

So the first thing indie hackers have to do when considering new features is to determine what they need to achieve: Is it user acquisition, paid conversions, or retention?

@cblindsey3 shared something helpful in this regard from a Microconf talk:

If trial to paid conversion is > 35% with credit card required (or 15% without) and churn < 6%, focus on acquisition. Otherwise, focus on retention. He also said that if you have < 30k monthly unique visitors, acquisition will likely give you the best ROI. Just rules of thumb, but something to consider.

Once you know your "why", you've got to figure out whether the feature you're considering actually moves the needle for it.

Validating and prioritizing features

Most of the time, it's pretty clear whether a feature could impact your core reason for considering it (i.e. acquisition, conversion, or retention). But it's rare for indie hackers to have just one feature idea and move forward with it. Generally, we've got a bunch of ideas, plus a bunch of feature requests from users, per above, plus a bunch of features from who knows where else... And that makes it pretty tricky to decide which features to start, which ones to throw on the backburner, and which ones to throw in the idea graveyard.

So when thinking about new features, consider a few things:

• Business value. Does it push the needle on the three reasons I mentioned above?
• User relevance. Is it relevant to all your users or just a few?
• Value to users. How valuable is it? Will they pay for it?
• Complexity and implementation effort. This plays a role in the prioritization frameworks below.
• Is there currently a sufficient workaround? If so, the feature may not be necessary.
• Usage frequency. How often will it be used?
• Is it easily communicated? If not, it might not get any user adoption.
• Positioning. Will it strengthen your brand and/or your position in the market?
• Does it create a "wow" moment? That can sometimes be worth it, if it helps with retention.
• Will it reduce decision-making time for potential customers?

Once you've made a decision on whether something is worth trying, test an MVP of the feature before building the whole shebang.

And of course, I'm all about prioritizing your features so that you're doing the most important features first. There are a lot of frameworks for prioritizing features out there, but I'll just list my top 4.

• DIE: This one is probably my top pick. You measure demand, impact, and effort using this spreadsheet. It's set up so that you'll actually want the lowest number possible, which is created by high demand, high impact, and low effort.
• Value vs Effort Quadrant: This one is great because it's quick and easy. To use this, rate a feature's value to the business and the difficulty to implement it. Plot the resulting point on a quadrant chart. The sweet spot is the highest value with the lowest effort. High effort with low value is trash.
• Prioritize by Constraints: Finally, if you're short on specific resources, you can prioritize based on what you do and don't have. If you can't afford something, it gets delayed and something else is prioritized. This can be used in tandem with other methods.
• RICE Method: Indie hackers love this one. You rate the reach (how many people it'll impact in a certain timeframe), impact, confidence (that it will deliver a desired result), and effort. Then figure out the total impact per time worked with this equation: Reach x Impact x Confidence / Effort. Here's what @csallen had to say about it:

What I like most about it is including the reach. It's really easy as a founder to become obsessed with very small corners of your app that only advanced users like yourself care about, while neglecting things that affect 100% of your users, e.g. the onboarding experience.
Impact is obviously important, and so is effort, both of which you included in your list. Effort is a big one for me as a developer. It's easy to get sucked into working on massive slog projects that, while impactful, aren't nearly as helpful as doing 50 smaller things instead.

Fix your product first

Before you even think about adding new features, make sure your current features are in a good place.

@yousuf: At the end of the day, in my experience as solo founder, improving poorly implemented existing features until they are "pretty good" is better than adding new features - my exception being new features that would unlock a new customer segment. As a solo dev, it's usually easier to maintain a codebase with fewer features, and if you ship things quickly, you'll find yourself under a mountain of technical debt sooner or later.

Then get it done

From there, add them to your project management or todo tool. I'm personally a fan of public roadmaps, so if you are too, add the new features to yours with a reasonable timeline. Then get to work.

What did I miss?

Subscribe for more tips, how-tos, and case studies

The Boot's Trap 🪤

Learn from indie hackers who are in the thick of it

Subscribe