I frequently encounter debates about Projects (and estimates)
Project Team vs. Product Team
John Cutler

Here’s a thought I’ve been carrying around in my renegade, skunkworks “Innovation Labs” (read: startup product mindset) as part of a enterprise services, IT-driven company.

My evolving theory on Project vs. Product is focus: the former is risk-mitigative whereas the latter is risk-accepting. The former presumes scope is locked (often predefined top-down), the latter defines scope based on hypothesis testing (and is empowered to pivot as needed). As a result, Project teams often become very waterfall based, despite the Agile dev methodology they allegedly employ because they lack the aspect of user/market-based feedback and discovery cycle. Product is inherently an ongoing hypothesis exercise of a thesis through product development.

I’ve personally seen Project teams employed for Professional Services, where the team aims to configure and implement (perhaps even pilot) an established Product. This may soon give way, however, Products themselves require ongoing optimization as the Client, its Customers and its market continuously shift. To that end, the outcome is never truly set or definitively certain.

What were once a set and forget system are now being tuned for ongoing optimizing (e.g. Content, user flows, business flow/politics) and that, is essentially turning everything in a Digital Product: managed and never truly static.

Like what you read? Give Lauren Nham a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.