What are the fundamental starting position?

When founders ask “What are the fundamental starting position?”, they’re usually looking for the minimum set of truths you need before you invest months of work (and money) into building. For technical, medical, and scientific founders, the trap is starting from the solution (“I can build X”) instead of the starting position (“a specific group of people will reliably pay to solve Y”).

A good starting position is not a 40-page business plan. It’s a compact, testable set of assumptions that you can validate quickly. Think of it like a baseline in an experiment: you define variables, define success criteria, then run small tests.

1) Start with a specific customer + a painful problem

Your first fundamental is a clear customer segment (who) and a painful problem (what hurts). “Everyone” is not a segment. “Healthcare” is not a segment. A segment is something like: “outpatient cardiology clinics with 3–10 physicians” or “PhD labs running weekly qPCR workflows.”

Then define the problem in observable terms. A strong problem statement includes:

• Context: when/where it happens (e.g., “during patient intake”)
• Frequency: how often (daily/weekly)
• Severity: what it costs (time, money, risk, missed revenue, compliance exposure)
• Current workaround: what they do today (spreadsheets, manual review, hiring, ignoring)

Rule of thumb: if the problem doesn’t cause a measurable loss (time, money, risk) or a strong emotional pain (stress, reputational fear), it’s hard to sell.

2) Define a value proposition that is testable

A value proposition is the concise promise of outcomes you deliver and why you’re different. Avoid vague claims (“AI-powered,” “efficient,” “next-gen”). Make it testable.

Use this simple template:

For [specific customer], who struggle with [painful problem], our product is a [category] that delivers [measurable outcome] by [key mechanism].

Example (generic): “For small outpatient clinics who lose hours weekly to manual prior authorization, our tool is a workflow assistant that reduces admin time by 30–50% by auto-generating forms and tracking payer status.” The numbers are hypotheses until validated, but they force clarity.

Translate “features” into “job-to-be-done”

Job-to-be-done (JTBD) means the real task the customer is “hiring” your product to do. A feature like “one-click export” is not a job. The job might be “send a compliant report to a regulator in under 10 minutes.” Starting position improves when you can state the job clearly.

3) Choose a wedge: the smallest market you can win

Most early-stage startups fail by trying to boil the ocean. A wedge is a narrow, high-need entry point that lets you win a small group, learn fast, and expand.

A good wedge has:

• High pain and urgency
• Clear buyer (the person who can say “yes”)
• Short sales cycle (weeks, not quarters)
• Reachable distribution (you can actually contact them)
• Expansion path to adjacent users/problems

For STEM founders, the wedge is often a single workflow step (e.g., “sample tracking for one assay type”) rather than an end-to-end platform. Platforms come later.

4) Know your business model: who pays, how much, and why now

A business model is simply how value turns into revenue. Early on, you need three basics:

1. Buyer vs. user: the user may love it, but the buyer controls budget.
2. Pricing logic: per seat, per usage, per site, per project, per outcome. Pick one that matches how value is created.
3. Budget source: what line item it comes from (operations, R&D, compliance, IT). If you can’t name it, sales will stall.

Also define your why now: the trigger that makes the buyer act. Examples: new regulation, staffing shortages, new reimbursement rules (varies by market), a new technology enabling lower cost, or a competitive pressure. “It’s cool” is not a why-now.

5) Build proof before product: evidence of demand

The fundamental starting position includes proof—not certainty, but evidence that reduces risk. For pre-product startups, proof can be:

• Problem interviews: 15–30 conversations with your target segment where you hear consistent pain and current spending/workarounds.
• Solution interviews: show a mockup and ask for commitment signals (pilot, intro to buyer, data access).
• Pre-sales or LOIs: a Letter of Intent (LOI) is a non-binding document stating intent to pilot/buy if conditions are met. Not revenue, but stronger than “sounds good.”
• Pilot commitments: a defined trial with success criteria (e.g., “reduce processing time from 45 min to 20 min”).

Commitment signals beat compliments. “I’d use it” is weak. “Here’s our admin lead; can you run a pilot next month?” is strong.

Define success metrics like an experiment

Pick 1–3 measurable outcomes for your first version. Examples:

• Time saved per task (minutes)
• Error rate reduction (%)
• Throughput increase (tasks/day)
• Revenue captured (e.g., fewer missed billables) (varies)

Write them down before you build. Otherwise you’ll ship features without knowing if you’re improving anything.

6) Map the competitive landscape and your differentiation

You always have competitors, even if no one sells “your exact thing.” The real competitor is often the current workaround: spreadsheets, email, interns, or “do nothing.”

Your starting position should include a simple differentiation statement:

• Alternative: what they do today
• Your advantage: faster, cheaper, safer, more compliant, easier to adopt
• Proof path: how you’ll demonstrate it in a pilot

If your advantage depends on a complex model or deep tech, translate it into the buyer’s language: “reduces review time,” “flags anomalies earlier,” “cuts rework,” “improves audit readiness.”

What to do next

1. Write a one-page starting position with: target segment, problem, current workaround, value proposition, buyer, and why-now.
2. Run 15 problem interviews in the next 2 weeks; track frequency, severity, and what they currently spend (time or money) to cope.
3. Create a simple prototype (Figma, slides, or a clickable mock) and book 5 solution interviews to test willingness to pilot.
4. Define a pilot offer with 2–3 success metrics, timeline (e.g., 4–6 weeks), and what access you need (data, users, workflow time).
5. Do a quick competitor/workaround study and write your “why us” in one paragraph focused on measurable outcomes.