Understanding Adobe Creative Cloud

There's been a lot of controversy around Adobe's move to Creative Cloud as well as their moving to a subscription-only product offering. This is obviously a major shift in approach for both, Adobe and their customers, so I thought I'd write a post to provide an angle at how to look at this move. A few things before I do, however:

- I do not currently work at Adobe. However, I did once work at the company over 10 years ago, when I was the product manager for Illustrator.
- The information I share here is simply my own opinion and my own ideas from my experience having worked at Adobe and from what I know in the industry in general.
- I am not endorsing Adobe's decisions, nor am I defending them.

Many people are of the opinion that Adobe moved to the Creative Cloud model to make more money. It would be hard to argue with that, as Adobe is a public technology company and looks to make a profit. But this stems from a major shift in thinking at the company, and when you say "make more money", there are various ways to look at it. To understand this better, you have to understand Adobe's  software business, and what has changed.


In the past, a major software product -- such as Illustrator, Photoshop, or InDesign -- was built using something we call a PLC, or a Product Life Cycle. At Adobe, the PLC for the average product was usually 18-24 months. The PLC traditionally begins with product managers who draw up a document that contains a list of all the new features that will appear in a new version. This document is a result of much research which includes numerous customer visits, focus groups, surveys, user studies, and discussions with product experts. This document -- basically a detailed roadmap for the new version -- is vetted by upper management, and the team hopes that when the product finally ships, people will purchase or upgrade to the new version -- in hopes that all their planning and research would satisfy what features the public needed.

Once this roadmap is approved, milestones are defined and the engineering teams start to build the features. Major milestones, such as alpha, beta, etc. are created and act as checkins along the way. At some point (usually at beta), Adobe shares the product with external customers to get feedback or to get additional help in testing the software in various environments. After the product is heavily tested, Adobe then ships the product.

In the world of software development, this process is referred to as "waterfall" -- meaning that the development is linear, and each part of the process happens sequentially. There are several issues with this development approach:

- The product team must anticipate what the public will need a full two years in advance.
- The massive investment in this two-year project means once you get started and you decide on a direction, making any kind of change is extremely cost-prohibitive
- By the time a product gets to beta and is tested by the public, it's far too late to implement feature changes, and often only crashing or other major technical issues are dealt with
- Large products with large feature sets require large teams of engineers -- all of whom are tied up on long-term projects. If a problem crops up and you need to move engineers from one project to another, you can jeopardize entire project schedules

The business downside to a waterfall approach is also a major issue. Guess wrong on what features you think the public wants to see in your product and you've not only wasted two years of development time without making money, you now must wait another two years to develop the next version, in hopes that you correct it then. The stakes are very high. And a company like Adobe must then spend millions of marketing dollars by staging a "launch" where all these new features are hyped in hopes that the public will make a purchase. Repeat this every two years, and for each major product that the company offers.

Let's contrast this waterfall method with an approach that's being used more and more in today's modern product development world. Instead of large teams building a large amount of big features across a span of several years, companies have started assembling smaller cross-functional teams that work on specific individual features with short development cycles. This approach is referred to as "agile" development. An agile approach allows a company to focus on specific features which they develop quickly -- even within weeks. This allows product teams to create features that solve customer needs quickly. Perhaps more importantly, it allows a team to take on risk by experimenting with innovative features or the like, without worrying about losing 4 years of work. Feedback from customers can be reacted upon immediately.

In theory, an agile approach would make both a software company like Adobe very happy, as well as its user base of customers. Adobe could build better products faster and that meet its user's needs, and customers can get features they really want and need in a shorter amount of time. But there are challenges on both sides.

On Adobe's side, moving from a waterfall approach to an agile approach for software development is a HUGE undertaking. Traditionally, Adobe would be structured in teams of engineers, quality assurance, product management, and the like. These teams all had their own management structure and hierarchy. An agile approach would mean creating smaller individual teams -- each containing an engineer, a QA person, a product manager, etc. These individual teams would be working on specific features, not entire products. Not only is this a massive logistical shift, it's also a massive cultural shift. Across multiple products.

On the customer side, moving from a mentality of seeing a new version once every two years to potentially seeing a stream of constant updates is also huge. There are standardized workflows at companies that need to be tested with each new version. Teams require training, needing to learn the new features. And perhaps most importantly, IT departments and business owners need to think about budgets differently.

Let's go back to Adobe's perspective for a minute. One could argue that Adobe could have stuck to a waterfall development approach. But moving to agile isn't only good for the product development benefits I outlined below. It's also necessary to make money. No, I don't mean making money by charging customers more. I mean it's necessary to make money in today's competitive market. While there aren't any serious competitors to Adobe's products, there are definitely some interesting products out there that are gaining attention.

Pixelmator and Acorn are examples -- and while they can't compete head to head with Photoshop, there are plenty of folks that are using those products as alternatives for certain kinds of work. A small company can easily add features and make adjustments, while a large company like Adobe moves like molasses only releasing massive complex feature-ridden products every two years. Adobe would never survive. They need to become agile and to react to customer needs quickly in order to maintain their leadership.

But in order for Adobe to move to an agile approach, they need to change their business model. They can't sell potentially new versions of each product every few weeks or months as each new feature is added. The overhead would be enormous. When I left Adobe 10 years ago, there were 13 localized versions for each language of every product. Every product had a Mac and a Windows version. Every product was available as a new full version or an upgrade version, and there were education versions as well. That means that from an accounting perspective, there are over 250 "versions" of every product that Adobe sells. And there are over 20 products. If each of those products were sold as perpetual licenses and updated on a constant basis, the costs Adobe would have to charge would be prohibitive.

So in the end, Adobe needs to move to an agile approach to stay relevant and fresh, and to compete in an ever-changing technology world. And in order to support that, Adobe needs to move to a subscription-based model. It simply cannot work in a perpetual license model.

Now, if you want to argue how much money Adobe is charging for their products, that's totally fine. But hopefully I've been able to provide some background for why Adobe had to go this route in the first place.