Solution Selling

When products were explained as features, meetings ended as list-reading. Walk through thirty of them and the prospect says they're looking at other options too. So the next meeting adds three more features the competitor lacks.

That fight is hard to win. The moment you're compared on features, the buyer builds a table — features down the side, three products across the top, check marks in the cells. When the check marks come out close, the final decision goes to price. The work spent building one more feature comes back as a reason to discount.

Losing with more features happened just as often. The prospect has one real friction and the list has thirty items, so they can't pick which one touches it. Being unable to decide and deciding to wait are the same state, and a buyer in it will describe the meeting as having gone well.

Solution selling tries to change what the comparison runs on. Replace the feature-counting conversation with one about what this problem currently costs them, and the axis shifts from how many features exist to whether the problem actually goes away.

The sequence has five steps.

1. Form a problem hypothesis in advance. Write down what a company in this industry at this size is probably struggling with, before the meeting. For a company of a hundred-odd people that's document search time, approval-chain confusion, inheriting a departed colleague's files. Without a hypothesis, the first call drifts into vague questions.
2. Confirm it on the first call and turn it into a number. In a discovery call, where you learn the customer's situation and problems, check the hypothesis and count together how many hours the friction consumes. When the customer doesn't yet see their situation as a problem, draw it out with SPIN selling questions, which move through situation, problem, and implication in order.
3. Convert to money. Multiply two hours a week by headcount and hourly cost to get an annual figure. Run it through an ROI calculator the customer fills in themselves and the number stops being your claim and becomes their arithmetic.
4. Demo only against that problem. Of thirty features, use the four that touch it. The rest come out when asked. Every extra screen is another cell in the comparison table you were trying not to build.
5. Write the proposal as problem, solution, effect. The order matters. Lead with features and the frame built across the first four steps evaporates, and the reader builds the comparison table again.

The output of this sequence is one sentence: this company spends this much a year on this problem, and our product removes this much of it. If that sentence doesn't assemble, the steps were followed without the method being used.

Three conditions make it fit: the customer is already doing the work with something, the cost of doing it that way can be counted, and the contract is large enough to justify the conversation time. An existing approach gives you something to compare against; countability turns value into money. Miss either one and the conversation stays qualitative, which means it stays unpersuasive at the moment someone has to sign.

Three situations are a poor fit.

1. Low-value, fast decisions. Attach problem research and cost modeling to a $500-a-year contract and the hours exceed the revenue. Showing the screen and the price works better there, and the buyer usually prefers it.
2. Requirements the customer has already fixed. In a tender scored item by item, the criteria belong to the other side. Trying to move them puts you outside the scoring sheet.
3. Problems your product doesn't actually solve. Inflate a problem and then land halfway across it and the buyer goes looking for whatever covers the rest.

The limits are clear. Time per deal is long. Confirming the problem and building the numbers adds two or three calls, which lowers how many deals one rep can carry. That's why it's often paired with land and expand, the strategy of starting small and widening inside the organization: the first contract covers one team, and the scope grows once the numbers have been confirmed in practice.

Heavy dependence on the individual rep is the other limit. Hearing a problem and converting it to cost on the spot takes practice, so teams running this method write up problem lists and conversion formulas per industry, which is also what makes the approach survive a rep leaving.

"Don't build a feature comparison. Start by asking how many hours they put into that today."

A proposal to move the axis of comparison.

"This isn't a solution-selling deal. It's $500 a year and three calls would eat all of it."

Matching the method to the size of the deal.

"We made the problem big and we only solve half of it. They'll go find something else."

Pointing out how this method backfires.

At Pagedeck, Sofia uses it only on enterprise deals. Her first call asks one thing: whether there was a document last week they couldn't find. If yes, she follows with how often that happens and what they did each time. Two or three answers in, the prospect is describing the cost without having been asked about cost.

The arithmetic runs on a formula Ravi built. Headcount, hours a week, and hourly cost go in and an annual figure comes out. Forty-five people at two hours a week and $23 an hour gives about $110,000 a year. The rule is that Sofia never says that number first — the prospect fills the cells.

A common reading is that solution selling means accommodating everything the customer wants. It starts by listening, so it looks like taking down requirements. But the core of the method is selecting, not listening. Out of five frictions the customer named, you pick the one you genuinely remove and make that one large. Accept all five and the proposal reverts to a feature list, with promises in the contract that the product won't keep.

The other belief is that making the problem bigger sells better. A larger cost makes the price look small, which is plausible enough. But the size of the problem moves in lockstep with how much of it you remove. Convince someone that $110,000 a year is leaking and then say your product recovers $15,000 of it, and they'll ask what happens to the other $95,000. With no answer to that, the conversation moves somewhere that has one, which is how a well-run problem conversation can hand the deal to a competitor.