Skip to content

Bets

This is where the rubber meets the road i.e. research, design, development.

Bets are specific actions you intend to take framed as experiments. Developing Bets is a skill, and must be nurtured in organisations that are used to a false sense of certainty. The DIBBs format below is one of the more complex ways to frame Bets but also a great way to start developing this skill.

You may wish to use a simpler format, especially when quickly sketching ideas out, but if you cannot frame it as a hypothesis with clear measures of progress you are taking shortcuts.

Bets size will vary based on the overall scope of your Hoshin Kanri:

  • Org level Hoshin: Bet’s could be 1-3 months work, a specific releases of a product or service e.g. alpha, beta, MVP, etc. with sub-tasks / Epics / user stories.
  • Team or product level Hoshin: Bets could be a day to a few weeks, focussed on a particular stage of the product development lifecycle e.g. “explore problem space”, “prototype solutions”, “test solutions” or the focus of an iteration.

At these small scales you may also see tasks like “set up regular showcases” appear but it is important to always be clear on how they relate to the bigger picture.

This template is based on the Spoify DIBBS model. Whilst it seems complex and can be difficult to complete it really forces you to consider and validate your ideas. See Spotify Rhythm for more information.

SectionNotes and examples
This data
Obtained from
Gives is the insight that
Leading to the belief / hypothesis
The returns / measures of progress will likely be

As tempting as it might be to dream up all sorts of new work as part of your new plan it is vital to start where you are. Whilst your existing portfolio of work, at the team or organisation level, may not meet the definition of a Bet or experiment if you do not include these in your prioritistion process against Strategies and Goals you are setting yourself up to fail.

There are many ways to prioritise Bets. Sadly in many organisations prioritisation is based on the highest paid persons opinion. I have also seen people agonise over this due to a percieved “lack of inforamtion”, often deferring prioritising work for many months until they have “enough” data. What they seem to fail to take in to account is teams will generally continue working on whatever they see fit.

I have found the ICE Prioritisation framework, simple quick and effective in cutting to the chase primarily due to it’s clear definitions for the “confidence” rating.