How to Build a Hypothesis-Driven Meeting Culture with Theso

Theso provides a platform for hypothesis-driven development, or HDD. Here, the hypotheses come first, and any development or building efforts come second. Hypotheses typically formulate the core idea behind a feature or business venture. As these hypotheses evolve, learnings are collected and iterations are recorded.

By being clear about underlying intent and learnings, the context is enriched, and the meeting cadence can be more flexible. The KPIs connected to hypotheses further contribute to making efforts understandable and real progress graspable, reducing the need for frequent sync meetings. With Theso, meetings can be triggered by events, instead of the calendar. Each transition in the process is sparked by something real — a hypothesis is approved, a milestone is reached, or a finding surfaced. A typical process could flow like this:

A hypothesis flows from ideation to approval, kickoff, through iterations and review, and finally to validation or invalidation. While HDD is event-driven, teams could still set a regular rhythm or release schedules. For example, a bi-weekly check-in might help to discuss implementation learnings or explore alternative directions, while a scheduled release date may help cut through bloat and emphasize delivery. A typical quarter might look like this:

Hypothesis Ideation

In Theso, an idea can be formulated at any point in time in the form of a hypothesis. If somebody has an idea, Theso provides the tools for AI-assisted ideation, while also pointing back at existing learnings, or correlating to ideas which may have already evolved. As hypotheses are the center piece, the maximum number of people should have access and be able to understand it.

There could be nothing worse than having a well-meaning colleague ruminating about an idea, which has already been shown not to work in a given situation. At the same time, a good idea should not be held back by hesitation about talking to a manager. The faster a great idea in the company can get from ideation to validation, the better it's going to be for the business.

Of course in Theso, hypotheses first start in the backlog / the inactive area. As long as hypotheses are not approved, they stay there until they are picked up for work.

Kickoff Meetings

Kickoff meetings in Theso start with the hypothesis. Once a hypothesis is created and selected for validation, the invites for the kickoff meeting can be sent out. During the kickoff, the hypothesis statement and the connected validation criteria or KPI are exposed to team scrutiny. After initial questions and concerns are cleared, the first iteration is planned.

The only things needed to kick things off are 1) a clearly defined hypothesis, and 2) a plan on how to reach the first iteration. Or, in other words, an initial plan to test what will most likely affect the validation metric, lead to prototype learnings, or lead to customer feedback.

Noticeably, a kickoff meeting doesn't have to lead to direct implementation effort. This is an important point in Theso. As the hypothesis and the validation metric are clearly established before the initial plan is created, the field of options is open for the product development team to set the best course of action, which may not always be software implementation. Again, this comes back to:

Validate your hypotheses as early as possible.

Fighting Planning Paralysis

One weak point of regular software planning processes is planning the same efforts ten times over, before the first step is made. With Theso, leadership can approve core hypotheses, and have teams gather learnings right away, instead of staying stuck in meetings that try to estimate the unknown.

Project Check-ins

To check in on projects, the easiest way is directly in the Theso dashboard. The intention and impact of each hypothesis is clearly defined and easy to grasp, via its confirmation metric. Business leaders and non-technical folks don't need another person to translate task progress into an estimation of impact — impact and iterations are directly visible.

Most of the time, teams are busy iterating — building prototypes, talking to customers, and watching metrics — and the dashboard reflects that steady progress. But when a hypothesis stalls — no meaningful iteration for a while, or only subpar progress — the check-in meeting is the moment to surface that and unblock it. It may be time to challenge the chosen approach, provide new information, or decide to try a different angle. Since efforts start from a slim hypothesis definition instead of a fully planned roadmap, adapting early is cheaper than pushing a dead end.

Iteration Reviews

Iterations in Theso are major milestones during the pursuit of a hypothesis — moments where the direction may meaningfully shift based on what was learned. Rather than inspecting partial progress on a fixed clock, an iteration review is triggered when a milestone is actually reached: customer feedback has arrived, a prototype has yielded results, or metrics have moved.

Iteration review meetings serve as a forum to build common understanding on the next iteration of the hypothesis. With the basis for an iteration gathered, the review is used to inspect the proposed change of plan and the actual outcome of the effort so far.

Hypothesis Outcomes

When an iteration review concludes that the KPI is confirmed, the hypothesis is marked as validated — the bet paid off, and the learning is recorded. If the review finds the approach doesn't work despite multiple iterations, the hypothesis is invalidated and the disproof is captured. In both cases, a final review documents what was learned, feeding back into the ideation pool for future hypotheses.

A validated hypothesis is always the preferred outcome, but the pursuit is designed so that even a disconfirmation provides value. Both paths should be mapped from the start. If confirmed, what is the benefit — are customers happier, is churn down, has conversion improved? If disconfirmed, you still gave an idea you believed in a fair shot. The solution space narrows, and the next best alternative becomes clearer. The team can either pivot to a different approach, or return to the status quo with new conviction — knowing the alternative was genuinely explored. The point is not to be indifferent to the result, but to ensure that either way, the team knows what to do next.