It is very hard for product teams not to jump straight into implementation mode. At the end of the day, as product teams, we want to provide value and we care a lot about it.
A year ago, as part of the Integrations team, we have implemented of the most successful features. Simple (not easy), but very valuable to customers, that allows them to translate Nexthink data into actions on many third-party tools. Long story short, this feature would help customers to reduce costs by fixing issues faster, and as a consequence reducing two critical metrics MTTT (Mean Time To Troubleshoot) and MTTR (Mean Time To Resolve).
If would have been very easy to keep adding stuff based on the sounded feedback that customers provided about a missing capability. The question becomes, does the customer really want that feature?
After hearing the same thing over and over again, we told ourselves, “we must implement this thing”. It’s a no brainer. But this is where having a clear idea of the causal structures of the system and understanding demand, is critical for a product team. This implies understanding the real motivation behind the request - how progress would look like for them, in terms of outcomes and the context they were facing, and also what we can deliver in terms of what, how, and how much
After a reflection, we realised that they didn’t want the feature they were requesting, they wanted something more that casually was being developed by another product team. It was better prepared to address their needs, and do even more.
We could have fallen into the temptation of implementing the solution we initially thought, and I admit that it wouldn’t have done any damage just for:
The tech-debt we would have created.
The cost of operating / maintaining that feature.
The lack of engagement when the other team delivers the capability they were building.
The opportunity-cost of not working on another important things.
The false idea of progress. Believing we were delivering something useful, when we were not.
Conclusions
Before implementing any feature, make sure you understand the demand - what progress means for customers (outcomes and context) - and the causal structures - technology, operations, and business model.
Have a systemic view and avoid silo-mindset: just because you’re the one talking to customers, what they might need could be somewhere else in the product.
Be bold: we could have implemented just what customers are asking. Our team understood that the real progress by customer would have been made by providing some more complex. Our solution would have been a vitamin, not a pain-killer. The fact that our team exposes that, gave us some time to explore that and make sure the other team was sure to cover that particular use case.
Avoid escalation of commitment: don’t based your decision-making on the investment you have done in the past. Again, it was quite easy and it made a lot of sense for us to implement what customers were asking for, it was a quick win. However, when you analyse the expected value we could get, it was not worth it moving forward.