The Goal
As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way.
What Should We Prioritize?
The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri makes an excellent case for a "problem roadmap", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry.
A Sad but Familiar Story
If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet.
I've done it. Some of the most respected names in product management have done it:
I've done it. Some of the most respected names in product management have done it:
- Quick Prioritization, by Steve Johnson
- How to Use a Scorecard to Prioritize Features, by Daniel Elizalde
- How to Build Roadmaps that Stick, by Bruce McCarthy
Columns in The Spreadsheet might include:
- Man-hours to implement
- Tool and other expenses required to implement
- Potential revenue
- Number of customer requests
- Number of lost deals due to absence of feature
- Alignment with quarterly or annual corporate strategic priorities
Halfway through the multi-hour exercise, you and the team are fatigued and decide to pick it up another day. Whether or not this follow-up meeting ever happens, the team ignores much of the priorities that result from the effort, and few if any updates ever occur to The Spreadsheet.
Why "The Spreadsheet" Sucks
The Spreadsheet approach to prioritization has at least three fatal flaws:
- Organizational dysfunction. It attempts to address organizational dysfunction with formulas and analysis that ignore human factors.
- Product strategy void. It indicates team members lack a shared understanding of the product strategy.
- Distraction from unique value proposition. It distracts from your product's value proposition or from the target audience that derives the value from your product.
Organizational Dysfunction
Step back and consider why one or more people on the team thought The Spreadsheet was a good idea. In all likelihood, it was due to difficulty determining or agreeing on priorities.
At some point, you may have asked your product manager, "Why aren't we working on feature Y instead of feature X? What data do you have to back up your decision?" Or members of the sales team bypass the product manager, talk directly to developers, and tell them how the next big deal will happen if only they would implement a killer feature. Or multiple product managers are competing for development resources and employ passive aggressive tactics to divert those resources to work on their products.
By now, you recognize the recurring theme: dysfunctional interactions among team members. The hope is that The Spreadsheet causes everyone to set aside their distrust and passive aggression and become "objective". If we just focus on the numbers and let the "magic formula" compute the score, all these dysfunctional interactions will go away, and we'll get on the same page.Once you recognize the context (dysfunctional team interactions) and the proposed solution (objective analysis of priorities), it becomes obvious to anyone with a modicum of human sensibility that the proposed solution misses the mark.
Product Strategy Void
Why does this distrust and passive aggression exist in the first place? Or if no such dysfunctional behavior is occurring, why is it nevertheless so hard to get on the same page? It could be due to personalities and culture, or it could be that the team simply doesn't have a shared understanding of the product strategy.
One model of product management is that the product manager or product owner (The All-Knowing One or The Decider, as Teresa Torres might say in jest) knows best, prioritizes a backlog, and doles out the work to designers and developers. "I've prioritized it for you; just design and implement it."
This approach works fine when the product manager or owner is, in fact, all knowing, has the time to meticulously specify and prioritize every user story in the backlog, and when the designers and developers are machines that do exactly what they're told. Good luck with that.
What happens in the real world? The All-Knowing One is swamped, she has no time to talk to prospects and customers, and designers and developers keep pestering her with questions. When the product manager is wrong or has no sound basis for her answers, she loses credibility.
What happens in the real world? The All-Knowing One is swamped, she has no time to talk to prospects and customers, and designers and developers keep pestering her with questions. When the product manager is wrong or has no sound basis for her answers, she loses credibility.
May I suggest another approach?
Teams are most productive when they share a strategic vision and each team member can "fill in the blanks". What if the product manager facilitated a shared understanding of the product strategy? Then each member of the team would feel confident making decisions without going back to The All-Knowing One. And the prioritizing that team members do on a daily, or even hourly, basis would flow naturally out of that strategy.
In the absence of a shared understanding of the product strategy, you, your product manager, and team members aren't likely to agree on priorities. The Spreadsheet isn't a strategy and is no substitute for a strategy. It won't fill this fundamental void.
Distraction from the Unique Value Proposition
Let's say you do have a product strategy and a shared team understanding of what it is. A fundamental part of your product strategy is the unique value proposition.
The unique value proposition is the value you envision your product uniquely delivering to a target market.
When the team chooses the product's unique value proposition, it selects a singular, overarching theme that implicitly embodies the set of market problems it plans to solve with the product. It has largely selected the high-level priorities and deliberately set aside problems and features that don't support the overarching theme.
For more information on unique value propositions and how to position your product relative to the competition, see this entry on competitive mindshare maps.
For more information on unique value propositions and how to position your product relative to the competition, see this entry on competitive mindshare maps.
Imagine sales and customers bombard the team with requests for a "killer feature" that has little or nothing to do with the unique value proposition. How does the feature fare in The Spreadsheet?
Well, it scores well in the "number of customer requests" category. Perhaps it has great "revenue potential" as well, so bump up the score in that column, too. Sales claims it loses a lot of deals due to the lack of the feature. It looks like this feature might score very well indeed on The Spreadsheet.
But evaluating the feature through the lens of the unique value proposition might lead to a very different assessment of its priority. In fact, the feature might undermine, or be unrelated to, the unique value proposition.
Now, given the feedback you've gotten from customers and sales, you might want to consider whether to "pivot" and change the unique value proposition, and thereby the product strategy, for the product. Alternatively, you might consider spinning off another product or company with a fresh and separate set of product strategy hypotheses based on the new information.
But if you believe you already have a product strategy worth pursuing and testing, The Spreadsheet has led you astray. If you prioritize features without regard for the unique value proposition, you end up with a fractured product that distracts from - rather than delivers - its promised value. It may deliver bits and pieces of value, but those pieces have little relation to each other. They don't coalesce around a central theme.
While the "potential revenue" rating might nonetheless seem to justify the high priority, it neglects the power of brand: the long-term impact on revenue of a cohesive product that delivers a clear value proposition.
How to Prioritize
At this point, you're wondering how your team should prioritize, if not using The Spreadsheet.
I propose three primary questions to guide prioritization:
But evaluating the feature through the lens of the unique value proposition might lead to a very different assessment of its priority. In fact, the feature might undermine, or be unrelated to, the unique value proposition.
Now, given the feedback you've gotten from customers and sales, you might want to consider whether to "pivot" and change the unique value proposition, and thereby the product strategy, for the product. Alternatively, you might consider spinning off another product or company with a fresh and separate set of product strategy hypotheses based on the new information.
But if you believe you already have a product strategy worth pursuing and testing, The Spreadsheet has led you astray. If you prioritize features without regard for the unique value proposition, you end up with a fractured product that distracts from - rather than delivers - its promised value. It may deliver bits and pieces of value, but those pieces have little relation to each other. They don't coalesce around a central theme.
While the "potential revenue" rating might nonetheless seem to justify the high priority, it neglects the power of brand: the long-term impact on revenue of a cohesive product that delivers a clear value proposition.
How to Prioritize
At this point, you're wondering how your team should prioritize, if not using The Spreadsheet.
I propose three primary questions to guide prioritization:
- To what extent does this item (feature, user story, epic, market problem, theme, or experiment) support the unique value proposition?
- What is the level of effort required to implement this item?
- What will implementing this item enable us to learn?
(Heck, I might throw in a fourth one: how fun will it be to work on this item? It matters.)
The answers to these questions aren’t numbers team members plug into a formula. They form the basis for thought processes and conversations. Consider them holistically and always in the context of the unique value proposition. As Teresa Torres cautions, "If you use time-to-build to prioritize what to build next, you’ll end up with a product full of easy solutions." Teresa rightly urges us to emphasize impact on a goal. I contend the goal is delivering the unique value proposition, as I wrote in 2013.
The answers to these questions aren’t numbers team members plug into a formula. They form the basis for thought processes and conversations. Consider them holistically and always in the context of the unique value proposition. As Teresa Torres cautions, "If you use time-to-build to prioritize what to build next, you’ll end up with a product full of easy solutions." Teresa rightly urges us to emphasize impact on a goal. I contend the goal is delivering the unique value proposition, as I wrote in 2013.
Accordingly, your product manager should lead the process of determining the product strategy (including the unique value proposition) and foster a shared understanding of it, and the reasons for it, among the entire team (across all departments). The product manager may also lead the process of conceiving experiments to continually test the riskier assumptions behind the product strategy hypotheses.
This high-level strategic baseline sets the stage for every member of the team to make common sense day-to-day prioritization decisions without resorting to numbers and formulas and without going back to The All-Knowing One for guidance. And when the product manager or team prioritizes one item over another, it will flow naturally out of the shared understanding of the product strategy. Steve Johnson calls it "empowering judgment with context".
Healthy conversations about how my three considerations apply to an item should and will occur. But rarely will you need to ask for the "data" that justifies a prioritization decision. The Spreadsheet approach won't appeal to anyone, except perhaps to the most hopelessly analytical members of the team. God bless 'em.
Comments
In so many cases, teams use spreadsheets to create the appearance of data although so much of the "data" is based on politics or opinions. I use spreadsheets to help teams rank "this is more than that" -- it's a great exercise in focusing on what really matters to their market and their company.
Centering on unique value proposition is a strong method for ensuring the team stays focused on what matters. You don't want a loose collection of features; you want a killer offering with the right features. Product managers should focus the team around the product vision. Who are you trying to delight? And what key features do they need? The more we can brief the product team on the personas and their problems, the better product we can offer to the market.
So yes, let's provide context to the team so they can use their own judgement. I see product management more as leadership than supervision. I want the developers, marketers, and sellers to align around creating products our market will love.
At my last company, we talked every day - sometimes every hour - about "Lisa", our primary persona, and the singular theme representing the unique value we needed to deliver to her.
An example of a remark heard in these conversations: "Would this idea help us give Lisa a personalized car-buying experience?"
It was much easier for everyone to get on the same page regarding priorities with this relentless and singular focus, because everyone understood it to be the path to revenue (at least as a hypothesis we continually needed to test).
Read more in http://www.stratfordmanagers.com/blog/2533/storytellers
"It’s worth thinking about the product story early in the process of developing the product roadmap or defining the contents of a product release. The sooner you articulate the story, the more it will guide the roadmap and enable effective marketing. It becomes a self-fulfilling prophecy."
Just the opposite. I have often found that introducing a scorecard actually forces a team to clarify the strategy and the value proposition so that they can effectively pick the right columns for the scorecard. Supporting the value prop and the company strategy actually become those columns. Revenue is often there as well, but as just one part of the whole picture. (Ignoring revenue is just as dangerous as ignoring the value prop.)
I have also found that scoring ideas on the spreadsheet collaboratively with the team brings out exactly the kind of healthy discussion about what we really value and what will really bolster our value proposition (as well as our revenue) that you argue is so important.
Further, I have found that going through this exercise does in practice reduce the amount of opinion and emotion in discussions of priority, forcing people to articulate their opinions in terms of relative contribution to common goals. A scorecard approach makes it clear to everyone that there are multiple goals we are trying to meet and that the ideas that hit on all or most of them will be winners.
All of that said, no one should be a slave to a formula. In my workshops on prioritizing and roadmapping (http://www.slideshare.net/bmmccarthy/roadmapping-301), I tell people to think of the scorecard as an aid to decision-making, not as the decision itself. I devote a whole section to developing problem/benefit-oriented themes for releases and using scoring to help decide which features go into them.
So maybe I agree with everything you said here -- except the premise. ;)
- Absolutely agree on the vision statement. A well-known product strategy and unique value proposition empower the organization to solve problems without delay and foster unprompted innovation.
- Formulas like this are bad in all the ways you mention plus a few others. As Jim points out, we would just automate the product management process if a formula could determine award winning products.
On the other hand, it seems like the post should have been titled “Why Formulas Suck for Prioritizing”. At the end of the day, all the Agile/product management tools are effectively fancy spreadsheets, yet shared context is required to communicate up and down the organization.
- For instance, what tool is suggested to prioritize 20 (or 1000) items which (a) are in line with the product strategy, (b) enhance the unique value proposition, and (c) tell a great story when combined?
- Also, as you imply with “fun factor”, part of the product manager’s job is to “sell” these features up and down the organization. While the formula creates a distraction, what harm comes from showing others the interesting metadata associated with each story, including data around the three items suggested for prioritizing?
You wrote:
"Each of your three dysfunctions are real and you make a good case for dealing with them before you can effectively prioritize. None of these arguments, however, demonstrate successfully why you can't use a scorecarding approach to prioritize once you've nailed the strategy and the value proposition and straightened out the decision-making process."
I did write that two of the reasons The Spreadsheet sucks is that it often indicates an organizational problem (dysfunction or a lack of consensus on the product strategy) and is not itself the problem. But you seem to have missed the key point about what happens once you fix these organizational problems.
Once you fix them, the need for The Spreadsheet (or scorecard) largely disappears. The team already made decisions about what product strategy will lead to revenue, what product strategy will support the company's strategic goals, and what market problems to solve.
You wrote, "Ignoring revenue is just as dangerous as ignoring the value prop." But you're not ignoring revenue if you're supporting the unique value proposition, because you've designed the value proposition to yield revenue.
As I also mentioned, if you revisit these criteria for each individual item you're prioritizing, it will tend to distract you from the unique value proposition and lead to an incoherent product. Having one column be the unique value proposition only slightly mitigates this problem; it doesn't solve it.
So you see that the columns on the conceptual "scorecard", as applied to granular product decisions such as "this feature or that one", are largely reduced to the three criteria I mentioned towards the end of my blog entry. And once you're down to those three criteria, many of the granular product decisions become trivial. For those that aren't trivial, a quick conversation centered around my three criteria usually resolves them.
You could still try a scorecard in some of these cases to try to make these conversations more "objective", but I've found well-functioning teams with a shared understanding of the product strategy rightfully scoff at that idea as a waste of left brain cells.
Making the "metadata" (scores) available for reference in the tool sounds good but is, in my opinion, overkill. Once we go that far we're headed into the "comprehensive documentation" territory that the Agile Manifesto suggests we avoid. In many cases, if the team is truly on the same page about the product strategy, they can look at the items in the list and know almost instantly what the priorities and rationale are without assigning or reading numbers.
With a small, tight-knit team managing one product it very well may all come together organically as you describe. But if you've got three or four goals you are trying to optimize for, a large number of stakeholders to manage, and a large number of ideas (features perhaps) that all fit to one degree or another with your value prop, your company strategy, and your revenue goals, it can be challenging to prioritize and to get consensus on those priorities. I speak from experience on this.
And I'll say again that I have personal experience with using the scorecard approach as a framework for getting stakeholders with very different ideas about direction to consensus on product strategy (because it forces you to define a value prop and related goals). Similarly, I have long experience with using it as a way to defend against shiny object syndrome or deal of the week syndrome, where folks who are not thinking strategically need a reminder of the reasons why we're doing what we're doing.
I don't mind if you don't use a spreadsheet. I would appreciate it, however, if you would keep an open mind about whether other people can get value from one.
I certainly do have an open mind about using any sort of tool. While I generalized about scorecards for prioritizing, I didn't categorically state they never, in any circumstance, can help. That characterization of my position is a "straw man" :-)
Let's be clear: you believe The Spreadsheet generally should play a central role; I believe it generally shouldn't.
I think you have to fully grasp the concepts before so adamantly defending The Spreadsheet (scorecard). Based on your statements, it doesn't appear that you do:
"I have personal experience with using the scorecard approach as a framework for getting stakeholders with very different ideas about direction to consensus on product strategy (because it forces you to define a value prop and related goals).."
Here you're acknowledging the product strategy void I mentioned. You contend, however, that The Spreadsheet helps spur conversations that lead to forming a product strategy. Is The Spreadsheet, in general, the best way to start that conversation and form the strategy? My goodness: how has the team reached a point where it's debating the priorities of individual features and then considering the unique value proposition?
Also, you wrote:
"But if you've got three or four goals you are trying to optimize for, a large number of stakeholders to manage, and a large number of ideas (features perhaps) that all fit to one degree or another with your value prop, your company strategy, and your revenue goals, it can be challenging to prioritize and to get consensus on those priorities"
We can differ on this point based on our experiences, but here you're again hinting that somehow the unique value proposition doesn't itself represent a strategic decision intentionally aligned with the company strategy and designed to deliver revenue.
Remember, in your previous comment, you divorced these concepts when you stated, "Ignoring revenue is just as dangerous as ignoring the value prop." This statement indicated a profound misunderstanding of what most good value propositions are designed to do: deliver revenue.
So it's difficult for me to see how The Spreadsheet generally should play a central role when you're predicating its use on an incomplete understanding of the concepts.
Rather than continue talking past each other, though, I suggest that we look for common ground. I think we would agree on a few statements:
* Prioritization derives directly from company and product strategy
* A value proposition is an encapsulation of your product strategy and will only be workable if it can be profitable
* A scorecard spreadsheet is just a tool and shouldn't make decisions for you
Fair enough?
But I do want to find common common ground where it actually exists:
* Prioritization derives directly from company and product strategy
Priorities of individual items come directly from product strategy, mainly the unique value proposition delivered to key personas. But priorities only indirectly come from the company strategy, because the product strategy should already align with the company strategy.
Again, putting revenue and support for company strategy alongside support for the unique value proposition on The Spreadsheet is redundant; the UVP already encompasses those considerations.
So many columns collapse down to support for the UVP that you start to wonder whether we need columns at all.
* A value proposition is an encapsulation of your product strategy and will only be workable if it can be profitable
Yes, although sometimes we align a UVP to organizational strategy that calls for revenue outside the product itself.
* A scorecard spreadsheet is just a tool and shouldn't make decisions for you
Yes.
Roger
1. The UVP often has multiple components which can be broken out into separate goals (as columns in a spreadsheet). This was the case at NetProspex, where we had both quality and quantity goals. These goals could sometimes be in conflict but the best ideas were those that supported both strongly, and those ideas rose to the top of the scorecard and were implemented.
2. Of course the UVP supports revenue, but sometimes ideas come up that will generate quick cash without advancing the UVP. One could argue (and on specific ideas I often have) that one should not pursue anything in that bucket, but the reality of many companies (and any public company) is often that one has to make one's quarterly numbers however one can. Again, the best ideas are those that bring in revenue by supporting the UVP -- and a scorecard spreadsheet drives those ideas to the top so you can end the circular argument with your Sales VP about what really matters by pointing to those best ideas.
You have clearly experienced poorly-conceived spreadsheets being used as bandaids to ineffectively treat deeper problems. So have I. All I'm saying is that I have seen them used for good as well.
"No matter how complicated the product, no matter how complicated the needs of the market, it's always better to focus on one word or benefit than two or three or four."
Sure, you can break the single theme down into the sub-themes, if you will. But doing so typically gets in the way of a holistic evaluation of the impact on the user experience.
Moreover, the "goals" you mention in your slides are ñot, as you characterize them, goals we achieve to deliver our unique value proposition. It's the other way around: we hope design the UVP to achieve the goals. "Grow market share" doesn't deliver the UVP; delivering the UVP grows market share.
Short-term revenue might indeed be a special case for companies living quarter by quarter (although we probably agree that companies compromising the unique value proposition in pursuit of the next big deal usually spin their wheels). There are any number of special contingencies that can arise - short-term revenue is but one.
These contingencies merit a conversation but probably not scoring under the guise of "objectivity". If a hurricane causes us to switch to a different office temporarily that is more suitable for doing certain kinds of work, we don't whip out a scorecard and add a "Hurricane" column. We have a conversation about how we best support the unique value proposition while addressing the contingencies.
Yes, in some cases it might be helpful to structure our thinking and conversation by listing out key contingencies and discuss their dependencies and interactions, but trying to objectively score them probably goes too far.
https://medium.com/@bpmilne/the-prioritization-paradox-873c47bc61f6
I think a few things...
Roger's right in that those problems are all real, and that throwing a spreadsheet at them in order to solve them or work around them is the wrong way to use a spreadsheet to prioritize things. I've seen those problems too, seen teams use spreadsheets to try and work around them, and not make the best product decisions. So I agree with the points.
I agree and disagree with Bruce. I agree with Roger that spreadsheets should not drive prioritization, and I agree with Bruce (and I think a couple other folks) that Roger did not address the situations where using a spreadsheet to prioritize is least obviously a problem - and in those situations, I think it is a problem for a reason folks have not touched on enough.
I love the metaphor Rich Mironov just used in his presentation from Agile 2015 (slide 10 http://www.slideshare.net/RichMironov/startup-pm-eventuallyjul2015 ) - the idea train. The idea train unloads hundreds of great ideas, and you have to pick among them. Roger makes a great point about how spreadsheets lead you astray when you use them to score ideas that may or may not be aligned thematically with what you're trying to do. So, what do you do in that situation, when none of the ideas is actually bad (or dilutive or unaligned or whatever - they are literally all things you want to do, but you are forced to choose) - and the question is which of them do I do now, next, not yet, or never?
It's almost the product manager's version of the trolley problem ( https://en.wikipedia.org/wiki/Trolley_problem ) which idea do you kill in order to allow a better idea to live? [side note for folks looking for rabbit holes - this article is outstanding: https://medium.com/backchannel/reinventing-the-trolley-problem-85f3d1730756 ]
Mike's comment about sharing context is a key point - here's a useful way to use a score card: to help people understand the relative importance of different aspects of assessing ideas (which is more important this quarter - penetrating an adjacent market / new persona, growing "solution share" solving more of the problem, growing market share, improving quality, differentiating from competitors, negating competitive differentiation, appeasing the new VP, etc etc etc).
Steve, in the first comment, alludes to the fact that this dazzling array of "math" is really an expression of opinion. As such, it's subject to debate. And easily usable as a "soft skill" as a way to convince an organization to agree with "the data (which is really just estimates, weighted subjectively by _the decider_ [hat tip, Teresa]" as a way to get the rest of the team to go along with the decision)."
Here's my beef. Once you defer to the "math" as the arbiter, you are a victim, and no longer leading. I _cannot_ add that feature to this release, it's 19th on the spreadsheet. Victim.
Spreadsheets help you understand the context of the choices you're making. Eliciting and getting agreement about the relative weightings of (and selection of) the attributes that populate the scorecard is valuable for articulating and exposing the biases of the organization members in how they assess "better." The spreadsheet can be a useful tool for scoring.
Now that we've (I hope) convinced people to not conflate prioritization with scheduling, can we also convince them to not confuse scoring with prioritizing?
Scott
ps: While life is making it trickier for me to contribute to this kind of discussion than I would like, it is really great to see that great conversations like this are still happening and that I can jump in. Thanks everyone!
Now gotta read Ben's article...
Thanks for a great discussion. I'm super late the to game, but better late than never, right? =)
I agree with most points in the discussion here. My main comment is that a scorecard is just a tool, just like many others. It'll be the responsibility of the PM to use it if/when needed. It is true that strategy is the starting point, but once you have that, then you can use any tool at your disposal. What we are after is getting to a strategic decision and therefore we can use any strategic decision making tool that can help us get there. For example, you can use "High 5" analysis, two by two, or scorecards. They are only tools that help us get to our end point.
I also think that this is a constant and never-ending process. The dysfunctions you mention are real, but I disagree that you can fix them once and you are done. Challenges with alignment and communication will always continue to arise as the company evolves, new stakeholders arise, new employees are hired, etc. Therefore, Product Managers find ourselves chasing alignment as a key part of our job. And depending on the circumstances, we'll need to pull in whatever tool we need in order to get the job done. Some tools work better with some people or roles, and we have to recognize that in order to be efficient.
In my article (thanks for including it in your post), I share scorecards as an example of the many tools that we have at our disposal. No one tool is the answer. It's all about the process and finding alignment with people. "People" being the complicated part here.
Thanks!
Daniel Elizalde
TechProductManagement.com
Scott: Thanks for taking the time to thoroughly understand the issues and raise the important distinctions. The "priority" an item is actually an ambiguous concept. It literally represents a relationship to other items. But that relationship could be temporal ("we'll do this one 'prior' to that one") or a degree of importance ("this item is 'prior' in importance to that one"). In product management, the two are closely related but not identical.
I think you might not have considered one of my key points when you wrote:
"Spreadsheets help you understand the context of the choices you're making. Eliciting and getting agreement about the relative weightings of (and selection of) the attributes that populate the scorecard is valuable for articulating and exposing the biases of the organization members in how they assess "better." The spreadsheet can be a useful tool for scoring."
The third flaw I exposed in my piece was the fractured product that results from The Spreadsheet approach. If we score each item on factors such as revenue, alignment with corporate strategy, and lost deals, we're essentially setting aside the product strategy (if we have one) and opening up the same debate on an item-by-item basis. The same is true of debating the relative weights of factors as they might relate to each individual item. It's like debating whether the sun is hot today when we've already agreed the sun is hot, period.
So I wouldn't slavishly assign and document weights for every idea to provide "context". I do, however, share and discuss Google docs containing prospect interview notes, Google sheets with usage and traction metrics, and Google slides with theme- and experimentation-based roadmaps.
Bruce: It's not likely you can do everything that supports your value proposition. But you can make judgments about which ideas will have the most impact, relatively speaking, and without assigning scores.
Daniel: I don't have much sympathy for "it's just one among many tools" and "it depends on the context" defenses. If I argue that interoffice mail is a poor way of communicating, a rebuttal stating "it depends on the context; it's just one tool among many" doesn't acknowledge the point and doesn't refute the general (as opposed to universal) truth of the statement. I certainly didn't mean to imply that spreadsheets or scorecards are never helpful in any situation.
Also, I agree prioritizing and strategy are constant and never-ending processes. I didn't mean to suggest you can fix them once and be done with it. On the contrary - the experimentation and learning I mentioned are part of testing and iterating on the strategy, and the product managers should unrelentingly facilitate a shared understanding of it. People and teams are always prioritizing individual activities and ideas; I favor "empowering judgment with context" (kudos again for that one, Steve) and thinking and conversing about the three considerations I recommended to maximize the likelihood of product success.
My point is that within the constructs of the existing set of decisions (strategy), a spreadsheet is still useful for weighing relative aspects of particularly complicated issues. Here are a couple examples of what I mean.
Scenario 1: Your product is already established in the market, current product strategy is around achieving growth. Growth is intended to come from (a) increased market share gains with existing market segment A, (b) increased market share gains with existing market segment B, while also investing in foundational work to enable (c) increased share-of-wallet in customer segment A next year by solving an adjacent problem with an upsell-able model.
What framework would you suggest for understanding which of the three priorities is most important, if not using a spreadsheet? How best would you organize your team's belief in the relative importance of improving quality, refactoring for lower-future-costs, developing new features, or improving *ilities as mechanisms to achieve (a), (b), or (c)?
I'm agreeing with you that using a spreadsheet to tell you what to do is bad. I'm just adding that using a spreadsheet to help you develop a cohesive approach that manifests multiple activities and initiatives and investments that in aggregate manifest as the embodiment of your strategy is good.
You described a scenario in which a product strategy exists that is designed to achieve growth in three different ways, and now we're prioritizing those three forms of growth.
Why are we prioritizing them now, instead of as we were developing the product strategy?
I'm scoring the relative alignment / contribution to achieving those forms of growth among choices of _things we go do_ that all contribute to one or more of those forms of growth.
I believe it is useful to know if stakeholders are particularly keen on achieving growth by one of the three mechanisms (and why), or want growth for growth's sake (they are only keeping score and don't care which mechanism drives it. That helps with organizational alignment activities.
Further, it helps you clarify and assess and remember (and communicate within the org) why you decide that you will only invest 20% of the team's time on the capability that enables (c), and are spending the lion's share of resources on (b) and almost nothing on (a).
The product strategy is "achieve growth through some combination of (a), (b), (c)." The choices of investments you make in your product should align with one or more of them.
Think of it as completeness and correctness analysis, if you want. You can answer the questions - "Does my roadmap include everything it needs to, to achieve (a) to the degree we intended when formulating the product strategy?" and "Does this item I plan to ask the team to work on support (b) sufficiently to justify the large investment in resources?"
Impact maps and concept maps help with this exercise too, but I find the spatial analysis limits my ability to do anything assessing relative strengths of relationships.
Of course, you can always revisit the product strategy, if you discover that you have insufficient "good ideas" for achieving (c) - this gives you a mechanism to _with intentionality_ revisit that the (business design) approach to achieving growth through (a), (b), and (c) should really be (a), (b), and (d).
"What framework would you suggest for understanding which of the three priorities [a, b, or c] is most important, if not using a spreadsheet?"
In my view, "growth" is not a product strategy, so saying "we have growth as a product strategy, now let's see how various individual ideas impact the different forms of growth" indicates an incomplete strategy.
Rather than prioritize individual ideas in terms of these factors, how about creating a lean canvas and discussing each product strategy hypothesis on the canvas in the context of its impact on the growth factors? Some discussion of possible roadmap items might take place in this conversation as well. A spreadsheet might also be useful, but I doubt it would be the most optimal way to structure the discussion.
Moreover, if you want to leverage the power of brand, you look at the size of the market that would pay for the promised value expressed in the unique value proposition. Then you do everything you can to test whether your assumptions are correct at that level instead of examining each individual feature idea.
Goals drive strategy. Strategy drives tactics. "Growth" is not a strategy. Fill the strategy void.
Now assume that you and your team have identified 20 things you could go do - all of which advance the strategy in some way, to some degree, at some cost.
Now assume that your team can only do 3 of the 20 things in the immediate time period.
How do you decide which 3 to do, and which 17 to NOT do during the immediate time period?
The last section of my blog entry answered it. Concentrate on the three considerations I mentioned and discuss any contingencies.
Further, I stated:
"The answers to these questions aren't numbers team members plug into a formula. They form the basis for thought processes and conversations. Consider them holistically and always in the context of the unique value proposition. As Teresa Torres cautions, 'If you use time-to-build to prioritize what to build next, you’ll end up with a product full of easy solutions.' Teresa rightly urges us to emphasize impact on a goal. I contend the goal is delivering the unique value proposition, as I wrote in 2013."
In my own experience I have seen several firms fall into the "he who shouts loudest" trap, which may well serve the individual, but does not deliver the right result for the firm or for the broadest community of clients. In these instances the more quantifiable approaches perhaps give a better chance of making a decision based on a more level playing field.
We have then had to address these challenges in the production of our product management system "Prodigy" (www.prodigyproduct.com) attempting to learn from our own practical experiences of running product divisions in major financial organisations, whilst adopting a lot of the best practice that the product management community has produced.
Our view is that you need to be able to take both an evolutionary and a revolutionary approach. For the revolutionary approach, which is to be adopted for items that need to be changed fast (ie short term regulation, competitive pressures)there needs to be a facility to suggest a change, have it approved, and be able to design/build/launch it into the product in the shortest possible timeframe. The evolutionary approach works for those items that can afford to be included in a more regular review cycle (typically quarterly/semi/annual) where the broader management team should certainly take the time to review and discuss the merits of these new suggestions against the roadmap.
The roadmap and prioritisation is also clearly, an absolutely critical area. We have taken a while to shape this aspect of Prodigy as we digested the various different client views. At the simplest level, every new suggestion needs to be tagged with a number of what & why value tags, which can then drive a natural prioritisation in the roadmap. We then display those roadmaps shown at product and company suite level, which should now allow members of a management team who might not be totally familiar with products that sit outside their spheres to appreciate the relative merits of each item.
Above all of this, the most practical item that we have built in for this stage of the discussion is the "bang for the buck" capability to shuffle the various new suggestions, identify how many you can achieve under your inevitable budget constraints, and compare the relative benefits numerically (from the system) and verbally (around the room).
For us, as a system provider, we need to be aware of the various different opinions that product management professionals will have (as very aptly demonstrated in the responses to your great post) and try to build solutions which we hope will give you the best possible platform to reach a considered consensus.
www.prodigyproduct.com
It's a more extreme assessment of spreadsheets than I hold, since the question "does it support my UVP?" has always felt a bit monolithic to me, when trying to decide whether to revamp the onboarding, fix some core user painpoint, or develop some innovative feature.
I personally find it useful to break prioritization decisions down into bite-sized criteria, and often it's useful to score and visualize this information as a starting point for prioritization. Spreadsheets aren't ideal for a number of reasons, and that's why we've built productboard to fill many of those gaps.
That said, there's a lot we agree on, including the importance of rallying everyone around a coherent strategy.
Full response to you here: https://medium.com/@productboard/roger-l-cauvin-thanks-for-sharing-your-post-34b9b610bf71
Related post here: https://blog.productboard.com/still-prioritizing-features-in-a-spreadsheet-heres-why-that-should-scare-you-1611d61b95a1
Keep up the good work!
Winston (& team productboard)