When Grayson Omans, founder and CEO of Phoenix LiDAR Systems, described the company’s transition into its next chapter following the Revolution Geo Systems acquisition, he did not sound like a man delivering a polished exit line. He sounded like someone who had spent years living inside the pressure of building a company and was finally ready to hand off the parts he liked least. “I didn’t just hand them the keys,” he said. “I threw the keys at them.”

The line is funny, but it is also revealing. In one sentence, it captures fatigue, trust, relief, and the deeper logic of the deal: this was not a disappearance, but a refocusing. Grayson made clear that he would stay close to product strategy and the gaps he still wanted to solve, while the day-to-day trench warfare of leadership would shift elsewhere. 

That distinction matters because the acquisition is not the real story here. The real story is why Phoenix became worth acquiring in the first place. In the interview, the assignment was framed explicitly as a foundational piece about Phoenix’s role in “establishing the market,” and that turns out to be exactly right. Phoenix did not merely build sensors and payloads for a new category. It did not arrive here by becoming larger than its category; it got here by helping invent one. Phoenix helped teach the market what integrated LiDAR could look like in practice—how it could be flown, how it could be processed, how it could be trusted, and eventually how it could be moved across platforms as customer needs expanded. This is not just a startup survival story. It is a market-making story. 

It is also a story that only really makes sense when its three principal voices are understood in relation to one another. Grayson Omans is the gap-spotter, the product mind who saw a market opening before it looked commercially sane. Ben Adler, co-founder and CTO, is the systems builder who had already been living inside the problem long before Phoenix existed as a business. Rob Dannenberg, president of Phoenix LiDAR Systems, is the market witness turned scaler—the person who first understood Phoenix from the outside and later helped translate its support culture and workflow discipline into a broader operating philosophy. From the start, that triad matters: Grayson saw inevitability before feasibility; Ben turned improbability into working systems; Rob became the customer’s view of Phoenix as a company that could teach, support, and scale what others were still treating as experimental. Together, they show how categories actually get built: not through one heroic insight, but through repeated collisions between vision, engineering, and customer reality. 

Founding: Foresight Before Feasibility

Phoenix’s origin begins with what looks, at first glance, like a small and almost comic trigger. At the time, Grayson was working in Irvine in product management at Bosch, and he describes that background as the place where he learned to “fill gaps, find gaps, find needs.” Then came the moment that set everything else in motion: a sushi chef told him that his brother had a drone capable of flying a DSLR camera. Grayson’s immediate reaction was disbelief. Cameras were expensive. Drones crashed. The idea sounded reckless and impractical. But when he saw the platform actually holding the payload steady, his thinking jumped far beyond aerial photography. Hollywood video, he figured, would become crowded and commoditized. LiDAR was different. If valuable optical payloads could now be flown reliably, then airborne LiDAR at much smaller scale was not a fantasy. It was a coming market. 

That leap is important because it shows what Grayson was really doing. He was not simply getting excited by a new toy. He was applying a product manager’s instinct to a technological inflection point. Later in the interview, he would describe the opportunity as “inevitable,” and that word matters. Phoenix was not born out of an abstract interest in drones. It was born out of the conviction that airborne LiDAR would miniaturize, democratize, and open a new set of commercial workflows. The problem, as Grayson also admitted, was that inevitability and viability are not the same thing. “It’s easy to make a prototype,” he said. “It’s incredibly hard to make a commercially viable product.” Phoenix would spend the next decade learning just how wide that gap could be. 

Ben had arrived at that same future from the opposite direction. In Hamburg, he was working in robotics and computer science, dealing with localization, path planning, navigation, and the messy limitations of early sensing systems. He had already built an octocopter around a small scanner and a navigation stack assembled from parts that had to be soldered together by hand. In his account, almost everything about the machine was rough. Latency was high. The vehicle did not hover cleanly. Navigation was unstable. Hardware interfered with GPS. The platform itself looked improvised enough that his username—kernel panic—felt like an appropriate emblem. But the significance of that period is not that it produced a clean product. It is that Ben had already done the hard thinking required to understand what it meant to generate point clouds from a flying robotic platform. Where Grayson saw the market gap, Ben understood the technical pain buried inside it. And later, as Phoenix evolved from payload experiment to integrated platform, that same engineering mindset would help turn a loose collection of components into something much closer to a workflow architecture. 

The true founding moment of Phoenix was not a formal launch. It was an email. Grayson saw Ben’s YouTube video and reached out in late 2012. Ben almost did not answer. He remembers sitting with the drafted response and recognizing that if he sent it, there would be “no exit.” If the work succeeded, there would be no easy way to treat it as a side project and move on. That small hesitation says a great deal about how serious the opportunity already felt to both men. Grayson had seen inevitability before feasibility. Ben had already lived feasibility before usability. Phoenix began at that intersection—when foresight met technical stubbornness and both sides recognized that the idea was large enough to become a company. 

Demo Years: Turning Impossibility Into Public Plausibility

The years that followed were not elegant. Phoenix was bootstrapped, improvised, and often held together by determination more than polish. Grayson funded the effort in part through Brushless Gimbals, which he ran in parallel as a way of generating cash while Phoenix found its footing. At one point, the company operated out of his home, with employees working from his living room and into what was supposed to become his son Liam’s bedroom. His pregnant wife, he recalled, eventually told him to get the whole operation out of the house. That image matters because it strips away any illusion that Phoenix emerged from a polished innovation pipeline. This was a company assembled under pressure, with roughly $100,000 tied up in demo equipment and no real institutional buffer against failure. 

Within that chaos, the early demo years did more than produce colorful war stories. They became the period when Phoenix began teaching the market how to see itself. Nowhere is that clearer than in the San Diego Chargers stadium demo with Wolfgang Juchmann, then Director of Sales and Marketing at Velodyne LiDAR, and the HDL-32, the first great Phoenix story because it contains almost everything that would define the company’s early life. 

Velodyne mattered enormously in that period. The company was still broadly associated in some circles with another realm of technical obsession altogether: high-end audio. Its reputation had been built in part on subwoofers that used real-time feedback to reduce distortion so dramatically that they became a benchmark among home-theater enthusiasts. That lineage is worth keeping in view because it tells you something essential about Velodyne before LiDAR ever enters the scene. This was not a me-too electronics brand. It was an engineering-driven company with a habit of pushing precision and control into places where markets had not yet fully caught up. By the time Velodyne’s multi-beam sensors became central to the emerging autonomous-vehicle ecosystem, the company had already established itself as a real innovator. And that, in turn, makes Grayson’s outreach more revealing. Phoenix was not asking a generic parts supplier for help. It was asking one of the most technically consequential sensor companies of the era to entertain what, at the time, still sounded like an insane proposition: hoisting a very expensive LiDAR sensor onto a drone. 

That context sharpens the meaning of Wolfgang’s presence. Velodyne was looking hard at automotive. The company’s sensors were increasingly associated with self-driving programs, advanced mobility, and the future of machine perception on the ground. Drone-borne LiDAR was not the obvious commercial priority. So Wolfgang’s appearance at an early Phoenix demo was not a casual favor. It was a moment of curiosity—and cautious skepticism—from a company effectively sitting at the center of the emerging LiDAR market. Wolfgang physically brought the Velodyne unit himself because he was, as Grayson put it, “super sketched out” about letting a young company take it into the field. The aircraft was home-built. The integration was fragile. The timing was bad. “It was pure chaos,” Grayson recalled. At one point, while the system was misbehaving, Wolfgang left for the gas station. While he was gone, the demo finally started working. Phoenix got one pass in the air, crashed into a bush, recovered the aircraft, bent the LiDAR back into place, and still managed to come away with enough data to make the point. 

Later, when Wolfgang presented the result publicly, the audience reaction was immediate. “Everybody’s jaw dropped,” Grayson said, and he described Juchmann receiving a standing ovation in San Jose. That moment was not just a crazy early demo. It was when Phoenix turned impossibility into public plausibility, in front of one of the companies most responsible for shaping how the market thought about real-time 3D sensing. Supplier skepticism, fragile integration, physical failure, recovery, public proof, and market reaction all lived in the same scene. The point cloud did not just validate a prototype. It allowed the industry to imagine, for the first time, an entirely different kind of workflow—drone-borne LiDAR that could cover complex environments quickly enough to matter. 

From Payload to System: Discovering Workflow as the Product

If the Chargers story was about making the impossible look plausible, the living-room and hand-wired years were about discovering what Phoenix was actually building. On the surface, those months read like a cascade of technical failures: Linux drivers that would not work, board designs that failed in practice, an auto-routed PCB that turned into a maze of shorts, hardware that smoked on the eve of demos, and cables that Ben had to route by hand when the boards could not be trusted. Grayson cycled through engineers who, as he put it, looked good on paper but “couldn’t do jack squat.” Navigation assumptions hurt too. Phoenix heavily promoted real-time solutions because they looked magical in the field, but behind that promise sat fragile communications links, patchy corrections, and an underdeveloped appreciation of how much simpler post-processing might have made life. 

Seen as a list, those stories sound like startup pain. Seen as a pattern, they mark the period when Phoenix realized it was not building a payload; it was building a system. The real R&D work was not just flying LiDAR. It was integrating navigation, communications, drivers, boards, and data logic into something that behaved coherently enough for customers to trust. Ben’s contribution here was especially important. He was not only solving isolated technical failures. He was helping give Phoenix the internal logic that would later define its software and workflow architecture. The product was not a box bolted to an aircraft. The product was workflow coherence—an end-to-end chain that took customers from mission planning through acquisition to data they could actually use. In those improvised rooms, Phoenix was quietly defining what “integrated” would have to mean for the category it was helping to invent. 

Making Value Visible: Teaching Customers to See

The same logic shows up in the field demos that followed. Some of the messiest stories in the interview are also the most important because they reveal how Phoenix learned to make value legible, not just technically correct. There is the Anaheim parking-garage demo beside Hooters, where a customer wanted the system to resolve a fence wire cleanly enough to count as a pass. There is the now-famous line that the customer did not have his glasses, which may have helped. What matters is not the humor. What matters is that Phoenix was discovering, in full public view, the difference between a seductive concept and an operational system. 

One breakthrough was not a sensor but a way of showing value. Phoenix discovered early that real-time point clouds had enormous rhetorical power. People loved watching the aircraft, but when the point cloud appeared live on a screen, the meaning of the system became obvious almost instantly. Grayson describes this as “magic,” and from a sales standpoint it was. In one later demo, the point cloud mirrored the vehicle’s turns in real time, and the reaction in the room was immediate—something close to holy shit. Once people could see both the platform and the data at the same time, the pitch became radically simpler. This was not just technical theater. It was category education: Phoenix teaching customers, many of whom were still used to collecting one point at a time, what a modern integrated workflow could feel like. The company was learning that it would not be enough to be right technically. It also had to make the value visible quickly enough for customers to understand what had changed. 

Those early customers were not just buyers. They were co-validators. The first sale, Ben admitted, felt like a miracle—someone believing enough to write the check even when the product was still rough around the edges. In practice, those customers helped Phoenix learn where the workflow broke, which assumptions failed in real use, and what mattered most to actual jobs in the field. They were the bridge between spectacle and trust, turning wow moments into repeatable expectations. 

Following Workflow, Not Platform Hype

As Phoenix matured, the questions shifted. The company moved from proving that drone-based LiDAR could work at all to deciding what it wanted to be inside the larger market it had helped create. The APS job in Arizona captures that middle period well. The team flew a Vapor 55 with a serious IMU package. The immediate output looked questionable. Two weeks later, the post-processed trajectory snapped together. That swing—from field doubt to delayed coherence to durable confidence once the whole chain held—captures the stage Phoenix had entered. It was no longer just proving possibility. It was proving that the workflow could become reliable enough for buyers to trust under real operating conditions. 

If one product marks the point where Phoenix moved from raw invention into something like scalable business, it is mini bucks. In Phoenix’s own telling, mini bucks was both a market enabler and a survival tool. It arrived at a time when Velodyne shortages were stretching delivery windows to eight months. Without an alternative path through Riegl and mini bucks, Grayson says Phoenix might not have stayed in business. That claim is significant. It means mini bucks was not simply a successful product SKU. It was the bridge between category excitement and commercial continuity. At the same time, it widened the customer base because it better matched what many users actually needed. In that sense, mini bucks also marks a strategic maturation: Phoenix was beginning to scale not around what looked most technically dramatic, but around what made the most sense for real users. What mattered was whether the data was accurate, usable, and tied to a workflow customers could sustain. 

By this point, Phoenix was also confronting a different sort of pressure: scale as a supply problem rather than an invention problem. Grayson points to the moment when Riegl throttled product volume as the point he realized Phoenix could have scaled faster if enough units had been available. That is a fundamentally different challenge from getting something to work at all. It is the challenge of a company that has moved from proving the category to participating in it at meaningful volume. It also forced Phoenix to ask a harder question about its own identity. Was it, in fact, a drone LiDAR company? Or had that label already become too narrow? 

The answer emerged gradually, and with some frustration. Phoenix had long been seen primarily as a drone LiDAR company because that is where it first made its name. But the company’s internal logic had already begun to move beyond that. The TerraHawk VTOL effort revealed where Grayson believed the industry should go: longer endurance, wider coverage, lower-risk economics, and less dependence on the limitations of short-range drone operations. What prevented that from becoming the immediate center of the business was not a lack of technical ambition. It was regulation. Grayson is blunt on the point. “The tech is there and we’re ready,” he said. “It’s just the regulation.” Rather than wait for policy to catch up, Phoenix adapted. It moved into airborne solutions, transferable pods for Cessnas, R44 mounts, and then increasingly serious mobile systems. 

That move is best understood not as a retreat from drones but as a clearer expression of what Phoenix had been all along. The company’s real loyalty was never to a single aircraft type. It was to the customer’s data-collection problem. Grayson distilled that logic in one of the interview’s best lines: “drive when you can, fly when you must.” He also admits that Phoenix had done a poor job of telling that story clearly enough. Internally, perhaps 80 percent of customers were already using multi-platform workflows. Externally, many still saw a “drone company.” The rebranding push around drone, airborne, and mobile was therefore less a reinvention than an overdue clarification. As Phoenix put it later and more forcefully: “We are the LiDAR integration company.” That line matters because it describes not just a marketing position, but the company’s mature self-understanding. 

Rob’s Lens: Trust, Stickiness, and Scale

This is where Rob Dannenberg, president of Phoenix LiDAR Systems, becomes indispensable. Because he did not found the company, he can explain Phoenix in customer terms rather than founder terms. Before joining, he had already formed a very specific impression of Phoenix from the outside. If someone was entering the space and did not know what they were doing, he would tell them to “give Phoenix a call,” because Phoenix was uniquely good at “hand-holding” users through how to acquire data, not merely how to process it. That distinction is crucial. A great many vendors, he argues, would show users how to run software after collection but would not really teach planning, acquisition, and the operational sequence that made success repeatable. Phoenix did. That is a strong explanation for why the company built so much loyalty without always looking, from the outside, like the flashiest player in the room. 

Rob also offers the clearest articulation of why Phoenix’s software and support matter. He says roughly 95 percent of customers stay in the Phoenix software ecosystem, a remarkably high adoption rate in a field where hardware and software often fragment quickly. He credits that to several things at once: training, responsiveness, a lower barrier to entry, and what he calls a workflow-first philosophy that carries across UAS, mobile, and airborne collection. Ben, describing the product side in his own stripped-down language, says the ambition is simply “to make it not suck.” Beneath that modest phrasing lies a sharper point: in a sector where expensive systems can still feel awkward, fragmented, and oddly hostile to users, coherence itself becomes a competitive advantage. Phoenix’s software and support culture are not add-ons. They are part of the product. 

That support culture is not sentimental. It is strategic. Rob says one of the strange things about the LiDAR market is that many customers have been trained not to bother offering feedback, because they assume no one will listen or respond anyway. Phoenix tried to reverse that pattern. Customers coming over from other ecosystems were surprised that the company actually wanted to know what they were trying to do, not simply what box they might buy next. Rob recalls one 3,000-person engineering firm telling him it had never felt more cared for by any vendor it had worked with. He also describes a market that is “hungry for somebody willing to step in and listen to them.” Those are not small claims. They point to a different theory of scale. Phoenix did not scale by pretending every customer needed the same answer. It scaled by listening closely enough to keep adapting the answer without losing coherence. 

For Rob, that is what Phoenix was really selling in its middle years and beyond. Not a single platform, but the promise that the workflow would eventually make sense—that the customer would not be left alone somewhere between hardware, software, and field reality. That perspective is what makes his role in the current transition so important. He is not simply the next executive in line. He is the clearest embodiment of how Phoenix came to be experienced by the market itself. 

Next Phase: Modularity and Role Specialization

That may be why the Revolution acquisition feels, at least from the outside, less like a sale and more like a concentration of strengths. Grayson goes back toward product strategy and the customer gaps he believes the company still needs to fill. Ben continues deepening the software and workflow architecture. Rob takes on the challenge of operational scale—what he sums up as “more of the same, just more of it.” That phrase is deceptively simple. What Phoenix is really trying to scale is not just hardware volume. It is a whole operating philosophy: integrated workflows, platform flexibility, support that users actually feel, broader support for non-Phoenix hardware, rental and upgrade paths, and a clearer message that Phoenix is built for the small and mid-sized firms trying to stretch one investment across multiple collection modes. 

In one sense, Phoenix’s history contains all the expected startup ingredients: chaos, improvisation, broken hardware, impossible demos, late nights, supplier skepticism, and a long chain of near-failures that had to be converted into momentum. But the more important lesson is larger than entrepreneurial endurance. Phoenix mattered because it kept aligning three things that rarely stay aligned for long: technical possibility, customer workflow, and market trust. It saw the gap before the market was ready to name it. It suffered through the engineering required to make the opportunity real. Then it widened its own identity when customers’ actual needs outgrew the category label that had first given the company visibility. 

What makes the ending of this story optimistic is that Phoenix no longer has to prove the category exists. It has moved beyond that. The opportunity now is to refine the thing it built hardest in the first place: an integrated, intelligible workflow that gives customers more ways to work without forcing them to abandon the systems they trust. Rob’s language for that future is direct and hopeful: “the market is hungry for somebody willing to step in and listen to them.” Ben’s is drier, but it points to the same horizon. From his side, the task is to keep making the workflow coherent enough that it does not “suck.” One quote speaks to empathy, the other to execution. Together they sound like exactly the right note on which to leave Phoenix: a company that helped invent a market and still sees room—plenty of room—to make it better.