Opportunity solution trees and continuous discovery

  • 21 July 2022
  • 2 replies

Userlevel 7
Badge +12

I had a couple folks reach out over private message after reading @Amir_Rozenberg’s Medium article that we posted yesterday (read the post here), asking how I’ve approached continuous discovery using Productboard. In the interest of transparency, here’s an approach that I’ve followed in my past product work:

  • Use Objectives to capture the Desired Outcome (in OST). Alternatively you could also use a Component as you organize your thoughts then move these over to Objectives once you’ve settled on the priorities. You can’t track different levels of Objectives easily in Productboard -- most teams focus here on the product’s objectives
  • Use Components to capture the Opportunities (in OST). These can be nested if needed
  • Use Features to capture Solutions (in OST)
  • Create insights from notes and add to Components so you can track and identify the Opportunities most important to your customers. The User Impact Score can identify those for you.
  • Use Segmentation to narrow in on those Components most relevant to your target audience
  • Once you have the priorities established, then you can add your Solutions (or let your teams come up with those solutions) and add them as Features
  • Use the Objective's Value, Effort, Score, and Priority (you could also add Drivers and Prioritization scores) to help your teams make decisions about what solutions to proceed with -- especially when there are many competing solutions
  • And then tie in roadmaps so you’re communicating both WHY and WHAT you’re working on and WHEN it’s happening

While Teresa Torres’ visualization of this helpful, Productboard’s hierarchy can also be used. It’s just in a different form.

Some of the gaps I ran into:

  • Prioritizing Components today can only be done with Segmentation and User Impact Score -- most folks prioritize in Productboard using Features (Solutions in OST).
  • Some teams need more than a 1:1 relationship, they want to support a 1:many between child and parent, which we can’t easily represent in Productboard today. Tags could be an option here to show a connection. In my experiences these were few and far between though.

And for those interested, here’s a little Loom I put together awhile back that can help you see how this comes together.

And my amazing colleague @Jake Sawyer even built out a nicer looking demo in his test workspace (screenshot below)


Are you using continuous discovery? What capabilities do you use or need from Productboard? Let us know in the thread below, we'd love to hear your thoughts.


2 replies

Badge +1

This is brilliant, thank you for sharing! We are currently restructuring our product board hierarchy and are implementing the opportunity solution tree to help our small but mighty product team be laser focused on what to prioritise and build next. We are going to try using tags to tackle the parent/child issue. Will let you know how we get on!

Userlevel 7
Badge +12

Glad you found it helpful @Parveen Downer