Stage 2

Solution Validation

The customer and problem are clear. Now build something so you can test whether you have the right solution to the problem. Get your customers to put their money and time where their mouths are — through beta testing of an MVP.

Stage 2 progress0%

0 of 0 complete

Goals of this stage

Build an MVP to test your assumptions
Use the MVP to gather quantitative and qualitative data through real product usage
Begin iterative product development
Validate your customer segment and value proposition
Strengthen your business foundation with more formal documents and processes

This stage assumes

You completed Stage 1 — a real need clearly exists in this market
You have customers interested, signed up, and ready to use your product or service

Do not move forward if

You're having difficulty recruiting new customers
Your product is not delivering the expected value to your customers
Your story is not clear to your customers or mentors

Part A — Build & test the MVP

Design the Initial MVP

Define the 'minimal' product that realizes value for your customers.

"Minimum Viable Product" is widely misunderstood. It is not a cheap version of your grand vision — it is the smallest thing that tests your riskiest assumption. Start from the question "what do we hope to learn?" and design backwards. Every feature must earn its place by contributing to that learning; everything else goes in the backlog. The discipline here directly determines how fast and cheaply you learn in the beta.

Define the MVPThe smallest feature set that delivers the core value identified in your Stage 1 problem statement.
Write down what you hope to learnSpecific, falsifiable hypotheses: "X% of early adopters will use it weekly," "users will pay $Y."
Agile: product backlog createdPrioritized list of everything beyond the MVP, fed by your Stage 1 customer evidence.

Build the MVP

Build the product and iterate per your product management process.

Now — finally — you build. Work in short cycles (sprints) with regular check-ins so the team stays aligned and course-corrects quickly. Write a lightweight product development plan covering scope, timeline, and responsibilities. And design data security and management in from the start: how you collect, store, and protect user data is much cheaper to get right now than to retrofit after a breach or before a diligence process.

Product development planScope, milestones, owners, and timeline for the MVP build.
Agile: sprint planning / scrum meetingsShort build cycles with demos and retrospectives — momentum plus course-correction.
Data security and management designed inHow user data is collected, stored, encrypted, and accessed — documented before launch.

Measure

Establish metrics to effectively learn from user behavior — what works and what doesn't.

If you can't measure it, your beta is just a vibe. Instrument the product before launch: an analytics tool tracking sign-ups, activation, feature usage, and retention. Define your KPIs in advance so you're not retrofitting a story onto whatever numbers appear. What users do will frequently contradict what they say — and behavior is the truth.

User/product analytics tool implementedEvent tracking live before your first beta user logs in.
KPIs definedThe handful of numbers that tell you whether the solution is working — chosen before launch.

Beta Customer Recruitment

Secure an initial set of customers to use and test the product and give feedback.

Your Stage 1 customer list now pays off — these are your first calls. Recruiting beta users is also your first marketing experiment: test channels and messages, and note carefully which ones produce sign-ups. If recruiting is hard even with a validated problem, treat that as serious data, not bad luck (it's one of this stage's stop conditions). For B2B, structured pilots with named success criteria turn beta tests into future case studies.

Test initial marketing tacticsTry several channels and messages for recruiting beta users; track what each produces.
Evaluate marketing tacticsWhich channels delivered users at what cost/effort? Keep the winners for go-to-market.
Pilots / case studies arrangedStructured engagements with success criteria, designed to convert into references.

MVP Product Launch

MVP built and customer-ready for testing and measuring.

"Customer-ready" doesn't mean polished — it means a real user can get to the core value without you sitting next to them. Roll out deliberately: a small first group, watch closely, fix what breaks, widen. Start your onboarding process with the very first user; how people experience their first ten minutes determines most of what follows.

Product rollout executedStaged release to beta users, with the team watching analytics and support channels.
Customer onboarding process startedA repeatable first-run experience that gets users to value fast.

Closed Beta

Get early adopters to test your product and provide feedback.

A closed beta is a controlled experiment, not a soft launch. Restate what you're hoping to learn, run a defined test process with a known group, and — critically — close the feedback loop: when a user reports something and you fix it, tell them. Users who see their feedback acted on become your evangelists; users who report into a void quietly leave.

Define what you're hoping to learnBeta-specific hypotheses tied to your MVP learning goals.
Beta test process establishedDefined cohort, duration, communication cadence, and success criteria.
Close the feedback loopEvery piece of user feedback acknowledged, triaged, and answered.

Resources

Centercode: beta testing guides and best practices

Beta Customer Feedback

Establish how customers will provide feedback for your product.

Make giving feedback effortless: an in-app widget, a shared channel, a simple bug form — whatever your users will actually use. Then treat the input systematically: log it, look for patterns in the UX, and separate "this is broken" from "this is missing" from "I don't understand this." The happiest beta users are also your first source of testimonials and case studies — ask while the enthusiasm is fresh.

Customer bug logging tools/processA frictionless way for users to report problems, feeding your tracker automatically.
Evaluate the feedback / UXSynthesize feedback into themes; watch real users navigate the product.
Get testimonials, references, and/or case studiesDocumented proof from real users — fuel for go-to-market and the investor pitch.

Quality Control

A testing process for beta product improvement.

Beta users forgive rough edges; they don't forgive losing their data or their time. Establish a basic QC discipline: triage bugs by severity, verify the product works across the devices and browsers your users actually have, check performance under realistic load, and re-test old functionality whenever you ship new code (regression). This isn't enterprise QA — it's the minimum rigor that keeps your beta credible.

Bug evaluation and managementSeverity-based triage with clear ownership of fixes.
Compatibility testingWorks on the devices, browsers, and environments your users actually use.
Performance testingAcceptable speed under realistic usage — slowness reads as brokenness.
Regression testingNew releases don't break what already worked.

MVP Readiness

Customer acceptance of the product's readiness for a public release.

The judge of readiness is not you — it's your customers. Are beta users coming back without prompting? Recommending it to peers? Would they be disappointed if you took it away? When beta customers accept the product as genuinely useful and your metrics back them up, you have the evidence to justify a public release in Stage 3. If acceptance is lukewarm, iterate here; scaling a lukewarm product just produces lukewarm results at higher cost.

Customer acceptance validatedRetention, engagement, and direct customer confirmation that the product is ready for wider release.

Part B — Validate the business model

Go-to-Market Strategy

How will you acquire customers/users and convert them to paying?

A great product with no path to customers is a hobby. Draft your go-to-market strategy now, while the beta gives you a live laboratory: which channels reach your early adopters, what message resonates, and what it takes to convert interest into payment. Define KPIs for the funnel itself — visitors, sign-ups, activation, conversion — so "marketing" becomes a measurable system rather than a series of hopeful posts.

Marketing activity plan / strategyTarget segments, channels, messages, and budget — grounded in what beta recruitment taught you.
Funnel KPIs definedMetrics for each funnel step, from first touch to paying customer.
Sales channel analysisMap possible routes to customers — direct, partner, self-serve — and their economics.

Sales Channel Testing

Test how you reach and acquire customers/users.

Don't just analyze channels — test them. Run small, cheap experiments in each plausible channel and compare results: cost per lead, conversion rate, sales cycle length, and quality of customer. Most startups eventually win through one or two channels; the sooner you identify yours, the less money you burn spreading thin across all of them.

Channel experiments run and analyzedReal data on which channels produce customers, at what cost, at what quality.

Customer Onboarding

A process for onboarding new customers/users to increase adoption.

The gap between "signed up" and "getting value" is where products die quietly. Build a deliberate onboarding path — a checklist, a guided first run, a welcome sequence — that takes a new user to their first success quickly. Measure where people drop off and smooth those steps. In Stage 3 this process must work without your personal involvement, so make it repeatable now.

Onboarding checklist createdA documented, repeatable path from sign-up to first value.

Revenue

Clearly defined revenue projections based on your product offering.

The beta is your pricing laboratory. Test willingness to pay with real asks, not surveys — discounted pre-orders, paid pilots, or simply charging for the beta. Define your pricing model and unit economics: what does one customer pay, what do they cost to serve, and what's the margin? Revenue projections built on observed behavior carry weight with investors; projections built on hope do not.

Pricing model / unit economics definedPrice, cost to serve, gross margin per unit — tested against real customers in your financial model.

Costs

A solid financial understanding of fixed and variable costs = operating costs.

Know exactly what it costs to run the company each month, split into fixed costs (salaries, rent, tools) and variable costs (hosting, support, transaction fees that scale with usage). This is the basis of your burn rate and runway — and the cost side of every unit-economics calculation. Your accounting software plus financial model should answer "what's our monthly burn?" in seconds.

Monthly expenses trackedFixed and variable costs reconciled between accounting software and the financial model.

Financial Model

A 24–36 month monthly financial projection model to determine the viability of your model.

Upgrade your Stage 1 spreadsheet into a real projection: monthly revenue, costs, and cash for the next 24–36 months, driven by explicit assumptions (customer growth, pricing, churn, hiring). The output that matters most is the cash line — when do you run out, and what has to be true to avoid it? This model becomes the quantitative backbone of your Stage 3 fundraise.

24–36 month financial model builtMonthly projections with explicit, documented assumptions and a clear cash runway.

Partners

Who will make it possible for you to deliver value to the customer?

Few startups deliver value alone — you may depend on suppliers, integration partners, resellers, or platforms. Identify the partners critical to your model and formalize the important relationships with agreements and NDAs. A handshake understanding that your business depends on is a risk; investors will ask about it.

Partner agreements / NDAs in placeKey dependencies documented and protected.

Part C — Formalize the company

Contracts & Policies

Created prior to capturing the first customer data (privacy, terms of use, etc.).

The moment a real customer touches your product, you have legal obligations. Before that happens, have your customer-facing documents in place: terms of service, privacy policy, and the contracts you'll sign with customers, employees, and partners. Letters of intent and MOUs from beta customers do double duty — they protect both sides and serve as traction evidence for investors. Use your Stage 1 legal partner; templates are a starting point, not a finish line.

Terms of serviceThe rules of using your product, accepted before first use.
Customer data privacy agreement / policyWhat data you collect and how you use it — required before the first byte of customer data.
Customer contractsStandard agreement for paying customers, reviewed by your lawyer.
Software license agreementTerms under which customers may use your software.
NDA / confidentiality agreementsReady to deploy for partner, vendor, and hiring conversations.
Customer letters of intent / MOUWritten commitments from beta customers — also powerful traction evidence.
Employment contractsIncluding IP assignment, so everything built for the company belongs to the company.
Partner agreementsFormalized terms with the partners your delivery depends on.

Patent Research

Is your product/tech patentable? Do you infringe on existing patents?

Two questions, both important: can you protect what you've built, and could someone else's patent stop you? A "knock-out" search — a first-pass scan for obviously blocking patents — answers the second cheaply. If your technology is genuinely novel, talk to a patent attorney about filing; a provisional application is a relatively inexpensive way to secure a priority date while you keep validating.

Patent 'knock-out' searchFirst-pass search for blocking patents in your space.
Patent filing (if applicable)Provisional or full application for genuinely novel technology.

Pitch Deck

Draft of a pitch deck for investors.

You're not fundraising yet — but drafting the deck now exposes the holes in your story while there's still time to fill them. The standard arc: problem, solution, market, product, traction, business model, competition, team, financials, ask. As your beta produces data, the traction slide fills itself in. Show the draft to your mentors; their confusion is a map of what to fix.

Draft pitch deck createdFull narrative arc, reviewed by mentors, updated as beta evidence comes in.

Mentors & Advisors

Continue developing early-stage mentors and advisors in industry, tech, and business.

Keep your Stage 1 mentors close and engaged — share beta results, ask hard questions, and listen when their reaction doesn't match your enthusiasm. One of this stage's stop conditions is "your story is not clear to your customers or mentors." That makes mentors part of your quality control: if you can't make them believers with real data in hand, the story (or the data) needs work.

Mentor relationships active and engagedRegular updates, honest feedback, and growing conviction from people who've seen your data.

Stage 2 exit check

Beta customers use the product without prompting and confirm it delivers the expected value. Recruiting new users is getting easier, not harder. Your story lands clearly with customers and mentors. Your unit economics make sense, and your legal and financial machinery is in order. That's solution validation — now go earn traction.

Continue to Stage 3: Traction & Investment →