I don't fit problemsto solutions.I find the real one.

The problem

Project Ares is Circadence’s cyber-range training platform. Cyber operators use it to train as defenders and analysts for government and private organizations. The ask was a new generation of the platform.

The real problem

Two constraints capped growth, and a new version number fixed neither:

• Content was bottlenecked on specialists. A realistic range includes virtual machines, containers, simulated traffic and users, and automated adversaries. Building a custom one took roughly two to four weeks of range-engineer time, and there were never enough range engineers.
• The strictest buyers couldn’t say yes. Many government and defense customers can’t run training on a shared cloud, so a cloud-only product was out of reach for them however good it was.

Architecture

Gen3 platform. A cloud-native rebuild on Azure that can also be deployed on-prem or fully air-gapped. Ranges combine VMs and containers orchestrated on Kubernetes, simulated network traffic and user activity, and automated adversaries. Everything is provisioned as code with Terraform, and images and configuration are built with Packer and Ansible, so the same range deploys the same way in the cloud or inside a closed network. Gen3 is multi-tenant, has a new web client for learners and instructors, and has much deeper telemetry and reporting.

RangeGPT Studio. The pipeline from a plain-language prompt to a deployable range:

1. Promptplain language
2. Scenario specLLM + RAG
3. Infrastructure as codeTerraform / Ansible
4. Validationautomated checks
5. Human reviewrange engineer
6. DeployAzure or air-gapped

The retrieval layer grounds each scenario in MITRE ATT&CK and CVE data, Circadence’s library of proven scenarios, the certification curriculum, and the customer’s own network topology. Tasks are routed across multiple models, balancing cost and quality and keeping deployments that must stay inside a closed network self-contained.

Decisions I made

• Keep a human in the loop. RangeGPT could have deployed straight from the prompt. I kept a range engineer’s approval as the final step, trading some speed for the trust government buyers need before anything runs on their network.
• Put air-gapped deployment in Gen3 scope. Building it added cost and complexity, but without it the strictest, highest-value buyers were out of reach.
• Ground RAG in the customer’s real network. Generic ranges teach generic skills. Using each customer’s own topology as context means operators train against the environment they actually defend, which also made demos land.

Curriculum and UX

Gen3 introduced a certification-based curriculum with dedicated AI modules. They cover AI security as well as fundamentals such as setting up MCP servers and how RAG works. Telemetry maps what learners do to skills and certification objectives, so instructors and commanders get readiness reports, not just completion rates.

The hardest UX problem was a tension at the core of the product. Scenarios have to demand real critical thinking, problem solving and hands-on tool knowledge, or they don’t train anyone. They also have to support learners who need help at every step, without handing over the answers. We designed layered support that keeps the challenge intact for experienced operators and gives newer ones a path through.

How we built it

I brought AI-native practices into the team’s development process: AI coding assistants with shared conventions, AI-drafted requirements and acceptance criteria, and AI-generated tests. The biggest change was AI prototyping for UX. We put working prototypes in front of users during discovery, so questions about product fit and design got answered before engineering committed to a build.

My role

As Group Product Manager, I led a cross-functional team of roughly 10–25 people across product, engineering, design and range engineering. I owned product strategy and the Gen3 scope. On the commercial side, I ran live demos for government buyers, shaped the product and technical sections of proposals, and trained the sales team.

Results

• Took Project Ares Gen3 from 0→1, deployable in the cloud or fully air-gapped
• Helped secure $20M+ in government contracts through product strategy, demos and proposals
• Contributed to $500K+ in new client and partner revenue through GTM and sales enablement
• Cut custom scenario builds from ~2–4 weeks of specialist time to hours, with review included
• Instructors and sales engineers can now build ranges, including custom demo ranges for each prospect

What I’d do next

Self-serve at scale. Let customers generate and validate their own ranges in RangeGPT Studio, with automated validation covering routine scenarios and human review saved for the riskiest ones. That turns scenario creation from a service Circadence delivers into a capability customers own.

The problem

Hanging Valley builds custom enterprise software for sales, marketplace and payments businesses. On this project, reps were losing deals to their own tools, not to competitors. They couldn’t see when a deal stalled or a price changed until it was too late to act.

The real problem

The data existed, but it was spread across four places that didn’t talk to each other: on-prem SQL Server databases, an ERP and billing system, Dynamics 365, and the spreadsheets reps exported and stitched together by hand. Every answer a rep needed took assembly. Better dashboards wouldn’t fix that. The fix was one trustworthy source of data, delivered to where reps actually work, which is their phones.

Architecture

1. Legacy sourcesSQL Server · ERP · CRM
2. SyncPower Automate flows
3. Data hubDataverse
4. Mobile appPower Apps
5. Insightrole-based Power BI + alerts

Power Automate flows pull from each legacy system into Dataverse, which becomes the single hub for customer, pipeline, pricing and inventory data. The legacy systems stay in place and keep doing their jobs. On top of the hub sit a mobile-first Power Apps client and role-based Power BI dashboards. The same flows fire push alerts when something a rep needs to act on changes: a deal stalls or moves stage, or inventory or pricing shifts under an open quote.

Decisions I made

• Mobile first. Reps sell from the road, not from a desk. We designed for a phone screen and a thirty-second glance first, then scaled up to desktop.
• Role-based views. A rep, a sales manager and an executive need different answers from the same data. Each role sees only what it acts on, which kept the app simple and kept adoption high.
• Wrap the legacy stack instead of replacing it. Migrating the SQL, ERP and CRM systems would have taken far longer and put daily operations at risk. Integrating in place got value to reps quickly.

Trade-offs

Building on the Power Platform let a small team ship quickly on the client’s existing Microsoft stack. The cost was scale: flow-based syncing is simpler to build than an event-driven pipeline but has lower ceilings on volume and speed. That was the right trade at this size, and it’s the first thing I’d revisit as usage grows.

My role

As Product Lead with a team of about 3–6 people, I owned the product end to end:

• user research with the sales org;
• prioritization;
• planning the integration with each legacy system;
• pushing for a mobile-first design;
• keeping sales, IT and leadership aligned.

Results

• 40% shorter sales cycles
• 15% higher close rates
• 90%+ adoption within three months
• $1.2M in annual cost savings

What I’d do next

Replace the flow-based sync with an event-driven pipeline (change data capture from the legacy systems into a streaming layer). Alerts would arrive in seconds rather than on a flow’s schedule, the system would scale past the Power Platform’s limits, and it would lay the groundwork for AI-driven recommendations for reps.

The problem

An online-wallet and alternative-payments platform was carrying risk on several fronts at once:

• vulnerabilities in its legacy databases;
• compliance obligations across regions (GDPR, CCPA, PCI DSS);
• a patchwork of on-prem SQL, Azure and Dynamics 365;
• fraud detection that flagged too many good customers and missed too many bad actors.

The real problem

Every stakeholder wanted their risk fixed first, and each fix depended on the others. Fraud models are only as good as the data they read, and compliance can’t be automated over data you can’t see or control. A big-bang rebuild would have frozen the product for too long. The real problem was the order of the work.

Architecture

1. Phase 1: Dataencrypted Azure SQL migration
2. Phase 2: ComplianceAzure Policy + Power Platform
3. Phase 3: Fraudrules + Azure ML model
4. Phase 4: VisibilityPower BI monitoring + admin tools

1. Data. On-prem SQL databases moved to Azure SQL with advanced encryption. This consolidated scattered records into one controlled, auditable layer.
2. Compliance. Policies were enforced with Azure Policy, and Power Platform workflows automated the repetitive GDPR, CCPA and PCI DSS work that had been done by hand.
3. Fraud. A hybrid engine. The existing rules stayed in place for known patterns and explainability. An Azure Machine Learning model scored transactions on top of them to tell real risk from normal-but-unusual behavior, which cut false positives.
4. Visibility. Power BI dashboards track fraud trends and model performance, alongside admin tools the security team uses every day.

Decisions I made

• Secure the data layer first. It was the least visible phase and the hardest to sell internally, but every later phase depended on a secure, consolidated source. Starting with fraud would have meant training models on data we didn’t trust.
• Hybrid over replacement for fraud. Swapping the rules for a model wholesale would have lost explainability that compliance and analysts depended on. Layering the model on top of the rules reduced false positives while keeping decisions easy to justify.

Trade-offs

A phased roadmap delivers its most visible win (better fraud detection) later than a fraud-first plan would. We accepted that because each phase shipped value on its own and reduced risk for the next. The platform grew by half during the work without a security setback.

My role

As Product Lead with a team of about 3–6 people, I owned the roadmap end to end:

• sequencing the phases;
• coordinating engineering across the Azure, SQL and Dynamics stack;
• keeping compliance, security and product priorities moving together rather than against each other.

Results

• 25% fewer fraud-detection false positives
• $2M in annual operating savings
• 30% improvement in overall platform performance, and 15% lower payment latency
• Supported 50% user growth without compromising security

What I’d do next

Move fraud scoring from batch to real-time streaming, so every transaction is scored before it settles rather than reviewed afterward. The consolidated, encrypted data layer from Phase 1 is what makes that step possible.

The problem

Construction plans change constantly, from a minor tweak to a full redesign, and every change has to reach the crew. In practice, crews worked from outdated printed sets or scattered digital files. The gap between what had changed and what the crew was holding led to expensive mistakes and rework.

The real problem

Crews had no shortage of plans. They had too many copies, with no way to tell which one was current. The fix needed a single current version, reachable by anyone on site, in seconds, on whatever phone they carried.

Architecture

1. New revisionuploaded by the design team
2. Cloud storeversioned plans
3. QR on siteone code per set
4. Mobile webalways the latest version

Plans live in a versioned cloud document store. Each code posted on site points to its plan set rather than to one file, so scanning always opens the current revision. Every access is written to an audit log: who opened which version, and when.

Decisions I made

• Mobile web, not a native app. Crews won’t install an app for one job, and subcontractors change from site to site. Mobile web works on any iPhone or Android phone straight from the camera, with no app store and no login friction. That was the single biggest factor in adoption.
• Do one thing well. We resisted adding features. It’s for getting the current plan quickly, and that simplicity is why it held up for crews with very different levels of comfort with technology.

Trade-offs

Skipping a native app meant giving up offline mode and deeper phone features. We accepted that because the real barrier was getting people to install anything at all. A tool nobody installs saves no one from a mistake.

My role

As Product Manager, I worked with engineering on the storage and versioning design, and with UX/UI designers on an interface built for the job site that worked for crews of every level of technical comfort.

Results

• 75% fewer plan-related errors
• 50% faster plan distribution
• 1,500+ active users within six months
• $3M in additional revenue from partnerships with construction firms

What I’d do next

Add change highlighting, so scanning a revised plan shows what changed since the crew last looked, plus an optional offline cache for sites with poor signal.

The problem

Residential construction is resource-intensive. A project’s environmental impact (material waste, energy use, carbon footprint) was tracked, if at all, in separate systems across design, procurement and the job site. None of it could be turned into a decision while it still mattered.

The real problem

The firm didn’t need another sustainability report. It needed the data in one place, early enough to change the design and the order of materials, rather than totaled up at the end.

Architecture

1. DesignBIM model quantities
2. Siteprocurement + waste logs
3. Modelregression forecasts
4. DecidePower BI dashboard

The dashboard joins material quantities and energy models from BIM with procurement records and site waste logs, so planned and actual use sit side by side. Regression models trained on historical projects forecast material cost, waste and carbon for projects still in design, which is when changing course is cheapest. The $12M savings figure is a projection across the portfolio of projects using the dashboard.

Decisions I made

• Forecast, don’t just report. A report tells you what went wrong. A forecast made during design tells you what to change. We put the predictive view at the front of the dashboard.
• Co-design with contractors. I ran research directly with contractors and project managers, so the metrics matched how projects actually run and busy site teams would really use it.

Trade-offs

Regression models on historical projects are simple and explainable, which suited a firm new to data-driven decisions. The cost is accuracy on unusual projects. We chose transparency, so teams could see why the dashboard predicted what it did.

My role

As Product Manager, I:

• integrated data sources across the project lifecycle;
• worked with sustainability experts to define the right metrics;
• ran user research with contractors to refine the feature set.

Results

• $12M in projected material savings across the projects using the dashboard
• 30% less energy used during construction
• 15% smaller project carbon footprints
• $6M in energy savings in the first year after construction
• 5% higher project profitability

What I’d do next

Replace the regression models with forecasting that updates continuously from live procurement data, and push alerts when a project drifts from its material or carbon budget.

The problem

A great Dungeons & Dragons campaign needs an experienced Dungeon Master: someone to improvise stories, invent characters and referee rules on the fly. Most people who want to play don’t have one, and prepping a campaign from scratch is enough of a barrier that many interested players never start.

The real problem

A language model can improvise a story on its own. Two things are harder:

• Consistency. It has to remember the tavern keeper’s name three sessions later.
• Accurate rulings. It shouldn’t confidently invent a rule.

Without both, players stop trusting the Dungeon Master, and the game falls apart.

Architecture

1. Player turnnatural language
2. Contextgame-state memory
3. Rulesretrieved from the rulebook
4. Dungeon MasterLLM narration + ruling
5. Updatewrite back to game state

Merlin’s Beard is built on the OpenAI API. Structured game-state memory stores characters, inventory, quests and world facts, and each turn brings the relevant parts back into context. Afterward, new facts are written back, so the story stays consistent across sessions. Rules are grounded with retrieval (RAG): when a ruling comes up, the relevant rules text is pulled in, so the answer is based on the actual rules rather than the model’s memory of them.

Decisions I made

• Structured memory over chat history. Replaying the whole conversation is expensive, and the model still loses details. A structured record of what’s true in the world kept the Dungeon Master consistent and kept each turn’s context small.
• Look up rules, don’t recall them. Players forgive a bold plot twist. They don’t forgive a made-up rule. Retrieval made the Dungeon Master a trustworthy referee.

My role

As founder, I invented the product and took it from idea to launch myself: research, feature prioritization, engineering, UX design and testing.

Results

• 1,000+ active users within three months
• 40% increase in retention

What I’d do next

Give the Dungeon Master voice and images: spoken narration and generated scene art, so a session feels like sitting at a real table.

The problem

Residential contractors ran projects on a patchwork of spreadsheets, email threads and manual tracking. There was no single source of truth for schedules, budgets or communication, and no way to catch problems before they became expensive.

The approach

We brought task timelines, budget tracking and team communication together in one platform, with discovery work directly with contractors from the start.

Decisions I made

Templates over a fixed workflow. Every contractor runs jobs a little differently, and a rigid workflow would have been abandoned in weeks. Configurable templates let each contractor start from how they already worked, so adopting the platform meant fewer changes to their habits.

What changed

• Spreadsheets, email threads and manual tracking gave way to one platform for schedules, budgets and team communication
• Contractors adapted templates to their existing process instead of learning a new one
• Problems with schedules and budgets surfaced earlier, while they were still cheap to fix