Twenty years of product work compresses badly into bullet points. These are the three efforts where the decisions were hardest, the ambiguity was real, and what I'd do differently is still worth talking about.
Ivanti · Enterprise IT & security software
Arrived to no AI strategy and an open argument about pace. Shipped one small, real thing first — then used what it exposed to justify the platform underneath it.
When I joined Ivanti there was no AI strategy in place. The company knew it had to move, but there was genuine internal disagreement about how to break in and at what pace — and the debate was running on two fronts at once. One was internal: using AI to increase our own velocity. The other was external: exposing AI to customers in a way we could actually control for experience, delivered value, and cost.
Underneath that was a quieter risk. Several teams were about to start building agentic features independently. Left alone, each would have invented its own agent scaffolding, its own definition of "good enough," and its own answer to who is allowed to do what on whose data. That kind of duplication is cheap to create and extremely expensive to unwind.
I didn't start with the platform. Starting with a platform means guessing at the requirements, and the guesses are usually wrong in the ways that matter. Instead I started with a deliberately small, fast bet: a natural-language query builder that used an LLM to make filtering faster. It was chosen for one reason — it mapped to a workflow users already performed constantly, so the value would be legible rather than theoretical.
Shipping it made two structural gaps obvious, and made them arguable with evidence rather than opinion. First, every team was going to rebuild agentic capability from scratch without a shared framework. Second, every team was going to implement quality differently without a common evals and observability layer. I sequenced those two platform layers next, specifically so they would accelerate everything that came after rather than only the thing that exposed the gap.
Two principles shaped how those layers were built:
Evals as the contract, not the gate. Eval pass rates and traces became the definition of quality, which moved acceptance left. Teams stopped discovering that a model behaved badly during a late review, and started designing against a measurable bar from the beginning.
Governance as a product surface. Identity, auditability, and reversibility were treated as first-class parts of the platform rather than a compliance pass at the end. In enterprise AI the question isn't only "can the agent do this" — it's "on whose behalf, with what permissions, and can we see and undo it afterward." Bolting that on later doesn't work.
From there I pushed the platform toward being genuinely consumable: self-service onboarding, golden paths, and reusable shared services, so that building on it was less work than building your own. That extended outward too — we launched externally consumable MCP and agentic frameworks so partners and customers could build their own agentic solutions against the Ivanti Neurons platform.
Shipping the small workflow feature before the platform looked like a detour, and internally it was questioned as one. It wasn't. It turned an argument about strategy into a concrete list of gaps that a room full of engineers agreed were real — which is what actually unlocked the investment in the framework and eval layers.
With the foundation in place we built a customer-facing insights and recommendations engine that reads a customer's complex environment and pairs what it finds with a concrete recommended action. The practical effect is on mean time to resolution: when a vulnerability surfaces, an administrator sees the insight and the remediation path together rather than starting an investigation from scratch.
Alongside that, three previously independent solutions were consolidated onto the unified platform with shared, self-service capabilities and consistent standards — less duplicate building, less operational surface area, and a stronger cross-sell story. The agent framework and observability layer are now the foundation for the next wave of agents, working toward a longer-term vision of a substantially autonomous Ivanti management system built on that same insights and recommendations engine.
Platform investment is easiest to win once a real product has already run into the wall the platform removes. I'd sequence it the same way again — and I'd spend even more of the early effort on developer experience, because a shared capability that's harder to adopt than to rebuild will simply be rebuilt.
Mastercard · Open banking & data products
Financial institutions don't buy transaction data. They buy the confidence to make a decision from it — which makes accuracy and coverage the entire product.
Raw bank transaction data is messy in ways that stay invisible until you try to build on it. The same merchant appears a dozen different ways. Categories are inconsistent. Fields go missing. None of that matters if you're rendering a transaction list — and all of it matters the moment a lender wants to underwrite from cash-flow data or a bank wants to act on a predicted balance.
Our customers were financial institutions making real decisions with real downside. The product was never "access to data." It was whether the enriched output was accurate and complete enough that a risk team would sign off on using it.
We built an AI/ML insights platform that turned large-scale transaction data into decisioning intelligence — predictive signals for balances, cash flow, SMB revenue, and consumer income — using retrieval and enrichment over high-volume pipelines. In parallel I owned the enrichment models and the requirements for OAuth-based data connections, since permissioned, high-fidelity connections are what make every downstream signal defensible in the first place.
Two things I insisted on. First, a developer-first platform: partners had to be able to integrate and innovate on our open banking infrastructure without a services engagement, because adoption at the pace we needed was never going to come through bespoke integrations. Second, real customer and partner advisory — run as a genuine validation loop rather than a showcase — which is what informed roadmap sequencing, pricing, and monetization instead of merely confirming what we already planned to do.
Engineering and data science deadlocked on how to improve transaction categorization. Engineering wanted regex — fast, cheap, deterministic. Data science wanted better ML models. The argument stalled the work and started to damage the relationship between the two teams.
I didn't pick a side, partly because I needed both teams fully engaged on execution either way, and partly because listening properly made it clear each was right about a different slice of the problem. We shipped a hybrid: regex for the common, well-known entities where deterministic matching wins outright, and ML for the long tail where patterns don't generalize and only a model can. Accuracy landed well beyond where either proposal would likely have reached alone, and each team owned the part it was genuinely best at.
Business-entity and categorization accuracy improved substantially, and data fill rates rose across the high-volume pipelines — the two properties that determined whether an institution would build a decision on our output at all. The insights platform gave those institutions predictive signals they had previously either bought elsewhere or gone without, and the developer platform let partners extend it without our engineers in the room.
When two strong technical teams disagree hard and neither will move, it usually means the problem has more than one regime and each team is optimizing for a different one. Naming the regimes is faster than adjudicating the argument — and it leaves both teams with ownership instead of a loser.
MX Technologies · Data-centric SaaS for financial institutions
The engineering was excellent. That was part of the problem — it made it easy to keep building impressive software for problems customers weren't willing to pay to solve.
MX was engineering-led, and the engineering talent was genuinely strong. But a lot of what shipped lacked product-market fit — technically impressive software aimed at problems customers weren't demonstrably willing to pay to have solved. My mandate was to turn four data products into a growth engine with real go-to-market and P&L accountability, which meant changing how decisions got made rather than simply shipping more.
I introduced a product-led operating model with one structural change at its center: for each product, a trio of PM, designer, and engineer ran customer discovery calls together. Not a PM relaying findings back to the team — the engineer in the room, hearing the customer directly. That single change did more to shift priorities than any framework I could have imposed, because it is very hard to keep advocating for a backlog item after you've heard three customers describe a different problem.
We used those calls to reprioritize around what customers were demonstrably willing to pay for, and paired it with treating go-to-market as part of the product rather than something that happened after engineering finished. I also invested in developer experience — integration ease and documentation — because for data products, time-to-first-successful-call is the real adoption metric.
Our CPO — who had hired me partly for my Adobe marketing background — was strongly invested in building a remarketing platform: advertising to financial institutions' customers, then remarketing anyone who engaged but didn't convert, through social channels.
I validated it properly rather than politically: Figma mockups for user testing, direct interviews, and customer data. The pattern was consistent and unkind to the idea. Target customers already had a marketing vendor, didn't trust MX to deliver outside its core competence, or simply weren't interested. I brought the evidence back and recommended we stop. We killed it and repivoted those engineers onto work with a validated monetization path.
The four products moved into strong year-over-year growth, with a measurable lift in customer satisfaction traceable to discovery-driven prioritization. The more durable outcome was cultural: the default answer to "should we build this" stopped being an internal opinion and started being an external one.
The fastest way to change what a team builds is to change who the team talks to. Frameworks and prioritization rituals mostly re-rank the ideas you already have; discovery run by the people who will actually build the thing changes which ideas exist at all.
Turning raw, messy data — transactions, claims, endpoint telemetry, model output — into products people will pay for.
Multi-year vision and roadmap for an enterprise AI/ML platform — core agents, agent frameworks, retrieval, evals, and governance — treated as products other teams build on rather than rebuild. Full case study ↑
Led PMs and cross-functional partners delivering payments and open-banking data products at global scale, including the AI/ML insights platform and partner and acquisition strategy. Full case study ↑
Built the product management practice from scratch and led marketing as an executive across SaaS claims-management, billing, and EDI platforms moving financial and transactional data between providers and payers. Re-platformed the EDI system from an owned data center to AWS for elastic scale and cost control, and launched a product-operations framework for KPIs, roadmaps, and execution that measurably accelerated time-to-market.
Owned four data-centric SaaS products with go-to-market and P&L accountability, and moved the organization from engineering-led to product-led. Full case study ↑
Productized and monetized service offerings and integrations across the Adobe Experience Cloud platform. Directed PMs, product marketers, and product operations against year-over-year revenue targets, championed innovation aligned to emerging market trends, and led analyst relations.
Owned the end-to-end lifecycle for LANDesk Security Suite, reversing a multi-year revenue decline into growth through data-informed feature strategy and direct customer feedback. Started in technical account management and support engineering — still where most of my instincts about enterprise software come from.
MBA, University of Utah · B.S. Information Technology & Software Engineering, University of Phoenix.
No-Code AI and Machine Learning: Building Data Science Solutions — MIT · Pragmatic Marketing PMC Levels I–III.
Happy to go deeper on the research method, the bets that didn't pay off, or what I'd do differently — that's usually the more useful conversation anyway.