Drivers are miscellaneous criteria you can use to surface interesting ideas or prioritize what to build next. They're particularly valuable for scoring features in the early phases of prioritization, since they can be used along with the prioritization score to sort/filter features.
Examples of drivers
Drivers are often framed as broad attributes. For example, if one of the core ways your product differentiates itself in a market full of clunky enterprise tools is through delightful user experience, you could evaluate all your feature ideas based on how much they'd contribute to the UX magic of your product.
Borrowed from the Kano model, one of the simplest ways to prioritize is considering to what degree each feature is simply expected, or would surprise and delight:
- Satisfier – Table stakes, baseline functionality necessary to compete
- Delighter – Exciting, innovative, or new functionality
To this you might add drivers representing qualities that help you stay ahead of the competition:
- Differentiator – sets you apart from the competition
- Spoiler – closes the gap between you and a competitor's differentiator
Other drivers might represent other positive outcomes that could be brought about by each idea:
- Cost reducer
- Platform reliability
- User delight
- User adoption
- User engagement
Drivers vs. objectives
Of course, if any of these are part of your primary focus at the moment, they would be best represented as objectives.
Objectives support a more robust prioritization workflow, allowing you to indicate a value for each feature as well as a final priority (must-have, should-have, nice-to-have). You can also use objectives to group features on your Roadmap, signifiying the outcome each feature is helping you achieve.
Note that only drivers can be used in conjunction with the Prioritization score at this time. This is in part because it's best to focus your team's efforts around one objective at a time.
Using drivers with objectives
Even when you're using objectives, drivers can still come in handy as secondary prioritization criteria.
For example, while your main objective may be to expand into a new market segment, you could use drivers like satisfier and delighter to indicate which features are tablestakes and which are innovative/unexpected.
You might also use a driver to represent something core to the way you differentiate in the market, or something near and dear to your team's product principles. An example would be a UX magic driver that keeps the team focused on shipping features most likely to delight — especially important when you're up against clunky competitors.
All in all, drivers are useful when you end up with too many "must-haves" within an objective and need additional criteria to decide which to build next.
How to add a driver to your Features board
Like all column types, you can show/hide drivers on your Features board using the configurations bar at right.
Toggle on the entire column group, then individual drivers.
Add new drivers by selecting [+] New driver.
A popular exercise for scoring drivers
Still not sure where to begin? Here's an exercise our team used to great effect when we were just starting out. It works best when you've already zeroed in on a major problem you'd like to solve or a significant piece of functionality you plan to deliver but still need to prioritize which features to include.
Add two drivers to your board:
- Satisfier – To what degree is this table stakes functionality? (basic/expected functionality that solves a key pain point in the product today or that users will be frustrated not to see in your product e.g. support for inline graphics in an email client)
- Delighter – To what degree is this exciting/innovative/new functionality that users will love but didn't know to ask for? (exciting enough to help you win new business)
Get your team in a room, and filter your Features board to zero in on those ideas currently under consideration. (This might mean filtering by a given status, component, or objective.)
- Learn more about how to customize your project's status values. 👀
Explain that you'll be scoring each feature from 0-5 based on to what degree it's a satisfier and a delighter.
To heighten the drama, give each teammate 10 seconds to write down each score on a slip of paper. Then on the count of three, have everyone share their scores. In cases where scores differ by more than one point, have a brief debate. The most senior PM in the room facilitates the discussion, acts as a tiebreaker, and helps the team settle on a final score.
When the exercise is over, you'll have scored all your features along two particularly valuable dimensions for making prioritization decisions. But you might just find that the very process of debating your disparate scores was the most valuable thing of all.
Using drivers to prioritize what to build next
Once you've scored your features along each of several drivers, you can sort/filter your board by individual drivers, or use the prioritization score to incorporate them all into a single value.
Enable a prioritization score on your board under Drivers & Scores. This is also where you can add a new prioritization score.
Customize how each driver is weighted into the final score:
You can even divide your score by the estimated development effort if you'd prefer to ground your scores in reality. But just as often, you'll find you won't have effort estimates at this early juncture. In fact, since estimates can be time-consuming for your dev team to generate (even more so if they're done accurately), you may only seek estimates for those features you think there's a fair chance you'll go build.
What comes next
If you're using drivers earlier in the prioritization process, you might have spotted trends as a result of this exercise that help you further group features into objectives. For example, if your drivers helped you surface many ideas related to driving new user adoption you could create an objective for this.
If you're carrying out this exercise after grouping features by objective, you could use driver scores or prioritization scores as additional criteria to help you set a final priority (must-have, should-have, nice-to-have) within an objective. Or they might help you decide which features to deliver now, next, or later by way of releases.