SAAS STAGE-TO-UPDATE PLANNER
A Buildside resource for SaaS founders
https://www.buildside.app/build-in-public/saas-founders

Choose the stage that fits your current decision. These prompts are a planning resource,
not a scorecard for product-market fit or a substitute for customer conversations.
All Handoffly examples below describe a fictional subscription product.

STAGE 1 — EXPLORE A PROBLEM
Decision: Is there a recurring problem for a specific person or workflow?
Public artifact: A problem statement and the current workaround.
Ask: Describe the last time this happened, what you did and what remained difficult.
Evidence to keep: Specific behavior, consequences, workarounds and untested assumptions.
Do not treat: A supportive comment as proof someone needs your proposed product.
Handoffly example: "Where does a handoff usually get stuck? If you coordinate a small
team, tell me about the last task you had to chase: what was missing, and how did
you resolve it?"
Next workflow: https://www.buildside.app/solutions/validate-saas-idea

STAGE 2 — TEST AN MVP
Decision: Can someone complete the core task with the available product?
Public artifact: A usable demo, prerequisites and a bounded test brief.
Ask: Try one task and describe where you pause, guess or cannot continue.
Evidence to keep: Observed steps, completed tasks, friction and expected behavior.
Do not treat: An enthusiastic reaction as equivalent to completing the task.
Handoffly example: "Can you hand off one task without a call? Try a sample task:
name the owner, add the context and confirm the next step. Where do you have to guess?"
Next workflow: https://www.buildside.app/solutions/find-saas-beta-testers

STAGE 3 — PREPARE A LAUNCH
Decision: Do relevant people understand what is ready and take the next step?
Public artifact: Clear product context, current availability, limits and an invitation.
Ask: Try the available workflow if it matches your task, and ask about anything unclear.
Evidence to keep: Actual participation, product questions and readiness gaps.
Do not treat: Attention or sign-ups as proof of continued product use.
Handoffly example: "The core handoff flow is ready: name the owner, add the context
and confirm the next step. Reminders are still planned. Try a sample handoff if
this matches your work."
Next workflow: https://www.buildside.app/solutions/launch-saas-product
If you are not ready for trials, explain what early access means:
https://www.buildside.app/solutions/grow-saas-waitlist

STAGE 4 — IMPROVE A LIVE PRODUCT
Decision: Does a change address a problem people encounter in the workflow?
Public artifact: The change, its reason, availability and a focused follow-up question.
Ask: People using the affected workflow to try it again and describe remaining friction.
Evidence to keep: Actual behavior, unresolved problems and the reason for the next change.
Do not treat: A clear release post as proof the change helped in practice.
Handoffly example: "We moved the owner beside the handoff summary so the receiver
can see who acts next. If you tried this workflow, walk through it again. What is
still unclear about the next action?"
Next workflow: https://www.buildside.app/solutions/prioritize-product-feedback

BLANK UPDATE PLANNER
Product and intended user:
Current stage:
The decision in front of me:
What is available now:
What changed or what I tried:
What I observed:
What remains uncertain:
The public artifact I can safely share:
The person whose experience would be relevant:
One focused question:
What evidence I want to keep:
What I will follow up on:
Link to the product and earlier context:

PUBLIC OR DIRECT?
Public: Product change, public-safe example, useful context, a specific question.
Direct: The person's real workflow, a recent detailed example, private or sensitive context.
Remove customer information you cannot share and use synthetic examples where appropriate.

KEEP THESE SIGNALS SEPARATE
Peer advice — a perspective that may challenge your thinking.
Usability evidence — what a relevant person does while attempting the task.
Customer demand — evidence about the problem, motivation and willingness to adopt.
Continued use — what happens over time inside the product.
A Buildside post's engagement alone does not establish the other three.

REVENUE IS OPTIONAL
You can share decisions, demos, milestones and lessons without sharing revenue.
Only publish figures you have actually measured and can explain.

Product history: Keep earlier questions, available capabilities and follow-up changes connected.
First-week guide: https://www.buildside.app/guides/building-in-public-saas