Work · for evaluation
Technical Product Manager — AI platforms, APIs and developer products.
I have a software engineering background and I have run product as a founder and as a contracted PM. This page exists so that can be checked rather than taken on trust: two pieces of work with the reasoning attached, code you can read, and an honest note on where the evidence currently stops.
What I do
The layer where capability has to become dependable behaviour.
The through-line across everything below is the same: human behaviour, product, technology and business systems are one problem, and most expensive product mistakes happen where a team treats them as four.
APIs and platform surfaces. Designing the contract before the implementation: resource shape, versioning, idempotency, error semantics, and what a consumer can rely on across a change.
AI behaviour as product behaviour. Where model capability has to become dependable product behaviour — guardrails, evaluation, honest confidence, and the boundary between what a system knows and what it is willing to claim.
Data, consent and permissions. Treating a promise made in copy as an engineering requirement, with an auditable trail rather than a policy page.
Translating between customer reality and engineering. Turning observed behaviour into a technical direction a team can build, and a technical constraint into a decision a founder can make.
Case one · decision evidence
Product Health Scorecard — building the diagnostic before selling the cure.
The belief going in. The reasonable default for a solo founder building a lead instrument in a week is to assemble it from third-party tools — a form builder, an email platform, a booking tool. Glue, not engineering. The first build followed part of that.
What the evidence said. The funnel made an audited promise that stack could not keep. The public boundary — assessment emails are never used for sales follow-up without separate consent — requires consent to be checked at the moment each email sends, with a trail. An external platform splits that source of truth: consent lives in one database and sends fire from another.
The decision, and the rejected alternative. Own the email infrastructure natively. Every external platform rejected — none offered a capability needed at this scale, and each would have split the consent trail. Trade-off accepted on the record: manual bounce and complaint handling.
Where it stops. Proof level 3 — decision evidence. Outcome data waits on the field test. I would rather say that than imply a result I have not observed.
Solo build. Every product decision mine, on a dated decision log.
First commit to verified production: four days. Full system including nurture and capture layers: six days.
20 statements across 10 dimensions, nine deterministic result routes, belief-vs-evidence comparison.
Consent enforced at send time against an auditable trail — no external ESP, because an ESP would split the source of truth for a promise the copy makes.
107 tests green. Runtime dependencies: Next, React, MDX. Supabase and Resend integrated through raw REST.
Take it: Product Health Scorecard · How one line of consent copy decided the architectureCase two · decision evidence, executed
An artisan-services marketplace — resetting a finished build around what users actually wanted.
The belief going in. The team had built the marketplace the way marketplaces are usually built: one app for both sides, customers browsing profiles and past jobs to pick someone. More choice and more information equals a better marketplace. That is the default pattern, it is cheaper to build, and the product had already reached real users.
What the evidence said. Ten user interviews. When people need a reliable artisan they do not browse — they ask someone they trust. The recommendation, not the catalogue, is the product they actually use. And after booking, customers were calling repeatedly to ask whether anyone was coming, because nothing told them.
The diagnosis. Browse-and-choose handed the customer the exact job they were trying to get rid of: judging whether a stranger can be trusted to fix their problem. The credible alternative — keep the direction, improve the UX — was rejected, because the flaw was in who owned the trust decision, not in the polish.
The decision. Bring it back and start over, on a product that had already shipped. The founder approved the reset. Two dedicated apps, problem-first matching instead of browsing, dispatch and live tracking, escrow payments. The sunk cost of the original build was the accepted trade-off.
Where it stops. Proof level 3 — the reset was advocated, accepted and carried through to a store-approved rebuild on both platforms. Post-launch user behaviour is not in yet. The client is not named here.
My role. Contracted Product Manager. The review, the ten interviews, the diagnosis, the case for the reset and the go-to-market strategy were mine.
Not mine. The developer team built and rebuilt the product. The founder made the call to reset.
Kept as an open experiment. A connection fee at match time, which the team knows may suppress conversion and is leaving in to find out. A stated hypothesis, not a validated model.
Currently
Practising the specialization, in public.
I am building didii, and running a structured AI platform apprenticeship against real projects — each one gated on a written decision memo and a security review rather than on having finished the tutorial.
The honest boundary: my public portfolio does not yet contain three complete, verified case studies, and I am not going to imply years of dedicated AI platform ownership that the record does not support. What it does support is a software engineering background, product ownership as a founder and as a contracted PM, and the two cases above with their reasoning intact.
Code. This site and the Scorecard — github.com/yusstech
Profile. LinkedIn
Writing. Human Systems — how I think, at length, including where I was wrong.
CV. On request — ask and I will send it, tailored to the role rather than generic.
The longer personal story is on About.Hiring, or considering it