As a Product Manager you constantly make decisions.
It can be a huge time saver, because you may be able to benefit from others’ expertise and experience to quickly understand a problem from many different angles. Additionally, decisions informed by many different perspectives tend to be better.
However, as you’ve probably experienced more than once, reaching agreement with many, often passionate, voices in the room can be challenging. Disparate opinions can lead to too many compromises which in turn lead to mediocre output.
1. The self-edited idea dump
Example scenario: You are the Product Manager of an eCommerce site. Its performance has been declining for the past month despite following conversion best practices, so you’ve gathered your team for a brainstorm. How do you come up with new ideas beyond the tried-and-true to improve sales?
Next, ask everyone to select the 5 ideas they want to move forward to the next step. Don’t spend more than 30 seconds doing this. It’s important to frame this section around selecting which ideas to move forward with, rather than which ideas are good vs. bad. Deciding what’s good vs. bad can be a difficult decision, whereas what to move forward with vs. not should be relatively straightforward.
Next, ask the participants to rip up the ideas they just got from their neighbor. This makes tangible that the ideas the group didn’t move forward are discarded. Oftentimes, participants have a hard time letting ideas go, clinging on to them as if they were precious gems. Ideas are cheap, and the best ideas are rarely the ideas that come to us first. In fact, our first ideas tend to be the safe and obvious. To get to the interesting stuff, you need to move beyond the obvious and this requires you to feel empowered to abandon your ideas.
2. The 2×2 triage
Example scenario: Imagine that you are planning your next product iteration. You have to balance feature requests from your stakeholders, feature ideas spurred by user research and maintenance work your development team wants to do. How do you decide what work to include and what work to exclude in the iteration?
Select your axes. Urgent vs. important (also known as the Eisenhower Matrix) is a good go-to. Effort vs. impact is another alternative when you are less concerned with time.
A note about naming: you may intuitively want to make your axes polar opposites, e.g. “Urgent vs. Not Urgent” and “Important vs. Not Important”. The problem with this naming convention is that it forces participants to make hard decisions. It can be too difficult to determine in the moment howurgent something is. It’s easier to decide whether something is more urgent or less urgent, especially when compared to other things. Additionally, for someone who feels strongly about an item it’s easier to concede to “Less important” than to “Not important”. Thus, the better naming convention is “More… vs. Less …”; “More urgent vs. Less urgent”.
Now, start placing the stickies inside the four quadrants. Do this in silence. After all the stickies have been placed on the wall, have a quiet read for a minute and then start asking questions: Is this thing really that important? Are we sure that this thing isn’t more urgent?
Keep moving the stickies around collectively until you have placed half of them below the horizontal line. Be strict with this; challenge every single sticky that has been placed above the horizontal line until you have moved half of the set to the bottom half.
- The top right quadrant holds the items that are obvious. These are your definite yeses.
- The top left quadrant holds the items that are up for debate. These are your maybes.
- The two bottom quadrants hold the items that are either unnecessary or not worth the effort.
3. The dot vote
Example scenario: You and your team are designing a new product. It’s a mobile app that allows runners to find other runners in their neighborhood to go running with. Each member of your team has prepared several sketches of what the app’s user experience and interface could look like. How do you decide which design and feature ideas to explore further?
Each participant gets a set number of votes. 3 — 5 tends to be a good number; it’s small enough to force hard decisions but big enough to produce patterns. You can either use sticky dots or markers to represent votes.
Next, define what to vote on. In the example with the sketches of the mobile app, you could cast votes on complete sketches (for instance, Jane’s clean registration screen), or on specific ideas in the sketches (for instance, Mark’s clever drop down menu).
Tally up the votes. If you decided to explore all ideas that received at least one vote, you’re done. If you decided to move forward with a fixed number of items, identify which items qualify based on most votes received.
4. The stack rank
Example scenario: You are working on a tool to help adults learn how to write software code. Your office is being visited by an expert on adult learning, but you’ve only been able to get one hour with them and you have a list of 15+ questions. You think you’ll be able to get through 5 of your questions, but which ones? And which questions should you bring to ask as extras if time permits?
(This tactic is similar to the dot vote in that it generates a subset of most valuable/most important items. However, the stack rank generates a list of items in order of importance whereas the dot vote doesn’t capture information about the relative importance or value of items.)
Now it’s time to collaboratively sort the items in order of importance. Start rearranging the items, placing the most important item at the top of the column and the least important item at the bottom of the column. Everyone participating in the stack rank exercise are free to move items up and down. Once people stop rearranging the items, the facilitator asks everyone to take a step back, review the column and make any last changes.
You now have a prioritized list of items. Start processing items from the top. If you only have scope to process 5 out of 15 items, you now know which ones: the top 5 on your list. Should you have additional scope, you now also know which items are your extras.
5. The Roman vote
Example scenarios: Should we break for a few minutes or keep going? Should we keep this idea or should we throw it out? The Roman vote gives the facilitator an opportunity to formulate an end state to a situation and get the rooms permission to go there. It’s a great tactic to use when a decision has clearly been made by the group but not made explicit yet.
Anyone in the room can call a Roman vote. The person who does so should have a proposal ready that can be answered by the group with a yes or a no. For example: “Do we feel comfortable moving forward with this idea?”
- An upward pointing thumb for a yes
- A downward pointing thumb for a no
- A sideways pointing thumb to go with the will of the group
6. The decision matrix
Example scenario: You are debating which one of several possible new features to implement. They are all good ideas but your stakeholders and product sponsors have different ideas about which feature is best. You have also spoken to customers and gotten a basic understanding of how big of a need each feature would solve for. How do you leverage the input of your stakeholders and the feedback of your customers to determine which feature is your best bet?
Begin by determining the columns of your decision matrix. Which aspects of the items you’re choosing between are most important? If you are deciding between feature you might want to consider early customer feedback, the ease of technical implementation, how on-brand the feature is. If you need to incorporate the input of certain stakeholders and/or subject matter experts, choose columns representing their expertise.
Bonus: The rapid feedback round
Example scenario: Your team is working on a mobile step tracking app. You have just launched the MVP. It’s time to determine a direction for the next quarter, and you have identified several future directions for the product based on what you have learned so far. You want to gather the input of internal stakeholders and subject matter experts to better understand the feasibility and value of each proposed direction (for instance, you may be looking to understand dependencies, technical integrations, what data your organization can track or has available about users, etc).
Prepare a short description of each idea that you want to collect feedback on. You should be able to describe the idea to your stakeholder group in 60 seconds or less. A good format is to answer key questions like:
- What it is? E.g., it’s a weight tracking feature that shows the user’s weight over time on a beautiful and easy-to-understand chart.
- What problem does it solve? E.g., it helps users track their weight against their activity level so that they stay motivated to keep walking.
- For whom? E.g., Busy people whose only exercise is walking to and from work, to and from the grocery store, etc.
Next, you will open up to the participants for clarifying questions, such as: Where will the user’s weight data come from? Have you also considered tracking the user’s BMI? Are you planning to capture weight data daily or weekly or at some other interval? You will spend 2 minutes doing this.
Lastly, ask the participants to contribute amendments to the idea. Spend 3 minutes doing this. The guiding principle here is: Don’t hate, iterate — encourage constructive feedback that makes the idea better. Remember, what you’re looking for is subject matter expertise that makes your idea stronger, not to validate the idea (stakeholder feedback is not validation).
You now have a set of ideas that have been improved upon leveraging internal expertise. Use one or a few of the other techniques described here to decide which ideas to move forward with and validate with real users.
* This technique was inspired by Holacracy, which is a system for distributing decision-making inside organizations.
About the Author