Designing a Product Development Process

I find that the following product development process works quite well in most organizations for medium to large scale interactive projects (web, multimedia, etc).

It can be used for user centric interactive products, such as casual games, on-line tools, and brand building websites. I am a big believer that a development process should be customized according to each product’s needs in order to optimize the time to market, so the following process descriptions should be viewed as building blocks that you can shift, overlap, and exclude as necessary. With that, let’s begin!

Click here to download the PDF version: example_product_development_process

PHASES OVERVIEW

The diagram above is a high level overview of the process to take a product/project from initiation to completion. This process should be modified to fit the needs of each individual project. For example, not all projects will require all phases, and the duration of each phase and relation to one another on the timeline may differ depending on the project’s needs.

PHASE DESCRIPTIONS

RESEARCH, CONCEPTING, & SCOPING

A product owner/manager defines the goals for the project/product by initiating a Marketing Requirements Document (MRD). For new products and projects whose execution is not straightforward, a concepting step may be required to determine how the goals will be met. Once the goals and exceptional approach are clear, the product manager works with the User Experience (UX), Engineering, and QA managers to create a high level schedule. All of these elements are rolled into the MRD for stakeholder approval.

• The MRD should include the business case, creative/executional mandatories, high level schedule, and marketing plans
• Schedules will remain high level at this stage and will be refined as requirements are nailed down
• The product owner/manager may consider the following when defining the product/project goals: omniture data (site statistics) & customer feedback/insight, market conditions, and company objectives
• Many different tools may be used during the concepting step to help define the product’s execution including: brainstorms with subject matter experts, focus groups, sketches and/or look and feel explorations

Deliverables:

1. MRD – Product Owner/Manager
2. High Level Schedule – Product Owner/Manager, Director of UX, Director of Engineering, Director of QA

REQUIREMENTS DEFINITION & INFORMATION ARCHITECTURE

The product owner/manager collaborates with the engineering and UX directors to create a Product Requirements Document (PRD). For new products, the product manager will email the first draft of the PRD to the stakeholders for optional review & feedback within a specified time. The feedback will then be rolled into the PRD and handed off to the Director of UX to inform the Information Architecture (IA). Once the IA is complete, it is reviewed in tandem with the PRD at a stakeholder meeting.

• The PRD describes what the product does and how it works. It includes detailed feature descriptions, use cases, and standards (such as performance, SEO, tracking, and testing standards).
• The PRD should remain a working document in order to maintain its accuracy and relevance. This is particularly true during the IA phase, in which items in the PRD may need to be altered as they are visualized in wireframes.
• The IA illustrates the user experience and may include wireframes, flows, and site maps.

Deliverables:

1. PRD – Product Owner/Manager
2. IA (wireframes, site maps, and flows) – Director of UX

VISUAL DESIGN AND COPYWRITING

Under the guidance of the Director of UX (or Creative Director – depending on the company structure), a designer builds out the necessary screens and visual components and hands them off on a rolling basis to a production designer to prep for programming. Key pages should be designed and approved first. A copywriter feeds copy to the designer for all page elements, and delivers a copydeck to programming and QA for copy that does not appear in the designs (error copy, email copy, SEO text, etc).

• The PRD should continue to be updated throughout the remainder of the project to ensure its accuracy.
• The Director of User Experience may elect to conduct usability testing throughout this phase.

Deliverables:

1. Page Designs – Designer
2. Copydeck – Copywriter or Product Manager
3. Usability testing recommendations (optional) – Director of UX

PRODUCTION DESIGN (when applicable)
A separate production design resource may be required for large projects with many assets. The production designer will be responsible for cutting up and prepping images for programmers, sourcing imagery, and producing various assets (such as ad resizes or thumbnails).
ANIMATION/MOTION GRAPHICS AND SOUND DESIGN (when applicable)
Some projects may require animation and sound design. These tasks can begin after the core design and copywriting have been completed. A separate animation spec and sound effect list and voice over scripts are often required. The Director of UX or Creative Director is usually the point person for creating the necessary documentation and managing these resources and deliverables. This is a common step for flash based websites.

MARKETING PLANS FOR LAUNCH (when applicable)
The product manager collaborates with the marketing and business owner/s to determine the promotional plans for launch. If designs or copy are needed, these will be handled after the main product handoffs.

FRONT END PROGRAMMING

An HTML/JAVASCRIPT programmer will receive visual assets on a rolling basis and is responsible for implementing the front end of the application (alternatively, this could be a flash developer). As pages are implemented they should be spot checked by the director of UX to ensure adherence to spec and handed off to the backend developers on a rolling basis. Key pages and core functionality should be implemented first.

Deliverables:

1. HTML/AJAX – HTML Engineer

BACKEND PROGRAMMING

Once the PRD and IA is approved, the Director of Engineering creates a Technical Requirements Document, outlining how the engineering team will execute the features, noting dependencies (such as code that is shared with other site sections), and defining standards and code checklists. Once the Technical Requirements Document is approved by the VP of Engineering, it will be distributed to the engineering and QA teams. The Engineering team will use the Technical Requirements Document to refine their estimates and finalize the project schedule. Final milestone dates will be rolled into the weekly all project status report.

Once the Technical Requirements Document is complete, the Engineering team can begin implementing the supporting system and core functionality, working towards a review of core functionality (may or may not include final visual components). As the front-end assets are delivered on a rolling basis, the engineering team will implement the visual components, working towards a feature complete review. Once the functionality is approved/locked, the Eng Diirector will perform a code review to ensure code quality and completeness. The engineers will then work towards code complete and fulfill any remaining test entry requirements for Quality Assurance (QA).

Deliverables:

1. Technical Requirements Document – Director of Engineering
2. Alpha Build (core functionality) – Engineering team
3. Beta Build (feature complete) – Engineering team
4. QA Handoff build (code complete, test entry Requirements complete) – Engineering team

QUALITY ASSURANCE TESTING

Following the creation of the PRD, the Director of QA creates a test plan and sets up the bugbase for the project. Once the engineers reach code complete, the Director of Quality Assurance determines if the build meets test entry requirements. When approved, a dedicated QA team will complete full product sweeps and identify, prioritize, assign, and verify all bugs.

The Director of QA will arrange for a bug scrub to ensure all bugs are being addressed and evaluate the build’s readiness for launch. The product owner/manager will partner with the Director of QA to initiate a stakeholder review (Launch Approval) and act as the final say for launch.

• The Test Plans will include test cases and will guide the quality assurance testers throughout the QA process to ensure complete coverage
• Engineers will remain assigned to the project throughout the QA phase to address bugs
• QA may get a headstart on testing and familiarizing themselves with the product once engineers hit functionality complete (prior to meeting test entry requirements). This often reduces the overall duration of the official QA cycle.

Deliverables:

1. Test Plans – Director of Quality Assurance
2. Launch Plan – Director of Quality Assurance, Build Release Manager, Director of Engineering

POST-LAUNCH WRAP-UP
QA, Engineering and UX resources should remain assigned for a short period to test and address issues on the live site. If features were pushed for a later release, additional functionality/builds should be treated as a new project and consequently be weighed against other priorities in the product roadmap. Once the project is deemed “complete” resources will be assigned to new projects.

Following the project’s completion, the product owner/manager will be responsible for reporting if the product/project goals were met (using the MRD as the criteria for success).

Following project completion, the team may elect to conduct a post mortem meeting to acknowledge successes and identify areas of improvement for future projects. Findings should be documented and distributed to the entire product development team.