Opportunity solution trees and continuous discovery


Userlevel 7
Badge +13

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.

 


17 replies

Userlevel 4
Badge +4

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 +13

Glad you found it helpful @Parveen Downer 

Userlevel 5
Badge +2

This really is awesome Scott, I think translates quite well, we’re adding some of these terms in a little so I will come back and add some feedback in a few weeks.

Userlevel 7
Badge +13

Look forward to it @ashivory 

Badge +1

This is great, I was wondering how to work with continuous discovery alongside Productboard.

Do you have any tips how to transfer existing hierarchy of features to the the opportunity tree or are you running these in parallel? 

Userlevel 7
Badge +13

Hi @Daniel,

The foundation of continuous discovery is built around interviewing, prototyping, and testing assumptions. Productboard can support each of these. The interviews you do and bring into Productboard as notes and turn into insights to inform your strategy and understanding of your customer’s needs. Prototyping you can do as you explore possible solutions with the very customers that shared feedback with you — which you have access to (and feedback from those continued conversations can feed additional notes and insights). And finally, you can test and validate your assumptions using those to feed ongoing learning as well. 
 

You may not need to fully change your hierarchy to do this work. What you have could work just fine. But you could do them in parallel too. I wouldn’t overthink it. Key overall is ongoing interactions with your customers. 

Userlevel 1
Badge

A obstacle that I’ve encounter with this approach is that one solution(feature) can be part of multiple trees or multiple opportunities within the same tree. A feature request would be to be able to show/link the same feature multiple times and that the content of it is similar. I want to reduce the need to have to update the description of the same “feature” multiple times. 

Userlevel 1
Badge

As an example, this structure is not possible to create within Productboard? See highlighted part on the OST.

 

Userlevel 7
Badge +13

@andyjohansson thats correct given the limitations of the current hierarchy. One option however here might be to nest components within each other.

 

Userlevel 1
Badge

Alright, thanks. Are Productboard considering facilitating these kinds of trees in some kind of new feature / capability? 

Userlevel 7
Badge +13

@andyjohansson nothing in the immediate plans, but I’ve shared your feedback with our team.

Userlevel 1
Badge

Alright, thanks for that 🙏

Badge

We create the opportunity - solution tree using the feature - subfeature logic. Any advice on how you include assumptions as part of that logic in Productboard?

Userlevel 7
Badge +13

@Jeroen assumptions are typically stated as part of solutions, so I would suggest including them in the description. Alternately, you could use sub-features for your experiments to test those assumptions or you could use sub-features to capture those assumptions. Keep in mind that Productboard wasn’t created specifically to support OST, but you can be creative in finding ways to include those elements in the work you do.

Userlevel 1
Badge

+1 on @scott.baldwins response @Jeroen.
Really hope we can get a dedicated view in the future to support OST 🌲

Badge

Thanks for this example, @scott.baldwin !

Did anyone find a decent workaround for contrasting and comparing opportunities based on the CDH framework?

As pointed out by Scott above, it is impossible to prioritize components. My initial approach is ranking the first feature (=solution in CDH) within the respective opportunity or setting up a placeholder feature if none exists.

Userlevel 7
Badge +13

@hannes.lachmann as noted, Segmentation and User Impact Score can be used to prioritize with components. So you could compare and contrast using those. For example components with the highest user impact score that address your target customer would be best to start with.

Reply