An idea can survive a long time in a presentation because nobody has to depend on it. The first real customer changes that. Someone brings a deadline, imperfect information, and a working habit the product must fit. What sounded convincing now needs to produce an outcome. That encounter is one of the most valuable design inputs a young company can receive. The HeadsUp example below connects this question to a specific company in the Interesting Concepts portfolio.
Begin with the work already happening
Ask how the person completes the task today. Follow the documents, messages, workarounds, and people involved. A spreadsheet may look inefficient from outside while quietly handling exceptions that a new product has never considered. Replacing it requires understanding what it does well.
For example, a team tracking renewals may care less about a calendar than about knowing who can approve a cancellation. That distinction changes the product. The useful starting point is a concrete recent experience: what happened, what became difficult, and what the person did next.
A first conversation for HeadsUp
For a product such as HeadsUp, a useful early conversation starts with the last renewal the customer handled. Ask who noticed it, where the contract lived, which date mattered, and who made the decision. The answer may reveal that reminders were already plentiful while responsibility remained unclear.
A request for “more notifications” should therefore prompt a follow-up question about the previous failure. Did nobody receive the message, did the wrong person receive it, or did the recipient lack the information needed to act? Each is a different product problem.
Make the first commitment small enough to keep
Offer a bounded outcome with an explicit scope. Name the information required, the work the customer will still do, and how completion will be recognized. An early product should give people enough clarity to decide whether participating is worth their time.
Some parts of delivery may initially involve manual work. Explain that where it affects the experience, timing, or handling of information. A careful manual process can reveal what deserves automation. Presenting it as an already autonomous system hides the very constraints the team needs to understand.
Listen for behavior, then ask why
Compliments can encourage a team without showing whether the product belongs in someone’s routine. Observe whether the customer returns, completes the intended task, and chooses the product when the old method remains available. Then ask about the reasons behind those choices.
A missed session is not automatically rejection. The customer may have had no relevant task that week, encountered a confusing step, or been waiting for a colleague. Keep those explanations separate. Each suggests a different response, and none is improved by treating every interaction as proof of demand.
Protect the relationship from overpromising
The first customer should have a clear way to report a problem and receive an honest answer. Record requests without automatically committing to them. Explain which changes fit the product’s purpose, which need more investigation, and which the team cannot support.
The aim is a useful exchange: the customer receives a dependable outcome, and the company learns how to deliver it more consistently. One relationship cannot represent an entire market. It can, however, expose assumptions that would otherwise travel unnoticed into every subsequent sale.
Keep the lesson narrower than the market claim
One interview can uncover a valuable exception without proving that every small business needs the same workflow. Record the observation, the interpretation, and the next question separately. An owner’s workaround may be unique to a purchasing arrangement or a particular supplier.
Interesting Concepts can use that discipline across the portfolio. Gather can study one real intake; Clearcut can study one scope change. The aim is to improve understanding of the work before turning a single story into a general promise.
