Invention, Innovation, Adaptation, and Adoption
LinkedIn, like all social media platforms, is drifting towards mediocrity. Recently, I encountered a post from a supposedly seasoned product practitioner urging wholesale adoption of a new product operating model proposed in a recent book by an author who writes extensively about product management. I’m paraphrasing, but the practitioner’s sentiment was clear: "If everyone would just adopt this model, all our problems would be solved."
While I haven't read the book in question, I doubt such a one-size-fits-all approach would work. Let's explore why blindly adopting models designed for specific companies rarely succeeds.
Inventing something new is laborious, time-consuming, and expensive. Adoption is economically sensible and carries lower perceived risk. Businesses optimized for speed and measured in quarterly increments can rarely afford the deliberate pace invention requires.
Don't feel bad if you're an adopter—you're probably doing the right thing. But remember: most models won't work out of the box for you.
Waterfall, Scrum, Spotify—all these models were designed for specific purposes. The Lean Startup described conditions for building instant messaging avatars. The Spotify model is suited to building a scalable, real-time music player. Pre-1980 frameworks were optimized for spaceflight and military applications.
Yet, we persist in adopting frameworks without adapting them to our needs.
Adoption, part one
Waterfall , arguably the first software development process, has a contested origin. Herbert D. Benington described a phased development process in 1956, while Winston W. Royce proposed a more detailed, multi-step process in his 1970 paper . Neither used the term "waterfall," and both warned of potential limitations.
Royce's process was tailored for "software packages for spacecraft mission planning, commanding and post-flight analysis." Benington's process coordinated the Semi-Automatic Ground Environment (SAGE), which controlled NORAD's response to potential Soviet nuclear missile strikes.
So, low-stakes projects, right?
Thirty years later, my teams were using Waterfall in (mostly) unaltered form to develop identity management tools for corporations. Consider the difference in failure tolerance. In my case, failure meant employees couldn’t sign on to enterprise applications. In Royce’s case, failure meant astronauts drifting off into the cosmos. In Benington’s, nuclear annihilation.
领英推荐
Nonetheless, Waterfall suited our complex software even if using it meant long delivery cycles. Agile practitioners deride infrequent delivery, but our customers couldn’t adopt new versions of our software more frequently than every twelve months. Even if it took eighteen months to release a new version, we were still delivering value.
I invested little effort in adapting our use of the Waterfall methodology. Instead, I adapted myself to the process.
I wrote long, detailed product requirements documents, begged for detailed engineering specifications, questioned delivery estimates, pointed out when features weren’t correctly implemented, complained about bugs, and made impossible decisions to release with known issues.
Though it caused us pain, we adhered as closely as possible to our chosen process. We estimated that features would take six weeks, but they ended up taking six months. Project reviews often bogged down while we untangled how to get Team B to unblock an idle Team A. We didn’t adapt the model because, in the end, when we assembled all the parts and shipped the software, it mostly worked as expected.
During my tenure, we did a handful of releases for each product in the portfolio and grew the business from $10M to over $350M. It’s hard to argue that we weren’t successful. However, the process we were using was entirely overengineered for our needs, and we could have easily diverted people and money to attack different problems in new markets.
Adoption, part two
Spotify’s software engineering model fascinates and dazzles people. Perhaps this is because Spotify used it to build spectacularly successful software, and it seems reasonable that adopting the model will lead to similar success.
Spotify’s approach is as much a behavioral science experiment as an engineering process. It’s a masterclass in culture design, combining people, processes, technology, physical space, ideals, and principles to create a unique community invested equally in autonomy and alignment.
Think for a moment about the physical space design. The Spotify team carefully considered how their working spaces create conditions for creativity, innovation, communication, and collaboration. The model relies on Squads sitting face to face, having open areas to stand, talk, draw, and plan, and making spaces for quiet focus time and collaborative work like pair programming.
Eventually, Spotify adapted the model—its primary purpose was adaptation–as new product principles took hold. The team outgrew the original model design, and keeping alignment across teams became more important than letting teams operate entirely autonomously.
The Spotify model’s success relies on its completeness, and most companies that claim to have adopted it haven’t...