seed
“A fundamental misconception in product transformation is that everything must become a product.”
This point is essential, but can also be misleading. Here are two concrete examples of “not a product” needs turning into product needs:
- Compliance Projects – while one-time responsibilities are project in nature, assuring compliance data is accessible to those who handle compliance efforts is product opportunity. The alternative is heavily disruptive “quick questions” that come at the cost of team flow.
- Boundary Spanning Activities – No matter the term (WGs, SIGs, CoPs, CFTs), the practice of organizational knowledge sharing is not itself a product. That said, if any of those efforts are meant to produce meaningful output in the form of recommended practices, documentation, or governance, then they benefit from thinking through a product lens.
Team Topologies is incredible for debugging team dysfunction. In my experience focusing more on the challenges to flow vs the type of organizational problem is a better indicator of opportunity.
This is an entry in my digital garden. See what else is growing here.