Find your current stage
| Current reality | Stage | Exit check |
|---|---|---|
| The idea is based on observation or personal frustration. | 1 · Validation | You can name the buyer, recent incident and current workaround. |
| You can deliver the result manually, but the product boundary is unclear. | 2 · MVP | One input-to-result flow works without depending on imaginary features. |
| The workflow is clear, but implementation choices keep changing. | 3 · Stack | You can explain ownership, failure recovery and maintenance. |
| People understand the result, but the offer or price still feels arbitrary. | 4 · Pricing | The buyer understands the value unit and package boundary. |
| The product is usable, but qualified buyers are not entering the pipeline. | 5 · Acquisition | One eligible channel has been tested; responses, unknowns and the next permitted step are recorded. |
| Customers have access, but activation, repeat use or support is unstable. | 6 · Retention | You know where value appears, where users stall and what the product costs to operate. |
Stage 1: Validate the problem
Decision: Is there a specific workflow problem worth testing with a defined buyer?
Evidence: Recent incidents, exact language from the person doing the work, the current workaround, who owns the outcome and what happens when the task is delayed or done badly. Compliments about the idea do not answer these questions.
Next action: Document several recent incidents in the same format: trigger, person, steps, workaround, consequence and authority to buy. If the pattern is still vague, use the validation hub before designing the product.
Exit check: You can describe the problem without mentioning your proposed software, and the buyer recognises the situation.
Stage 2: Shape the MVP
Decision: What is the smallest complete workflow that produces a result the buyer can judge?
Evidence: The minimum input, the first useful output, states that can cause harm or confusion, steps that still require judgment and the fallback when automation fails. A list of requested features is not a workflow.
Next action: Draw one path from input to result. Label every step as product, manual operation or postponed. Then check the boundary against the MVP hub and Before retrying n8n, reconcile the local effect.
Exit check: A pilot user can complete the core job, and you know how to handle the failures that matter.
Stage 3: Choose the stack
Decision: Which implementation can you maintain when data is messy, an integration fails or a customer needs an answer?
Evidence: Data sensitivity, permission needs, expected integrations, backup and export requirements, deployment ownership, variable costs and the skills available to fix the system. Speed to prototype matters less if every incident requires a rebuild.
Next action: Compare no more than a few realistic options against those constraints. Record the failure mode and recovery owner for each critical dependency. Use the stack hub for the trade-offs.
Exit check: You can explain where customer data lives, who can access it, how it leaves and what happens when a dependency is unavailable.
Stage 4: Price and package the result
Decision: What unit of value should change the price, and what belongs in each offer?
Evidence: How buyers describe the result, what they pay or spend today, costs that rise with usage, support burden, time to value and objections heard in sales conversations. Competitor pricing is context, not a substitute for your own economics.
Next action: Write one value metric, one package boundary, one usage-related cost and one likely objection. Test whether a buyer can predict the bill and explain why a higher tier exists. The pricing hub covers the available models.
Exit check: The offer is understandable before a demo, and delivering it does not create an unknown loss on every active account.
Stage 5: Find the first repeatable route to buyers
Decision: Which reachable group has the problem now, and which channel can start an honest conversation?
Evidence: Buyer role, triggering situation, places where that buyer can be reached, replies that reveal timing or fit, sales objections and whether the promised result leads to activation. Follower counts and untargeted traffic do not show buyer access.
Next action: Choose one segment and check source use, contact eligibility, channel rules and stop requests before drafting or contacting anyone. If a required rule is unknown, wait. For an eligible channel test, record the reason for contact, response and next permitted step. Use the acquisition hub to shape the motion.
Exit check: You have recorded replies, any reasons people actually gave and the next permitted step. If someone does not reply, record the reason as unknown. Silence does not establish motivation or permission to follow up.
Stage 6: Make value repeatable
Decision: What must happen for customers to reach value, return and remain supportable?
Evidence: The first useful result, repeat workflow completion, failed imports, confusing permissions, unanswered notifications, support themes, cancellation reasons and the time required to serve an account. Usage alone can hide customers who are stuck.
Next action: Trace one recent successful account and one stalled account from signup to outcome. Treat differences as clues to investigate, not proof of a cause. Address security or data integrity issues first; otherwise, choose a reversible check of the suspected gap. The growth hub covers activation, retention and operating limits.
Exit check: Customers can reach the promised result more than once, and the support load remains compatible with the team running the product.