A person can love your product, use it every day, and still lack the authority or budget to buy it. For a founder selling into an organization, discovery needs to answer three separate questions: Who experiences the problem? Who will champion the solution? Who can approve the purchase?

That distinction became one of the most practical lessons in The Upper Room conversation with Shadrach Igwe, Co-Founder and CTO of CerTracker. CerTracker helps healthcare professionals and organizations manage credentials and compliance. In the October 13 session, Shadrach described the shift from building a useful tool for an individual to understanding how organizations decide to adopt and pay for it.

Start with the pain, then follow the purchase

CerTracker began with a personal need. Shadrach described building an app to help his future wife organize her professional credentials. An inquiry about using the tool across a much larger workforce pushed the founders to consider a business they had not originally set out to build.

The origin matters because the user’s problem was concrete. The next challenge was commercial: enthusiasm for the tool did not necessarily sit with the person who could purchase it. Shadrach said it took the team more than a year to understand that difference.

His lesson is useful beyond healthcare. A staff member may struggle with a workflow while a department leader controls the budget. A team may want a tool while technology, security, or procurement colleagues help determine whether it can be adopted. These are illustrative examples; an organization’s actual process must be discovered rather than assumed.

The goal is to learn how value travels from the person doing the work to the person approving the expense.

Map three roles before calling an opportunity qualified

Use this working map in your next discovery conversation:

• User: What task is difficult? How often does the problem occur? What happens when it goes unresolved? What does the person use today?

• Champion: Who wants the problem solved enough to help move the conversation forward? Can they describe the value in their own words? Will they introduce the relevant colleagues?

• Buyer: Who owns the budget or can authorize the purchase? What evidence do they need? When can a decision be made, and what other steps are required?

One person may fill more than one role. Several people may share a role. This map is an editorial tool drawn from the session’s user-versus-buyer lesson, not a description of every CerTracker customer or a universal purchasing process.

When a prospect says they love the product, acknowledge that signal and keep learning. Ask what would need to happen for their organization to adopt it. A clear explanation of the next step is more useful than another compliment.

Ask for the introduction that changes the conversation

Shadrach described bringing a customer champion and a technology decision-maker into the same conversation. The champion could explain the practical value while the team showed what the product did and explored whether a purchase could move forward.

A useful request is specific: Which colleague should join us to discuss adoption and budget? That is easier to act on than a general request to help the business grow.

He also described a broader habit of asking connections whether they knew someone who could help. In one example, he attributed a group purchasing agreement’s progress to contacting an organization’s CEO and being introduced to an operating leader. The reported four-week timeline is his account of that transaction. It is not a typical sales-cycle benchmark or a promise that direct outreach will produce the same result.

Founders can take the behavior without copying the outcome: explain what you are trying to learn, ask for an appropriate introduction, and make the next conversation easy to arrange.

Test the economics without chasing a headline

Shadrach used simple arithmetic to compare a large number of small purchases with a smaller number of larger purchases. The useful question is what kind of business the team can realistically serve and sustain.

For example, ten annual contracts at $100,000 and one hundred at $10,000 each both total $1 million before expenses. Those are hypothetical calculations, not CerTracker’s reported customer count or pricing. Reaching either total still depends on demand, value, delivery capacity, sales costs, retention, and the purchasing process.

A larger budget does not automatically make someone a better customer. Ask whether the product solves a problem they prioritize and whether the team can meet their expectations. The right buyer needs both a reason and a way to purchase.

Keep service at the center of discovery

Shadrach’s founder story also emphasized learning to receive help and offering the skills he already had to others. That posture can make customer discovery more honest: listen for the problem before defending the solution, and be willing to learn that a different stakeholder needs to join the conversation.

His Christian testimony framed service as part of his personal motivation. It should not be turned into a formula promising financial success. A useful product, generous conduct, and disciplined commercial learning each matter; none removes the need to make sound operating decisions.

A practical next step

Choose three active opportunities and write down the user, champion, buyer, purchasing steps, and the next introduction needed. Mark unknowns plainly. Use the next conversation to resolve one important unknown rather than repeat the entire pitch.

The test is simple: Can you explain whose problem you solve, who can help the solution move forward, and who can fund it? If one answer is missing, that is the next discovery task.

Resources and source notes

This article draws on The Upper Room conversation recorded October 13, 2026: the CerTracker origin at approximately 08:46–10:07, introduction requests at 32:35–35:24, the user/buyer lesson at 48:25–50:04, and purchasing discovery at 51:12–52:37 in the original recording. Speaker-reported outcomes are attributed rather than independently verified.

Learn about CerTracker · Read the i2E founder story