Entrepreneurship Lessons That Matter

I learned to trust this approach after seeing how easily enthusiasm disguises weak demand. People often agree that an idea sounds sensible because agreement costs them nothing. Their behavior tells you more. A customer who has lost working hours, paid for an imperfect workaround, or actively searched for a replacement gives you stronger evidence than someone who says, “That would be nice.”

The reader I have in mind owns a real business and has limited room for waste. You may serve customers directly, manage a small team, and make decisions from cash flow rather than a large research budget. You do not need a research department. You need disciplined conversations, a simple scoring method, and the willingness to reject an attractive idea when the problem lacks urgency.

The Problem-Intensity Scorecard

The Problem-Intensity Scorecard measures whether a problem deserves a solution. It combines four signals: frequency, cost, failed workarounds, and buying urgency. Each signal receives a score from 0 to 5. The total creates a practical starting point for your decision.

1. Frequency: Ask how often the problem occurs. A problem that appears every day deserves more attention than one that appears once a year. Score daily problems near 5 and rare problems near 1.

2. Cost: Measure the money, time, lost sales, stress, or risk the problem creates. A missed appointment that costs a service business $150 deserves a higher score than a minor inconvenience.

3. Failed workarounds: Find out what the customer already does. Customers who pay for several tools, assign staff to manual work, or tolerate repeated mistakes show stronger demand than customers who have never tried to solve the problem.

4. Buying urgency: Ask what happens if the customer does nothing for the next 30 days. Immediate consequences produce a higher score than distant or unclear consequences.

Add the four scores. A total from 16 to 20 indicates a strong problem worth testing with a paid offer. A total from 10 to 15 suggests that you should narrow the customer group or investigate further. A total below 10 usually means you should not build yet.

Use evidence, not polite opinions. “I would probably use that” earns no points. “I pay a receptionist three hours every Friday to confirm appointments” gives you evidence for frequency, cost, and an existing workaround.

You can test the scorecard with ten to fifteen conversations. Ask open questions before describing your idea: “Tell me about the last time this happened.” “What did you do next?” “What did that cost?” “Have you paid for anything to prevent it?” “Why did you keep or stop using that option?” These questions force the discussion toward actual events. If the customer cannot recall a recent example, the problem may not feel urgent.

Keep a simple table while you work:

| Customer group | Frequency | Cost | Failed workarounds | Urgency | Total | |---|---:|---:|---:|---:|---:| | Independent dental clinics | 4 | 4 | 5 | 4 | 17 | | Individual patients | 2 | 2 | 1 | 2 | 7 |

The first group shows stronger potential because clinics experience the problem repeatedly, lose money when it occurs, and already spend effort trying to control it. The second group may notice the problem but lack both the authority and urgency to buy.

The scorecard works because it separates appreciation from commitment. A customer can appreciate an idea and still refuse to change behavior. A customer who describes a repeated loss and accepts a paid test gives you a reason to continue.

A Paid Test Before a Product

Consider a local appliance repair business that wants to create an online booking system. The owner believes customers dislike waiting on the phone, but building software would cost several thousand dollars. The owner applies the Problem-Intensity Scorecard first.

1. Choose one customer group. The owner contacts 12 property managers who arrange repairs for rental units. Narrowing the group matters because a property manager handles many appointments, while a homeowner may book only once every few years.

2. Ask about recent events. The owner asks each manager about the last missed or delayed repair appointment. Nine managers describe a recent case. One manager explains that staff spent 45 minutes calling tenants and technicians after a technician arrived at the wrong time.

3. Record the current cost. Across the conversations, managers report two to six scheduling problems each month. The owner estimates an average internal cost of $90 per incident in staff time, tenant disruption, and repeat visits.

4. Identify current workarounds. Eight managers use shared spreadsheets, text messages, or manual reminder calls. Three already pay for scheduling software but still make phone calls because tenants miss automated messages. These workarounds show that the problem has survived previous attempts to fix it.

5. Score the problem. The owner assigns frequency 4, cost 4, failed workarounds 4, and urgency 4. The total reaches 16, which passes the initial threshold.

6. Offer a manual pilot. Instead of building software, the owner offers to manage appointment confirmations for three property managers for four weeks at $250 each. The owner uses existing tools and promises a weekly report. Payment matters because it tests whether the problem deserves a budget, not just agreement.

7. Review the outcome. During the pilot, the service prevents 11 missed appointments and saves each manager roughly four staff hours. Two managers renew for another month, and one asks for a longer contract. That evidence supports building only the features that the pilot required.

The expected outcome is not a perfect product. The expected outcome is a clearer decision. If nobody pays, or if customers stop using the service after one week, the owner learns that the problem may not justify software. That lesson costs far less than building an unused platform.

Quick checklist

• Select one customer group with a repeated version of the problem. - Interview 10 to 15 people about recent incidents, not general opinions. - Record frequency, cost, workarounds, and consequences of inaction. - Score each category from 0 to 5. - Reject vague answers as evidence. - Test payment with a manual service, deposit, preorder, or paid pilot. - Build only after customers show repeated use or renewal.

Finish this test within two weeks when possible. A short deadline prevents endless interviewing and keeps the work tied to a decision. You are currently in the evidence phase: measure the problem before you design the answer.

Mistakes That Distort Demand

Counting compliments as demand

Customers often encourage business owners without intending to buy. They may like the idea, support your effort, or avoid an awkward refusal. Compliments do not prove urgency.

Do this: Ask for a recent example, the current workaround, and the amount paid to handle the problem. Request a deposit or paid pilot when the conversation supports it.

Not this: Treat “I would use that” as a confirmed sale.

Building before testing the manual version

A polished product can hide weak demand. It also creates pressure to defend the investment, even when customers do not return. A manual version exposes the real work and lets you test the result with less risk.

Do this: Deliver the outcome using a spreadsheet, phone calls, existing software, or a simple payment link. Track what customers request repeatedly.

Not this: Spend months adding features before one customer pays for the basic result.

Scoring the wrong buyer

The person who experiences a problem may not control the budget. An employee may complain about scheduling, while the owner decides whether to pay for a fix. If you interview only the user, you may overestimate demand.

Do this: Speak with the user and the buyer. Compare their scores, then confirm who approves payment and what evidence that person needs.

Not this: Assume the loudest complaint comes from the customer who will purchase.

Your immediate action is simple: choose one customer group, list its most expensive recurring problem, and schedule ten conversations within the next seven days. Complete the Problem-Intensity Scorecard before you name features, hire developers, or order equipment. A profitable business begins when a real customer has a costly problem and a clear reason to pay for relief. That discipline gives every later entrepreneurial decision a stronger foundation.

End of chapter one. 7 more chapters in the full book.