Most founders start by pitching solutions — sleek demos, feature lists and product roadmaps. But after years of building products, I've learned this approach gets the sequence wrong. At Hex, we discovered that successful commitment engineering starts before you have anything to show to potential customers. The first step is ensuring you understand the problem you're solving.Implementing commitment engineering effectively requires a systematic approach to gathering evidence and moving carefully toward solution validation. The difference between success and wasted effort often comes down to recognizing a few key signals early in the process.Here's what we've learned about making commitment engineering work. Getting started with commitment engineeringWhen a potential customer agrees to meet, most founders launch into their pitch. Instead, try asking: "Can you tell me more about what you’re struggling with? What solutions have you already tried for this problem?" You'll get far better results from early conversations if you spend the majority of the time listening. The depth of someone's response also tells you if you're addressing a significant pain point. When people have a real problem, they don't give short answers — they share detailed stories about failed attempts, current workarounds and the costs of the status quo. If you're getting brief responses or struggling to keep the conversation going, you might not be targeting a pressing enough problem. This focus on problems also extends beyond customer conversations. I highly recommend publishing content about the issue you’re focused on — and you can do this long before you know what you’ll be selling. Writing about problems rather than solutions serves two purposes: It helps you build an audience of potential customers, and it demonstrates that you truly understand their challenges.How to read the signsWhen potential customers consistently decline your next-step requests — whether for follow-up meetings, using the product for a specific situation or bringing a colleague to your next meeting — that means you're facing one of two problems: Either the pain point isn't severe enough to motivate change, or they don't believe your solution will work. If people describe their challenges in detail but hesitate to see your solution, you need to build more credibility. But if you're hearing responses like "We have a way to handle this" or "It's not a major priority," you're likely solving a problem that isn't painful enough.  When you implement commitment engineering, you’ll learn to distinguish between these scenarios early, because they require different responses. You’ll need to strengthen your solution story in the first case, or find a more pressing problem in the second.The potential pitfalls of this approachThe most dangerous feedback in early product development sounds like this: "That's interesting — keep me posted on how it develops." Potential customers often default to politeness rather than direct criticism. Remember that everyone's calendar is full. No one has spare time to spend on an early-stage product just to be nice.  Real interest looks different. It involves concrete actions like scheduling follow-up meetings, opening calendars on the spot or offering to bring colleagues to the next discussion. Time is a proxy for genuine interest, and finding out what people are (and are not) willing to commit to will give you clear signals. A second common mistake is taking on too many design partners — the early users who engage in your commitment engineering process. While it's tempting to work with everyone who shows interest, this often leads to a lack of focus.  Two design partners are ideal. It's the minimum number that prevents you from building a single-customer solution, while keeping your feedback loop tight and manageable. Look for partners who respond quickly and engage deeply, rather than trying to juggle multiple surface-level relationships.