Project Everglades
ROLE: Product Owner / Strategy Lead
TEAM: 1x Technical Designer, 1x Senior Engineer, 1x Senior 3D Artist
DURATION: 3 months | OUTCOME: $250K contract win; adopted for AI education at the University of Central Florida
Project Everglades was a joint product initiative between Lockheed Martin and Cubic Austin to create an entertainment-first platform for drone swarm AI development and testing. The platform would enable AI engineers to compete in esports-style competitions while advancing autonomous systems research.
My role was to devlop and pitch the product strategy, making technology recommendations that balanced feasibility with ambition, and navigate a complex client relationship where technical and business priorities didn't initially align.
Cubic and Lockheed had aligned on the vision, an engaging platform for AI training, but disagreed on the path. Lockheed preferred their proprietary software stack. Cubic's technical team knew this would add four to six weeks of learning curve and integration risk to an already tight eight-week delivery window.
The core question wasn't technical preference. It was: what trade-offs are we willing to accept?
Stick with Lockheed's tooling → maximize future integration but risk missing the delivery deadline
Move forward with proven commercial tools (Unreal Engine 4) → hit the timeline but require defending the choice
As the product owner, I needed to frame this as a business decision, not a religious war about tools.
I developed a two-part communication strategy:
The Vision Deck — "What if we reimagined AI training?"
We created a high-fidelity concept video showing what an engaging AI training platform could look like: tournament mechanics, competitive leaderboards, real-time feedback, visualization of drone behavior. The goal was establishing a clear product target that both teams could rally around, rather than getting lost aesthetics.
After pitching this approach, Lockheed Martin raised concerns about our use of a commercial software product (Unreal Engine 4, or UE4) and pushed Cubic Austin to use Lockheed’s proprietary software instead. This would have put the eight-week project at risk, so this presentation was created to detail our plan and illustrate the risk to the project deadline by switching to a new technology.
We mapped the 8-week timeline in granular detail:
Learning curve for proprietary tools (2-3 weeks)
Integration testing (2+ weeks)
Iteration cycles (compressed)
Contingency buffer (none)
We showed the math: switching platforms ate up our schedule buffer and shifted risk almost entirely onto delivery quality.
The implicit argument: We can have this platform on time with proven tools, or we can use proprietary software and hope nothing breaks. Choose one.
Lockheed Martin chose the product roadmap over the tooling preference. They understood the trade-off and accepted our recommendation. We received a $250K contract award to build the playable prototype.
OUTCOME & IMPACT
Delivery: Shipped the platform on schedule, meeting all specifications.
Market Validation: The platform is now in active use at the University of Central Florida for reinforcement learning education, exactly the downstream impact we predicted. It's become a reference example for how entertainment design principles can accelerate technical education.
Strategic Lesson: The best product decisions aren't about being "right"; they're about making the trade-offs explicit, showing the consequences, and helping stakeholders choose with full information. Lockheed didn't choose UE4 because we convinced them it was cooler. They chose it because we showed them it was the only way to ship on time.
What I'd Do Differently
If I ran this project again, I'd front-load the timeline risk analysis before ever recommending a tool. Starting with "here's what we're building and when we need it by" prevents the tooling debate from becoming about preferences and keeps it centered on business constraints.