People keep confusing agile with product development but they are different concepts. It’s important to make this distinction because it actually matters. It isn’t just semantics, the confusion is causing us all problems. Understanding this difference may fundamentally change the approach most organisations take to building digital products.
This post explains why the distinction matters, then clearly defines product development and agile as different concepts. Finally, some thoughts are put forward on what you can do if your organisation is confusing the concepts.
Why the distinction matters
Thanks to the roaring success of tech companies over the last two decades, people look to tech folks as the beacons of how to create massive value with technology. People’s faith is not misplaced, it’s spot on. However, the “tech” part of tech has led to non-tech industries focusing on the tech aspect without realising that the success of tech companies has primarily been driven by their approach to product development (of which excellent engineering is a component).
Organisations that have looked to technology teams in product development initiatives means these organisations are being led from the inside out, rather than the outside in.
It’s not the fault of technologists and software engineers either. The technology folks are usually battling to get their organisations to realise the value of approaching their digital products as product development initiatives. The technology folks I speak with feel hamstrung because they’re being asked to do “digital products” but don’t get the broader organisational change required to move beyond agile and do product development.
There is a lot of spotify agile model being applied, and story points burned down all because that’s what tech teams within successful tech companies do. There isn’t recognition that it’s just part of the product development puzzle.
It’s okay though, we’re all stepping in the right direction. To uplift, the first step is to reach an understanding on the difference between agile and product development.
What is product development?
New product development is described broadly as the transformation of a market opportunity into a product available for sale (Source: Oxford’s ‘A dictionary of business and management’ and NPD on Wikipedia).
What is agile?
From the first line of the Agile Manifesto – the original document behind the agile movement – “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Emphasis mine.
Agile transformation folks will argue that agile can be applied more broadly beyond software. Maybe it can, maybe it can’t. For the purpose of this discussion it’s not so relevant. You’ll see why in a moment.
A minor clarifying point: “Agile” and “agile development” are often used interchangeably so they’re thought of as somewhat interchangeable for our purposes here because it doesn’t seem to materially impact the argument being put forward.
What’s the difference between product development and agile development?
Agile is specifically a methodology and/or philosophy for delivering and developing software. Product development is concerned with a much broader context of taking advantage of a market opportunity. Agile is just one methodology that you may use to conduct one or more parts of product development.
Let’s look at the word “development” itself to further pick apart the definitions and differences. Development is the process of developing or being developed; an event constituting a new stage in a changing situation. Develop is to grow or cause to grow and become more mature.
In agile development you are concerned with development in the sense of software development. Writing code, understanding requirements and deploying features. Making software more mature.
In product development the word development is focused on reaching new stages of a market opportunity through growing and maturing a product. This may not involve any software. Software is just one component. Granted, for a software product it may be a major component but it is still just one component.
What can you do about it?
Now that you can see the difference, what can you do about it? How can you use this information to help yourself, your teammates and your organisation?
The starting point is being aware that there is a difference. The next step is getting the rest of your company to recognise there is a difference. This in itself in many companies is no easy feat.
Beyond that, I’ll cover the next steps another day.