How I
think.

The problem

Managing a complex runtime platform meant needing code-level understanding to make sound decisions. The traditional approach — scheduling deep-dives, waiting for engineers to explain things — was too slow and too dependent on other people's availability. I needed genuine technical grounding without creating a bottleneck for anyone else.

The approach

I built what I call an Architect workflow — using AI primarily to read and understand codebases rather than generate code. I adopted 8 tools across 19 surfaces and ran 860+ AI-assisted sessions in a single month. The discipline was in model selection: lightweight models for quick lookups, more capable ones for deep architecture analysis. The result was engineer-level codebase understanding I could act on independently.

What changed

I could evaluate engineering proposals with real technical grounding, identify risks earlier, and contribute directly to performance tooling decisions. I committed a diff with 3,000+ lines changed — unusual for any PM. Formally assessed as AI-First — second-highest maturity tier, P87 frequency and P71 depth among all product managers in the organisation.

The problem

The platform had an engaged creator community but chronic stability issues that undermined confidence. Creators were building on a surface they couldn't fully trust, which limited what they were willing to attempt. The question was not which features to add — it was whether the platform had earned the right to ask creators to invest more in it.

The approach

I drove a stability programme addressing root causes of creator friction — performance tooling that let creators find and fix their own bottlenecks, and a Docathon that produced 31 new docs, updated 55, and deprecated 81. Only when that foundation was solid did I introduce creator competitions and ship persistent variables and leaderboards — the features creators wanted, but that would have failed on an unstable platform.

What changed

The platform grew to over 1M monthly active users. But the outcome I am most proud of is that creators started building more ambitious things. That only happens when they trust the surface they are building on.

The problem

The enterprise platform served knowledge workers well. Shift-based frontline workers — food manufacturing, logistics, retail — were invisible to it. They managed shift cover with WhatsApp groups and phone calls, and a missed shift meant real operational cost. The question was whether software could actually change that behaviour, or whether the problem was too embedded in how frontline work was organised.

The approach

I started with extended fieldwork — observing how shift managers and workers actually communicated, not how they said they did. The insights shaped a phased strategy: first solve the most acute pain (shift cover requests), then build toward full schedule management, then integrate with existing WFM systems. I partnered with a major food manufacturer to run a real-world pilot with actual workers on actual shifts — not a prototype, a live test of whether the product changed behaviour.

What changed

Shift cover requests that previously took hours resolved in minutes in the pilot. The partner confirmed the core value proposition. The product and strategy became the foundation for the company's broader frontline worker investment — which is what 0→1 PM work is actually trying to do: create the conditions for a much larger bet.

The problem

Calendar sync failures were causing meetings to disappear or show incorrect details. The join flow had unnecessary friction. These were not exciting product problems — they were reliability issues that quietly erode trust and push users toward competitors who just work. In a product competing against established tools, the bar for basic reliability is high and unforgiving.

The approach

I partnered with infrastructure engineering to find and fix the root causes of calendar sync failures — not just the symptoms. Alongside that, I redesigned the accept/decline flow, shipped calendar edit mode, and launched a lightweight meeting experience that reduced load times for ad-hoc conversations. Every change was motivated by one question: does this make it more likely that someone gets into their meeting?

What changed

Calendar sync reliability improved significantly. Meeting join completion rate improved. Support tickets related to meeting confusion fell. These are not headline numbers — they are the numbers that determine whether users stay long enough to discover the features that actually differentiate the product.

The problem

The AR creation tool was powerful but asked too much of new creators. A blank canvas and complex tooling meant high drop-off early in the journey. The content supply problem was actually an onboarding problem — we were not giving new creators enough reason to believe they could do this.

The approach

I led the design and launch of a templates system — pre-built AR experiences creators could modify and publish rather than build from scratch. Alongside that, a guided Studio Tour that walked new users through the key features at the moment they needed them. I also introduced structured feedback channels that fed directly into the roadmap — so creators could see that their input changed what got built next. That loop compounds.

What changed

Templates became the highest-adoption entry point for new creators. New users were publishing their first AR effect in minutes rather than hours. Creator satisfaction improved as feedback was visibly actioned — and the community grew because people felt the product was being built with them, not just for them.

The discipline

Knowing which mode a task calls for — thinking partner, execution layer, pipeline component — and not defaulting to the easiest one. Most people default to the chat box. The leverage is in knowing when that is the wrong tool.

The approach

I documented this honestly: what workflows exist, where AI genuinely adds leverage, and where it flatters without improving. I ran a structured experiment asking both Claude and ChatGPT to independently assess my usage across five dimensions — frequency, breadth, workflow sophistication, dependency level, and output leverage. Both converged on the same observation: the meaningful distinction is not how often someone uses AI. It is whether they have rebuilt how they work around it.

What it produced

A quantification framework and a builder's log — a detailed account of what AI-native practice actually looks like in a product management context. The dual-model assessment removed the self-serving bias that comes from evaluating your own practice. The convergence between two independent models on the same conclusions gave the result credibility.