Part III: Make the App Buyable

Chapter 11

Your App Is Not the Offer

Feature Inventory Versus Buying Proposition

Put the same application behind two different landing pages.

The application is a specialized AI tool for professional services firms. It connects to the systems where project information already lives, pulls the relevant data together, identifies missing information, generates an analysis, produces a client-ready report, and keeps an audit trail. It has integrations, configurable workflows, templates, exports, role-based access, an administrative dashboard, and enough AI inside it to justify using the word AI on the website without committing fraud.

The first landing page explains all of this. It tells you about the integrations, the automated analysis, the customizable templates, the intelligent recommendations, the real-time dashboards, the secure data handling, and the inevitable collection of other capabilities accumulated during development. There is a screenshot showing several of them at once, and farther down a feature comparison table in which the checkmarks become increasingly enthusiastic as the plans get more expensive. Nothing on the page is false.

Now put the identical application behind a second page. This one is written for a firm whose experienced employees lose several hours every month assembling recurring client reports from information scattered across project systems. It explains that the firm can connect the sources it already uses, establish the reporting workflow once, and produce the next reporting package with most of the collection and assembly already done. It tells the buyer what is included in getting the first workflow running, roughly when to expect a useful result, where human review still belongs, and what support exists if the setup misbehaves.

The software has not changed. The purchasing decision has.

That distinction is easy to miss because builders describe products from the inside out. We know what exists because we built it. We know which integration took three days longer than planned and which feature looks simple only because several unpleasant technical decisions are hidden behind a button. So when somebody asks what the product is, we reach for the inventory: it connects to these systems, performs these functions, supports these formats. I can do this for an embarrassingly long time, and in the right conversation it is useful. In the wrong one, it leaves the buyer doing nearly all of the commercial work. They have to look at the feature list and reconstruct the proposition themselves: which capabilities matter to their situation, what those capabilities would replace, how much effort adoption requires, and what exactly they are supposed to believe will be better afterward. Some buyers will do that work. Most founders should not build a business plan around their generosity.

A feature inventory answers a legitimate product question: What can this software do? A buying proposition answers a different one: What am I agreeing to if I say yes? The features constrain what you can credibly offer; a good offer is not a verbal escape from a weak product, because eventually somebody uses the thing, which has an inconvenient way of resolving disagreements between the promise and the software. But the reverse is also true. A capable product does not assemble its own commercial meaning.

This is where software businesses become oddly literal about themselves. The founder spent months creating fifteen useful tools, so the website proudly announces 15 powerful tools. That is an accurate statement about inventory. It says nothing about which person should care about all fifteen, which problem causes them to act, or why access to the collection deserves a purchase. A founder with 500 visitors, thirty signups, and zero customers does not want fifteen tools. They want to know why people aren’t paying and what to test before spending another week changing things. If the page makes them translate the tool list into an answer to that question, the founder who built the software has transferred one final design task to the prospective customer: Please inspect these capabilities and assemble your own reason to buy. That is asking a lot from someone who has not paid you yet.

The problem gets worse as the product becomes more flexible. Flexible software can support many buyers, workflows, and outcomes, which is an engineering strength and a buyer’s ambiguity. A reporting platform might serve agencies, consultants, accounting firms, and internal operations teams, automating monthly reports, compliance packages, and client deliverables. Every use case is legitimate. Putting all of them on the page does not make the offer stronger; it documents more possibilities. This is why adding capability can make a product objectively better while making it no easier to buy. The builder thinks, Now it does twelve things. The buyer thinks, Which one of these am I here for?

I use offer more broadly than the sentence above the checkout button. It is the proposition the buyer believes is on the table: the situation you are prepared to improve, what you will provide, and roughly what accepting it requires of them. The difference matters most when the buyer says no. A rejection of a feature inventory is nearly impossible to interpret. Perhaps they did not see the feature that mattered, or could not connect the capabilities to their workflow, or understood every feature and still saw no reason to change. You learn little because you made the buyer infer too much. A clearer proposition gives the market something sharper to disagree with. The feature inventory tells the buyer what exists. The offer has to tell them what buying it means.

The Buyer Is Purchasing a Change

A useful way to test an offer is to remove the product name and ask what becomes different if the buyer says yes. Not what they gain access to. What changes.

Before the purchase, somebody spends Friday afternoon assembling a client report from four systems; after it, the information is collected automatically and the person reviews exceptions. Before, an operations manager has no reliable way to see which requests are stalled; after, the manager sees the exceptions without asking three people for status. Before, a consultant spends two hours turning notes into a deliverable; after, a usable draft arrives in twenty minutes and the consultant spends the time reviewing judgment rather than formatting. Those are different propositions from AI-powered analytics, automated workflows, or intelligent recommendations, which may be accurate but describe properties of the solution while leaving the buyer to imagine the changed condition.

Builders underestimate how much work hides inside that imagination. When I see an automated analysis pipeline, I can trace the sequence: data comes in, gets normalized, a model evaluates it, exceptions surface, somebody does less manual work. The buyer sees a box labeled Automated Analysis, which is a much shorter experience. They do not know which part of their process disappears, which part remains theirs, whether the result arrives early enough to matter, or whether this is another dashboard they will feel vaguely guilty about ignoring.

This is why sell outcomes, not features is directionally correct and not very useful by itself. “Outcome” becomes its own marketing fog. Increase productivity. Save time. Grow revenue. Make better decisions. Almost every business product can claim those, in the same way that “go somewhere” is technically a travel plan. The useful question is more concrete: What observable part of the buyer’s situation should be different after the purchase? If the product saves time, what work takes less time? If it reduces errors, where do those errors occur today? If it automates something, what no longer requires human effort, and what still does? That last question matters especially with AI products, because automation is an unusually generous word. A workflow can have twelve steps, and automating three of them may be a worthwhile product, but the buyer needs to know which three. Otherwise the promise expands to fill whatever the reader hopes automation means.

Suppose an AI application reviews incoming service requests and recommends how to handle them. The builder describes classification, retrieval, orchestration, confidence scoring, and human-in-the-loop controls. The person running the operation hears something simpler: Today, experienced staff inspect every request manually. With this system, routine requests arrive already classified with the evidence attached, while ambiguous cases are held for human review. Now there is something to evaluate. The buyer can ask how many requests are routine, how often the recommendation is wrong, and whether reviewing exceptions is materially better than reviewing everything. The offer has entered reality.

The change does not have to be dramatic, and this is where founders talk themselves into trouble. Once we decide the buyer is purchasing a change, we are tempted to make it enormous. The app no longer saves reporting time; it transforms client operations. A reasonably helpful application becomes responsible for modernizing an industry. Calm down. A small change is worth paying for if the situation makes it valuable, and precision is more persuasive than grandeur because precision gives the buyer something to compare with what happens today.

It also means the buyer may care about a different change than the one the founder finds most impressive. An application reduces a process from forty minutes to ten, so the founder emphasizes speed. Then conversations reveal that managers barely care about the thirty minutes; what they care about is consistency, because the old process produces different outputs depending on who performs it and senior employees spend time checking junior work. The product did not change when that was discovered. The interpretation did. A capable product usually creates several improvements at once, and the founder’s job is not to announce all of them at equal volume. It is to understand which change the intended buyer has enough reason to purchase. Once you can describe that change, a more detailed question appears. What, exactly, is included in getting the buyer from the current state to the promised one?

Offer Components

The change does not arrive by itself. Something has to connect the buyer’s current state to the promised one, and that something is the rest of the offer.

Suppose I tell an operations director that our software can reduce the manual work required for a recurring client report. Good. We have moved beyond “AI-powered reporting.” The director still has questions. Which reporting workflow does it handle? Does my team configure it, or do you? How long before the first report works? What happens when the source data is incomplete? Are we buying software, an implementation, or both? What help do we get? What does it cost, and what are we committing to? Why should I believe the result will look like the one you described? Those questions are not interruptions surrounding the offer. They are the offer. An offer is the set of conditions under which the buyer is asked to believe the promise is worth accepting: some combination of the buyer, the use case, the outcome, the scope, the path to useful value, implementation, support, terms, price, proof, and the risk the buyer believes they are taking on. I am deliberately not turning that into a twelve-box framework with an acronym. You already have enough software to maintain. The point is that if one of these pieces changes, the buying decision can change even when the application does not.

Scope is the clearest example. “We automate client reporting” sounds attractive until the buyer discovers it means one report type from one data source. That may still be valuable; the problem is an offer that let the buyer imagine broad scope and introduced the boundary only after enthusiasm had done some work. The opposite failure is describing every workflow the product could support, so the buyer has to determine which piece applies to them. A usable offer draws a boundary around what is being purchased.

Implementation changes the proposition just as much. One vendor says, “Create an account, connect your systems, configure the workflow, import the historical data, and contact support if you run into trouble.” Another says, “Send us the current reporting template and give us access to these two systems. We will configure the first workflow with you and have your team reviewing a live output next week.” The code could be identical. One asks the buyer to purchase software and become the implementation team; the other includes some of the work required to reach the result. Neither is universally right. Self-service fits a simple product with low setup cost; a service-heavy implementation can destroy the economics of a product that only works if thousands of customers onboard themselves. But for the buyer deciding today, the required work is part of what they are buying.

Time to value works the same way. “Save hours every month” says something about eventual value. “Your first automated report will be ready within seven days of connecting the required sources” creates a timeline the buyer can evaluate, and an obligation for the seller, which may be why the first version is more popular. Support belongs here too: a buyer of a trivial utility needs almost none, while a company changing an operational workflow cares a great deal about what happens when the integration fails at 4:45 on Friday before the report goes to a client. And terms alter the proposition: monthly access with the ability to cancel is different from an annual commitment, a limited pilot from a company-wide rollout, payment before evaluation from testing the relevant workflow first.

Price is part of the offer, obviously, but price only becomes interpretable once we know what surrounds it, and it gets its own chapter because founders have a remarkable ability to stare at a number while ignoring everything it is attached to. For now: five hundred dollars for login access to a tool you configure yourself is one proposition. Five hundred dollars for a defined workflow configured with you, producing a useful result this week, with support during the first month, is another. Same number. Different purchase. Proof and risk shift the proposition in the same way; a claim with a real example beside it requires less imagination, and a product that can run beside the existing process for two weeks asks for less than one that requires migrating years of data and signing a twelve-month agreement. The buyer is spending money, and also time, political capital, workflow stability, and their willingness to be responsible if the decision goes badly. None of that appears on the pricing page. All of it belongs to the transaction the buyer thinks they are entering.

This is why I become cautious when someone says, “We know people want the outcome. They just aren’t buying.” Before concluding that the buyer rejected the outcome, I want to know what else was bundled into the decision. Perhaps they wanted the result and disliked the implementation. Perhaps useful value arrived too late. Perhaps the contract asked for more commitment than the problem justified. Perhaps the proposition required so much work that the promised efficiency began by assigning them a new project. And quite often the improvement is subtraction: less scope, fewer options, a shorter commitment, one specific use case. The test is whether the buyer can understand what they will receive, what they must contribute, what changes if it works, and what saying yes commits them to. Once those pieces are visible, another question becomes unavoidable. The buyer is not evaluating your offer in isolation. They are comparing it with something.

Friction Belongs in the Offer

A better future can still be a bad purchase if getting there is miserable.

Founders describe the value on one side of the decision and treat everything required to reach it as implementation detail. The buyer does not have that luxury. Setup, migration, training, approvals, integration work, data cleanup, internal coordination, and the risk of disrupting an existing process are all part of what saying yes means. If the product saves ten hours a month but requires sixty hours of setup, that matters. If it reduces manual work for one team but creates a security review, a procurement process, an administrator role, and a training requirement for three others, that matters too. The friction may be justified. It is still friction.

Builders miss this because we live closer to the product than buyers do. We know which settings matter, why the integration asks for those permissions, and which warning can be ignored. What feels like “just connect your account” to the builder may mean finding an administrator, requesting credentials, asking security whether the connection is allowed, and discovering that the account owner is on vacation. Migration is the same. A product may be obviously better once a team’s information is inside it, and the buyer may still refuse to switch because the existing system contains years of messy records and undocumented conventions nobody fully understands. The buyer has not failed to appreciate the value. They may understand it perfectly and decide the transition is not worth the trouble. This is why “our product is easier” is an incomplete claim. Easier than what? Easier after setup? Easier for the daily user but harder for the administrator? A product can reduce operational friction while increasing adoption friction, and the founder controls more of the second than they realize.

Sometimes the right response is a product change: the setup really is too hard, the permissions really are excessive. But sometimes the product does not need to change at all. The offer does. A buyer who hesitates at “Import your existing customer records and configure your workspace” may respond very differently to “Send us your current export and we will load the first dataset with you.” The software did not become simpler. The purchase did. That does not mean every subscription should come with white-glove onboarding, which can turn a scalable product into a small consulting firm wearing SaaS clothing. The point is to account for the work honestly. If the buyer must do it, say so. If you can remove it, remove it. If you can absorb some of it economically, consider whether that changes the decision. If it is unavoidable, make the path through it clear enough that the buyer can judge whether the result is worth the effort.

Learning friction deserves the same treatment. A powerful application may expose dozens of options because the problem is genuinely complex, which is excellent design for an expert and homework for a new customer. The commercial question is whether the offer provides a credible route to the first useful result: a template, a preconfigured workflow, a narrow first use case, or even a clear statement of what to do first. The product may contain fifty things. The buyer does not need to encounter all fifty before receiving value from one.

There is also internal friction, which matters whenever software is sold into organizations. A person can want your product and still have to persuade someone else. They may need budget approval; IT may need to review an integration; a manager may ask what process is being replaced. If the proposition ignores those requirements, you are asking your internal champion to finish building the offer after the sales conversation ends, which is not a great handoff. You cannot anticipate every institution’s process. But common friction should not be treated as somebody else’s problem because it happens outside the application.

The test is to describe your offer from the buyer’s perspective and then add the sentence To get this result, the buyer must... and finish it completely. They must connect two systems, find an administrator, export historical data, train four people, obtain security approval, change an existing process. Whatever is true, write it down, and look at the combined proposition. Founders frequently sharpen the promise, clean up the page, and improve the demo while the buyer is still staring at three weeks of migration work. Sometimes the strongest improvement to an offer is not a bigger promise. It is a smaller burden. Once the burden is visible, the offer often improves by shrinking: less scope, a clearer first result, and a smaller commitment that can still matter.