With all the well-publicized challenges inherent with project-based work, could there be greater benefit to operating in “product mode” by organizing ongoing business capability-focused teams around products and product lines? This is the subject of a fascinating article on MartinFowler.com by author and consultant Sriram Narayam (Agile IT Org Design) titled Products Over Projects.
For quite some time I’ve been suggesting to clients to consider organizing by product, so I’m delighted to see the concept so well articulated and thought out.
Problems with Managing by Project
As Narayam points out, with projects, an initiative is funded, a team is formed, and the outcome is delivered. Then a new project is assigned, and in all probability a new mix of players that have to go through the whole “forming/storming/norming/performing/adjourning” cycle all over again. And forget about ideation, that’s a whole separate process done by “other folks.” Prioritization also generally happens external to the project. Lastly, the rest of the product lifecycle, including benefits realization, is disconnected.
With a narrow focus on the scope of the project, you run the risk of getting exactly what you asked for (if you’re lucky) but not what you need.
What is Product-Mode and What Kind of Environments is it Applicable To?
In an organization that operates in “product mode,” the flow from ideation to build to run is much more holistic. A team is funded based on the needs of the product category, product line, or strategy that they’re meant to foster and nurture. The team generates ideas and prioritizes work. The team leads the delivery. The team owns the benefits realization, and is measured by meaningful KPIs, not just whether they delivered to a set of requirements.
Equally important, the team sticks together beyond the lifecycle of a single project or initiative. They build knowledge and gain rapport, remaining at peak performance throughout. While the article focuses on this approach in the IT sector and the digital realm (beyond just software development), I would add that this concept is broadly applicable and increasingly employed in R&D, Professional Services, NPD organizations, and more.
Why not create programs around your product categories, products, or product lines and have the teams responsible for the prioritization, development, and nurturing of their area? It’s a much more integrated approach.
Narayam uses a case study about the development of a Retirement Calculator as an example. A financial services company needed the calculator in order to steer prospects toward buying retirement products or improving their plan contributions. A project team was assigned to develop the calculator and then… well, that was it for their role. A product-based team would have instead been focused on solving the problem of increasing sales and plan contributions, of which a calculator may have been part of.
Impact on Resource Planning
Most articles that talk about agile and product-based approaches ignore the ever crucial resource planning aspect. Fortunately, this article doesn’t, and specifically cites the staffing utilization challenges, which differ somewhat from that of project-based environments.
For instance, team sizes need to be periodically reviewed to adapt to changing business needs. Areas with light roadmaps may need to be combined with others. As for prioritization, a central component of resource planning, cross-team “initiative” priorities must still be set centrally, with team-specific “roadmap” priorities managed by the team.
From a cross-team utilization perspective, the article notes that some team members may take on multiple roles if they have bandwidth. However, Narayam wisely cautions against optimizing solely for utilization, implying that optimizing for speed of delivery and value is more beneficial in the long run. He also offers suggestions for employing different types of teams, and even having hybrid core/flex teams, augmenting core teams where appropriate with additional resources.
All in all, Narayam makes sound points in illustrating a refreshing approach to work that is built to foster an increased value focus, reduced time to market, and greater benefits realization. I think the article is an absolute must-read for anyone pursuing greater business agility and value-focused work methods.
