Marketing Expert's Corner

This article written in 2008
 

Priorities

If you're a fan of decision science -- and who isn't -- you believe that a company's competitive situation is a result of superior decisions.  Technologists will say that competitive advantage comes from better products, but those better products wouldn't exist in the first place if the corporation hadn't made a series of really good decisions along the way.

OK fine.  But just how do you make good decisions in trying times like these?  Welcome to this month's excerpt from my upcoming Prentice Hall book on Salesforce.com best practices.

I'm hoping that you'll find areas in this Report that I'm dead wrong about!  Please email me with feedback where you think I'm full of it.  Through vigorous debate, the ideas will get even stronger.  The best argument of the month wins a prize.

The Business Case

Nearly any important business decision is driven by a quantitative evaluation.  Of course, it's driven by financial ROI:  expected cash invested vs. projected revenues.  But some of the cost / benefit elements just don't fit into dollars.  How do you value strategic flexibility or better customer satisfaction?   How do you compare the internal "sunk costs" of an investment with, say, the political costs of a project that's unpopular with the boss?  Don't kid yourself, even the most spreadsheet-driven company will make decisions based on mainly non-financial factors.  They're just buried in footnotes, assumptions, or fictitious allocations in their lovely spreadsheets.

In almost any situation, the cost side of the equation will be on firmer ground than the revenue or benefits side.  As I wrote before, revenue forecasting is unreliable at best, capricious or even fabulous at worst.  But let's assume that the business case is approved for all the right reasons, now what?

The Feature+ Priority List

Whether you are working on an internal IT project, improving an existing product, or preparing a new product for launch, you'll need to develop and maintain a priority list for the development team.  In preparing this list, everyone reflexively focuses on features, but there are several other items that have to be prioritized as well.  For software, it's stuff like application responsiveness, install time, ease of use, internationalization, quality, and documentation.  For high tech hardware, it's things like setup time, control-panel software, self-test/auto-demo, packaging, and fit-and-finish.  You know, all the stuff that nobody wants to do but will make a big difference to the customer.  Don't be surprised if these items represent 30% or more of the work.  If you don't have these as explicit items on your list, resources won't be properly allocated and you'll have problems as the project progresses.

So let's assume you have a complete list of features and attributes for the project.  How should you prioritize them?  Some of the items on the list, such as bug fixes for an existing product, are expensive to do but won't yield any measurable revenue.  Others are vying for priority because they're competitive "requirements," but it's tough to determine which ones will make a big difference to sales.

All too often, prioritization is done by a purely political process that yields inconsistent or even illogical results.  The most important thing in this prioritization process is to involve the customer as closely as you can, without listening too much to:

  • very big customers (the root cause of The Innovator's Dilemma)
  • input that may have been fed by your competition (companies love to fill customers' heads with irrelevant "requirements" and absurd must-have features)
  • sales reps with an axe to grind.

The second most important thing for a high quality decision is to involve a variety of sources so that you don't ignore important input.  Here are some methods for doing that.

The Delphi Method

The Delphi Method was developed by the RAND Corporation decades ago because they noticed that the larger the group, the less accurate the forecasts (or the poorer the decision quality).  In big meetings, the ability of important or eloquent people to sway the group’s opinion overwhelmed “the wisdom of crowds.”  The collective IQ sometimes sank to the lowest common denominator of the group. 

The Delphi method is able to make forecasts and tradeoffs more reliable as the size of the group grows.  One of the innovations of the method is asking each participant what level of confidence they have in their own forecast, so that less-certain inputs are given less weight.  I've modified the base Delphi method for product and project priority spreadsheets.  Here's what you do:

  • Start by creating a column on the spreadsheet to indicate the importance of the requirement (“importance” needs to be a number from 1-10 indicating the business significance of the requirement).
  • Have another column indicating the rank or management level of the main champion of the requirement (higher is better, as it’s an indicator of internal political visibility).
  • Add a column on a spreadsheet for each of the cost and benefit areas of the proposed feature, and fill in as many of the rows as you can.
  • Finally, create a column on the spreadsheet to indicate the responder's level of confidence about the information on that row. (This should be ranked from 1-10, with 1 indicating “we really don’t know” and 10 indicating “we are very sure”.)
  • Create formulas in excel to create a weighted average that includes each of these factors to form a total score for each requirement line item.
  • Each person participating should fill in their own spreadsheet.  For manageability, keep the participants to 10 or less. 
  • The final step is to aggregate (with one last set of weighted average formulas) the “final scores” across all the stakeholders, so you get a single composite score for each requirement line item.

Use these scores to create an initial ranking of the requirements. Of course, this scoring system will not make any decision, but it does provide insight into what each of the stakeholders thinks is important.

Prioritizing via Investment Bets

In this method, you do not attempt to collect or evaluate preferences from a large number of people. Instead, you just ask a few executives to play an investment game, from which you generate a weighted average of their responses. It’s moderately fun to play this game, and it can be done in as little as 5 minutes of an executive’s time.

The set-up for this investment game is simple: each participant is given a hypothetical $100,000 to invest in the priority-list items according to what they believe would give the best business impact the company overall.  If they have trouble thinking this way, tell them to allocate the $100K to the items they think will be the biggest contributors to revenue.  Have each of them fill out a spreadsheet, and do a straight average of the investment "bets" placed on each requirement line item.

Weakest / Strongest Elimination

This exercise doesn’t use formulas or parametric analysis. Instead, it’s an exercise of  “American Idol” combined with “The Weakest Link.” This method isn’t very precise, but it’s useful for short-term priority calls because it’s relatively quick.

The prioritization is done as a group exercise, typically using a projector or video conference. The list of features is put in a spreadsheet, initially in “best guess” order of preference (with the no-brainers at the top of the list). The process is simple triage, and the goal is to divide the list into three groups:

  1. The features that are “above the line” – safe from questioning and sure to be done.
  2. The features that are alternates in case one of the “above the line” items can’t be done or needs to be delayed.
  3. The features that are “below the line” – won’t be done this time, no point in reviewing them any further now.

Using a moderator, run through the top part of the list to see if there are any items that can be demoted to category #2.  When the audience agrees on a demotion, move that item down on the spreadsheet so everyone can see the consequences.  Then run through the bottom part of the list to see if there are any items that need to be promoted to #2.  Move them up accordingly.  Finally, go through the category #2 items to see which ones need to be promoted or demoted from there. 

Popular Votes

Some types of organizations prefer popular votes as a matter of culture and management style. Popular votes are easy to conduct, but can be problematic when it comes to meaning and wisdom.  Not everyone who votes is equally competent or knowledgeable about product or customer issues, and some voters just won’t have as much at stake as others will.

In most cases, it is preferable to have unequal voting: VPs should have bigger votes than worker bees, and Sales should have a bigger vote than Accounting. This weighting issue is particularly important when sales territories disagree violently about how a product should evolve.  This may rub some people the wrong way, but business is not a democracy.  Be sure to set up the apportionment of voting before you actually take any votes, so that people don't think the voting was rigged. The weighing of different people’s “importance” may be a very touchy issue, so play nice.

Phone Us +1 650 326 2626