Most founders do not start with a ‘customer problem’. They start with an idea. Sometimes, it is a technology they are excited about, or a workflow they personally dislike and get annoyed by every day. It might also simply be the conviction that an industry must be ready for a change. That is understandable, of course, but it is also dangerous. A product doesn’t become valuable because it’s clever or well-built, or because it is technically impressive. The former may be partly a reason, yes, but it becomes truly valuable because it solves a problem that is painful enough, frequent enough, and expensive enough that somebody wants it fixed now. 

 

That is the only starting point that matters. 

 

If you are building in B2B, this is even more important. Companies buy a product that promises, to an acceptable extent, that it will help them make money, save money, reduce risk, be more efficient, or reduce friction from a process that is already important but not working at peak efficiency. 

 

So, your first job as a builder is to learn. You need to understand who has this pain, where it is, how often it appears, what it costs, and why existing solutions aren’t quite hitting the mark. Pain is the beginning of the product, not an afterthought.

 

This is where many startups lose months, or even years. They make the assumption that the discovery stage is informal, where having a few conversations or positive reactions, and maybe a pilot, is enough to go into product mode. Going into product mode without being clear on the pain that needs solving means you are working the wrong way around. 

 

“We thought that everybody could benefit from this product. So, we decided, why not? Every website would have it. But from those metrics, adoption was lackluster… Revenue was terrible. Nobody wanted to pay for it. The problem wasn’t real.” - Mati Staniszewski, ElevenLabs

 

The companies that get to product-market fit faster are usually not the ones with the best initial ideas, but the ones that learn faster than everyone else. They identify the pain earlier, and they narrow their customer focus sooner. So, they stop wasting time on attractive, but unsupported signals. 

 

That is what we’ll be exploring throughout this chapter: how to find the pain that is actually worth building around, and how to do it with enough discipline that you are working with real tools instead of informal positive feedback. 

​

Why founders get this wrong

The most common mistake is painfully simple. Founders overestimate the value of their intuition. It’s in our nature - all of us - to believe that our ideas and our gut feeling are correct. 

 

We want to believe! 

 

Intuition is not useless. In fact, most strong companies begin with some form of informed intuition. You may have worked in an industry for years and seen a broken process up close, or you might have built infrastructure and realized that a new capability had become possible. Perhaps you experienced a problem directly and assumed that others had it too. All of those are valid starting points, but they are only starting points. A hypothesis is not a market. 

 

This is especially true for technical founders. If you have spent years building systems, you are trained to respect elegant solutions. You see what is possible before most people do. That can be a strength, but it could also quickly become a trap. You start with the tech, and then you go looking for the reasons the market should want it. The logic makes sense to you, but customers do not follow that logic. They don’t buy logic either. They buy relief from pain. 

 

Many good products fail because the pain was not painful enough. Others fail because the pain existed, but not for enough similar companies. Others still fail because the person who felt the pain could not actually buy the solution. All these mistakes have one common root cause: weak discovery. So, the first shift in mindset is that your initial belief has to earn the right to survive. Do not protect your gut feeling, test it. 

 

“Because if it doesn’t work for one customer, the rest is just a theory.” - Marcel Gordon, Helsing

 

Start with what you know, but don’t stop there

Most successful B2B products begin from one of two starting points. 

 

The first is domain knowledge. You have worked in an industry, function, or workflow long enough to recognize recurring frustration. You know where the delays happen. You understand where people use spreadsheets as a workaround or where manual effort piles up. You know where the systems do not talk to each other, leading to silos. You can pinpoint where reporting isn’t working well, where quality drops, and so on. This is a strong starting point because you already understand some of the context instead of guessing from the outside. 

 

The second is technological leverage. You know that a technical capability now exists that did not exist before, or has become affordable enough to use commercially. That might be a new AI model or capability, a new infrastructure layer, a new hardware capability, a new interface, or a new way to automate work that used to be manual. In this case, your challenge is different. Since you don’t know (yet) what the strongest pain is, you have to go find the workflow where this capability matters enough to change behavior and justify the budget.

 

Both paths can indeed work, but they also both require the same discipline afterward. 

 

If you come from the domain side, do not assume that because you ‘lived’ a problem, many others feel it with the same urgency. Sometimes, the pain is real but too narrow, too specific for a market to really exist. Sometimes, people have found ways to work around the pain, meaning they won’t be willing to pay to resolve the pain. Or, sometimes the problem is experienced by a junior user who complains a lot, but who has no actual buying power. And at times, the problem is temporary and anecdotal - a specific employer, and not an entire market. 

 

If you come from the technology side, do not assume that the most ambitious use case is the one people care about most. Founders will usually imagine a transformative future application, while the market is looking for a much simpler fix to a much more immediate workflow problem. Yes, the bigger vision may still be right in the long run, but it’s rarely the entry point. 

 

The market usually rewards urgency before it rewards ambition. That’s why your first task is to turn what you know into a testable hypothesis. 

 

“It’s not that customers came and said, well, you need to build a new database. It was more that these continuous issues that were accumulating with customers were piling up.” - Manuel Haug, Celonis

 

Form a real hypothesis

Before you start talking to people, write down precisely what you believe. 

 

You need at least three things:

 

1. The pain

2. The person

3. The company

 

First, the pain. What is the specific problem? In which workflow does it appear? What actually happens when the problem occurs? What gets delayed, lost, mispriced, missed, or done manually that should not be?

 

Second, the person. Who feels this most directly? What is their role? How senior are they? What are they responsible for? What metrics, pressures, or priorities make this painful for them?

 

Third, the company. What kind of organization are you imagining? Which industry, size, geography, maturity, complexity, or software environment makes this problem more likely to exist?

 

This makes up your first working hypothesis. It will almost certainly not be fully right, but if you don’t write it down, you cannot test it properly. You will drift from one conversation to the next, collecting anecdotes and impressions without knowing whether they confirm anything. 

 

A founder without a hypothesis usually ends up doing one of two things. Either they talk to everyone and learn nothing clearly, or they hear one enthusiastic reaction and treat it as proof. Neither is discovery. Good discovery starts with a position, then it exposes that position to reality. 

 

Find the right people, not just available people

Once you have your hypothesis, the next step is to talk to people who match it. 

 

This sounds simple, but it’s where a lot of confusion and superfluous information can enter the process. Founders are often so eager to get conversations that they start talking to anyone adjacent to the problem. Someone in the same industry, or with a similar title, senior enough to be interesting, and so on. This can lead to a lot of information, but with very little clarity. You need comparable conversations. 

 

There are two common routes into the market. You can start with people or with companies. 

 

If you start with people, you look for individuals who appear to fit your assumed buyer or champion profile. The advantage is speed. You can use your network, introductions, LinkedIn, alumni groups, communities, or cold outreach to reach people with the role you think matters. The disadvantage with this approach is that titles often hide important differences. In other words, two people with the same title may operate in completely different environments and care about very different things! 

 

If you start with companies, you first define the type of organization you think is likely to have the pain. Then, you look inside those organizations for the right individuals. This can be slower, but it usually gives you a better foundation for pattern recognition because the context is clearer. 

 

Both routes are fine. The important point here is that you need to be intentional. If you are too broad in the beginning, every conversation will sound slightly promising, but nothing will repeat. 

 

Repetition is what matters. 

 

“We made sure we don’t build for one customer, but for at least two or three, because the danger, of course, is you overfit in one customer.” - Maximilian Eber, Taktile

 

When you start hearing the same language, frustrations, failed attempts at solutions, commercial constraints, and so on, you are getting closer. When every conversation is interesting but different, you are probably still too broad. 

 

Not all pain is commercially useful

One of the most important lessons in discovery is that not every problem that sounds frustrating is worth building a company around.

 

Some pain might be real but infrequent, or frequent but minor. Some might be severe but isolated to one specific kind of company, while others might be widely shared but with no budget attached to it. This is why founders have to separate inconvenience from urgency. 

 

A good B2B pain point usually has several characteristics:

 

• It appears often, ideally daily or weekly rather than once or twice a year. 

• It affects more than one person, because single-user pain rarely supports a meaningful budget. 

• It has a measurable commercial consequence, whether in revenue, cost, time, compliance risk, error rate, lost opportunities, or customer experience. 

• It is top of mind, which means the person can explain it quickly without needing help from you. 

• In many cases, the company has already tried to solve it somehow, which is a strong sign that the problem is not theoretical.

 

Pain becomes commercially useful when it changes behavior. 

 

That is the standard. If the problem is serious, people usually do something about it. So, they’ll build manual workarounds or hire extra people. They accept inefficiency because they have no better option. These are signs that the pain is significant and has ‘weight’. 

 

On the other hand, if the person says, ‘Yes, that is definitely a problem’ but nothing has ever been done about it, you need to be careful. That may still become a market, but it is not yet strong evidence. 

 

There’s a huge difference between interest and urgency, yet many founders mistake informal validation for demand. They hear ‘that sounds interesting’ and it confirms their idea is the next unicorn. It is not. It is only progress if the problem is important enough that somebody wants to keep talking, involve colleagues, share data, or discuss implementation.

 

“Part of the product design work is finding out what the actual problems are and getting a first read on whether what you’re building would actually be accepted.” - Christopher Kränzler, Aleph Alpha

 

The pain is usually more mundane than the vision

Another recurring pattern in discovery is that founders imagine the most exciting use case while customers care about the most immediate one. 

 

That is normal. Founders are drawn to leverage. They see what the technology could unlock at full maturity. Customers, in the meantime, are trying to get through the week. They don’t wake up thinking about your category. They wake up thinking about the work that is slow, messy, frustrating, and expensive right now. Markus Müller, from Flinn, illustrates this well:

 

“I ask what’s a waste of time. Across those answers, we heard the same three things again and again and again.” - Markus Müller, Flinn

 

So when you talk to the market, do not be surprised if the strongest signal comes from something smaller than your original vision. That does not mean your vision was wrong, but rather that your entry point was wrong. 

 

This is important because the first product doesn’t need to capture the full future! It needs to solve a problem well enough that a company will buy, use, and expand from there. Many companies start by solving a narrow but painful workflow, then grow into the broader category later. That is often the smarter path anyway. It reduces complexity and it improves the learning speed. Importantly, it also forces you to build around real usage. 

 

The market funds the first credible wedge, and not the full thesis up front.

 

Understand the three personas

In B2B, one of the fastest ways to confuse yourself is to assume that ‘the customer’ is one person. It is not! 

 

In most purchases, especially once you move beyond very small companies, there are at least three relevant personas: the user, the champion, and the decision maker. 

 

The user is the person who will work with the product directly. They care about usability, workflow fit, speed, reliability, friction, and whether the product actually helps them do the job. They are often the source of the strongest practical insight, because they live closest to the pain. 

 

The champion is the person who helps carry the product internally. They understand the operational problem but they also know how to frame it in a way that the business can take the product and act on it. They also connect the day-to-day pain to commercial or strategic outcomes, and they’re the person who organizes internal discussions, gets feedback from colleagues, gathers the requirements, and pushes the entire process forward. 

 

The decision maker, as the name suggests, controls the budget and/or has the authority to approve the spend. They may not know the details of the workflow at all. What they care about is whether the product fits strategic priorities, whether it reduces risk, whether it improves the financials, whether it addresses their pain. 

 

 

​

​

​

​

​

​

​

​

​

​

 

The person who feels the pain is not always the person who can buy. As Niebelschütz shared:

 

“Always design for the actual user, but the actual user isn’t necessarily the person who signs the contract.” - Matti Niebelschütz, CoachHub

 

That one point explains a huge number of false positives in early discovery. The junior user might love the product but not be powerful enough commercially. Or the team lead could be enthusiastic but unable to secure the budget for it. An executive may approve the project, but only if a manager has done the internal selling first. If you only understand one of these layers, you will misread the market.

 

So, in your discovery conversations, you need to map not just the pain, but the buying path. Who experiences the issue? Who benefits from solving it? Who needs to approve it? Who worries about integration, compliance, or risk? Who can block it? This clarifies your product and overall messaging. 

 

Run discovery interviews properly

An early-stage discovery interview should be a structured conversation of thirty to sixty minutes. The quality of that conversation depends almost entirely on your discipline. Do not see this as a disguised sales pitch - this will skew results. You are not there to impress the person with your idea, but to understand their world. That means that you need to ask open questions, listen carefully, and resist the urge to explain too much too early. 

 

The three parts to a discovery conversation are:

 

1. Understand the context

2. Identify the actual problems

3. Test the urgency

 

In the first part of the conversation, you will want to understand the context. What does this person actually do? Which team are they in? What are they responsible for? What process are they part of? Which systems, constraints, and stakeholders shape their work? Without this context, individual complaints are hard to interpret.

 

Second, identify the real problems. Ask about the biggest friction points in their day-to-day work. Ask where delays happen, where errors happen, where handoffs go wrong, where people spend time on tasks they know could and should be simpler, and ask what’s annoying and costly. Then, be quiet. 

 

Third, test the urgency. Once they bring up a pain point, go deeper. How long has this actually been a problem? Who else is affected? What’s been tried before? Why did those attempts fail? What happens if nothing changes?

 

This is where many founders lose the plot: they hear something interesting and immediately start pitching. That cuts off the best part of the interview. The interview needs to feel like an investigation. 

 

Go where the work happens

A lot of context can be lost by staying in a conference room or on a video call. If you can visit customers on-site, do it. This is especially important if your product touches physical workflows, operational environments, fragmented systems, or coordination across teams. You learn things in the real environment that nobody thinks to mention in a meeting. You can see the workarounds so you know how to position yourself as a better alternative. 

​

“We try to stay very close to the users. We release something, watch people use it, review their sessions, and interview them. They give us very specific feedback.” - Maximilian Seifert, Cosuno

 

What people say and what they do are not always the same. They don’t intentionally lie, but they stop noticing the inefficient parts of their own environments after a while. They adapt and describe the process at a high level, but the reality on the ground is often more revealing. 

 

The same can be said for software-heavy environments. Product people and founders learn a lot by being present in actual commercial conversations, implementation discussions, customer calls, and the like. This is where the real information tends to be, but you have to be there in person to see it. 

​

“If the thing doesn’t work and we didn’t ask a single customer if they like it or not, then that’s a sign for a project not well done.” - Dustin Jaacks, Heyflow

 

How many interviews are enough?

There is no magic number, but there is a useful rule: you probably have not conducted enough. 

 

Early founders often like to stop discovery after ten or fifteen good conversations. That is usually too early. You might have enough information to get excited, but not enough to know what repeats and what is incidental.

 

A better benchmark is to aim for at least 50 meaningful conversations around the same broad problem space, then to go deeper within a narrower segment once patterns start to emerge. But the exact number matters less than what happens inside those interviews. Are you hearing the same pain from similar people in similar environments? Are the same constraints showing up? Are the same workarounds recurring? Are you starting to understand which company types produce the strongest urgency and shortest buying path? 

 

If yes, you are converging. 

 

If not, then you are still exploring. 

 

It’s fine to start broad. In fact, most teams should! But start leaning in once you start seeing the strongest signal coming in. Discovery becomes much more useful when you compare oranges with oranges. 

 

Define your ideal customer profile properly

Your ideal customer profile is the answer to the following question: what kind of company is most likely to feel this pain strongly enough, in the right way, with the right buying conditions, to become an early customer?

 

Elements like the industry, company size, or geography are all important, but so are deeper variables including:

 

• What systems do they already use? 

• How complex is their organization? 

• How many stakeholders are involved in the relevant workflow? 

• How mature is the process today? 

• Is the company growing fast? 

• Is the function under pressure? 

• Is there a budget owner close to the pain? 

 

The company size is particularly important here: smaller companies can move quickly but don’t usually feel the pain as strongly or they can’t justify spending. Very large companies might feel the pain very intensely but the sales cycles are longer, there’s more complexity internally, and overall there’s more red tape. Many startups therefore find the best early customers somewhere in the middle: just large enough to have meaningful pain and budget, but still small enough to move. 

 

By the end of the discovery phase, you should be able to say three things clearly. 

 

First, you need to understand the pain in the customer’s own words. 

 

Second, you should understand the personas, namely who uses the product, who champions it, who buys it, who can block it, and what each of these people cares about. 

 

And third, you should understand your ideal customer profile. 

 

Move from discovery to co-development

Once you have done enough discovery, a small number of companies (ideally three to five) will stand out with real pain, a credible internal champion, some willingness to invest time, and ideally to buy before the product is fully mature. This is the ultimate signal for strong commitment.

 

These are the companies you want as early co-development partners. This is a partner that helps you shape the product by sharing context, testing incomplete features, giving feedback that is detailed and based on real usage, and so on. They help you understand what actually matters and what does not. In return, they get influence, priority, and a solution that is being developed around a problem they genuinely care about. Even though it is very early stages, try to agree on a payment, even a small one, in order to make sure that there is commitment.

 

This relationship is one of the most valuable assets an early startup can have, but it is also risky if you choose badly. Choose based on relationship quality, internal credibility, practical urgency, and the likelihood that the project can turn into a meaningful commercial contract later.

 

Even if the relationship feels informal and promising, formalize it by putting it in writing.