I read an article this week about the “Tyranny of the Marginal User.” The author discussed how large companies focus more on attracting new customers than retaining current ones — primarily due to unit economics and internal company politics. It’s a fascinating read from the perspective of a Google insider. And it talks about products that have massive user bases. OkCupid was given as an example. It used to be a complex product that made it possible to find interesting romantic matches. Over time, it devolved into something like Tinder, a simple swiping app that doesn’t create deep connections.
The point here is that they had to cater not to their existing users but to their growth metrics. Things got simple and boring because they built features for the next user.
This made me wonder about indie hackers and our small software products. We also need to grow, but we need to retain customers, as their monthly payments keep our businesses afloat.
So, how much complexity do we allow? How many customer feature requests do we implement? Should we listen at all?
Experience this article as a podcast, a YouTube show, or as a newsletter:
It’s a difficult choice because we often don’t know how customers will respond to new features, and development time is precious when we’re also trying to bootstrap a whole business around a product.
As a software engineer and business operator, I want to share my personal framework for judging feature requests and improvements. I’ve found that the highest chance of feature adoption and customer retention comes from features that align with the job the customer needs to do with my tool. The “jobs to be done” framework is excellent for understanding requirements.
What Our Customers Really Need
A good example is FeedbackPanda, the software-as-a-service business I co-founded and sold in 2019. The job was for online English teachers to create written feedback for parents and submit it for payment. Features that made this process faster or easier were quickly adopted and appreciated. Features that did something outside that scope were often ignored or complained about.
We considered integrating other systems or building communication features, but they were underused or unused. These features were not critical to the job at hand—creating and submitting feedback. But, once we built a feedback template-sharing feature into the product, its adoption exploded.
Understanding the job to be done was crucial. Features that supported this consistently increased retention and signups because our customers were happy to refer new teachers our way — especially if it meant their job would get easier if those new teachers shared their own templates.
Funny enough, that’s precisely why products with millions of users go for the marginal features: they need more people to join for their network effects to work more effectively. So, in a way, indie hackers and unicorns are aligned: it’s just that as we’re hunting for that elusive product-market fit, our marginal users are still early adopters who have a higher capacity for dealing with complex products.
Back to what features to build.
I noticed two other factors to be really useful for judging the criticality of a feature: workflow inputs and outputs. Every job to be done starts somewhere and has a result that the next job needs.
When I learned to program in the Elixir language, I was mesmerized by how elegant functional programming can be. Every function takes in data, transforms it, and returns data again. An Elixir program is really just a chain of data transformations.
And that’s what a workflow is. You start with a task and end with a deliverable. And in between these two sit many subtasks that each have some kind of input and output. One task’s output is the input of another, which makes any feature that makes this easier a strong candidate.
For inputs, look for features that add ways to connect or make connection easier. For outputs, add new formats that follow-up tasks expect or can deal with more easily. Also, anything that enriches the outputs in ways that future tasks can use is a good idea. If you have a video editor that adds subtitles to short video clips, maybe it could also export a variety of subtitle files that platforms like YouTube prefer to ingest instead of just burning the text into the video.
It’s essential to focus on features that align with the job your customers need to do —both within your product and in the workflow outside it. Products that lack this focus go die in the startup graveyards every single day: they’re just “great ideas,” but they get abandoned the moment your prospective customer notices that they don’t fit into their existing process.
But if you do support their workflow, you can expect significantly higher retention and happier customers who are more likely to refer others to your product.
When Customers Speak
Still, be careful with feature requests. When customers request features, make sure they are specific and relevant to the job your tool is meant to do. Be cautious about implementing unspecific requests or features that go beyond the scope of your tool’s purpose. Stick to your core promise and focus on solving the specific problem you set out to solve.
In the future, you can choose to expand your scope, but as an early-stage founder, don’t feel pressured to build everything right away.
Sometimes, customers say they’ll join if you build a particular feature. If possible, make them commit by paying for a multi-month subscription with the guarantee that you’ll build the feature within a reasonable time frame. Otherwise, it’s an empty promise that will lead to feature bloat in your product (for a customer who’s not even paying.)
It’s okay to say no to potential customers who try to pull you towards solving other problems outside the JTBD you want to solve. Stay focused on your initial goal, and don’t pivot too quickly based on individual requests.
Just because someone wants something different doesn’t mean you should act without purpose. It’s like being a headless chicken, running around aimlessly. That’s no way to build a purposeful business.
When deciding if you should build a feature, consider a few things:
Is it a job to be done? Does it fit the scope of the problem you’re trying to solve? Is it part of the workflow, and does it improve integration into existing processes? Does it change or simplify input methods? Is it enhancing your output, adding new ways to export results, or enriching the data for easier use with other tools?
If your feature fits these criteria, go ahead and build it.
If not, it’s probably best to wait.
Because if you don’t balance this, your product will look like this: