Seven Ways to Find a Startup Idea, Then Test It

Seven Ways to Find a Startup Idea, Then Test It

Startup ideas become useful when a founder generates them from a real advantage or problem and then tries to disprove the demand before building the solution.

Jared Friedman's Y Combinator talk How to Get Startup Ideas provides seven practical routes. The framework is good for creating candidates. It is not a predictor of venture success, and it does not replace evidence from the people, workflow, market, and buyer.

The seven routes

The first route begins with what the team is unusually good at. Deep knowledge can reveal expensive workarounds, trusted distribution, technical feasibility, or a problem outsiders cannot see.

The second begins with a problem the founder has personally experienced. Personal experience can create urgency and insight. It can also create a sample of one.

The third asks what the founder wishes existed. The missing product may point to real unmet demand, or it may be a private preference without a market.

The fourth looks for a recent change. New technology, regulation, behavior, distribution, cost, or infrastructure can make a previously weak idea possible.

The fifth creates a variant of a successful company. A model may work for another customer, geography, workflow, price, or regulatory setting. A variant still needs a reason the incumbent or copy cannot win.

The sixth comes from talking with people about their problems. The conversation should examine actual work and recent behavior instead of asking whether a hypothetical product sounds good.

The seventh looks for a large industry that seems broken. A broken experience can hide a strong opportunity, a necessary constraint, a concentrated gatekeeper, or a rule that prevents an easy solution.

The source should be credited to Friedman and Startup School. Venture Step's contribution is the evidence pass that follows.

flowchart LR
    A["Seven idea routes"] --> B["Problem hypothesis"]
    B --> C["Observe current behavior"]
    C --> D["Identify user, buyer, and alternative"]
    D --> E["Test frequency, urgency, and economics"]
    E --> F["State disconfirming evidence"]
    F --> G["Build, revise, park, or stop"]

Write a problem hypothesis

Do not begin with the product pitch. Write who experiences the problem, what they are trying to accomplish, what happens now, how often it happens, what it costs, who pays, and why the situation may have changed.

"Small insurance agencies need AI" is not a useful hypothesis. "Commercial account managers at agencies with a specific workflow spend a measurable amount of time reconciling duplicate submission data before a renewal deadline" can be investigated.

The hypothesis should also say what would make it wrong.

Observe the current alternative

People solve important problems somehow. They use a spreadsheet, email, manual review, a consultant, an incumbent product, a policy exception, extra staff, delay, or acceptance of the loss.

The current alternative reveals the real competition and the cost of changing behavior. It also shows whether the problem is painful enough to deserve budget.

Ask for a recent example. Have the person walk through the work, records, handoffs, approvals, errors, and consequences. Avoid collecting confidential or personal information you do not need.

Y Combinator's broader Startup School library provides the context for founder problem selection, users, products, and company building. It is practitioner guidance, not a controlled study of venture outcomes.

Separate the user from the buyer

The user feels the workflow. The buyer controls money. Security, legal, finance, procurement, IT, regulators, and data owners may influence the decision.

A problem can be intense for the user and still lack a purchasing path. A buyer can have budget while the user resists a system that creates more work or surveillance.

Map the decision, not only the persona.

Test frequency, urgency, and consequence

A rare annoyance may not sustain a company. A frequent problem can still be cheap. An expensive problem can be tolerated because change creates a larger risk.

Ask how often the event occurs, what happens if nothing changes, which deadline matters, how performance is measured, and which cost is visible in a financial or operating record.

Do not use enthusiasm as proof. A compliment, waitlist signup, or feature request is weaker than time, data access, a pilot commitment, a signed agreement, or payment.

Steve Blank's customer development overview frames a startup as an organization searching for a repeatable and scalable business model. The search is the important word. Early assumptions should become tests.

Examine founder advantage without romanticizing it

Founder-market fit can include knowledge, credibility, access, obsession, technical ability, operating experience, or a relationship with the problem.

It should not be reduced to having worked in the industry. An outsider may ask a better question. An insider may inherit assumptions and conflicts.

Write the advantage as a testable resource. Which interview can the team obtain? Which workflow can it understand? Which product can it build? Which buyer trusts it? Which evidence would show the advantage is not special?

Check the economics before polishing the concept

Estimate the number of plausible buyers, current spend, price, implementation cost, support cost, sales cycle, gross margin, retention driver, and the value created or risk reduced.

The estimate can be rough. Its job is to reveal the assumption that must be tested next.

If the idea depends on a new law, cheap model inference, a platform integration, or a supplier, confirm the dependency. A recent change can create the opportunity and can also disappear.

Use kill criteria

Kill criteria protect a founder from explaining away every weak signal. A team can decide in advance to stop or revise if the problem is infrequent, the buyer cannot be identified, the data cannot be used lawfully, the cost of switching exceeds the value, the sales cycle breaks the economics, or the existing alternative is good enough.

Stopping one idea is not evidence that the team cannot build a company. It is evidence that the search produced information.

Apply the framework inside a company

Dalton extends the seven routes to employees who want to improve their current organization. The same method works if the evidence and authority are respected.

Start with a costly workflow, observe it, find the owner, measure the baseline, test a small change, and record the result. Do not create a shadow product that bypasses data, security, legal, or operating controls.

The goal is not idea volume. It is a smaller set of problems with enough evidence to deserve the next experiment.

AI assisted with research organization, structure, drafting, and validation. Dalton Anderson remains the attributed author and final editorial authority. The transcript and linked public sources control factual claims. Publication remains unauthorized.