Design Tips are series of ideas and tips that can help you make the most of frameworks.
Idea Generation Frameworks
Decision Making Frameworks
Choosing a Prioritization Framework
This design tip is for people who are seeking to prioritize a Product Backlog or Project Portfolio and are trying to choose between Prune the Product Tree, Buy a Feature and the Planning Wall.
You have a set of Product Backlog Items or projects in a Project Portfolio and you want to prioritize them.
Which prioritization framework should we use?
This depends on your primary area of emphasis. The following table should help
What items should we include?
We recommend only including the items for which you have questions.
If you know that really must do one or more things, then just tell your participants that you’re going to do those things. For example, suppose you have to implement a project for regulatory compliance. Don’t ask participants about this project because there is no choice.
If you know for certain that you’re not going to implement a feature or implement a project than don’t ask your participants to prioritize it, because if they make it their #1 choice you’re going to just disappoint them!
Is there a Recommended Ordering?
While each of these frameworks can stand-alone, there are some recommended sequences.
1. Strategic prioritization should precede tactical prioritization. This means that if you’re planning on both, do Prune the Product Tree before Planning Wall or Buy a Feature.
2. Shape items before their final prioritization. At Conteneo, we use Planning Wall a lot for internal planning. The shaping process typically provides us with the answers we need and from an internal perspective we often don’t need an additional Buy a Feature. However, keep reading!
3. Don’t assume you know your customers desires! The only way to really know what your customers want is to engage them in some way (e.g., observe their behavior, look at logs of system use, and of course, invite them to forums). At Conteneo, we’re especially fond of Prune the Product Tree and Buy a Feature.
Of course, you may be facing design considerations not listed here that motivate different design choices. If that is the case try to make these design considerations transparent so that everyone understands the tradeoffs.
Please contact us if you have any further questions.
Single Proposals Preferred Design Pattern
This product tip is for people who are designing Buy a Feature, Buy a Project, Participatory Budgeting, or other collaborative funding frameworks using Decision Engine.
You’re designing a forum and you have three proposals:
Proposal 1, $40K
Proposal 2, $50K
Proposal 3, $20K
Let’s further stipulate that while each of these proposals are separate, they are related. For example, in a business these might all be marketing proposals. In Participatory Budgeting, these proposals might all be related to public safety or parks and recreation.
(a) Should you keep the proposals separate or should you bundle them into a single proposal? Meaning, should you have one big proposal for $110K that includes Proposals 1, 2 and 3?
We recommend keeping the proposals separate. See the Design Considerations for reasons why.
(b) Should you include BOTH the bundle AND the separate individual proposals in your forum?
We recommend only including individual proposals. See the Design Considerations for reasons why.
Design Considerations (Forces)
Here are some design considerations / forces that we have considered in making our recommendations.
(1) You want to understand the priorities of the group relative to each proposal. This suggests that you want to keep proposals separate because bundling proposals makes it hard to understand individual priorities. Consider, for example, a participant who supports Proposals 1 and 2 but is opposed to Proposal 3. Bundling proposals makes it impossible for a participant to support only those proposals they choose.
(2) The ideal number of proposals for a Decision Engine forum is between 12 and 20. If you have a lot of proposals, you might think that bundling them together is the best approach. Instead, we recommend running a lot of proposals as a tournament. Specifically, let’s say you have 40 proposals. Organize them into two forums: Proposals 1 through 20 and proposals 21 through 40. Take the proposals purchased in round 1 and the proposals funded in round two and feed them into a third forum.
(3) Including the same item multiple times is often confusing for participants and creates opportunities for slight errors in describing the items. It also makes processing results unnecessarily complex because you can’t compare the funding behaviors for the funding of individual proposals and the bundled proposals.
Of course, you may be facing design considerations not listed here that motivate bundling of items. If that is the case try to make these design considerations transparent so that design team understands the tradeoffs.
Please contact us if you have any further questions.
Variations on Participatory Budgeting
Over the past 15 years we’ve produced thousands of Participatory Budgeting and Buy a Feature events. In that time we’ve created a lot of variations of the core theme – and we continue to create more! In this design tip we’d like to share some of the many variations we’ve used in the hopes that you might find combinations that can help you Collaborate at Scale. Think of this design tip as giving you access to a set of knobs and dials that will enable you to create versions of this framework that meet your needs. I will also cover Zero-Based Budgeting, a very special configuration of these policies that is becoming increasingly important in our Participatory Budgeting projects. A subsequent design tip will give more insight into analyzing results of Buy a Feature frameworks.
The Core Game
If you’re a subscriber to this newsletter, chances are pretty good that you know the core Buy a Feature framework: a list of items are presented to a group of participants who are given a shared budget to fund, or purchase, items of interest.
To create variations on this core structure we will decompose it into its constituent parts. We can then vary these parts in ways that enable us to create new frameworks. This is a process we also teach in our class on advanced framework design. Let’s examine a few of the most important parts: Content, Resources and Policies (or Rules of the Game).
If you’re relatively new to Buy a Feature, don’t be alarmed at these policies and their variations! Rest assured that our online platform is pre-configured with a set of default policies to make it easy for you to quickly get started using Buy a Feature.
The content in the framework consists of the items, their description and their price. Here are two variations on content that we find useful.
Adding New Items: Write-In Candidates
Most Buy a Feature games are fixed: the list of items can’t be extended. However, there are plenty of times when you want participants to add items to the game as a means of identifying fresh ideas or critical content.
We did this for a GE Customer Advisory Board and for several Participatory Budgeting projects in San José, CA.
Be careful about write-in candidates because to add them into a forum means you need to make choices about how they are priced and whether or not adding new items expands the budget. We recommend keeping the budget constant and having a subject matter expert available to help you price the items. If you can’t price the items in real-time during the forum, ask participants how much they would be willing to invest in these items. Investment levels will provide a reasonable proxy for the importance of the items.
Each of the items needs a price. There are two common pricing algorithms. The first is to use an estimated price. Our online platform makes this really easy by enabling you to associate a shirt size with the item which the platform then uses to select a random value within a range you define. This is the dominant approach within business, when we’re generally using rough estimates of costs (“Project A is a Medium and will cost $350K – $400K; Project B is a Large and will cost $600K – $700K).
The second approach is to use the actual or detailed cost estimate of the item. We use this technique in our philanthropic work when citizens really do need to know the cost of a new street light or a new service program. This variation is also common in portfolio management, when detailed cost estimates are available to business unit leaders.
Most of the time the items in a Buy a Feature framework are independent. Like a well-structured Agile backlog, this simplifies the framework and enables participants to separately consider the value of each item.
However, just like in Scrum, there are times when items in your forum have natural relationships. We’ve produced items with the following relationships:
Precedence: To purchase item B you first purchase item A. Item B is optional – but if you want it, you must purchase A!
Co-dependence: If you purchase either Items A or B you must purchase them both. This makes it seem like A and B are really one item, but often it is easier to manage the items separately.
Exclusivity: You can purchase one and only one of a list of items (keep the list small!).
While we have done this, we generally try to avoid complex relationships. We worked with one client who insisted on creating a pricing model in which groups of items, when purchased together, updated the rest of the items in real-time. It was an epic failure – participants became quite frustrated because they couldn’t keep track of their bids and purchases, and changes in just one bid could invalidate previously stable purchases.
The standard and most common bidding policy is that participants can bid any amount of their available funds on an item. This works very well because it is quite simple and direct.
Many Asian cultures prefer to have an “all or nothing” bidding policy, in which the total budget is pooled and participants must agree, as a team, on funding an item. This can be accomplished with a simple Yes/No vote.
Another variation is to require a minimum and/or a maximum bid on an item (e.g., Item A costs $100,000 – you must bid at least $20,000 but not more than $50,000). We’re not a fan of minimum / maximum bid policies because they can artificially limit the revelation of the intensity of the participants.
There are three variations on the Budget. The first is to simply use a percentage of the total budget as means to motivate prioritization of the items. We’ve found that 40% to 60% of the total works best. This approach is common when using our platforms for market research.
The second is to use the actual budget that you’ve got for the planning cycle. This approach is common when using our platforms for Participatory Budgeting or for portfolio management.
The third approach is to start the forum with zero budget – which means you must provide a means for the participants to acquire funds. In a resource allocation game participants can provide their own budget (“I commit 20 hours of community service” or “I commit $65,000 of my total discretionary budget”).
In the Budget Games variation, we provide participants with a list of items that they can cut in order to secure funds. We call these items the “Red Sheet” items and require that participants reach unanimous agreement on a red sheet item before the budget is dispersed (equally) to the participants.
Combining Policies: Zero-Based Budgeting
A very special version of Buy a Feature is known as Zero-Based Budgeting, a technique we’ve been using in San José, CA. In ZBB we establish several policies that work together to create an amazing experience.
Budget: The total budget is held as constant for the prior year. So, if the City spent $64M on neighborhood services last year then the Budget for the next year is the same – a “Zero” Change.
Item Price: The price of the items, in this case neighborhood service programs, are the amount of money the City spent in the prior year.
Item Funding Policy: Participants, in this case residents of the city, can choose to increase or decrease the amount of funds for a given program. This means that if a program is working well residents can fund more of the program and if it is working poorly residents can fund less of it or recommend that it be eliminated by not funding it at all. All items start out with zero funding – the “Zero Base”.
Write-In Candidate: We allow residents to add up to two write-in candidates for new programs and ask them to indicate how much they’d like to invest in these new programs.
We’re really excited about Zero-Based Budgeting because it provides residents with a means to shape the programs of the city in a way that better meets their needs over time.
Funded Item Ranking Policy
The standard version of Buy a Feature uses the time of purchase of items to understand the preferences of the group, as we believe that the faster an item is funded and the more stable it remains during the forum is a solid indication of its priority.
Some facilitators have asked for additional information on the priorities of the funded items, so you can now require that items are rank ordered by the participants after they complete their purchases.
Phew! That’s a lot of compelling variations of an incredibly powerful framework. Check in next week on how to post-process the results of these great varations. And do tell: What are some of the variations you’ve found most effective in your work?
Handling “Must Do” Projects in Portfolio Prioritization
One of the more common uses of Decision Engine is portfolio planning and portfolio prioritization. It is common in these situations to have several projects that “must” be funded. For example, fixed overhead (office space, administrative overhead), regulatory or security compliance, or previously committed projects that have contractually required budget distributions would all be considered “must fund” initiatives.
In this design tip we’ll provide some best practices for handling “must fund” iniatives.
Let’s assume that you’re working in a Business Unit with a total IT budget of $30M and that you have 23 potential projects under consideration for funding with a total cost of $48M. You’re thinking that this is the perfect opportunity to use Decision Engine (aka Buy a Feature). And you’re right!
Let’s further assume that three of these projects are “Must Do”:
- A security upgrade for $1M that is required by the legal team.
- The completion of a promising and well-run marketing automation project for $800K.
- An allocation for corporate overhead for the staff of $2M.
The reality is that you don’t have $30M to invest – you really have $26.2M to invest.
There are two choices you have in configuring your Decision Engine Framework.
Option 1: Present the full list of 23 initiatives to the participants and the full budget. Start your forums by requiring that participants fund the required initiatives.
Option 2: Present the subset of the budget and the subset of the initiatives to the participants.
Our experience shows that Option 1 is the recommended and superior approach for the following reasons:
- The participants are quite likely to know that the full budget is $30M and join your forum with this number as part of their mental model in joining the forum. Even if they don’t say it, providing less than the full amount will cause unnecessary confusion.
- Showing participants the full budget along with the “must fund” initiatives creates a more realistic mental model. In our personal lives we know that don’t have discretionary control over our entire salary. Instead, we mentally allocate for “fixed costs” – rent, food, insurance, car payments, and so forth. This is also true of our businesses, and showing these fixed or pre-allocated costs build trust that the process represents true reality.
- Listing the required funding items at the top of the forum creates a powerful learning experience for participants who are new to collaborative prioritization. Specifically, when the forum starts, tell your participants that the first thing they must do is equally fund the required initiatives. This teaches them how to use of Decision Engine, introduces them to collaborative prioritization and prepares them for the more challenging negotiations that will emerge as the primary focus of the forum.
We’ll close by noting that this design tip is congruent with the values and practices of Scrum and the larger Agile community. Specifically, agilists value transparency and collaboration as a means to making effective decisions. Structuring Design Engine forums as recommended in this design tip will increase transparency and trust within your teams.