(Today’s issue has a fun challenge question that demonstrates just how much the software industry has changed in the past 20 years. See Can You Answer This? below.)
Requirements are the fuel that Product Managers produce to feed the company’s software development engine. As part of refining the quality of those requirements, it’s helpful to understand that requirements don’t all serve the same purpose.
In fact, there are different types or categories of requirements, designed to obtain different types of results. For example, some requirements dazzle prospects during demos, although they are rarely implemented when these same prospects become customers (yet they became customers partly because of those dazzling features). Others represent solid new functionality that will be used to the hilt.
When presenting a requirement, Product Managers benefit from clearly determining its purpose and discussing it with the team. A clear understanding of the goal of the requirement reduces debate and confusion when it is being designed and implemented.
It’s a balancing act to include requirements from all the various categories, yet that’s exactly what is necessary to ensure that you don’t neglect an important aspect of the product as you improve it.
As the Product Manager, you are in the position to develop requirements that reflect the goals of the entire company, assisting its ability to sell, ability to deliver, and ability to service the product. Amid the advocates from individual departments like Marketing, Engineering, and Sales, you may be the only one who makes sure the entire company’s needs are represented in the product.
Read on below for a discussion of the various categories of – or reasons for – requirements.
Can You Answer This?
Talking about requirements always gets me thinking of product change and evolution, and how our economy has seen an amazing change in the software application landscape over the past two decades. So can you answer this:
What company was the largest independent software vendor (ISV) in 1985?
(answer at the end of the article)
Not Always Obvious
The purpose of a given requirement – the category it falls into – may take some thinking through, some discussion with other members of the team in order to drill down to the real reason or reasons that a requirement is offered. While a proposed new feature at first appears to be added user functionality, it could in fact be a cost cutting improvement for your own product implementation team when you look a little harder.
Let’s take a look at the major categories:
User Convenience
There are lots and lots of requirements that are suggested by the customer base and by consultants for the purpose of user convenience. They streamline tasks or make the interface easier to use.
User convenience does not provide the benefits you could get from new functionality. But many minor, convenient improvements to the software add up over time and result in customer loyalty, enthusiastic references, and a product that does better against the competition.
If you have a lot of programming resources, you can make room for lots of requirements that are for user convenience. I once knew companies that had lots of programming resources. But one thing you don’t want to do is spend too much time on little tweaks that please the existing customer base but don’t result in more sales to new customers.
User Capabilities
The category of user capabilities is what most people think of when they think of requirements. This represents major new functionality, or significant extensions to existing functionality.
New user capabilities are ultimately what put your product ahead of the competition and build its reputation out in the market. Many of the suggestions for new user capabilities come from prospects as well as gaps you uncover when analyzing your product relative to its competitors.
When too many of the requirements are new user capabilities, the result can be a messy product with lots of bugs or technical issues, and an overall impression of being unfinished.
Sales Appeal
During the sales cycle, your sales reps talk with prospects about all sorts of things they’d like to do with the software. Eager prospects also offer lots of exciting suggestions for new features – ability to work in zero gravity, speech recognition through a life size hologram of Princess Leia, etc.
It’s a time of endless possibilities, which means that maybe, just maybe, if you want to appeal to prospects and get them to buy, you’ll put in certain features just for their sizzle. Like an executive dashboard. Everyone loves the idea. But once they buy the software, only a fully customizable version will do, one that looks nothing like the standard version, and not until the software has been up and running for a year.
You can benefit from understanding when a requirement is there for its sizzle value. Because the functionality probably does not need to be thoroughly fleshed out. You’re not asking the software engineers to create the best solution with excellent performance levels. You’re asking for something cool that you can show during demos.
The key to such requirements is to figure out how to put them in with maximum dazzle and minimum effort.
Cost Cutting
Still other requirements serve the purpose of cutting costs. Requirements for implementing architectural changes, for example, often generate a flurry of discussion about market standards, relative merits of one technology over another, etc. But their purpose is either to cut the cost of the product to your company, or to cut your customer’s cost of ownership through ease of implementation or integration.
For example, the requirement to automate installation procedures by pulling together a series of existing scripts and processes into a single package is for the purpose of cutting cost (But read the section called Any Other Purposes? below).
Partner Appeal
A final category of requirements is those that serve to add partner appeal to your product. These are features or capabilities that either highlight your integration with business or technology partners – and often these can be of the “sales appeal” variety – or else make your product more appealing to potential partners. For instance, the requirement to package your services with supporting documentation and a structured certification program aims to increase your product’s appeal to potential VARs or integrators who want to ramp up quickly on the services that go with the software so they can provide the services themselves.
Any Other Purposes?
It’s possible for a requirement to fit into more than one category. The earlier example under Cost Cutting above mentions the requirement to automate installation. That also adds to the partner appeal for VARs who will install your software and control their own customer base. If installation is automated, a VAR can quickly learn the process and roll it out.
Clarity Means Focus
When you make sure that you as the Product Manager, and the rest of the management team whose job it is to back up the requirements for each release, are clear about the purpose of each requirement, you help focus design and development work. And focus means speed. Call me paranoid, but in the end it seems like moving faster than your competitors leaves you safer in both the short and long run.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
Here’s the Answer
Here’s the answer to the question posed above.
In 1985, Cullinet Software was the biggest independent software vendor.
Cullinet Software, founded in 1968, was the first software product company to go public in 1978. Its flagship product was IDMS. From 1986 to 1989, a series of strategies and decisions placed the company in a much weaker position. Cullinet was acquired by Computer Associates in 1989.
