“What are some best practices when developing a new product?”
The first thing that comes to mind when answering this question is to make sure that you choose the right development process for the right type of product – and this should be explicitly stated as part of your strategy. There are two main types of development processes – Waterfall and Agile – and both are designed for very different applications. So, let’s talk about that a little bit.
A Waterfall development process is designed to take a set of requirements and develop them into a fully-featured final product. This process takes place via a series of decision gates; the most important of which is the presentation and approval of a business case that’s designed to obtain funding for the overall development project. This type of process is most appropriate for tangible products that are not necessarily released in releases, if you know what I mean.
If you got the reference, then you’re sure to understand what an Agile development process is typically used for. In this type of process, you take a set of requirements and develop them out through a series of design sprints. Each sprint results in a release of features that adds iteratively to the overall product functionality. This process dispenses with the decision gates and, quite often, the individual business cases, and instead focuses on speed to market, fast customer feedback, and iterative design. As you may have guessed, Agile is typically the development process of choice for software and service type products.
The key, of course, to the question at hand is to make sure that you choose the right type of process for the right type of product. But this isn’t always as easy as it may seem. Often times, product managers have no control over what type of development process their companies employ. What’s worse is that many companies will adopt one process or the other without any consideration for the type of product that they are actually developing. And if that seems like a stretch, consider the amount of resource, training, and flexibility that would be required to adopt two completely different development processes and deploy them both in a flexible way. It should come as no surprise that the investment required in this scenario might not always be welcomed with open arms.
So, the best practice is to choose your development process as part of your strategy, and to have the flexibility, expertise, resources, and – yes – money to match your development process to your product to your strategy.
When all of that lines up – you’ll be a lot closer to best-in-class. And when it doesn’t – you may just be like everybody else!
Listen to the podcast episode
Dear Strategy: Episode 030