Project Management, Product Management, Scrum, and a Life in the Theatre

Photo of Alabama Theatre from Library of Congress. Believed to be in public domain.

I’ve been working in digital media and technology for so long sometimes I almost forget that I ever did anything else. But my first few years out of college I had another career entirely.

Seattle’s music scene was exploding, people I knew were becoming rock stars, and I had some real sound engineering chops along with the hair to go with them. For my own perverse reasons, I put those skills to work in theatre instead of music. For three years I worked in the cadences of live theatre, until the process of “teching in” a show became second nature.

In the tech week leading up to the cruel, hard deadline of opening night, we’d meld the work of the actors with the work of the designers until they became seamless. We turned the performance into a product that could be reliably manufactured every night with consistent quality.

Coming from this background, the concepts of Lean production and Agile management feel like common sense. How else could you do what theatres do regularly?

Theatres identify a new product opportunity, develop a resource plan for creating the product, coordinate independent development across multiple disciplines, then bring together the output of these disparate teams with just enough time in the schedule to tune them to work together, identifying and clearing blocking issues through both ongoing one-on-one communication and a daily meeting with all the involved parties.

The outcome of the theatre rehearsal schedule is a performance, which is nothing but than a repeatable process.

Every night on a smoothly-running show is a night on an assembly line. If the director, stage manager, and designers have done their work right, they’ve built a great assembly line and great performances roll out of it like so many cans of peas.


Then I moved into digital media and tech, working variously at startups, enterprises, and agencies. None of them approached project management quite the same way as the other, but some of them did it better than others. Which is not to say that there is a right way and a wrong way, because there really isn’t.

Too often in the world of digital media and product, projects so often slip deadlines, overrun budgets, or fail to produce anything that anyone would actually use. Small companies with these problems usually disappear pretty quickly the same way a theatre that only mounts bad shows would. But established enterprises can run for decades without bringing the real value of their resources to bear on their business needs.

Compounding the problem, each sub-optimal project execution becomes part of the culture of the teams that worked on it. At an enterprise with executional challenges, an expectation that major efforts inevitably are slogging marches in the vague direction of an unclear finish line will become a self-fulfilling prophecy. This memory of past failures is far more powerful than any Mission/Vision/Values screensaver HR can install on every desktop machine.

But the employee trapped on a slow walk to nowhere can be startled to see that the exact same process applied to a completely different project is actually working beautifully. That’s because not all work is the same, and applying what works for one type of work to a different type of work can turn out to be a big mistake.

The process of mounting a theatre production is, by definition, a creative one. But as a sound engineer I did technical things. I positioned speakers. I patched signal paths. I applied ‘x’ many dB of attenuation to the frequencies between ‘y’ Hz and ‘z’ kHz.

It got complicated, and there were some shows where I cursed the Sound Designer for being so damn creative that I really had to be on my toes not to mess up every night. My technical skills were being used in the service of a creative endeavor and creativity is often messy. That was the trade off, but it was also what attracted me to the work in the first place.

I once saw a presentation in which the presenter stressed the importance of having a process for orderly management of Information Technology by declaring “today, every company is a technology company” and then providing examples to back up his position. Ryanair, he pointed out, was launched by hiring an IT department before it acquired any planes.

He was right in that every company is a technology company, but he was wrong in that he didn’t take that insight the next step to its logical conclusion. Sitting there, I had an epiphany.

Before long my realization led me to go back to school, but not for the MBA or Master of Information Science I’d been considering. Instead, I looped back to my beginnings and got a Master of Communication in Digital Media. I wrote a post for the program blog about my realization using the idea that had changed my path as the title:

Every Company Is a Media Company.

“Media” is often used casually to mean “the news media” or something similar. But really media means anything that we use to share ideas. Without communication, no business idea or process is possible. Machines may be able to run themselves, but unless humans interact with them, what they are doing isn’t business. The companies that are better at human/machine interaction are the ones that succeed.

Whether or not it was a result of my post, or was just in the zeitgeist, the phrase popped up elsewhere occasionally for a few years but invariably missing the point I’d tried to make when I first wrote it. Other people who used it were talking about content marketing, but I was talking about human factors and informed technology choices.

Once a product is built, the technology project is considered done, but the media project is just beginning.

Typically, the people responsible for choosing, or building, technology products are trying to hit a list of specs. The tech must do A, B, and C in order for the project to be considered a success. What happens after the specs, in the interaction between the tech and the people who must use it, is too often not considered when defining a project’s success.

I’ve spent my career having to live with the outcomes of this type of project management. Here’s an example.


A large retailer which made roughly a quarter of its ~$2B annual revenue from ecommerce was losing market share to smaller, more agile competitors. Its site was a relic of the early web: Static and feeling increasingly clunky as customers’ expectations evolved. The millions of dollars in unmade sales were growing continually and the Ecommerce department was chomping at the bit to redesign the site.

For 18 months, there was just one thing that blocked moving forward with the redesign: The kiosks.

Some years earlier, the IT department had been tasked with the project to identify and implement appropriate technology for in-store kiosks that would display the ecommerce site and allow customers and employees to look up and order items not in stock at that location. You rarely see these kiosks now because smartphones have made them largely obsolete, but in the first decade of this century they were helpful and measurably contributed to overall sales.

On the surface, the technical requirement seems simple. Each store needed a low cost computer with a web browser.

But there were other considerations:

  • By default, web browsers can go anywhere on the internet and it was important to limit the kiosks to only the ecommerce site.
  • The cash register network ran on Windows and the internet was awash in Windows viruses then so IT had severely restricted the number of stores allowed to have direct internet connections.
  • Even the connections that did exist were slow ones, adequate for backend data transfer but not real time web browsing.
  • The tech needed to last for a certain number of years in order to justify the original expenditure.

To an IT team working in isolation, the solution was clear and a vendor’s product was chosen.

The new kiosks were dumb terminals that connected through the firewall to a server back at headquarters. The server browsed the ecommerce site and sent a picture of it back to the kiosk. People using the kiosks were clicking on a picture of the website and not the website itself. It was secure and required minimal administration. All the requirements were met.

But as the web had evolved, customer expectations for the site had gotten more challenging. Any sort of change to the displayed web page had to be rendered as an image and sent to the kiosk. The solution had been adequate for simple pages but as the web became dynamic it stayed static.

After the kiosks were installed, marketing promotions using rotating images on the home page had resulted in angry phone calls from the kiosk product owner demanding that the campaigns be ended because the kiosks couldn’t handle them. The introduction of demonstration videos on product pages resulted in a cross-departmental meeting and lingering hard feelings, but nothing else. A new budget year came with no money set aside to replace the kiosks because they had not yet reached their projected end-of-life dates.

That was when the Ecommerce department decided it had no choice but to move forward with a site redesign that completely ignored the constraints of the kiosks.

The new site would no longer be confined to an outdated 800x600 screen resolution. It would have dynamic elements, including a global dropdown navigation menu that would send the kiosks into catatonic stupor whenever a customer tried to do the most basic tasks. It would make up for any lost revenue from the kiosks by increasing sales on all other digital channels.

All of these choices were made to further the goals of the business, but they were met with anger and resentment. Ecommerce was clearly disrespecting IT by not proposing a new site that behaved the same way as the site they already had. The matter was escalated to the VP level before it was determined that the limitations of the in-store kiosks were not a legitimate reason to prevent the redesign of the site.

To me, this situation was the personification of project management gone wrong.

The goal of project management is to complete a project, like installing kiosks. But a project that is identified, defined, and executed in isolation from the context of organizational goals is at high risk of long-term failure.

It’s easy to come up requirements based on the wrong set of questions and have a project look like a success. The kiosks did what they were chosen to do: Display the current ecommerce site at minimal expense and risk. But they were chosen to do the wrong thing.

What the project management process used couldn’t take into account was that the kiosks were less important as technology choices than they were as part of the organization’s online media plan.
It couldn’t do that because the IT department had spearheaded the company-wide adoption of a product-oriented project management methodology that had no concept of any other types of work.

In truth, there was no online media plan, because there was no context in which an online media plan could be framed. The kiosks supported what Ecommerce was doing at the time, when they should have been chosen to not block things Ecommerce was likely to do in the future. The project management model in use made it impossible to accommodate the evolution of the business.


Experiences like this — and I’ve had many — got me interested in project management that doesn’t focus on a product release as the end goal, but focuses on human factors and iterative development as the end goal. In a society where our industrial paradigm is based on how 19th Century railroads kept the trains on time, this can be a big shift in perspective.

After being exposed to some basic concepts of the Scrum methodology I read up on it and adopted some principles to my own team management style. Then a couple years ago I went ahead and got dual certifications, as a Scrum Product Owner and a ScrumMaster. And that convinced me that pretty much everyone I’ve ever heard talk about Scrum gets it wrong.

One of the biggest mistakes is conflating “Project Manager” and “ScrumMaster.” They really aren’t comparable. It’s wise to be wary of Project Managers who talk Scrum when they aren’t working with Scrum teams.

But different types of work don’t all need to be managed the same way.

In theatrical production, the Director determines the goals. The Director is the Product Owner and has a direct relationship with the actors and designers. The Stage Manager documents and communicates the decisions of the director, both individually and in collaboration with the designers.

The Technical Director works with the technical staff to realize the designers’ visions on time and on budget. Within the technical departments, the approach is much more like traditional project management, but the specs themselves emerge from the more Scrum-like process between the Director/Product Owner, and Stage Manager/Scrum Master.

This hybrid approach that uses different methodologies at different levels accommodates the realities of different types of work.

At the top, the challenge is collaborative and a bit messy. In practice, the coordination between teams looks very similar to Scrum. But below that, the different technical teams (sets, lights, sound, costumes) are focused on the type of straightforward product creation that a well-managed waterfall approach can keep on track. Changes that happen between the Director and the Designer cascade down as updated requirements for the crew.

From my perspective, Scrum is a good match for the messy things that I think of as “media” rather than “tech.” But if you can say with certainty that you understand all the future ramifications of your project and it has a well-defined scope that’s not likely to change, then by all means get out the Gannt chart and go manage yourself a project.

On the other hand, if it’s a situation where decisions have cross-team impacts, where teams are working simultaneously on different aspects that have to merge into the whole, or if the product itself is intended to be a living, breathing, ever-evolving thing, you might want to consider coordinating at the top with Scrum and its messy flexibility.