My first real product work was as a business development intern, running early customer discovery for a new B2B engagement platform. The goal was to find out whether the business model held up before the company committed serious money to building it.
What I learned there has stayed with me. In B2B, it's easy to find people who like your idea. It's much harder to find someone who'll actually pay for it, through a process that involves several people who never attended your demo.
User, buyer and approver are often different people
| Role | What they care about | What they'll tell you |
|---|---|---|
| User | Does it make my daily work easier? | Enthusiastic feedback on features |
| Buyer | Does it solve a problem worth this budget? | Questions about cost and value |
| Approver | Is it safe, compliant and worth the risk? | Questions about security, contracts, vendors |
| Influencer | Will this affect my team or systems? | Concerns about integration and change |
Early discovery often only reaches users, because they're easiest to talk to. A user who loves the idea is a good sign, but they may have no budget and no say in purchasing.
I'd make a point of speaking to at least a few buyers and, if possible, someone who approves vendor decisions. Their questions are very different, and they often reveal deal-breakers you won't hear from users.
Find the budget line
Ask what the company spends on this problem today. That might be another tool, a contractor, a team's time, or nothing at all.
Writing out the job they're hiring for helps here, because it tells you what the real alternatives are. If they spend nothing, that's a warning sign. It might mean the problem isn't painful enough to fund. If they already pay for a partial solution, you have a reference point for price and a clear alternative to beat.
Also ask whose budget it would come from. A product that sits between two departments can struggle because neither wants to pay for it.
Test willingness to pay early
"Would you pay for this?" gets polite yeses. Better tests involve some commitment:
- Asking for a paid pilot, even a small one.
- Asking for a letter of intent or a pre-order.
- Discussing a specific price and watching the reaction.
- Asking them to introduce you to the person who'd approve the purchase.
If someone is enthusiastic but won't take any of these steps, the enthusiasm might not translate into a sale. User interview questions that focus on past behaviour help here too.
Watch for false signals
Some things feel like validation and aren't:
- Lots of meetings. People take meetings for all kinds of reasons, including curiosity and keeping an eye on the market.
- Feature requests. A long list of requests can mean interest, or it can mean the product isn't quite right.
- "We'd definitely use this when it's ready." That's a nice thing to hear and not a commitment.
- Interest from one champion. One person can't usually push through a purchase alone.
Understand the buying process
Ask how they bought the last comparable tool. How long did it take? Who was involved? Was there a security review, a legal review, a procurement process?
This tells you how long sales will take, which affects how much runway you need. It also tells you what you'll need to have ready, like security documentation or contract terms, which matter a lot for enterprise sales. I saw this firsthand at Chemarc, working with large manufacturers, where the buying process was often longer and more careful than the product conversation.
Write down what would change your mind
Before discovery, decide what evidence would make you stop or change direction. For example: "If fewer than a few of the buyers we speak to currently spend money on this problem, we'll reconsider the pricing model."
That stops you from interpreting every conversation as encouragement. The point of validation is to find out early if something won't work, while it's still cheap to change.