Chapter 4

One More Feature Won't Save You

The Safest Place Is the Code

There is a particular kind of optimism that appears when an app isn’t selling. Maybe it needs the Slack integration. Or better reporting. Or team accounts. Or a mobile version. Or support for the file format three people have asked about.

The reasoning is rarely absurd. That is what makes it dangerous. There is almost always something genuinely incomplete about a software product. Give me ten minutes with an application and I can probably find something worth improving. Give the founder and me an afternoon together and we can produce a respectable roadmap. Software is exceptionally cooperative that way. It will never tell you that there is nothing left to do.

The commercial problem is different.

If people are using the product but not paying, as we saw in the previous chapter, there is an unresolved question about what that behavior means. The missing feature might be the answer. It might genuinely prevent a valuable use case, block a purchase, make the product unsuitable for an important workflow, or create enough friction that buyers choose an alternative.

But “the product could be better” is not the same conclusion as “the product is not selling because it needs this feature.” I have made versions of that leap more times than I would like to claim as professional development.

My engineering brain is extremely helpful here. It can look at commercial uncertainty and produce a technical response almost instantly. Nobody is converting? Improve onboarding. Prospects disappear after the demo? Build the capability they asked about. People aren’t coming back? Add notifications. A competitor has something we don’t? Well, obviously we need that too.

This feels good because the proposed action is concrete. I know how to create a feature branch. I know how to estimate the work. I can inspect an API, design a schema, implement the integration, test the workflow, deploy it, and know at the end of the day that something changed.

The harder question is whether the buyer’s decision changed.

That work takes place in less comfortable territory. You may have to call someone who declined to buy and ask what actually stopped them. You may discover that the feature you thought was essential was barely relevant. You may learn that the person requesting it has no purchasing authority. You may find that the prospect wants the feature, likes the product, understands the price, and still does not consider the problem important enough to act on.

There is no code change for that.

One of the reasons builders retreat into the product is that the retreat does not look like retreating. It looks like work.

Often, it is work. Good work.

The roadmap gets shorter. The product improves. Releases go out. Customers who already use the application may become happier. Bugs disappear. The interface gets cleaner. Nobody is sitting around avoiding responsibility.

The problem is subtler. We can be productively answering a question the business did not ask.

Suppose an application has been live for three months. A few hundred people have tried it. Some use it regularly. Nobody has paid. Three free users have requested an export feature.

The founder builds the export feature. What has happened?

The application is objectively more capable. Three users may be pleased. The feature may prove useful later. It may even turn out to be commercially important.

But unless we have evidence connecting that feature to a buying decision, we have not yet solved the monetization problem. We have improved the product while leaving the commercial explanation intact.

This distinction becomes more important as building gets easier.

AI Changes the Economics of Avoidance

There was a time when a bad feature idea benefited from the protection of being expensive. If adding something required three engineers, six weeks, a database migration, a new vendor contract, and a meeting with somebody whose calendar could not accommodate you until next Thursday, the feature had to survive a fair amount of scrutiny before anyone built it. You asked questions because the alternative was expensive. Is this actually important? How many customers need it?

What happens if we don’t build it? Will anybody buy because it exists?

Is there a simpler way?

Modern AI-assisted development has weakened that natural resistance. I consider this mostly good news. I have no sentimental attachment to boilerplate. I don’t think manually typing repetitive integration code builds character, and I am happy to let an AI system help me chase down the sort of bug whose eventual cause turns out to be one incorrect property name.

But lower implementation cost changes the threshold for saying yes.

If an integration used to require two weeks and now looks possible in two days, the instinct is to build first and investigate second. If a landing-page variation takes twenty minutes, make five. If a new workflow can be scaffolded before lunch, why debate it? The cost of being wrong appears small.

Unfortunately, the cost of a feature is not limited to the hours required to type it.

Every feature expands the surface area of the product. It creates something to test, explain, maintain, support, document, secure, observe, and eventually decide whether to remove. Integrations fail when upstream APIs change. New options complicate onboarding. New workflows create edge cases. Flexible products develop configuration screens, and configuration screens eventually develop their own configuration screens if nobody intervenes.

More important for this book, every build consumes attention that could have been used to resolve the commercial question. That is the part AI cannot make disappear.

Suppose I can build a requested feature in four hours instead of forty. Excellent. I have saved thirty-six hours of engineering.

If the feature was based on the wrong theory of why buyers were not purchasing, I have not saved the business thirty-six hours. I have become wrong more efficiently.

This is the modern version of hiding in the code. It no longer requires disappearing for six months to build a giant product nobody asked for. You can remain highly responsive, release constantly, talk to users, use analytics, generate roadmaps from feedback, and still avoid the harder task of finding out which changes affect a purchase.

The activity can look almost exemplary. Weekly releases. Fast response to feedback. Ten integrations. Beautiful changelogs. A rapidly shrinking backlog that somehow keeps replenishing itself.

Meanwhile, revenue remains flat.

I do not think the solution is to slow down engineering for ceremonial purposes. Fast building is an advantage. Use it.

But once implementation becomes cheap, why you build becomes more important, not less. “Can we build this?” used to eliminate a fair number of ideas automatically. Now the better question is: What earns permission to build it?

The $40,000 Feature Request

A prospect once told a team I was working with that our application was almost exactly what they needed. There was one problem. They needed an integration with a system we did not support.

This was not the sort of feature you add by exposing another checkbox. Building the integration properly meant authentication work, engineering time, testing, documentation, deployment, and an ongoing obligation to support a dependency we did not control.

Still, the sales conversation made the decision sound straightforward. A serious prospect was evaluating the product. A specific technical gap had been identified. The proposed annual agreement was worth about $40,000.

The instinct inside the team was perfectly reasonable. If this closes the customer, build it. I wanted to test one part of that sentence before we did the engineering. The key phrase was if this closes the customer. So we went back to the prospect and asked, in substance, whether they were prepared to proceed with the proposed agreement if we delivered the integration by the agreed date and the rest of the product performed as demonstrated.

The conversation changed. They still liked the product. They still wanted the integration. They were not prepared to commit to buying afterward.

That did not make the prospect dishonest. They had identified something they genuinely wanted. It did not make the feature useless either.

It told us something narrower and much more valuable: we did not yet have evidence that the integration was the thing standing between us and a sale. That distinction saved us weeks of false certainty.

We kept talking to the market. Two more companies mentioned the same integration. This time the commitment question appeared much earlier. One agreed to a paid implementation pilot contingent on the integration working. Another agreed in writing that completion of the integration would satisfy the remaining technical requirement in its evaluation.

Now the same feature request meant something different. We built it. The original prospect still did not buy. The other two did, producing more than $70,000 in first-year revenue between them, and the integration later proved useful in additional deals.

What I like about this story is that the conclusion is not “don’t listen to customers.” We did listen. Nor is it “never build anything unless someone signs a contract first.” That would be impractical in plenty of products and almost comical in consumer software.

The useful distinction is between a requested feature and a purchase-critical feature. The original prospect had provided evidence of preference: they wanted the integration. The later prospects provided evidence that the integration affected a commercial decision.

Those are different facts.

Had we simply built from the first request, we might eventually have arrived at exactly the same code. The technical outcome could have been identical.

But we would have reached it with much less commercial information. That is why, when a prospect asks for something expensive, I have become interested in a second question.

Not just:

Do you want this feature?

But:

What commitment does this feature unlock?

Sometimes the answer is substantial. “If you support SSO, security will approve the pilot.” “If you can process this file type, we’ll run the evaluation next month.” “If the product supports our existing CRM, I’ll move forward at the quoted price.”

Those statements still do not guarantee a sale. People change their minds. Organizations change priorities. New objections appear. One person can sincerely believe the remaining requirement is technical and discover that procurement has prepared several exciting new requirements of its own.

But the evidence is stronger.

Compare that with:

“It would be nice if you had Salesforce integration.” “I’d probably use this if it worked on mobile.” “You should add dashboards.” “Have you thought about teams?” All useful observations. None deserves to quietly transform into a revenue forecast.

This is the same discipline we applied to user metrics in Chapter 3. The feature request should be allowed to prove what actually happened: somebody requested a feature.

Before turning it into weeks of engineering, find out what else you think it proves.

The Build Permission Checklist

I use Build Permission as a way to slow down the decision just enough to identify what we think the engineering work will change.

This is not a bureaucracy for developers. Please do not create a seven-stage Jira approval workflow and blame me.

It is a short commercial test for product work being justified as monetization work. Before an important feature enters the roadmap, ask six questions.

1. Who needs this?

Be specific.

“Users” is usually too broad. Which users? Paying customers? Prospects? A buyer segment you are trying to enter? One unusually vocal person? The founder?

There is nothing embarrassing about the final answer. Founders are allowed to want features. Product vision matters. Just label the source accurately.

A capability requested by several qualified prospects deserves a different interpretation from a capability the team believes will make the product more impressive.

2. What do they do today?

The request exists in a current workflow. What happens without the feature?

Do they manually export data? Use another product? Pay someone to perform the work? Avoid the task? Live with the inconvenience? Refuse to adopt your product at all?

The workaround tells you how much behavior the missing feature is already causing. If the answer is “nothing much, this would just be nicer,” that is information.

3. What financial or operational consequence exists?

Do not force every feature into fake ROI arithmetic. Nobody needs a spreadsheet proving that dark mode will unlock $18,742 in annual enterprise value.

But if a feature is supposed to help monetize the product, there should be some connection to a consequence that matters. Does the missing capability create labor, delay, risk, lost revenue, rework, support burden, implementation difficulty, or some other meaningful cost? A request attached to a consequence is usually more interesting than a request attached only to preference.

4. What decision is blocked?

This is the question builders skip most often. What cannot happen until the feature exists? Can the prospect not begin a pilot? Can the buyer not pass a security review? Can the customer not move a workflow from the old system?

Will an existing account not renew? Is the feature preventing activation? Or is everyone perfectly capable of proceeding today and merely expressing a preference for a better version? You are looking for a decision boundary.

5. What commitment has been made?

The appropriate commitment depends on the situation. For a large B2B feature, it may be a paid pilot, a signed agreement contingent on technical completion, or written confirmation that the feature satisfies the remaining requirement.

For a smaller self-service product, you may not get formal commitments. You might instead test the feature manually, put it behind a paid tier, offer early access, ask users to join a design partner program, or create some other behavior that costs enough effort to reveal seriousness.

The point is not to demand money before touching the keyboard. The point is to ask for evidence proportional to the build. A four-hour experiment can survive weak evidence. A four-month integration should probably require more than “this would be awesome.”

6. What result would justify the build?

Decide what success means before you implement the feature. One new customer? Three qualified evaluations? Higher activation among a specific segment? Retention of an important account? A technical prerequisite for entering a market you have deliberately chosen?

Sometimes the answer is not directly commercial. You may need the feature for reliability, compliance, architecture, supportability, or strategic product reasons.

Fine. Then say that. The discipline is not “every line of code must generate revenue.” The discipline is “do not call something monetization work unless you can explain the commercial theory.” That distinction protects both the business and the engineering team.

Developers should not be forced to carry the burden of fixing sales problems through an endless sequence of vaguely revenue-adjacent tickets. And founders should not interpret successful deployment of those tickets as evidence that the business problem has been solved.

Build Permission gives the feature a hypothesis. Once it has one, the release can teach you something.

When Building Is Absolutely the Right Move

I have spent enough pages warning you about building that I should make something clear. Please keep building software. The title of this chapter is One More Feature Won’t Save You, not Software Development Was a Terrible Mistake.

Products need features. Early products are often incomplete. Customer feedback can expose serious deficiencies. A missing integration can prevent adoption. A weak workflow can destroy value. Poor reliability can make an otherwise good product impossible to trust. Sometimes the correct commercial diagnosis is extremely technical: the application cannot yet do something the buyer legitimately requires.

When that happens, building is not avoidance. It is the answer. The difference is that evidence pointed there.

Imagine five serious prospects reach the same point in an evaluation. They understand the product. The problem is important. The price is within range. They have authority. They want to proceed.

Then each discovers that your application cannot integrate with the system containing the data required for the workflow. That starts to look like a product problem. Or suppose customers pay, begin onboarding, and repeatedly fail because importing their existing data is too difficult.

Fix the import.

You do not need a spiritual journey about founder psychology. The system is broken at a place you can observe.

This is why I do not like rules such as “never build before selling.” They are memorable and sometimes useful, but reality has more cases than a slogan can comfortably contain.

You may need a prototype before buyers understand what is possible. You may need technical validation before asking someone to commit. You may operate in a market where security, reliability, integrations, or compliance requirements establish a legitimate minimum product before serious buyers can evaluate it.

The question is not whether product work is allowed. It is whether we know why this product work deserves priority now. The best roadmap becomes a mix of different kinds of work, each honestly labeled. Some work maintains reliability. Some reduces risk.

Some serves existing customers. Some tests a technical idea. Some supports a strategic direction. And some exists because evidence suggests it will change a commercial decision. Trouble begins when every item is quietly placed in the last category because revenue is weak.

If a feature is worth building for product reasons, build it for product reasons. You do not need to pretend a new settings screen is a sales strategy.

Stop Using Velocity as Proof

Technical velocity is seductive because it is visible.

Last month the application supported three integrations. Now it supports eight. The release notes are longer. The UI has been rebuilt. The AI output is better. New workflows appear every week.

You can point at the difference. Commercial learning often leaves a smaller artifact.

Sometimes all you have after an important week is this:

We learned that the buyer we were targeting does not own the problem.

Or:

Three prospects liked the product, but none considered the problem urgent enough to switch.

Or:

The feature everyone requested did not change the purchase decision. That can feel like less progress than shipping another release. It isn’t. If the goal is to build a business, discovering that your current theory is wrong can be worth far more than making the application better under that theory.

AI makes this discipline increasingly necessary because velocity has become cheaper to manufacture. We can create an impressive amount of software activity without forcing the commercial model to become more accurate.

The repository is not lying. The features are real. The work happened.

It just may not be the work the business needed. A roadmap can be an avoidance strategy with excellent project management. So take the next significant feature on your list and run it through Build Permission. Who needs it? What are they doing without it?

What consequence does the gap create? What decision is actually blocked? What commitment exists? What result would make the build worthwhile?

You may finish that exercise and decide to build immediately. Good. Now you know why.

You may decide to build a much smaller version first because the evidence is promising but weak. You may realize that the feature is valuable for product quality but has little to do with monetization. You may discover that nobody has actually connected the request to a purchase at all. That last answer creates an uncomfortable empty space on the roadmap. Do not rush to fill it.

If the evidence does not currently say build, the next question is not automatically what else can we build? The next question is where the path to money is actually breaking.