Assuring ‘Voice of the Customer’ in Development and Design

By Cathy Mabe, Carolyn M. Newell September 06, 2007

Most software development methodologies and best practices stress the importance of ensuring that the customer vision and expectation for how the product will function is reflected in the implementation. Indeed, many methodologies claim that a product company will either “make it or break it” depending on how well they deliver on perceived market trends.

Product companies that successfully anticipate customer needs ahead of clear customer demand are rewarded with short sales cycles and the brand loyalty that comes when customers perceive that a company “gets it”.

The term most often used by product companies to describe the customer’s point of view is “Voice of the Customer”, or VOC. Product management groups frequently employ VOC viewpoints to determine product direction during requirements development. But the VOC viewpoint is usually not part of the rest of the development lifecycle, and designers, developers, and customer facing groups who actually provide the end product to the customer are not as VOC-aware.

How does a business ensure market-driven VOC is understood by groups outside of product management?

How can a company intentionally deliver a Voice of the Customer product into the marketplace?

This article will address:

  • VOC accountability across the product development lifecycle
  • VOC accountability directly to the customer or market
  • Collaboration and traceability best practices

Begin with the End in Mind

Vendor-customer collaboration during the requirements gathering process allows the customer to give input based on their business needs and helps to keep Product Management attuned to the emerging market trends. It also gives the customer a sense of ownership and will provide everyone with a greater understanding of what the project encompasses.

Many corporate customers now stress mapping and traceability deliverables as part of the sign-off process for approving a customized software product. These deliverables are intended to make it easy for business users to see how their needs are translated into requirements and then translated from requirements to design. To maintain a connectedness with customer throughout the product lifecycle, we can take a tip from our friends in contract negotiations – interim milestones. Interim milestones will allow product managers to work with the customer stakeholders to continually validate what they thought they heard – i.e., the customer’s voice - against what was actually put into the requirements.

Think of it as a “taste test”. When soft drink companies want to differentiate themselves by making product changes, blind taste tests represent interim milestones in their product lifecycle. In conducting these tests, consumers are offered several versions of the product (soft drink). The consumers will tell testers what they think is good or bad about the soft drinks they’ve tasted, how it makes them feel, or even what they think would make the product better. The intent is for each iteration to produce a product that appeals to a broader range of customers and with higher customer quality ratings than the previous iteration.

Interim development and delivery milestones for validating the VOC will work to improve quality and eliminate delivery risk.

Initial requirements gathering sessions should include:

  • Customer focus groups – listen and understand customer process and needs without focus on technical solutions.
  • Requirement workshops – includes subject matter experts on existing systems to understand current functionality.
  • Requirement overviews – presentations providing an overview of the requirements you’ve gathered and the functionality the solution plans to provide; the benefit is additional time with the customer to get feedback and to let them know their needs are understood.

Later we’ll explain how formalized traceability of the items gathered direct from the customer to your requirements and designs can be a huge benefit. Customers will have higher confidence that they have been heard when they can see in their own words how they’ve impacted the software.

Dig Dirt from the Trenches

Another good way to gather requirements is to collaborate with sales teams. There is a chance that feedback from the customer is altered when money or a contract are involved. Sales teams have the benefit of seeing both the good and the bad. A sales person focused on meeting commission and sales quotas will ardently offer feedback as a way to ensure that the products they are selling will be bought. If the relationship of sales and product management is strong enough, the sales group can provide features for future releases to jump start roadmap planning.

If a working list of customer needs cannot be obtained directly from the customer, product managers can leverage sales to provide RFI’s, RFP’s,report backs, as well as market and trend analysis from investors or a customer’s own quarterly and annual earnings release.

Interaction with sales should include:

  • Requirement workshops – use sales and marketing to gauge customer needs and expectations prior to focus groups and other customer requirement workshops.

  • Requirement overviews – presentations providing an overview of the functionality to be provided.

  • Customer needs – formal and informal turnover of customer needs via RFI’s and RFP’s; invitation of product management on sales demonstrations and other customer meetings.
Develop an Iron Clad Case

Rally support for requirements from designers through repeated collaboration overviews where the voice of the customer is the primary topic. Avoid going directly to requirement details by providing development the same high level requirement workshops that were delivered to customers and sales. When they understand the big picture of the project then begin iterative collaboration on requirement details, always referring back to primary customer or market driver.

Collaboration with development on their design is prime opportunity to further validate requirements and gain perspective on the feasibility of a solution. If designers cannot understand the customer need or cannot agree with product management on the end solution it may be time to go back to the drawing board.

Collaboration processes with development should involve:

  • Requirements and architectural workshops – use to refine requirements and understand architectural impacts.
  • Requirement reviews – a formal review of requirements with the goal of approval of requirements.
    • Lead designers and testers should be collaboratively involved in requirement reviews so that product managers can validate understanding of the VOC into the development point of the SDLC.
    • Requirement sign-off by the development organization should be focused on whether or not the development group is confident that the requirements as stated are understood and to the best of their technical knowledge – complete.
    • Designers and testers should agree with the product manager that the requirements are attainable.
    • Mechanisms such as budget and estimation will determine whether requirements are actually feasible and should be controlled outside of requirement sign-off.
  • High Level Design (HLD) reviews – a formal review of the design resulting from the written requirements. Note: HLD reviews may continue even after sign-off in the case of design and integration changes.
Collaborate with Peers

If you work in a company with multiple products or product managers it is essential that you also collaborate with them. The purpose of peer-to-peer review is twofold; it eliminates gaps and drives out duplicity, and ensures that all product management deliverables are uniform with the same technical detail and caliber. The latter is a value that can enhance relations with customers and development.

Keep in mind the goal of working with your peers and develop ground rules to guide the process:

  • Feedback should be open and collaborative with guidelines provided to teams on how to phrase suggestions to their peers.

  • Unless meaning is lost due to grammar, spelling, and other punctuation mistakes; peer-to-peer feedback should be limited to only the technical aspect of the requirements.

  • Reviews should be started at the beginning of requirements development and formalized as a gate to collaboration with development groups or prior to customer deliverables.
Communicating to all Groups

Standardize VOC by creating real world examples or scenarios of the business need being addressed. These scenarios should be targeted to the most common business user (a CSR over the phone) with services, steps, and interactions as close to the user’s reality as possible.

The beauty of a standard set of scenarios is that it can be reused. As customer and market needs change, enhancements can be made to scenarios. Scenarios can then be a common language spoken by the customer, product management, developers, implementation, and sales teams.

A common language or platform for dialogue and collaboration can be its own type of traceability: what is an ‘XYZ’ to the customer is an ‘XYZ’ to the product manager is an ‘XYZ’ to the developer and an ‘XYZ’ to the sales and deployment teams.

Scenario development and term selection should be done as early in the lifecycle as possible.

How to Achieve VOC Traceability

The first step in being able to trace how the voice of the customer has impacted design is to first identify where the input originated. Requirements management involves tracking requirements of multiple types including:

  • NEEDS – Customer and focus group feedback, market and competitive analysis.

  • RELEASE – Releases are for roadmap planning but should always have an overall focus or goal driving introduction to a customer or market.

  • FEATURES – High level consolidations of functional enhancements that will aid in release planning. These can be derived from NEEDS or may be created on-the-fly as a result of release planning.

  • REQUIREMENTS – Business or system level details derived from FEATURES to aid design.

  • DESIGN – Use cases, architecture models, high level designs derived from REQUIREMENTS to aid development.

  • TEST – Test scenarios or test cases derived from REQUIREMENTS that are validated by development.

Defining a hierarchical relationship among these entities will help you develop a process for requirements management and choose a tool for aid. There are many good tools out there such as basic homegrown Access or Excel systems. Telelogic, IBM-Rational, and Ryma Technologies also have very robust systems.

AssuringVoice1

The latter part of the traceability process involves backward traceability of design deliverables to requirements. This is typically a process completed by the development groups and should be validated with product management. Using traceability to design can drive out missing or incomplete items and should speed up sign-off. Additional steps should also be taken to scrutinize design elements that are not traced back to a requirement; this could be an indicator of scope creep.

Tracing requirements to test documents will be the final internal quality check for product management. It is generally cheaper to find missing items by this stage then when into full testing and production.

AssuringVoice2

Benefits

Organizations that leverage VOC gain from better partnership with their clients. Their sales teams are aware of upcoming enhancements in order to be more efficient at bringing in new revenue. The acceptance and understanding fostered across departments leads to more productive collaboration.

Furthermore, product designs will be resilient enough to withstand a roadmap shake-up. Through diligent traceability, features and designs can be moved easily without creating a gap. The expectation is that fewer defects will be found in the code, leading to shorter testing cycles.

Few companies are able to follow the Voice of the Customer all way through to the end product. That kind of market credibility is an asset at any bargaining table.

Cathy Mabe

Cathy Mabe

Cathy Mabe is an experienced business analyst professional with Amdocs; skilled in collaboratively working with internal and external customers to provide detailed business functional requirements. Cathy has over 13 years of experience in custom software application analysis and creation for the cable and satellite industry with a concentration in design and development of the call center desktop.

Carolyn M. Newell

Carolyn M. Newell

Carolyn M. Newell is a product management expert with 7 years experience in system analysis of customer care and billing software. Carolyn is a requirements management and methodology leader for Amdocs; including product lifecycle traceability process and procedures leveraging various requirement management tools

Looking for the latest in product management news, articles, webinars, podcasts and more?