Opinion · Scientist, Entrepreneur, Businessman
What mentoring more than 30 founders taught me
I want a founder to be able to test a risky idea and still have the money and time to make another decision.
I have mentored more than 30 founders whose businesses are at different stages. My scientific training helps me ask what an idea predicts and what evidence would make me reconsider it. Mentoring has taught me to consider how I raise that question. A founder can act on a challenge when we name the assumption and ask what would change our view.
Five lessons I take into a founder conversation
- Start early. Try a small version of the offer before you commit to building it. Show the customer what they would have to do, pay or give up to use it. Early feedback leaves room to change the offer.
- Expect mistakes you can afford to repair. Keep a first order small enough that replacing it would leave you time and cash to try again.
- Challenge what you are doing. Ask what would make a customer stick with their current way of working. Invite someone who doubts the proposal to explain which evidence would change their view. Give them room to disagree before you decide.
- Try to kill your startup on paper. Make a habit of looking for the assumption that could end the business. Test it while you can still change course. This is the exercise behind Kill My Startup.
- Understand the customer. Ask how the person solved the problem the last time it came up. Their reason to switch may differ from the one you put in your pitch. The answer should help you decide which part of the offer to test first.
This is where People First, Problem Second, AI Last comes into my work. Begin with the person and the task they need to complete. Decide what would make that task easier before you pick a tool.
What the odds of three failures can teach us
Imagine three attempts, each with a 50% chance of failure. Assume the outcomes are mutually independent, so the results of the other attempts do not change the chance that any one fails. Multiply one factor of 0.5 for each attempt to find the chance that every attempt fails. Two failures in two attempts have a 25% chance. Three failures in three attempts have a 12.5% chance.
The chance of failure on the third attempt alone remains 50% in this example.
Repeated tests can share the same weak point
Suppose a founder tests several prices with customers recruited from a single group. A weak response across the tests may reflect who saw the offer. Repeating that setup can leave the founder with little evidence about customers who buy through a different channel. If the team changes the recruitment method or the offer after each attempt, it may also change the chance of each outcome.
The product rule follows from the stated assumptions. Applying it to a startup would require evidence for those assumptions. I use the comparison as a qualitative business analogy. After a weak result, check what your next test shares with the first before you repeat it.
Put the pickup service in front of a buyer
Consider a hypothetical founder planning a pickup service for small shops. Before building a booking app, the founder could ask a shop owner to show how they arrange a pickup today. If the owner already has a reliable courier, the test might focus on whether the new service can collect parcels during a busy period at a price the shop would pay.
The founder could offer one paid pickup with a manual booking. Confirm the pickup window and price before asking the owner to commit. If the owner pays, keep a record of the time and cost to complete the job. If the owner declines, ask which part of the offer made them stay with their current arrangement. The evidence will be specific to that shop and offer.
Write down what would make you change course
Before asking for advice, write down the customer, the assumption you most need to check and the smallest test that can give you an answer. Add the most you can spend, the date you will review the result, and what observation would make you continue, revise or stop.
Show the note to the person who will challenge it. Ask them to point to an outcome the team might explain away. Agree how to record that outcome before the test begins. At the review, put what the customer did beside what the team expected. Keep the two statements separate when you decide what to try next.
Sources and scope
The mentoring count and five lessons come from my account for this series. The examples teach a method and contain no founder records. See the author-source summary and my earlier account of mentoring through incubators.
For independent trials with fixed probabilities, see University of Illinois Math 461 course notes on independent events. For related work, see StarApple AI and the first article in this series.