Problem-solution fit: a solution is not a product

A solution is a general answer to "how could this work better?": remind regulars when their service is due, use software instead of a notebook. It's useful for choosing a direction, but nobody can use it on Monday morning.

A product is the same idea made concrete. It names:

• who does something (the administrator at the counter, not "the shop");
• when they do it (at hand-over, while the car owner waits);
• with what (a phone form, ten seconds per car);
• what the customer gets (a Viber message under the shop's name 30 days before the service).

The customers paid for a result: regulars who come back. A solution is one route to that result; a product is the route drawn on a real map of someone's day.

A right solution can still fail as a product. If nobody has a moment to feed it data, it has nothing to send. Problem-solution fit means both at once: the solution solves the problem and fits the customer's working day.

To check whether a solution fits, walk through a real working day with the people who would use it. Good questions are about steps that already happen:

• "What happens at the counter when a car is handed back?"
• "Who writes down the mileage, and where?"
• "How do you tell regulars it's time for a service today?"

Each answer shows a moment when data appears, a person who could enter it and the tool already in their hands. At Greg's shop that walk-through showed that the mileage is known exactly once: when Martha writes the invoice on her phone while the owner waits.

Questions about features don't do this. "Would you like a reminder feature?" invites a polite yes that costs nothing. "How much would you pay for an app with ten features?" asks someone to price an imaginary thing. Both answers feel encouraging and tell you nothing about whether anyone has ten free seconds for your product.

When a shop has no system for bringing regulars back, it's tempting to think the field is empty. It isn't. Doing nothing is a competitive alternative, and often the hardest one to beat.

Doing nothing costs no money, no setup and no new habit. Its price is hidden: regulars who forget and drift to another shop. To win, your product has to make that hidden loss visible and then cost less in time and hassle than the shop's current zero effort.

That changes the questions you ask:

• How many regulars came back last year without a reminder, and how many didn't?
• What would an extra returning car be worth to the shop?
• How many seconds a day is someone willing to spend to get it?

If the honest answer is "not even ten seconds", reminders lose to doing nothing, however good the code. So list "nothing" next to the notebook and the sticker every time you compare candidates.

Every problem a customer has already has some answer, even a clumsy one. That answer is the competitive alternative: what the customer does today instead of buying your product. For bringing regulars back it might be:

• a relative calling from a notebook (4,000 UAH a month, stops when she's busy or ill);
• a windscreen sticker with the next service mileage (cheap, but the driver stops seeing it and the shop can't see who is due);
• hand-typed Viber messages, or nothing at all.

Your solution has to beat that alternative on time, money and hassle, from the customer's point of view.

Compare several candidates side by side, including the ones people use now. Each has a weak spot, and so does the one you want to build: automatic reminders depend on someone entering cars. Comparing isn't about finding a perfect option. It's about choosing the weak spot the customers can live with, and then designing hard around it.

Once you have a candidate, take it back to the people who will live with it. The aim of solution validation is to find out what would go wrong, not to win a yes.

The technique is simple:

• describe what it would do, step by step, in the customer's own world: "Martha enters the mileage at hand-over, 30 days before the service a message goes out under your name…";
• then stop and listen for "that won't work here, because…".

That sentence is worth more than any compliment. It points at a real step you haven't seen: a sold car whose new owner would get someone else's reminder, a car owner who hates being spammed, a niece whose job the reminders would quietly take away.

A pitch does the opposite. Promising a result ("30% more regulars!") and asking "want it?" invites politeness and hides every one of those problems until after launch, when they're expensive to fix.

In a small business the person who decides and pays is often not the person who uses the product every day. At Greg's shop, Greg chose GarageDesk and paid for it. Martha, the administrator, is the one who would enter each car.

That matters because a reminder system is only as good as its data. The mileage is known at one moment, hand-over at the counter, with the owner waiting. If entering a car takes Martha more than a few seconds there, she'll skip it, and Greg's money buys an empty system.

So design the input around the user's moment, not the buyer's picture of it. Nina first imagined Greg filling in his client list once a week; Greg doesn't even know the mileage of half the cars.

Ask two separate questions in every conversation: who decides to buy? and who touches it every day, and when? Talk to both. A buyer can say yes to a product that its users will quietly stop feeding.

Two kinds of fit are easy to confuse.

• Problem-solution fit: customers agree the problem is real, and a specific solution fits their working day. You show it with conversations, walk-throughs and a choice between candidates, before or while you build. At GarageDesk it looked like this: all five prepaid shops picked reminders over call lists and stickers, once Nina's design fitted Martha's ten seconds at the counter.
• Product-market fit: enough customers keep using and paying for the product month after month, and new ones arrive without heroic effort. You can only see it later, in retention and payments, after launch.

The first is a precondition for the second, not a promise of it. Five shops choosing a design says the design is worth building. It doesn't say they'll still pay in month six, or that a hundred other shops want it. Claiming product-market fit from a few good conversations is a common way to stop listening too early.

The three questions turn into a short routine you can run before writing any code:

1. Write down the result customers paid for (regulars come back), not the feature you have in mind.
2. List several candidate solutions, including the clumsy ones people use now: automatic reminders, a monthly call list, better stickers.
3. Walk through the working day with the people who would use them: who has the data, at what moment, with what tool.
4. For each candidate, ask what it replaces and what it could break: the cost of the current alternative, and new problems such as spam, sold cars or someone's lost task.
5. Pick one and define the exact moment and person that feed it.

The order matters. Candidates come before the walk-through so you judge them against a real day, not against your favourite. Risks come after you know the day, because that's where they hide. And the last step, naming the person and the moment, is exactly what turns a solution into a product.