What’s the difference between a Requirement and a Feature?

Let me try and explain this difference in this short blog post.

What is a Requirement?

One of my favorite books on requirements, “Software Requirements,” by Karl Wiegers defines a requirement as follows:

A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective.

Another of my favorite books on requirements, “Mastering the Requirements Process,” by Suzanne & James Robertson defines a requirement as follows:

A requirement is something the product must do or a quality it must have.

Great definitions, both. Taking these into account, I’d define it as follows:

A requirement is a capability that a product must possess or something a product must do in order to ultimately satisfy a customer need.

A requirement tends to be more granular, and is usually written with the implementation in mind. Those who consume requirements tend to be engineers or technical audience.

What is a Feature, Then?

Again, culling from the books linked above, I’d define a feature as follows:

A feature is a set of related requirements that allows the user to satisfy a business objective or need.

A feature tends to be a “higher-level” objective than a requirement - and is usually more focused on business needs rather than implementation.

Usually a feature is something you’ll print on a detailed datasheet of your product/service - i.e. intended to be shared with your customers and prospective customers.

An Example

Do you find the definitions above a little hazy? Here’s an example to help give you a more tangible feel. Let’s say you’re designing an online bookstore to compete with Amazon. [P.S. I wish you good luck, you’re gonna need it! ]

For such a project, here’s an example of a feature:

• 1-Click Ordering

Here are some examples of requirements related to this feature:

• User shall be able to activate 1-click ordering within his account
• User shall be able to deactivate 1-click ordering within his account
• User shall be able to order books with just 1 click
• …
• User shall be able to “Undo” his 1-click order for a period of 30 minutes from the time he placed such an order

I hope you find this brief blog post helpful to understand the distinction between a requirement and a feature.

Please chime in with your thoughts or perhaps an even better definition - click here to let your thoughts known…

One sentence in her post caught my eye:

…many requests for solutions are obscured insights into problems.

This is an excellent point by Cindy. I’ve found this to be very true in my own experience as well.

Why Feature Requests From Customers Are REALLY About Unsolved Problems

When a customer asks for a new feature - they may or may not actually want/need the feature they ask for!

Often product managers make the mistake of assuming that the customers know exactly the feature they need. But this may not be a correct assumption in many instances.

What the customers do know - and they know this really well - are the problems they have that are unmet by your product or service. They not only know about these problems, but very often they know them far better than product managers or anyone else at your company.

What Does This Mean To Product Managers?

The next time a customer asks for a new feature - make a concerted effort to understand what problem(s) they have that they’re trying to solve by asking for this feature. Really, really understand the problem. In depth.

Then design a “feature” that solves this problem insanely well - far better than even the customer might have envisioned.

What do you think - does this make sense, or am I off-base? Click here to let me know your thoughts…

This is a short post, but we wanted to share this interesting list with you…

It is based on a quick survey we ran to visitors to some pages of our site between Jan-12th and March-16th. We asked the visitors who were in Product Management or Product Marketing to give us a list of tools they use most often to perform their day-to-day tasks. Here’s the list of top-10 tools in order of their popularity - please note that #10 is actually one of the product management tools built for product managers (gasp!)

Product Management Tools

• Microsoft Word
  • MRDs, PRDs, business cases, competitive matrices, etc
• Microsoft Excel
  • Requirements tracking, Financial analysis, Charts, etc
• Microsoft Powerpoint
  • Roadmaps, Customer presentations, Training, etc
• Web Conferencing Tools - Such as WebEx, GoToMeeting
• Bugtrackers - Such as Bugzilla
  • Collaborate on bugs with Engineering teams
• Screen Capture and Image Editing Tools
• Online Office Suites - Such as Google Docs
  • Largely similar use as Microsoft apps above
  • We were surprised these were this popular!
• Wikis
  • Collaborate with internal teams (Engineering, etc), as well as Customers
• Survey Tools - Such as Surveymonkey and Surveygizmo
  • Customer surveys
• Requirements management tools - Such as Accompa
  • We think the presence of these tools in the top-10 list is likely skewed because some of our traffic is from our own customers, and customers of similar software who’re looking to switch
  • That said - we think these useful tools are starting to come into their own, and are starting to get adopted by more and more product management and product marketing teams

What are your thoughts on this list? Did we cover all of your frequently-used and favorite tools? If we left any out, which ones? Click here to let us know…

One of our sales reps is close friends with a sales rep from a competitor - let us call them Jim and Bob (not real names!). They actually spent the Christmas holidays skiing together.

One of the stories they commiserated on was how they both felt that executives (C-level) at most companies seem to place very little importance on their Product Management teams, compared to Sales or Engineering teams.

Are “Product Management” Teams Second-Class Citizens?

First let us share with you why Jim and Bob felt this way. Over the past year, they’ve been part of a good number of sales opportunities where the Director/VP of Product Management really wanted to buy the software for their PM team. But they couldn’t get approval from their bosses to purchase the software. Which left the Director/VP pretty dejected - and of course, Jim and Bob too.

The funny thing is - software from both of our companies is very affordably priced. Compared to what most companies spend on SFA (sales force automation) or Development (Engineering) tools - software for PM teams cost a fraction, often less than one-tenth and as little as one-hundredth in some cases.

Because of this experience, Jim and Bob felt that C-level execs at most companies place very little importance on Product Management teams.

If this were indeed true (we’re not 100% convinced it is true, due to reasons that follow) - then perhaps these C-level execs are stepping over dollars to save pennies. How so?

If PM teams turn out bad MRDs/PRDs - Engineering teams will waste their time working on the wrong things. Then Sales teams will waste their efforts trying to sell the wrong product. Everybody loses.

A Call to Product Management Professionals

Whether what Jim and Bob felt is true or not - one thing we’ve observed over our couple of decades in Product Management is this. Most C-level execs place far more importance on Sales and Engineering than Product Management.

This is kinda bad news to PM teams - especially in a bad economy.

Our call to Product Management professionals as we usher in 2009 is as follows:

• Justify your existence to C-level execs proactively, and regularly
• Demonstrate to C-level execs specifically how your PM team’s actions in the past year helped the company
  • Be as specific as possible
  • How did you help achieve higher revenue, lower costs, achieve competitive differentiation, etc
• Demonstrate to C-level execs how your PM team’s planned actions in 2009 will help your company
• Proactively structure the work done by your PM team to be of strategic importance, from the perspective of C-level execs. Then tell them about it.

In a nutshell: Justify your PM team’s existence by doing important work in 2009, and tell everyone (as loudly as you can!) including your C-level execs what you’ve done.

This will help ensure that the valuable contributions by your PM team is recognized by C-level execs - and will lead to PM team having a higher impact on your company, better career progression, increased job security for PMs, and may be even an approval when you want to spend a little money down the road to give your team a tool better than good ol’ spreadsheets!

P.S. The reason we’re not 100% convinced with Jim & Bob’s feelings is this. Even in a bad economy, more and more companies continue to purchase tools from Jim and Bob to help their PM teams work more successfully & efficiently. We think that while many C-level execs may place less importance on PM teams compared to Sales or Engineering, it is unlikely that most of them place very little importance on PM teams.

What are your thoughts on this somewhat controversial topic? Click here to let us know…

What is a “Persona”?

A Persona is an abstracted representation of a typical user of your product.

For example, let us assume that your company makes Sales Force Automation (SFA) software. One of the personas can be as follows:

Scott Smith - A sales manager at an auto-parts wholesaler. He manages 7 sales reps and 1 sales administrator. He’s moderately computer savvy, and is a Type-A personality. He is responsible for quarterly team revenue goals, as well as weekly activity goals for each sales rep. He uses our software every day. He has a 4-year college degree, and is 37 years old.

How to Create Personas for Your Product

Create the personas for your product by following these simple steps:

• Identify the major categories of users for your product
  • For our SFA software example, this could be: Sales rep, Sales manager, VP of sales, Sales admin
• For each category of users, create a fictional persona with enough relevant details to seem like a real person
  • Relevant details include information such as Job Responsibilities, Education, Skill Level, and Frequency of Use. You may also include name, age and gender to make the persona seem more real - as in our example above.
• Avoid unnecessary details
  • Don’t go overboard when adding unnecessary details - otherwise some “cranky” product manager blogger may write you up!
• Create one persona to represent each major category of users

Observing real users using your product is one the best ways to gain the insights needed to create personas. You can create a persona by combining characteristics of several real users to represent a “typical user”.

How to Use Personas

Using personas while defining and managing requirements shifts the perspective of requirements to focus on what the users need from your product, rather than the traditional approach of what features your product should have.

Here are some steps to follow while using personas to define and manage your requirements:

• Identify all the major personas for your product. Consider both end users and buyers of your product.
• Prioritize the personas, based on criteria specific to your company and market.
• Identify the needs of each persona - ideally in the form of use cases.
• Prioritize the needs, based on ROI or other metrics.
• Translate these needs into requirements.

Personas provide an alternative, user-centric way to manage your requirements that can be more effective than the traditional feature-centric approach to requirements management.

What are your thoughts about using personas to manage requirements? Click here to let us know…

They lost a big sales deal (worth several hundreds of thousands of dollars) because they lost track of a critical requirement when their product manager left their company.

What Sales Reps & Engineers Do Better Than Product Managers

Sales reps need to keep track of Opportunities - i.e. the list of prospective customers - and data related to these opportunities, such as call logs and tasks. Opportunities are one of the most important pieces of data tracked by sales reps at most companies. How do they keep track of this data? Using Excel or Word? Nope. Almost always using a sales force automation tool (or contact management tool) such as Salesforce.com, Saleslogix, etc.

Likewise, Engineers need to keep track of Issues - i.e. defects/bugs in their products - and data related to these bugs. How do they keep track of this data? Using Excel or Word? No again. They almost always use an issue tracking tool such as Bugzilla.

Why Not Product Managers?

Yet, product managers at most companies use Excel or Word to keep track of Requirements (or feature requests) - one of the most important data they track.

This was the case at the prospective customer I spoke with yesterday. Their old product manager had kept track of requirements in an Excel sheet. When he left, the requirements got lost because others in their organization did not have visibility into these requirements.

This is a case where a requirements management tool such as ours or the ones from our competitors would have helped immensely - just the same way sales reps and engineers benefit from their respective tools.

I think the primary reason most product managers still do not use such a tool is - Product Management is a much younger profession compared to Sales & Engineering. As the profession matures, it will adopt better tools, just like Sales & Engineering professions do today. As a matter of fact, we at Accompa (as well as our friends at our competitors) are already starting to see the beginning of such maturation.

What do you think is the reason product managers still use Excel or Word instead of better tools to track requirements? Let us know your comments.

In this post, we’d like to outline some practical steps that PMs can use to get started with this practice.

Practical Steps

1. Create a list of all the major benefits to your organization that implementing new requirements and features can produce. Examples, as mentioned in our last post, include:

• Build customer loyalty
• Create competitive advantage
• Further business strategy
• …
• And, of course, financial benefits: Increase revenue & profits

2. Give each of these benefits an appropriate weighting.
3. For each requirement/feature under consideration, assign a value to each benefit on a scale of 1-10.
4. Calculate the weighted sum of all the benefits. This is the “Total Return” of a given requirement.
5. Assign a value to the “Investment” needed to implement the requirement, again on a scale of 1-10.
6. Divide “Total Return” by “Investment” to calculate ROI Metric for the requirement.

Once you normalize this ROI metric, you can then use it to prioritize your requirements and features in your next MRD (Market Requirements Document) or PRD (Product Requirements Document). This will help you implement a structured method to prioritize your requirements.

We believe that this type of a structured methodology is much more repeatable and defensible than ad-hoc judgments often used to prioritize requirements and features.

What do you think? Let us know your comments.

Scott Sehlhorst wrote:

You won’t go wrong by focusing your company, your strategy, and your products on solving valuable problems.

Jeff Lash said:

Rather than simply counting the number of features or the amount of enhancements, product managers should evaluate the ratio of value to effort and focus on obtaining the most value for the customer with a given amount of effort.

We agree with both Scott and Jeff. When it comes to prioritizing requirements, we believe there is one metric that helps you more than any other metric. Wondering what it is?

The One Number

This one metric is ROI (Return-on-Investment) - but we don’t mean it in the normal sense of this acronym.

ROI is most commonly used as a purely financial metric:

ROI = Financial Return / Financial Investment

We mean it in a much broader sense. Think of all the benefits that a feature/requirement will provide you. For example:

• Build customer loyalty
• Create competitive advantage
• Further business strategy
• …
• And, of course, financial benefits: Increase revenue & profits

Give each factor an appropriate weighting (based on your company and product) and calculate the total return. Then divide it by the financial investment to get an ROI Metric. Once you normalize this (not-purely-financial) ROI metric, you can then use it to prioritize your features/requirements.

We believe that this one metric is a much better guide for prioritizing requirements and feature requests than any other single metric.

Do you agree? Let us know your comments.

Just wanted to let you know that starting today our blog has a new name.

We used to call it “Practical Product Management” - since we write about topics covering practical aspects of product management.

It turns out that our friends at Pragmatic Marketing, Inc have trademark rights for the phrase “Practical Product Management”!

Since we’re known as good kids that play well with other kids , we’re changing our blog’s name to “Product Management Insights“.

Under this new name, we will continue to write about insights into practical aspects of product management, aimed at helping product management professionals everywhere. Thank you very much for your readership and support - and as always, we wish you outstanding products and continued success…

Gopal compares his stand-alone GPS unit vs the built-in GPS unit in his new Toyota Camry car, and poses a question:

The system controls not only the GPS, but also my bluetooth telephone via speed dial, phonebook etc, the four disc CD changer and a bunch of other things.
….
It sure does meet all product functionality requirements that it was set to achieve, but it falls well short of usability requriements - thanks to product integrations. Do your products suffer from this same problem?

The question of “Should we keep adding features requested by various stakeholders even though it may drastically affect usability?” is one of the important questions faced by Product Management teams at many companies. Here are our thoughts on this.

Balance is the Key

The key thing for product managers to keep in mind as we ponder this question is the difference between:

• Purchase Criteria, and
• Usage Criteria.

The most common argument to keep adding new features, especially for B2B products, is that buyers prefer products with more features. This argument is usually made by Sales teams.

In our experience, this argument is often true. Many vendors use Feature Matrices as one of their key sales tools. These matrices are used to convince prospective buyers that the vendor’s product has more features than products from their competitors, and hence is better.

As a result, there is a lot of pressure on product managers to keep adding new features. Adding new features eventually leads to loss of usability - and if left unchecked, ultimately makes it very hard for users to achieve the single main task that they bought the product for!

Here are some ways product managers can ensure that their product remains easy-to-use even against the pressure to add new features: 

• Only add features that are requested by many customers. Do not implement one-off feature requests.
• When adding new features, always keep usability in mind. A trick you can use is to make one usability enhancement for every new feature.
• Educate key stakeholders that adding features is not always the best way to go - use recent successes like the Apple iPod as an example that focus on usability can win in the market too.
• Create spin-off products rather than adding features to current product.
• In the battle of Usability vs Features, champion Usability - odds are your company already has many champions for Features!

In Summary:

We think Product Management teams should carefully balance Features with Usability - and never lose sight of their product’s Raison d’être (”reason for being”), the one thing it must do very, very well.

If you just keep adding requirements and feature requests from every stakeholder, you just might end up with a product like this!

What do you think - do you agree with our thoughts, or did we miss something?! Let us know your comments.