Tell me if this sounds familiar: Three minutes into your first coaching session with a team, you learn they are heads-down focused on finishing their MVP with a target release date four months from now. And they haven’t yet talked to a single customer.
So, you immediately interrupt and tell them that they should have ideally started with customer interviews and validated their problems before building out a solution. You try and convince them to stop building and course-correct.
Here’s how that plays out:
You: Starting with a solution is too risky. You're back to the drawing board if it fails to solve a real customer problem. That’s why I suggest you pause building and spend some time first running a few problem discovery interviews.
Them: We know the problems already. We started building this product because we experienced these problems ourselves in our work. Also, we did reach out to a few friendly customers and pitched them the solution. They loved it and can’t wait to start using it. That’s how we validated the problem is real.
You: Talking to friendly customers is a good start. But you have to factor in the fact that they might be slightly biased because they know you already. More importantly, though, customer interviewing isn’t about pitching but learning from your customers. Are you familiar with the problem/solution fit process using customer interviews?
Them: Yes, we’ve read all the books like Running Lean, The Mom Test, and Talking to Humans. And we completely understand the importance of starting with problems with some products. But our product is different.
You: Why is that?
Them: Our product is solving an obvious problem with a non-obvious solution. People will need to see it in action to believe it. Most of the examples in these books are B2C products that you can quickly test with customers. Ours is a more complex B2B product — at a higher price point aimed at more sophisticated customers. We can’t simply create a landing page and run ads.
You: Yes, the books cover more B2C examples because they are more relatable, but the principles apply even to B2B products. Let me send you a few B2B case studies that you can review. Let’s regroup after that and see what you think.
Them: Interesting… Yes, please send them over, and we’ll take a look.
You never hear back from them ever again.
What just happened?
You Can’t Lecture Your Way Around Cognitive Biases
You just tried to argue through a series of cognitive biases and lost. We all have cognitive biases that we unconsciously employ to justify what we already want to do over what we need to do.
The real kicker is that intelligence makes matters worse.
According to behavioral scientist Daniel Kahneman, the smarter you are, the more prone you are to cognitive biases.
Reasonably smart people can rationalize anything. Entrepreneurs are especially gifted at that.
In the scenario above, the team wants to build out an MVP, and some of the biases at play are:
- The Innovator’s Bias: Build a great solution, and customers will come.
- The Visionary Bias: People will not understand what we are building unless we show them a finished product.
- Survivorship Bias: None of the companies we admire, like Apple, ran customer interviews. So why should we?
- Confirmation Bias: We have this problem, and so do others. They told us so.
- Sunk Cost Fallacy: We can’t afford to lose momentum now by slowing down product development.
- Probability Bias: Yes, most startups fail. But we are different.
Also, the team is aware and well-informed of new methodologies and techniques for testing ideas. However, they don’t think it applies to them. Lecturing here rarely works. If you push too hard, the team disengages and does what they want without you.
Is there a better way?
Yes, let me outline my 3-step process next:
- Start by baselining the team and their business model
- Use a traction-driven approach to identify what’s riskiest in the business model
- Trigger the team to change course (if needed)
1. Start by baselining the team and their business model
“Seek to first understand, then be understood.”
- Stephen Covey
In the scenario above, there’s a lot of missing context that might warrant a different course of action. Instead of rushing to prescribe what a team needs to do, you should first conduct a complete diagnosis. Remember that everyone, including us coaches, is prone to biases.
My favorite tool for this is using a Lean Canvas + 5-minute backstory.
This is how I conduct all my first coaching sessions with teams.
- Before the session, I ask them to spend no more than 20-minutes capturing their idea on a Lean Canvas and sending it to me.
The reason I give them: So we can hit the ground running. I emphasize the importance of taking a snapshot versus creating a perfect model. And to skip any boxes they don’t understand. - When we start the session, the first 5 minutes are theirs. I ask them to put their Lean Canvas on the screen and walk me through their idea — not by reading their Lean Canvas, but by sharing their backstory and progress-to-date.
I specifically want them to focus on - Origin story: How did the idea get started?
- Team: Who’s involved?
- Traction: How many customers (if any) do they have?
- Goals: What are they trying to achieve in the short-term and long-term?
- Risks: What’s keeping them up at night?
- After the initial intro and setup, I let them talk and only speak to ask a clarifying question when I want them to elaborate on a point further.
What’s going on here?
First, letting the team go first disarms them and lets them get everything out in the open. They feel heard, which builds trust. More importantly, it lets you understand how they think.
While they present their idea’s backstory and progress-to-date, I actively listen to
a. Baseline their business model,
b. Understand their chain of beliefs
c. Rank their chain of beliefs
Let’s walk through this in more detail.
a. Baseline their business model
Before you can identify what’s riskiest in a business model, you need to understand the complete business model. No two ideas and teams are the same. The same idea with a different team can surface different risks.
A Lean Canvas only provides a high-level overview of the business model and was never intended to be a standalone document. It doesn’t include vision, mission, or team details — all of which are important to understand.
Also, since it’s a single snapshot in time, it misses timeline and progress context (metrics, what’s been done, etc.).
This is exactly why I ask the team to fill in those details in their 5-minute walkthrough. You’ll find that what they say often differs from what they captured on a Lean Canvas. You need both narratives to build a complete picture.
When the team outlines their goals or assessment of risks, I don’t challenge any of it at this point. I am simply in discovery mode with a mission of baselining their business model.
b. Understand their chain of beliefs
All ideas are built upon beliefs that stack upon one another like blocks in the game of Jenga. The foundational blocks constrain and shape the idea. Also, any faulty or weak assumptions in the foundation have ripple effects.
By paying attention to the idea’s backstory and the words the team uses, you can reconstruct this chain of beliefs.
The idea backstory is far more revealing on the chain of beliefs than a Lean Canvas or idea pitch.
For instance, from the origin story, I can determine if this is
- a solution-centric idea (e.g., technology-driven),
- a revenue-centric idea (e.g., growth-driven),
- or unfair-advantage-centric idea (e.g., invention-driven)
While good ideas can come from anywhere, knowing the idea source helps to understand the situational biases that often accompany it.
From the words the founders use to describe their idea, I can often determine if they are more
- hacker-oriented (e.g., technical),
- designer-oriented, or
- hustler-oriented (e.g., marketing/sales).
This helps to understand how the team naturally thinks and the language they use.
c. Rank their chain of beliefs
The reason I ask clarifying questions along the way is to understand the empirical depth of their key assumptions. For instance, I might ask how they know that their customers have a particular problem or where their pricing model came from.
My goal is to categorize their beliefs into one of three buckets:
- A leap of faith (no evidence)
- An anecdotal observation (some evidence)
- A fact (backed by lots of empirical data).
2. Use a traction-driven approach to identify what’s riskiest in the business model
Too many people rely on intuition and experience alone to identify what’s riskiest in a business model.
Pardon the pun, but this is too risky.
There’s too much at stake when you rely solely on intuition — no matter how experienced your intuition is.
Startups are in the business of defying status quo thinking.
Instead of intuition, you need a systematic approach to uncovering what’s riskiest. All businesses share a universal goal: To create happy customers. The traction question above is key to uncovering what’s riskiest.
If the startup has no customers, the key propelling question to uncovering what’s riskiest is asking what’s holding them back from creating their first ten customers.
If the startup already has customers, the key propelling question to uncovering what’s riskiest is asking what’s holding them back from creating their next ten customers.
This systematic approach is built on the Customer Factory mental model. I’ll cover this in more detail in a future post. For some context, until then, you can read The Customer Factory Manifesto.
3. Trigger the team to change course (if needed)
If the team is already focused on the right risks, we discuss possible right actions to employ (tactics) for achieving their business model objectives (more traction).
Most teams, however, prioritize their riskiest assumptions incorrectly. Instead of telling them that (lecturing), you have to figure out the most effective way to get them to discover it themselves.
You do that through a triggering event.
All change starts with a triggering event.
Sometimes that triggering event can be delivered through logic. For example, making a case for establishing repeatable sales before pursuing growth tactics.
Other times, it’s a function of the environment. For example, the team is running out of money and now open to trying anything.
Yet, other times, you have to carefully devise an experiment to trigger the team. The best experiments align with what the team wants versus what you think they need.
For example, instead of telling the team in the scenario above to conduct weeks of customer interviews (something they don’t want to do), tell them that complex sales have long sales cycles and offer to help them build a pipeline of early-access customers through a direct sales process (something they want).
Complex sales often follow prospecting, discovery, demos, then commitments to either a prototype or pilots. Even though the word interview doesn’t appear here, you are essentially interviewing customers during discovery and demos.
Running sales (acquiring customers), however, aligns with what the team wants, and so they go along. Any unexpected outcomes, like their inability to set up calls (channel risk), deliver compelling demos (uvp, problem, customer risks), or secure commitments, will serve as effective future triggering events.
What’s different this time is they discover it situationally versus hypothetically. This difference makes all the difference.