Outcomes, not a portfolio tour.

US insurance client programme (in-house PM role) — 10K to 100K users without a rewrite

• ContextA regulated insurance platform with strict security and audit obligations, scaling from roughly 10K to 100K users over an 18-month period. I worked on it as an employee, in an in-house Senior Product Manager role, for a US insurance client.
• Business problemGrowth was outrunning release reliability. Each release required a named senior engineer to babysit the deploy, and incidents in a regulated environment carried audit consequences, not just downtime. The internal assumption was that the team needed more QA headcount.
• DiagnosisThe CI history said otherwise. The defects reaching production were concentrated in API contract changes and environment drift — neither of which the existing UI regression suite touched. The suite was slow, expensive and structurally aimed at the wrong layer. This was a quality architecture problem, not a coverage problem.
• InterventionRebuilt the automation architecture around contract and integration tests; put CI quality gates in front of the five journeys carrying revenue; fixed staging/production environment parity so a green run predicted real behaviour; added performance engineering ahead of the growth curve; and moved release control from a named individual to a documented, gated process.
• Outcome10× user growth carried on the existing architecture with no rewrite, 99.9% uptime sustained, and release cycle time down approximately 40% against the baseline before the programme.
• What changed permanentlyRelease ownership stopped depending on one person. The team hired one QA engineer into a system that could support them, instead of two onto a treadmill.

Attribution note: the release-cycle and uptime figures are directly attributable to the quality architecture work and measured against the six months before the programme. User growth is a business outcome the programme enabled by removing the scaling constraint — it was not caused by it. This was delivered as an employee in a team, not as an independent advisor; source figures come from the programme's close-out review, and I can walk through the measurement basis on a call.

Enterprise readiness — why upmarket deals stall

• ContextA pattern I have worked repeatedly in in-house product leadership: a B2B product with strong SMB traction attempting to move upmarket into enterprise accounts. No client named.
• Business problemEnterprise deals were reaching late stage and then stalling. The roadmap was being rebuilt every quarter around whichever prospect had complained most recently, and engineering was shipping features that did not move a single deal forward.
• DiagnosisThe blockers were not feature gaps — they were trust gaps: audit logging, SSO/SCIM, permission granularity, data residency and a security review the company could not pass. Sales was selling around them; product was building past them.
• InterventionNamed the assumptions behind each enterprise bet and ran time-boxed spikes with pass/fail criteria written in advance. Rebuilt roadmap sequencing around deal blockers rather than feature requests, including the decision to kill two heavily-requested features. Installed prioritisation logic and roadmap governance the team could re-run without me.
• What this changesDeals stop dying in procurement and legal after a demo that went well. The roadmap stops being rewritten every quarter around whichever prospect complained most recently, because the sequence is set by what is actually costing deals.
• Hardest partThe killing, not the building. Removing two heavily-requested features is a harder conversation than adding five, and it is usually the decision that unblocks the quarter.

A note on this one. This is stated as method rather than as a measured engagement, deliberately. The outcome figures I previously showed here were from in-house team work and I could not evidence them publicly to the standard the rest of this page holds, so they are gone rather than softened. The thinking is unchanged and I can walk through specific examples on a call.

Founder & operator — what building teaches that advising cannot

• ContextQuickVikalp Technologies (2023–2026) folded into Aarohii AI Solution Private Limited, now an AI product house with three live products and one launching: PixellPeep (AI-powered visual regression testing), Captverse (a business operating system with CRM, sales, inventory, payments and AI agents), ViraQueue (AI-drafted social posts held for human approval) and Auvora (enterprise vendor management and source-to-settlement procurement, coming soon).
• What was actually hardEvaluating AI features honestly. A model-backed feature can demo beautifully and still be unshippable, because the failure distribution is not visible in the happy path. Building PixellPeep forced me to design evaluation and observability for non-deterministic output rather than theorise about it.
• Second lessonScope discipline under real cost. Folding QuickVikalp into Aarohii was a decision to stop spreading a small team across too many bets. It is the same decision I now ask clients to make about roadmaps, with more credibility for having taken the loss myself.
• Third lessonQuality economics from the paying side. When the cost of a flaky pipeline comes out of your own runway, the argument for quality architecture stops being philosophical.
• How this informs the advisory workEvery recommendation I make is one I have had to live with commercially. That is the difference between advice and opinion — and it is why the ventures stay, rather than becoming a logo wall.