Product leader with 5+ years driving B2B SaaS from 0→1 launch through growth-stage scale. I oversaw product improvements that saw revenue 20x. I work directly with executive leadership on strategy and I've built product functions from the ground up: hiring teams, designing operating models, and establishing processes that let development move fast. I also build LLM-powered workflows.
After studying computer science and technical writing I started my career in IT before transitioning into product management. My technical foundation means I can go deep with engineering teams while still keeping the user front-and-centre.
I thrive building 0→1 products: taking ambiguous problems through discovery, defining the right scope, and shipping solutions that drive real customer value and user delight. I especially love being a translator between technical and non-technical teams.
I'm looking for a Senior PM or Lead PM role at a growth-stage small business or established organization where I can own a product area end-to-end, learn an entirely new domain, and upskill both technically and professionally.
AWS
Figma
GitHub
Hotjar
Jira
Metabase
Mixpanel
Notion
Zapier
ChatGPT
Claude
Cursor
Magic Patterns
MCP
n8n
OpenAI API
Vercel
When I joined Pivott, there was no product function. No process, no team, and no path from idea to shipped. Engineering was experienced, but it had come from a stable, profitable business built around maintenance. The mandate was a new SaaS product at startup pace.
A 0→1 launch without a product function is a structural risk. Work defaults to ad hoc decisions, unclear requirements, and reactive engineering.
Core tension: Move fast enough to compete, and still build the process that can sustain it.
The team's instincts were set for stability, not speed. Process change without credibility rarely sticks.
1. Design the full lifecycle before hiring
I mapped 17 phases, from idea submission to review and success monitoring, before growing the team. New hires started inside a working system.
2. Secure CEO alignment before rolling out to engineering
The cultural gap meant a process change needed executive weight. With the CEO aligned first, the shift was company direction, not only a PM's opinion.
3. Use certification frameworks as a starting point, not a constraint
Planning poker, sprint rituals, and backlog governance were the baseline. I adapted them to Pivott's stage instead of applying them by the book.
Pivott's marketing site ran on Webflow, from a purchased template. Marketing could not build new pages on their own. Custom interactions needed a developer. A planned redesign was getting harder to justify.
Feature landing pages were stalled. A pricing page, with collapsible comparison tables and an interactive plan structure, kept getting deferred. In Webflow, the effort was not worth prioritizing.
The constraint was the platform, not the design. Webflow handled basic copy. A new component, an interactive pricing layout, or a feature page each needed a developer or a Webflow specialist. Pivott had neither available for marketing work.
Core tension: The site had to grow with the product, but every meaningful change was its own project.
Webflow was also retiring its legacy editor. The status quo was temporary either way.
1. Pull the 2027 redesign forward by more than a year
A competent Webflow rebuild was about the same effort as React, with worse long-term outcomes. Leadership approved moving immediately. A year-plus plan became a few weeks.
2. Use Magic Patterns as the design tool
Instead of hiring a designer or a Webflow consultant, I used Magic Patterns to produce an on-brand React prototype before any production code. It included a component library, brand tokens, responsive behaviour, and accessibility compliance. Leadership could click through it before committing engineering time.
3. Choose Next.js over Vite and React Router
Next.js gave server-side rendering for SEO, file-based routing, and native metadata. On Vercel, deployment, staging branches, and preview URLs were essentially zero-config.
4. Design for non-developer contribution from day one
A Marketing Manager needed to contribute, not only review. Named Tailwind tokens, a clear folder structure, and a CLAUDE.md file let Claude Code and Cursor match the codebase. Copy updates, new pages, and image swaps no longer need a developer.
Customer support kept pulling the product team into Slack, email, and calls. Documentation, PRDs, and BI tools already existed. Customer Success was not using them.
Support asked the product team instead of looking it up. That meant constant interruptions, slower replies while people waited on a PM, and documentation that sat unused.
Core tension: Let support reach product knowledge on their own, without making the product team the bottleneck.
1. Validate non-technical solutions first
I improved the docs and ran a lunch and learn on self-serve questioning, adapting PM-style interviews for support. It helped. It did not reduce reliance on the product team.
2. Invest in a scalable system
AI could aggregate and synthesize what we already had. I proposed an internal Product Concierge for real-time, self-serve answers.
3. Prioritize trust and accuracy over breadth
The assistant cites its sources, shows how old the information is, and holds back when confidence is low.
Buyers expected Pivott to read their contracts with AI. Early tests handled basic details and missed complex clauses. I owned the work from that first test through a full rebuild of the extraction pipeline, and the initiative shipped.
The early pipeline called a model up to ten times per contract. That was slow, expensive, and hard to trust when a field was wrong. A narrow first test was the way to learn. It was not the product we shipped.
Core tension: Prove the AI could extract real contract terms, then rebuild it so the cost and the accuracy could hold in production.
1. Start with a small demo, then ship the real pipeline
The first test accepted a vendor processing limit and extracted only contract name and date. That limit was the demo. The shipped pipeline is the rebuild.
2. Keep automation conservative where trust mattered
Recurring tasks stayed on simple patterns, with odd cases sent to manual review. A vendor was not created from a name alone.
3. Rebuild as one structured call
Replaced up to ten model calls per contract with one. Added per-field reasoning, a staff review panel, a provider fallback, and OCR caching.
An enterprise property operator audited leases by hand for accuracy, consistency, and omissions. The work needed many people and a lot of time. The question that started the work: can existing document AI read a lease and compare it to expected values?
A full audit product, with customer access, saved output, and every field, would have been a large bet before anyone knew whether the model could match a lease to expected values. The sales motion was not self-serve. Staff would run audits on a prospect's real leases before any purchase.
Core tension: Learn whether the audit was real without building the commercial product first.
1. Test the cheapest version first
The prototype split PDFs into 15-page pieces, sent them to a document AI service, and compared the results to expected values, treating a currency value written two ways as one match.
2. Sell through staff-run concierge audits
Chose a go-to-market model of staff-run audits ahead of product-market fit. Hid staff-only screens from customer roles and skipped guided self-serve onboarding.
3. Make a dollar difference the headline
The engine stored match or no-match, not the size of a discrepancy. A dollar figure persuades more than an item count, so storing that difference became a prerequisite for the reporting work.
4. Validate on known answers before more sales use
Designed a three-dataset plan: synthetic seeded errors, a known-flawed real property, and an unaudited property. Success was full reconciliation: every real discrepancy flagged, and no correct value flagged.
A prospect had no way to sign up for Pivott alone. Sales qualified the lead, and staff created the company and user by hand. I owned the plan to change that, and the work shipped.
Full self-serve sign-up was the larger build. There was also no permanent place to show the product without copying a company for every prospect. Starting with the full sign-up would have spent the roadmap before anyone had used the product on their own.
Core tension: Learn whether self-serve demand was real, then ship the sign-up, rather than stopping at the test.
1. Validate with a sandbox, then build sign-up
Asked new users to try a sandbox first, so demand was visible before the harder build. Self-serve sign-up shipped after that. It was the sequence, not the end state.
2. Make the sandbox permanent
Redesigned it from a per-prospect copy into one always-on environment. That removed sales-conversion pollution and the work of managing duplicate companies.
3. Protect account privacy
When someone signs up twice with the same email, the flow sends a login link rather than confirming that the account exists.
4. Ship concierge upload on the way to full automation
Customers see automatic contract processing. Staff entered the details behind the scenes as the smaller first step. Spreadsheet upload shipped with the rest of the motion.
If you're building something interesting, I'd love to be a part of it. Reach out to me at the links below.