Sorting Out Feature Requirements

October 1, 2018

Dear Strategy:

“How do you sort out the specific features of product requirements from tons of information gathered from market insights, customer, industry, competitors, etc.?”

On the surface, this may seem like a question that we’ve answered many times before on this show. I mean, we’re always talking about gathering insights about the industry, market and your own company, and then using that information to develop some sort of a future plan. But this question is unique in that it is talking specifically about using that information to develop product features, which is altogether different than using it to develop a product strategy.

Or is it?

Most companies that I work with will have some sort of a strategic planning process that is distinctly separate from their (typically) gated product development processes. Even in an agile environment, product development is usually performed as a separate process from strategy development. The strategic plan may serve as a reference point for any development projects that are currently underway, but, purely from a process standpoint, these two practices are usually treated quite differently.

Because of this, there can be some level of confusion as to whether or not the information used to develop a strategy would be the same information used when trying to justify a development project. To spare you any suspense, let me just say that it should be. You may be working to a different level of detail at for product development project, but the insights guiding your decisions should be coming from the same basic foundation.

The whole point of a strategy is to gather information and then use that information to make decisions. It would follow, then, that those decisions would be what you would use to help guide your development projects. Said differently, if you find yourself having to sort through “tons of information” for every development project, my guess would be that you are either not connecting your development projects to your strategy very effectively, or that you do not have a formal strategy to begin with. As you might guess, neither of these scenarios are particularly desirable.

So, the first part of my answer would be that you should use the information you gathered in your strategy (as much as possible) to guide your development projects as well. This will not only ensure that your project business cases and strategies are connected, but it will also prevent you from doing the same basic insight gathering work multiple times.

With that said, I don’t want to imply that if you have a solid over-arching strategy that you’ll never have to make additional decisions at a product feature level. It’s just that those decisions should be a lot less overwhelming because your choices should have already been narrowed down through your strategy to some extent.

Still, when you do need to make additional choices at a product feature level, you can use some sort of a decision matrix to help guide your process. A decision matrix is nothing more than a table that lists your features along one side, and then allows you to rate those features with respect to some criteria that will help you make decisions about which ones you might want to include. You will still need to decide which criteria to use for your evaluation, but if you choose within the same three categories used in your strategic analysis (typically company, market, and industry), you should find that your decision matrix all but creates itself.

So, your company criteria might include things like cost, revenue, and profitability impacts; your market criteria might include things like share position and addressing unmet customer needs; and your industry criteria might include things like competitive advantage and staying ahead of industry trends. Rating each potential feature with respect to each of these criteria (perhaps on a 1 to 10 scale in each column), will allow you to lay out a nice little matrix that could help guide your decisions with respect to which features should be included, and which should be left on the cutting room floor.

Of course, I always caution people about trying to turn decision-making into too formulaic of a process – so, you should proceed with some level of caution as you approach this methodology. Still, tying your criteria back to your strategic insights, and tying your evaluation back to your strategic choices, should allow you to infuse enough intuition into the process to get the best of both worlds. And, perhaps most importantly, you won’t need to do the same work twice, which means you’ll have more time to spend on coming up with your next big idea!

 

Listen to the podcast episode
Dear Strategy: Episode 063

 

###

 

Are you interested in strategy workshops for your product, marketing, or business managers? If so, please be sure to visit Strategy Generation Company by clicking the link below:

Strategy Generation Company - Strategy Training and Inspiration

 

Bob Caporale - Host and Author of Dear Strategy Podcast and BlogBob Caporale is the founder of Strategy Generation Company, the author of Creative Strategy Generation and the host of the Dear Strategy podcast. You can learn more about his work by visiting bobcaporale.com.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.