“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:

1. 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.
2. 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.

Source: Project to Product Transitions: Challenges & Solutions Nobody Talks About — Team Topologies - Organizing for fast flow of value

Related:

• A Definition of Platform Product Management
• Platforms as Internal Products
• From Project to Product Management

[up:: Applying Team Topologies to Marketing and Community]