The common advice to conduct unbiased discovery interviews sounds logical but often fails. The truest way to validate an idea and understand customer needs is through the act of selling. This forces a concrete value exchange and reveals genuine demand in a way that hypothetical conversations cannot.

In early stages, the key to an effective product roadmap is ruthlessly prioritizing based on the severity of customer pain. A feature is only worth building if it solves an acute, costly problem. If customers aren't in enough pain to spend money and time, the idea is irrelevant for near-term revenue generation.

Product teams often fear showing prototypes because strong customer demand creates pressure. This mindset is flawed. Having customers eager to buy an unbuilt feature is a high-quality signal that validates your roadmap and is the best problem a product manager can have.

Most problems customers describe are "pain points" they won't act on. You can't distinguish these from real, actionable demand ("pull") through interviews alone. The only true test is presenting a viable solution and attempting to sell it. Their reaction—whether they try to pull it from you—is the only reliable signal.

Instead of pitching a future product, identify an enterprise champion's urgent, blocked project. Deliver the solution manually as a service first (e.g., a PDF report). This validates demand, generates revenue, and is a common path in enterprise software.

Believing you must *convince* the market leads to a dangerous product strategy: building a feature-rich platform to persuade buyers. This delays sales, burns capital, and prevents learning. A "buyer pull" approach focuses on building the minimum product needed to solve one pre-existing problem.

The "Pull Framework" defines demand not by pain, but by observable action. It requires a customer to have an active, unavoidable project, to have already explored existing options, and to find those options insufficient. This is the signal for a product they will eagerly "pull" from your hands, even if it's imperfect.

During validation calls for Merge, prospective customers expressed extreme annoyance with the status quo but were skeptical the founders could technically solve it. This combination was the ultimate signal: the pain was immense, and a successful solution would be highly defensible and valuable.

Replace speculative feedback from discovery calls with a process that would be "weird if it didn't work." First, get strangers to pre-pay for a solution. Then, deliver it manually. This confirms real demand (payment) and validates the solution's value (retention) before writing code.