Choosing one problem

When several problems pass the rule, a feeling isn't enough. Put the finalists side by side and ask each the same questions:

1. How often does it happen?
2. Who already spends on it? The share of shops that have the problem and already pay in money or hours.
3. Does the person who pays feel it in money?
4. Can the customer see the result? Something an owner can count.
5. Can you build something useful in weeks?

GarageDesk's two finalists:

• Frequency: phone chaos (A) happens every day; a forgotten service (B) comes every few months per car. A wins, honestly.
• Spending: A, 4 of the 11 shops that mention it; B, 6 of 9. B wins.
• Payer feels it in money: Greg counts lost regulars as lost revenue; phone chaos mostly bothers Martha and Paul. B wins.
• Visible result: a car that comes back after a reminder can be counted; "fewer calls" is hard to prove. B wins.
• Time to build: reminders need a client list, dates and a way to send; booking also needs car owners to stop phoning. B wins.

Note where the other problem wins: it keeps you honest.

Counting wins is a useful start, but criteria don't weigh the same at every stage. The question is: what does the business need most right now?

GarageDesk has no paying shops and Nina's runway is counting down. What matters most is shops paying soon. That puts the heaviest weight on:

• money already spent on the problem, because a shop that already pays for a workaround can switch its budget to you;
• a result the owner can count, because that's what he's paying for and what keeps him paying.

Frequency matters too, but less at this point. A problem that happens every day yet costs the owner nothing he can see is hard to charge for.

So B wins not because it takes four columns out of five, but because it wins the columns that matter most now. If GarageDesk were already profitable and looking for daily engagement, the weights might shift toward frequency.

Things that should carry no weight: which idea is easier to explain to investors, which one a founder always wanted to build and which one a relative recommends.

A decision that lives only in a conversation fades fast. In a month, when shops start asking for online booking, nobody will remember exactly why B won, and the choice will be reopened by whoever argues loudest that week.

So write it down the day you make it, in a few lines:

• the date;
• the choice: problem B, regulars who forget their next service;
• the two or three main reasons, with numbers: 6 of 9 shops that have it already spend on it, against 4 of 11 for A; owners can count the cars that come back;
• who decided: Nina, because product is her call under the founders' agreement;
• what's parked, and the date to look at it again.

This note does two jobs. It protects the decision from pressure that isn't new information: a loud customer, a relative's opinion, a bad week. And it makes a real change of mind easy, because you can see exactly which number would have to change to flip the choice.

A spoken "let's go with B" and a quick start feel faster, but the time is lost later, re-arguing the same choice.

After committing to one problem, requests for the others don't stop. A shop asks Oscar for online booking; another wants repair history. Each request is tempting to treat as a sign that the choice was wrong.

The useful response is the same every time: "not yet", then write it down. Over a month the notes turn into a number you can use on the date set to look again:

share asking = shops that asked for it ÷ shops you talked to × 100%

Example: in January Oscar talks to 40 shops and 3 of them ask for online booking. 3 ÷ 40 = 0.075, so 7.5%. That's a fact to compare with something, for instance with how many of the same shops already spend on reminders, instead of a memory of "people keep asking for booking".

Two cautions:

• divide by all the shops you talked to, not only those who asked for something;
• an ask isn't spending: "it would be nice to book online" is a mention, and mentions are cheap. On the review date, check whether those shops spend on the problem too.

Choosing a problem means little unless the next weeks change because of it. Committing has three practical parts, for a set period such as two months:

1. Everything serves the chosen problem. The conversations, the pre-sale and the first version are all about bringing regulars back with reminders.
2. The other problems go on a "later" list with a date to look at them again. A, online booking, and C, repair history, aren't deleted; they wait.
3. Requests for parked ideas are counted, not acted on. When a shop asks for booking, the answer is "not yet", and the request becomes a line in the notebook.

Two things quietly break a commitment:

• building "just in case": online booking at weekends splits a two-person team's attention exactly when focus matters most;
• promising parked features: "booking arrives in March" turns a parked idea into a deadline nobody chose and might sell a shop something that won't exist.

A commitment is also what makes the result readable. If two months of effort go to one problem, you'll know whether it worked. If they go to three, you won't.

Committing to one problem can feel like throwing the others away. It isn't. Choosing one problem decides the order of work, not the final scope of the product.

The parked problems often belong to the same customers. Online booking and repair history serve the same independent repair shops as reminders. Once reminders pay and the first shops trust GarageDesk, those features can become parts of the same product, sold to people who already know you. That's usually easier than starting with them.

Each parked idea gets a date to look again, and dates differ:

• online booking and repair history: soon, because shops already ask about them;
• the mobile app for car owners: far away, because it serves people who don't pay GarageDesk and belongs to a rung the company hasn't reached.

What the order protects is the next few months. A small team that builds three things at once usually finishes none of them well enough for a shop to pay. One problem first, the others later, is how a bootstrapped product grows into a broader one.

A month after choosing B, booking requests may pile up. That's exactly the moment the written decision and the request count were made for.

What to do depends on when and what you know:

• Before the review date: keep the commitment. Say "not yet", log each request and carry on. A pile of requests is a reason to look carefully on the date, not to switch in the middle of the period.
• On the review date: open the decision note and the count. Compare the requests with what made B win: how many shops already spend on reminders, how many paying shops B has brought, how many of the shops asking for booking also spend on that problem.
• If the numbers have really changed, change the plan in writing, with the new reasons and a new date. That's a decision, not a drift.

Two responses to avoid: switching to booking the moment requests grow, which throws away the period's work before it can show a result, and ignoring the requests forever, which turns a parked idea into a forgotten one.