What We Look for Before Building a New Venture

Start with a system of evidence, not an idea

New ventures are often narrated as flashes of insight: an underserved market, a new technology, or a product that should exist. Ideas matter, but they are abundant and adaptable. What deserves investment is a reinforcing system of evidence: a meaningful problem, a customer motivated to solve it, a credible way to reach that customer, an initial solution that can be delivered, and a path by which the venture becomes stronger as it grows.

We treat venture formation as a sequence of de-risking decisions. At each stage, the team should identify the assumption most capable of invalidating the opportunity and seek the fastest credible evidence about it. That may be problem interviews, workflow observation, a manual service, a prototype, a commercial proposal, or a limited delivery. Building software is only one experiment, and often not the first one required.

This discipline protects more than capital. It prevents teams from becoming emotionally attached to an implementation before they understand the customer’s reality. It also creates a clearer narrative for future employees, partners, and investors: not that the founders believe intensely, but that they have learned something specific and know what must be learned next.

The purpose of early venture work is not to prove the original idea right. It is to discover whether a durable business is becoming true.

Look for pain with urgency, consequence, and ownership

A real problem is not merely something customers dislike. It has consequences they recognize: lost opportunity, unnecessary cost, material risk, delayed work, or a persistent failure to achieve an important goal. The strongest signals are frequency and existing effort. If people repeatedly assemble spreadsheets, hire specialists, tolerate awkward workarounds, or escalate exceptions, the problem is already consuming resources even if it lacks a formal budget line.

Identify who feels the pain, who owns the outcome, who uses the solution, and who can authorize change. These may be different people. A daily user can be enthusiastic while a budget owner sees no priority; an executive can sponsor change while the operational team resists disruption. Venture design must account for this decision system, not reduce “the customer” to a single persona.

Timing is equally important. Why would the customer change now? A new obligation, cost shift, behavior, platform capability, or competitive pressure may create urgency. Without a trigger, even a severe problem can remain tolerated. We want to understand both the structural problem and the event that moves it from acknowledged to actionable.

• Consequence: what becomes worse if nothing changes?
• Frequency: how often does the problem enter the workflow?
• Workaround: what time, money, or risk is already spent coping?
• Ownership: who is accountable, affected, influential, and able to buy?
• Trigger: what makes action plausible now rather than someday?

Test behavior before building conviction

Customers are often generous with encouragement. They can sincerely praise a concept without changing behavior, allocating budget, or accepting implementation effort. We therefore seek evidence that carries a cost: time spent introducing us to colleagues, access to a real workflow, permission to examine representative data, participation in a pilot, agreement to a deployment plan, or a commercial commitment. The appropriate signal depends on the stage, but it should require more than politeness.

Discovery should examine recent facts rather than hypothetical preference. Ask a customer to walk through the last time the problem occurred: what triggered it, who became involved, which systems were used, what decision was delayed, what was tried, and how the outcome was judged. Contradictions are useful. If a stated priority has no owner, no recent action, and no consequence for delay, it is probably weaker than the conversation suggests.

Experiments should isolate uncertainty. A landing page can test message response but not retention. A concierge service can test whether the outcome is valuable before the process is automated. A prototype can test comprehension and workflow fit but not willingness to implement. State what each experiment can and cannot prove, and decide in advance what evidence would cause the team to proceed, revise, or stop.

Choose a wedge that can earn expansion

A strong initial market is narrow enough to understand and serve, but meaningful enough to support a venture. Narrowness can come from industry, role, workflow, event, or operating environment. The goal is not to describe a small demographic; it is to find a group whose shared problem allows the team to build a focused product, repeat a sales motion, and learn quickly.

The first product should solve a complete problem for that group. A thin layer across many workflows may demonstrate ambition but create weak value and heavy integration burden. A sharp wedge can become the trusted entry point, generate proprietary workflow insight, create valuable data relationships, or embed the product in a recurring decision. From there, expansion should follow an adjacent customer need or capability—not a generic promise to serve everyone later.

We also ask how the venture could develop an advantage. Technology alone is rarely permanent. Advantage may emerge from distribution, accumulated workflow data, integration depth, network participation, operational excellence, brand trust, or a learning loop that improves the product. The mechanism must be compatible with customer value; friction that traps customers is not the same as a defensible business.

A wedge is not simply a smaller product. It is a focused promise that can be delivered completely and creates the right to make the next promise.

Design distribution and economics together

A venture is not viable merely because customers want the product. The team needs a plausible path to find, persuade, onboard, serve, and retain them. Map the buying journey early: trusted channels, evaluation requirements, security or procurement steps, implementation effort, decision cycle, and the moment value becomes visible. If every customer requires founder-led education and custom integration, that may be acceptable during learning, but it is not yet evidence of a scalable motion.

Model economics as a set of drivers rather than a precise forecast. What determines price and willingness to pay? Which costs rise with usage, complexity, service, or risk? How much human delivery is embedded in the product? What must be true about retention and expansion? Use ranges and scenarios, then connect experiments to the most sensitive assumptions. Early precision can create false confidence; explicit drivers help the team learn.

Consider structural constraints before product investment. Regulated data, long procurement cycles, specialized implementation, platform dependency, or concentrated suppliers may be entirely workable, but they shape capital needs, team composition, sequencing, and risk. A compelling opportunity can still be the wrong venture model for the available resources and time horizon.

• Discovery: how does the right customer encounter and trust the venture?
• Conversion: what evidence and approval are required to buy?
• Activation: what must happen before the customer experiences value?
• Delivery: which costs and human work scale with each account or transaction?
• Retention: why does value recur, and what expands the relationship?

Evaluate the founding system—and earn the right to build

We look for founder-market fit beyond résumé matching. Does the team have unusual access to customers, insight into the workflow, technical or operational ability to deliver, and the credibility to recruit partners and talent? Just as important, can the founders learn without defending the original thesis? Venture building repeatedly converts uncomfortable evidence into sharper choices. Intellectual honesty and pace of learning are core operating capabilities.

The team also needs a reason to be the team for this problem. That reason can combine lived experience, domain relationships, technical insight, and a durable commitment to the customer. Gaps are expected, but they should be named with a plan to recruit, partner, or learn. Unspoken gaps become future bottlenecks, particularly when a venture crosses product, regulation, go-to-market, and service delivery.

Before substantial build, write an investment memo that captures the problem evidence, customer decision system, timing, wedge, proposed outcome, distribution path, economic drivers, advantage hypothesis, team fit, principal risks, and next experiments. The memo is not a ceremony or prediction. It is a record of why this venture deserves the next unit of time and capital. If the evidence changes, the thesis should change with it. That willingness is not a lack of conviction; it is how conviction becomes earned.

• Proceed when the core evidence reinforces a focused, testable venture thesis.
• Revise when the problem is real but the buyer, wedge, delivery, or model remains wrong.
• Pause when a decisive external condition must change and there is a clear signal to monitor.
• Stop when repeated behavioral evidence contradicts a foundational assumption.