As a product manager, almost every big decision you make is a bet. You’re betting you know what users really want, what your engineers should prioritize right now, and how your startup will distinguish itself from the fray of competitors vying for market dominance.

Choosing the next features and functionality to build into a product is a tough call: should you prioritize a table-stakes feature or build something totally innovative that your competitors haven’t even thought of?

Calling major product decisions or new sets of features “bets” has become popular in the product management sphere because it gets product managers in the right mindset.

And that mindset is this: How confident am I that this bet will pay off, especially when comparing it to other possible bets?

In her book, Thinking in Bets: Making Smarter Decisions, Annie Duke clarifies that “a bet is a decision about an uncertain future.” So, a guess. Imagine someone playing poker who bets a few chips on a pair of kings. She doesn’t know what everybody else has – she just knows that what she has is pretty good.

When you’re a product manager placing a bet that has significant implications on your business, you want that bet to be as well-informed as possible. You won’t know the outcome – you’ll just know your odds of success are pretty good.

We’re a fledgling startup that makes several product decisions daily. We only have a couple engineers, and their time is very valuable, so we need to make sure they’re working on features that will make a positive impact on our users and our business.

Placing a bad bet wastes weeks of engineering time and cash runway, and placing a good bet directly results in a fresh cohort of satisfied users. The stakes are high, so bet selections are a big deal for us.

Here’s how we do it.

Building a good bet

Our bets comprise five parts. Each part is intended to build knowledge among the team about the likelihood of success or failure.

Bet

This is the feature or set of features our product manager is proposing, and his hypothesis for how it’ll pay off for the user and the company. We move one or two bets forward every two weeks.

This cadence keeps the team nimble: work is time-bound rather than scope-bound, ensuring we can pivot quickly.

Journey

This is how our product manager predicts the set of features will play out from the user’s point of view. His insights are informed by user interviews.

Our product manager will offer up one or two use cases illustrating how the user will optimally leverage the new features and how they will improve her experience in the app. Essentially, it’s a best case scenario if the bet pays off.

Assumptions

These are universal human behaviors or common learnings from user interviews that we can safely say are true for most people.

For example: users prefer to create a new account on an app in as few clicks as possible. I don’t need data to back up this claim – it’s safe to say that people prefer completing mundane tasks quickly.

Justification

This is where our product manager makes his case.

Each bet needs to be backed by data from user research, product metrics, user demographic metrics, etc. to convince the team to go full steam ahead. Our product manager has to be able to justify the company allocating resources right now to this proposed set of features.

Hopefully, your team is meticulous and discerning, and they’ll ask a lot of questions that you’ll need to have answers for. Backing your bets with as much relevant data and research as possible increases your odds of success, so this is the place to be really thorough.

Risks/Further Research

If there were no risks, it wouldn’t be a bet. We run through all the potential risks of following through on a certain bet, including thought experiments like  “users may expect x and we’d be giving them y.”

There’s no way to predict anything with 100% accuracy, and this is especially true when it comes to the delicate science of predicting user behavior, user retention, and product stickiness. Laying out all the risks and making a judgment as to whether they’re significant enough to render the bet infeasible is key to making an informed decision.

Similarly, identifying areas where further research is needed helps to identify bets that have potential, but should probably be tabled for a bit.

Presentation and debate

This is just as important as building the bet.

We hold bet selection meetings once every two weeks to decide which set of features our design and engineering teams will focus on next. Key decision-makers across the organization – including heads of engineering, design, marketing, and C-Suite executives – talk through each bet and vote on their viability.

Bet selection meetings aren’t just about reviewing the work you’ve done – they’re also an opportunity to gather even more information.

Product decisions and resource allocation affect every facet of the company, so it’s important to us that everyone has insight into these plans. Each department brings a hyper-specialized perspective to the bet that can illuminate additional variables, risks, and benefits the product manager may not have considered.

There is always the risk of having too many opinions in the room, and this can make it hard to make timely decisions. We all know how annoying it can be when there are too many cooks in the kitchen.

You need to have a way to hear everyone’s feedback, weigh the votes alongside the supporting data, and ultimately make the decision yourself as the owner of the bet.

Assessment

Implementing a simple method of consolidating feedback and assessing each bet ensures the varied opinions of the team do not stall decision-making.

At Classify, we’ll vote as a team on the status of each bet. This takes a bit of the pressure off – we don’t have to unequivocally vote “yes” or “no” to each bet. We leave room to revisit, revise, or de-prioritize certain bets in case there is too much uncertainty among the team to make a clear-cut decision.

Here’s our list of status labels:

Approved: This bet is good to go. The team agreed it should be a priority, the data and user research strongly support the hypothesis that it’ll pay off, and we’re ready for design, engineering, and any other involved teams to move forward and tackle this set of features.

Deferred: This bet is too risky or not worth pursuing at the moment. Either user research has shown this feature is not a priority, or the feature isn’t aligned with the current product vision. The bet may need to be changed a bit with the understanding that it’ll be revisited at a later date.

Shelved. Totally vetoed. The team and our users do not see value in pursuing this set of features. Some of the concepts part of this bet may come up again in a future bet,  but in its current form, it’s simply not a wise investment.

In addition to these status labels, we also have a grading system signaling how the product team feels collectively about the value each bet will deliver to the end user. Prior to each bet selection meeting, the product team meets to discuss each bet in detail and reach a consensus on their level of confidence that a bet will yield valuable results.

If the product teams’ research and intuition suggests the bet aligns closely with most users’ current needs and feedback, it’s labeled High Confidence. A grade of high confidence also signals engineering has verified they can implement the feature in the allotted time frame.

If existing research suggests a bet aligns with the product strategy or mission but there are remaining research questions the product team still needs to answer to be more certain, it’s labeled Medium Confidence. Finally, if the bet includes features that lack supporting research, it’s labeled Low Confidence. A low confidence bet would likely not be presented to the team.

While bet selection meetings include a cross-section of team members from key company functions, decisions about whether to approve, defer, or shelve a bet are ultimately negotiated between the Head of Product and the founders at Classify.

Tyler’s thoughts

Our Head of Product, Tyler Stone, presents bets to our team on a bi-weekly basis. It’s a lot of pressure.

This is what Tyler says makes a good bet:

“If I’m playing roulette I’ll mix up my strategy between safe and risky - safe bets more often than risky ones. You don’t want to lose everything, so you’ll take the occasional risk that you think might have a solid payoff. Luckily, in product, we have the ability to improve our odds through research. A bad bet can become good based on feedback from users. Ultimately, a good bet is one that your product team feels confident enough to justify to the broader team (despite the possible risk), while highlighting the benefits for both the user and the business.”

And this is a common mistake he thinks you should avoid:

“A bet is more than a single feature or list of features. Features are a part of a journey that you’re betting will benefit the user and the business. If a journey is well-defined, it describes the features you must implement to achieve the desired outcome. The bet also clearly denotes the scope of those features.”

That’s the rundown on building, presenting, and assessing product bets. Good luck.

Oh, and if you’re feeling frazzled and overwhelmed at work, try Classify. We built it specifically for product managers. It’ll help you stress less.