The perils of good ideas and a trick PMs can use

It’s human nature to want to come up with solutions to problems we face. This is true in everyday life as well as in business. A parent of a child struggling in school might want a change in the way a subject is taught and a manager that is falling behind on revenues will want to come up with good ideas to accelerate growth. In business and especially in agile organizations this natural tendency of coming up with good ideas can however be very problematic.

The first problem is that good ideas are usually aimed at solving a business needs (which is ok) but often, little or no real user research has been done (not ok). For example, a VP is seeing that she is a risk of missing her yearly growth target. Since she meets a lot of customers she has formed some ideas on some features that the product is missing. She books a meeting with a product manager and explains the situation and that team really need to prioritize the new feature so that the division can reach their growth targets. An idea is not a verified user need though and since the idea is not verified it is likely to contain a lot of false assumptions.

The second problem with good ideas is that they take time to implement and are disruptive to the product development process. To get good and constantly improving products, teams and PMs need to have the ability to plan out their development process. An “important request” coming from the sidelines can derail weeks of progress and worse create a culture where teams let go of their ownership of their product. For example: arranging exploratory interview with customers and solutions testing to verify hypotheses are critical activities that takes time to arrange. If a good idea comes in the middle of this process, a lot of the work that has been done risks getting lost.

The third problem with good ideas is that they don’t work. Almost no features work as intended on the first release and it is first after customer feedback and iterations that products usually become good. This is why product teams need to focus on outcomes and not outputs. After a features is launched the team should learn from how it is performing and over time get closer and closer to a solution that generates the intended outcome. However this is not a level of commitment the good ideas usually have. Instead of becoming a product, the good idea becomes a one-off that miss targets and adds to technical debt. 

So what can a PM do to avoid getting stuck doing good ideas? One way is to ask (and demand an answer for): “what happens when we launch this feature and it fails?”. New features usually fail so the question is legitimate and the answer can hopefully spark a good debate around current priorities and the challenges the manager is facing. Maybe the team is already on the verge of an insight that will positively affect revenues? Maybe the team actually do need to refocus, but if they do it’s likely not to implement the feature as it was conceived in the good idea.