01 — Idea / Problem
Purpose: Frame the problem clearly so the cycle starts with the right focus.
Outcome
A clear problem statement and context captured in SwiftCNS.
This stage is about creating enough clarity that the rest of the cycle has somewhere real to stand. If the problem is fuzzy, the rest of the loop tends to become increasingly interpretive instead of evidence-driven.
Time to complete
15-30 minutes.
Inputs
Project context.
Target user or customer segment.
Initial pain point and business relevance.
Steps in SwiftCNS
Open your project and start a new conversation.
Describe the problem, who has it, and why it matters now.
Capture constraints and assumptions already known.
Confirm what success looks like if this problem is solved.
Why this stage matters
Teams often want to move quickly to assumptions or solutions. That instinct is understandable, but if the problem is not framed well, the team risks testing the wrong thing with a lot of discipline.
This stage is where the team aligns on:
what problem is actually worth exploring,
who is affected by it,
why it matters now,
and what kind of outcome would indicate progress.
That gives the next stage a cleaner foundation.
Role lenses
Startup: prioritize the narrowest painful problem first.
Program manager: verify the problem aligns to program outcomes.
Mentor: challenge vague or solution-first framing.
What strong output looks like
A strong problem frame is:
narrow enough to be testable,
important enough to matter,
clear enough that the team can identify assumptions next,
grounded in a user, market, or operational reality rather than an abstract idea.
Weak vs strong pattern
Weak
broad or generic problem statements,
solution-first language disguised as a problem,
no clear user or stakeholder,
no explanation of why the problem matters now.
Strong
one visible problem in focus,
clear affected audience,
real context and constraints,
clear signal of why learning here matters.
Outputs
Problem statement.
Initial context notes.
Shared definition of scope.
Definition of done
Team agrees on one problem statement.
Scope is specific enough to identify assumptions next.
Common failure mode
The most common failure at this stage is false clarity. The team feels aligned because everyone can talk about the same idea, but the actual problem is still too broad or too vague to guide testing.
If that happens, narrow further. The best first problem statement is usually smaller than the team initially wants.
If blocked
Use Core Definitions to separate problem claims from assumptions.
Next step
Continue to 02 — Identify Critical Assumptions.
Last updated