We're going to talk about prioritization a little more generally today,
not just project prioritization but actually you know, you've got strategic goals, how do
you align your activities with the goals at the corporate level, then at the divisional level,
at the team level, and then right down to the individual level. How do we prioritize and make
sure that we're being efficient and effective in executing on the goals of the business? And
to help us do that we've got a couple of crazy guys from the West Coast, Harry and Wes
Harry I don't quite know where to start with Harry, right he's been around
the block for a while you know he was one of the guys who built one of the
very first shopping carts, online shopping carts right, so a real Trailblazer
and he sent me a bio, and I started reading it and then I kind of felt just
kind of collapsed with exhaustion reading the companies that he's worked with right, so it's
Adobe, DreamWorks, Google, HP, Microsoft, PayPal, Rackspace, SGI (those of you who remember SGI), Skype,
Semantic and and all the rest, I mean just unbelievable people that Harry's worked with and
Wes's resume CV is no less impressive you know Thompson, Reuters and guys like that
Harry and Wes are both kind of product guys, real product guys,
and innovation guys, but this conversation actually started because Harry's writing a book
all about prioritization, and in there he was wise enough to realize that there's
a methodology called AHP, which again if you've been on some of our webinars you know all about it,
but Harry was wise enough to know that AHP is a really strong methodology for prioritizing
projects and reached out and you know we've been, again those of you who know us know Dan,
Dan and I did a quick read over the chapter on AHP, just to help make sure that it was all kind
of ship shape and and proper. And we got chatting and said "Hey listen, we should
do this webinar". So I'm really excited you could all join us
Harry & Wes I'm going to hand over to you guys to introduce yourselves and
and perhaps Wes you could go first, because I know Harry's going to
kick off with a story so we can then hand on to Harry and he can lead in with a story.
Thank you Stuart, good afternoon, evening, morning to everyone who's joined. It's
a privilege to be with you and really looking forward to our engagement today
I'm actually located in Texas, although a lot of my clients have been on the west coast of my
work with Harry, I'm a transplanted Texan, and if I were to talk about my career I would say
in three phases that I have been a management and technology consultant
gotten to see how a number of the world's leading companies run from the inside out,
grew weary of being on the road enjoying a company called Rackspace very early on, and was one of the
early product managers for the cloud at Rackspace and got to see a company grow from a post series A
small company to one that grew to be at the time one of the world's great service companies
with revenues over four billion dollars. And most recently I've been involved in both startups
and in Consulting, and so you know one of the things that I'm sure we'll get into today is
the startup world is rich because the opportunity to make a difference, to act
on priorities, and to see those come to fruition and see those work or not work based upon your
own individual contribution was something that was very, very, appealing to me. And so this sense
of ownership that we talk about a lot, it really becomes real in the startup world.
So most recently I was a part of a VC backed B2C startup, and Harry and I have
worked together for over 10 years, I consider him a mentor and a friend, he has taught me a
ton about product design and coaching, so we work together today as executive player coaches
who specialize in strategy and specifically in prioritization so we look
forward to contributing what we know, and I'm sure we'll learn a lot from you as well in the process.
Thanks Wes, go ahead Stuart. I was just saying thanks Wes, Harry over to you. So I
mentioned on the LinkedIn post I consider myself more of a student than an expert in prioritization
at this point the deeper and the further I go into the world of prioritization and and
specifically the more conversations I have with Stuart, the more I realize how little
I actually know, what I do know started off roughly eight years ago where I
thought I want to write a book on prioritization, that can't take more than a year. Well here
we are almost eight years later it's finally getting done, and and I feel like I've only
scratched the surface. So Wes mentioned that we're functioning as kind
of player coaches and what that means is that in the contact Silicon Valley primarily at
this particular point it means being a fractional executive and coaching from within that. I mean I
also have individual clients at this point, but by and large I'm going in as a 10 or 20 or 30 percent
executive, either as a product leader or as a COO, and then coaching from within,
that point of view. And you know the the gist of the book in a nutshell is that
the best companies somehow figure out
how to prioritize, right, and they are composed of teams that somehow figure out how to identify what
matters most and focus on those things, and then those teams are composed of individual
contributors and frontline managers that somehow manage to you know pick out the things that are
really going to be difference makers and and get those things done. But it's really stunning
to me that so few people actually really understand what prioritization IS. They understand
why it's important, on my bookshelf behind me I probably have a hundred books on the topic
that talk about how important it is, and absolutely none of them tell you really how to do it. So the
book that I'm in the process of just finishing up right now with Wes's help, with some of Stuart
and Dan's help, is really about stepping back from prioritization, turning it into a first-class
citizen like decision making and then recognizing that in order to be effective at it you have
to have a process for it. And that once you understand that there is a repeatable process for
prioritizing that then it becomes a question of, you know are you doing it for yourself, by yourself,
are you doing it as part of or leading a team, or are you operating at scale within an organization?
And then there's the question of is it really an episodic kind of one-off and infrequent thing, or
are you doing it periodically day in and day out as an individual, or in an ongoing fashion weekly
or you know by sprint with a team, or are you doing it as a function of kind of the work
that you're doing organizationally to make sure that you understand how you're ultimately going
to be able to allocate resources and keep those resources and all of that work synchronized and
aligned with with the work that's going on in the C-suite to make sure that you're
headed in the right direction and you've got an effective strategy. So I wanted to just start off
with what I think is kind of an ironic and funny story, but it's so typical when I tell people
I'm writing a book on prioritization, because everybody says the same thing which is like
"I need to read that!". Well I tell you, people write the books they need to read, and so I'm at the
top of the list of people who probably needs to learn a little bit from the work
that we're all doing right now, but I got a call from a leader in cloud cost management,
it's a SaaS solution that's out there today, company is making a lot of money
helping other companies save money in their cloud deployments. And they called me and
they said "we can't get our next round of funding unless we figure out how to get a generative AI
feature set built into our next product, what do we do?". And I looked into
the problem and I thought okay, well this is going to take some work, because it's going to
you know disrupt their entire product roadmap, and I said well why
don't why don't we start off with, you know, what are you actually doing in terms of
prioritization, just out of curiosity. And they said well we're using RICE, and I said RICE that's
interesting. And if you're unfamiliar with RICE I'll talk about you know Wes and I'll
talk about kind of the different approaches and methods that there are to prioritization, and
especially bounded in the context of product design and development, because I think having
having that lens helps us look at the microcosm of prioritization and then back up to
the macrocosm of the grand challenge of what it means and why it's so difficult for companies
to do it effectively. And so the guy that's in charge of products said oh
we're using RICE, and I said why are you using RICE? And he didn't answer, he sent me a
video on what RICE was. And I looked at it and I thought okay you know RICE is basically
a set of dimensions or criteria that you can use in a simple way to you know spreadsheet or
if you're less clever you can put it in a visual framework, and it stands for REACH - you know
how are you connecting with some form of measurable, you know whether it's customers, or
whether it's transactions, some kind of metric. And IMPACT - what does impact mean? You know
the RICE methodology looks at it as a straightforward
scale of you know three is massive, and two is high, and one is less high. And then CONFIDENCE -
okay 100 percent we have complete confidence right, 80 percent less confidence,
50 percent or below like don't do it. And then those become the numerators over EFFORT, rice R-I-C-E.
And Effort the RICE methodology points to as person months. But it is so coarse
grain, and it is so blunt as an instrument, that I couldn't figure out how we were going to refactor
their roadmap using something as simple and as common as RICE. And yet, you know this is a
senior level product guy right, he came out of Cisco he largely knows what he's doing. And
yet why is he using, why are THEY, using RICE? Well they're using RICE because he's using
RICE, and why is he using RICE? Because it has a clever name. And does he really know about other
kinds of prioritization methods? No he's done what they've done before, because that's what they did at his last job. Almost every environment I go in people are doing what it is they've done
before, or what it is that they think is ultimately going to lead them to some kind of better place,
without having any kind of clarity that RICE is a function of a set of criteria for a sorting technique,
and separately there are frameworks, and separately there are marketplace simulations, and
separately there are hybrid techniques like AHP, which are insanely powerful if you apply them
appropriately with people that know what they're doing - preferably with tooling that supports it. So
every time I talk to somebody about prioritization I hear another horror story,
except for Steward of course, then I just hear about these really interesting challenges and I'm like wow that's interesting. I wanted to stop there for a minute and pause because
that's the Grand Challenge in some way is everybody feels like they need to read the
book on prioritization. So I think part of that, and let's just do a little test actually,
while you were talking I banged together a quick poll. So thank you for those who've put in
your biggest prioritization problem, if you haven't what's stopping you? You need to prioritize that
guys, but in the meantime here's a little poll. So we're talking about prioritization
and usually the reason that's top, the reason you get that reaction, is because everybody
that I've spoken to - the votes are coming in already - everyone I've spoken to
feels overloaded. And it feels like it's got worse, I'm not sure that it has actually
got worse, but it feels like it's got worse because we have better communication so it's it's kind of
visible, and you keep getting these reminders and tasks and team messages that you've got a
long to-do list right and - there we go, right we'll end the poll there and
just share the results. So no big surprise here, nobody says they've got about the right
amount of work, nobody says they're off to the golf course, everyone feels overloaded right on
this call to some degree, a bit or a lot. So Wes, you know when it comes to kind of product and
things like that, how do you start to take that apart? How do you start thinking about
projects and product direction when you always have too much to do?
So two things - first of all, I think it's very critical when it comes to the amount of proposed
work to, as best you're able from the position you're in, to connect what you're doing with the
greater story of how the company is moving forward in the world in order to achieve its vision.
That in many ways becomes a great filter for what you should do next.
Okay, so that's important. I want you to say it again, say what you said again but
you know really with feeling this time. Because that's a really profound statement right?
The story matters we're organizations, but behind that we're individuals, and we all
signed up to do something meaningful and great, and to be able to connect to that greater good
that our organizations stand for and and be able to filter what it is that we're working on through
that lens is very powerful. It's focusing, and it also helps I found a lot in how often extraneous
work gets snuck in on the side and that's you don't want to say no to someone, or someone
else has a pet project. We get bias in the system and so when we have something greater
than ourselves to be able to appeal to, be it core values, be it a lofty goal or a mission
that we're on, that's clear and understood by all, then I find that it is a a useful tool not the
only, because we still struggle with the desire to cram more work into the hours that we have.
And to tie it back to the story I told you a few minutes ago the CEO said "Where
do we start? How do we get this generative AI stuff built into our product?" and I said write
the press release you want to release. Tell that story and link it to who it is you
are and why it is your customers and clients care about you in the future. From there we can
use that as a guiding template, if you will, to do the product work to figure out how to get from
where we are today to what ultimately allows us to release that new chapter in that story
So you're talking about tying your activity to the strategy or the goals of the organization and
you know there's some really good research out there that talks about how looking at the
overall performance of organizations, those organizations that have strong alignment
massively outperform those that don't. Massively outperform them, right. So
there's something like - any stats geeks out there - they ran a regression
of performance versus degree of alignment and the r squared was 0.8 right, a HUGE correlation.
So this stuff really does work, really does matter, and looking through the comments right
people know this. We've got Ronald talking about trying to allocate
things within the organization cascading down, but that's difficult. We've got Doug talking
about OKR's cascading down to allow you to have priorities. At the same time right we've got
Jonathan on here - Hi Jonathan great to see you man - got Jonathan on here talking about
priority number one is always what the CEO says, right and you know a funny story about that one -
Dan dug this a couple of months ago, stumbled across this one - so Amazon
you know they spent couple of hundred million developing the Fire Phone,
have you seen it? Yeah you're laughing because you know where it is right? It's in the bin
They spent a huge amount of money, and everyone knew that it was never going to happen
but every time they kind of said well why are we doing this they go "Cos Jeff said". And
so you know these problems are real and everybody here has them. So another quick poll
who here feels like all of the delivery resources around their organization understands
the strategy of the business and knows how it applies to them? Because Wes
that's kind of what you were talking about right? Absolutely. Right so who thinks
that all their delivery resources really know how the strategy applies to them
I'll just give you a second to vote, it's not that hard a question
There we go. So most people feel like people kind of have an idea
and we've got one brave soul who says they're really on it - congratulations!
Let me just end the poll, I'm going to share the results so you can all see that
there we go. And what I can tell you is that what the research tells us, actually and what
our experience is, is that when you're going to sit down with the executives in the C-suite
and, you know, let's say you've got 10 people around the table and you ask them you
know how would you write down your strategic goals, and which ones are most important?
If you've got 10 executives you'll have at least 20 opinions around the table
So not even the c-suite really knows what the strategy is, and how it applies to what they do
So Harry what do we do with that? Well you know I'm often accused of recommending too
many books, but I will suggest that everybody on the call pick up a copy of Rumelt's "The Crux",
and if you haven't read it, it is a fantastic book on taking a challenge based approach to
identifying the crux of the matter, the strategic challenge, and then figuring out what your response
to that is. But interestingly the place I learned the most about strategy was probably
the most unlikely of places that I worked, with respect to strategy, and that was at Dreamworks
Animation. I was involved in Shrek and Shrek 2, the production, design, development of
those particular movies. I ran the intranet - for a second there
I thought you were going to say that you were model for Shrek, but that would be cruel wouldn't it?
[Laughter] Better Shrek than the donkey!
At any rate, one of the things I learned there was that movie studios have a remarkably
well, especially 3D animated computer-generated productions,
because you know it costs a couple hundred million dollars to produce a movie, and it costs a
couple hundred million dollars to market those movies. And it isn't too difficult to get the
math wrong and wish you hadn't made the movie, because you can lose an extraordinary amount
of money unless you get the movie right. And that involves getting the story right, and getting the
story right means really working through whatever it is that people are going to expect when that
story is done playing out as an 88 minute pixel perfect digital artifact in somebody's living room
The companies that seem to understand how to how to get their strategies right seem to understand
how to get the story right, and the ones that have the easier job with it I think are the ones
that are extremely top down, you know the Apples of the world where you know having a
a movie production-like mentality allows them to work through the collaborative
conversations and decision making necessary to get to the point that they know what to say
no to. Because at the end of the day if we had all the resources in the world we would just do
everything right? But what strategy tells us to do is how to pick and choose what it is we're
going to say no to, so that we can say yes to the thing that's even more important. So given all that
I just got lost, and I'm now thinking about the slides that I created that I wanted to share
No that's good, so the top level it's - I mean again I want to pull that out Harry because
sometimes people miss that - prioritization is not about what you do, it's about what you choose NOT
to do. That's right. That's the active decision because the default is do everything
right so prioritization is an action that lets you deselect things. You know we
always think about choosing which projects we're going to do, or which features we're going to add
or whatever it may be, but actually it's which ones we're not going to invest in. Well I think one of
the things that was that really became clear to me learning about AHP, talking with you
and Dan, I mean it just really crystallized the idea that your priorities aren't your priorities
What I mean to say is that your priorities are your options, preferably in force ranked order
preferably aligned with your strategy, but ultimately it's the conviction that you
bring to understanding what's going on in your organization and in the broader market conditions
if you will, that allow you to choose. Just because something's number one doesn't mean that's where
you're ultimately going to place your bet right? What it does is it sets up conditions where you
can have really informed conversations. And that's really the beauty of something like AHP because it
provides a methodology for getting people on the same page so that they are ultimately in
a far better state to agree on what they agree to, and agree on what they don't
agree to. The challenge with most other approaches to prioritization is that
when I say "tree" you know I'm thinking Sequoia and you're thinking Aspen. And not having
clarity about what we're actually talking about. You know John Von Neumann, I know Stuart you
probably appreciate, says - I'm butchering the quote you know - "Why talk very specifically
about things we know nothing about?" And a good prioritization effort helps us coalesce
our understanding of what we're talking about, so that we can get specific about it. Ultimately so we
can make decisions and move those decisions into resource allocation and ultimately into activities
that need to cascade through the organization so that we've got coherent action that's effective so
that we can be more efficient in how we go about utilizing our resources to accomplish our strategy
It's all about alignment. And alignment is about engagement
When people are a part of the process they are much more willing to follow along with the
decisions, even if they disagree with them. Another thing that I think is critical of leadership is
to be able to speak to what will not change in terms of the vision of the organization and
the highest level objectives, but then to make room for, as Harry said the priorities are a
set of choices a set of options, possible futures. And these need to be tested. And when we test them
it does two things, one is it saves us a lot of time if we're wrong, and two it lets our people
know that we're not just blindly committed to this path, that you may disagree with, but this
is the path we want to run. First in order to see if the fruit is on the tree there
That's really interesting, so I'm gonna come in and just
not challenge or disagree, but put the emphasis in a slightly different place right, because when
you know when you're talking about projects or features as priorities I disagree I don't
think they're the priorities. I think they're just how you meet your goals. And the real
decision you're making right, when people disagree about what project to do, actually they're not
disagreeing about which project to do, what they're really disagreeing about is which goals are the
highest priority. Because if we agreed on that then we would all agree on which projects
were most important, contributed to those goals
I really appreciate you highlighting that Stuart, and here's why - ultimately prioritization is effective when we are talking about the same
kinds of items at the same level, so co-mingling solutions and opportunities or
solutions and problems, they become very difficult to prioritize against, and so at the end of the day
from a product perspective, I love the product, I love to prioritize opportunities there's a
very well done framework by Teresa Torres who made this popular called "Opportunity solution Tree"
and in it we just see a tree diagram from top to bottom of the organization's top objectives
in terms of the type of organization it wants to be, and how it intends at a high level to meet
those objectives. And then there are opportunities to pursue in pursuit of those goals, and then from
that level down we have a myriad of possible solutions that can deliver. And then
once we pick that we're gonna like have experiments even, so ultimately what we're
doing I think is we're prioritizing at the opportunity level
and we're saying what are the most important as you said goals? What are the most important
opportunities for us to pursue goals, to pursue problems to solve? And from there the solutioning
is really just someone's best proposal for how to achieve that, that may or may not be true
Yep. I've been interviewing, along that point, I've been interviewing companies that have
deployed OKR's, with tooling and without. And one of the great challenges, I
know somebody asked a question about OKR's, is OKR's you know if you boil it down just to
the most simple construct we're talking about objectives right? And objectives in theory
are really components of goals, and goals in theory are you know essentially a response
to a strategy. And the challenge with the way most people are approaching OKR's is
they don't understand what their priorities are, so they haven't translated from the strategy to
the goals to their priorities, and what they're doing then is they're distributing
the responsibility for figuring out what those priorities are without doing the
work throughout the organization and it's very hard to link these things then back to what it
is the organization is trying to do. Even if the OKR's cascade to some extent. And that's actually
I think one of the larger challenges that I'm seeing at least in Silicon
Valley at scale is that the mechanisms to cascade priorities down doesn't exist
That's a very good point, and OKR's in particular can be quite dangerous because often what
you find is that the OKR's are set before you figure out which projects and initiatives
actually have the biggest impact. So what that does is it means that you have a
whole bunch of executives who have bonuses tied to delivering on a particular OK or R and
so when you're trying to select projects you suddenly have all this noise, because everyone's
fighting for their project because they need that project to hit their objective and get their bonus
And so you know in an ideal world you'd flip that on its head right, and you know prioritization
shouldn't be part of, you know it's not a budgeting process, it's actually part of your
core strategy planning right. your core strategic planning. And it should come before you assign
the OKR's, because your projects are the things that are
- I mean in reality it's kind of iterative right, you say "Well we'd like to grow by 30 percent" and then you
look at what are those opportunities Wes that you were talking about right, what are those
opportunities? Okay the opportunities we've got can give us 20 percent, so actually now we're gonna now we've
picked our opportunities we're going to set the objectives for the organization based off
of that. And when you do that then you you get rid of all - you get rid of a lot I won't say all -
but you get rid of a lot of the politicking, the fighting for my project stuff that goes on,
the guys who sneak around the back and try and get the project done on the quiet, you know
you get rid of all of that because suddenly we've set the objectives and we've got
the actions that are aligned with strategy and the objectives supporting supporting all of that right, consistently
Absolutely Stuart, and as I earlier mentioned alignment. Alignment is deeply
connected to a sense of fairness or integrity within the process. And so this is where a tool
like AHP can be very, very, valuable. Ultimately you're looking to determine what matters most
in terms of the criteria that exist, and then how much do you weight those criteria relative to
one another and going through the process - Stuart we're just meeting and talking about
thinking you would likely agree that we're not blindly obligated to take the
project that scores the highest, but it gives us a quantitative point of view that based upon what
we have all said as an organization this is what has scored first. And then there's a qualitative
view as well from leadership as to what we truly believe, that get combined into a decision, a set
of decisions and actions that become that essentially they become the plans that are
activated upon by the organization. And so I just think this sense that going back to if you're
in the middle of an organization, or if you manage individual contributors, the sense that fairness is
very important and so even when your project isn't chosen, even if it's scored highly you're getting
an explanation as to what the thinking is behind the executives who may have chosen a different
path. And it also legitimizes your case should the first path chosen not be the correct path
Yeah I love that. I love it. Go ahead. I was going to shift the the focus
of the conversation to just a small number of slides that I put together but before
I do that was there something you wanted to ... Yeah so I was just going to ask one question, so
Rolando asks what level of definition - benefits/risk/budget/schedule -
does a project need in order to prioritize within a project portfolio? And that
sort of ties to a little bit of what you were just talking about Wes right, and that
sort of hierarchy and what level of detail do you think is appropriate?
I would say it's whatever the even level of abstraction is with the things you're comparing
it to, it's not an answer you can give in and of itself to a particular item, it's
something that has to allow you to have apples to apples or oranges to oranges comparisons across
the portfolio of of competing items. And so every item needs to have you know one
or more preferably two at least attributes and values associated with those things, and if you
can agree on what those attributes are and you could think about attributes as criteria and
you can agree on what the metrics are, or at least how you're assigning value to those metrics, and
you can once you have some reasonable degree of agreement or alignment around that it allows you
to say this versus that. Without that level of clarity it's just an academic exercise and
it doesn't end well. And I think coming to that right, one of the great things
about AHP is it lets you compare apples with apples, but it doesn't let you compare apples
with elephants right, they're too different. And so you know what you find is that
when you're prioritizing you actually end up with multiple portfolios. So one of our customers
for example, their engineering team uses this, it's a charity that runs all the lifeboats
here in the UK, and they have two portfolios. We've got a portfolio for the small tasks
and they've got a portfolio for the big projects right, so a big project is refitting a
rescue boat or something right, small project might be making a change to an engineering diagram
And the level of information you need for those two is completely different, something that's
going to take two hours of work, do you know what, you're not going to spend a lot of time analyzing
that you're just going to answer a couple of questions, get a nice quick score, and then just
treat it like an agile backlog, take them off the top the ones with the highest score you
just go and do. You don't need to do a lot of thinking right? Those big projects, you're going to do a
lot more analysis, you're going to look at a lot more of what's the benefit, what's the cost, what
resources do we need, what resources do we have available, you're gonna overlay all of that information
So the answer really is it depends, and it depends what kind of portfolio
you're working with, and and so on and so forth. So it's a great question thank you for that
The best heuristic I can offer to you is think of items that exist at the
same altitude we wouldn't compare opening a data center with establishing a new
flavor of Linux let's say if you're a cloud provider. These are two different
completely different types of work, of items that you would compare, that you would
set in separate categories. Yeah with significantly different implications of
getting it right and getting it wrong. Yes. So we may have lost Stuart but hopefully... Sorry I
just saw smoke going past my window outside and thought just wondered if anything important was on
fire. Speaking of priority! Yeah absolutely. So Harry, you had some slides you wanted to share. Yeah just
a small number of slides, hopefully you can see, what I'm sharing here
So you know speaking of dimensions and altitudes, and you know
one of the one of the challenges we were talking about earlier has to do with you know how do you
select a method? It's not just how you compare items, but how do you actually select methods
And there are a number of things that are really at play in terms of selecting a method, and one of
the things that Wes and I've been talking about is the difference between selecting
an approach for value streams, a subset of which you might consider to be products
versus projects. And I'm, you know I tend look at projects as - even large ones -
as somewhat time-bounded or temporary work by groups of people that may not work together
day in and day out for forever. And so you know it depends a lot in selecting a method
what you're optimizing for. Are you optimizing for something that's going to continue forever, or are
you optimizing for something that is going to have some kind of scope or time-bound associated with it
We talked about the strategic versus tactical level, there's also question of life cycle stage
and complexity, like where is this thing in its ongoing evolution? And what level of complexity
whether it's cognitive complexity of the people required to be working on it, or whether
it's the intrinsic dynamic or static complexity of the thing itself, is going to affect how you
might want to be looking at the different methods. Organizational scope, team size - obviously
this is a huge issue when it comes to picking your methods you know if you're working in a
large, you know tens of thousands of people across multiple sites
and countries in different languages and different time zones it's going to require that you approach
things a little bit differently. And then there are going to be certain things that are going
to work well in some cultures and structures versus things that work in others. So I
wanted to use this just as a lens for looking at the book. The first part of the
book talks about a repeatable process, DEGAP, which is really DECIDE is it
worth the investment to prioritize? And obviously when you get down to the small
thing you can run a quick process, make a decision, move on. A very large thing, the implications
of not being intentional about your process can have long-term cascading implications
ENGAGING in the process, figuring out who the stakeholders are and identifying
the information sources. GATHERING the information that's required. ARRANGING that
information into whatever form is going to be most useful, normalizing it in whatever way is
required, picking the criteria, sorting through all of that. And ultimately the focus when most people
think about Prioritization they think about the P, but all this other stuff has to happen beforehand
And you know I'm not going to continue talking about how awesome AHP is because I
personally have never been through a complex AHP deployment, however from everything I know
about AHP, part of what's so excellent and valuable in the process is it really does force
you to go through this repeatable process. And so the book walks you through each of
these phases and then looks at what it means to do it as an individual, to do it as a team,
or to do it as an organization. Actually Harry - just before you leave that slide, so
I just want to throw in here something that again, making explicit something that you said there, which
is a lot of people think of prioritization as a meeting, we have the prioritization meeting
and that's where it happens. But that's not where it happens. Prioritization is a process, right? It
starts - and you know this is a good model for thinking about it - you Decide to
prioritize, you Engage with people and figure out what's important, you Gather all the information
here the alternatives, you score them, you Arrange them. Then you're ready to prioritize. Oh and by the
way, then you're going into execution, so then you want to be monitoring and staying on
top of that and re-prioritizing if things change. So it's this continuous process which
I think comes out really nicely here, so thank you for putting that up. Yeah and this became clear
to me once again at DreamWorks where I realized you know people talk
about animation like it's the thing that you do to make the character move, but animation is actually
a remarkably complex process of you know getting the story right, and getting the
actual digital artifact delivered, and everything in between that's required in order to - you know
when Shrek sits down on a chair, that chair doesn't exist, it's software. Somebody had to build
it before they started animating. And knowing what the sequence of activities is
and knowing what needs to be done, putting all the information
together, aligning all the resources and then setting up for the act of animating the
characters themselves is a beautiful analogy in a sense to what prioritization is about. The
act of prioritization if you will is one point in the overall repeatable prioritization process
So the part of the challenge that we talked about earlier was we talked about the fact that you know
when you look at prioritization as a point event people often don't have enough time
to do it, usually the process is driven by either the highest paid or loudest person
in the room, and often the way that people respond to it is they pick the method
they know, or they grab something that seems to have a clever name and they move forward with
it without any real understanding of what its limitations are, and what implications of those
limitations are going to be. You know sure, Stuart can talk for hours about the fact that
generally most prioritization efforts don't spend enough time defining what the criteria are,
what are the measuring sticks you're going to use for determining whether something's
important or not? And then how do you get people in alignment about what those criteria are? And then
you know most people move into the stuff without sufficient tooling, and with very deep
assumptions about whether the approach is going to work at all. And
I often talk about this as the fact the learning loop is broken in prioritization, because people
don't realize the failures they're experiencing two years down the road you can often
thread that needle all the way back to the decisioning and prioritization process that led
to the results that led to those outcomes. But the time scale is so long that people
often don't make these particular links. Then in the context of prioritization at large I
mentioned earlier there are sorting techniques, and I'll outline those in a second. Frameworks,
simulations, and hybrid methods. This distinction, it seems so simple in retrospect right,
you look back and you're like "of course there are sorting techniques", "of course there
are frameworks", "of course there are simulations". But if you go out on the internet and you start searching for
prioritization techniques, they're going to call something that's a sorting technique a framework
no one's going to call AHP a hybrid method even though it's a brilliant conglomeration of a bunch
of very effective pieces - sorting techniques, frameworks, and to some extent simulation - that
go together to actually make possible something that you couldn't do unless you link these things
together in a repeatable way and then provided purpose-built tooling to allow it to happen
So just as examples and really I'm thinking about this from the point of view of product
design and development, you know the common sorting techniques okay everybody knows what stack ranking
is - sorry it should have said stack or Forced Ranking I'm sorry for the typo there. Pairwise or paired comparison
it's fundamental right, it's one of the core fundamental sorting techniques that
almost guarantees that you're going to end up with a Forced Ranking that makes some kind of
sense even if you can't articulate the criteria behind it. And it's part of AHP, it's part of the
method itself. And then we have the laundry list of other kinds of methods that people
use without really understanding their limitations, and we talked about RICE earlier. Frameworks
think about the difference between a sorting technique and a framework as a
framework is something you can see that's visual and not in a spreadsheet. So you have the
common urgency versus importance Eisenhower Matrix probably the most common
framework that I see in product design and development is impact or value over effort,
another thing that's included in AHP. And then there are innovation games from Luke Hohmann
like prune the product tree, or speedboat, or remember the future. You can read about those and
he has a book called Innovation Games. And then Dave Gray came out with
a book called Game Storming many years later that talks about this stuff.
Simulations are an entirely different class of approaches to prioritization. A non-binding
vote is a simulation of how people are going to act in an environment and Buy a Feature is
applying economics to that. And you can put these together like Legos if you
understand what you're doing, so once again it goes back to what you're optimizing for
And once you understand what you're optimizing for it's very helpful to
then pick and choose the pieces that are going to solve for the challenges that you're
facing in dealing with that optimization. And if you're operating at scale in a complex environment
with multiple portfolios of risks and projects and products and investment opportunities, maybe
less so investment opportunities, but AHP is pretty much the only hybrid method I personally
have been able to find that stands up to the scrutiny of can you run it in an organization with people
that know what they're doing with purpose-built tooling to end up with an outcome that's likely to
lead to resource allocation that's going to be aligned back to the strategy. Other than
that you're going to have to sort of put together a recipe of other sorting techniques or frameworks
or simulations and figure out how to end up with some kind of sensible answer to the challenge
that you're facing. I don't know if I have any more slides here, let's see. This is really cool actually
as well because it's, you know what you've got here is a whole bunch of different techniques that are
applicable in certain places but not in others, right. So AHP is really great for
your top level prioritization, your strategic prioritization, your portfolio, within programs
and potentially down to product, and absolutely down to product backlogs
But something like something MoSCoW is much more
kind of categorical where you have one or two key people that matter right, so if you're trying to
do it in a large organization versus a small organization, the tooling would be
different that you need. The sorting technique you should use would be different, the frameworks
for visualization might be different, the degree to which you need to simulate. So Harry
you've not heard this but we're shortly going to be releasing a nice little bit of AI that will
simulate thousands of portfolios hunting for the one that delivers maximum value with
whatever resource constraints you have. So that's a great example of where you're combining
AHP which is about the scoring, with the simulation. So the combination
may change across different tasks and different scale of organizations and things like that
and you know one one of the big challenges with a lot of the frameworks here is in
a large organization they don't scale. So again RICE is great if you have one decision maker
but if you've got 30 decision makers from you know each one in a different
stove pipe with different goals and incentives, then RICE just isn't going to work because there's
no mechanism to get them on the same page. So it's not that AHP good RICE bad, it's
that they're both good in the right place. And so those strategic project portfolios,
product portfolios, digital transformation programs, things like that AHP is fantastic
But perhaps in a smaller organization, in a startup especially in the early
days some of those other techniques are really powerful as well. Yeah and I noticed Chris
just asked about highly volatile environments where priorities are
shifting constantly and how do you determine what to optimize for and I think that's going
to be situation dependent to a large extent, what I would suggest there is often
using either a quantitative or qualitative cost of delay, and if you have as the approach
for evaluating what you are then going to have to put off. Because what most people do is they simply
add to the list and they don't actually decide what they're not going to do or what they're
going to delay or defer and so having a group of people who agree that you know, going
back to the D and decide for DEGAP, having people agree that it's worth the the cost benefit
analysis is in favor of being intentional about prioritization, the question then becomes how are
you going to respond to that? And that response is going to depend on that environment. And
you know in the absence of any more information I would say cost of delay is your very best friend
There's an interesting assumption in the question actually, so Chris thanks for
the question right, because we get this kind of question a lot and
you know what I would suggest is that actually what's changed is what
options you're considering, usually. Your strategy shouldn't be changing. If your
strategy is changing every two minutes you have a totally different problem, your problem isn't
prioritization your problem is you don't know what your strategy is, right. You've gotta fix that
So your strategy shouldn't really be changing very quickly unless something
traumatic like COVID happens right, then your world changes, but usually strategy
moves more slowly than that, you know it's typically a big
off-site reviews and you know it takes a while to build a strategy properly
especially in a larger organization, but new ideas come in all the time. So what
you really need is that framework wherever you are on this map right you need that framework that
lets you quickly evaluate okay this new idea this, new opportunity - Wes using your terminology right -
this new opportunity where does it fit? Where does it rank? Does it rank above or below
the ones that we're already doing? What's the risk profile? Do we have the right resources available?
Okay, then we decide do we do it, and then what do we NOT do or delay or whatever
to make space for it? So we had a customer that
they reckon that they now make those decisions, that they respond to those changing
ideas 10 times faster than they did before. Simply because they have a structure
the strategy which doesn't change, it sits there as a scoring model and stuff comes through really
quickly right, because we know what that strategy is and there's buy-in to it
And again those other other methods on the left-hand side do the same thing but in different
environments, you know similar sort of ideas. And then the frameworks in the middle are
really interesting. One I would add to this list that's really important I think is the
the Priority Matrix - well actually it's the Impact/Effort Matrix right there - the priority Matrix
And you know the the combination of that, the Eisenhower Matrix, and with a little overlay
of risk usually, that's the bread and butter, that's going
to give you most of the information that you need to to really drive a decision
Yeah and I mean this is a very small subset of the hundreds of sorting techniques
frameworks, simulations. I'm not going to say hybrid methods because I didn't find a lot of them
that are out there. These are just the grab bag of stuff I wanted to
put into the mix, just specifically applicable in the context of product design and development, but
I mean back to the comment that you made Stuart a minute ago about the strategy not changing
and referring back to the book that I mentioned earlier "The Crux", the Crux of the
challenge the organization is facing is probably not changing and therefore your strategy which
is a response to that is probably not changing, and it's the relationship of that challenge to
the organizational response to that which largely should remain stable over some
reasonable period of time. It's all of the other stuff that comes in at a lower level that
causes so much churn. Absolutely and and so I'm going to ask one - we're actually
more or less out of time, so I'm not going to ask one more question - Harry is there
anything else that you wanted to share on the slides before we ... Uh no
Excellent, all right so the key message I think is, I think two really clear messages right - go
buy Harry's book when it comes out in December, and go buy our software which is available now
But more sensibly I think the key thing here is that what
I've heard from the guys today is that in order to be a high performance organization you
have to align your activities to your strategy and goals, and you have to do it at different levels in
the organization and there are a number of tools that you need to bring to the table to do that
Obviously we've got a dog in the race right, so I'm going to say AHP, the way
we do, it is good because we've actually bundled a whole bunch of those simulation
tools and frameworks and things like that around AHP to make it more useful
But there's a whole bunch of frameworks to help you do that and I think the key message, the
word that's just burning in my mind following this is intentional. Be intentional in
aligning with strategy, be intentional in deciding what process you're going to do to do that, to
achieve that alignment. So guys is there anything else that you'd kind of add to that
sum up? Not for me, I just so appreciate the opportunity to be here, thank you so much Stuart
I've learned a lot from you and look forward to continue learning from you. Likewise,
that's a process that goes both ways. Stuart I think that's a great way to wrap it up, what
you just said. Excellent, super. Thanks Wes, thanks Harry, thank you everybody for joining us .
And if anybody has questions or they want to reach out to you guys how should they do that?
LinkedIn is probably the best way to reach me - I'm Harry Max everywhere, LinkedIn Harry Max,
Twitter Harry Max, Gmail Harry Max - Harry Max everywhere. Yes and for me LinkedIn W Bright
Excellent, W Bright in Texas