Mozaic Group

Integrating Market Research in an Agile Environment A Whitepaper

Jacob Brown 11/1/2014

Integrating Market Research into an Agile Environment

For decades, Product Management and Market Research have worked together in a close and

comfortable relationship. Research provides the market information and insight, and Product

Management provides the muscle behind new product development and launch.

The graphic below provides a simple illustration of how Research and Product Management work

together on a typical new product development project.

Beginning around the turn of the Millennium, this tried and true model started to breakdown.

The first sign of friction was a relentless demand for faster research. Clients began to ask: “Can’t we do

it faster?” “Can’t we use the internet to speed it up?” “Why does the research take so long?” Both

Corporate Researchers and Research Providers resisted this push, concerned that it would result in “Bad

Research”.

Eventually the pressure from Product Management won out. Their demands fostered the development

of a wide range of excellent new research tools; such as webcam focus groups, online diaries, mobile

research, DIY survey tools, etc.

However, even with the adoption of faster and cheaper internet research technologies; the friction

between Product Management and Market Research has continued. And, it has slowly become clear

Assess market

Develop Concept

Concept Test

Revise

Concept

Estimate Demand

Finalize Concept

Test Messaging

Launch

that the disagreement isn’t really about how long it takes to recruit a focus group or program an online

survey. It’s about change.

The Traditional Product Development Model

It shouldn’t be a surprise that the traditional product development model is coming under pressure.

After all, the process was created more than fifty years ago – think Mad Men.

The traditional model was created to fit a business model based on:

Mass Markets for standardized products

Long periods between product updates

Huge capital investment requirements to fund production

Under this model, you only got one chance to launch a product. The rewards for getting it right were

huge, and the penalty for missing your mark was equally large.

Once, the product was accepted, all innovation stopped. In fact, meaningful innovation was

discouraged, lest you accidentally kill the golden goose. As an example, Frosted Flakes is sold in over

100,000 stores in the United States; yet it is essentially unchanged since it was introduced in 1951. 63

years with the identical product. The biggest innovations have been to the design of Tony the Tiger on

the box.

Is it reasonable to expect the process that gave us Frosted Flakes will work equally well to create a

disposable smartphone app?

Managing Innovation

While the old model favored standardized products for the masses; today the market rewards

innovation, personalization, and a continuous product evolution.

The iPhone launched the Smartphone industry and propelled Apple from a mid-sized technology

company to the most valuable company in the world. The iPhone was launched 7 years ago, and we’re

already on Version 6. Six major new product roll-outs in 7 years was an unthinkable pace of innovation

just a few years ago.

But, while yesterday’s market punished you for change, today’s consumer are accustomed to updates,

new versions, and improvements. In fact, they expect their products to evolve, and they welcome

useful and meaningful innovation.

To meet this demand for continuous change – the Product Development process had to open itself to

innovation. Enter Agile Product Management.

Out with the Waterfall in with the Scrum

The traditional product development process is often referred to as Waterfall. A term coined to

describe software development, but equally relevant for a wide range product development projects.

Under the waterfall method, all the innovation takes place up-front. Market Research and the Product

Management team work to investigate the market, uncover unmet needs, define target segments.

Then, all product stakeholders work together to agree to very specific product definition, and the teams

drive to create, produce, and market a product that exactly meets that specification. And, new ideas,

discoveries, or changes to the product definition are actively discouraged; because change disrupts the

process.

This explains how products that sounded great at the start of the process, often seem irrelevant by the

time they are launched. The market has changed – but the development process remained fixed on the

original product definition.

In contrast, many companies are moving toward some form of Agile Product Management. Agile

Product Management comes in many forms, Scrum, Kanban, XP, and others. For this article I’ll simply

use the term Agile or Scrum to describe the general approach.

Unlike the Waterfall method, Agile Product Management recognizes that you can’t know everything

before you even begin. Think of it like a 2 week trip from London to Rome. Waterfall is like a bus tour

where every minute of your day is already planned; and any deviation from the plan is seen as a

problem. Agile is like renting a car. You still have to be in Rome in 2 weeks, but you welcome each day’s

adventure.

At the beginning of each Sprint (typically 2 weeks), the team, known as a Scrum, sets specific

development objectives. These objectives are based on clearly defined “User Stories”. A User Story

illustrates a specific product feature/capability and reflects a specific user need.

Unlike the traditional development process where extensive work is done to create detailed product

specifications at the very beginning of the process – the Agile method is engaged in a continual cycle of

discovering and defining the product. It is a cycle of innovation driven through the ongoing collection of

customer input and feedback.

The Source of the Conflict

People often say that Agile has revolutionized the product development process. But I would posit that

the reverse is true. Agile didn’t change anything – Agile was created because the world has changed.

And, Agile has been adopted so quickly and widely because it answers a need: how can we develop

products that meet today’s ceaseless appetite for innovation.

But, while many Dev groups have gone Agile, the Market Research group is still caught in an

unrewarding loop of trying to make Waterfall faster. It’s easy to see how the information needs and

expectations of an Agile Product Group (with multiple teams, 2 week Sprints, and team members talking

directly to customers) would conflict with a Market Research group still following a traditional product

development roadmap.

As a result, the Product Group can begin to see Market Research as an impediment to innovation, rather

than a leader. And, the Market Research team may see an Agile group as unfocused, undisciplined, and

unable to stick to the script.

A Solution

The solution to this friction is for the Market Research team to find ways to adapt their research tools to

an Agile environment. Agile Research places a higher value on immediate and hands-on customer

interactions, and a lower value on traditional research methodology and rigor. Agile research stresses

being 85% right today vs. being 95% right 2 months from now. It isn’t “Bad Research”, but it is very

different.

In the end, Market Research will have to accept that the world has changed and that research must

adapt to reflect the new marketplace. The Product Group is the customer. And, if Research can’t meet

the needs of their customer, than the Product Group will find ways to go around them.

Research must embrace a new way of doing business. Below I have outlined what I see as the 5

Characteristics of Agile Market Research.

The 5 Characteristics of Agile Market Research

•Each research event is focused on a limited set of issues. So the sessions should be brief with a focsed set of questions. Remember, we’re just trying to answer the questions the team needs to resolve today.

1. Fewer questions

•Since the Sprints only last 2 or 3 weeks, we need to plan for lots of events so that we can be constantly updating the Scrum team with the information they need for their next Sprint Cycle.

2. Frequent events

•It's not enough to be quick, we must also be flexible. The research can’t be dependent on a typical 6 – 8 week research schedule.

3. Flexible scheduling

•We are not canvasing the world – looking under rocks for potential user groups. The research should focus on the Prime Target, the people we expect to be our core users. The most enabled, enthusiastic, and likely to adopt. If we can’t win these people over – what hope do we have in the broader market?

4. Focused target

•The Scrum Team needs to talk to customers directly. Research can either facilitate the DIY research, and help make sure it’s a fruitful or be perceived as a barrier to innovation.

5. Facilitate DIY Research

Research that matches the Sprint Cycle

The goal is to create a research structure that the Product Team will embrace rather than tolerate. And

the key is to create a flexible plan that can be synched with the team’s efforts. Each two week Sprint

Cycle has a clearly defined structure that looks something like this.

During each Sprint, the team (known as a Scrum) works through an agreed upon set of User Stories –

think of these as feature requirements. One way to integrate research within this cycle is to meet with

the product team during Story Time, a meeting (known in Sprint parlance as a Ceremony) during which

the team reviews the Product Backlog to see what User Stories are on the horizon. During this meeting

the Sprint Team and the Research Team can work together to identify specific topics or user stories that

require more learning to aid product development.

Research then uses the next 2 – 4 weeks (one or two cycles) to research these requirements and then

reports on them during Sprint Planning. In time for those User Stories to be added to the team’s next

Sprint Cycle. In this way, the research team is deeply integrated with the development team’s needs,

activities, and working on the same timeline.

Building an Agile Research Calendar

The following table outlines a quarterly research plan I created for a major consumer technology

company. It combines 3 different research strategies to create an integrated Agile research plan.

Foundation Research: A quarterly strategic research project – a multi-city focus group study that looks

at the strategic product issues – not focused on individual User stories. This is an Anchor Study and

looks very much like a traditional research project. There is still a vital role for this type of baseline

research initiative.

Sprint Research: These are short, fast, focused research events, centered on uncovering the information

needed to understand complex User Stories. For this product, mall interviews were conducted every

two weeks to answer specific question the product team needed to answer NOW.

DIY Research: The Product Team wants/needs to do customer interviews. We developed a process for

training the product team on doing in-home ethnographies. Then we scheduled the in-home research

and then let the Product Team take the lead.

Week Foundation Research

Sprint Research DIY Research

1 Sprint Research

2 DIY Research

3 Sprint Research

4 DIY Research

5 Sprint Research

6 Milestone Research

7 Sprint Research

8 DIY Research

9 Sprint Research

10 DIY Research

11 Sprint Research

12

Summary

The world has changed. What we market has changed. Products are now services – services have

become products. And the way we bring these “products” to market never seems to stop changing. So

it only makes sense that the way we use research to support the development of new products must

evolve. And, there is no going back.

It is not a question of the right way or the wrong way to do research. It is a question of the research

industry’s willingness to adapt to a new world. And, in truth, we must embrace the change. The choice

is simple; be willing to adapt, or risk becoming irrelevant.