Skip to content

Work

Three problems, three shapes.

A reliability problem, a choice between mechanics, and a commercial one, all on the same product surface. Each is written the same way: what the problem was, what I changed, and what it cost.

01Performance & adoption

Step Syncing

A fifteen-second launch cut to under two seconds, and step-sync completion up 35%.

Problem
The step count people opened the app for sat behind a fifteen-second wait.
What I changed
I reclassified launch time from an engineering backlog item into a product requirement, and held my own roadmap for eight weeks.

Read the case study

Before
15s
Benchmark
2s
What we measured against
Shipped
under 2s

Drawn to scale in seconds.

+35%
Step-sync completion
25 → 6MB
App bundle, 76% smaller
020→1 · Engagement

Steps Premier League

A competitive step league built from nothing, moving session time from 3.5 to 7.8 minutes, on a north star I would not choose again, and I explain why.

Problem
A step counter competes with the one already on the phone. It needs a reason to be opened that the OS widget doesn’t have.
What I changed
I evaluated three retention strategies and shipped the one with no recurring bill, and named who it costs.

Read the case study

3.5 → 7.8

Minutes per session

The declared north star, and a choice I will argue about.

0→1
Built from nothing
3
Strategies evaluated
03Applied AI · Monetisation

AI Smart Health Report

A generated health report people could actually read, that became a key USP in five enterprise deals.

Problem
People finished a check-up and received clinical values they had no way to interpret.
What I changed
I designed the report as a product with three audiences, the reader, the buyer, and the person who has to sign it off.

Read the case study

15%

Incremental revenue

From cross-sell placed inside the report, not around it.

5+
Enterprise closes
0→1
Requirements to launch

Two shorter ones

Funnels I fixed before this job.

Both are here for the trade-off rather than the result, and both fit in three hundred words, which is about what either is worth.

Infinyte Club · Product Operations · Feb – Apr 2023

The verification wall

Funnel analysis showed signups dying inside a five-step verification flow that ran before the account existed.

The trade-off

Deferring verification means accepting a population of unverified users and owning the recovery. That was the decision. The doubling was just what happened next.

I ran the funnel and the drop was not gradual. It sat inside a five-step verification flow placed before anyone had an account, which meant the product was asking for identity documents from people who had not yet seen what they were signing up for.

The proposal was to move verification past the signup boundary. That is not a UX tidy-up. It means accepting users you have not verified, and it only works if you own what happens next. I took it to the CEO with that framing rather than as a conversion win, because the risk was the part that needed the decision.

What made it shippable was the recovery: a push and in-app nudge system, built with engineering in three weeks, that pulled people back to verification once they had a reason to finish it.

Signup completion doubled, which is most of what moving the failing steps out of the signup funnel was always going to do. The number that decides whether this worked is what share of those signups ever finished verification, and that one is not in my record.

2×
Signup completion
3 weeks
From proposal to shipped nudges

I did not own

  • The compliance call. I proposed moving verification later; I did not decide what was acceptable to defer.
  • The build. Engineering shipped the nudge system in three weeks.

Circle Health · Product Intern · Jul – Sep 2024

The claims maze

People starting an insurance claim were abandoning it partway, and nobody could say where.

The trade-off

A claims flow can be short or it can be complete, and the places it asks for the most are the places it needs the most. Cutting steps was not available; resequencing them was.

I owned discovery for the claims journey and mapped it end to end, which is how the drop-off points stopped being anecdotal. Then I built a real-time dashboard tracking 50K+ user journeys, so the question in sprint planning changed from where do we think people leave to here is where they leave.

The redesign resequenced the flow rather than shortening it. A claim cannot ask for less. It can only ask in a better order, front-loading what a person already has to hand and deferring what they need to go and find.

Alongside it I ran year-on-year claims analysis across 20+ enterprise clients, which gave the commercial team something concrete to take into renewal conversations.

50K+
User journeys tracked
20+
Enterprise clients analysed

I did not own

  • The claims policy. What a claim requires is a regulatory question, not a product one.
  • The build. I wrote the user stories; engineering shipped them.