Tell us about how you prioritize today

2 months ago
27 April 2022
9 replies
110 views

Userlevel 1

Claus
Productboard
4 replies

We recently launched Formulas in Productboard. Enabling you to use well known frameworks such as RICE, WSJF or build your own custom prioritization formulas. Currently Formulas is limited to include Custom Number Fields. Next steps are to include:

User Impact Score
Drivers
Segments
Objectives

But before we do that, I am super curious to get some feedback on how you prioritize today. Here are some questions to get you started:

How are you using formulas for prioritisation?
How do you use drivers, whether with formulas or instead of them?
Do you use the Prioritization Matrix? Do you use it in combination with the Drivers or Formulas?
What prioritisation capabilities are missing from Productboard today?

Thanks for sharing your feedback with us!

9 replies

Userlevel 1

Here to follow.

Looking for a new paradigm. We were using Drivers but those cannot be applied to sub-features which is how we structured a lot of our use.

Userlevel 3

Mmcclain
Collaborator
21 replies
2 months ago
28 April 2022

My hope is to get us moving towards RICE but as of now the company tends to use really loose projection ideas to prioritize, and more at a whole project basis.

They apply basic 1 to 5 scoring, discussed as a group to some categories.

Where it gets weird: The first three is where high scores mean “low” risk or “low” use of resources etc. So you have to score it backwards from what the effort score is.

Risk
Engineering Resources
Development Complexity

and then these are just other gut checks around other factors.

ARR Potential (I guess more like related to maximizing LTV for customers?)
New revenue Potential (I guess related to new sales?)
Customer Satisfaction (I guess related to projected NPS impact?)
Customer Retention (I guess related to keeping customers signed up?)

Then each one gets a fixed weight applied. For example ARR potential might be weighted x3, Development Complexity weighted x1 and all others x2. And then they just score based on the average of allthat. So you get a mess like

((Risk x 2) + (Resources x 2) + (Dev Complexity x 1) + (ARR x 3) + (New Rev x 2) + (Satisfaction x 2) + (retention x 2) ) / 7

So - I REALLY hope we can move to RICE even if they feel like they need some extra multiplier in the impact score or something. I was toying with changing it to “PRICE” with the extra P for “perception” meaning that we don’t know if many users will actually USE something or really be impacted by it - but it’s something that helps get the foot in the door.

Moving forward it would be great to be able to eventually integrate with Pendo - like map a given feature usage metric to at least something that can be added to the “Reach” value in a formula.

Userlevel 3

Moving forward it would be great to be able to eventually integrate with Pendo - like map a given feature usage metric to at least something that can be added to the “Reach” value in a formula.

Our upcoming custom fields API will allow for precisely this. If you’re willing and able to use the APIs, you can sync the output of an analysis to a feature custom field, which will be compatible with our formulas. We’re starting with the API rather than native integrations as most customers store metrics in different locations and we wished to be interoperable with all systems.

I would be curious how you’re using “reach” today. I understand many PMs classify reach as the volume of users that can be reached, rather than the number of people currently using the feature.

Userlevel 1

Claus
Author
Productboard
4 replies
2 months ago
29 April 2022

Here to follow.

Looking for a new paradigm. We were using Drivers but those cannot be applied to sub-features which is how we structured a lot of our use.

Hi Michael,

Thanks for sharing this. It is truly helpful. Can you tell me about how you work with subfeatures today?

Userlevel 3

Mmcclain
Collaborator
21 replies
2 months ago
29 April 2022

I would be curious how you’re using “reach” today. I understand many PMs classify reach as the volume of users that can be reached, rather than the number of people currently using the feature.

I’m not using at all today. But I guess if I had a feature that was directly related to another feature I could estimate how many active users would take advantage of it, vs. features that don’t have an existing user base.

For example, we have a feature that allows a user to “Clone Instrument Record” for equipment in their plant. And let’s say I put a feature in PB “Multi-Asset Clone” or some related. I might want to map in the # of users who use the existing Clone function as a potential reach for adding a new feature to it. Whereas other areas of the app are for different user roles. It’s just a theory.

When I really think about it - I probably need to walk before I run here and at least get RICE prioritization reasonably right before I go automating a bunch of stuff that is an incorrect interpretation. 🤔

I love the idea of having custom fields in APIs! My coding skills are stuck in the early 2000s though. 😬

awachsman
Navigator
1 reply
2 months ago
3 May 2022

This is exciting! I had noticed the formulas and have been waiting to be able to use User Impact Score and/or Segments’ Scores or driver scores within the formula. I don’t yet have a custom formula figured out but I know it would incorporate those scores dynamically. At the very least, using the RICE formula we would be able to replace a manually entered number for Reach and/or Impact with a calculated dynamic value based on insights or segments importance. The next step I would wonder about is pulling reach/impact numbers from our product analytics tool in some way - can the APIs accomplish that?

Userlevel 3

JeremyAlexander
Productboard
7 replies
2 months ago
4 May 2022

It absolutely can. Check out our custom fields API.

What analytics tool do you use? We’re considering some future native integrations that will allow for precisely this.

Userlevel 3

JeremyAlexander
Productboard
7 replies
2 months ago
4 May 2022

I would be curious how you’re using “reach” today. I understand many PMs classify reach as the volume of users that can be reached, rather than the number of people currently using the feature.

I love the idea of having custom fields in APIs! My coding skills are stuck in the early 2000s though. 😬

Would it be possible to be supported by your engineering team? While we can’t advise on exact timelines, this is usually a day or two of work.