Requirements Gathering For New Product Development

Developing a new product is a daunting task. If the product happens to be new to the market or new to the world, then developing a new product is even more challenging. There are no fool proof methods. Having worked in Silicon Valley with startups & highly successful companies, I can give a few pointers towards successful new product development.
The first step in successful product development is requirements gathering. Requirements’ gathering is a complex task with various sub tasks and levels – which is usually accomplished through several iterations.
New products typically have their roots in an idea. The idea is then developed into a product concept (see: Innovation Management - Taking Ideas to Concept). Once a product concept is developed, the next stage is: Define the product requirements.

What is a New Product?
First let us define what is a new product? A new product in context to this article means “new to the world” type products – i.e., such a product is being introduced for the first time: First time for the company or first time to the market. Examples of such new products include:

• Google Chrome:- A new type of browser – and the first one for Google.
• SMART Car
• World Mate Mobile software
• iTunes:- iTunes was first of its kind in music store/distribution system.
• Motorola’s Iridium
• 3M’s Post It
• Blackberry Pager
• Cast Iron Integrated Appliances

New product Requirement Gathering

Requirements for a new-to-the-world product will always be vague. Therefore the best strategy is to capture the requirements – however vague they are in a document. New product requirement gathering starts with identifying needs of various stakeholders:

• Customers & Users
• Promoters
• Developers

1. Customer & Users

The need for a new product comes mainly due to the shortcomings in the existing products. As a result, current products in the market are unable to meet the customer needs. So the first step is to identify the customer needs. For a new-to-the-world product, we need to capture the perceived customer needs.

1.1 Perceived Customer needs

Identifying customer needs for a new product is often tough - In most cases, many customers are able to express their frustrations with the current products in the market & identify the shortcomings in the current products, but customers cannot express their needs for a new product. Therefore one must be prudent enough to derive the customer needs.

There is a well established method to capture the perceived needs of the customer – called as Product Opportunity Gap (POG) analysis. POG analysis can be used very effectively to discover the latent needs, the current shortcomings in the existing products and future needs of the customer. For more information on POG see: Product Management - Developing breakthrough products

For example, let us take an example of developing a personal video/MP3 player. The customer needs for a personal video player are:

1. Large screen size – but small enough to carry around in a pocket.
2. Battery life to last at least for 10-12 hours.
3. Removable battery for replacement
4. External battery charger & internal battery charger – i.e., user should be able to charge the battery while the battery is inside the device.
5. Universal power adaptor – should work on both 110V & 220 V systems.
6. Easy/intuitive user interface.
7. Ergonomic design for comfortable handling. Anti-Slip hand holding areas.
8. Splash proof & water resistance
9. Connect to PC via USB & WiFi, connect to TV via HDMI or S-video
10. USB host interface so that user can connect other data storage devices.
11. Ability to read data from other data storage devices ( Pen drives, portable hard drives, video cameras, etc.)
12. Connect to headsets via Bluetooth.
13. FM player, MPEG3, & MPEG4 decoder i.e., multi format audio/video decoder
14. Digital Video Recorder – ability to record TV programs.
15. Rugged construction so that the product does not get damaged when accidentally dropped.
16. Stylish design with interchangeable colored cases & Hip carrying case

These are some of the basic requirements for any type of personal video players. Data storage technologies can then become additional requirements can be used to create different types of products:

1. DVD player or Blue-Ray player
2. 100-300GB Hard drive to store movies, music & photos
3. 32GB or 64 GB, extendable up to 256 GB Flash memory via memory cards.

1.2 Intended Operating Environment

A product will operate in some operating environment. Often times, this operating environment is pre-existing and can be well defined. The intended operating environment must be well documented in the product requirement document – so that the developers should well understand and if required the operating environment can be reproduced in the development labs.

Understanding the user environment is crucial for the success of the new product. All persons involved in developing the new product should be able understand the user operating cases and use cases. This helps in developing products that meet the user requirements.

Operating environment factors include: Places (home, office, traveling etc); User conditions such as: Dusty environment, Hot weather, cold weather, high humidity etc; User knowledge or cultural bias etc.For example take the case of the personal video player. The operating conditions include:

1. Usage at home (bedrooms mostly), office & mostly while traveling – in cars, trains & flight
2. Should operate in extreme weather conditions from 40oC to -5 oC, should be able to operate in dusty, humid environment
3. Users may not be computer savvy
4. Users may not be very comfortable with English language
5. Power supply conditions may vary greatly – ability to work with dirty power.
6. Users are usually teenagers.

1.3 Customer Use cases

How does a customer use the product? What are the different uses for the product?

It is very important to document all the possible customer use cases, so that developers can understand how the product is being used. When a new product is being developed, it may not be possible to capture all the possible use cases – extra effort must be taken to document as many use cases as possible.

Users often times use the product in ways that was not originally intended by the manufacturer. But such use cases cannot be documented before the product is developed. This implies that use cases must be documented continuously even after the product has been released in the market.

2. Promoter’s requirement

When a new product is being developed, promoters play a major role in driving the product requirements. Promoters – aka investors or managers are the real brains behind the new product. Promoters provide the direction, vision and the business rationale for the new product. The common requirements which are typically driven by promoters are:

1. Technology Platform
2. Business models
3. Business use cases

2.1 Technology Platform

Promoters often decide on the technology platform – often times without consultation with the potential customers. This is often done on gut instincts. Many a times promoters have deep understanding of the market and that gives them the requisite knowledge to choose appropriate technology platform for the product.

What is technology platform?

The meaning of Technology platform varies widely with the industry – but it all refers to the foundation technology on which the product will be built on. For example: In case of software, it could imply the operating system (Windows, Unix, Linux etc.); In case of automobiles it could imply the engine technology (Diesel or gasoline or Natural Gas or electric or hybrid); In case of cell phones it could mean the operating standard (GSM or CDMA or 3G) etc.

Promoters are the best persons to decide on the broad framework of underlying technologies that will be used to develop the product.

2.2 Business Models

Every product or a service in the market has a business model in which the business sells the product/service. It is the promoter’s job to define the business model for the new product. The business model decisions include: manufacturing location/partners, distribution systems, pricing, margins, licensing etc.

Business models play an important role in defining the final product. The business model for a new product has to be determined before the product development starts – and refined over time. As the business models change, the product features/specifications also change. During this process, it is the role of the product manager to closely orchestrate the business model needs to the developers and the vice-versa.

Business models must then be translated into product requirements and these requirements should be orchestrated to the developers. Developers in turn can provide feed back to the promoters and help them fine tune the business models.

To understand this, take the case of iPod & iTunes. Apple built a business model around personal audio/video players, where users can manage music/video in their iPods by using iTunes store to download music via a local copy of iTunes on the computer. This complete business model was the key factor that ensured the success of iPod, while other MP3 players failed to build a sustaining business mode to support the product.

2.3 Business Use cases

Business use case is an extension of business models. In case of commercial/industrial products, the product will have a buyer, which is the firm, who is different from the user. The Business use cases include factors such as operating costs, total cost of economy, ease of maintenance, serviceability, customer support, release management etc

For example, Microsoft bundles its Office suite in many different ways – based on licensing. A basic license will consist only of Excel, Word, PowerPoint, & Outlook. While enterprise license will have lot more: Visio, MS FrontPage, MS project, MS Notes etc. This differential product bundling is an example of business use case. Similarly, GM & Ford offer their cars with different pricing and services bundle for car rental companies.

3. Developers Product

Developers are the engineers & technicians who actually develop the product. Developers can give valuable inputs to product requirements – mainly in terms of what is technically feasible and with inputs on how to make a particular feature better. The role of developers in requirement gathering can be broadly classified as:

1. Project constraints
2. Product improvements

3.1 Project Constraints

Every product development project has its set of constraints. These constraints in turn limit what is feasible – which in turn defines the final product. Developer’s inputs are very valuable in developing new products – mainly because new product ideas are often very lofty, which is very high in promise but not based on reality. The developers can then give the project a healthy dose of reality.

Promoters and customers often start out with a very high ambition and often demand a product so advanced that the current engineering technology would be able to deliver it. Therefore the product requirement must be toned down to match with the reality of today’s technologies.
The typical constraints that bound any product development projects are:

1. Resource constraints
2. Technology constraints
3. Time-cost-quality constraints

The project constraints limit what is feasible with the given set of resources. On one hand constraints act as a limiting function, but on the other hand constraints also act as impetuous for innovation. Developers are smart to figure out ways to go around the constraints and innovate. Product managers must encourage such innovative thinking to prompt developers to innovate while giving the constraints.

3.2 Product Improvements

Product Developers are typically engineers & technicians who have several years of experience in developing similar products. With experience, they would have learnt ways and means to improve on any product. So given a set of product requirements, they will certainly have ideas to improve the product in ways that was never thought before. These improvements will be small incremental ideas – which makes the product better or cheaper to manufacture or easier to use. It is therefore mandatory for the product manager to gather these ideas from the developers. (Also see: Ideas to Concept – Small Ideas are better)

Product improvement ideas/suggestions will be coming all through the development phase. It may be tempting to have all these ideas to be incorporated into the product design; however such a move will have an adverse impact on the project schedule. The best solution is to capture these product improvement ideas in the product requirement document before the start of the project, and ideas generated during product development must be viewed on its merit and project impact to decide if that idea can be incorporated into the current development version, or should it be deferred to the next version. To accomplish this, product management must start with a plan for the follow-on product to the first version – even when the first generation product is in development.

4. Form a feedback loop

New-to-the-world products do not always meet the customer requirements in the first release. The new product may meet some of the customer needs – but the solution will often have its fair share of short comings. It is therefore very prudent to plan for multiple revision of the product. A general rule of thumb is that a new product will take at least three versions before it becomes stable and widely accepted in the market. New Product development projects will have negative NPV during the initial few releases of the product and this must be factored into the product development financial planning.

So the best way to improve the product is to release the product into the market – for the target set of customers, take their feed back and then develop the next generation/version of the product. During this cycle, experience from the customers, promoters and developers must be captured as feed back to the product and convert it into product requirements and then incorporated into the next version of the product.

Once customers start using the product, it is very essential that customer experiences are observed and documented by promoters, developers & product management. Documenting the customer experience is a form of customer feedback – but it defers in the basic fact that the customer does not give the inputs, instead the customer is observed while he/she is using the product and that observations is documented. This practice is called Customer Anthropology.

Customer feedback, customer studies, promoter feedback, and developer feedback should all be channeled into a new product requirement document. This closed loop orchestration must be repeated several times to achieve mass customer acceptance.

Closing Thoughts

Developing new product requirements can be summarized in the following state diagram.

Product requirements initially start out as a vague set of ideas which needs to be filtered down in to a set of instructions that can be implemented by developers/technicians – to realize a product. New product development is an iterative process – where at the end of each iteration, a working product is produced. The product released at end of each iteration will not be perfect and will need further refinement & improvements which has to be done in the subsequent development cycles.

Promoters and developers must be aware that new product development will take at least three iterations to get to the targeted set of customers. Product managers and project managers must plan accordingly for multiple iterations – and see to it that the product is enhanced progressively through the iterations.