"What we're gonna do right here is go back, way back, back into time." - Jimmy Castor Bunch
Nothing says prepare for the future quite like a 20 year lookback! Call me old fashioned, but I still believe we can learn a thing or two from the past.
Movements are the most personal pillar of the Revenue Design methodology - and the most misunderstood. I've seen it up close enough times to know that how people typically approach movements is largely off. Two things stand out.
First of all, like so many things in tech, the notion of building a movement is riddled with confirmation bias. It's easy to study what worked and assume you can replicate it. But by the time a movement is visible enough to study, the conditions that sparked it are as long gone as Kaiser Soze.
Second, in today's attention economy, movements are mistaken with virality. Movements must hold lasting value, not just fleeting interest. But it seems all the attention is going towards virality – no pun intended. The breakouts of this era must make believers, not just capture attention. Believe that.
I've been a part of a number of movements over the course of my career – some I helped spark, others I watched slip away. In this post, I'll cover three that each left a lasting impression and an important lesson, and one that's in flight. One consistent piece of advice: movements have their own origin stories a lot like startups. They begin with someone deciding the current conversation isn't big enough. Whether you write it down or not, shout it from the mountain top or not, it starts with a manifesto.
The Zen of Palm
Philosophy elevates documentation.
I will age myself here, but fresh out of college after my ahem first failed startup attempt, I landed a web development job at PalmSource — the software side of Palm. Before the iPhone, before the App Store, the first commercial smartphone was the Treo.
I was fortunate enough to work on the Palm OS Developer Program. Funny enough, the Palm OS design guidelines from 2003 landed on the front page of Hacker News last week. But the movement I wanted to cover here was the Zen of Palm.
An initiative that was passed along to me was to publish a series of Solution Guides, profiling a few of the top app developers. The person spearheading that campaign was also the author of a paper titled The Zen of Palm. It was closely aligned with the design guidelines, but this went beyond – it was more about the philosophical reasoning, design decisions, and mental model for building high-value mobile applications. It was a manifesto.
I didn't fully grok its importance at the time, but I did witness its impact as I profiled developers. We needed them to truly believe it was worth their time and effort to build for Palm OS. Remember, before the iPhone – this was new territory for every application developer. Documentation alone – even docs as excellent as the design guidelines – weren't enough on their own to make true believers.
And it worked. As I spoke with developers and wrote out the Solution Guides, I had a philosophy to align to. Everything was bigger than the code. The Zen of Palm gave developers an identity. We've all witnessed how this played out over the years with the App Store.
Looking back, it's easy to say Palm squandered the smartphone opportunity. Maybe so, but being a pioneer for that kind of movement was something to be proud of regardless. And an early career experience that would have lasting impact.
Serverless Has Servers
Conviction outlasts correctness.
The early cloud infrastructure days were wild. Nothing quite like AI today, but when AWS first launched S3 and EC2, everything changed quickly. My Palm OS days kept me close to developer advocacy, but I had moved more to the business side of technical alliances.
My roommates at the time were starting a dev tools startup called Iron.io. I joined about a year in once they had solid traction with developers and a notable early presence on the Heroku add-on Marketplace. My job was to drive marketplace business and establish alliances across the AWS, OpenStack, Cloud Foundry, and Red Hat ecosystems.
It was always hard to get people excited about what we were building unless they had personally experienced async challenges at massive scale. Message Queues were a known category, but far from a "must have" for your average developer. The company was growing, but not at an explosive rate — especially compared to peers like Stripe, Twilio, and New Relic.
Then we wrote an article for ReadWriteWeb titled Why The Future of Software and Apps will be Serverless that changed everything. Kudos to Ken Fromm who authored the article – I will forever defend that publication as the origin of the term.
To say that serverless was polarizing is an understatement. On one side, a swarm of developers and DevRel influencers went all-in and declared serverless the future. On the other side, the "serverless still has servers!" crowd was highly vocal.
We coined the term. We should have owned the movement. But we didn't. In hindsight, we didn't have enough conviction. I went on a speaking tour around serverless, but cautiously played both sides — "ha, yes, there's still servers, it's more about the developer experience." And, "it's not the silver bullet architecture for every workload — think of it for background jobs at scale."
Both technically correct statements, but both too timid. When we softened the message to be precise, we gave everyone a reason to ignore us. The serverless movement was built without us and eventually left us behind.
Now, 10 years later, that tension between conviction and correctness has only intensified — sensationalism runs wild. But I take my cringe like my creamer — just a splash. I'll forever be on the side of correctness, but when the movement starts to build, you just can't flinch. It's supposed to take a life of its own, that's what makes it a movement.
BeyondCorp: Google Security for Everyone Else
Occupy the space others create but don't own.
The serverless chapter taught me that naming a movement doesn't mean you own it. This next chapter taught me what happens when you don't. And finally, a personal win!
After Iron.io, I joined a security startup called ScaleFT as their first marketing hire. They were just getting off the ground with a sharp approach to SSH access. Cool tech with a lot of "wow" factor for a certain type of developer, but there was barely a market. Zero Trust was no more than a whisper outside of industry analysts, so we had a lot of work to do to get anyone to care.
As luck would have it, right around the same time, Google released a white paper detailing their internal security architecture. Novel for the sheer operational scale, but also for the unconventional approach — instead of relying on traditional network controls, they applied auth at the application layer via reverse proxy in front of every internet-facing service. The fundamentals of Zero Trust in practice.
They titled it BeyondCorp. It mostly sat in paper purgatory until they published Part 2 about a year later, this one more technical in nature. Also at this time, ScaleFT was evolving from an SSH tool to a secure access platform. When we read Part 2, our response was essentially, "yes! This is exactly what we're building!"
As we thought about how to align ourselves to the BeyondCorp approach, we did a domain lookup. Turns out beyondcorp.com was available. Google is great at publishing industry-changing whitepapers, not so great at the follow-through.
So we bought the domain and built a basic info site that explained the core principles of BeyondCorp – with only a light mention back to ScaleFT. The topic gained traction fast, so we pushed further — we launched local Meetup groups in San Francisco, New York, Boston, and Seattle, I wrote a weekly newsletter with industry commentary, and we hosted fun satellite events at the major cybersecurity conferences.
The community took to it. We kept everything around BeyondCorp informative and vendor-neutral while building up the ScaleFT business. It was such a logical connection that we didn't have to force it – as a 15-person team, we were widely considered the Zero Trust company at the time. Zero Trust would eventually become one of the biggest inflection points in all of cybersecurity. For us, a scrappy content marketing idea became an industry-wide movement we could legitimately hang our hat on.
Long story short — two lead architects from Okta came to one of our SF Meetups, and a few months later, we were acquired. That was July 2018. I spent the next five years at Okta, where everything I learned about startup product marketing became everything I needed to learn about big company product marketing. That's a whole separate topic.
The lesson here is that the ground swell comes from the ground-level work. Google created the BeyondCorp framework, but it would have been forgotten without us building the belief structure. When I look at BeyondCorp, and then go back to the Zen of Palm and Serverless, there are similarities – make something bigger than the work that practitioners want to identify with.
Actionability
Kill your own category before someone else does.
Now I'm at it again at Axonius. I almost stopped short of this as it's current, but I'm taking some of these learnings to heart in real time.
In short, the cybersecurity industry has been enamored with visibility for decades. The saying goes, "you can't protect what you can't see". Axonius built an incredible business around that principle. And we created and dominated a category once already - Cyber Asset Attack Surface Management (CAASM).
But we saw an emerging theme that visibility alone isn't enough on its own. A sprawl of dashboards does not make a company secure — you have to actually do things. Actionability is our term for taking action grounded in complete visibility.
Building the Actionability movement required an uncomfortable first step: we ceremoniously killed off the category we created to focus on the future. This was quite the test of our conviction. We didn't just tell the market – we told the team, and our customers that thing we built our reputation on was no longer the destination, but rather the foundation.
It's good that we did that when we did. The market trends we predicted have so far come true – the major analysts came out and said the same thing shortly after, and the market convergence we set our sights on is exactly what customers wanted to see from us. It was a critical evolution for a company growing into a scaled company.
When we started circulating this internally and externally, we had to make a couple things clear. First, actionability isn't a category the same way visibility isn't a category. It's an overarching theme – perfect for a movement. And second, that actionability doesn't negate visibility, it extends it. I'd be lying if I said everyone jumped up at the prospects – it's taken persistence to get this far, and we have a long way to go.
While actionability is in its early days, I'm taking my learnings from the past and the general pattern of movement design with me – align to the inflection, build out the space, do what it takes to earn the belief.
Takeaways
I hope you enjoyed a day in the life of Revenue Design. And by day, I mean 20 hard fought years, not a funded vacation meant for YouTube views. To summarize my personal 4-part spiritual jazz number:
-
Philosophy elevates documentation. People need something to believe in, not just something to build on.
-
Conviction outlasts correctness. You can be technically right and still lose the movement you started.
-
Occupy the spaces others create but don't own. The biggest ideas often go unclaimed at the ground level.
-
Kill your own category before someone else does. The market won't wait for you to be ready.
Movements are fun – it takes guts to start one, and discipline to sustain one. But truly owning a movement is how companies win.