Biren Nayak / PM

Product management · how I work

How I use AI across the product lifecycle

Honestly, it’s woven through my whole week now — discovery, PRDs, prototyping, and a lot of the grind I used to just push through. Three modes, really: a thinking partner, a build tool, and a co-worker that does the clicking.

Thinking partner

Synthesising research, drafting PRDs and stories, poking holes in my own edge cases, reading impact data, getting stakeholder comms to land.

Build tool

Clickable prototypes for concept validation, and scrappy local tools that hit other teams’ and third-party APIs.

Co-worker

Walking through user flows, scraping, and the one-off data entry that discovery and sanity checks always seem to need.

I’ve kept everything here generic — no real product or project details.

Foundation

A private skill that actually knows our system

This is the thing everything else leans on.

Before I do any discovery or spec work, I load a private Claude skill I built and keep current. It’s basically our system’s context in one place — architecture, service boundaries, the data model, and the constraints and tech debt that never make it into a Confluence diagram.

So when I’m writing acceptance criteria or reasoning about a flow, it’s anchored to how the system actually behaves rather than my best guess — and it pushes back when I describe something the architecture wouldn’t actually support.

The loop

From a friction point to a measured outcome

Roughly the path I run for each improvement — discovery through to a measured result. Open a step for where AI fits and what it produces.

The work

I start on the quant side. I instrument my own events through GTM, then read the behaviour across custom reports in GA, Looker / Data Studio, or the CRM, and in Clarity — session recordings, heatmaps, rage-clicks, funnel drop-off. Looking for where users hesitate, backtrack, or bail, and trying to tell real friction apart from noise.

Where AI comes in

Claude helps me shape the GTM tags and the GA / Looker report definitions, and Clarity’s built-in Copilot summarises the recordings and surfaces behaviour patterns I’d take hours to spot by hand. I use all of it to shortlist the frictions worth taking to the backlog.

Tools  GTM · GA · Looker / Data Studio · CRM · Clarity + CopilotOut  a prioritised list of friction points, each with the evidence behind it and a rough sense of effort

The work

Getting it to something engineering can pick up — problem statement, user stories, acceptance criteria, the non-functional bits, and the edge cases. All written against the system skill so it lines up with how things really work.

Where AI comes in

Claude summarises the research, gives me a first draft of the PRD, and is genuinely good at enumerating states and failure modes — the stuff that otherwise surfaces mid-sprint or in QA.

Tools  Claude + system skillOut  a dev-ready PRD, stories with acceptance criteria, and an edge-case list

The work

Getting the critical items — decisions, risks, trade-offs — in front of leadership in a form they can actually action, and pulling the right inputs back without a week of back-and-forth.

Where AI comes in

I draft the update, then run it through the Gemini browser extension to tighten it — cut the throat-clearing, lead with the ask. The escalation reads like an escalation, and I get a decision back instead of three clarifying questions.

Tools  Gemini (browser extension)Out  stakeholder updates and escalations that actually get a response

The work

Getting the flow concrete enough to react to. It’s far easier to align people on something they can click through than on a Figma frame or a wall of text.

Where AI comes in

Claude builds a working prototype straight from the spec — fast enough that it’s disposable, so I’m not precious about binning v1 after the first round of feedback.

Tools  ClaudeOut  a clickable prototype for concept validation

The work

Pressure-testing the experience against how other teams’ services and third-party APIs actually behave — in a lower environment, before it hits grooming or a tech review.

Where AI comes in

Claude builds me small local tools that call those APIs directly, so I can see the real responses, error states, and latency. I tighten the flow against that, and walk into tech and QA conversations already knowing which questions are coming.

Tools  ClaudeOut  throwaway test tools, and far fewer surprises once it’s in dev

The work

After rollout, checking whether the change did what the PRD said it would — pre / post on the target metric, the guardrail metrics, and the segments that matter. Not just “did it ship”.

Where AI comes in

Claude helps me build and read the GA, Looker / Data Studio, and Tableau views, compare pre and post cleanly, and write the readout so the outcome — or the miss — is clear to stakeholders.

Tools  GA · Looker / Data Studio · TableauOut  an impact readout: what moved, what didn’t, and what I’d do next

Alongside

Always on, not once a cycle

Two things that just run in the background of everything else.

Tracking my own progress

Claude is hooked into my Jira board and a tracking sheet. It pulls ticket status, flags what’s moved and what’s been sitting, and drafts my standup notes — so I’m reporting progress at 9am, not reconstructing it.

Claude + Jira + Google Sheets

Automating the busywork

Claude for Chrome in co-worker mode takes the repetitive stuff off my plate — clicking through user flows to check they still work, scraping data I need for research, and the one-off data entry that testing and sanity checks always seem to require.

Claude for Chrome · co-worker mode

Guardrails

How I keep it honest

A few rules so this stays useful and doesn’t bite me later.

Grounded, not guessing.

The system skill keeps specs and analysis anchored to how the product actually works — and Claude calls it out when I get a detail wrong.

I verify anything that leaves my hands.

Numbers, claims, edge cases — checked against the source before they go into a PRD or in front of leadership. AI is confidently wrong often enough that this isn’t optional.

Sensitive data stays out.

No customer data, no PII, nothing unreleased goes into a prompt. I work on the shape of the problem, not the raw records.

Stack

The stack

What each one is actually for.

Claude

My main workhorse — research synthesis, PRDs, prototypes, local tooling. Runs the private system skill and is connected to Jira and a tracking sheet.

Claude for Chrome

Co-worker mode for the browser work — flow checks, scraping, one-off data entry.

GA + GTM

My own product-event tracking — GTM to instrument events, GA or the CRM for custom funnel and behaviour reports.

Looker / Data Studio · Tableau

Dashboards and impact reporting — measuring whether a rolled-out change actually moved the metric.

Microsoft Clarity + Copilot

The qualitative side of discovery — recordings, heatmaps, rage-clicks. The built-in Copilot summarises sessions and surfaces the behaviour patterns.

Gemini

Browser extension I use to sharpen stakeholder and leadership comms before they go out.

Different tools, same habit: start from how the system actually works, verify what matters, make the call myself.

The line

What I don’t hand over

The parts of the job AI doesn’t do — and that I don’t want it to.

Deciding what’s actually worth building.

Discovery will hand me twenty problems. Knowing which one moves the north-star metric is the job.

Reading the room.

When to escalate, who needs to be in the pre-read, how hard to push on a trade-off before it costs me capital.

Owning the outcome.

“The model suggested it” isn’t a line I get to use in a retro.

Saying no.

Prioritisation only means something when someone’s accountable for what didn’t make the cut.