I joined Adobe to make the tools that my friends & I wanted to use. I was a Web designer & animator who loved what I could do with Photoshop & Flash, but who hated all the barriers that got in the way. My whole mission was—and has remained—to hijack the brains of smarter people and get them building the stuff we (creators) need. My loyalty has always been to that mission.
Like most big changes, the move to Creative Cloud is both exciting & disruptive. So far some people love it while others are very upset. I’m not writing this post thinking I’ll change everyone’s hearts & minds. I just want to tell you how I personally have thought about the change, from the perspective of someone who deeply wants to help creative people thrive.
My overriding thought for months has been, “How can I take advantage of all this to do good things for customers—things we couldn’t do before?” If you’ve come to know me at all through the years, I hope you’ll know how sincerely I say that.
A few key points about the change:
- It marks a move towards a less app-centric & more solution-centric world.
- It marks a move away from “big-bang” feature updates & towards continuous refinements (“JDI“-style).
- It means more nimble development.
- It radically lowers the barrier to entry to creative tools & broadens access to them.
Part of what’s made the change feel weird (even to me when I first heard about it) was that it’s seemed a bit like taking apples (previously shrink-wrapped, unchanging apps) and selling them as oranges (constantly evolving services). We’re all so used to versions of Photoshop & CS apps shipping once & standing still.
We believe that to help creators going forward, we need to think broader. For example, is creating the next great Photoshop or Lightroom feature the only way Adobe can help photographers? No: that’s necessary but not sufficient. Photographers need services that help them do their jobs, make money, and sustain their craft. The same is true for all kinds of creators.
We need to make more oranges—and the oranges you want.
To me it’s like when we first created Lightroom. It was born of the realization that photographers didn’t just need us to go deeper & deeper with Photoshop, but to go broader in addressing workflow challenges.
Now it’s time to think broader again—not just multi-image, but multi-device, and not just individual apps but connected solutions. Photographers can see some hints of this in Tom Hogarty demoing cloud sync between Lightroom & tablets, and in Adobe adding beautiful portfolio hosting to Creative Cloud subscriptions. Designers can see this with Digital Publishing System arriving at no extra cost, giving them a new way to reach readers & serve clients. Creative Cloud is just 12 months old, and there’s so much more we can & must do.
To get there, we need to fundamentally change how we build desktop software. Here’s how things used to work:
- Teams would decide on a schedule (generally 18-24 months). So that customers wouldn’t get bombarded by constant one-off updates, we needed teams to stick to these dates (i.e. vary features or quality to fit).
- We’d work our butts off to deliver every possible improvement, but when crunch time came, we’d have two lousy choices: either rush to finish a feature & make the release, or cut it, putting it 18-36 months from customers’ hands. (And yes, there are accounting rules that make it difficult or impossible to give away new functionality (distinct from bug fixes or compatibility updates), but let’s stay out of that can of worms here.)
- We’d include “wow features” that sell upgrades. It’s easy to wag your finger here, but we’re all busy and distracted: For a new product to grab my attention, it has to really grab my attention. For better or worse, that’s put a pressure on teams to include gee-whiz functionality. Some of that’s useful day-to-day, but some ends up just being demoware.
- Fixing bugs in the shipping version often came at the expense of working on the next version’s codebase.
- Enabling services meant working across versions of the apps, sometimes with significantly different architectures, file formats, etc.
It’s not a recipe for responsiveness & polish—so let’s do something better:
- Plan more frequent, more incremental updates. That makes it much easier to respond quickly to customer feedback & changes in the market.
- Continuously evolve the codebase, rolling out new features & bug fixes together as soon as they’re ready.
- Don’t rush features or hold them for years: just ship them when they’re ready. (It’s much easier when the next train is leaving the station in just a couple of months.)
- Don’t worry so much about whizzy new features. Don’t worry, those will still happen, but we don’t need to force them in to sell upgrades.
- Integrate new services more quickly, creating systems that go way beyond static, standalone apps.
This gets much more practical when the teams focus on continuous development of one codebase. Knowing that everyone’s using the current version makes it much simpler to plug systems together.
Now, you could reasonably say, “Okay, fine, but keep rolling out perpetual versions that periodically catch up with the current one.” Unfortunately that hasn’t been great when we tried it over the past year: every time we’d add features just for subscribers, many people who bought perpetual would feel like second-class citizens. No one likes feeling diminished. It also increases drag on the product teams, splitting their attention between past & future.
As someone who’s spent a lot of years building tools I hope you’ll love, I’m convinced that continuous, incremental development helps me serve you better.
As I say, thanks for reading. I haven’t tried to address every concern, and I’m not sure I could if I tried. I just want you to see how things look from the perspective of someone who deeply wants to help more people create a more beautiful world. Even though I (and Adobe) often can’t keep up with all the feedback, please know that it’s extremely valuable. I am committed to keeping this conversation going.