3 principles for accelerating the product development process
In a previous article I argued that establishing strong governance around innovation is the first step to help accelerate product development. Once strong governance is in place, executives should evaluate their existing product development process and establish common principles across the organization.
In most well-established companies the understanding and application of the product development process is blurry and uneven across the organization. This leads to misunderstandings between different departments and political finger-pointing when preset expectations are not met, resulting in a dramatic reduction in speed-to-market and innovativeness of offerings.
These organizations have a lot to learn from the lean startup movement, a methodology conceptualized by Eric Ries in his inspiring book from 2011. At the same time it is important to remember that large complex organizations are not – and never will be – startup organizations, no matter how hard they try. Instead these type of companies should attempt to distill some few critical and simple principles for their product development process, and disseminate them across the organization. What these critical principles might be depends on the specific situation of a given company, but most companies can gain in terms of innovation and speed-to-market by revolving their product development process around these three governing principles in some form or another:
1. An inherent customer-focus. How to create customer value should be at the center focus of development from the beginning, no matter whether the project customer is internal or external. If not, the problem that the project is intending to solve may not be of much relevance for the customer. Customer-defined value creation is the first principle in lean thinking and has become so pervasive that it is almost a cliché to mention it, but nevertheless it is a point that often gets forgotten along the way in product development.
A common misconception about being customer-focused is that it necessarily entails that organizations should ask their customers for which specific features they would like to see in a final product – this is not at all the case. Instead, the principle promotes the thinking that everything that gets developed should start with the customer experience in mind. Steve Jobs is a famous example of a customer-focus development proponent and an “ask-your-customers-what-they-want’ opponent. He said that “people don't know what they want until you show it to them” – but he also said "You’ve got to start with the customer experience and work backwards to the technology". This means that companies should watch how customers use the products through prototypes and pilots.
A great example of a FS company which was solving the wrong problems for its customers is the Royal Bank of Scotland. When the bank started to digitize in the late 90s it had assumed that its customers valued convenience over everything else, and therefore developed its offerings around this, extending opening hours, increasing the number of bank branches, etc. However, studying its customers more deeply revealed that more ‘soft’ personal factors such as feeling genuinely cared about and recognized as individuals was valued much higher than convenience. This insight led to a dramatic reconceptualization of its offerings towards a more systematic management of its customer interactions and a de-emphasis on costly initiatives to increase convenience, resulting in a much improved top- and bottom-line (see Golati & Oldroyd – The Quest for Customer focus, Harvard Business Review for more about the RBC case).
2. An iterative approach to product development. Most traditional companies have a very little tolerance for failure and as mentioned before, projects which do not end up in immediate success are often used politically within the organization to promote certain agendas and careers. Risk-averseness is understandable in an environment where failure can mean the loss of billions or even bankruptcy, but in product development this approach is futile: If there is no tolerance for failure and if those employees who take calculated risks end up risking their careers as well, then the ideas put forward in these organizations will often be very incremental and ‘me-too’-like. Instead, a more iterative approach should be adopted where project teams are allowed to get wiser as a project moves along.
3. A common understanding of the development process across the organization. An overall common understanding of the product development approach should be established across the organization. This does not mean that all departments should follow the same exact process – it is and always will be very different to run a high-risk innovative research project which may or may not not end up in a product offering, and then a more operational project with a focus to meet new compliance standards in certain product groups. Still, employees should have the same frame of reference in order to ensure that different departments work in the same direction, and at a rapid pace.
The development process in financial services is often very well documented in the IT organization, but unfortunately not so much elsewhere. Different departments often have very different methodologies if any, and this leads to a very uneven development process across the organization with no real opportunities for enjoying synergies. While it is not a bad thing that IT has documented a process approach, it is problematic if they have a monopoly on the methodologies in the organization. The IT development process documentation is often very complex and accompanied by numerous documentation requirements which are not relevant in other contexts. Therefore organizations should establish a common overall framework with a high level of flexibility and repeatability, giving different departments the opportunity to adjust and detail as they deem necessary.
Product development today is unfortunately a highly manual process in many companies, giving rise to cross-organization misunderstandings and a significant reduction in speed-to-market. Executives therefore need to think hard about how to make the process more consistent, repeteable and streamlined if they are to face the challenges ahead.
