While learning from Atlassian’s own material — especially how their internal teams handle idea triage — one thing stood out immediately: Discovery is treated as a filter, not a funnel.
I’ve been studying Atlassian’s walkthroughs on how their teams use Discovery, including:
- How one team in Atlassian uses Jira Product Discovery — Part 1
- How one team in Atlassian uses Jira Product Discovery — Part 2
Across those examples, a consistent pattern emerges. Ideas are expected to:
- move slowly at first
- remain ambiguous early on
- earn their way forward through clarity, not urgency
That framing became the foundation for how I set up my own workflow.
The core principle behind the setup
Instead of designing my workflow around stages or statuses, I designed it around questions. Each step exists to answer one specific question.
An idea cannot move forward until that question has been answered clearly. This is how I prevent Jira Product Discovery from turning into a prettier backlog.
Why I didn’t use the default workflow
Jira Product Discovery’s default workflow is reasonable — but it’s designed to be flexible for many teams, not prescriptive for design-driven work.
That becomes a problem when you are deliberately practicing design-driven development.
From Atlassian’s own internal examples, one theme kept surfacing:
Most failure doesn’t come from execution. It comes from skipping steps in thinking.
Default workflows optimize for motion. Design-driven work needs guardrails that slow things down.
I also learned from structured product-thinking instruction that emphasized sequencing decisions over shipping features: understanding the problem, challenging assumptions, and only then shaping a solution. Without explicit stages that enforce this sequence, tools like Discovery tend to collapse into a backlog with better labels.
That’s why I adapted the workflow to:
- explicitly separate problem framing from solution shaping
- delay execution until constraints and structure are clear
- add a deliberate pause to challenge assumptions before building
These changes weren’t cosmetic. They were necessary to make the tool support thinking, not just tracking.
The mental model behind the workflow
The instructor whose material I’m learning from consistently reinforces one core idea:
Good product work is about sequencing decisions, not just making them.
That principle is embedded directly into this workflow. Each stage exists to answer one question. An idea only moves forward when that question has been answered well enough to justify the next step.
This sequencing is what keeps Discovery from turning into a feature factory.
How this maps to the triple diamond
The triple diamond model describes three cycles of divergence and convergence that move from ambiguity to execution.
This workflow mirrors that shape intentionally.
- Problem space: ideas are captured, framed, and explored without commitment
- Solution space: problems are challenged, shaped, and structured
- Concrete space: execution happens, outcomes are evaluated, and learning feeds back into discovery
Execution begins only after decisions are made. Learning never stops at “shipped.”
Full mapping overview
| Triple diamond | Thinking mode | Jira Product Discovery states |
| Diamond 1 - Problem space | Diverge -> Converge | Inbox -> Proposed -> Needs more information |
| Diamond 2 - Solution space | Diverge -> Converge | Backlog -> Wonder -> Explore |
| Diamond 3 - Delivery & learning | Build -> Reflect | Make -> Impact / Shipped |
What each step is for (and why it exists)
| Step | Purpose | What happens here | Design-driven development alignment |
| Inbox (triage) | Capture raw signals without commitment | Ideas are captured the moment they appear. No framing, prioritization, or judgment yet. Prevents losing ideas or promoting them too early. | Early discovery. Pure signal capture. |
| Needs more information | Create space to learn before committing | Constraints, unknowns, and affected areas are identified without jumping to solutions. Multiple systems may be involved, but no decisions on how yet. | Research and exploration. Divergence before structure. |
| Proposed | Turn a raw signal into a clearly framed problem | Ideas are rewritten to describe what is broken or missing, not what should be built. If it sounds like a ticket, it does not belong here yet. | Problem definition. Converging on intent. |
| Backlog | Commit to solving the problem without scheduling it | The problem is acknowledged as real and worth solving. Success is defined in behavioral terms, not implementation details. | Alignment before execution. |
| Wonder | Force a pause to challenge assumptions | The framing is pressure-tested: root cause vs symptom, special case vs foundational pattern. Prevents premature convergence. | Synthesis and reframing. |
| Explore | Define the shape of a solution before building | Constraints, boundaries, and contracts are defined. Still no tickets or sprints. This is design work in the product sense. | Converging from abstract problems into concrete solution space. |
| Make | Execute what has already been decided | Discovery pauses and delivery tools take over. Most meaningful decisions should already be made at this point. | Delivery. |
| Impact / shipped | Close the loop and learn | Outcomes are evaluated and new signals are captured, which flow back into the Inbox. Shipped does not mean finished forever. | Evaluation and iteration. |
Why this alignment matters
Most teams collapse all three diamonds into one:
- ideas become tickets
- tickets become code
- code becomes “done”
This workflow deliberately resists that collapse.
By aligning Jira Product Discovery with the natural rhythm of design thinking, it ensures:
- problems are framed before solutions
- learning happens before commitment
- execution follows clarity, not urgency
As execution becomes cheaper — through tooling, frameworks, or AI — judgment becomes the scarce skill.
References & influences
The workflow and mental models described in this post are informed by the following resources. These shaped how I think about product discovery, decision sequencing, and design-driven development.
- Atlassian — How one team uses Jira Product Discovery (Part 1: idea triage)
- Atlassian — How one team uses Jira Product Discovery (Part 2: Prioritisation)
- Userfocus — ISO 13407 is dead — background & implications
- Design thinking / Triple Diamond — Talk: evolving beyond the Double Diamond
