Embarcadero: When a Product Is Too Complex to Explain, Build the Experience Instead

The innovation was real. The value was hard to see.

Embarcadero had built a genuinely clever approach to enterprise software deployment. AppWave turned traditional Windows software into self-contained applications running inside virtual file systems, so organizations could distribute and manage software centrally while cutting down on installation headaches, licensing complexity, and applications fighting each other for the same system resources.

The technology solved real problems. Customers just couldn’t picture it.

And this wasn’t a case of needing a snappier description. AppWave asked people to imagine an entirely different way of buying, deploying, updating, and managing software — which is a lot to ask of a brochure. We could describe the architecture, list the benefits, and draw diagrams of how it all worked. Customers still had no felt sense of what using AppWave would be like. That’s not a messaging problem. It’s an experience problem, and you can’t write your way out of an experience problem.

Reframing the challenge

The obvious question was “how do we explain AppWave more clearly?” The better one: how do we let customers experience the value themselves?

That changed the whole initiative. Instead of another deck or demo, we built a working proof-of-concept marketplace — a place where customers could discover, buy, and launch real software through AppWave. It would make the value visible. Just as importantly, it would let us watch how people actually responded and use that to improve the product, the positioning, and the commercial strategy. We weren’t building it to promote AppWave. We were building it to learn what AppWave should become.

Building the proof of concept

My team built a full app store demonstrating how software could be packaged, distributed, purchased, and managed through AppWave. We partnered with a range of independent software vendors to stock it with a deliberately messy variety: small utilities, business applications, big office-productivity suites, games, free tools, and commercial products.

The variety was the point. We didn’t want to prove AppWave worked under lab conditions with one tidy category of software. We wanted to stress it against applications with wildly different requirements, complexity, licensing structures, and use cases. Every app we added was another chance to test the platform and expose its weak spots. The store was a customer demo and a product-validation environment at the same time.

Turning an abstract concept into a concrete journey

The experience let customers understand AppWave by doing rather than imagining. They browsed, picked what they needed, bought it, accessed it through AppWave, and felt the deployment get simpler. No one had to master the underlying virtualization architecture. They just got the outcome: less time installing software, fewer desktops to babysit, simpler updates, more centralized license management, fewer application conflicts, and faster access to the tools people actually needed.

One enterprise engineer put it better than any of our materials did:

“AppWave saves time; I’ve gained hours back into my week.” — Randy Zickert, Allianz Global Investors Capital

AppWave wasn’t valuable because application virtualization is technically impressive. It was valuable because it gave people their week back.

Building the commerce layer

Under the hood, the proof of concept ran on a PHP and MySQL backend paired with a heavily modified Magento storefront, which gave us room to build a dynamic marketplace across many kinds of applications and transactions.

We also had a commerce problem to solve. Customers expected buying to be fast and convenient, but we needed a secure way to handle repeat transactions. I negotiated an agreement with a third-party payment processor and helped build a flow where the provider handled the actual transaction while the platform kept a customer token — enough for a one-click purchase without making people re-enter their payment details every time. That was more than a usability nicety. It proved AppWave could support not just deployment but the whole commercial experience around discovering, buying, and accessing software.

The prototype was a learning system, not a demo

The marketplace wasn’t built to confirm we’d been right all along. It was an experiment, and every part of it answered a different question. Could a wide range of applications actually be packaged? Where did software vendors get stuck? Did customers understand how to access what they bought? Which benefits landed hardest? Where did the experience create friction? Which segments saw the most value? And the big one: was the real opportunity internal deployment, external commerce, or both?

Customer behavior surfaced problems that internal planning never would have. We got to observe the product in context instead of grading it against a technical spec, and that told us how to improve AppWave’s functionality, usability, and positioning. Marketing wasn’t standing by waiting for the product to finish so it could wrap a story around the result. The marketplace fused product development, customer experience, market research, and messaging into one continuous loop.

Letting the market reshape the strategy

The original vision was a broad marketplace offering software from many vendors. Our work confirmed the technology had real value — and revealed that the opportunity wasn’t limited to that one model. So rather than force the product into its original story, we used what we’d learned to pursue two sharper paths.

Enterprise software deployment. The first was using AppWave to distribute, license, and manage Embarcadero’s own software inside enterprises: centralized management, simpler deployment, easier license administration, less desktop maintenance, faster access, fewer conflicts. These customers weren’t shopping for an app store. They wanted a more efficient way to manage enterprise software. The marketplace helped us see that difference clearly.

White-label app stores. The second was offering customizable app stores to large ISVs and telecom companies, who could build branded software marketplaces inside their own ecosystems. That turned AppWave from a single Embarcadero store into an enabling platform other companies could run for their own customers.

Same core technology, two distinct needs: internal enterprise application management and external software commerce. The proof of concept didn’t just validate a product. It revealed a portfolio of options.

The adaptive marketing lessons

The AppWave initiative illustrates several principles at the center of The Adaptive CMO.

Confusion is a market signal. When customers keep failing to understand a product, the instinct is to rewrite the message. Sometimes that’s the fix. But persistent confusion often means something deeper — you’re asking customers to make a big conceptual leap without giving them enough to stand on. The trouble explaining AppWave told us another brochure wouldn’t cut it.

Demonstration can outperform explanation. Complex products tend to get marketed with increasingly complex descriptions, which usually makes things worse. The store translated AppWave from an architecture into a sequence of recognizable actions: find software, buy it, use it, manage it. The experience became the explanation.

Research should change what you do. Findings aren’t valuable on their own. They’re valuable when they change the product, positioning, experience, or investment. We collected feedback while customers used a live system, then acted on it — improving the platform and rethinking the opportunity.

Build to learn, not just to launch. The proof of concept wasn’t a shrunken version of a predetermined product. It was a machine for reducing uncertainty. Its most valuable output wasn’t the store. It was what the store taught us.

Product and marketing need a shared loop. Marketing couldn’t write a real AppWave narrative apart from the product experience, and the product team couldn’t fully judge the technology without seeing how customers and vendors reacted to it. Feedback improved the product, the product’s behavior improved the positioning, the positioning shaped the experience, and the experience generated new feedback. Each part made the others smarter.

Customer value isn’t the same as technical capability. AppWave’s engineering was sophisticated, but nobody buys sophistication. People valued saved time, easier deployment, less maintenance, and more control. The strongest positioning showed up the moment we translated capability into operational impact — which is really just asking, over and over, what does this let the customer do better?

Strategy should evolve when the evidence does. The prototype revealed two viable opportunities where we’d expected one obvious path. An inflexible organization would have kept forcing the technology into its original model. Changing direction in response to evidence isn’t a failure of strategy. It’s the entire point of having an adaptive one.

The lasting lesson

AppWave started as a communication challenge and became an exercise in product discovery, customer research, experience design, and business-model development. By building a working marketplace, we gave customers a way to understand the technology without decoding its architecture — and gave the company a way to learn. The prototype exposed friction, clarified value, improved the product, sharpened the positioning, and uncovered two routes to market.

That’s what adaptive marketing looks like applied to product innovation. It doesn’t polish a narrative and then defend it against inconvenient evidence. It builds an experience, listens hard to the market, and lets what it learns decide what happens next.