Rob Danby: Good morning Steve and thanks for joining me. Could you start us off by introducing yourself, including your role at Invetech and personal experience using agile for product development?
Steve Cocks: Good morning, Rob. I’ve been a program manager at Invetech for about 15 years, running a number of medium-throughput and Point of Care diagnostic instrument development programs. At Invetech, we’ve been using elements of the agile process to develop instruments for some time; however, over the last couple of years we’ve instituted a more formal process aimed at further integrating agile into our developments. A key component of this has been a greater focus on customer-centered design.
Rob: Can you describe the concept of customer-centered design as it applies to agile product development and why Invetech has embraced this as a central element?
Steve: The goal of customer-centered design is to ensure that we get the designers inside the head of the customer. By “customer” I mean all product stakeholders including members of the marketing department, the service department, assemblers on the production line, and of course the end users of the product. Essentially the “customers” are anyone who interacts with the product itself.
Our goal with customer-centered design is to ensure we apply any learnings and insights as early as possible in the development cycle so that the development team doesn’t spend time traveling in the wrong direction. Customer-centered design is therefore essential to getting fundamentals of the product correct.
Rob: How does this approach differ from traditional product development?
Steve: This approach differs to what we might have called in the past a “traditional” product development or “waterfall” approach, where the marketing department develops a high-level specification and then hands this across to the engineering department, who then might break down the specification into lower-level specifications before handing them to developers and designers, who then may write a lower-level specification. With this approach, the team actually doing the product development can be quite removed from the original design intent. Agile helps overcome these limitations.
Rob: What are some of the ways you gather customer insights and how are these used to inform the product development process?
Steve: What you might call “traditional inputs” are still used, such as the customer specifications, but the additional elements we add are things like visits to various workplaces to experience real-world workplace environments and situations. For example, on a current project we’ve been sending many of the designers to end-user laboratories where instruments are used. Our team has also gained insights into many aspects of our client’s business, from experiencing the help desk to attending service calls. They’ve also worked on the production lines to experience this environment firsthand. Again, this helps our development team really immerse themselves into the environment of the people who have to use, service, sell, support, and manufacture these instruments, and can lead to a deeper understanding of challenges faced, opportunities for innovation, and enhanced product design outcomes.
The other part of the process is to make sure that the information collected is communicated to the rest of the design team who don’t have the opportunity to make these visits. One method we use to distribute the information amongst the product developers is to create a range of information-rich posters. These are quite large posters visible to the entire team in the project development area, which we call the Obeya space, and document key features and performance goals of what will make the product a success. Obeya is a Japanese word which literally means “big room,” so we co-locate all product development functions there including designers and engineers, representatives from service, marketing, production, etc.
Finally, one additional way of helping the development team to gain insight into client needs is to bring competitor instruments into the Obeya space. This helps them to better understand what the competitive landscape is like.
Rob: Can you give me an example of some of the posters your team has developed as a result of the customer-centered process? What do they include, how are they used, and what is the value for the team, the clients, etc.?
Steve: A number of the posters have marketing specific goals, for example a list of all of the product features, including the top five product features that will matter most to end users. We also have posters that map how this instrument compares to competitor products, highlighting which of the features we need to be better at and the features in which we are prepared to call it a draw.
We also have other posters which highlight critical elements of the end users’ sites such as elements of the customer workflow as the customers use the diagnostics instruments.
Having these posters displayed in the Obeya workspace keeps them top of mind for the entire product development team throughout the duration of the project and ensures everyone is working toward the same end goal.
Rob: As an experienced program manager, what are some of the biggest changes or improvements you’ve experienced from using this approach for your product development programs?
Steve: If I take the experience from the project that I’m currently working on where these principles have been implemented, we find that the development team is far more connected to the project and its goals. All team members have a clear understanding of what the developers have produced and the communication has been flowing far more freely between the developers and the stakeholders. It is proving a very positive experience.
The other advantage that we’ve really noticed is that due to the visual nature of everything we’re doing—whether it’s putting up wall posters detailing product success goals, having competitive instruments, or constructing our own prototypes in the Obeya—is that any visitors who come into the Obeya workspace instantly get insights into development team goals and, perhaps more importantly, development team progress.
Rob: For other companies looking to adopt agile principles for product development, what advice would you offer to help them get started?
Steve: The first place to start is with the establishment of the Obeya space. Ideally, you want to create an Obeya space with all of your developer representatives and stakeholders in the one room. Ensure that key information you provide to the development is visual, whether it be posters or competitive instruments.
Furthermore, keep the visuals fresh. I’ve found that as you work through the project, the needs of the development team and the needs of your stakeholders will evolve. So don’t let the posters and the information there just become wallpaper. Make changes and refresh the content regularly. Keep it relevant to the team, and above all, if it’s not working for you, change it.
The other piece of advice I would give to companies looking to take on agile principles is to truly adopt customer-centered design. Get the development team out of the office and in front of your customers, your end users, your service department, and your production department. Get them inside the heads of your customers so that they can develop a product that is truly captures the needs of your stakeholders.