Esther MirzakhanyanProduct manager who vibe codes

Portfolio · 2026 · 0-1 builds

From a blank page to a launch-ready product.

Product manager specializing in taking ambiguous, regulated consumer problems from 0 to 1: health, intimacy, parenting. I find the problem, decide what the product must never do, scope the first version hard, and build it myself with AI coding agents until it can be argued with.

Esther MirzakhanyanThree 0-1 builds in 2026 · sole PM on each
→ next slide ← previous F fullscreen
Nire telehealth home page on a phone
0-1 build · Nire
IntimPath today screen
0-1 build · IntimPath
Lull today screen
0-1 build · Lull

Product philosophy

How I build new products

Four positions I take on every 0-1 build. They are the reason the three products in this deck reached a working, reviewable state without an engineering team.

  • Discovery is reading the problem, not confirming the brief.The brief for Lull said "sleep tracker"; the parent's day did not. The brief for Nire said "marketing site"; the problem was that nothing on it could be substantiated. I start from what the person would say out loud, and from what the category forbids.
  • The "never" list is the strategy.In health-adjacent categories the product is defined by what it refuses to do: no invented proof, no claims the business cannot back, no advice that needs a clinician. I write that list before the feature list, and I turn it into tests.
  • Scope to the hypothesis, cut everything else.V1 exists to test one belief. Anything that does not test it, or that would hurt a family or a patient if wrong, is out and written down as out, with the reason.
  • Speed comes from building the thing, not the ticket.AI coding agents are my engineering capacity. I spec, build, review and QA in one loop, walk every changed flow in a real browser, and distrust the output on purpose: rules become tests, claims are read against the code.

Snapshot

Three 0-1 builds, one method

Each was taken from an ambiguous brief to a working product in six to twelve weeks, as the sole product manager and the builder. Click into any of them below.

Nire home page on a phone
0-1 build · Nire · telehealthTelehealth site for compounded GLP-1 weight care, hormones and sexual health. Six weeks from a site nobody could ship to a compliant, launch-ready product.
IntimPath today screen
0-1 build · IntimPath · intimacy trainingWeb subscription turning clinician-grade pelvic-floor, anxiety and desire training into a few private minutes a day. Nine programmes, five languages. Twelve weeks.
Lull today screen
0-1 build · Lull · baby sleepFirst-year companion for parents where trust is the product: predictions as windows, one table of truth, no invented proof. Ten weeks to a walkable beta.

Case study 1 · 0-1 build · Direct-to-consumer telehealth

Nire: a regulated site nobody could ship, launched clean in six weeks.

Compounded GLP-1 weight care, hormone therapy, sexual health. The brief was "we need the marketing site live for paid traffic". The reality was a site that could not legally go public.

A. Executive summary

Nire, in one screen

The productA direct-to-consumer telehealth marketing site for compounded GLP-1 weight care, women's HRT, testosterone therapy and ED treatment, handing patients to a partner's clinical intake.
The target userUS adults arriving from paid social on a phone, deciding whether to start a free medical evaluation for a treatment they are embarrassed to ask their doctor about.
My roleSole product manager and quasi-founder for the site. I owned the problem, the requirements, the compliance program, and I wrote the code myself with AI coding agents. Counsel and the client were my stakeholders; there was no engineering team.
TimelineSix weeks, 10 July to 21 August 2026: rebuild, then a full marketing-compliance audit and remediation, to a launch-ready build with guardrails in CI.
0-1 buildTelehealthMarketing complianceDesign systemSole PM

B. Phase 0 · The ambiguity and the problem space

A site existed. Nothing on it could be defended.

Nire's public site was a Framer export: unmaintainable, with placeholder social proof and health claims counsel had never seen. Paid acquisition was budgeted. The question underneath the brief was not "how do we launch" but "what are we allowed to say, and how do we know it stays that way".

The spark

  • Mandate"Get the marketing site live for paid traffic." The pipeline had just been switched to deploy straight to production; the staging gate was removed in the same week.
  • What I sawSix regulatory requirements from counsel, and a site that described compounded drugs as "safe" and "evidence-based", promised "the same active ingredient" as branded drugs, and showed a 4.7-star rating from 2,400 reviews that did not exist.

Customer discovery

  • Structural read of the existing product36 captured surfaces at three breakpoints, decomposed into a component inventory (62 recurring pieces) before writing a line.
  • Regulatory readCounsel's six-requirement baseline, FTC substantiation and fake-review rules, Florida's weight-loss advertising rule, and the recent FTC action against a telehealth brand for exactly this pattern.
  • Audit as discoveryEvery page checked against the six requirements; every finding a screenshot with route, rule and file. Four of six failed.

Why now

  • MoneyPaid social spend was budgeted and waiting on the site.
  • ExposureEvery prohibited claim was one merge from being public under the brand's name.
  • TrustIn a medical purchase the words that create legal risk are the same words that decide whether a patient trusts the brand enough to start.

C. Phase 0.5 · Vision and strategy

Compliant and convincing are the same thing here

We believed that by rebuilding the site as a clinician-led, fully disclosed marketing surface on our own design system, patients arriving from paid social would start a free evaluation at least as often as with hype claims, with zero legal exposure and without needing an engineering team.
Build vs buyKeep the Framer site and patch copy, or rebuild in code. I rebuilt: copy in Framer cannot be tested in CI, cannot be shared across pages, and cannot be reviewed as a diff. Code-owned content fixtures made one rewrite fix nine pages and made a claims lint possible. The partner's intake, checkout and login were kept, not rebuilt.
Strategic alignmentThe company's play is to run acquisition for partner clinics. A site that can pass counsel review and survive a regulator's look is the asset; a site that converts on invented stars is a liability that ends the partnership.
Success criteriaZero prohibited claims on any page, verified by a test. Every mandated disclosure on every weight-loss page. No social proof the business cannot substantiate. Guardrails so a future edit cannot undo it.

D. Phase 1 · Ruthless scoping

What the first version had to do, and what I said no to

Prioritized by exposure: P0 blocks any public deploy, P1 blocks marketing spend, P2 is hygiene. The P0 list was short enough to finish in days, which is what made launch-on-time credible.

The MVP

  • 36 routes on one design systemHome, four treatment areas with one page per medication, how it works, who we are, FAQ, contact, six per-product safety pages, and the complete legal set.
  • Static, no backendA single-page app with two calls to action that hand off to the partner. Nothing to secure, nothing to keep up.
  • Compliance built inShared disclaimer component, claims lint in CI, review checklist next to the code.

What I cut

  • The in-house backend and in-app flowsThe first commit shipped a frontend and backend. Ten days later I stripped login, quiz, checkout and patient portal: the partner owns them, and every regulated event lives there.
  • Testimonials and ratingsRemoved, not replaced. No real reviews existed. The section returns the day verified ones do.
  • Trust sealsLegitScript, HIPAA and pharmacy seals removed until the certifications exist.
  • Blog and "in the news"Nothing to publish yet; a dead link is worse than no link.

Constraints

  • No engineersI was the team. AI coding agents were the capacity; the browser was the QA lab.
  • Counsel and client decide wordingEvery patient-facing sentence was proposed with the rule it satisfies; the client chose the disclaimer placement on 17 August and I shipped it the same day.
  • Two inputs I could not producePharmacy contact details and the substantiation file are business items. Tracked with owners, explicitly not launch blockers.

The product

What patients see

Desktop pages of the launch build, sliding inside one screen. One hero message per treatment area, clinician-led claims only, and the mandated disclosure where the client directed it.

Nire home page GLP-1 weight care hub Semaglutide page Women's HRT page ED treatment page How it works page Semaglutide safety page Privacy policy

Scoping in practice

Claim the process, not the outcome

Problem: "evidence-based" is an efficacy claim, and no clinical studies exist on compounded semaglutide. Decision: say what actually happens to the patient. A licensed clinician prescribes and oversees treatment, which is a real differentiator. "Individual results vary" under the call to action.

Before
Old hero: 'Evidence-based GLP-1 treatment'

GLP-1 hero. "Evidence-based GLP-1 treatment, reviewed by a licensed clinician and delivered to your door."

After
New hero: 'GLP-1 treatment prescribed and overseen by a licensed clinician'

Shipped. "GLP-1 treatment prescribed and overseen by a licensed clinician, delivered to your door." plus "Individual results vary."

Scoping in practice

Trade invented proof for real information

Problem: a 4.7-star rating, "2,400+ reviews", five placeholder quotes and a dead "View reviews" link, in a category where fake reviews carry per-violation penalties; and "important safety information" promised but rendered as plain text. Decision: remove the social proof entirely and spend the effort on six per-product safety pages.

Removed
Old testimonial block with an invented rating

Home. Invented rating and review count with placeholder quotes.

Added
New semaglutide safety information page

Safety pages. What the medication is, who should not take it, side effects, and when to seek care.

E. Go-to-market and launch

Launch gate, hand-off, and the moment the floor moved

Nire's traffic is bought, not grown: paid social to a treatment page to the partner's free evaluation. So the launch strategy was a gate, not a campaign.

Launch strategyLaunch readiness was the tracker: every P0 and P1 item landed, the claims lint green, counsel's checklist signed against the evidence index. First users come from the partner's paid social, per treatment area, so each medication page is a landing page and carries its own disclosure and safety link.
The "oh sh*t" momentMid-audit I found two things in the git history. A routine copy commit had deleted the one compliant compounded-medication sentence the site already had, and a separate commit had opened the production environment by removing the dev access gate. The site was one merge from publishing 14 prohibited strings under the brand. I stopped everything, wrote the P0 list that afternoon, moved the disclaimer into a shared component so it cannot be deleted page by page, and made the banned-claims list a CI test so the pipeline itself refuses the next slip.
What it taught the teamA compliant sentence that lives in one page's copy is not compliant; it is temporary. Rules that matter live in components and tests.

F. Results and learnings

Launch-ready, verifiable, and it stays that way

Pre-launch by design: the metrics below are validation of the build, not vanity traffic. The partner controls the moment paid traffic starts.

0prohibited claims on any page, enforced by the CI claims test on every merge
50 / 62tracker items landed; the remaining 12 are business inputs with owners, none blocking launch
36routes on a 62-component design system, including six new safety pages
6 wkfrom first commit to launch-ready, with zero engineering hours

F. Results and learnings

What V1 taught me, and what I would do differently

Initial traction to watchFree-evaluation starts per treatment page from paid social, and the drop between page view and hand-off. Read the safety-page click-through as a trust signal, not a leak. Compare disclaimer placements within the compliant options; the client's choice was a judgment call we can now measure.
Next stepsBring verified reviews and a real certification back, behind their business owners. Ship the pharmacy notice the moment the details arrive. Add the substantiation file so the quality claims the site still cannot make become possible.
RetrospectiveI would put the claims lint and counsel's checklist in the repo on day one, before any copy existed, instead of week five. I would get the disclaimer placement decision from the client in the first conversation, not the last. And I would have captured the two business inputs as blockers on the first day, because they are still the only open items.

Case study 2 · 0-1 build · Consumer subscription · Sexual health

IntimPath: a clinician's plan, in a few private minutes a day.

Nobody books an appointment about this. The brief was a web-only product under a new brand. The problem was making people who will never see a doctor start, pay and come back tomorrow.

A. Executive summary

IntimPath, in one screen

The productA browser-based subscription that turns what a good clinician would prescribe for ordinary sexual problems (pelvic-floor training, anxiety work, education about your own body) into a paced daily plan. Nine programmes of 16 to 70 days, five languages, three quiz funnels, checkout and post-purchase offers.
The target userMen who finish too fast or cannot rely on an erection; women who have lost desire, never learned what works for their body, or hit menopause unprepared. All of them: would rather do nothing for years than say it to a stranger.
My roleProduct manager and builder. I owned the programme line-up, pacing, packaging and pricing, the claims, the content and the implementation, working to a strict CTO review on every merge request. Payments and accounts come from the company's platform, not built here.
TimelineTwelve weeks, June to September 2026, 219 commits, to a full product on the development environment: marketing site, funnels, checkouts, app and admin as one application.
0-1 buildConsumer subscriptionSensitive categoryFive languagesSole PM

B. Phase 0 · The ambiguity and the problem space

Ordinary problems that almost nobody gets help with

The company owned a library of programme content and quiz funnels from an earlier, app-store product. The mandate was a web-only product under a new brand. What it should be for, and why anyone would pay, was open.

The spark

  • The gapSexual problems are common and treatable, yet a clinic means saying it to a stranger's face, pills treat the symptom, free content contradicts itself and is never sequenced. So people do nothing, for years.
  • The reframeThe missing thing is not information; there is plenty. It is a private, paced, personal plan that says what to do in the next ten minutes and makes you better at it over weeks.

Customer discovery

  • Voice of the customerCollected the sentences people actually say about this (next slide) and mapped each to the alternative that failed them: clinic, pills, free content, generic fitness apps.
  • Content auditWent through every lesson and workout of the inherited library: what was educational, what was a supplement pitch, what could not be claimed. The pitches went; the education stayed.
  • Category rulesSensitive-data consent, what a wellness product may claim versus a medical one, and what an app store would have refused.

Why now

  • Web-onlyA browser product avoids app-store review of sexual-health content and the platform fee, and reaches a phone without an icon to explain.
  • Platform readyThe company's payment and account platform could be reused through its SDK, so V1 could spend its weeks on content and funnel.
  • Content exists376 programme days could be rewritten as original material rather than commissioned from zero.

Customer discovery

Who buys this, and what actually hurts

Every product decision traces to one of these sentences. The alternatives fail them in predictable ways: a clinic costs a conversation, pills teach nothing, free content is endless and never sequenced, fitness apps treat the pelvic floor as an afterthought and ignore the head.

He says

"I finish too fast and I've started avoiding sex because of it."

"It works sometimes and not others, and I never know which tonight will be."

"I'm not going to my GP about this. I'm not taking pills forever either."

"I read that Kegels help. I have no idea whether I'm doing them right."

She says

"I love my partner and I just don't want it any more. I feel broken."

"I've never really known what works for my own body."

"Menopause changed everything and no one prepared me."

"Every article says something different and none of it tells me what to do today."

C. Phase 0.5 · Vision and strategy

These are trainable problems, not fixed traits

We believed that by holding the plan and setting the pace, in four to fifteen private minutes a day on a phone, adults who would never book an appointment would start a programme, pay for it, and still be there in week three.
The insight behind itControl, arousal and desire respond to practice the way strength does: the pelvic floor is a muscle under progressive load, performance anxiety is a loop that breaks with attention training, desire responds to stress and self-knowledge. All three need short repeated practice, correctly paced, which is exactly what people cannot self-administer.
Build vs buyPayments, accounts, subscriptions and CRM: bought, through the company platform's SDK. Content: rewritten as original material rather than licensed, because the claims and the voice had to be ours. Funnels, app and admin: built, as one application on one domain, because the hand-offs between them are where subscription products leak.
Strategic alignmentThe company runs subscription products on quiz-driven acquisition. IntimPath is that model in a category the app stores make hard, under a brand the company owns outright.

D. Phase 1 · Ruthless scoping

Seven programmes live, two hidden, and a short list of things I refused

One plan for everybody would be wrong for almost everybody, so V1 needed separate programmes per situation. Everything else was judged by one question: does it help someone come back tomorrow?

The MVP

  • Today, and nothing elseThe home screen shows two short lessons and one or two sessions. No library to browse, no backlog to feel guilty about. Progress is one dial and a stage name.
  • The workout playerA ring that expands and contracts at the exact tempo, a voice, an optional vibration. Ten levels mapped day by day, so the load climbs on its own.
  • Nine programmes, assessed at both endsLasting longer, erection quality, pelvic strength, rebuilding desire, learning your body, menopause, and a version written for queer women. Each starts and ends with the same self-assessment.
  • Three quiz funnels, one checkout, two offers52 to 60 screens from symptom to programme; three plans; one upgrade sold at two price points, prices editable without a deploy.

What I cut

  • Unfinished programmesTwo men's programmes with no days authored stay hidden until they are genuinely done, decided from the content registry, not a flag.
  • Supplement and cream pitchesStripped from every lesson; the education stayed. A wellness product does not sell you a cream mid-lesson.
  • Named specialists and app-store referencesPortraits and names we could not vouch for were dropped; the legal text lost every app-store clause.
  • A native appBrowser only, by design. No icon to explain, no review board, no waiting.

Constraints

  • A strict reviewerEvery merge request read line by line by the CTO. I ran a review and browser-QA pass before each one, and wrote the MR descriptions by hand.
  • A shared SDK I could not changePayments and accounts behave the way the platform decides. When it was wrong, the fix could not live in my repo.
  • Five languagesAbout 20,400 strings per language, with grammatical agreement correct per audience, so a German woman does not read a sentence written for a man.

The product

What the customer sees

Captured from the running application at phone size.

Today screen with two lessons and a workout
Just todayTwo lessons and a session. Nothing else to decide.
Workout player with a ring
Follow the ringIt sets the tempo and says when to contract and release.
Lesson explaining the pelvic floor
Know what you're trainingTwo minutes on the muscle nobody explained to you.
Women's programme day
Her own planNot the men's programme with different pictures.
The same day rendered in German
In her languageAll of it, not just the buttons.

E. Go-to-market and launch

From a symptom to the right programme, and to the offer

Acquisition is the quiz. Three funnels of 52 to 60 screens turn a symptom into a programme and an email into an account with no password; a parent of two or a man at 1 a.m. does not create passwords. Then checkout, consent, and a fixed ladder of offers with a decline path that never loses the first purchase.

Opening screen of the quiz
First contactThe quiz that turns a symptom into the right programme.
Checkout page showing current and goal state
The promiseWhere you are now, where the plan takes you. Three plans.
Upgrade screen
Going deeperThe one upgrade, for the people who stick.
Library of programmes and practices
When they want morePractices for a bad week, off the daily path.

E. Go-to-market and launch

The launch plan, and the day the payment callback lied

Launch strategyStakeholder walkthroughs on a live preview, not screenshots: I deployed preview builds so marketing, CRM and the CTO could click the real funnel. First customers come through the three quizzes from paid social, one funnel per audience, with the price catalogue mirrored locally so offers can change without a deploy.
The "oh sh*t" momentWhile testing the checkout end to end I found that a forged "charged" callback, sent to our endpoint without a real payment, would mint an entitlement on the published version of the shared payment SDK. A free subscription for anyone who read the network tab. The fix belonged in a library I was not allowed to patch. I kept the release clean: proved the hole with a reproducible test, wrote the bug report for the SDK owner, added a guard at our handler that verifies the charge before granting anything, and kept the SDK change itself out of the merge request so the release did not depend on another team's timeline.
What it taught the team"Bought" components still need a threat model on our side of the boundary. Every callback that grants value is now verified before it grants.

F. Results and learnings

A full product on the development environment, and the metrics that will judge it

IntimPath is complete and reviewed but not yet exposed to paid traffic, so the numbers below are what shipped and what I would measure, not vanity traffic.

376programme days as structured content anyone can extend
5languages, about 20,400 strings each, agreement correct per audience
335automated tests where there were none, guarding the rules a content edit can break
3quiz funnels of 52 to 60 screens, plus checkout and post-purchase offers
Initial traction to watchQuiz completion and email conversion per funnel. Day-1 and day-7 workout completion, because the whole bet is that people come back tomorrow. Upgrade take-rate and the save-offer's recovery rate on cancellation.
Next stepsFinish the two hidden men's programmes, wire the remaining guided audio, and ship the downsell offer that is tested and waiting for a go-ahead. Then the first paid-traffic cohort, one funnel at a time.
RetrospectiveI would write the content first and the app second; too much of the middle weeks went to rewriting lessons inside a finished shell. I would agree the SDK contract and its failure modes with the platform team in week one, not discover them in week ten. And I would translate as I wrote, not at the end.

Case study 3 · 0-1 build · Consumer subscription · Parenting

Lull: one honest companion for a baby's first year.

The brief said "sleep tracker". The parent's day did not. Ten weeks from that sentence to a beta a stakeholder can walk end to end on a laptop in a minute.

A. Executive summary

Lull, in one screen

The productA baby sleep and care companion for the first year: sleep predictions as windows with a stated confidence, the whole day on one timeline, two courses, a solids planner with an allergen ladder, and a quiz-to-checkout funnel, served from one application.
The target userA parent at 3 a.m., deciding from a phone about a person who cannot tell them anything, who has stopped trusting an app that gave a nap time as a fact and was wrong.
My roleSole product manager and builder, quasi-founder: problem framing, the three rules the product never bends, scope, the prediction engine's logic, content strategy, the funnel, and the implementation with AI coding agents. Payments come from the company platform.
TimelineTen weeks, July to September 2026, to a working beta: public site, funnel, checkout, app and API, plus devops and database handover documents.
0-1 buildParentingHealth-adjacentContent is the productSole PM

B. Phase 0 · The ambiguity and the problem space

It is 3 a.m. and the app just lied.

The mandate was a sleep tracker with a paid funnel. Reading how parents actually use these products changed what the product had to be: not more precise, but never wrong in a way that loses trust.

The spark

  • The brief"A baby sleep tracker, with courses, and a quiz-to-checkout funnel."
  • The problem underneathWhen should the next nap be? The app says 14:20 as a fact; the baby disagrees; the parent stops trusting the app. Is this a regression? Every rough week is labelled one. What is normal at this age? Six sources, six answers.

Customer discovery

  • The parent's daySleep, feeds, nappies, first foods and allergens, health, dressing for outside, growth, the parents themselves: split today across four tools and a group chat. The tracker had to hold the day, not one column of it.
  • The evidence basePublished age norms for wake windows and total sleep, month by month; which regressions the literature recognizes (four months biological, eight to ten developmental) and which it does not (twelve months is a schedule problem).
  • Competitors' trust failuresConfident times, invented "% of parents" proof, safe-sleep advice buried behind a paywall.

Why now

  • A category built on borrowed credibilityRatings and testimonials convert once; when a tired parent notices the numbers were invented, everything else the product says becomes suspect. Honesty was the open position.
  • Platform and funnel readyThe company's quiz-to-checkout pattern and payment platform meant V1 could spend its weeks on the engine and the content.

C. Phase 0.5 · Vision and strategy

Trust was the product. Everything else was derived from that.

We believed that by giving parents one honest companion for the whole first year, with sleep as the one domain that has a real engine and predictions shown as windows with a stated confidence, parents would keep logging past the first week, and pay for depth rather than for a promise.
Build vs buyThe prediction engine: built, from published norms plus per-baby learning, because a licensed black box could not be honest about its confidence. Payments, accounts, CRM: bought through the platform SDK. Content: written to a style guide, one calm specialist talking to one tired parent, every module cited. Images: licensed or generated, never scraped (see the launch crisis).
Three rules that never bendPredictions are windows with a confidence, never a time. Anything about medicine or safe sleep is said plainly and stays free. No invented social proof anywhere, enforced by a test.
Strategic alignmentFree stays free: the tracker, every article and age guide. Premium is depth: full courses, the solids planner, long-range trends, export, more than one baby. That maps to the company's subscription model without selling a parent something that should never be behind a paywall.

D. Phase 1 · Ruthless scoping

What I kept out mattered as much as what went in

Every "out" is a place where being wrong would hurt a family. Those are not features to ship fast.

In, for the first version

  • The tracker and the engineTen kinds of entry on one timeline; 28 monthly bands of published norms; per-slot learning; a transition declared only after seven days of evidence; tagged sick, travel and teething days shown but not learned from.
  • Two coursesSleep and starting solids, staged by age, audio first for a parent who cannot read right now.
  • Solids planner and allergen ladder100 first foods with age-banded preparation, nine allergens one at a time.
  • Dressing by weather, age-filtered guidanceAnd a quiz-to-checkout funnel that runs end to end, in a simulated mode before any payment processor exists.

Out, on purpose

  • Prescribing a sleep-training methodThe course explains the methods and the evidence; the app never asks you to do one.
  • Assessing any symptomThe reaction logger records and pauses; it never triages. Severe signs go to the emergency number, never to a form.
  • A community feedPeer advice about babies is a liability the product cannot moderate honestly.
  • Anything needing a clinician in the loopUntil a clinician has reviewed the age table and the allergen method, the product says less, not more.

Constraints

  • Solo, ten weeksAI coding agents as the team; a brief and rules written before the first line of code so the agents built against something.
  • Health-adjacent claimsEvery number the product shows had to come from one table, so a public page can never quote a wake window the app disagrees with.
  • Pre-processorNo payment provider yet, so the whole funnel had to run in a simulated mode for copy review and walkthroughs.

From why to what

A window, not a time. An engine built to be honest about it.

  • Start from published norms.Age minus weeks premature picks one of 28 monthly bands; day one gets the population's answer, labelled as such. No empty state.
  • Learn this baby, slot by slot.Each wake window is learned separately; the first window and the run-in to bedtime behave differently.
  • Never let one bad day move the estimate.Outliers dropped, recent days weigh more, the norm keeps a hand on the result.
  • Change regime as the baby changes.Under six months wake windows drive, from nine months the clock; a nap drop needs seven consecutive days of evidence.
  • One table of truth.Engine, public age guides and course text read the same per-month table.
Guidance screen naming the current wakeful phase
Guidance for this baby"Learning Mira's rhythm · day 2", then the phase the evidence recognizes.

The product

The public site, reading from the same table as the app

Courses, age guides and library pages quote the same per-month norms the engine uses. A page cannot disagree with the app.

Lull marketing home page Courses page Age guide page Library page Science page

The product

Inside the app

The course a tired parent can listen to, the log that takes ten seconds, the guide that says what is normal, and the one screen that reads the weather for you.

Course lessons screen
The sleep courseStaged by age, audio first.
Log sleep screen
Log sleepNap or night, tag the odd days.
Four-month sleep change guide
What is normalThe four-month change, explained.
What to dress them in for outside
Dress for outsideToday's weather, one answer.

E. Go-to-market and launch

How a parent arrives, and why the first screen is a question

A three-minute quiz is onboarding and acquisition at once: it opens with the parent, branches on the baby's age, and feeds the answers into setup. The email is the account; sign back in by link. Three plan lengths, a fixed ladder of offers, and a decline path that returns to the exact step.

Quiz: who is filling this in
Who is filling this inThe parent first, then the baby.
Quiz: how old is your baby
Branch on ageNot born yet to two years.
Email screen
Email is the accountNo password to abandon at.
Checkout
CheckoutNow versus with a plan.
Payment declined screen
Decline pathBack to the exact step.

E. Go-to-market and launch

The launch plan, and the week the food library turned out to be stolen

Launch strategyA beta, not a launch: first parents come from the quiz funnel in simulated-payment mode, so copy review and stakeholder walkthroughs happen on the real pages before a processor is wired. Every claim the product makes about itself is computed from the build, so the marketing cannot drift ahead of the product.
The "oh sh*t" momentWeek seven. The solids planner shipped with 536 food photographs, and I found they had been scraped from a competitor's site: copyrighted, unlicensed, and already published under our image path. In a product whose whole thesis is honesty, that is not a bug, it is the thesis failing. I pulled the set from the roadmap the same day, replaced the first foods with openly licensed photographs whose attribution is generated from the same data file the app reads, so credit travels with the image, and started regenerating the rest. Then I made it a rule: no image, audio or text passage is referenced by content until its source and licence are recorded.
What it taught the team"We have the content" is not a fact until provenance is. Provenance is now a field, not a memory.

F. Results and learnings

What shipped in ten weeks

Counts read from the build, not typed in. A working beta: public site, funnel, checkout, app and API, walkable end to end on a laptop in a minute.

28age bands of published sleep norms behind predictions, guides and courses
95course chapters across three tracks, every module cited and quizzed
100first foods with age-banded preparation; 9 allergens on a ladder; 228 recipes
54quiz screens across two funnels, one engine
306automated tests, including the tone and no-social-proof rules
10kinds of entry on one timeline
46library articles plus 16 month-by-month age guides
5locales routed; app strings translated

F. Results and learnings

What I would measure, what is next, and what I would do differently

Initial traction to watchQuiz completion and email conversion. The share of babies whose prediction reaches "personalized" by day seven, which only happens if parents keep logging: that is the retention metric for this product. Trial-to-paid, and course completion by module to see where the audio earns its keep.
Gates before launch, shown not hiddenA clinician's review of the age table and the allergen method. A full visual redesign. The remaining audio lessons and photography. Translations beyond the app strings. Payments, CRM, support and legal wiring. I keep this as a checklist with one status per line.
RetrospectiveI would record provenance for every asset from the first import, which would have saved the licensing week. I would bring a clinician in at the scoping stage rather than as a launch gate, because their review may still move the age table. And I would resist the whole-day scope a little longer: the engine and the course are the product; the rest earned its place, but it cost weeks I could have spent on a second baby's data.

Artifacts

Proof of work: the documents behind the decisions.

Sanitized excerpts of the real artifacts from each build: audits, trackers, evidence indexes, journey and state diagrams, handover checklists, devops documents and launch gates. Internal names and hosts removed.

Artifacts · Nire

Audit one-pager, change tracker, evidence index

The audit is written for two readers at once, counsel and engineering. The tracker holds the exact replacement copy per item so fixes apply verbatim. The evidence index makes every finding a file.

Nire compliance audit verdict table Nire change tracker excerpt Nire screenshot evidence index

Artifacts · IntimPath

Journey map, state diagrams, handover checklist

Diagrams live in the repository next to the code and render in the team wiki. The handover checklist was written so the project could change hands from one page, with assumptions marked as assumptions.

IntimPath customer journey and quiz end diagrams IntimPath checkout states and app entry diagrams IntimPath handover checklist

Artifacts · Lull

Devops handover, the licensing fix, launch gates

The build document lets devops run the product without me. The credits file is generated from data, so attribution cannot drift from the images. The gates list is the launch conversation, in writing.

Lull build and run document for devops Lull food photograph credits Lull pre-launch gates checklist

Background

Ten years of getting products to exist

2026
Three 0-1 builds, sole PM and builderNire, IntimPath, Lull: from ambiguous briefs to launch-ready products with AI coding agents as the engineering capacity.
Oct 2023 — now
Product Manager, subscription platform (under NDA)Owned paid funnels, onboarding, paywalls and segmentation on a high-traffic platform; 100+ A/B tests; shipped LLM-powered personalization and agent-based workflows. +24% conversion on acquisition flows, +31% on redesigned onboarding, win rate from ~20% to ~35%.
2022 — 2023
Product Manager, YouScanB2B social listening, end to end. Customer interviews drove vision and features; +18% free-to-paid on Dashboards, −19% churn after removing sales blockers; sunset redundant features.
2018 — 2022
Product Marketing Manager, DomenikLaunched new brands, websites and campaigns from nothing; wrote requirements for design and engineering; ran budgets and exhibitions.
2015 — 2017
Market Research AnalystMarket, competitor and sales analysis.
Education
MBA, Wisconsin International UniversityAI for Product Creation and A/B Testing at Projector Institute; GoPractice product management.

Toolkit for rapid validation and building

  • BuildClaude Code and AI coding agents as engineering capacity; Node.js, Express, React, Tailwind; SQL and migrations; git and merge-request flow, reading a diff and a stack trace.
  • ValidateQuiz funnels in simulated-payment mode for walkthroughs; preview deploys on Cloudflare Pages; browser QA on every changed flow; A/B testing programs and experiment guardrails.
  • Specify and trackMermaid journey and state diagrams; Excel trackers as the single source of truth; evidence indexes; one-page audits; handover checklists.
  • GuardRules as tests: claims lint, tone rules, no-social-proof checks, mutation-checked test suites; counts read from the build, never typed in.
  • CategoriesSensitive and regulated consumer products: sex, health and the body without shame or clinical distance; consent, privacy and claim discipline.

Contact

Looking for a PM who can take it from 0 to 1?

I am open to product roles where the problem is ambiguous, the users deserve honesty, and a PM who can build and ship the first version is an advantage. Happy to walk through any of the three builds live, including the trackers, the tests and the parts that are not finished.

Esther Mirzakhanyan

esther191189@gmail.com LinkedIn Download CV (PDF)

Nire screens are from the launch build and the audit evidence set. IntimPath and Lull screens are from the running applications; Lull is pre-launch and prices are omitted on purpose. Artifacts are sanitized excerpts.

1 / 1