What a TV Series Can Teach You About Software Projects

What a TV Series Can Teach You About Software Projects

How you can create better ongoing value

Have you ever thought about how making and maintaining a television series, or how the production of a movie, relates to software product development from an Agile and Lean perspective? Not to worry because I have.

  • Movies and Projects = Big Bang (no learning)
  • TV Series and Products = Just-in-Time (learning)

Pitching a new television series, or a movie, is like pitching the idea for a new software project. The idea is presented at a high level along with some general estimates about the people and money needed to pull it off. If all sounds intriguing, both get the approval to proceed. But here’s the difference. In a traditional project-minded environment, the entire project is funded and scoped out in detail. That approach is very similar to making a movie. Television shows, however, do not work this way. I’m suggesting we want to be like a television series.

Movies represent the “big bang” delivery that we are accustomed to in traditional project management. Have you ever heard of a movie that “bombed” and lost millions of dollars? It happens quite frequently. Why is that? Because movies need to spend a lot of money up front before adequate feedback can be attained. When producers guess wrong, they lose, just like software development projects produced in the same manner. While movies cannot release incrementally and get better over time, your product can. Movies are the example of how to fail with software projects where as a television series is the example to follow.

What if we funded a minimum viable product (MVP) only, or funded six months only, and then evaluated the “pilot” to determine if we should keep going?

A television series gets initial funding for only a handful of shows and then launches the pilot (think proof of concept or MVP in the product world). Only if feedback is positive does the rest of season one get financed, and only if season one is successful do more seasons get approved. Makes sense, right? Why finance an entire season if no one wants to watch it, much less commit to multiple years up front. What if instead, we funded an increment and evaluated — does this project continue to provide value worth the investment? Isn’t that what a television series does? They evaluate viewership and take in viewer feedback to decide if the show continues.

When viewership starts to decline, when value tails off, it reaches the point of diminishing returns. Just like in projects/products, when the value you deliver stops being as valuable, the value curve flattens while the effort and cost remains the same. The Theory of Diminishing Returns suggests that’s the point to pull the plug (on a show), or stop adding features (products), or cancel the project, and move on to something else where the value delivered is much higher for the effort.

And what about requirements? Are nine seasons written all up front? What about just all of season one? No, that’s not how it works. Scripts are written nearly real-time or only a little ahead. Why? Why don’t they write the scripts for the whole year or multiple years up front? Because that’s waste. For one, what if the show gets cancelled? Wasted effort. What if feedback suggests a certain character needs to go or new ideas are presented that weren’t considered before? The writers think they know what viewers want (assumptions), but use feedback to learn and adjust and to stay current, so anything written “sitting on the shelf” would become waste, is inventory, from a Lean perspective. The same holds true for your product. Furthermore, this is why “requirements” are bad and we work from assumptions instead.

The television series, like a software product, has a roadmap of high level ideas to flesh out, but they hold those ideas loosely and flesh out just in time, allowing the end product to follow an empirical process to deliver what viewers (users) want, when they want it, rather than force preconceived ideas on them. Shouldn’t your product management work the same way?

Scroll to Top