Improving your product development and innovation odds

Product ideas should come from everywhere in the organisation. In my experience, a healthy product development function has ideas flowing from all directions – not just product managers, UX people or managers. You should seek out the noise, frustration and friction around your products, your competitors' products and the jobs your customers and prospects are trying to do. My "product radar" tells me to home in on the call centre or service desk, website analytics team, and salespeople to tap into existing problems and frustrations. However, the greater number of people who feel they can contribute their observations, the better.

When you have a flow of ideas, the next challenge is to clarify and validate them. The process of collating, translating and assessing tends to lie with a product manager or user experience person. Typically, they will turn the insight into an experience that can be developed by starting with a statement that captures the need, such as 'As a (role), I need to (do something) so that (outcome).'

The next step is to decide which insights to act on. I strongly advise against having a committee to review and select. You must make it an evidence-based process. The more you encourage people to test their ideas, the better your process and, ultimately, outcomes in terms of impact, ROI and commercial value. To do that, you need a sound business case for each problem selected for development.

Asking people what they want is a fundamentally flawed way to establish requirements. We humans have very unreliable recall. We often suggest what we think we (or others) want rather than what we really need. Observing needs and testing hypotheses to establish real needs and the value people will put on solving those problems is much more reliable. So, product managers must assess the value each option would deliver compared to the effort and/or complexity required to create it. With that data, we can decide whether to add it to the product backlog, considering commercial and competitive realities.

In my experience, the best way is to prototype. You could ask people what they want in more and more detail. However, there's nothing more powerful than putting something in the hands of users and seeing if they understand it and can use it. You get immediate, observable feedback. You can see if there's friction or disconnect. You can understand why people can or can't do the thing. It's quick and, importantly, can be done within the scope of a development sprint so the team can learn and refine.

If you're building what you think users want, the result is usually low ROI for new product developments. If evidence isn't at the heart of decision-making, opinions and ideas will drive the development pipeline. Without sound, tested hypotheses, toxicity tends to fill the void. Conflict and misunderstanding result from frustration, misdirected effort and products that aren't succeeding.

Validation almost always creates effective products. At the very least, it helps to prevent wasting time and resources creating ineffective products. It's effective because user testing is a journey. It should be a regular occurrence, keeping you, your team and your stakeholders informed and continuously learning. I think of it as having sensors installed in your development process that tell you when something has gone wrong. If a sensor is triggered, you can course correct.

Of course, the reality is that top-down and bottom-up can – and should – be part of the same process. The challenge is to be a sentient team that is self-aware and cross-functional. I believe this is the fundamental transformation organisations should seek - the ability to incorporate scientific method into the development process. Moving quickly and adapting as you go is not just at the heart of effective product development; it's good for culture and central to the effectiveness of your organisation.