Product vs. Single Projects (and 8x Teams)

A couple posts ago, I mentioned something about teams improving their capacity for value delivery “by 8x”. Someone I respect questioned that claim, which in turn lead to an interesting conversation.

Single Project

Take a narrowly defined project in isolation. Assume the customer can describe exactly what they need (by the way, I think this is actually possible in some domains, others would disagree). Prescribe a tech stack. Measure the outcome based on how much the project costs, when it is completed, and conformance to some sort of spec. Run the test over and over on different, but similarly skilled teams. In this case, and against these metrics, I don’t think you’ll ever see one team outperform another team by 800%.

Maybe a crude example … ask 50 similarly sized expert home building teams to build a single house to plan, and you wont see one team build it in 2w and one team build it in 16w.

SaaS Product

Take another scenario. A company wants to make as much revenue as possible while at the same time retaining their existing customers. The company delivers their software via web browsers to 20,000 customers, and earns the bulk of its revenue from monthly subscription fees. In this case, I think it is entirely possible for the best teams to produce 8x the revenue (or more). Why? The best/better teams would likely…

Again, probably a bad example … but imagine a construction company toying with prefab, new materials, variable floor plans, 1000s of homes, etc. I could see one generating 8x the revenue.

In short, they can beat the feature/project factory approach, which opens up all sorts of opportunities for optimizing value delivery. I repeatedly see large enterprise software product companies with vast resources get shellacked by small, nimble teams. Or even on a very local level the relative performances of UX Research or Growth teams.

This is the 8x I’m talking about. The distance between the best and the mediocre is great.

The differences here make comparisons difficult. You’ll hear someone talking about product development practices, and it will sounds completely foreign. Or someone talking about competitive contract work, and their challenges will seem foreign as well. Context is everything!

Multiple hat-wearer. Prod dev nut. I love wrangling complex problems and answering the why with qual/quant data. @johncutlefish on Twitter.