So Long, Autodesk Shotgun
Note: I’m writing this as a former employee (as of June 2021) of Autodesk. My views are entirely my own, based on my recollections and personal experiences during my time with the company.
I’ve been working with the Shotgun team in various capacities for the past 7 years, shortly after it was acquired by Autodesk. The first few months I worked with the team, people would ask me what it was like, and I’d always answer “absolutely everyone is super-smart, it’s really weird”. Practically everyone who was there back then has now moved onto other things outside of Autodesk, but I stay in touch with many of them and miss working with them all greatly.
Today I read this post (warning: the language used in the post is quite strong). It’s the kind of thing no Product Manager wants to read, as it signifies us having failed our users. It made me reflect on how things have changed both in the company and how those changes have manifested in the formerly beloved product itself over the past few years.
When I started, the feeling within the Shotgun team was one of a startup embedded within a larger corporation. We had a great deal of autonomy, and I spent the first few months blissfully unaware of what most of the rest of Autodesk was doing. We were focused on one thing, and that singular purpose, combined with the fact that most of the team (myself included) had been plucked out of the industry we were now serving, meant that all of us cared deeply about the work we were doing. Customer pain wasn’t a cliche, it was our pain too. I spent months embedded with people trying to use Shotgun to get their film and episodic shows produced, I was there when things went wrong for them and they lost time or got frustrated. Our company mission was to “get people home in time for dinner” and we all knew how important that was. We had seen people work long hours, sacrificing everything for the sake of a single shot in a piece of media (or had been one of those people). We desperately wanted to succeed.
A couple of things got in our way.
Even when I joined seven years ago, much of the technology used in the web-based product was dated, and many of the design patterns and user interactions were archaic or undercooked in a rush to get them out the door. From a certain perspective, this was a good thing– the product had product-market fit, and arguably a big part of the reason for that was that its development process was optimised for being responsive to the multitude of varying needs of its customers, not in spending time and energy in polishing features that were good enough. One thing I learned about building B2B software, is that every customer needs different things. So if you have customer A who needs something, then you go and build it as quickly as possible, when customer B comes along with a different problem, you are incentivised in the short term to now go and build the thing customer B needs, rather than iterating on the feature you just made for the benefit of some imaginary future customer. Everyone wants to build software that delights, but doing so often means not doing something else, and when you are trying to make people “happy” and “willing to pay”, as opposed to “delighted”, something has to give.
Years of this mindset had created a product that was feature-rich, had incredible retention, even winning an Academy Award, but was falling apart at the seams from product debt. We had reached a point with the product where whenever we tried to build anything new or otherwise update certain aspects of the software, dozens of unrelated things would break. There was limited test coverage across all the code, and conversely a lot of different ways for users to configure their particular experience. It wasn’t that every instance of Shotgun was unique, but it wasn’t far off.
It was a problem that always seemed incomprehensible to new leadership. Someone would join the team with the ambition to make us go faster, assuming it was down to lack of motivation or willingness to make changes. I referred to this excellent article often when I was thinking about this situation, and this graph in particular:
We were constantly in the red area of the graph. We had tons of data on what we needed to do with the product, debated furiously about what was the most important of all the things to commit our scarce resources to, because doing anything at all would be extremely challenging and costly; and then failed to execute effectively. That though, was not down to any technical hurdles. It was down to an existential issue.
Autodesk is a big corporation, albeit one with less than 10,000 employees globally. It’s best known for AutoCAD, though the overall product portfolio probably numbers in the hundreds. Most of what Autodesk does is serve the architectural, construction and manufacturing industries. A tiny portion of its revenue though, comes from media & entertainment, predominantly high-end 3D content creation and rendering (with Shotgun as the product that focuses on the business functions of those processes). No one seems to know, or at least be able to articulate why it maintains its deathgrip (over time it has acquired many of the dominant products in the space) over a vertical that doesn’t materially factor into the company’s bottom line. We would speculate that there’s the sex appeal (such as it is) of big splashy visual effects showreels in stark contrast to photos of people with hardhats and the umpteenth render of a building exterior in corporate marketing materials. Whatever the reason, we constantly felt that the corporate overlords would at some point decide to cut their losses and drop the entire division. That never happened though. Instead we had a string of reorgs and their corresponding shifts in focus.
Around three years ago our product group was selected to pilot a new “incubation” process within Autodesk. On paper it was a superb idea- you allow a group to effectively function with the same level of autonomy– and accountability– as a startup would. Our goals became growth-based, we had targets and if those targets were successfully met then our “funding” would increase accordingly.
The problem though, was that no-one on the team actually cared about growth. “Get people home in time for dinner” had to become something more like “get even more people home at some time”. Our growth targets then just became a means to an end: get more users and then we get permission to do the stuff that we actually felt excited by.
With all of this came a sense of (in retrospect) unjustified optimism. The team was restructured, some development teams were dropped and more senior managers were hired in their place. The idea was to get them in place for when our team would be able to grow. The only thing we needed to figure out was where to find the growth opportunity.
The high-end visual effects industry that we dominated is notoriously slow to adapt to change, and operates for the most part on razor-thin margins. There were billions flowing into film and episodic production every year, but there wasn’t (and likely still isn’t) an obvious opportunity to further monetise our existing customers. But there were two bets that might make a difference. First, Shotgun was too hard to get up and running for anyone unfamiliar with it (due to us never having paid back the aforementioned product debt). Fixing this might lead to greater adoption. Second, although Shotgun popular with Producers and Coordinators, Artists didn’t get on well with it. It was estimated that in a given company there were many more artists not using Shotgun than there were people already using it and that winning them over would lead to significant growth.
We organised around going after those two potential opportunities and then almost immediately ran into trouble. I (along with a couple of other product managers) was involved with solving the ease of use problem. What was easy was identifying the roadblocks and them prioritising their importance. Where we came unstuck was in actually trying to implement viable solutions to those problems. Any single problem we tried to address was going to be a multi-month effort with the team we had and the technical challenges we would have to overcome (and again, in retrospect even those estimates seem woefully optimistic). There was also the problem which no-one really wanted to admit, which was we didn’t have experience of building things that were easy to use (fortunately, for me at least, many of the people we hired over the past couple of years did have that experience, and I learned a lot from them).
But we tried, thinking we could tackle smaller line items in shorter time spans and build up a sort of momentum. We budgeted work by the quarter, but the first quarter worth of work stretched out to two quarters, then required further work in addressing regressions, then more regressions. My choice each time was between abandoning the work half-finished and try something else, or else seeing things through to completion. I chose the latter option, because we had a long history of leaving things half-finished, and everyone on the team, and our customers, was pretty tired of it. I still don’t know if it was the right one, but it definitely wasn’t the wrong one.
Meanwhile, the artist opportunity was pursued by building out a new product from the ground up, using a much more modern technology stack than we were used to. It represented the future, but it also meant that many developers who were experienced with Ruby or C++ had to reskill in a very short space of time. It was hard. The product, Shotgun Create, ultimately launched as a vastly superior (in terms of user experience) alternative to Shotgun’s capabilities for reviewing and approving work. But it was hard to get people to actually use it. For a couple of months or so, everyone across the organisation stopped what they were doing to help out on the adoption push. It was a stressful time for many, and when it was over, had left a deep scar on the team.
Two opposing schools of thought were forming. In one camp, the only way forward was to completely redesign and rebuild Shotgun from scratch, using modern engineering and design. In the other, we had to make incremental changes, minimizing disruption to users above all else. Both approaches had their pros and cons, but the team couldn’t be aligned to one or the other. From leadership down, we oscillated back and forth between each. During this stormy time, the strategy to improve adoption through changes in the product was jettisoned in favour of a focus on Go To Market, and a number of key people departed the company, either through frustration or having been terminated.
The result of this was that for the first time the majority of employees on the Shotgun team were not native to the media and entertainment industry. Many of them were willing to learn, and had a strong sense of empathy, but it would take time to build the domain knowledge up. Priorities shifted once more, this time to focus on integrating with the Autodesk corporate machinery. It was a sensible approach, as it would remove things that were bespoke to Shotgun without providing any real benefit, such as billing and sales channels, but it carried a massive opportunity cost, with leadership making it the top priority for us, and requiring a lot of work over a number of months for the team without having anything users would actually care about to show for it. More reorgs happened, as if to drive this point home. The “Street Team”, a support team comprised of extremely smart and knowledgeable former Shotgun experts and workflow specialists, was dissolved, with the general Autodesk support team attempting to fill in. From the perspective of the product team, we pretty much stopped hearing from customers altogether (aside from those we were speaking to directly).
The incubation process ended, or perhaps fizzled out. Many customers were complaining that their needs were not being met, but there wasn’t capacity to do anything about it (others had since given up complaining, which was in many ways worse). What we were trying to focus our energies on at that point was creating the infrastructure to create new experiences in a piecemeal way that would be decoupled from the problematic technology stack. Our bet was that being able to build in a new environment would allow for experimentation and iteration at a speed expected of a modern software company. It represented our attempt to finally break free of the technical debt that had plagued us for years. It was exciting.
And then came another reorg, and corresponding shift in priorities.
I can’t say (both for legal reasons, and because I don’t know) where things are headed for Shotgun going forwards. It has recently been renamed to “ShotGrid” in an effort to make it less problematic, as part of the integration work (and needless to say, requiring a lot of work in its own right). I can count the number of people still working on the ShotGrid team who have industry experience on one hand (and the former willingness to learn and empathise seems to have dissipated), a far cry from how it was when I joined. Perhaps that doesn’t matter. Perhaps the remaining ShotGrid team will be able to address the product debt issues and modernise or otherwise improve it for the userbase in a way we were unable to do. More than anything, I hope to read a post from a customer at some point in the future, telling a story about how the product helped them get home in time for dinner.
