Skip to main content

Perspective

“No Software”, Part Two: what comes after the SaaS bargain?

My Wharton reunion is this weekend, and unfortunately I can't be there.

I genuinely hate missing it. I would love to see classmates I haven’t seen in years, catch up on where their lives have taken them, and remember some of the amazing times we had together.

Missing it has also had me thinking about what stayed with me from those years. Not a specific class or professor. A way of thinking about Value.

  • Where does it get created?
  • Who captures it?
  • What should a company own versus buy?
  • How do incentives quietly shape what companies do?

The frameworks I learned still hold. What’s changed is the economics underneath them. And when the economics move, the same framework can point you to a very different answer.

That’s what this piece is about. It’s also why we’re building HyperContent™ around something we call Continuous Value.

Continuous Value builds relationships around outcomes, not products.

Instead of organizing the company around selling more of the product we happen to build, we want to continuously find where we can create value with a customer and bring whatever combination of product, technology, expertise and operations creates it.

To explain why I think that matters, I have to go back even further, to my first job out of college.

A then and now split: the author at the Microsoft campus in 2000 and at the IBC Smart Stories Incubator in 2026, under the title No Software, Part Two.

Working at Microsoft in 2000

In 2000 I was just starting my career as a program manager at Microsoft. I worked across MSN, mobility, and eventually the developer division as we shipped the first versions of .NET.

It was the same year Salesforce was building its brand around the curious negative slogan “No Software.”

Here’s what people forget. Microsoft saw the shift. In June 2000, the company announced .NET around a future of software and services. By August, Microsoft’s own description of the strategy explicitly included “designing software as a service.” We were using the phrase before SaaS became the acronym that defined an industry. Microsoft’s August 2000 announcement still says it in black and white.

We saw the shift. But we imagined it organized around the platform we already had.

Incumbents don’t miss the next era. They imagine it organized around what they already built.

That isn’t a failure of intelligence. I was fortunate to work alongside countless brilliant minds in Redmond. It’s one of the consequences of success. When you have built something enormous and valuable, the next era naturally looks like an extension of it.

The customer gets the final vote.

I’ve spent two decades in SaaS. I’m not early to saying it’s under pressure.

After Microsoft I spent most of the next two decades leading B2B SaaS businesses across UX, data visualization, transportation data, and most of all media technology powering thousands of newsrooms and sites around the world.

I’ve sold the model, built it, defended it, and lived off it.

So I’m certainly not early to declaring that SaaS is under pressure. Plenty of people got there before me.

The question I find much more interesting is what comes next.

AI is making software dramatically cheaper to build. Customers are increasingly composing their technology from things they build and things they buy. Access to sophisticated software is becoming less scarce.

Value isn’t.

When those things are true at the same time, the old bargain starts to wobble. And that’s where I’d rather be early this time.

The SaaS bargain worked because software was scarce.

The bargain was simple:

We build it. You rent it. You figure out how to create value with it.

That deal made sense when sophisticated software was scarce and expensive to create. Shared platforms created enormous leverage. Nobody was wrong to rent.

Then the inputs changed.

A media company can now build an internal workflow in days that once might have required a software vendor or a significant product team. Meanwhile, in media, I see some of the largest technology bills still going to broad, relatively undifferentiated platforms. Some of those are the kinds of platforms I spent my career building.

Building got cheap. Running never did.

Build versus buy was never a philosophical question. It’s an economic one. Change the cost and time required to build and ask the question again.

The framework didn’t fail. The answer changed.

Great companies can lose while doing everything right.

One of my favorite books we studied at Wharton was Clayton Christensen’s The Innovator’s Dilemma. I appreciated the idea then. I understand it differently after spending two decades building and operating technology companies.

Cover of The Innovator's Dilemma by Clayton M. Christensen.
Clayton M. Christensen, The Innovator's Dilemma (Harvard Business Review Press). Cover shown for reference.

Christensen’s great companies weren’t simply asleep at the wheel. They could listen carefully to their best customers, improve the products those customers valued, and allocate resources rationally, and still leave themselves exposed to disruption.

That’s what makes it a dilemma.

The machinery of a successful company can make defending yesterday’s source of value the rational thing to do.

Every incentive points toward protecting what already works.

HyperContent isn’t magically immune to that. No company is. Continuous Value is our attempt to give the company permission to move when the value moves.

Value creation and value capture are not the same thing.

The second idea from Wharton is more economic, and for me just as durable: the distinction between value creation and value capture, formalized in strategy work by Adam Brandenburger and Harborne Stuart. A customer and supplier can create a pool of economic value together. The commercial arrangement determines how that value gets divided.

The value stick: willingness to pay at the top, then price, then cost, then willingness to sell. The full span is labeled value created, divided into the customer's share, the firm's margin, and the supplier's surplus.
The value-creation framework separates the value a relationship creates from the share each side captures. After Adam Brandenburger and Harborne Stuart; see Harvard Business School’s value-stick explanation.

What matters to me isn’t the terminology on the diagram. It’s the distinction.

The product is not the value. It is one mechanism for creating value.

That sounds academic until you hit a real decision.

Suppose helping a customer build something destroys a software fee but creates more value overall. A SaaS company organized around protecting that fee has a reason to resist. A company that can participate fairly in the new value has a reason to help.

Same situation. Opposite instincts.

Christensen explains why companies get trapped defending the old mechanism. Value creation and capture suggests how we might afford not to.

A composed stack beats the monolith.

Look at how a modern media technology stack is increasingly built: customer-owned code and agents, commodity cloud, specialist products, open standards and operating partners. I think of that collection as the customer’s media operating system.

And I think it should belong to the customer.

The principle we’re adopting at HyperContent is simple:

Build what differentiates you
Buy what accelerates you
Let someone run what slows you down

None of those decisions is permanent. Something you rented yesterday may make sense to build tomorrow. Something you built may become a commodity worth buying. Something easy to create may still be a terrible use of your best people to operate.

The advantage isn’t getting the split right once. It’s continuously deciding which is which.

A composed stack still needs shared contracts between the parts. For media, we’re putting that idea into practice through the Story Object Model, a common definition of the story that customer-built systems, specialist products, AI and HyperContent can share.

Continuous Value, in practice.

So what does all of this mean for how we run HyperContent?

The customer owns the stack and the decisions. Together, we agree on the outcomes that matter, find where value can be created now, choose the best way to create it, measure what actually changed, learn, and ask what’s next.

Continuous Value The relationship is continuous because the search for value is continuous.
  1. 01 Find the value Agree on the outcome that matters now.
  2. 02 Choose the means Build · Buy · Product · Expertise · Operate
  3. 03 Create & measure Deliver, then measure what changed.
  4. 04 Ask what’s next Earn the next turn by creating value in this one.
Customer owns the stack · HyperContent follows the value
  • Sometimes the answer is our product.
  • Sometimes we should help a customer build.
  • Sometimes we should help eliminate a SaaS bill, including one of our own.
  • Sometimes another specialist simply has the better product for the job.
  • Sometimes we’ll operate work that a customer’s best people shouldn’t be spending their time on.
  • And sometimes we should tell a customer to stop paying us for something because they can now do it better themselves.

For a company built to protect software revenue, those sentences are uncomfortable. For a company organized around Continuous Value, they should be rational.

The economics have to reinforce this, or it’s just a nice slogan. Where we can credibly measure the value created together, part of what we earn should be tied to it. If we grow your audience, we should benefit. If we reduce your technology bill, we should benefit. If the right answer is for you to build rather than buy from us, our business model shouldn’t stand in the way.

Outcome-based pricing isn’t the definition of Continuous Value. It’s one mechanism that keeps the partnership honest.

The relationship is continuous because the search for value is continuous.

And continuity has to be earned. The gold standard is earning the next turn by creating value in this one.

I’d rather be early this time.

Salesforce’s “No Software” campaign never really argued that software would disappear. Software became more important, not less. It attacked the commercial abstraction around it: the packaging, pricing and assumptions of that era.

I think we’re at another one of those moments. Product doesn’t need to disappear. But it can’t be the thing the company is trapped inside.

HyperContent started from one thesis:

Information shouldn’t be trapped in the form it was created in.

A story is not the page it was published on. The truth persists while its expression changes for the audience.

There’s a second thesis now, and it’s about the company:

A technology company shouldn’t be trapped in the product it happened to build.

The first is why we built HyperContent. The second is why we’re building it differently.