Prioritization and Value Maximization

12 Comments

1. 

   Kelly Waters

   Posted August 1, 2007 at 6:49 am

   This is a really great article Scott! You’ve really taken on my simplistic way of visualising these two dimensions on to something that can be judged on a more quantitive basis. I really like the idea of a value-to-effort ratio driving the order of priorities.

   Kelly.

   Reply to this comment
2. 

   Scott Sehlhorst

   Posted August 1, 2007 at 1:04 pm

   Thanks Kelly, and thanks for starting the conversation and contributing to the exploration. And I would not describe your visualization as simplistic at all. Your introduction of work into the equation is what got this whole thing started. Without that, and our discussions, I would not have been able to write this.

   Thanks again, and thanks for helping everyone here – both with your blog and with your comments at Tyner Blain.

   Reply to this comment
3. 

   Scott Sehlhorst

   Posted August 1, 2007 at 1:06 pm

   Oh – for anyone who was wondering about the image for this article. The image is from the Invisibles Quiz at Filmwise http://www.filmwise.com/invisibles/invisible_284.shtml

   Answers are available at http://www.filmwise.com/invisibles/invisible_284a.shtml

   The image above shows the clothes (without the emperor) from the movie Gladiator. A very fun site if you are a movie buff, but be warned, you may lose a lot of time taking the quizzes on the site.

   Reply to this comment
4. 

   Brian lawley

   Posted August 3, 2007 at 11:58 am

   This is an approach that I have used for years, although your analysis and way of thinking about it is a little deeper. Basically once you have ranked the value priority of features you work with your team to determine the amount of work required. High value features that are easy to implement move to the top of the list.

   There are a few potential pitfalls though:

   - Over many releases you may never get to the bigger items that can truly differentiate your product

   - The synergy between use cases (and individual features) isn’t necessarily taken into account. Oftentimes if you implement specific combinations the sum is greater than the whole.

   - The competitive environment may force you to implement something that is lower-value but higher-effort but that customers consider a must have in order to purchase your product.

   - The end result may provide good value to the customer, but may not be above the bar for you to be able to get any press and pr around the new version of the product. (i.e. the press may just view it as a simple .x rev and not cover it, so the market and your customers may never find out about the new features.)

   Reply to this comment
5. 

   Scott Sehlhorst

   Posted August 6, 2007 at 9:57 am

   Thanks Brian for reading and commenting!

   Your insights are great additions to the discussion! It further emphasizes that you can’t use a simple heuristic for prioritization. The notions of synergy, attracting buyer personas, and getting PR are great ones that you can’t reasonably roll into a working system.

   Net net, prioritization will always be something that is guided by (articulated) value, but ultimately finalized with expertise.

   Thanks again!

   Reply to this comment
6. 

   Tim Owen

   Posted August 7, 2007 at 3:19 am

   Scott,
   It would be nice to understand how you determine, in a product context (not a one off consulting project where a single customer determines value), how to establish value for a use case. Your analysis presumes some level of value for each use case. It is easier to determine level of effort than level of value in my experience. I work in an agile environment, where story cards are not fully fleshed in use cases either so the value is even harder to determine at the story card level. Would like some thoughts on these topics.

   Thanks.

   Reply to this comment
7. 

   Scott Sehlhorst

   Posted August 7, 2007 at 8:42 am

   Hey Tim,

   Thanks for reading and commenting! I’ll tackle your first question in this comment, and your second question in the next comment.

   When I approach valuation in a product context, I look at three general areas of perceived value. In no particular order:

   • Perceived Value to Buyer Personas
   • Realizable Value to User Personas
   • Strategic Value to “us” (the software creators)

   Buyer personas are important because they influence short-term sales. For consumer products, the buyer is often the user. However, I also pour analysts, reviewers, etc into the buyer persona bucket. This group, in my experience, tends to care more about speeds and feeds in red ocean markets – and tends to be sold on “vision” in blue ocean markets. Admittedly, my background is overweighted in enterprise software – would love to know if folks with more consumer software experience think about it differently.

   User personas are important for two main reasons. First, they are the people who affect change, or realize value, by using the software. Second, they are the word-of-mouth marketing engine that can drive product sales, increased adoption and usage (thereby magnifying ROI), and provide feedback and ideas that help make your product even better.

   Finally, as a company with a distinct competence, and a market strategy, there will be goals for defining brand, presence, and penetration. Some product features might be strategically relevant while not representing immediate value for the current user base, and while not encouraging purchases today by the current buyers. But they could be important to future positioning.

   In that context, I apply strategic “value” as a benevolent dictator – questioning, rethinking, and enforcing a company vision and therefore a product vision into the prioritization mix. I also treat this separately from the relative valuation of use cases, but wanted to get the idea into the answer, without clouding the discussion.

   This leaves individual use cases to be valued. A use case has an inherent value to the actors who perform it. This is the same “per user” evaluation that is done for “one off consulting projects.” The only trick is to establish a cross-market valuation. Pragmatic Marketing puts it really well in their training – you aren’t trying to understand your customer, you’re trying to understand your market. I’m trying to capture “use case X has value Y to customers Z.” In this case, customers (Z) are all of the customers that meet a particular profile. Sort of a blend of market segmentation and “persona development for companies.”

   Each customer in group Z(or prospect, if you prefer that term) will have their own frequency of use information for a given use case. We can combine this data to say that use case (X) has an average value of (Y) for customers in bucket (Z). And by knowing how big bucket (Z) is, we have a market-based value for use case (X).

   Within each class of customers, we estimate the values of the particular use cases. If we were targeting only a single group of customers, this gives us the valuation. The answer is more interesting when there are multiple market segments (groups Z). You can proportionally adjust the values (Y) for the sizes of the groups (Z). And then add them all up and do the most valuable features.

   I don’t, however, think that is the best way. If there isn’t a single group of customers (Z) that dominates your market, then you end up trying to be all things to all people. I believe you are much better off targeting a single market segment, and optimizing on it. At some point, you have to “make the call” and switch from the next most valuable use case for that market segment to the most valuable use case for the next market segment – which is now your new focus. Again with the dictator thing.

   As part of this strategic (dictator) decision, you have to look at how you can address buyer personas. While not directly valuable (as in, not causing the realization of value for a single company), they are indirectly valuable – as they make it more likely that you will sell your product. I guess you could apply some sort of “probability of impacting a sale” numbers to those buyer focused features. I haven’t seen anyone try that, and I suspect you have to do something less quantitative and make the call.

   Anyway, that’s how I would approach it, as described from the bottom up. From the top down, I would say.
   1. Segment the market into similar customers.
   2. Prioritize those market segments, and attack them in order.
   3. For each market segment, prioritize the use cases – incorporating a notion of buyer personas into the prioritization.
   4. Plan the sequence in which you will expand to other market segments.
   5. Execute.

   Reply to this comment
8. 

   Scott Sehlhorst

   Posted August 7, 2007 at 8:47 am

   Tim – on the subject of story cards…

   What I like about agile approaches is that they aren’t “don’t document”, they are “only document enough.” And I would say that if story cards aren’t fleshed out enough to be able to understand (or at least approximate) their value, then they aren’t “enough” and you might want to do enough more upfront work to do some valuation. The more you understand about the value of each story, the better your ability to prioritize them.

   At a minimum, get the broad brush understanding of your space, and get the next level of detail for those few stories you suspect are the most valuable.

   For exactly this reason (the challenge of valuation), I believe the better approach (at least on projects I’ve worked on) is to use use cases – even if informal ones, combined with persona development to set the stage for agile delivery.

   Thanks again for participating and for the great questions so far!

   Reply to this comment
9. 

   Adam

   Posted August 8, 2007 at 2:08 am

   Wow, excellent post Scott. There are lots of great thoughts in here.

   I’ve been a PM in both consumer and enterprise environments, and both differ greatly. If you aren’t careful with managing expectations of product mgmt, both product types can easily become very jagged no matter how you prioritize the features.

   That being said, I’ve always felt there are two key ways to plan a release:

   1 – Time to features
   2 – Features to time

   If you construct a set of user stories, have dev estimate (and in some cases, add padding afterward), and say, “OK, based on these numbers, and the knowledge we want to release in 1 week, we can do features 1-5.”

   Now, the key missing here is the market data. In both enterprise and consumer products it’s critical. Again though, don’t let the few that shout the loudest get the most. Market data really is about wisdom of crowds, and leveraging that data you glean from your research efforts to solve a market’s pain.

   Not enough companies do this properly, or enough, in my opinion. Listening to your market does not mean taking a phone call from a customer that’s dumped a ton of money in to your company and implement whatever they want. But, I digress.

   I’d take the ordering of features to time based on the dev estimate and ensure the matched-up to the data I had received. For example, if dev told me they could do features 1 & 2 for the release, but may have to drop feature 3 to hit the release cycle.

   If I wasn’t getting a sense from the market that feature 3 was super important, who cares. Release fewer features that are 100% done as opposed to a bunch of half-assed ones that only “kinda” work. Even in an iterative approach this is critical – and becomes silly to even think of ignoring, seeing as you can just fix / tweak / enhance existing foundations week after week, day after day.

   So, after all my rambling, and looking at this from a self-serve / consumer market mindset, my thoughts would be:

   - Fit the features to your iterative release cycles based on each user story / requirement estimate from dev

   - Ensure what you are fitting to the time is actually something the market values and will help solve a problem(s)

   - Release features that are done, even if it means dropping them during the iterative cycle when you realize it’s just not going to happen for the release

   It’s still easy to stretch yourself too thin. You can always make it up in a release next week though =)

   Reply to this comment
10. 

    Scott Sehlhorst

    Posted August 8, 2007 at 9:48 am

    Thanks Adam! Great tips all.

    Reply to this comment
11. 

    AlanAJ

    Posted August 14, 2007 at 8:49 am

    To give Tom Gilb his due, his dynamic prioritization technique using an impact estimation table has been guiding Evolutionary deliveries based on maximal stakeholder value per step (timebox) for years going on decades. Your pictures are better, though!

    See Competitive Engineering (Gilb 2005) ISBN 0-7506-6507-6, Chapter 9 for details. For example, on page 265 you can see that while oranges are a “better” solution than apples (470 vs. 260), the performance to cost ratio is far better for apples (5.2 vs. 1.57). Remember this next time someone tells you you can’t compare apples and oranges!

    Reply to this comment
12. 

    Scott Sehlhorst

    Posted August 14, 2007 at 9:53 am

    Thanks Alan! I wasn’t familiar with Gilb’s work.

    You can also see the same efficiency element at play in his presentation on measuring engineering processes: http://www.gilb.com/community/tiki-download_file.php?fileId=84

    Thanks again, there is a ton of stuff on his site!

    Reply to this comment

One Trackback

1. By Thomas Eichberger on April 29, 2011 at 9:52 am

   Prioritization and Value Maximization in Sprint planning meetings http://goo.gl/eZ4BY

Post a Comment