Whitepaper: Integrating market research into the Agile Sprint Cycle
4 likes1,646 views
The document discusses the integration of market research within agile product development, highlighting the shift from traditional methods to agile approaches due to increasing demands for speed and adaptability. It examines the friction between product management and market research and proposes five characteristics of agile market research to better align with the needs of agile teams. Ultimately, it emphasizes the necessity for the research industry to evolve alongside changing market dynamics to remain relevant.
Whitepaper: Integrating market research into the Agile Sprint Cycle
- 1. Mozaic Group Integrating Market Research in an Agile Environment A Whitepaper Jacob Brown 11/1/2014
- 2. 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
- 3. 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
- 4. 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.
- 5. 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.
- 6. 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.
- 7. 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
- 8. 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.
- 9. 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
- 10. 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.