I build products people actually keep using.
Twelve years turning fuzzy problems into shipped features — then teaching the next generation of PMs to do the same, without burning out.
I got into product because engineering alone wasn't the job.
I started as a backend engineer, and the part I liked best was never the code — it was figuring out why we were building it in the first place. That question followed me into product, and it's still the only one I care about on day one of any project.
Since then I've taken three startups from a rough idea to something customers paid for, sat through the unglamorous middle of two pivots, and learned more from the products that failed than the ones that didn't. These days about a third of my time goes to mentoring — mostly first-time PMs figuring out the job nobody trained them for.
12+ years shipping products · 3 startups, Series A to acquisition · 40+ mentees coached
Three products, three different kinds of hard.
Details are illustrative for this demo — the shape of each problem is the real part.
A scheduling tool nobody asked for out loud
Customers kept working around our product with spreadsheets. Six weeks of shadowing ops teams turned up the real job: nobody wanted a better calendar, they wanted to stop being blamed for other people's delays.
Fixing a funnel everyone assumed was fine
Signups looked healthy on paper. The drop-off was hiding one screen downstream, in a step three teams had each assumed belonged to someone else. Untangling ownership mattered more than any single design change.
Rebuilding trust after an outage
A payments incident had shaken customer confidence more than the downtime itself. The fix wasn't just technical — it was a new way of communicating status, before customers had to ask.
Three ways to work together.
Most engagements start with one of these — scope always flexes around the actual problem.
Product advisory
Embedded or fractional PM leadership for teams that need senior judgment without a full-time hire yet.
1:1 mentoring
Fortnightly sessions for PMs figuring out the parts of the job nobody put in a job description.
Speaking & workshops
Talks and half-day workshops on product discovery, roadmap prioritisation, and leading without authority.
How I ended up doing this.
Where the "why" question started
Three years writing code for features I didn't always believe in. Learned more about product thinking from bad specs than any course could teach.
Thrown in, mostly figured it out
No playbook, no senior PM to shadow. Shipped the company's first real roadmap process, mostly by trial and a lot of error.
Learned to lead without a title
Ran cross-functional launches across three time zones with no formal authority over any of the teams involved.
Kept a team steady through the hardest transition
Held product direction together through due diligence, integration planning, and the inevitable re-org that followed.
Doing the parts I always liked best
Working with a small number of teams directly, and spending real time on the mentoring I used to squeeze in on weekends.
Most product advice skips the messy middle. I write about that part.
Short, occasional notes on discovery that doesn't go to plan, roadmaps that need to change mid-quarter, and the judgment calls that never make it into a case study — the actual day-to-day of the job.
What it's actually like to work together.
"Maya asked the one question our whole roadmap was quietly avoiding. Uncomfortable in the moment, exactly right within a month."
Head of Product, marketplace scale-up"Six months of mentoring and I stopped apologising for decisions in meetings. That shift alone was worth it."
Product Manager, fintech platformTell me what you're building, or what you're stuck on.
Whether it's advisory work, mentoring, or a talk for your team — I read every message myself and reply within a couple of business days.