Product owners and innovation managers shouldn’t waste any more money on IT
Every month I meet numerous product owners, innovation managers or founders of tech start-ups to exchange tips and tricks. During these meetings we often discuss product development projects that get stuck, exceed their budgets or in some cases completely fail.
There are lots of different reasons why these product development projects don’t succeed. Varying from not having a budget for a 2.0 version (i.e., having spent too much too soon) to having a finished product that is so inflexible that very soon a completely new product is needed.
The familiar metaphor of a swing (see image above) is also often mentioned. And it always boils down to this: the determining factor in the unfavourable process leading to a failed project was a lack of communication and documentation.
"Three months after a very detailed briefing I received a product which I immediately had to have adjusted…"
As founder/developer of multiple start-ups, I’m only too aware that communication and documentation can be huge stumbling blocks in product development projects. I can safely say I had to pay dearly to learn to recognise these stumbling blocks. Nowadays I can look back and feel amused, but when I was in the thick of it, I felt really bad.
Although the process was extremely educational for me, this doesn’t mean that other people have to go through it too. On the contrary, take advantage of this heads-up because as a product owner or an innovation manager you will often find yourself being asked to set up a new product development project (at leastI hope so, for your sake 😉). Besides the fact that this type of project can be very challenging, it also carries risks in terms of the time and money invested.
How do you reduce this investment risk and ensure you don’t overextend your resources? There isn’t a single answer to this question, but you could start by postponing the start of the development process until you have the following aspects sorted:
1. Product roadmap
2. Product requirements document
3. Version release planning
Product roadmap – A multi-year product roadmap can give IT clarity about the product’s objectives. This enables them, at an early stage, to take into account things like scalability, transition to native, data model, development stack, compilation of the team, etc.
“Of course we intended to expand to other countries if our platform proved successful. So we were very unhappy to discover that we still needed to do a lot of additional work when the time came.”
Product requirements – Misinterpreting a function can be disastrous. However simple a function may be, adjusting it after the fact can have serious consequences for the development process. So make sure you compile a comprehensive set of requirements that both business and IT can operationalise. This will avoid discussions and additional development further down the line.
Version planning – There’s no such thing as launching a perfect product. If you launch an almost perfect product, that actually means you waited too long to launch. The phenomenon of ‘Release early, release often’ is a subject for an entire separate article. What you need to take away from this article is that everyone has to be up to speed on which functionalities are ‘must haves’ for the next version and which are ‘nice to haves’ which can be upgraded to ‘must haves’ in the subsequent version.
So, the lesson I learned was to not start by churning out code, but rather first and foremost to ensure that all stakeholders are completely in the know about the (future) product and the development process. Sure, in theory this process takes longer. And yes, we all want ‘results’ as quickly as possible.But in practice you’ll see that you save a huge amount of time and money and you’ll actually achieve a good product sooner.
If you’d like to take a closer look at how I have implemented this processor if you’re interested in getting some tips for your own development process, then get in touch at www.wegotyourstack.com.