There was a prototype, a handful of rough drawings and a category of business software that seemed to have misplaced its sense of time. Product lifecycle management systems knew how to preserve engineering records, but too often behaved like museum cases: expensive, carefully sealed and awkward to change. Ray Hein thought the category belonged in the cloud. An investor named Matt Holleran thought the idea was promising. But before money followed enthusiasm, Holleran wanted an architect to inspect the wings.
The architect was Ron Hess. Hein later recalled Holleran's condition with the blunt economy of a startup fable: speak to Hess, and if Hess said the thing could be built, the investor would find the money. Hess had spent years inside Salesforce and then at Kenandy, helping construct cloud enterprise resource planning software on the same platform. He understood both the seduction of a grand diagram and the spiteful little details that wait beneath it.
Hess and Hein spent roughly two weeks validating the premise. Then Hess left his job. What followed came in similarly brisk blocks: incorporation, a term sheet, early employees and the first capital. Propel formally launched on April 22, 2015. The company was not born from one lightning strike so much as a string of small permissions, each earned before the next was requested.
“If he says you can build it, I’ll fund it.”The condition investor Matt Holleran gave Ray Hein, as Hein later recounted
The useful kind of evangelist
By then, Hess had accumulated an unfashionably useful career. He earned a computer science degree from California State University, Chico in the late 1980s. He worked in escalation management at Santa Cruz Operations, the Unix company known as SCO, then moved through program-management roles at Chromatic Research and Lightspeed Semiconductor. At Neoforma, an internet marketplace serving hospitals and suppliers, he managed CRM programs. The job titles changed because the technology business was changing beneath them.
Salesforce brought those strands together. Across more than seven years, Hess worked in product management, developer evangelism and Force.com architecture. “Evangelist” can sound like a job for a microphone and an optimistic slide deck. Done properly, it is translation under pressure. A developer needs to know not merely what a platform promises, but where it bends, what it refuses and how a working system can emerge from those boundaries.
At Kenandy, Hess became principal application architect, working on a generation of ERP built on Salesforce. By the time Hein arrived with the PLM proposal, Hess knew the terrain from both sides: the underlying platform and the enterprise applications constructed above it. His answer carried weight because it was not faith at all. It was informed risk.
A wager against the upgrade weekend
The founding wager was architectural but also social. Traditional PLM lived close to engineering, often on premises and behind specialist interfaces. Propel proposed placing product information on the Salesforce platform, where it could connect with the customer and commercial data used by sales, service and marketing. The ambition was to let more of a company participate in the life of a product, from its first definition to what happened after somebody bought it.
This was not an obvious proposal in 2015. Ross Meyercord, who would later become Propel's chief executive, has written that his first response was skepticism: why cloud PLM, and why on Salesforce? Years later, the oddity has faded. Cloud delivery is ordinary. Connected product records are a familiar aspiration. That is the trouble with good infrastructure bets. Once they work, they rearrange memory and make the earlier world look needlessly quaint.
The business grew around that bet. Propel announced a $4.2 million financing round in 2016. In 2018 it announced an $18 million Series B and said the previous fiscal year had brought more than 500 percent revenue growth and a 300 percent increase in customer count. Those figures belong to the company, not to Hess alone. But they measure the distance traveled from the moment an investor asked whether the product was technically possible.
Propel also widened its language. The company connected PLM with product information and quality management, trying to stretch the “product thread” beyond engineering. In late 2022, Meyercord took over as CEO and publicly thanked Hess and Hein for the vision that had brought the business to roughly 200 customers. In 2023, Propel announced that Hess was moving from chief technology officer to chief architect. The new title sounded less like a promotion than a return to the question that started everything: what should be possible next?
Architecture as an offer, not an ambush
Hess's published writing reveals a consistent concern with choice. In an essay on release cycles, he contrasted the disruptive upgrade rituals of traditional enterprise systems with software that arrives ready to adopt. Sandboxes allow customers to test. Permissions allow a small group to try a feature. Feature flags announce what is changing. A company can pull an update when its regulatory or operational schedule permits, or accept a push when speed matters more.
The prose is technical, but the principle is almost domestic: do not rearrange somebody's house while they are asleep. Enterprise software governs jobs, approvals, audits and the record of how physical things are made. A surprise is not delightful simply because a release note calls it an improvement.
Ways to make change less theatrical: test it in a sandbox, limit it with permissions, and expose it with a feature flag. Hess's release model gives customers a choice about when novelty becomes reality.
He made the same argument from another angle when writing about IT leadership. If IT departments spend their days maintaining integrations and extinguishing application fires, they have little time to shape revenue, resilience or customer experience. Unify enough of the system, he argued, and technical leaders can move from custodianship toward strategy. The architect's craft is therefore not the worship of architecture. It is the removal of unnecessary work from everyone else's calendar.
There is a revealing continuity here. The escalation manager of the late 1980s dealt with systems at the moment they disappointed somebody. The later architect tried to prevent disappointment from becoming routine. Between those roles sits a lifetime of enterprise software learning the same lesson at greater scale: complexity never disappears. It is either absorbed thoughtfully by the people building the system or passed, with interest, to the people using it.
“People that bring us the strongest objections are the ones that appreciate fast, flexible, feature-rich release cycles the most.”Ron Hess on reluctant users and responsive software
That sentence contains a modest theory of product development. Objections are not noise to be defeated by training. They are information. A “sticky wheel,” in Hess's phrase, may identify the exact place where a system has ignored the people expected to use it. Answer the objection quickly, and resistance can become advocacy. An architect who listens for friction is designing not only a database but a relationship.
Reading invisible forces
Propel's official biography supplies one wonderfully specific personal detail: Hess is a licensed glider pilot. The fuller logbook is better. He has flown gliders around Truckee for roughly 30 years, holds a single-engine land pilot license and serves as president of the Truckee Tahoe Soaring Association. Before enterprise clouds occupied his days, he flew foot-launched gliders in the 1985 U.S. Nationals. It would be too neat to claim that flying explains his architecture. Lives do not arrange themselves for the convenience of metaphors. Still, the two disciplines share an appealing respect for invisible forces.
A glider pilot cannot ask an engine to correct every poor choice. Lift must be found in air that looks like ordinary air. Altitude is stored possibility; weather is architecture with opinions. The pilot works within conditions rather than pretending they do not exist. Building on a platform is a similar act of chosen dependence. The limits are real, but so is the lift.
Hess has written across the fashionable vocabulary of modern manufacturing: digital twins, blockchain, supply-chain technology and the evolving place of IT. His tone tends to pull the grand term back toward a working process. Blockchain becomes a ledger whose participants validate change. A digital twin becomes useful when it connects information across a product's life. The future, under inspection, is usually a set of records that the right people can trust at the right moment.
That practical instinct is the lasting interest in his story. Hess was present for several revolutions in computing, from Unix workstations and specialized chips to software platforms delivered continuously through the cloud. He did not need to predict every turn. He learned the systems well enough to recognize when an old category could catch a new current.
A decade after Propel's launch, the founding drama remains pleasingly small. A prototype. Two coffee meetings. Two weeks with an architect. A resignation. A check. This is how large systems sometimes enter the world: not with certainty, but with one person whose experience makes a particular uncertainty bearable.