As part of the work that Chris and I performed on the product management framework (ref the link), we tested it for fit against a series of different sources of insight. Interestingly, we found that the three branches of Business Outcomes, User Needs and Target Groups were sufficient for progressing to design concepts; the trick was identifying the order in which the disciplines are involved.
The table we came up with is shown below. While it might seem curious that, for example, an iPad starts with the business outcomes, we began here because it’s clear that Apple would have a very clear view of what they wish to achieve from a future product and would build their product to those KPIs. They have a clearly identified target segment for new products and subsequently focus on meeting that group’s needs. Note that leaving the User Needs until last does not imply that these are subservient to the remaining disciplines; rather that the met needs will be focussed toward driving the KPIs for the identified segment.
We do not show Technical Insight here. This was a recurring theme in the recent book “How Google Works”. However, a technical insight makes something possible that was previously not possible (or cost effective / adaptable). One must still meet the needs of a target group for a given outcome, even if the ultimate use is not apparent at the start of the process. Thus technical insights help us prioritise; however, we still create products that meet the needs of a segment of users, in line with our business goals.
Note that business analysis is the correct approach for Technical Improvements or Regulatory Compliance. These are the role of domain experts – the Complicated space in the Cynefin model – rather than the safe-to-fail experimentation of product management as befits the Complex space.
We’d love to know whether this tallies with your understanding of how insights can be used. And are there any missing cases?