← Devika Naik

AI & Productivity

How I Use AI Across My Entire PM Workflow

Devika Naik · Jan 2026 · 11 min read

The honest truth about AI and productivity

I'll be straight with you: most writing about "AI for PMs" is too vague to be useful. Use ChatGPT for your PRDs! Summarize meetings with Otter! Fine, but that barely scratches the surface.

What I want to share is something more specific: over the last year, I've rebuilt my entire PM workflow around a set of AI tools - and it has genuinely compressed what used to take me weeks into days. Not because the tools are magic, but because I've figured out where exactly they unlock leverage in the product development cycle.

I run a personal workflow that goes: market research → idea evaluation → quick prototyping → launch for feedback. Every stage used to have friction. Now most of that friction is gone. This post is a walkthrough of the tools I use at each stage, why I picked them, and how I actually use them - not the idealized version, but the messy real one.

My workflow, end to end

Before I get into tools, let me quickly map the workflow so the rest of this makes sense. When I'm exploring a new product idea or feature, I move through four stages:

  1. 1

    Market research

    Understanding the space - who's in it, what users are saying, what's missing, what the opportunity size looks like.

  2. 2

    Idea evaluation

    Stress-testing the concept - surface the counterarguments, check assumptions, size the market, build a first-pass business case.

  3. 3

    Quick prototyping

    Getting something tangible - a wireframe, a clickable mock, or even a functional prototype - fast enough to show people before you've convinced yourself you're right.

  4. 4

    Launch and learn

    Shipping a minimal version, gathering real feedback, and using it to decide what to build next.

AI has touched every single one of these stages. Here's how.

Stage 1: Market research

Market research used to be my least favourite part of the job. Not because it's unimportant - it's arguably the most important - but because it was slow, repetitive, and involved a lot of tabs. Hours of Googling, reading G2 reviews, scanning Reddit threads, digging through App Store comments, synthesising it all into a coherent picture. Then doing it again when something changed.

Now I do most of this in a fraction of the time, and the output is sharper.

Research

Perplexity AI

Perplexity is where I start every research session. Think of it as a search engine that actually synthesises what it finds, with citations you can verify. Where Google gives me ten blue links to click through, Perplexity gives me a structured answer with sources - and it's fast enough that I can iterate on the query in real time.

My typical session: I'll open with a broad question like "What are the main pain points users have with B2B expense management tools?" Then I'll drill down - "What specifically do users complain about in Concur reviews?" - and synthesise across sources in minutes. For competitive landscapes, it's especially good: I can get a current-state snapshot of a market segment without spending half a day building a spreadsheet.

What it doesn't replace: actual user interviews. Perplexity can tell me what people say publicly. It cannot tell me why. User calls still matter.

How I use it: Initial market scans, competitor analysis, surfacing user sentiment from reviews and forums

Research

Claude (Anthropic)

Once I have raw material - a batch of user reviews, a competitor feature list, a messy set of notes from discovery calls - I bring it into Claude for synthesis and sense-making. Claude is better than any other model I've used at reading a large chunk of text and extracting structured insight from it without hallucinating things that aren't there.

My go-to prompt pattern: I dump 20-30 user reviews into the chat and ask it to identify the top five unmet needs, grouped by user type. Then I ask it to challenge its own analysis: "What might this be missing? What user segments might feel differently?" That second step is where you catch the blind spots.

One thing I've learned: the better your input, the better your output. I've started taking better notes in user interviews specifically because I know I'll be feeding them into Claude afterwards. The tool has made me a more disciplined researcher, not a lazier one.

How I use it: Synthesising qualitative data, stress-testing research conclusions, writing structured research readouts

Research

Gemini Deep Research

For longer, more formal research tasks - market sizing, industry trend analysis, regulatory landscape checks - I use Gemini's Deep Research mode. It runs a much longer agentic search process and produces a properly structured research report, not just a summary. Think of it as the difference between a quick search and commissioning an analyst brief.

I used this recently to understand the landscape of AI-powered financial planning tools in Southeast Asia before a strategy session. The report it produced covered market size estimates, key players, regulatory nuances by country, and emerging user behaviour patterns. It took me ten minutes to prompt and read. The equivalent manual effort would have taken me a day.

How I use it: Deep-dive market reports, industry landscape snapshots before strategy sessions

Stage 2: Evaluating ideas

This is where I think AI is most underrated as a PM tool. Not for generating ideas - everyone knows you can use ChatGPT for brainstorming - but for killing bad ideas faster.

The biggest waste of time in product development isn't building the wrong thing. It's building the wrong thing when you could have figured out it was wrong before you started. AI makes the pre-mortem stage much cheaper.

Evaluation

Claude as a devil's advocate

I've developed a specific ritual for evaluating new feature ideas. I write a one-page internal pitch - problem, proposed solution, target user, why now - and then I ask Claude to argue against it as hard as it can. Not just surface-level concerns, but specifically: "What assumptions am I making that could be wrong? What are the strongest arguments a competitor or investor would make against this?"

This sounds simple, and it is. But it's remarkably effective at surfacing blind spots before they become expensive. The best counterargument I've ever received from this process saved us from over-engineering a personalisation feature that our users would never have noticed - because the underlying problem was actually about onboarding, not preferences.

I also use Claude to build rough business cases. I feed it what I know about the addressable market, our current conversion funnel, and estimated development cost, and ask it to model a simple impact estimate. It's not a financial model - it's a sanity check. Good enough to decide whether the idea deserves a proper analysis or should be shelved.

How I use it: Pre-mortem analysis, assumption stress-testing, rough opportunity sizing

Evaluation

NotebookLM (Google)

When an idea is more complex and I need to synthesise across multiple inputs - user research, market analysis, competitor teardowns, stakeholder feedback - I put everything into NotebookLM and have a conversation with the material. It lets me ask questions across all my sources simultaneously: "Based on everything in here, where is the clearest user pain that isn't addressed by any existing solution?"

This is particularly useful before a big strategy session. I'll upload all my prep documents - sometimes 10-15 files - and use it to generate a structured briefing document for the leadership team. The briefing practically writes itself once the sources are in.

How I use it: Synthesising multi-source research before strategy sessions, generating briefing documents

The goal of Stage 2 isn't to confirm that your idea is good. It's to efficiently find out if it's bad. AI dramatically lowers the cost of finding out you're wrong early - which is always better than finding out after you've shipped.

Stage 3: Quick prototyping

This is the stage that has changed most dramatically in the last twelve months. The gap between "I have a product idea" and "I have something tangible to show people" has collapsed. What used to take a designer two weeks and a developer another two weeks to produce a clickable prototype now takes me two to three days, often working solo.

I want to be specific here, because there's a big difference between wireframing tools, design tools, and tools that can actually generate working code. I use all three, at different stages.

Design

Figma + FigJam with AI plugins

Figma is still my primary design tool, but the way I use it has changed. For early-stage ideation, I start in FigJam - it's looser, faster, and great for mapping user flows and rough screen layouts before you commit to anything. I use it to sketch the core flow in an afternoon, share the link with a couple of trusted colleagues, and collect async comments before moving to higher fidelity.

For Figma itself, plugins like Wireframe Designer and Autoflow have meaningfully sped up the wireframing phase. I can generate a set of baseline wireframes for a standard pattern (settings page, onboarding flow, empty states) and then customise them rather than starting from scratch every time.

The bigger unlock has been using Figma's Dev Mode in combination with AI-assisted handoff. Engineers spend far less time asking "what does this state look like?" because the spec is already there.

How I use it: User flow mapping, mid-fidelity wireframes, async design reviews before moving to high-fidelity

Design

v0 by Vercel

v0 is the tool I reach for when I want to go from wireframe to something that looks like a real product, fast. You describe a UI component or a full page in natural language, and it generates clean React and Tailwind code that you can immediately preview in the browser. The output quality is genuinely impressive - better than most junior designers, honestly, for standard UI patterns.

My workflow: I take my Figma wireframes, describe each key screen to v0, and get working HTML/React components back. I then assemble them into a clickable prototype using a simple Next.js scaffold. This produces something that looks and feels like a real product, not a Figma mock - which makes a huge difference in how users interact with it during testing.

I used this approach to build a prototype for an AI-assisted financial insights feature. Total time from wireframe to interactive prototype: about six hours. The feedback session I ran with it surfaced three critical navigation problems that would never have come up in a Figma prototype, because users were actually clicking through a live interface.

How I use it: Converting wireframes to working UI components; building realistic interactive prototypes for user testing

Design & Build

Cursor

Cursor is an AI-native code editor, and it's the reason I can build functional prototypes without waiting for engineering bandwidth. I'm not an engineer - I can write basic HTML, CSS, and a little JavaScript, but I'm not shipping production code. Cursor lets me operate several levels above my actual coding ability by providing intelligent suggestions, explaining what code does, and helping me debug when things break.

My typical use: I'll take the components v0 generated, open them in Cursor, and wire them together into a functioning prototype with real navigation and state. If I want to add a simple data table with mock data, or a toggle that changes the view, I describe what I want in natural language and Cursor writes the code. I review it, ask it to explain anything I don't understand, and iterate.

This is not the same as engineering. I'm not writing scalable, production-ready code. But for a prototype that needs to survive five user sessions? It's more than good enough, and it's built in a day instead of a sprint.

How I use it: Building functional prototypes, adding interactivity to v0 components, quick data visualisation experiments

Design & Build

OpenAI Codex

Codex is a legitimate alternative to Cursor, and several PMs I know use it exclusively. The output quality is genuinely comparable - both can take you from a plain-English description to working code in seconds, and for straightforward UI components there's not much between them.

Where I find them different is in the back-and-forth. When something breaks or I want to change direction mid-prototype, I find Claude better at holding context across a long session and explaining why it made the choices it did. That matters when you're not a trained engineer and actually want to understand the code, not just run it. Codex tends to produce the answer; Claude tends to produce the answer and walk you through it, which is more useful when you're building at the edge of your technical comfort zone.

If you're already in the OpenAI ecosystem, Codex is a fine choice. I just keep returning to Claude for that teachability.

How I use it: Occasional cross-check when I want a second model's take on a tricky component

No-code

Lovable

When I want to skip even Cursor's lightweight coding and go directly from idea to working app, Lovable is my shortcut. It's a no-code/low-code AI tool that builds full web applications from a description. You can connect it to Supabase for a real backend, add authentication, and have something that a user can actually sign up for and use - not just click through.

I've used Lovable to spin up a functional beta in less than a day: real sign-up flow, basic CRUD operations, a simple dashboard. Nothing scalable, but entirely real. I then run that beta with ten to fifteen early users for two weeks, collect structured feedback, and use that to write the actual product spec for engineering. The quality of feedback I get from a real (if rough) product is an order of magnitude better than feedback on a mockup.

How I use it: Building lightweight functional betas for early user validation; replacing "slide deck pitch" with "actually try it"

Stage 4: Launch and learn

Getting something in front of users is only half the job. The other half is interpreting what you learn. This is where the feedback loop closes - and where AI helps me move faster from raw feedback to clear decisions.

Research

Dovetail

Dovetail is my research repository. Every user interview gets transcribed and uploaded here. Every usability test recording goes in. Every batch of survey responses. The platform uses AI to surface themes and patterns across your research - but more importantly, it makes your research searchable and shareable, so it doesn't disappear into someone's Google Drive three months later.

After a round of user testing with a prototype, I'll use Dovetail to tag key moments in the recordings, pull out quotes by theme, and generate a research readout in half the time it used to take. The themes it surfaces aren't always right - I always review and edit the AI-generated analysis - but it's an excellent starting point that usually captures the 80% that's obvious and lets me focus my attention on the nuanced 20%.

How I use it: Organising and analysing qualitative feedback from user interviews and usability tests

Writing

Claude for writing and communication

Once I have research insights, I need to communicate them - to engineers, to leadership, to stakeholders who weren't in the room. This is where Claude shows up again. I use it to turn a rough outline and a set of bullet points into a polished PRD, a one-pager, or a strategy memo.

My process: I write the core content myself - the arguments, the data, the recommendations. Then I ask Claude to improve the structure, tighten the prose, and flag anything that's unclear or unsupported. I treat it like a very capable editor, not a ghostwriter. The thinking is mine; the polish is collaborative.

The part I never skip: reading the final version aloud before sending. AI-generated prose can sound fluent but feel slightly off - too formal, too hedged, or subtly not like you. Reading it aloud catches those moments instantly.

How I use it: PRDs, strategy memos, research readouts, stakeholder updates, release notes

The most important thing about Stage 4 is speed - specifically, the speed at which you can go from "we shipped something" to "we know what to do next." AI doesn't just help you move faster inside each step. It compresses the time between steps, which is where most of the delay actually lives.

What this actually looks like end to end

Let me make this concrete. Here's a recent example: I had a rough idea for a feature that would surface spending anomalies for business users - something like "your SaaS spend spiked 40% this month, here's what changed." A meaningful idea, but I'd heard similar ideas die in roadmap reviews before.

Here's how the full cycle ran with AI:

That used to take six to eight weeks. It took ten days.

One thing I've learned the hard way

Early on, I tried to fully automate my research synthesis - piping outputs from one tool into another without reading them carefully. It produced faster garbage. The value of AI in this workflow is not removing your judgement from the loop. It's clearing enough space in your day that you can actually apply that judgement where it matters.

AI tools amplify the PM you already are. If your research is shallow, you'll synthesise shallow research faster. If your prototypes don't reflect real user problems, you'll build non-solutions faster. The cycle compresses - but the quality of thinking behind it still depends entirely on you.

What's shifted for me is where my time goes. Less of it on the mechanical parts - research aggregation, component scaffolding, writing first drafts - and more of it on the parts that actually require being a PM: talking to users, arguing about tradeoffs, deciding what not to build. That's the unlock. And honestly, it's made the job more interesting, not less.

← Devika Naik