What is an agile product strategy?
In a perfect world we would have a crystal-clear vision of what our end product needs to be. But that’s not what happens – the market changes as we develop. So an agile product strategy needs to be able to move with these changes. Some key elements of that include: 1) delivering the new product in progressive, incremental iterations; 2) structuring each iteration as a series of deliberate experiments to test what the market is looking for, and; 3) building rapid feedback loops into the process to channel that learning into the next design iteration. These structural changes and the underlying mindset shift help you stay on top of market evolution and adjust your approach rapidly, as needed.
Why would someone use an agile product strategy?
In my mind it’s embodied by that moment of intellectual honesty you sometimes get when you begin developing new products and realize that neither you nor the customer can know what the market truly wants when you first set off on the journey. It’s the spirit of Henry Ford’s famous quote “If I had built what customers asked me to I would have built a faster horse,” or Steve Jobs saying, “The customer is wrong.” The market doesn’t even know what it wants so how can developers have a clear sense of what that product needs to be to serve a nonexistent market? So if you can have that epiphany, it fundamentally changes the way you would go about designing a new product.
Is agile product strategy strictly applicable to software development, given agile’s original purpose?
Absolutely not. The Agile community traces its origins back to the Toyota new product development process in the same way the LPPD community does, so Agile principles attempt to describe a more universal truth than just software development. It’s true that Scrum, XP and other agile methodologies really come of age in a software environment, and because of that there is definitely some terminology more catered to software. However, that doesn’t mean the same thinking can’t be used in physicalproduct or service development. In fact, we see Scrum, in particular, being used increasingly in major industrial product and service contexts like the aerospace industry. There’s certainly value in establishing feedback loops in a physical product’s development cycle. The cadence may need to be longer to account for physical fabrication time, but with a little creativity that cadence is often much shorter than people think and they definitely get the benefits of updating their understanding of the product and the market needs.
How does an agile product strategy differ from what we think of as a “conventional” product strategy?
Good question. Well first I should say I don’t know of too many companies with a product strategy that is truly conventional anymore. But a conventional product strategy depends on the lead designer being overly-confident in their ability to predict the market. It would typically involve a bunch of marketing folks choosing a market sector that they haven’t tapped into yet, doing a huge amount of customer research up front to determine and document what they want to make, then ordering development of a product, crossing their fingers and hoping that the product is a hit. Market testing happens only at the end of the development process, and only then do you find out what the customer’s perception is. You might be able to make changes at that point, but for the most part you’re committed. And at any rate it’s extremely expensive to make any big, sweeping changes at the end of the cycle. This is the sort of isolated design process that leads to the Edsel. With agile product strategy, we are talking about a much more inclusive approach.
That’s a pretty convincing case for agile product strategy. In that sense, why don’t we see more companies using it in place of the conventional or semi-conventional strategies that are more common?
I think a number of modern companies do use elements of agile product development in bringing new products to market, such as occasionally asking for intermediate feedback, but they don’t think of it as an integrated approach. The problem with that is that, like most good strategy, there is a self-reinforcing internal consistency to a complete agile strategy that falls apart of you remove many of the key elements. So companies fail to achieve what they could with a more thoughtful and deliberate approach.
I think the key reason they don’t implement a full agile product development process is that it takes time and effort to explicitly state your product assumptions, develop and deploy tests of each of these assumptions, and continually update the product vision. It is much easier to use a “fire and forget” design approach, and as long as you don’t get badly burned you don’t know how much value you might have left on the table. What we do see is that once one competitor in an industry starts to use an agile product development approach, it typically only takes six months or so until we hear from their competitors looking for ways to keep up.
Are there any limitations to using an agile product strategy?
There certainly are. You can try to compress your product development cycle all you want but you will still occasionally need to make some big design bets on how to architect your new product. It is very expensive to come back and change these design choices. For example, you can’t build a skyscraper on the foundation of a two-story home by “evolving,” but you can move the walls around and change how individual rooms are used pretty easily. It is definitely worth taking the time at the beginning of the design process to identify and research these key foundational decisions.
The concepts addressed in this interview were originally published in the post Maxwell Health and Agile Healthcare Strategy, by Alex Brown.