Product Development Process

Scott Smith

1. Introduction

This document outlines a Product Development Process (PDP) for bringing software products to market.

The ultimate goal of the PDP is not to bring a product to market. The goal is to bring the right product to market. The right product can be defined as one that solves customer problems in a way that also meets corporate business objectives.

Specifically, the ultimate product goals of the PDP are to insure:

The product has the right features & architecture

The product is targeted to the right customers/industries

The product has the right level of quality

Sales knows how to sell it

We know who we will be competing with

That technical support knows how to support it

There is a customer training program

That the product meets the expectations of the customer

That marketing knows the features and benefits

That the product is priced right

The product will be profitable

The product meets corporate business goals

2. Using the PDP

The PDP has a set of well-defined product goals that will ultimately bring the right product to market. It should be remembered that the PDP is a process. And by having a process we want to make life easier for everybody concerned. So in addition to the product goals of the PDP above, we also need to understand what having a process can do for us. These process goals include:

To facilitate communication by clearly outlining each functional group’s delivery responsibility

Speed up the definition and delivery of product by using common sense

Remove dependencies between groups

Foster teamwork by improving communication

It is most important that while implementing the PDP that these process goals be kept in mind. The PDP is a process that should be used in direct proportion to the development product being proposed. A major release, involving many developers and long delivery times should be given as much consideration as possible. A minor point release needs only abbreviated information. Put another way, not all documents need to be produced or all questions answered.

3. Terms

To facilitate communications the following terms are defined:

FCS = First Customer Ship.

Date the product ships to customers

Release Date

Master is done. Ready to be duplicated. Release sign-off complete

Pre-release

Not complete product release that can be shipped and booked as revenue. Limited shipment. Limited quality. Used to give a company early access to code. This release should not to be used for production. Is supported. Sometimes called SDK release.

Beta

Features: Goal is to have all of the features but some features may not be included in the Beta release. Changes to feature functionality between FCS and beta release can be made. Sometimes not compatible with FCS release.

Quality: Will contain critical bugs. Still under testing.

May be released in multiple beta reversions. (Beta I, Beta II)

Alpha

Core modules may not be complete. Screens without functionality. Quality low. Development not complete. May melt your PC. Will be used by select technical consultants in Sales Calls. Will be presented to customers for feedback. Alpha product will be the basis of final product.

Prototype

Throw-away version of product for evaluating technology, concepts. Has some working functionality.

Demo

A sales presentation using the product as a base. In some cases this might be a separate product that will need planning, sign-off budget, and support similar to a regular product

Proof of Concept

Example of the product. Not functioning, like screen mock-ups

4. Document Flow

The Product Development Process (PDP) is a process to insure that the product is well defined. Output from this process consists of documents created in the execution of the process as well as the product itself.

The major documents of the PDP include:

Opportunity Document

Marketing Requirements Document

Marketing Plan

Product Roadmap

Functional Requirements

Technical Functional Specification

Product Release Plan

Product Release sign-off

Opportunity Document

Not owned.

This not a formal document, rather, it is a natural step in any product’s development where an idea is expressed that says we have a potential product. This could be in any form from a prototype to an idea scribbled on a napkin. What is important is that the idea is tested, internally or externally to judge if the idea has merit before more formal resources are deployed.

Marketing Requirements Document

Owned by Product Marketing.

One aspect of this is to insure Corporate has a strong understanding of the target customer along with the market opportunity they represent. In addition, The PDP should help identify if Corporate has the ability to successfully build the product within the opportunity window.

Specifically, the PDP should identify the Market opportunity. That is, in what space will the product play?

In detail, the questions that need to be addressed in defining the market opportunity include:

Define the overall market

Define target market segments

Who are the target companies/industries

Who are the target users

Who are the target buyers

What problems does the customer have we are trying to solve

How does solving these problems benefit the customer (ROI)

Who are the customer-partner representatives?

Who are the technology-partner representatives?

Functional Requirements

Owned by Product Management.

The MRD scopes the overall objective of the product. These questions make up the first part of the Marketing Requirement Document (MRD) should address. Once we have a clear understanding of what the market is, customer problems and how solving customer problems benefit the customer, the remaining part of the MRD needs to address what makes up the product to be built and sold.

In defining the product the following questions need to be addressed:

What is the specific problem-set the product should solve?

How does the Product solve the customer’s problems?

How should the product operate in the customer’s environment?

How does the workings of the product solve customer’s problems?

What is the road map / Phases for developing the product?

How should the product function?

We need to clearly define terms here. Functional Requirements Vs functionality or features. The functional requirements should define what is required: For example, how a user might make a request or what needs to be on a card when it is initialized. How the specific implementation is engineered or architected is left for the technical functional specification.

Marketing Plan

Owned by Product Marketing.

What is the plan to market the product? Questions to be addressed include:

Who is the target user/buyer?

What are the main marketing messages?

What is our competitive advantage?

What are the features/function/benefits?

What is the product launch plan?

What is the media plan?

How will sales be supported/trained?

How will leads be generated?

Technical Functional Specification

Owned by Engineering.

The Functional Specification defines the scope of the product to be released. Issues that need to be addressed here include:

What are the features?

What is the process flow?

How is the product architected?

What technologies are used as part of the architecture?

User interface design

What 3^rd party products are parts of the product?

Performance/reliability targets.

Product Roadmap

Owned by Product Management.

This document outlines the future features and architecture of the product. It outlines the steps for each release and should cover a period of 2-3 years or 2-3 major releases.

Product Release Plan

Owned by Product Management.

What is the plan for releasing the product to market? Included here are details on product packaging, training plans, support plans, customer service and ordering procedures.

Product Release sign-off

Owned by Product Management.

This document contains the approval signatures of each related party stating they are ready to support their area of responsibility for supporting or selling the product.

5. Process

The goal of the PDP process is to insure that the above questions are answered and that the different functional groups within Corporate know what to expect in both timing and their involvement in the process. The flow of the process looks something like this:

1. Opportunity Assessment

2. Define the Product

Product Marketing: MRD

Product Management: Functional Specification

Engineering: Technical Functional Specification

3. Project Approval Meeting

4. Development

Documentation Plans, testing plans, development schedules, etc.

5. Alpha

6. Beta

7. Product release plan

8. Product release sign-off

For each documents or process steps the assumptions need to be tested. Targets for testing the assumptions include Customers, technology partners, sales, marketing, and engineering. Additional testing might be done with analysts, PSO, & technical support.

5.1. Fast-Track PDP

One problem with having a process is that it is easy to get bogged down by the process. Insisting that each step be completed before another process can start can delay the ultimate delivery of a product. This can be a problem with time to market is critical or when Engineering is sitting idle waiting for functional requirements. A linear process, though traditional, is not necessary in defining and building software products today. The Fast-track process that this document will propose will show how Marketing, Product Management and Engineering can work together concurrently in rapidly defining and building a software product.

Marketing, Product Management and Engineering usually have an informal understanding of target markets and product features. In most cases, this informal understand is usually the starting line for market research. In figure 1 this informal understanding is identified as the Opportunity Assessment. Opportunity Assessments can come in many forms from Prototypes to scribbles on napkins. In traditional product development processes, it is not until market research is complete, target markets defined, and customer problems identified that feature lists can be proposed. At all points in the process market validation needs to be performed. Each step can be very time consuming, because the next step is not started until the first is completed.

Figure 1

The traditional linear process continues all the way through product delivery (figure 2). Alpha products are released, customer feedback received and beta product released, tested, changed, etc. This continues until feedback says that a product is ready to be released.

Figure 2

The major problem with the linear process is time. Not the time it takes to do market research, or get customer feedback, but the time it takes to move paper between the participants. Also, idleness of other groups while waiting for previous steps to complete increases total elapsed time between project start and finish. For example, in the linear approach while marketing is doing research what is engineering doing? In the ideal world, engineering should be working on finishing the last release while marketing starts looking at the next. But things don’t normally work that way. Usually, Marketing is busy launching a product so many times engineering takes the lead building prototypes, or building products without understanding the market opportunity or customer needs.

So the Fast-track process recognizes that Market research needs to be performed and customer opportunities need to be identified. The difference is that the fast-track approach takes a non-linear approach to the process. In other words, market opportunities, customer issues, features and product architectures can all be developed concurrently. The goal of concurrent development is not to skip steps (All of the same questions asked in the linear process must also be answered in the fast-track process), the goal is to remove lag-times between steps and prevent idleness of dependent groups. How can this work when one step normally depends on a previous step’s input?

Fast-track explained

First, fast-track development is based upon 4 simple concepts that I will outline here and then go into more detail. The first is the 80-20 rule. That is, engineering and marketing usually has an 80% idea what the product should do, so each group can start independently. The second rule is to make changes in the plan and test the changes in multiple iterations. The third concept is to have a system that can facilitate the propagation of changes to the team and facilitate feedback. The last point is to have outside feedback directly input into the process. So let’s look into each of these points in more detail to see how the process works and each rule works together.

The 80-20 rule. Most of the time, it is possible to get the players involved (engineers, marketing, select customers and sales) into a room to get a general agreement on product features. This step, usually the only one for many companies in defining a product, can get the product features right about 80% of the time. This is because most members of this group have had some level of customer contact or relevant experience. This initial product feature agreement falls down because companies see this as the end-all step rather then the beginning. In the fast-track process, Each group has it’s 80% starting point, but then each group needs to complete the necessary work to verify assumptions and get the detail necessary to complete planning. Which leads to rule 2.

Rule 2 says that a plan needs to be verified, research in tested. Sometimes multiple times. As market research is conducted, as customers and partners give feedback to the plan, and as engineering looks into timelines and architecture changes are going to be made. What makes this process work is that each group refines their part of the plan and updates the others on progress. As each group sees the other’s updates their part of the plan can be changed accordingly. This iterative approach can continue until the objectives are reached. (Markets defined and final features identified).

Figure 3

What’s critical about the fast-track is that each functional group is updating its part of the plan concurrently. That is, Marketing is identifying opportunities while Product Management is building features and road maps and engineering is defining architecture and development schedules. What’s important is that as each group makes a change the other group sees that change and makes any necessary updates. To achieve this level of concurrency a software systems needs to be in place that communicate changes to team members. For example, if a functional specification is updated to reflect a new feature, the engineers working on that part of the functional specification must be notified that a change has been made so they can also make a change. (Software systems that can facilitate this are not covered in this document.)

Lastly, the concurrent process should involve customers and technology partners. The must have direct access to functional specifications, etc so that they can make comments on the plans. This feedback is then immediately communicated to all parties using software systems listed above.

With the fast-track process, it is no longer is it necessary for one group to wait for others to finish. For example: A product manager suggested new feature ‘A’. The feature is added to the Functional Specification. ‘A’ can then be analyzed by Marketing (Does ‘A’ meet our market objective?), Engineering can comment on ‘A’ (does it fit into the architecture) and customers can comment as well (is ‘A’ something that will solve a problem). Fast-track saves time. Also, errors are prevented because we get feedback up-front. Not having to wait until customers get the product in hand to make a comment. In addition, it is possible to take the alpha and beta cycles into the fast-track process. (Figure 4) This is accomplished by allowing customers and partners to have ready access to software builds which allows for immediate feedback and faster alpha/beta cycle times.

Figure 4

So in looking at fast-track development. It is possible to speed the delivery of changes to the team and facility feedback as well. Also it takes a realistic approach to how product definition really happens in a fast-paced software company. This will result in a better defined product, less chance of error, less miss-understandings more focused marketing and faster products to market.

6. Marketing Requirements Document Template

6.1. Introduction

6.2. Product Description

6.3. Market Research

6.3.1.Target Market

6.3.2.Target Companies and Industries

6.3.3.Target users/buyers

6.3.4.Customer Problem set

6.3.5.Competitive Advantage

6.3.6.Customer ROI analysis

6.4. Product Packaging/Pricing

6.4.1.Packaging

6.4.2.Price model/Licensing

6.4.3.Platform targets

6.4.4.Internationalization

6.4.5.Documentation needs

6.4.6.Export issues

6.5. P&L

7. Functional Requirements

7.1. Introduction

7.2. Product Description

7.3. Customer Problem-set to be Solved

7.4. Functional goals

7.4.1.Ease-of-Use

7.4.2.Installation

7.4.3.Work-flow

7.4.4.Functionality

7.4.5.Internationalization Issues

7.4.6.Export Issues

7.5. Performance and Reliability Requirements

7.6. 3^rd Party Integration Requirements

7.7. Documentation

(Owned by Product Management & Technical Communications)

7.7.1.Printed

7.7.2.On-line

7.7.3.Help System

7.7.4.Examples

7.7.5.Tutorials

7.8. Platforms Support

7.9. Schedules

8. Project Approval Meeting

The approval process for this project is:

1. Sales must commit to a revenue number

2. Marketing must present a business opportunity and P/L overview

3. Marketing must present an MRD with worldwide consideration

4. Engineering must present resource/cost estimates/functional specification

9. Product Release Sign-off

1. Has the final product been installed and functions used?

2. Has the physical packaging and order procedure been reviewed?

3. Who are the five customers that are ready to purchase this product? Do you understand why they are buying?

4. Did you review documentation?

5. Is pricing complete and communicated to sales?

6. Based on the beta feedback are you comfortable with the quality of the release?

7. Is Customer Support ready to take calls?

8. Are ordering procedures in place?

9. Is Operations ready to ship?

10. Is the related Web Site information ready?

11. Is the customer support related information ready?

12. It the product release plan complete?

13. Is the marketing plan complete?

Product Release Sign-off

Authorization to Ship

Product Name: FCS Date:

Authorized signatures

Product Manager: ___________________________ _________