Improved Prioritization And Market Segmentation

balance

Prioritization is about maximizing the value you provide to your customers. When you have multiple sets of customers with different priorities, what do you do? You could try and find the lowest-common-denominator, and please everyone a little bit. But that would be the wrong thing to do – by trying to please everyone, you fail to delight anyone.

Setting Up A Prioritization Example

To keep it simple, imagine that your market can be divided into three distinct groups. You would represent each of those three groups with a persona. While working with customers in each group you identify that each group has a distinct set of priorities. You have five capabilities you want to introduce – represented by five features. You will be able to release one capability (feature) per release. Keep it simple for now by assuming they all have the same cost and time to implement.

Each group ranks the features 1 to 5. Each group ranks them differently.

no prioritization at all

One client I worked with would create a simple spreadsheet like the one above. Each group has a column, and each feature has a row. The number in each cell is the sequence of that feature, in priority order, for each group. That client would then add an “Aggregate” column, representing the sum of the values. My client would then sort the spreadsheet from lowest to highest aggregate value.

prioritizing the lowest common denominator

Feature 3 would be in the first release, then feature 2, feature 1, feature 5, and finally feature 4.

Each of the three most important features for any given group is highlighted in green, with descending intensity. This makes it easy to see that (for this example data) each group gets their most valuable feature in one of the first three releases. It takes until release 4 for all three groups to have their “top 3″ implemented.

You can call this the lowest common denominator approach. Relative value is averaged out across all of the groups. Each group has an equal say in what gets released when. One problem is that each group is (almost never) exactly as important as all of the other groups.

Prioritizing Features By Customer Importance

This approach, flaws and all (we’ll come to that) could be improved by taking into account the relative importance of each group. Consider adding a weighting value for each group. That weighting might reflect the size of the market segment, the strategic value, or a combination of factors that cause one market segment to be more important than the others.

adding group weightings

The chart above shows the same example, except now groups 1,2, and 3 have an importance measure of 10,20, and 40. The aggregate value column now incorporates that weighting. Instead of just adding up the sequence values for each feature, the values are first multiplied by the importance of their group.

Counter-Intuitive Math

You would think that since the smallest numbers come first, you might want to divide by the relative value of the groups instead of multiplying. When you aggregate the sequencing, higher numbers (lower priorities) tend to push features to the bottom of the list, and lower numbers (higher priorities) tend to pull numbers to the top of the list. If you divide by the relative importance of each group, instead of causing their inputs to bubble to the top, you end up reducing the relevance of the inputs from that group. By multiplying you make each group’s inputs relatively more significant, as the relevance of the group increases.

weighted lowest common denominator

From the color coding, you see thta group 3’s influence is greater than either group 1 or group 2’s influence. Also note that (for this example), group 2’s most important feature is scheduled ahead of group 3’s third most important feature – even though it is also the most important capability to group 1. The aggregate value column is now sorted, using the same approach as before, but with a weighting that favors the more important group.

The Problem With This Approach

The approach looks pretty clever, and it is not horrible. What it is is mediocre. And it encourages mediocrity. First, you get mediocrity because a feature that is “kind of appreciated” by all groups will get a lower aggregate value (and therefore a higher priority) than a feature that is incredibly super critically urgent for one group but wholly uninteresting to another.

Consider feature F1. It is (because we get to make up the examples here) critically important to Group 1. It is also completely irrelevant to group 2. This is because the people in groups 1 and 2 are very different. They care about different things. Because group 2 is uninterested in feature 1, group 1 has to wait until the fourth release to get it. Bummer for those losers in group 1.

Now consider feature F5. Group 1 doesn’t care about it, and they get it in release 2. Those guys are probably sharpening pitchforks and lighting torches.

They don’t get what they really want until release 4, and you can argue that this is ok because the other groups are more important. But you haven’t set expectations well. Group 1 thinks their inputs are fed into the mix, and your roadmap is for them just as much as it is for everyone else. Turns out, this approach is not very good for setting expectations with group 1.

Another Manifestation of The Problem

Now look at the flip side. Your most important market segment, group 3, does not get what they want in sequence. To keep our example exhilarating, imagine that each shaded feature (sequence 1,2, or 3) is a “must have” for the group that ranked it. No group will go live until at least the 1,2, and 3 (shaded) features are implemented. That means that group 3 – your most important market segment – cannot go live until release 4. Group 2 can go live after release 3. But group 2 is not the most important group. You tried to satisfy the biggest, most valuable group first – and it did not work.

Why? Bad math.

You cannot use “sequencing alone” to represent the value that each feature provides to each group. For one group, maybe only the first two features have a lot of value, and the other three are all relatively worthless. You get a form back from them that shows 1 through 5. But it does not show that the value of (the features sequenced first and second are ten times the value of the other three features.

Solving the Problem With Good Math

There is a solution. But it is so much more labor intensive that most teams won’t do it. You have to determine the value of each feature to each market segment. You can’t use sequence or priority as a proxy. It has to be a number. Then you can aggregate.

The Philosophical Problem With This Prioritization Approach

There is still a philosophical problem with this approach, even if you did solve it with the right math. As we mentioned before, you are creating a mediocre – and therefore sub-optimal – solution by aggregating (and effectively averaging) the value of each feature to each group. Those features that are “kinda nice for everyone” will beat out the features that one group is really passionate about, but other groups don’t care about. If you take this approach, why bother to even define personas – you’re subconsciously ignoring those insights. Market segments are dominated by the companies that put out the killer features. It would be “killer” for some users if their car could go offroad. And killer for others if it got great mileage. Another group might really care that it is showy and fast. If you prioritized a feature that helped each of those goals somewhat (say, really good tires), how passionate would your potential customers be? The offroad guys want a roll cage. The eco-hawks want a super-efficient engine. And the “all hat no cattle” guys want a wing on the back – and it should come in yellow.

You may find that your segments are so different that you need to treat them as different markets, or at least market different products to them. Otherwise, you end up with a car that goes offroad but cannot climb a 40 degree slope, that gets 25 miles to the gallon, and, while yellow, does 0 to 60 in 7 seconds. You don’t delight anyone. How much penetration will you get in any of those markets?

Not much.

The Better Way To Prioritize

Pick your most important market. Do the most important things to them first. Then go to your next most important market. Repeat. Your prioritized road map will look like the following:

customer delight road map

Group 3 – your most important market segment – goes live as soon as possible. After release 3. Your next most important market segment goes live next. Until you run out of features and segments. Note – make sure you continuously reprioritize. You may, for example, discover a new feature that lets you double your penetration with group 3. You should probably do that before finishing a feature targeted at group 1 – even if group 1 is not launched yet.

Conclusion

Do the most important things, for the most important markets, first. Then add the next most important thing, after you learn through your incremental release plan, even if it means delaying the launch in a lower-priority market segment, in exchange for higher returns from an already served segment.

Post to Twitter Post to Facebook

This article was published on Wednesday, April 9th, 2008 at 10:15 pm and is filed under Business Analysis, Prioritization, Product Management, Requirements.
You can leave a comment on this post

8 Comments

  1. Interesting theory…

    To some extent it seems to beg the question, though. How do you determine the relative importance of your market segments? Let’s assume profit is a key factor. Is your strategy to sell a few high-margin “sports cars” or a lot of lower-margin “eco-chariots”? If the strategy is not a given (constraint) then you can prioritize on the basis of profitability…but how could you do that when profitability depends on the changes you have yet to prioritize?

    What you need to do is consider the impact of your optional enhancements on your strategic objectives, in this case profit. You can then be agnostic about which segment you prefer. A feature that no segment ranks highly may well improve profitability across all segments more than any other feature. Why would prioritizing that feature lead to mediocrity? Even if it does, you just need to add a “stunnedness” metric into your strategic objectives…but if you do this, you will need to establish the relative importance of improved “stunnedness” and higher profits (to combine the scalar objectives into an objective function, in some fashion).

  2. I found this blog and Alan’s comment informative.

    What seems to be missing from this information is how market
    segmentation helps to determine the best target market for a product.

    It often even enables development of products for specific target
    markets. This can bring better profits than developing a generic
    product and then trying to find a market for it. Today, people want
    products developed specifically to meet their needs.

    Market segmentation sometimes involves math, depending on the process
    used, but it provides much more than just what features to include in
    a product. It also reveals the best appeals to use for a target market, their information needs, concerns, values, and the best media to reach them.

  3. Very useful ideas. The twist I’m wondering about is when your analysis isn’t separated by market segment. In that case, for example, the different groups might represent different types of stakeholders (ala outside-in development, these could be sponsors, partners, insiders, or end-users).

    If I tried to use the approach you describe to handle the overlapping / conflicting needs of different stakeholder groups, what would I need to do differently?

    In this case, Group 3 wouldn’t represent the most important market segment, but might represent an important (but maybe not “most”) stakeholder group.

  4. Alan,

    Thanks for commenting!

    I think the right approach is to prioritize segments. You can do that based upon a forecast profitability per segment, a strategic objective (say to serve an existing customer base with a new product first, then expand to other market segments), for competitive reasons (to undermine your competitor’s cash cow, or to gain a foothold / economies of scale before attacking), or whatever reason.

    The point being that it is far better to be excellent in one segment – even at the expense of other segments, than it is to be pretty good in multiple segments. And by prioritizing the features that are most important to a single segment, you reach that point earliest. I believe that you will have better market penetration in each segment this way, resulting in an improved rate of growth. If you model your market penetration and don’t see this, then it is moot – but I expect you will find this to be true.

    As to the “highly profitable, but otherwise mediocre feature” example, I disagree. Let me fall on my sword and say that I should have articulated that prioritization within a market segment would include whatever is important in that segment – if profitability is the driver, then that “highly profitable” feature would be highly prioritized. Sorry for not making that explicitly clear. Given that clarification, I don’t think your example would exist – the highly profitable feature (when prioritizing by profitability, within a segment) would be highly prioritized for all segments where it is highly profitable.

    Thanks again!

  5. Linda,

    Thanks very much for commenting and welcome to Tyner Blain!

    You’re right – I didn’t talk at all about how or why you would prefer one segment relative to another – or prioritize one ahead of another. I alluded to this in my previous comment.

    I think you’re right also that focusing on a particular market segment not only helps with feature-prioritization, but it also can provide clarity in marketing communications, promotions, branding, and other elements of strategically attacking a market.

    You’ve added to the conversation here too, and I appreciate it.

  6. Hey Carl,

    Great question / interesting twist!

    I don’t believe this approach works at all for prioritizing stakeholders, at least in the ways that you’ve defined stakeholders in Outside In Development. In that case, you have insiders, principals, partners, and end-user stakeholders. The insiders, partners, and principals (sponsors) all collaborate to achieve something that is a success with end-users.

    And in that case, you are, in my opinion, collaborating as a team to deliver success. You can’t optimize (at least generally speaking) by satisfying all of the most important needs of one stakeholder group in advance of others. I think this only applies when looking at segmentation of the market into mutually exclusive groups. Perhaps, within a body – say partners – you might choose to prioritize one subset of the partners stakeholders in advance of another.

    The benefit of attacking markets this way is that you get greater penetration of the market segment by making the customers love your product. I don’t think you get an benefits from having a subset of your principals love your product at the expense of another group. In this case, I think the “numerical best” approach – what I label as least common denominator – would work better.

    I’d go on to say, in my experience, that politics within organizations would completely trump any mathematical prioritization for internal stakeholders. So I would only take this semi-quantitative approach when segmenting end users.

    You have a lot more experience in dealing with stakeholders and their priorities – what would you expect to see?

  7. Thanks for responding, Scott.

    It seems obvious to me that there will be times when the best thing to do will not be the most important segment’s highest priority. Let’s say Feature A is Segment 1’s second priority (perhaps a close second) and everyone else’s first priority… I think I should delight the vast majority and please the minority, rather than delight the minority and ignore the vast majority.

    I agree that a value-driven approach may lead to mediocrity, but this is far from inevitable. We need to understand how to mix satisfaction and delight to deliver optimal outcomes.

  8. Hey Alan, thanks for continuing the discussion!

    In terms of your example, I think it comes down to one of those “it depends” questions.

    Will feature A, delivered to these other segments be enough, by itself, to get people to purchase in those segments (and delight them, in your example)? If so, then yes – feature A makes much more sense – you get immediate payback. If feature A is only one of 3 features that each segment must have to really be delighted (and drive exponential / word-of-mouth marketing style growth in those segments), then I am inclined to focus my efforts on a single segment first.

    Ultimately it all comes down to the math, right? I guess what I’m trying to highlight is that there is a better-than-linear growth opportunity in each segment, but to achieve it, you have to address all of a particular segment’s “delight” requirements before you can achieve it.

    And I guess I’m making the assumption that geometric growth in one segment exceeds a slower, incremental growth across multiple segments.

    Ultimately, you should compare the results of the “be some things to all people, and we will slowly grow in all markets” approach with the “be all things to some people, and we will rapidly grow in one segment (at a time)” approach. In any given circumstance, it is possible that one approach is a clear winner where the other is not.

2 Trackbacks

  1. [...] http://tynerblain.com/blog/2008/04/09/improved-prioritization, thanks to Scott Selhorst for yet another great idea. Go there if you need a more visual [...]

  2. By Jonathan Babcock on February 10, 2009 at 12:32 pm

    Reqts prioritization: Improved Prioritization And Market Segmentation | Tyner Blain http://tinyurl.com/av48dz

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>