Essay / Product & Entrepreneurship
Go-to-Market Starts Before You Have Something to Launch
Distribution, buying decisions and trust belong in product discovery. Trace the route from a customer problem to a first conversation and useful adoption.
A launch plan often begins with a finished product and a blank space labeled distribution. The team has decided what to build, then starts looking for people who might buy it. That sequence can work, but it leaves several product assumptions untested until late.
How does someone recognize the problem? Where do they look for help? Who must trust the proposed solution? What has to happen between interest and everyday use? These questions affect the product itself, not merely the message used to announce it.
I think go-to-market belongs in discovery because a solution needs a credible route into someone’s working life. A feature can be useful in a demonstration and still have no plausible path to adoption.
If you do not know how a customer will discover the product, you are still missing part of the product.
Follow a real buying situation
Imagine a small retailer struggling to reconcile stock across several channels. A founder sees the problem and proposes an integration service. The immediate product question seems technical: can the systems exchange reliable updates?
The buying situation is broader. The person who feels the daily pain may not control the software budget. The agency maintaining the store may influence the decision. A warehouse colleague may worry about losing the spreadsheet that currently catches mistakes. The owner may care most about avoiding disruption during a busy period.
A discovery conversation should therefore trace a recent attempt to solve the problem. Who noticed it? What did they try? Where did they search? Which people became involved? What stopped or enabled the change? This is more useful than asking an abstract audience whether an integration product sounds attractive.
The answers can change the product boundary. A migration preview, a reversible trial, or an export of reconciliation results may matter more to adoption than another connector. Distribution and product design meet at that point.
A channel is a context, not an audience count
A large audience is not automatically a useful channel. The relevant question is whether people encounter the message while dealing with a problem the product can address. Timing, trust, and intent matter alongside reach.
For the retailer example, a community of store operators, a specialist consultant, and a general technology newsletter might all reach potential users. They create different conversations. One may surface operational questions. Another may provide trusted implementation help. A third may generate curiosity without any immediate buying situation.
Before investing heavily in a channel, define what a useful response would look like. It might be a conversation with an operator who recently investigated the problem, a request to examine a real workflow, or a trial with an agreed objective. A click is a weaker signal if it never connects to the intended job.
This is not an argument against broad communication. It is an argument for knowing what a channel is expected to do. Awareness, discovery, evaluation, and adoption are related activities, but they should not be measured as if they were interchangeable.
Learn outside the product narrative
A product demonstration creates a frame. Once people see the proposed solution, they may discuss the interface rather than explain how the underlying work happens. Early discovery benefits from conversations that begin before that frame is introduced.
Steve Blank’s account of getting outside the building emphasizes learning from customers in their actual context. The useful principle here is to investigate how people work and buy, rather than relying only on internal agreement about a solution. It does not mean every conversation confirms the initial idea.
For the stock problem, I would first ask someone to describe the last discrepancy they had to resolve. Which records did they compare? How long did the uncertainty remain? Who needed an answer? Then I would explore the last software change they adopted and the process around that decision.
Those two stories reveal different constraints. The first describes the problem. The second describes the route through which a solution could enter. A product needs to fit both.
Trust has implementation requirements
Trust is sometimes treated as a branding issue. For a product that touches important business data, it also has concrete requirements. A prospect may need to inspect permissions, understand where data goes, see a recovery procedure, or know who can help when an integration fails.
These needs can become product work. A clear connection screen, a read-only evaluation mode, and an understandable activity log may reduce uncertainty more effectively than a stronger marketing claim. They let the customer inspect the relationship instead of merely accepting reassurance.
The same applies to migration. If adoption requires replacing an existing process, the product should explain what changes, what remains available, and how to stop the trial safely. A reversible first step can make a conversation possible without promising that the entire transition is risk-free.
None of this guarantees a sale. It makes the proposed change assessable. That is valuable evidence for both sides: the customer can judge fit, and the builder can learn which concerns are material.
Separate interest from adoption work
Someone can want a result and still be unable to adopt the product. They may lack access to the relevant account, permission to change a workflow, or time to prepare the required data. Calling that person unmotivated would miss a design constraint.
Map the steps from first contact to first useful outcome. Include the actions outside the application: obtaining approval, inviting a colleague, collecting credentials, or scheduling a transition. Then identify which steps the product can simplify and which require a different sales or implementation approach.
For a self-service product, a long sequence of organizational approvals may challenge the intended model. For a service-supported product, those steps may be normal, but they need time and ownership. The important point is to make the route explicit before assuming a frictionless funnel.
Pricing is part of this route. A package that fits the daily user but requires a different budget owner’s approval changes the adoption process. That relationship should inform discovery rather than appear as a surprise after launch.
Design a small channel experiment
A useful early experiment has a defined audience, a specific problem statement, and a next action that teaches something. It also has a stopping point. Without those boundaries, posting repeatedly can feel like progress while producing little interpretable evidence.
For example, the retailer concept could begin with a short explanation of a reconciliation problem shared in an appropriate professional context. The invitation might be to discuss a recent incident, not to join an unspecified waiting list. Record whether respondents fit the intended situation and what their stories reveal.
Do not treat silence as a single clear answer. The message may be unclear, the channel may be wrong, the timing may be poor, or the problem may not matter enough. Change one important assumption at a time where practical, and keep the interpretation narrower than the evidence.
Likewise, a positive response does not validate every part of the business. It may justify another conversation or a limited trial. The next step should match what was actually learned.
A useful channel brings you closer to a real decision, not merely closer to a larger audience.
Let distribution reshape the product
The outcome of discovery may be that the initial product is too broad, too difficult to evaluate, or aimed at a person who cannot authorize the change. Those are productive findings if they arrive while the design remains flexible.
A narrower first use case may have a clearer buyer and a shorter path to value. A partner may be a better route than direct acquisition. An implementation service may be necessary before self-service becomes realistic. These are choices to test, not universal prescriptions.
The launch then becomes one event in an already developing relationship with a market. There is still communication to prepare and operational work to finish, but the team is not starting from an empty distribution box. It has evidence about where the product belongs, who needs to trust it, and what adopting it actually requires.