Cast the Ring Into the Fire: Why Founders Must Resist the Temptation to Add One More Feature

I have seen the same thing happen to founders enough times now that I have decided I need to start saying something earlier.

It usually starts with a good product.

Not a vague idea. Not another generic app. A real product. A product with a sharp niche, a founder with vision, real research behind it, and actual conversations with actual users.

Those are the products I like to work on.

David Ogilvy wrote in Confessions of an Advertising Man about the importance of believing in the product you represent. I have always felt the same way about software. I do not want to build things I do not believe in. I do not want to help create second-best products. If I am coming in as a fractional CTO or CPO, I want to believe the thing we are building has a real shot at being best in class for the people it is meant to serve.

And these days, that focus matters more than ever.

Artificial intelligence has made it easier than ever to build general software. Generic apps are cheap now. If your product does not require domain expertise, a sharp point of view, or a difficult problem worth solving, it is going to be very hard to defend.

So the best early-stage products usually begin with a beachhead: a specific user, a specific pain, a specific story, and a specific reason to exist.

And then, somewhere during the build, something happens. The product starts to feel real. The founder starts to ruminate.

They begin seeing all the other ways the product could be used. It could serve this group. It could serve that group. A VC says, “I would be more interested if it also did this.” A potential customer says, “This is great, but we would need it to also support that.” A friend makes an offhand comment. A new module appears in someone’s imagination. Another persona gets added to the landing page. Another workflow enters the backlog.

And suddenly the product is no longer telling one powerful story.

It is trying to tell three.

That is where the trouble starts.

You Cannot Tell Every Story at Once

The first version of a product has to tell an incredibly powerful story to the first group of users it is trying to capture.

That story shows up everywhere: on the landing page, in the onboarding, in the product architecture, in the navigation, and in what you choose not to build.

Every time you introduce another audience into that story, you dilute it.

Now the landing page has to ask, “Are you this person or that person?” Then maybe, “Are you this person, that person, or this third person?” And while that might seem like a small UX problem, it is actually a positioning problem.

There is rarely an elegant way to do it. The copy gets softer. The onboarding gets heavier. The product gets broader. The emotional connection gets weaker.

Instead of making one group of people feel like, “This was built exactly for me,” you make three groups of people feel like, “I think this might be for someone like me.”

That difference is fatal at the earliest stage.

Great products, like great stories, need coherence.

Think about Game of Thrones. Part of what made it so captivating was the sheer number of stories happening at once. There were love stories, revenge stories, quests for power, family tragedies, political betrayals, and hero’s journeys all unfolding together. For a long time, that complexity was thrilling.

But complexity creates debt.

The more threads a story carries, the harder it becomes to resolve them in a way that feels satisfying. Eventually, all those arcs have to come together. If they do not, the audience feels it.

Products work the same way.

Now contrast that with The Lord of the Rings. It is also a massive world with many characters, kingdoms, histories, battles, and side quests. But the core story is simple: Frodo must carry the ring to Mordor and destroy it.

That clarity gives the whole story its shape.

Early products need that same center of gravity.

They need to feel like the obvious answer for a specific person with a specific problem. The more user types you introduce, the more workflows you add, and the more promises you make, the harder it becomes to make the whole thing feel inevitable.

And early products need to feel inevitable.

The Ring of a Thousand Features

This is where the metaphor becomes useful.

For founders, the temptation to add “just one more thing” is the ring.

It is precious. It whispers. It says, “This will make the product bigger.” It says, “This will unlock another market.” It says, “This will help us raise money.” It says, “This will make that one buyer say yes.” It says, “This is easy to add.”

And the most dangerous part is that the ring is not always wrong. The feature might be useful one day. The other market might be real one day. The workflow might matter one day. The VC might even have a point.

But “one day” is not the same as “right now.”

At the zero-to-one stage, the question is not, “Could this be useful?”

Almost anything could be useful.

The question is, “Does this make the core story stronger for the first group of users we need to win?”

If the answer is no, cast it into the fire.

Do not put it in the backlog. Do not hide it in the nav. Do not add it as a secondary onboarding path. Do not build it because someone important said they might care.

Write it in a notebook if you must. Put it in a parking lot document. Let it sit. Let time test it.

But do not let it corrupt the product.

Beware the Counterfeit Yes

One of the most dangerous things a founder can receive is a counterfeit yes.

A counterfeit yes sounds like this:

“We would invest if it also did this.”

“We would buy it if it had this feature.”

“This would be interesting for our team if you supported this other use case.”

Founders hear those sentences and understandably want to act. They are trying to survive. They are trying to raise. They are trying to sell. They are trying to make the product more attractive and building has never been cheaper.

So they build the thing.

And then what happens? The VC does not invest. The buyer does not buy. The customer has another objection. The person who suggested the feature disappears.

Now the founder is left holding the bag. The product is more complex. The story less powerful.

And worst of all, the app is less delightful.

This is how good products die.

Not always from one catastrophic decision. Often from a series of small, reasonable-sounding additions that slowly dilute the original promise.

Easy to Build Does Not Mean Worth Building

This temptation has never been stronger than it is right now.

AI has made software faster to produce. Modern frameworks, component libraries, boilerplates, and LLM-assisted coding make it feel like adding another module is not a big deal.

And technically, maybe it is not. Maybe it is easy to add. But that is not the right standard.

A product is not finished when there is nothing more to add. It is finished when there is nothing more to take away.

That idea, often attributed to Antoine de Saint-Exupery, is one of the most important principles in early product development.

The cost of a feature is not just the time it takes to build it.

The cost is the explanation, the onboarding, the support, the navigation, the edge cases, the mental model, and the dilution of the story.

Every feature asks the user to understand one more thing.

Every persona asks the product to serve one more master.

Every additional market weakens the force of the original wedge unless it is introduced at the right time, in the right way, after the core has already been proven.

We Will Just Put It in the Nav Is Not a Strategy

Another version of this mistake is when the founder says, “We will build it, but we will not make a big deal out of it. We will just put it in the nav.”

That sounds harmless.

It is not.

If the feature is buried, then it is good as not built. It will not attract the new audience, because the product is not telling that audience a story. There is no dedicated positioning, no focused on-boarding, no emotional hook, no reason for that user to believe this product was made for them.

So now you have built something that does not help you acquire the new audience. But it can still create complexity for the existing one.

And what if people do find it? What if they use it? What if the secondary feature starts creating demands that conflict with the primary use case?

Now your core users want one thing, your accidental users want another, and your product starts bending in multiple directions at once.

That is not flexibility. That is fragmentation.

With great flexibility comes great complexity.

The more paths you allow into the product, the more responsibility you take on to make each path excellent. And at the early stage, you do not have the money, time, team, or market clarity to make five things excellent.

So make one thing excellent.

Build the Better Feature for the Core User

Here is the question I wish more founders would ask:

Would you rather build one excellent feature your core user will love, or five half-formed features for five audiences you have not yet earned?

Because that is usually the real trade-off.

It rarely feels that way in the moment. In the moment, it feels like expansion. It feels like opportunity. It feels like being strategic.

But in reality, you are often choosing between depth and sprawl. And depth is what creates love.

The goal of an early product is not to be broadly acceptable. The goal is to be intensely valuable to a specific group of people.

You do not need everyone to like it. You need a small group of people to love it. You need the hundred true fans. The true believers. The people who feel the pain so clearly that when they see your product, they immediately understand why it exists.

Once you have that, expansion becomes easier. You can add new markets later. You can introduce new workflows later. You can build the adjacent modules later. You can tell the second story after the first story is working.

But if you never get the first group to love the product, the second group will not save you.

The Focused Competitor Is Coming

There is another danger here founders do not think about enough.

While you are broadening your product, someone else can come along and build the focused version.

They do not need to beat you to market anymore. Software is moving too quickly for that phrase to mean what it used to mean. They can beat you in market. They can show up at the same time with a sharper product, a clearer landing page, a simpler on-boarding flow, and a stronger emotional promise.

While your app says, “We help these five types of users do these twelve things,” theirs says, “We help this exact person solve this exact painful problem.”

That is the product people remember. That is the product people share. That is the product that feels like it was built by someone who understands them.

The bar for building apps has gone down. The bar for building beloved apps has gone up.

Focus is how you compete.

My Duty as a Fractional CTO/CPO

As a fractional CTO/CPO, part of my job is to help founders build. But another part of my job is to help founders not build.

That is sometimes the harder responsibility.

Because the founder is paying me. If they insist, of course I can put the feature in the app. I can add the module. I can add the on-boarding branch. I can add the extra persona to the landing page.

But I also have a duty to say the thing plainly:

I have almost never seen this strategy work at the earliest stage.

I have seen it kill products.

I have seen good ideas get overtaken by secondary ideas. I have seen original theses diluted beyond recognition. I have seen teams run out of money not because they could not build, but because they built too much of the wrong thing too early.

So the next time the ring appears, I am going to say something.

That feature may be real one day. That market may matter one day. That module may deserve its own roadmap one day.

But right now, we have a ring to destroy.

Stay with the original thesis. Serve the first user deeply. Tell one powerful story. Make the product more lovable, not more expansive. Build until there is nothing left to take away.

And when the temptation comes to add one more feature because it feels easy, strategic, or impressive, do the thing that great product work often requires:

Cast it into the fire.