Product Bets

We want a framework to set, align and prioritize goals for Product Development company wide. In this system we track potential new products, variants and features of existing products on the high level.

Overview

Product Management uses Product Bets to capture, refine and rank features and variants for existing Products and the need for new products so that a Product Development team knows what the one goal is they’re working on at any time. Product Bets are the high level product road map.

Product Bets fit in our alignment framework below our 2-year goals and above the planning of the Product Development teams (who actually align themselves to these bets).

Product Bets are
  • about features that extend a product.

  • about variants that widen the potential use cases of a product.

  • about a new product.

  • reachable in a usable time. For example OpenShift 4 isn’t one, this is the name of the product (or technology) and therefore an ongoing topic. Instead we use something like VSHN Managed OpenShift 4 on Provider X at maturity level 1 so that we can measure and find out when a Bet is won.

  • not changes (including small feature requests), which are usually evaluated and either done or rejected by the Product Team directly.

Product Bets are coming in from two directions:

Outside-in

A Customer Solutions team sees demand from one or multiple customers. As we don’t want to block our customers waiting for a Product feature, Solutions Teams can and should build a custom Solution instead.
As soon as we see increasing demand, usually from multiple customers, for more or less the same solution, we should consider creating Product Bets.

Inside-out

Product Management observes the market, works-closely with our sales and might see trends that we as a company should follow. This could mean defining and creating a product inside-out without having a customer yet. This will also go into Product Bets.

The word bet comes from the fact, that we never fully know that something is really the correct thing to do, instead we bet that this will bring us closer to our goals and observe how our efforts change the situation.

Framework

We create, maintain and rank Product Bets in the Jira project VSHN Product Bets (PBET) with the issue type Product Bet.

Product Bets is the Governance (Steering) Backlog while Epics, Projects and Tasks are the Operational Backlog.
No product development work will actually happen on this issue type, it’s solely used for Product Bets. The actual work is done on tasks in the respective Jira project of the Product(group).

Board

Using Kanban boards we show all Product Bets in a Later-Next-Now 3 column view:

Later (Backlog)

This is the backlog, all Product Bets start here. Product Management refines all bets together with the stakeholder until they have a usable quality (for example ensure the Bet Format is used and all data is filled out correctly) and ranks them into the existing backlog.

product bets backlog
Next

Product Management moves bets from the top of the Later column to the bottom of this column as soon as we’re ready to start research on the topic of the bet to further refine it.

Now

Product Management moves bets from the top of the Next column to the bottom of this column.

product bets now next
The Next and the Now columns are periodically approved by the Products Delegate Circle, as are any changes on already agreed ranking.

There are also a Done and Dropped states in the workflow to mark bets as done or drop them during refinement.

Ranking

Product Bets don’t have priorities (Jira priority) or due-dates. We simply rank the bets in the Kanban view of Jira. Reasons for this are:

  • Priorities aren’t designed for long lasting topics, over time everything will end up as the highest priority (as urgency increases).

  • Ranking is absolute, where priorities are always relative to all other bets.

  • We’re only interested in the top most bet of each column, to know what we should currently work on.

It’s okay that one team works on bet #1 and the other team on bet #2.

Ranking is done by asking in a team effort (Product Management Interest Group or Products Delegate Circle) If you can only do one of these 2, which one would you do, and why? and then repeat this, until we’ve got a fully ranked column.

Bet Format

We’re not yet sure how the format of our bets will look like, we start somewhere and improve as we go.

Minimum content of a bet
  • A title (Summary in Jira)

  • Owner - owner from Product Management (Assignee in Jira)

  • Key stakeholders

  • Team Sponsor - owner in the team (usually a Product Owner) once it’s clear which team works on the bet

  • Success Metrics - how to check that we reached this bet

  • Related bets as Jira links (relates to)

The description is written using the DIBB format
  • Data - what we observe

    • Customer need

    • Financial backing and constraints

    • Market analysis

  • Insight - how to interpret this data

  • Belief - what we think this means for us

  • Bet - how we think we can address this situation

Unfortunately, there is no official definition of DIBB, just a blog post and slides. we’ve to find out whether DIBB is the right thing for us and how we use it.

Focus in Product Development

A Product Development team works on exactly one Product Bet at a time. This enables focused teamwork and simplifies planning.

Product teams will create Epics or Projects to work towards a Product Bet. This relation is linked by using a Jira issue link, giving us the chain of why in both directions:

  • The Product Team always knows and sees why they’re working on a project / epic.

  • Product Management will always see which projects or epics address a product bet—eventually also telling when we reached a bet.

A Product Team still has other work besides working on the active Product Bet like handling bugs, small feature requests, support, etc.

This process is tracked and reviewed as VIP-28