The concept
Connect the work to the why.
A shared space for people and AI to connect intentions, decisions and evidence of what changes.
Most teams can tell you what they delivered. The harder question is what changed — and whether their work made a meaningful difference.
The Focus Room explores a different way of working. A shared space where people and AI connect goals, observations, decisions and outcomes. It brings the reasoning behind choices into view, keeps assumptions separate from evidence, and helps everyone learn from what actually happens.
Not another task tracker. A living picture of what matters, what we’re doing
Align → Decide → Act → Evaluate → Learn
Shared context · Clear contribution · Continuous learning
Goal / shared intention
Start with what matters.
Fictional viewpoint · initiative owner
As the initiative owner, I begin with the outcome we want people to experience. A completed setup flow might be convenient for our team to measure, but it is not necessarily valuable to the person using the service. I ask users what they want to achieve, and I invite product and support colleagues to describe their interests and concerns. Together we agree on a provisional definition of a useful first outcome. The Focus Room is intended to retain that shared intention and the different perspectives behind it. We have aligned on what we are trying to learn—not proven that anyone has benefited yet.
Before I ask anyone to build something, I need to understand what success means. Our goal is not simply to get new users through setup; it is to help them accomplish something useful. The product team, support team and users may all see that goal differently. The Focus Room is designed to keep those perspectives connected, so every observation and decision can be related back to what matters.
- What we know
- In this fictional example, helping new users reach a useful first outcome is the team's intention. It is not an achieved result.
- What remains uncertain
- Different users may value different outcomes. What would meaningful success look like from their perspective?
Shared goal → gives incoming observations their meaning
Observation / a clue
Notice when reality doesn't match the plan.
Fictional viewpoint · initiative owner
Two small pieces of information reach me. In a fictional support conversation, a newcomer says they were unsure what to do next. In a separate fictional session note, someone pauses during setup. Instead of immediately creating two tasks, I record the observations and where they came from. I can see why they matter: we want people to reach a useful first outcome. But I cannot tell whether these examples are typical, whether a technical error occurred or whether the people expected something different. The Focus Room is designed to preserve both the signal and the uncertainty, so a plausible pattern does not become a fact by repetition.
I begin to hear that setup is confusing. A support conversation describes someone getting stuck, and a separate fictional session shows another person hesitating. These are observations with different sources, not proof of a widespread problem. The Focus Room can connect both clues to our goal and keep their context visible. Before drawing conclusions, I need to know who was affected, when it happened and what else might explain it.
- What we know
- Our fictional sources are support conversations and a single observed setup session. They describe experiences, not a representative success rate.
- What remains uncertain
- Who else experiences this? Under what circumstances? What evidence are we missing?
Observed signals → raise a question about our shared goal
An important question
Turn a concern into a question worth answering.
Fictional viewpoint · initiative owner
Our shared intention is to help newcomers accomplish something worthwhile. The reports suggest that some may struggle before reaching it. I identify a tension: are we unintentionally making that first useful outcome difficult to reach? This is a reason to pay attention, not evidence that we know the cause. A tension can also represent uncertainty or an opportunity, not only a problem. By linking the support report and the session note to the same question, The Focus Room could keep the concern focused and traceable. Now I can decide whether it needs clarification, who should own the investigation and what further evidence would help.
There may be a gap between what we want people to achieve and what they are experiencing. In The Focus Room, I call that a tension: a meaningful question, uncertainty or opportunity linked to a goal. It is not a confirmed diagnosis and not automatically a task. Several signals can point to the same tension. That gives us one question to investigate instead of reacting separately to every comment.
- What we think
- The setup experience might be preventing some users from getting value from the service.
- What remains uncertain
- Is the barrier the instructions, a technical problem, different expectations—or something else?
The gap we notice → becomes a focused question to explore
Explore explanations
Understand the problem before choosing the fix.
Fictional viewpoint · initiative owner
The first explanation that comes to mind is unclear copy, but that is only one possibility. A technical fault could make the same screen confusing, or people might be trying to achieve a different goal from the one we designed for. I ask colleagues to look at observed sessions, relevant error information and the original user expectations. We record where those observations come from and which alternatives remain credible. AI might eventually help connect sources and surface patterns, but it should not turn an attractive story into an established cause. Clarifying a tension means making the next choice better informed while protecting the history of what was uncertain.
I resist jumping straight to a redesign. Maybe the instructions are unclear. Maybe setup fails technically. Or perhaps people expected something different from the service. I keep these explanations side by side and ask what evidence could distinguish them: sessions, error reports or conversations with users. The Focus Room should make both the reasoning and what we still do not know visible, even when one explanation sounds convincing.
- What we think
- Unclear instructions may contribute to the confusion. Technical failures and mismatched expectations are credible alternatives.
- What remains uncertain
- We need a clearer definition of success, observed user journeys and details of any actual failures.
Different explanations → shape a more informed decision
Choose a testable action
Make a decision that can teach us something.
Fictional viewpoint · initiative owner
I have enough context to choose a next step, but not enough to claim a root cause. The team considers changing the copy, investigating technical reliability first and interviewing users about their expectations. We choose a bounded experiment: simplify one part of setup for a limited group and compare what happens with our prior observations. In The Focus Room, I would connect the decision to the goal, the tension, the hypotheses, the accountable owner and the evaluation criteria. The decision matters because it makes an assumption testable, not because an action item has been created. We remain prepared to revise the plan if new evidence points elsewhere.
We choose a small experiment rather than rebuild the entire experience: simplify one part of setup for a limited group. I record why this option was chosen, which alternatives remain open and who is responsible. I also agree in advance what we should observe afterward. The decision is not a declaration that we know the cause; it is a deliberate, limited action that can help us find out.
- What we expect
- Clearer setup may reduce confusion and make a useful first outcome easier to reach. This is still a hypothesis.
- What remains uncertain
- The test might reveal a different cause. We need to observe unintended effects and avoid treating setup completion as the whole goal.
An informed decision → defines an action and how it will be evaluated
Expected effect / prediction
Say what you hope will change.
Fictional viewpoint · initiative owner
We have chosen to test a simpler setup flow, so I state the theory behind the choice before anyone implements it. If unclear instructions are contributing to the difficulty, making them simpler might reduce confusion. But completing setup is only a possible intermediate signal; the outcome we care about is whether someone accomplishes something useful. We agree on what to observe, what qualitative questions to ask, who will evaluate the results and when. We also note that an improvement might come from other changes or differences between participants. The Focus Room is meant to preserve that forecast separately from the observations that arrive later.
Before the change goes live, I write down what I expect: less confusion during setup and, more importantly, more people reaching a useful first outcome. I decide what evidence would support or challenge that expectation and what unintended effects to watch for. This is a forecast, not a result. Recording it now prevents us from changing the definition of success after we see the numbers or stories.
- What we expect
- People may understand setup more easily and be better able to complete their first meaningful task.
- What remains uncertain
- If people finish setup but still get no value, the change may not have achieved what matters. The predicted effect is not evidence.
The prediction we record beforehand → can be compared with later observations
Action / delivery
Build the change. Keep the question open.
Fictional viewpoint · initiative owner
The team implements the bounded change and puts it in front of the small test group. The action is complete in this fictional example. We can trace the delivery back to the responsible decision, its assumptions and the intended outcome. That connection is important: it shows what we did and why. But an implementation milestone only demonstrates that work was completed. It does not establish that confusion decreased, that users found the service more helpful or that the new copy caused any improvement. In The Focus Room, delivery should become the starting point for evaluation, not the end of the story.
The team builds and tests the simpler setup, then makes it available to the fictional test group. We can now say that the agreed action was delivered and trace it back to the decision that authorised it. But delivery is not the same as value. A finished feature, merged pull request or successful release does not tell me whether people actually benefited. I still need to look at what changed for users.
- What we know
- The fictional prototype was created and made available to the limited test group.
- What remains uncertain
- Did it actually help? For whom? Could something else explain any improvement?
The delivered change → creates an opportunity to observe outcomes
Observed outcome / evidence
Look at what actually happened.
Fictional viewpoint · initiative owner
After the test, I separate what actually happened from what we hoped would happen. In the fictional observations, some participants complete setup; others still struggle. We have limited qualitative reports and do not know whether the group reflects the wider audience. Even when a person finishes setup, we still need to ask whether they achieved their first useful outcome. These observations are valuable because they challenge our assumptions and point toward the next question. But we should not turn anecdotes into a measured improvement or treat correlation as proof of cause. The Focus Room is designed to keep the sources, missing evidence and context attached to what we observed.
I look at the experience after the change. Some fictional participants finish setup, while others still hesitate or stop. I also ask whether finishing helped them achieve anything useful. Each observation should keep its source, context and limitations attached. A handful of encouraging examples may help us learn, but they do not represent everyone and do not prove that our change caused the difference.
- What we observed
- In this fictional test, some people complete setup while others still struggle. These are limited qualitative observations.
- What remains uncertain
- We don't know how representative the sample is, whether the change caused improvement or whether people achieved their actual goal.
What we observed → provides evidence for evaluating the earlier prediction
Weigh the evidence
Did the change make a meaningful difference?
Fictional viewpoint · initiative owner
Now I return to the original question. Did the simpler flow help people reach a useful first outcome? We know the fictional prototype was delivered, and we observed some participants completing setup. That does not tell us whether our intervention made the difference or whether the completed setup led to value. We compare the prior forecast with the limited observations, consider missing information and keep alternative explanations in view. The evidence is compatible with improvement, but not strong enough to establish magnitude, representativeness or causality. In The Focus Room, that is a legitimate evaluation: a finding can remain uncertain, rather than being forced into a green status.
I compare the forecast we wrote down before the experiment with what people actually experienced afterward. The simpler flow may have helped, but this small test cannot tell us how much, whether it caused the difference or whether users gained lasting value. The Focus Room is designed to make that uncertainty explicit. A sound evaluation can support an explanation, challenge it or leave it unresolved; it should never manufacture a success story.
- What we know
- A fictional prototype was delivered, and some people completed setup during the small test.
- What we think
- Clearer instructions could have helped, but other explanations remain possible.
- What remains uncertain
- We cannot yet establish the size of any improvement, its cause or whether users reached a meaningful outcome.
Evidence weighed against expectations → informs what the team learns
Learning / the next question
Let what you learned change what happens next.
Fictional viewpoint · initiative owner
The experiment has not produced a simple victory, but it has improved our understanding. We now realise that finishing setup and reaching a useful first outcome are not the same thing. I revisit our goal and ask what happens after setup, particularly for people who finish the screens but still fail to achieve anything meaningful. That becomes a follow-up tension for the team to clarify. The Focus Room should preserve the original goal, signals, hypotheses, decision, forecast, action and evaluation without rewriting history. Each new observation can strengthen, challenge or change the next choice. That is the point of the loop: act with intention, evaluate with humility and learn together.
A better question emerges: what happens after someone finishes setup? If they never achieve a useful outcome, we may have improved a step without improving what matters. I keep our earlier reasoning and decision history, update the assumptions and open a new tension to investigate. Learning is not the final box on a checklist. It reconnects the next decision to the original goal, with more context than we had before.
- What we know
- The fictional evidence isn't strong enough to claim that meaningful value was created.
- What remains uncertain
- What happens after setup? Which user needs are still unmet, and what evidence should we seek next?
Learning ↻ updates our understanding of the goal and opens a better question
