≡ Menu

5 Approaches to Software Strategy

I recently visited a potential client company who wants help in setting strategy for its licensed software products. In the last few years I’ve mostly helped companies with IT strategy, so I had to think back to my product development days and consider the differences between IT strategy and software product strategy. And in doing so, I realized that there are lessons from software product strategy that can be applied for use in IT organizations as well.

From my own experience, software companies (and maybe non-software companies as well) set their product strategy using one of five different approaches:

  1. Internal Vision
  2. Surveys and Check Lists
  3. Customer Requirements
  4. Personas and Scenarios
  5. Some combination of the above

1. Internal Vision
Steve Jobs, founder of Apple, is an example. Jobs himself created the initial vision of what Apple products should be, and so the products were an implementation of his vision. It’s like this in some other companies as well, or at least it starts out this way. Typically it’s the founder of the company who sets the initial product strategy, and then the entire company rises or falls by that vision. If the vision is one that customers want, then the company succeeds. If the vision is out of sync with customer wishes and the visionary doesn’t adapt the vision, then the company fails miserably.

The visionary in this approach doesn’t have to be the founder of the company, or even part of the company when it starts. Sometimes an individual makes it his or her personal mission to create the vision and strategy for a product – even if the individual didn’t create the product – and the product strategy is then set based on that individual vision.

The biggest advantage of this approach is that the product strategy is consistent, and the products typically appear to be well thought-out and well engineered for their purpose. But when the product vision becomes too big for one person to control, other approaches have to be considered.

2. Surveys and Check Lists
In some ways this is the exact opposite of the Internal Vision approach. Companies who use this approach don’t have an “inner compass” that shows them the way – or they choose to ignore their inner compass. Instead, they rely on “scientific” methods to determine what the product strategy should be. Surveys and focus groups identify the desired characteristics of a successful product. Check lists for product features are created by consultants and third-party product reviewers. Then the product strategy is created by the company to maximize the product score on these checklists, while often paying little or no attention to overall product consistency and usability.

The result is a product that scores well on the checklists but usually fails to be more than a mediocre performer in meeting customer needs. Thus this approach is a good way to avoid product failure, but not a particularly good way to achieve product success. Software defined this way often has feature bloat (an unreasonable swelling of the software to accommodate too many check list items), and it becomes non-intuitive and difficult to use. This is particularly true when the software is cobbled together from the source code of multiple acquired products. Some of the Microsoft products fall into this category.

3. Customer Requirements
This is like the Surveys and Check Lists approach but it’s targeted at specific customers instead of relying on a sample of potential customers. The concept is simple: If you want to know what customers want, just ask them, then do what they say. Of course there are a few problems with this approach. For example, if you ask a ditch digger what he needs to do a better job, he’s likely to say a bigger shovel if he’s never seen a backhoe. Most customers can only tell you about minor improvements that are needed in a product because they’re too close to the existing model of product use. It takes a different perspective to step back and look at the bigger problem, then recommend an improvement that radically alters the processes being used. Customers are not likely to have that perspective, so the Customer Requirements approach typically only gives you incremental product improvement.

Customers also tend to have conflicting requirements. The tradeoffs among the various conflicting needs are not easily made without a detailed understanding of how the customer actually uses the product (not typically obtained using the Requirements approach), but it’s these tradeoffs which ultimately cause the product to fail or succeed.

4. Personas and Scenarios
In his wonderful book, The Inmates are Running the Asylum, Alan Cooper describes a method that goes beyond customer requirements to focus on the process itself. Cooper asks you to create a few imaginary users, each of whom has specific goals for using the software. For payroll software, for example, you might create Joe Employee (who just wants to get his paycheck on time and with minimal hassle), Susie Payroll Clerk (who wants to minimize her own weekly effort while simultaneously minimizing the number of people calling her about problems with their paychecks), and Henry HR Manager (who needs summary reports to satisfy company executives and to meet various regulatory demands). Now Cooper proposes that you imagine typical scenarios that each persona might follow in the use of the product. For Susie Payroll Clerk, those scenarios might include the weekly time sheet process, data entry, checking for errors, and distributing paychecks. Design your software to maximize the satisfaction of each persona in each scenario, and you’ve gone a long way toward providing the ideal software product.

As Cooper points out, “To create a product that must satisfy a broad audience of users, logic will tell you to make it as broad in its functionality as possible to accommodate the most people. Logic is wrong. You will have far greater success by designing for one single person [the persona].”

5. Some Combination of the Above
I’m always amazed at the way various companies mix and match these approaches. Sometimes the combination creates a better product, but more often it just raises internal conflicts among the designers. If you have to use multiple approaches, then make sure you pick one of the approaches as primary, and then use the other approaches to fine-tune the primary approach or to sanity-check the design. For example, you might choose Personas and Scenarios as primary, but still do focus groups to help you improve your definition of the personas and scenarios that you use.

Conclusion – Getting Back to IT
“Ok,” you may be saying, “what does this have to do with IT? My IT organization doesn’t have any products, and I know exactly who is going to be using my software. Is any of this relevant to me?”

Yes it is. Consider that:

  • The people who use your software will eventually leave their jobs and be replaced by others who have different opinions about how to do their jobs.
  • Organizations change, and you may find that your software will be used by people in newly acquired divisions, in new locations, or even in different countries.
  • Job definitions change, and the work that’s currently being done by several people may someday be done by one person. Alternatively, the work being done by one person may be split apart to be done by multiple people.
  • Transaction volumes change, and a system that is adequate for today’s volume may be overwhelmed by higher demands in the future, or may be too cumbersome to satisfy a future decrease in volume.
  • Technology changes, and the user interface method used today may be replaced by a different method in the future.
  • The IT organization itself will change, and the people working on a system today will be replaced by different people down the road.

In light of all of this change, it’s not enough to just modify the system based on what your users tell you. Whether you realize it or not, you need a product strategy for each system even if the system is only used inside your company.

So think about the five approaches. Which approach do you want to use to define the product strategy (or “system strategy” or “software strategy” if you prefer one of those phrases) for each system you have? How will you use that approach to optimize the user effectiveness of each system within the budget limitations you’re given? And how will you use that approach to justify an increased budget for those systems that need more work, and a decreased budget for those systems that are good enough?

Product strategy isn’t just for software you sell; you really ought to have a product strategy for every one of your systems.

Related Posts and Articles

Comments on this entry are closed.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this. For more information on the use of cookies on this web site, see http://blog.makingitclear.com/cookies/