It’s been roughly 90 days since Intuit launched its 3x productivity initiative, provisioning Claude Code access to every single employee. They’re just one of many enterprises making the same bet to become AI-pilled and triple their productivity or risk obsolescence.

Across the industry, this bet has split organizations into two camps based on how they think about consumption:

On one side are the inputs-as-virtue leaders, who treat token burn as evidence of cultural transformation. They look at their workforce and conclude that human behavioral inertia is a Sev 0 threat. Setting $50,000 on fire so an employee can learn to use 10 billion tokens is a cheap tax for future-proofing the company. On the other side are the inputs-as-surveillance leaders. Performance reviews may be tied to consumption, and as a result, employees generate reams of unverified, fluffy, polished-looking AI slop.

Both camps are chasing the same 3x, but neither can verify they’re getting it. Token consumption can’t tell you whether the work is better, faster, or worth more than it costs. It can only tell you that tokens were used. Employees, sensing they’re being measured on consumption, are churning out volume to max out their allotments regardless of usability. Management watches usage climb and calls it transformation. It’s a textbook Goodhart’s Law failure: we’re incentivizing raw consumption with the goal of productivity, but optimizing for the former is corrupting the latter.

The instinct is to pick a side: either champion tokenmaxxing and accept the slop, or outright demand outcomemaxxing before employees have any foundation for what good looks like, disengage, or fall back on what they already know. But both are wrong when viewed as fixed policies. They miss the reality of how human beings learn. Tokenmaxxing and outcomemaxxing are just sequential phases of organizational maturity, and Goodhart’s Law applies differently in each.

The mistake most companies make is applying a point-in-time, static policy to a dynamic learning curve. You can’t demand ROI from someone who hasn’t figured out what the tool can do, and you shouldn’t subsidize brute-force burning from someone who has. To navigate this, management has to guide employees through three distinct phases, and recognize when to move.

One structural note: these phases apply per function rather than company-wide. I’d expect engineers running Claude Code through agentic loops to exit Phase 1 in weeks while a marketing team experimenting with drafting and synthesis to need months. For larger organizations with greater heterogeneity, there will likely be two or three phases running at once as the expected state.

phase 1: mandated tokenmaxxing

In the first 90 days of rollout, the primary goal is behavioral change, not efficiency. Any workforce will sort into roughly three groups:

1. Non-believers who tried it once, got a mediocre result, and abandoned.

2. Eco-conscious budgeters who feel guilty of wasting electricity and money and self-cap before they discover the upside (btw, here’s how much electricity it uses)

3. Power users – but at this stage, every power user is a Slop Cannon. Turbo Brains don’t exist yet; they’re Slop Cannons who survive Phase 2.

I’d argue Groups 1 and 2 deserve the most attention because re-activating a churned skeptic is harder than coaching an enthusiast towards discipline.

Management should give everyone an effectively unlimited budget, mandate the latest models, and actively tell employees to be wasteful on purpose. Push the models until they break. Try the absurd prompt. Burn an afternoon on a workflow that ends up not panning out. The goal is to trade short-term financial efficiency for long-term behavioral transformation.

The math checks out: If an employee’s salary is $150,000, capping them at $500/month in tokens to “protect the bottom line” is absurd if uncapped access could plausibly make them 3x more productive. The $50K you spend on tokens is buying you the option on a 6-figure productivity gain you can’t access any other way.

The Goodhart trap in Phase 1 is the inverse of what you’d think: you want people to chase the consumption metric, because the friction of adoption is the actual bottleneck. Slop is the cost of breaking the blank page problem.

You’d want to exit Phase 1 when weekly active usage stabilizes above ~70% without prompting, and senior ICs start complaining that reviewing AI output is eating their week. The second signal is the more important one because it means you’ve succeeded at adoption and created a new problem.

phase 2: pivot to preceptorship

Phase 1 succeeds when senior ICs and directors become slop janitors – drowning in volume from juniors who’ve perhaps learned to generate but not to judge. This is the most dangerous phase, because it looks like the system is working (token usage is up! adoption is universal!) when the work has just been offloaded to a different (most expensive) group of people.

The single highest-leverage move here is to shift review from outputs to prompts. Borrowing from healthcare, directors should become AI preceptors. When a junior submits sub-par work, the feedback isn’t about the deliverable. It’s:

Show me your context window and your prompts. Let’s refine your .md files.

This single reframe does more than any policy change. It turns every review into a teaching moment, it makes prompt quality a visible artifact, and it kills the incentive to ship volume – because volume without good context just produces more work for the reviewer to dismantle.

Strategies in this phase could include tapering the universal token budget so consumption stops being a virtue signal, introducing high-taste automated linters or secondary AI review agents as a slop filter before human review, and starting to grade employees on whether they’re building systems that level up their peers.

The Goodhart trap to note in Phase 2 is that tokens-per-employee falls, and management declares victory on “efficiency” while the actual problem (judgment, taste, context) goes unmeasured.

You’d want to exit Phase 2 when prompt quality, not adoption, is the bottleneck – and when a handful of Turbo Brains have emerged who can demonstrably ship reusable workflows that other people use.

phase 3: return to rigor with outcome grants

Once the behavioral shift has stuck, orgs can transition off universal unlimited budgets and onto outcome grants. If a Turbo Brain can prove a specific workflow saves their team 10 hours/week (inclusive of vertical and horizontal stakeholder alignment), their department unlocks a dedicated uncapped pool for that workflow.

The unit of reward is the reusable scaffold: a prompt library, an internal tool, a documented workflow, an agent that other people can pick up and run. You’re rewarding the thing that compounds, not the person who happened to build it. This matters because the alternative – rewarding individual productivity gains – recreates the same Slop Cannon dynamics one level up.

Outcome grants should be jointly approved by the function head (who can attest to the work) and finance (who owns the budget). Neither should own it alone since function heads may rubber-stamp and finance may starve good ideas.

What about employees who don’t graduate into Turbo Brains? They keep a reasonable baseline allotment for daily work, with their manager’s preceptorship still available.

We could counter the Goodhart trap in Phase 3 by funding attempts at scaffolding, not just successes, to avoid any drifts back toward conservative use of AI.

how companies could stagnate

To get to 3x productivity, organizations will want to progress to phase 3 as quickly as possible without sacrificing the foundational integrity established in the previous phases. You’ll want to watch out for signals of missing foundational pieces that could cause an organization to standstill.

In Phase 1, focus on quality once adoption numbers take hold. If not, token usage could climb, senior ICs could become full-time slop janitors, and no one will pull the trigger on preceptorship to progress on productivity.

In Phase 2, watch out for preceptorship becoming a permanent state where no one is trusted to operate independently, every workflow still requires a senior reviewer, and Turbo Brains never get the room to build. You’ll want to look at scaling quality and enable to deploy org-level judgment once it’s developed.

Be cautious of jumping straight into Phase 3. By skipping the foundational phases and gating everything on outcomes from day one, you risk adoption for the majority. This is where eco-conscious budgeters may self-cap before they know what’s possible, where Turbo Brains work in isolation without bringing the rest of the organization with them, and where managers may not realize the competence wasn’t broadly built because exploration was never funded.

teaching resilient adaptation

When Claude 5 (or the next leap) lands, it’s expected that parts of the org will snap back to Phase 1. Old prompts will break, new capabilities will emerge, and exploration will start over.

What’s critical for organizations is to cultivate problem-solving skills by developing a culture of play. AI has democratized the ability to build more than ever before, and the best way to understand it is to make stuff with it. This means budgeting for temporary efficiency dips as the expected cost of learning by making. The organizations that understand this don’t treat exploration as a waste. Instead, they deliberately fund exploration, protect it from short-term efficiency pressures, and build it into how teams work.

Orgs that do this don’t scramble when the next evolution of tools and capabilities land. They’ll treat it as Phase 1. That capacity to reset, explore, and build will be one of the only remaining durable advantages in a market where every competitor has access to the latest Anthropic releases.

Knowledge workers in tech are racing to go ‘AI-native’, or get left behind. For engineers, that’s a natural extension of how they already work. For everyone else – PMs, designers, ops – there’s a sizable gulf of execution to overcome.

Setup is one problem: dependencies, CLI tools, and config files that assume prior knowledge can get very confusing, very quickly.

Knowing which MCPs to install is another. Every function has its own process, and tools like Claude and Cursor are broad enough that the path to start is genuinely unclear. The current enablement model is self-serve: go read the docs, and figure it out.

What’s missing are curators – people who define opinionated paths and embed the knowledge into a guided setup.

So that’s what I built this past week: a multi-session onboarding system in Claude Desktop that takes PMs to fully tooled and ready to hit the ground running, no terminal experience required.

why claude desktop

There’s a catch-22 with AI tooling setup. If you don’t already have Cursor or Claude Code installed, you can’t ask them to install themselves despite how good they are at self-correcting. Claude Desktop breaks that loop, making it as simple as installing an app, and from there it can orchestrate everything else.

design decisions

The system has three phases: environment setup, tool connections, and building your first skill.

setup

Each phase is its own skill you invoke in Claude Desktop. /check-setup detects what you already have and only walks you through what’s missing. Every terminal command comes with a plain-English explanation and a verification check. All you need to do is copy-paste the command, see the output, and answer a question about how it went.

tool connection

The tool connection phase (/connect-tools) wires up Slack, Jira, Google Drive, Figma, and GitHub across Claude surfaces. Each tool has its own sub-guide because the auth flows are different – some are click-to-authorize, some need MCP plugin config. Bundling them would’ve created a wall of text that breaks the moment one tool changes.

building a skill

Phase 3 is building the skill (/build-skill) to apply the integrations. It teaches PMs how to create a custom Jira ticket-writing skill tailored to their specific team. The end state is for AI to actually be useful for your context. That’s the main difference between setup with tools installed and AI enablement.

safety net

As a safety net, there are two skills that support the user throughout this process:

1. /my-progress tracks exactly where you are so you can stop and pick up days later.

2. /escalate tries up to five automatic fixes when something breaks. If none work, it drafts a Slack message to the right support channel with everything that was tried and tags the right people. This ensures that no one is left stranded.

The whole system is built on the premise that you don’t need to be technical to benefit from AI tools. The people who understand the technology have a responsibility to make it accessible by building paths that meet people where they are, rather than writing more docs. This is one attempt at that.

demo

I can’t share a recording of how it works since this is set up on my work laptop. Instead, I’ll share the project structure and the overall project instructions I used which could in theory be scaffolded to create your own version.

project structure

It’s set up as a Claude Project skill organized as a router pattern, where one central skill file routes to phase-specific reference files.

architecture pattern

The whole thing follows a progressive disclosure router design: SKILL.md dispatches → phase routes (check-setup.md, connect-tools.md) triage what’s needed → sub-files handle individual tools with step-by-step instructions, expected outputs, troubleshooting tables, and escalation hooks. State is persisted across sessions via Claude’s storage API under the key onboarding:progress.

entry point

SKILL.md – This is the master routing table and configuration that Claude reads first. It defines the skill’s trigger keywords, core principles, the progress tracking schema (JSON), Slack channel IDs for escalation, and the routing table that maps user commands to reference files.

phase 0: welcome & orientation

start-here.md - This is the front door that handles first-time users by auto-detecting their Slack profile, checking prerequisites like training courses and access requests, showing the journey overview, and personalizing examples based on which group they belong to.

phase 1: environment setup (router + 3 sub-files)

check-setup.md – Smart router for Phase 1. Triages what the PM has already installed and only walks them through what’s missing. Routes to three sub-files:

• setup-foundations.md – Prerequisites: macOS version check, Homebrew install, Node.js, and Git. Each tool gets a plain-English analogy before the install command

• setup-cursor.md - Download Cursor, SSO login with company credentials, 60-second orientation tour, optional AI model configuration

• setup-claude-code.md - Request access via admin portal, install the CLI, first login with SSO, handle the common SSL certificate error, verify with claude doctor

phase 2: connect tools (router + sub-files)

connect-tools.md – Smart router for Phase 2. Explains connectors vs. MCPs, triages what’s already connected, determines which Claude surfaces the PM has, then walks through each tool. Routes to five sub-files:

• connect-slack.md

• connect-jira.md

• connect-gdrive.md

• connect-figma.md

• connect-github.md

phase 3: build first skill

build-skill.md - This guides the PM through creating a custom Jira ticket-writing skill, but any skill can be defined here as their hero example.

cross-cutting utilities

• my-progress.md - Progress tracker that loads PM’s state from persistent storage and renders a visual dashboard. Suggests the next logical action, surfaces active escalations, and offers to post a compact progress card to Slack

• escalate.md - Escalation flow triggered after 5 failed troubleshooting attempts or manually via /escalate. Gathers full context (who, phase, step, tool, all attempts, error text, environment), routes to the correct Slack support channel, drafts a formatted message tagging the program leader and logs the escalation to persistent storage.

reference files

• common-errors.md – This file contains error pattern matching for self-healing before escalation. Errors are collected and synthesized from the support channels.

Instructions

## Instructions
You are the onboarding assistant for [group name] product managers. Your job is to guide non-technical PMs through setting up Claude and AI tooling using a structured, multi-session onboarding flow.

**How you work**
When a PM starts a conversation or says “/start-here”, read the SKILL.md file first to understand the routing table, then read the appropriate reference file before responding. Always check for existing progress in persistent storage at the start of every session so PMs can pick up where they left off.

When a PM reports any error, read references/common-errors.md first and attempt to self-heal before escalating.

Route commands to the right reference file:
- /start-here → start-here.md
- /check-setup → check-setup.md (smart router → setup-foundations.md, setup-cursor.md, setup-claude-code.md)
- /connect-tools → connect-tools.md (smart router → connect-slack.md, connect-jira.md, connect-gdrive.md, connect-figma.md, connect-github.md)
- /build-skill → build-skill.md
- /my-progress → my-progress.md
- /escalate → escalate.md
- Error reported → common-errors.md

**Smart triage:** Don’t assume everyone starts from zero. Check what’s already installed/connected and skip completed items.

**Always a path to escalation:** When something goes wrong, try to fix it (up to 5 attempts with different approaches). Track every attempt. If still stuck after 5 attempts, auto-draft a Slack message to the right support channel with full context and tag the appropriate people. No PM should ever feel stranded.

**The three tools:**
By the end of onboarding, every PM should have:
- Claude Desktop (claude.ai) — Chat interface for research and guided workflows
- Cursor — AI-powered editor for files, documents, and projects
- Claude Code — Claude in the terminal for hands-on tasks and automation

Frame these as “three doors into the same brain — each optimized for different work.”

**Tone and approach**
- Warm, patient, jargon-free — like a friendly colleague, not a technical manual
- Use progressive disclosure — one step at a time, never dump everything at once
- Always use analogies before introducing technical terms
- Show the exact command and expected output for every step
- Celebrate small wins along the way
- If something fails, stay reassuring: “This is really common — let’s fix it together.”

**Key details**
[any context about channels, support channels, people, org context]

The system itself is unvalidated, but the pattern is what I’d want to see more of – opinionated, guided paths that meet people where they are. It’s the kind of onboarding experience I’d hope to see built natively into tools like Claude Code and Cursor so we can further lower the barrier to entry and build more inclusive AI for people of all backgrounds.

Every day, there is a new tutorial, a new starter pack, a new repository of skills.md touting “the best” in the industry. I don’t buy it anymore.

When anyone can write a skill in an afternoon, you get a proliferation of content with no governance for what’s actually good. If you work in an enterprise company and are writing a strategy doc, “good” will be based on your organization’s standards and house style. What I’m finding is most of the creators of these skills don’t work with the messiness of enterprise data or have existing standards to work with. They’re building off clean slates — early-stage companies with no baggage, or freelancers building theoretical skills that aren’t grounded in today’s reality. These creators are just really loud marketers.

After trying a few skills myself, I’ve found it’s hard to realistically apply this to my day-to-day. Is that just me? To me, skills are like boilerplates. They may get the bulk of the framework down but a lot needs to get re-worked and adjusted for a polished document that packs maximum meaning and subtext into each word and sentence. I will revise 30-40% of the content because the context of the delivery and my audience is always slightly different.

I think the trick is to treat skills like ML models: benchmark the new one against what you already have, prune what’s stale, and fold in what’s tested and proven.

Which is why I personally recommend everyone to test themselves! Start with something, then benchmark it and use your taste to refine it. You are the expert of your team, your processes, and how your craft fits into the way things actually work at your company.

Now getting off my soap box, here’s how I used Claude this past week:

Note: What works for me isn’t necessarily the correct, de facto way to go! Try for yourself.

A/B testing my writing

How do you codify your taste in writing?

First, I started with my strategy document stored as a markdown copy.

Then I used the prompt:

Given this strategy document <reference to file>, interview me using A/B examples to help refine the style and tone. Present me with two options for a paragraph. First, critique both options. Then ask me which I prefer and why. Use my answers to write a 1-page ‘Essence’ document summarizing my taste in this domain.

By default, Claude Code will visualize the example options in the terminal window and you can step your way through each feedback round directly in chat by just answering Claude’s questions and hitting enter.

Claude generated two variations in each round, and for each round I would use the voice feature to riff on what I liked and didn’t like for each option and why.

Next, Claude would take my feedback and deliver a new set of variations in a new round. For the paragraph I was working on, Claude presented 6 rounds:

1. Narrative vs. Structure

2. Thesis first: Tight vs Supported

3. Synthesis: Evidence density

4. Refined: Sentence rhythm & precision

5. Thesis clarity & closing strength

6. Specific thesis statement

As an example of variations, it presented these two option critiques in Round 2:

Option A: Ultra-concise — four sentences, one framework, done. Any audience walks away knowing the thesis. Risk: it may feel too sparse for a strategy doc where stakeholders expect to see the evidence that led to the conclusion. The research is entirely absent; you’d need to trust that the Problem section carries all the proof.

<revised content underneath>

Option B: Leads with the same clear thesis, then immediately supports it with one tight evidence block before closing. Gives the reader the ‘why should I believe this’ without burying the point. Risk: slightly longer — the research paragraph adds weight but could feel redundant if the Problem section already covers defection data. The customer quotes add texture but lengthen the section.

<revised content underneath>

By the end, it captured my ‘taste’ in a ‘writing essence’ file that I can now reference for every new document I write.

Creating a local copy of components

How do you prototype with your product’s real UI without cloning the entire codebase?

When your company has a poly-repo and all you want to do is create realistic prototypes with the design library, cloning the whole thing is overkill. Instead, I made a local copy of the components from the Storybook catalog of UI components so I can quickly whip up lightweight prototypes without worrying about the extra backend dependencies. To do this, I provided a URL and scraped the HTML and CSS for the components to build in my local repo.

Enriching Jira tickets

How do you turn a brain dump into a ticket an engineer can actually act on?

I logged a few bugs for a testing session and wrote up a test plan. Then I used Claude Code to enrich the tickets with detail and formatting. It’s quite nice to be able to brain dump a soup of thoughts and out comes a highly structured and thoroughly documented ticket with a detailed description, steps to reproduce, expected behavior, and actual behavior, written out for engineers to debug and fix.

I also used it to identify edge cases and acceptance criteria I missed. For example, I’ve been working on a feature that involves spreadsheet upload and extraction. Claude surfaced edge cases I hadn’t considered: browser refreshes during extraction, uploading a spreadsheet with mixed date formats or multiple worksheets in one .xlsx, and race conditions where the screen loads before our experimentation platform can make an assignment call — all valid and realistic test cases I wouldn’t have caught until they broke in production.

Searching through institutional knowledge

How do you separate signal from noise in a flood of internal AI content?

A fun way I used Claude Desktop (not CLI) recently is to search through our Slack for where the high-signal-to-noise, high-volume Claude Code activity was. Where are the super curious, super smart people using it? How are they using it? Because almost everyone is using it and sharing how they’re using it, you get a lot of noise.

I asked Claude to look for channels based on concrete engagement signals such as Slack reaction counts, thread depth, number of follow-up questions it resolved, and cross-channel references. Resources with fewer than 3 community engagement signals were excluded.

A few interesting insights I found when mining Slack:

1. Power users were in Tel Aviv, Israel - a hot spot of innovation and members sharing best practices for AI coding workflows.

2. Our #cmty-claude channel, which is intended to be a community for sharing Claude Code resources, was being used instead as a support channel with a lot of members asking questions about their setup.

It seems the best signal was almost never where you’d expect it. Official channels collected FAQ-style noise while real workflows surfaced organically in team channels.

Next week, I’ll write about turning that signal into something useful — an opinionated onboarding guide to AI tools at work curated across teams and functions.

Another week, another $50 using Claude Code at work. This week was more token-intensive than the last since I’ve been writing docs that require synthesizing a massive amount of context.

My three focus areas were preparing for an upcoming launch (which meant writing user acceptance test cases for a bug bash), prepping to talk about that launch (meaning more writing, but a Product Forum 6-pager), and writing a strategy for next year.

Here’s how I used Claude Code for each:

writing test cases

At Intuit, the responsibility for user acceptance testing falls squarely on the product manager. We’re the bearers of the quality bar and the gate-keepers of what gets shipped. If a customer goes through a bad experience, it’s on us to rally the team and fix it. That means when it comes to launching new features, we’re the ones writing test cases to uncover bugs in the experience.

Last week, I was preparing to launch a new experiment testing how two new design variants on an intro screen impact engagement. This means four paths to test: the control baseline, the experiment baseline, Design Variant A (slight improvements), and Design Variant B (a big-swing re-frame).

Since most of the expected behavior was already captured in Jira tickets and PRDs, I figured I could auto-generate the test cases and transfer them into a Google Sheet. I used Claude in my terminal to draft the scenario descriptions, steps to test, and expected behaviors by reading Jira tickets and Figma screenshots.

Quite a few issues came up on my first run:

1. Hallucinated happy paths: I didn’t provide enough context about how the screens linked. Claude assumed Variant A linked to Variant B on some navigation paths, or that a “Continue” button in Variant B mapped to a new screen when they were actually unrelated.

2. Formatting friction: I initially copied the text directly from the terminal chat and pasted it into Google Sheets, which carried over funky indentations and spaces.

Tip I learned after much struggle: When copying text from Claude Code chat, use the pbcopy me command rather than selecting and copying directly from the terminal window. Terminal selection copies the rendered output, which can include non-breaking space, tab-to-space misalignment, and invisible Unicode characters — all of which create weird indentation and spacing when pasted into docs. Piping through pbcopy gives you clean plain text without the extra ~funk.

I’d rate this use case an 8 out of 10. Minus a few necessary human edits, it did the heavy lifting with much greater detail and speed than I could manually. With four experiment paths, each with its own screens, buttons, and expected behaviors, the test matrix expanded quickly (I ended up with ~60 test cases.) Next time, I’d probably do this in Claude Desktop with the Jira/Figma/Drive connectors set up, prep the inputs better, and write a custom skill for it to eliminate the copy-pasting entirely.

writing product forum document

We have a ritual called “Product Forums”, similar to Coda’s Bullpen, where anyone can present a topic to get feedback or share their craft for visibility. I’m signed up to share progress on an initiative, which requires a 6-pager pre-read doc to keep the actual meeting focused on high-impact questions.

Luckily, I had a lot of working documents saved as markdown files, alongside manually crafted templates from past forums. I started a new session, used the voice feature (press+hold spacebar) to set the context, and prompted:

"Hey, I’m writing a document similar to [reference doc] but on this new project. Refer to [customer-interviews] and [analytics-findings] for the qualitative and quantitative learnings. Refer to [decision-doc] for the design variants we considered and our rationale. Use the AskUserQuestion tool to interview me in detail."

3 out of 10. The first draft definitely wasn’t immediately usable (more on that later), but it was an excellent seed starter to revise and edit off of. It got me past the blank page which is always my biggest opp in writing. Still, I had to overhaul a lot of the narrative structure.

writing strategy

It’s that time of year when leadership puts pen to paper on strategy. By far, this task was the most iterative and arduous for me+Claude.

Strategy is notoriously complex. As Chandra Janakiraman highlighted in Lenny’s Newsletter, it requires a ton of inputs: behavioral insights, UXR, competitive analysis, leadership interviews, and adjacent roadmaps. For a small startup, this might be easy to procure and synthesize. But for a large, established enterprise with hundreds of historical documents, versions, and fragmented insights, it’s incredibly hard for AI (and even me) to filter the noise.

I tried anyway. I used the voice feature to set context, fed it vetted docs, and told Claude to use placeholders for data and quotes that needed verification or could strengthen the narrative. It required heavy cache reads/writes and multiple versions.

Tip: Formatting your context to save tokens

If you’re pulling context from Google Docs, be careful with markdown exports. Exporting a doc with images creates massive base64 image tags, which will quickly inflate your token usage and costs. I learned it’s much better to just copy and paste the text directly to bypass the images altogether.

Also, navigating Intuit’s slide-heavy culture meant I had to make a lot of decks AI-friendly. I fed them into Claude Desktop and prompted it to convert the presentation into markdown slide-by-slide, making sure to tell it to ignore header and skipped slides. What was really neat was that at the end of the chat, Claude automatically offered a button to open the newly formatted document directly in Cursor.

2 out of 10. The first few drafts were not great, but again, they got me past the blank page. While I didn’t feel I could completely hand off this work to Claude, I did find it useful to have an idea sparring partner to go back and forth with until I got to something more usable.

reflection: the hard part isn’t the technology

Right now, the consensus among PMs is that AI isn’t “there” yet for complex tasks like strategy. It is still a heavily human-led endeavor. I agree with the sentiment, but I think the drag is more organizational than it is technological.

We’ve pulled back the curtain and found that for discrete tasks, there does exist an omniscient, powerful wizard that can 10x our productivity. But for complex knowledge work requiring cross-domain expertise and skills like synthesizing fragmented insights, navigating reams’ worth of ambiguous data, and writing for senior and cross-functional audiences, there’s no magic. There is just a human sporting an emerald frock coat, cranking the machinery and wiring everything together by hand.

Right now, Claude is fantastic at getting me a 40% quality document in 5 minutes. Getting it to 90%+ takes hours. Part of that is inherent to the craft. For knowledge workers, clarity of thought comes through the act of writing. I didn’t actually understand my own strategy until I was forced to restructure the arguments and sharpen the logic myself.

The other part of that friction is the tedious editorial scrubbing required to remove AI defaults. I refuse to ship a strategy document without purging the correlative constructions (”It’s not X, but Y”), the emphatic colons (”The signal is clear:”), and the banal buzzword phrases (”To unlock step-change growth” 😭✋.)

The writing is one thing, but the deeper issue imo is the data. My struggle with the strategy doc illustrates how disorganized corporate tribal knowledge remains a major limiting factor. Institutional context lives scattered across Slack threads, buried in emails, and locked in slide decks optimized for visual storytelling (anyone remember Rule of Three?) When the people who created that content leave the company, the history leaves with them.

Prompting can only get you so far in an informational vacuum with no human-approved seal of quality. What enterprises actually need are shared knowledge layers—codified, maintained, and vetted by domain experts—so the AI has something trustworthy to synthesize in the first place.

Building that layer is less of a technical challenge than a cultural one. Organizations have to fundamentally re-architect how people work. They must encourage teams to move away from isolated chat sessions toward shared context bases that serve both new and tenured employees alike. This requires a shift in priorities, including relinquishing the instinct for polish in favor of speed. It means documenting research and decisions in structured, AI-friendly formats as they happen, rather than after the fact. It means letting AI handle the grunt work while humans step up simply to manage, direct, and ship.

Until enterprise knowledge management catches up to the technology, organizations will keep hitting a hard ceiling on AI’s potential, and the climb out of the Trough of Disillusionment will be painstakingly slow. Luckily, individuals operate without those limits. The people figuring out how to build their own context layers, wrangle the messy inputs, and edit the output into something readable aren’t waiting for the enterprise to catch up.

That gap is their alpha.

I (finally!) got access to Claude Code officially at work. I’ve been feeling a bit behind the curve since it seems like most product teams have had licenses for months. So I’ve been trying to lock in and play catch up by exhaustively learning and applying ways I can automate my routine execution tasks so I can focus more on the judgment, taste, and influence aspects of the job.

Here is a day-by-day breakdown of exactly how I set that up over my first week:

day 1 - setup + installing mcps

We didn’t have access to Enterprise yet, so I only installed Claude on my terminal and used their API usage billing to get credentials. I personally prefer running Claude directly within an IDE like Cursor. By keeping Claude open in a terminal side-panel, I maintain context on the active directory and open files as visual cues while I chat with Claude.

Below is my personal setup that with Cursor as an IDE + Claude opened in the terminal as a side panel:

When it comes to setting up MCPs, I first set up Figma and Jira since those were the two applications I’d been interfacing with the most in my day to day. Below is the exact process I used (including some trial-and-error learnings) to connect an MCP, using Notion as the example:

1. Fetch the command: Copy the specific installation command from Claude Code’s MCP documentation for your target server.

2. Execute: Paste and run the command in your terminal.

3. Re-initialize: You will likely need to restart the session for the MCP to register. You can either start a new session entirely or kill the current one using Ctrl + C on Mac.

4. Verify: Type /mcp in the terminal to view your active list of connected servers.

5. Authenticate: Hit authenticate. This opens a new browser window (or tab) where you’ll authorize the connection.

6. Confirm: You’ll know the handshake was successful when you see an “Authentication Successful” message in the browser, mirrored by an “Authentication successful. Connected to [MCP name].” prompt in your terminal.

day 2 - project folder setup

I knew from a recent PM webinar that building reusable “skills” was the key to maximizing use out of Claude Code for PMs, but the optimal directory structure to enable that wasn’t immediately obvious.

When I prompted Claude to create my first skill to write weekly program review updates, it defaulted to a global setup, storing the skill at the root level of my laptop. I had to explicitly course-correct the LLM to adopt a project-local architecture, ensuring that my AI skills and knowledge were isolated within the specific project folder.

After a few steering prompts, I landed on this directory structure:

.
├── .env                          # Environment variables (e.g., API keys for tools like Jira)
└── .claude/                      # AI configuration and workspace directives
    ├── claude.md                 # Master instructions: Defines the PM persona, standard tone, and overarching goals
    ├── skills/                   # Active capabilities: The "How-To" instructions for the AI
    │   ├── create-jira-tickets/
    │   │   └── skill.md          # Rules for writing user stories, defining acceptance criteria, and sizing
    │   └── create-prd/
    │       └── skill.md          # Your standard PRD template, required sections, and formatting rules
    └── knowledge/                # Passive context: The "What" and "Why" behind the product
        ├── strategy/             # OKRs, quarterly roadmaps, and high-level product vision
        ├── competitive-research/ # Competitor teardowns, feature matrices, and market positioning
        ├── customer-research/    # User interview transcripts, survey data, and synthesized pain points
        ├── meetings/             # Raw meeting notes, transcripts, and weekly sync action items
        └── decisions/            # Decision logs (e.g., DACI frameworks), trade-offs, and pivot rationales

In retrospect, I should have treated the folder structure itself as a product feature. If I were starting over, I would spend more time upfront using Claude’s /plan mode to architect an optimal, scalable folder hierarchy before writing any markdown files.

day 3 - populating the knowledge base

I came into Day 3 pretty ambitious. My initial instinct was to create dozens of skills right out of the gate, but I realized that skills are less useful without the right context. So I started migrating a few of my core work artifacts into the .claude/knowledge/ directory to test against my skills.

Here’s the data ingestion workflow I used to convert my knowledge into a machine-readable format:

1. Dump the unstructured data: I created raw Markdown files and pasted in messy, unformatted text. Some examples of the context I brought over included raw Zoom audio transcripts, existing product strategy documents, and deep research outputs generated via Gemini.

2. Build formatting skills: Rather than manually cleaning this data, I built a few foundational skills specifically designed to parse and normalize raw text into structured frameworks.

3. Execute the cleanup: Using Claude Code, I invoked the formatting skill in the terminal and used the @ reference to point the AI directly at the .md file to rewrite it.

With my context properly ingested, the directory started to look like this:

.
├── .env                          
└── .claude/                      
    ├── claude.md                 
    ├── skills/                   
    │   ├── create-jira-tickets/
    │   │   └── skill.md          
    │   └── format-zoom-transcript/
    │       └── skill.md          
    └── knowledge/                
        ├── strategy/             
        │   └── q3-product-growth-strategy.md
        ├── competitive-research/ 
        │   └── competitor-teardown-tax-filing-alternatives.md
        ├── customer-research/    
        │   └── user-interviews-self-employed-tax-pain-points.md
        ├── meetings/             
        │   └── 2026-03-10-product-strategy-sync-transcript.md
        └── decisions/

day 4 & 5 - creating more skills

With my .claude/knowledge/ directory populated, I was ready to start executing workflows. I wanted to break down the types of cognitive tasks Claude Code could handle. Instead of just looking at what the AI can “type,” I started framing my skills around the level of cognitive load they remove from my plate.

These fall into three distinct tiers, scaling from basic data processing to advanced critical evaluation:

tier 1: information processing

• Example skill: /format-zoom-transcript

• Reasoning effort: Low

• Task scope: High volume

AI just needs to parse a massive amount of messy, unstructured data (like the raw transcripts) and format it into a clean, legible structure. I personally benefit from these types of skills by reclaiming energy it takes to parse through meeting minutes and manually pick out important information like action items.

Raw input

Bagels [ Owner Kaci Nguyen ]-Shared screen with speaker view
Mar 10, 2026 10:30 AM
Who can see your viewing activity?

00:00:02/00:26/12

Speed

Audio Transcript
Chat Messages
Search transcript
Kaci Nguyen
Kaci Nguyen
Hi everyone so this morning... I made bagels.
Casey Wynn
Casey Wynn
00:27
That sounds delicious. What kind?
Kaci Nguyen
Kaci Nguyen
00:41
Everything.

Output

# Bagel Meeting - March 10, 2026

[00:00] Kaci Nguyen: Hi everyone so this morning... I made bagels.

[00:27] Casey Wynn: That sounds delicious. What kind?

[00:41] Kaci Nguyen: Everything.

tier 2: structured facilitation

• Example skill: /write-decision-doc

• Reasoning effort: Medium

• Task scope: High organization

AI is taking on the cognitive load that I’d typically bear when organizing an argument from the logical structuring to the trade-off articulation. Instead, I’m able to focus strictly on the content and information gathering from stakeholders.

Here is an example skill file I use:

---
name: write-decision-doc
description: Drafts a structured decision document using the DACI framework (Options, Pros/Cons, Recommendation).
triggers: ["write a decision doc", "help me document this decision", "create a decision doc for", "I need to make a decision on", "/write-decision-doc", "options analysis"]
version: 1.0.0
---

# Skill: Write Decision Doc

Draft a structured decision document using standard frameworks: Decision Trigger, DACI, Options, Pros/Cons, Recommendation, and Helpful Details. Gather context from the user first, then produce a filled-in draft ready to share with stakeholders.

## Step 1: Gather Context
Use your standard questioning capability to collect essential inputs. Ask up to 4 questions at once. Tailor the questions to any context already provided in the conversation. Skip questions if the answers are already clear from provided Slack threads, meeting notes, or requirements.

Always ensure you know:
- **The Decision:** What needs to be decided and what triggered it.
- **The Driver (D):** Who owns this decision.
- **The Approver (A):** Who has final authority.
- **The Goal Framing:** What outcome the decision serves (e.g., revenue, user experience, learning).

## Step 2: Identify the Decision Type
Based on the context, determine how comprehensive the document needs to be. When in doubt, use the full template below. The user can always trim it later.

## Step 3: Draft the Document
Fill in the template below using the gathered context. Apply these writing rules:
- Lead every section with the key point.
- Use active voice.
- Be specific: use names, dates, and numbers where known.
- One idea per sentence.
- Use explicit `[TBD]` placeholders where information is missing. Never guess or hallucinate facts.

---

## Output Template

```markdown
# DECISION: [Name of Decision]

**Driver:** [Name] | **Last Update:** [YYYY-MM-DD]

---

## Decision Trigger
[1-3 sentences. What happened that requires a decision? Lead with the situation, end with the specific question that needs answering.]

---

## DACI & Status
- **Status:** [Not Started / In Review / Approved]
- **Target Date:** [MM/DD/YYYY]
- **Driver:** [Name]
- **Approver:** [Name]
- **Consulted:** [Names or Teams]
- **Informed:** [Names or Teams]

---

## Options & Recommendation

**Recommended Option:** [State the winning option here in one clear sentence and briefly explain why.]

| Option | Description | Pros | Cons | Consulted POV |
| :--- | :--- | :--- | :--- | :--- |
| **1. [Name]** | [One-sentence summary] | - [Pro] | - [Con] | [Notes] |
| **2. [Name]** | [One-sentence summary] | - [Pro] | - [Con] | [Notes] |
| **3. [Name]** | [One-sentence summary] | - [Pro] | - [Con] | [Notes] |

---

## Helpful Details
- [Key constraint, context, or technical detail]
- [Key constraint, context, or technical detail]

### Related Docs
1. [[Doc Name]](Link or "TBD")
2. [[Doc Name]](Link or "TBD")
```

---

## Step 4: Save the File
Save the finalized draft to the workspace knowledge repository:
`knowledge/decisions/[decision-name].md`

tier 3: cross-context analysis & critical evaluation

• Example skill: /review-product-strategy

• Reasoning effort: High

• Task scope: High complexity

This is the most advanced cognitive tier where AI acts as a strategic thought partner. To do this, AI uses multiple contexts at once (such as leveraging competitive research files and customer transcripts) and evaluate a net-new artifact against them. This can be used to pressure-test work and avoid blind spots by checking the strategy against any real-world realities that may have been overlooked.

Example prompt:

Review @knowledge/strategy/q3-product-growth-strategy.md against @knowledge/competitor-teardown-tax-filing-alternatives.md and @knowledge/user-interviews-self-employed-tax-pain-points.md.

For each of these dimensions, give a brief assessment with a Strength and a Gap or Risk:
- Market alignment
- Competitive positioning
- Customer focus
- Business model coherence
- Execution risk
- Strategic continuity

Close with the top 3 gaps ranked by business risk.

day 6 - ad-hoc tasks

This evening, I was moderating an alumni panel for the Intuit RPM/RDP 20th Anniversary. Because this panel was a one-time event, I figured the ROI of building a dedicated skill and saving it to my .claude directory wasn’t there.

Instead, I spun up a new terminal session as a new node purely for ad-hoc prep. The organizing team had curated a list of great questions for the panelists, but I felt some were phrased too formally for me to deliver them naturally.

So I fed the questions into Claude and used it for stylistic alignment, prompting it to rewrite the question to match my natural speaking voice and ensure the moderation felt conversational rather than scripted. It did pretty well for a few of them, but there were one of two where I needed to course-correct by providing it feedback.

Example:

Before:

In transitioning from a highly structured enterprise environment to founding an early-stage startup, which established product management methodologies did you find counterproductive and subsequently have to unlearn?

After:

Intuit teaches us incredible frameworks for building products at scale for hundreds of thousands of customers. But going to zero-to-one or even one-to-ten is a totally different beast. As a founder, what Intuit skills did you quickly realize you had to unlearn to scale your startup?

day 7 - skill prototyping framework

I came across Pawel Huryn’s well-known repository of pre-built PM skills and decided to port them directly into my workspace. It felt like a massive shortcut, but it quickly highlighted a few realities about how AI actually integrates into product work.

First, PM work is inherently cyclical. You aren’t writing vision docs, sizing features, or running sprint retros every single day. Because of this natural cadence, I haven’t been able to organically battle-test this massive library of new skills to gauge their actual quality.

Second, while community-built skills are a great baseline, they are fundamentally generic. They don’t naturally conform to the specific cultural DNA of your company, in my case, the “Intuit way” of communicating, structuring arguments, and driving alignment. The plug-and-play approach doesn’t always work for nuanced product workflows. It’ll need some fine-tuning.

Moving forward, my best practice for creating AI skills is a chat-first prototyping model:

1. Execute Manually: Run the task organically in a standard chat session first.

2. Iterate and Calibrate: Course-correct the AI’s tone, formatting, and logic until the output perfectly matches your company’s internal standards.

3. Codify: Once the output is perfect, prompt Claude with something like: “Extract the rules, formatting, and logic from this conversation and generate a skill.md file in my .claude directory so I can replicate this exact workflow next time.”

By treating the chat window as a sandbox, you ensure that every skill you officially save to your directory is already proven, tailored, and highly relevant to your actual day-to-day work.

An example of a /edit-writing skill (had to ask Claude Code to simulate the conversation heh):

Next week, I’m hoping to continue expanding on the skills I’ve created, codifying knowledge, QA-ing the skills, and exploring more advanced features like agent teams 👾

In the past month or so, I’ve finally overcome my intimidation with the command line interface, with much encouragement from my partner, who is an absolute whiz at these things. He’s always viewed the world as a large puzzle of logic and code. I’m pretty sure he thinks in zeroes and ones. I’m the opposite. I see the world as one, big, continuous narrative of the human experience. I think in feelings, motivations, and values.

He couldn’t care less about the monospaced font used in the terminal. He may not even notice that to anyone who isn’t staring at it for most of the day, the typeface screams built for a machine first. But it’s been a big month for me and my humanist sans-serifs (my beloved, stuffed-orangutan-of-a-typeface). I’ve finally, properly, Claude-coded.

The addiction has gotten pretty bad to the point that as I write this I feel this compulsive longing to build something and get an instant dopamine hit at localhost:3001.

It’s radicalizing, which is a word I use sparingly. A lot of my life’s friction points now seem to have a software solution that can be wired up… in a day(?!) How empowering is that? Claude has permeated almost every facet of my life, and with its delicate, thoughtful (sometimes whimsy) touch, forced me to have opinions about things I’d typically leave on autopilot.

When you can build anything, the hard part isn’t building. It’s deciding what you believe. Getting clear and thinking deeply (and I mean truly, deeply) on why I’m building what I’m building has become the new bottleneck. Once the underlying reason is clear, every decision falls into place. But getting to that level of clarity is darn hard work!

Most recently, I decided to graduate from my manual-entry personal finance spreadsheet to something more advanced. If AI can extract better insights from my data than I can, why wouldn’t I let it? I set out to build a personal finance tracker with automations and embedded AI to help me optimize my spending and plan for the future.

Immediately, I was hit with decision paralysis.

I was taught early on by my mom to save and invest early. (That is objectively valuable advice, and everyone should listen to it.) But how does that translate concretely into the real world and into code? Should I hardcode the 50/30/20 savings rule into my app? What if I want to become financially independent and retire early? Or what if I want to spend exorbitantly now during what should be my peak health years, while I can still comfortably backpack for days and pull off weekend snowboarding trips to Tahoe?

It turns out that infinite optionality is a kind of… a burden? When you have access to the vast internet’s worth of ways to live, you realize just how many ways there are. Suddenly, building a ‘simple’ tool turned into gridlock about which philosophy is actually the ‘right’ one to govern my life. Because when you tell Claude you want to build a personal finance app that helps optimize spending, it doesn’t just jump into writing code. It reflects questions back to you.

Having access to a model that knows way more than I do helps me think more deeply about what I actually want, especially when it surfaces new knowledge I didn’t even know existed. For almost every project and task I have, I will reliably invoke AskUserQuestion and Claude will wrangle an untethered thought and teach me something new, without fail.

It’s honestly a weird time to be alive. Not too long ago, humans and AI had a one-way, commensal relationship. AI was largely a static tool composed as a rules-based system (If X happens, then do Y). We humans were the main beneficiaries from AI-as-tool’s speed at solving complex calculations, while AI was mostly unaffected, possessing no ability to ‘learn’ from the interaction.

Now, Claude can and will ask me about my beliefs. And every time I answer one about my spending philosophy, about what my savings goals are, about why I’m building this particular thing – it remembers, and it gets better at asking the next one. The model learns, iteratively and constructively, from human feedback the same way I’m learning from its questions in a loop where we both have agency.

We’re entering a new age where humans and AI are in a mutualist relationship, one where both sides need the other to adapt. AI needs our human experiences to learn how to think. And in return, it challenges us to get honest and specific about how we actually want to live.

There is one party I’ll make an exception for. And that is, the coffee shop party.

I love these parties because they’re held during broad daylight, everyone is caffeinated, and there are no attire expectations. You just show up wearing whatever’s comfortable and hang out. And did I mention there is caffeine(!!!)

I’ve hosted a few of these, and honestly if I had the time and space for it, I’d probably host more.

Here’s me + my friend hosting our first coffee shop party:

Inspired by the coffee shop party + my desire to improve my AI prompting skills + my love for bundling things together to feed two birds with one scone, I vibe-coded an coffee shop ordering app!

Some fun features:

• AI-powered menu builder based on Vi🅱️es

• Personal digital cafe-fronts with QR code generation + shareable links for guests to order straight from their phones 📱

• Real-time order tracking system so your friends don’t have to find you and ask about their order when you accidentally forgot about it while they’ve been talking to others awkwardly thinking about what to do with their hands because they didn’t have a prop to hold like everyone else🧍🏻‍♀️

Anyways, here it is: https://cafecina.lovable.app/

This one took 651 prompts and 414 AI Edits.

There’s a lot more I can probably do with this, either adding more features or actually doing some more rigorous QA. But what’s most immediately next for me is probably to actually host a coffee shop party and see if this passes the smoke test.

Until then, catch me back in the kitchen testing out new drink and pastry (specifically the one and only Texas sausage kolache (or klobásník, for the purist pedants 🫵) recipes :)

In my humble, not-at-all biased opinion, it’s one of the most interesting roles in tech. And one of the most in-demand too.

In this post, I’ll break down:

• Part 1: What’s an AI Growth PM? And how are they different from the more commonly known Growth PM?

• Part 2: What levers does the AI PM pull to grow products at a massive scale?

• Part 3: Why it’s one of the most highly demanded roles in tech and why it’s here to stay

I’ve been lucky enough to be an AI Growth PM for about a year now, and it’s been a fascinating ride. I’m learning new things every day from some of the best mentors/managers in the field. These are the notes and observations I’ve gathered along the way.

But first, 🗣️ DISCLAIMER 🗣️ Like any role in fast-moving, dynamic world of tech, the exact title, scope, and day-to-day of an AIGPM can look different from one company to another. Especially with AI, the lines are getting blurred. What I’m about to break down in Part 2 is a framework of strategic levers this role often pulls. Think of it as a playbook that gets adapted to each company. The core idea is that someone (anyone! EVERYONE!) needs to be thinking about these levers strategically to drive AI-powered growth.

Part 1: What exactly is an AI Growth PM?

We’ve got:

• The Classic Product Manager (PM): This is often the role people think of first when they hear of PM. They’re the strategic minds behind the product, responsible for defining the product vision (where are we going?), crafting the strategy (how will we get there?), and building the roadmap (what steps will we take?). They immerse themselves in user and market research, leading the team from initial idea through discovery, development, and ultimately, getting the product out the door. They own the ‘why’ and ‘what’ of the product.

• The Product Marketing Manager (PMM): Once a product is ready (or nearing readiness), the PMM is point for taking the product to market. Based on their understanding of the target audience and competitive landscape, they craft the messaging and positioning, develop the go-to-market strategy, and create campaigns and materials that drive awareness and adoption.

• The Growth Product Manager (Growth PM): While a Classic PM might focus on building new features or entire products, the Growth PM is focused on driving specific business metrics or optimizing product funnels. They constantly look for opportunities to improve things like user acquisition, activation, retention, and revenue. Their toolkit consists of experimentation, and they’re all about making iterative improvements to move the needle on KPIs.

And now…

• The AI Growth Product Manager (AI Growth PM or AIGPM as I’ll refer to from now on): Just like the Growth PM role emerged from a specific business need (faster, focused growth), the AI Growth PM is born from the scale and efficiency of AI.

So, what makes them different?

AI Growth PMs share the same core goal as Growth PMs: improve crucial business metrics. But they do it by leveraging AI. They’re driving the requirements and strategy for optimizing the AI models to drive growth in a way that's not only effective in the short-term but also sustainable and incredibly efficient1 in the long run.

Part 2: The AI Growth PM’s Playbook

An AI Growth PM's job isn't just about knowing AI exists; it's about strategically using different aspects of an AI system to hit growth targets. Each "lever" they pull offers a distinct way to improve things:

1. Problem Framing & Objective Definition: What are we solving, and how do we measure success?

2. Data & Signals: What raw information powers the model?

3. Models & Algorithms: How does the system learn to make decisions?

4. Targeting & Personalization: Who sees what, and when, and where?

5. UX & Delivery: How are predictions presented and experienced?

6. Infrastructure & ML Ops: How does it scale, serve, and stay reliable?

1. Problem Framing & Objective Definition

No model matters unless it solves something meaningful. This lever is about defining clear, solvable AI problems that align with both user needs and business goals. It's where data science meets strategy – and where the AI Growth PM shines as the translator between technical potential and commercial value.

Key Components

• Business goal alignment: Everything starts with the outcome. AIGPMs will initiate a project by clarifying what success looks like in business terms: higher conversion, increased engagement, improved retention, increased LTV, etc.

• AI problem framing: Next, AIGPMs (shortening for my sake) will define the AI problem clearly. They’ll ask: Are you building a model to recommend, rank, classify, or generate? Is this a prediction problem? A retrieval problem? A content generation problem? Framing it incorrectly will result in vastly different solution that might miss the mark on KPIs.

• Model metric mapping: Once they’ve framed the problem, AIGPMs in partnership with their technical engineering/data science counterpart set the metric. Based on the business KPI they care about, they’ll select an evaluation metrics (e.g. accuracy, precision, loss, recall, NDCG, AUC).

• Proxy design & validation: In cases where business outcomes are hard to measure directly, they’ll define proxies with strong downstream correlation. As an example, "likelihood to watch full video" would be a proxy for content relevance.

• Experimentation readiness: While the team goes into model development mode, AIGPMs will think ahead about how they’ll measure success in the real world through A/B or multivariate testing. What are the primary vs. secondary metrics? What’s the baseline? They’ll define this upfront.

• Stakeholder & partner alignment: Throughout this entire process, AIGPMs will collaborate early with data science, product, engineering, and analytics to scope feasibility, timeline, and risks and partner on defining some of the requirements related to modeling and experimentation.

AI Growth PM Role & Responsibilities

✅ Identify high-impact, model-worthy problems tied to KPIs (growth, retention, monetization)
✅ Translate business needs into clear AI problem types and data requirements
✅ Define success metrics – not just for the model, but for the product and customer
✅ Bridge conversations between strategic teams and technical teams to align on value and approach
✅ Ensure downstream evaluation and experimentation plans are in place before launch

Common Pitfalls to Avoid

❌ Assuming a high model accuracy (e.g., 90% AUC) automatically means business success. If that accuracy doesn't translate to improved KPIs, the model isn't truly working.
❌ Building a complex AI solution without first understanding how a simpler heuristic or the current system performs. You need a baseline to prove AI's incremental value.
❌ Launching an AI feature without clearly defining upfront what “good” looks like in measurable terms.
❌ Underestimating the ‘last mile’ integration and not considering how the model will integrate into the existing product.

2. Data & Signals

Data is the fuel of models. The quality, quantity, diversity, relevance, and freshness of data directly determine how well models perform. Improving your dataset often yields greater returns than tweaking algorithms. For AI Growth PMs, this means becoming obsessed with the completeness, structure, and utility of the signals feeding the model.

Key Components

• Signal expansion: AIGPMs are always on the hunt for data (1P or 3P). When it comes to 1P, they’ll prioritize capturing a broader range of user behaviors and contextual triggers, such as clickstreams, hover time, scroll depth, or feature usage (more signals = richer understanding).

• Signal quality: On top of that, they’ll ensure the signals are clean, unbiased, and complete. That includes dealing with sparsity, noise, or skew in datasets that can lead to misleading model outcomes.

• Signal representation: Once they have the data, AIGPMs will work with data engineers (sometimes data scientists or machine learning engineers) to transform raw behaviors into useful, model-ready features (e.g. creating sequence modeling of click history, generating user/item embeddings from behavioral data).

• Feedback as signals: Thinking holistically, AIGPMs will design systems to capture and utilize user interactions to continuously improve data quality and model relevance. This includes explicit feedback (e.g. direct user inputs like likes, ratings, thumbs up/down) and implicit feedback (e.g. clicks, hovers, time spent, scrolls).

AI Growth PM Role & Responsibilities

✅ Champion richer instrumentation and signal coverage across the product
✅ Build a data roadmap that includes initiatives like instrumenting new user events, integrating streaming clickstream data, or third-party enrichments
✅ Partner with product, engineering, data science, and analytics on feedback ingestion as reliable, retrainable signal sources for model improvement

Common Pitfalls to Avoid

❌ Assuming the necessary data for your AI idea will just "be there”. Data strategy and instrumentation often require significant lead time.
❌ Ignoring data freshness and using stale data. Model performance can degrade quickly if data inputs aren't reliably maintained.
❌ Overlooking potential biases in data sources, which can lead to skewed model outcomes.

3. Models & Algorithms

If data is the fuel, then the algorithms are the engine that processes it. This lever about selecting, building, and refining the right model to maximize predictive power for the job at hand.

Key Components

• Model selection & architecture: Typically, data scientists select the appropriate algorithm based on the problem. Where AIGPMs help weigh in are on the product requirements such as the degree of explainability needed per use case as well as trade-offs between performance, explainability, development time, and other factors.

Models in an AIGPM’s toolkit:

• Foundational models:

  • Affinity/Propensity models: These predict the likelihood of a user to take a specific action (e.g. engage with content, buy a product, click an ad.)

  • Embedding models: Like ‘fingerprints’, these are compact representations that capture complex relationships and similarities for users or items. They serve as inputs for downstream ML models and are pretty powerful.

• Advanced models:

  • LLM-based content generation: Large language models can be used to auto-generate metadata or product descriptions. This can save a ton of manual labeling efforts and enable personalization at scale.

AI Growth PM Role & Responsibilities

✅ Collaborate with data scientists on model selection, iteration, and evaluation, ensuring alignment with business objectives
✅ Build a roadmap for developing and improving generalizable, foundational models (e.g. affinity, embedding models) that can serve multiple use cases
✅ Identify opportunities to leverage advanced techniques like LLMs to solve content gaps and power personalized experiences at scale

Common Pitfalls to Avoid

❌ Pushing for the most complex, cutting-edge model if a simpler, more interpretable one can achieve 80-90% of the desired outcome with less effort and risk.
❌ Blindly accepting the algorithm selection because your data scientist chose it. Instead, ask the data scientists to explain (at a high level) how the model works, its assumptions, and limitations, making sure the right trade-offs are being made.
❌ Forgetting that models degrade over time and failing to plan for ongoing monitoring and retraining

4. Targeting & Personalization

In a world saturated with content and information, relevance is king. When experiences for tailor-made, users are dramatically more likely to engage, convert, remain loyal, and ultimately drive the growth metrics AIGPMs care about. This lever is about moving beyond the one-size-fits-all experience and delivering the most relevant content to the right user segments at the right moment in their journey and through the most effective channel.

Key Components

• Audience segmentation (who): AIGPMs will work with marketing and analytics to identify well-defined groups personalize for. Some examples of how audiences can be segmented:

  • Behavior-based: Grouping users by real-time actions or patterns (e.g. ‘cart abandoners’, ‘repeat browsers’, ‘inactive trialers’)

  • Predictive: Forecasting likely outcomes to identify users ‘at risk’ or ‘ready to convert’

• Content matching (what): While AIGPMs aren’t building the matching algorithms (that’s what the data scientists will do!), they are responsible for defining what needs to be matched. Here, content can include things like articles, messages, offers, images, and much more. These will often be tailored to the user’s preferences and histories (via affinity models, embeddings, etc.)

• Journey orchestration (when & where): Given what's happening right now (location, device, current activity, time of day), what is the most relevant thing to show? AIGPMs are striving to achieve a specific growth goal. Journey orchestration is one way to do that. AIGPMs will consider how to optimize the sequence and timing of interactions across the user’s journey to achieve some goal like an onboarding sequence to activate new users or an in-app step-flow to encourage adoption of a new feature.

• Contextual targeting (when & where): Closely related to journey orchestration, contextual targeting involves more short-term "right time, right place" delivery. Based on the user’s immediate/real-time situation or environment like device, location, session context, or time of day, AIGPMs will focus on optimizing a specific interaction or piece of content.

• Explore/Exploit strategy: One of the most interesting (and imo life-transferrable) components is setting the explore/exploit strategy. AIGPMs consider the audience segment, product goals, and surface to balance safe bets with discovery by introducing diversity or novelty to avoid filter bubbles (where users see more of the same).

• Feedback loops: This was touched on earlier as “Feedback as signals”. Here, AIGPMs ensure real-time implicit and explicit feedback (likes, skips, scrolls, “not interested”) are leveraged to enrich personalization and guide adjustments in what content gets shown.

• Multi-objective optimization: For some more mature, complex products, AIGPMs will be involved with setting multiple objectives since real-world product decisions often involve multiple goals that need to be balanced. One example is deciding whether to optimize for revenue or conversion. Optimizing solely for revenue might lead to pushing expensive items that don't convert well, hurting conversion rate. On the flip side, optimizing solely for conversion might lead to promoting cheap items, hurting revenue and margin. It’s a balance. AIGPMs need to get stakeholders to align on the priorities and trade-offs, define measurable metrics for each objective, and ensure that business optimization doesn’t degrade the user experience to a point where it harms long-term growth (like retention or trust).

AI Growth PM Role & Responsibilities

✅ Identify and prioritize high-leverage personalization opportunities across the funnel to drive growth
✅ Define segmentation logic and targeting strategies in partnership with data science and analytics
✅ Collaborate closely across product, design, and engineering to activate adaptive experiences with feedback loops
✅ Advocate for personalization that earns user confidence through relevance, control, and transparency

Common Pitfalls to Avoid

❌ Ignoring the ‘Cold Start’ problem and forgetting to plan how personalization will work for new users (no history) or new content (no interaction data).
❌ Assuming a single 'one-size-fits-all’ personalization strategy works for all user segments or all parts of the product. Nuance and context is critical.
❌ Implementing personalization that feels overly invasive or reveals data they didn't realize was being used.
❌ Building personalization systems without considering ways for users to provide feedback, adjust preferences, or understand why they are seeing certain things.

5. UX & Delivery

Even the smartest prediction falls flat if users don’t understand or trust it. This lever covers the experience layer of AI—presentation, performance, and explainability—to make intelligent experiences feel intuitive, credible, and seamless.

I’m actually quite passionate about this space being a visual person that I am and having done research in Human-AI computer interaction. But I’ll bite my tongue here and keep it brief.

Key Components

• Presentation layer: Sometimes referred to as the ‘surface’, this is where users see the AI-driven content.

• Interaction design: AIGPMs make sure their AI outputs are actionable and navigable with minimal friction on the surface they’re presented on.

• Explainability & trust elements: Not captured in the targeting section is the ‘Why’ or the ‘Why am I seeing this?” messaging. To increase user trust and adoption, AIGPMs need to determine the degree of explainability needed for the use case and work with content or experience designers to bake that in via messaging or UI cues.

• Latency management: One trade-off that AIGPMs might need to weigh is speed of delivery vs. model complexity. They’ll work with the product development or product engineering team to implement techniques like caching, async loading, and fallback logic to limit latency.

• Resilience & fallback logic: This ones pretty straightforward. What happens when AI fails? AIGPMs need to author backup rules or fallback content, of course not in isolation but working with their team.

• Orchestration layer: This is a meaty one. I think of this layer as the final set of decisions and logic that determine what content actually makes it to that presentation layer and in what order, for a specific user at a specific moment. Interesting things get set here including diversity rules, impression capping, boosters/penalties (positive or negative multipliers added to content, you might see these added around the holiday season), model switching logic, and A/B test delivery infrastructure.

AI Growth PM Role & Responsibilities

✅ Define end-to-end experience of personalized features in partnership with designers
✅ Collaborate with engineers on real-time performance tuning and resilient system behavior
✅ Own orchestration strategy: prioritization logic, boosters/penalties, model switching
✅ Ensure feature rollout is testable, measurable, and aligned with experience goals

Common Pitfalls to Avoid

❌ Assuming users will understand or trust AI outputs just because they are "smart." The UI/UX needs to make them intuitive and valuable.
❌ Ignoring latency and underestimating how slow AI responses can kill the user experience and lead to drop-off.
❌ Launching AI features without robust fallback mechanisms for when the AI is wrong, data is missing, or the system fails.
❌ Underinvesting in explainability and assuming a complex model can't have some form of user-facing explanation

6. Infrastructure & ML Ops

All the data and models in the world don’t matter if they can’t reliably get into production. This lever covers the systems that support model development, deployment, experimentation, and delivery at scale.

AIGPMs will collaborate frequently with platform teams to enhance foundational infrastructure to serve their use cases:

Key Components

• Feature store: These are centralized systems for storing, sharing, and querying reusable ML features across teams and workflows

• Model serving & deployment: Infrastructure for delivering model predictions into real products, reliably and at scale. This should support batch, real-time, and streaming inference along with safe rollout practices like versioning and canary releases.

• Monitoring & observability: These are tools that track model health in production, from performance drift and prediction anomalies to latency and throughput issues.

• Experimentation infrastructure: This includes end-to-end tooling for running A/B tests on models or algorithm variants. Some features that AIGPMs are particularly interested in are traffic splitting, gating, and metric logging to evaluate both model performance (e.g. accuracy, loss) and product impact (e.g. conversions, retention).

• Training-serving consistency: One thing my architect heavily pushed for was architecture that ensures features and preprocessing logic used during training are preserved during inference. The benefit of this is ensuring the model behavior in production matches what was validated offline » Important for serving relevant recommendations!

AI Growth PM Role & Responsibilities

✅ Advocate for infrastructure investments that accelerates model-to-production cycles without sacrificing quality or control
✅ Balance long-term infra roadmaps (e.g. retraining pipelines) against short-term product impact via customer-facing use cases
✅ Translate cross-functional needs into infrastructure priorities that unlock developer velocity and business value

Common Pitfalls to Avoid

❌ Assuming moving a model from a data scientist's notebook to production is trivial. It involves significant engineering. I learned this lesson the hard way.
❌ Simply ‘making do’ with current infrastructure. AIGPMs, being closest to the business use case, have a responsibility to articulate specific platform requirements needed to support and scale their AI initiatives.

Each of these levers is a world unto itself. Great AI Growth PMs blend technical fluency, business savvy, and product intuition to judiciously prioritize short- and long-term investments across each pillar. They know which levers to pull, and when, to create a kind of self-improving "personalization flywheel" that keeps getting better. Naturally, I’d expect the specific way these levers are owned and operated will look different depending on the company, but the core challenges and opportunities remain the same.

Part 3: Why it’s one of the most highly demanded roles in tech (and why it’s here to stay!)

Since Youtube popularized the term ‘creator’ in 2011, the creator economy has grown into a $250 billion industry. Platforms like Substack, Spotify, and TikTok have built their own ecosystems where writers, podcasters, hobbyists, and quite literally anyone can produce and distribute content directly to their audiences.

The pace of growth has only accelerated. Generative AI tools like ChatGPT, Midjourney, and Suno.AI have reduced the time required to create content by orders of magnitude. Content that once took hours or days to produce can now be generated in seconds. With these additional tailwinds to an organically growing industry post-COVID, it’s estimated the creator economy could reach +$480 billion by 2027.

When content creation becomes nearly frictionless, the bottleneck shifts to discovering and recommending the right content to the right person.

During the 1800s Gold Rush, the people who built lasting wealth were the ones selling shovels rather than the prospectors themselves. In the AI surge, a similar pattern emerged: companies like Nvidia, which sells GPUs to train large-scale ML models, became foundational to the entire industry building large language models.

In today’s creator-led digital economy, recommendation systems have taken on that same infrastructural role. They power the discovery, engagement, and retention loops across creator platforms, influencing not just what consumers see but also which creators take off.

Who’s responsible for growing and scaling this? 🤔

As content volume grows, someone needs to strategically connect the supply with the demand at scale. AI Growth PMs fill this role, defining experiment strategy, optimizing the model, and ensuring that the content users see aligns with both relevance and business impact. They guide AI systems to understand what users value, enabling businesses to translate those insights into sustainable growth.

Humans will always create and always seek connection. Amidst the digital deluge of content, the AI Growth PM ensures technology helps us find the people and ideas we resonate with most.

Subscribe now

For the past few months, I’ve been using Daily Bean to log my days and jot down quick reflections. At first, I liked it—but over time, I started noticing some limitations:

• It tracked attributes I didn’t particularly care about (chores, meals, self-care... although maybe I should track those? 🤔)

• The emotion options were overwhelming (what exactly is pit-a-pat?)

• There was no web app—typing on a phone keyboard is tedious

• The free version required watching ads just to save an entry 😭

Instead of continuing to put up with these limitations, I thought: Why not build my own journaling app, designed exactly the way I want it?

Building my own solution

I started by sketching rough ideas in Excalidraw—nothing fancy, just enough to map out the core features and layout. This helped me think through what I wanted before jumping into development with Lovable.

From there, I iterated:

• Designed the layout: Tweaking and polishing each component piece by piece.

• Connected to Supabase: Setting up database schemas for journal entries and user accounts.

• Integrated GPT-4o: For smarter insights and quick access to past journaling entries.

• Refined the UI: Spending extra care—and a good number of prompts—to make sure everything looked pixel perfect (or close to it).

One of my favorite and most delightful moments was building an image preview feature for the home page. I was worried it’d be tricky to pull off, but Lovable made it surprisingly smooth!

try it out :)

👉 Another Day Another Entry Journaling App (Look Ma, no ads!)

I'm excited to continue making improvements to the app. A few upcoming ideas I’ve been thinking about:

✅ Better insights & richer mood tracking
✅ AI prompt starters to jumpstart meaningful conversations
✅ Data importing & integrations from other potential data sources (like Daily Bean)
✅ Even more UX/UI polish (such as adding better validations and consistent styling)
✅ Automatic tag extraction from journal entries to reduce the manual tagging

reflections

Building this wasn’t just fun—it was freeing. For the first time, I wasn’t held back by technical limitations or the frustration of not knowing how to code. Lovable became my creative playground, letting me explore ideas in real time and sparking moments of curiosity: “What if I tried this?” or “Could I make this happen?”

As a PM, I've struggled with insecurity around not feeling technical enough. Over the years, I've accumulated countless ideas that never saw the light of day simply because I lacked the coding skills to build them. There's a frustration and vulnerability that comes with having a clear vision but feeling restricted by your own abilities. At times, I've thought, maybe it's just time I learn to code... but I could never find the momentum to push through that daunting process.

This experience shifted that mindset completely. I realized I don't need to be fluent in code—I just need tools that let me express my ideas clearly and visually, in a language that feels natural to me. Suddenly I was building, iterating rapidly, and seeing my vision come alive. For the first time, I truly felt empowered to create something real, all on my own.

And this feels like just the beginning. I'm genuinely excited now—excited to dust off those dormant ideas and finally watch them come to life :)

After more than a 100+ messages and $20 later, the answer is yes.

In my last post, I experimented with AI-assisted web design, using a mix of ChatGPT, Webflow, and Midjourney to create a personal landing page. I was pleasantly surprised—ChatGPT made navigating Webflow much smoother by translating my ideas into web design terminology that I could map back to the Webflow style panel interface. It was like having an on-demand Webflow specialist, helping me bridge the gap between vision and execution.

But after that experience, I wondered: What if I let AI take over the entire process from design to deployment? Instead of just assisting me, could it actually design and develop my site while I played the role of creative director?

I decided to put this to the test with Lovable.dev, an AI-powered web-building tool that claims to generate full-stack websites from simple text prompts. I’d heard a lot of good things about it, but what really caught my attention was Build Wars: Webflow vs. Lovable.dev, a live competition where a Webflow designer and a marketer using Lovable.dev raced to build a website in an hour—with 25K+ viewers watching. Naturally, I had to see if Lovable.dev could rebuild and evolve my own site with minimal manual intervention.

🧐 What is Lovable.dev?

Lovable.dev is an AI-powered web-building tool that generates full-stack websites from simple text prompts. The AI can handle styling, animations, and even some interactivity.

For example, prompting it with something like:

“Create a simple, clean, and minimalist one-page portfolio website for a product manager named Kaci, showcasing their best projects, a short bio, and contact details.”

…results in a fully functional site like this: minimal-kaci-space.lovable.app—in about three minutes. It’s pretty insane.

Could Lovable.dev re-build and further evolve my existing personal site, with minimal manual intervention?

The Experiment

I started with a simple prompt, attaching a screenshot of my current Webflow-built landing page:

Create a personal website landing page that looks like this. Use placeholder images for now.

That got me this:

First impressions: not bad… but not perfect

When the AI generated my first draft, I had mixed feelings. On one hand, the structure was pretty close to my original design. It applied styling intelligently, even using hover effects for the interest tags and good proportions between all the text elements.

On the other hand, some elements felt off—image layout wasn’t quite right, and of course there weren’t interaction animations in place. Still, for something that took less than five minutes to generate, I had a decent foundation to work with for a simple landing page.

Enhancements & Iterations

Once I had my AI-generated site, I went in and refined it.

🛠 Adding tooltip interactions

I wanted tooltips to appear when users hovered over the interest tags and the external link icon. I wasn’t too specific with my prompt, and simply asked for a tooltip to appear on hover—the AI got me a pretty clean tooltip to work with.

🚀 Importing components from 21st.dev

I used 21st.dev, a library of pre-built UI components, to enhance my site. I landed on the highlight animation and sparkles text components, which made the main header pop more and add some interesting movement to an otherwise simple and static page.

🖼 Image hover animations & refinements

This was one of my biggest challenges. While Lovable.dev added animations, they weren’t consistent across all images. Some hovered smoothly, while others felt a bit janky. I had to dig into the code to figure out what was going on and get more specific with my prompt to make the right adjustments.

One unexpected (and hilarious) moment: While trying to debug the animations, I noticed that only one image (the otter) had the smooth transition I wanted. So, I prompted:

"Make sure all component image animation transitions are smooth and consistent. It looks like only the otter image transition is smooth right now."

Apparently, Lovable.dev took some creative liberties because the result was a set of floating, bouncing ghostly apparitions 🤣. Not exactly what I had in mind, but it gave me a good laugh before I reverted it.

📌 Refactoring (AI helps fix its own code!)

One super cool thing: Lovable.dev proactively suggested refactoring parts of the code to make it cleaner and more efficient. Instead of manually rewriting everything, I could just click a button, and AI would optimize it for me. Pretty handy for someone whose least concern is on code readability/maintainability/redundancy.

This was the refactoring prompt that got triggered by clicking the button:

Refactor src/index.css into smaller files to improve organization and maintainability. Consider creating separate files for animations, layout components, and responsive styles.

🎨 Visual polish

To bring everything together, I pulled colors from an image on the site and applied them to the highlight and sparkle components. This helped create more consistency and cohesion across the page.

The Result

🤩 What went well

✅ Beautiful design right out of the box – Lovable.dev is known for its aesthetic UI, and it delivered. It automatically added drop shadows to my images for depth and included smooth animations that felt polished.

✅ Automatic animations – It surprised me by adding subtle fade-in and slide-up effects to the content on page load, making everything feel more dynamic without me even asking for it.

✅ AI-suggested code refactoring – The built-in ability to clean up and optimize the code was a game-changer. I didn’t have to worry about how the website would get built. Instead, I could focus on how it looked and functioned which is really what I care about.

😭 What didn’t go so well

❌ Font inconsistencies – Lovable.dev struggled to match my existing fonts exactly, possibly due to lack of font parity between Webflow and Google Fonts which I later found out was used by Lovable.

❌ Animation consistency – Not all elements had the same smooth transitions. For example, my otter image animation worked perfectly, but other images felt choppy. Trying to correct this without looking at the code felt frustrating. I’d often get a “Changes already applied” message even though it was clear no functional changes were made.

❌ Slow iteration cycle – Every request took 2–3 seconds to process, plus another 2–5 seconds for the preview to update. Compared to Webflow’s instant visual feedback, this felt sluggish when making small tweaks.

Takeaways & lessons learned

1. Prompting matters—A LOT
   I quickly realized that the way I framed my requests directly impacted the results. Using clear, structured language—especially with design-related or coding-related terminology—helped AI understand what I wanted faster.

2. Using existing UI components is a hack
   Leveraging 21st.dev for pre-built elements sped things up significantly. Instead of figuring out the right words to get the visuals I wanted, I was able to leverage the prompts directly from 21st.dev and let the AI incorporate the code into its existing code.

3. AI is fast, but not instant
   One of Webflow’s biggest advantages is instant feedback when tweaking designs. You can see your changes in the style panel reflect immediately in the canvas. With Lovable.dev, there was always a brief waiting period between entering the prompt and seeing the preview, which made quick iterations and validations feel drawn out.

What would I do differently next time?

• Plan my prompting strategy more carefully
  Instead of a trial-and-error approach, I’d predefine a sequence of prompts for smoother iterations and try out new prompting strategies.

• Experiment with the knowledge base
  I wonder if adding design guidelines (like Dieter Rams’s principles or Nielsen Norman’s usability heuristics or the principles of visual design) to the knowledge base in the project settings would influence the AI’s design decisions. There were times when I didn’t know if something looked good or not. For example, I wasn’t incredibly happy with the image positions and sizing relative to each other. It would have been nice if the AI proactively made suggestions to improve the overall aesthetic, or incorporated best practices from the get-go.

• Be mindful of subscription limits
  My starter subscription included 100 monthly messages, and I burned through them quickly testing out different changes. Since Lovable.dev only gives 5 daily messages after hitting the limit, I’d need to be more strategic in future projects.

Final thoughts: Is Lovable.dev a Webflow killer?

Not quite, but gawd dayum, it’s scary impressive. I wouldn’t be surprised by how the technology will mature over the next few years.

Webflow still reigns supreme for those who want full creative control over their websites. Its robust visual editor allows for pixel-perfect precision and quick iterations. However, there’s a learning curve—users must invest time in understanding the interface to unlock its full potential.

Meanwhile, Lovable.dev caters to a broader audience who prioritize speed and ease over granular control. While this makes it an excellent choice for non-designers or those looking for a no-fuss solution, it also means that the final product may feel less unique or tailored compared to a Webflow-built site. If you’re okay with a more standardized, boilerplate look in exchange for efficiency and ‘getting the job done’, Lovable.dev is a solid contender.

Ultimately, the choice between the two platforms depends on your priorities—if you value unrestricted creativity and customization, Webflow is still the gold standard. But if you want a sleek, functional site with minimal effort, Lovable.dev provides a hassle-free alternative.

Would I use Lovable.dev again? Absolutely. But next time, I’ll approach it more strategically to get the best results with fewer iterations and optimized prompts.

🚀 On to the next project!

➡️ See the final result for yourself: kacinguyen.lovable.app!

I’m no longer a ‘new grad’ as I’d advertised in my bio. ChatGPT became a thing antiquating my 2021 research on AI tutoring agents. And my motive for having a site has shifted from trying to ‘sell myself’ to just having fun expressing myself.

This month, I decided to yank the dust cover off my site and give it an uplift.

Starting point: The initial design

I used Webflow to develop the first design that’s been live for the past few-ish years. As you can see, it’s literally black and white with some janky, lightweight highlight interactions that were neither polished nor inspiring.

The last time I tried to build a cool-looking site, I found it confusing to use Webflow—a hybrid of a no-code website builder (limited customizability) and straight-up coding (maximum customizability). I’m no engineer nor am I designer, and I felt like Webflow was built for a designer-almost-engineer. As a result, I heavily procrastinated on learning how wield its full functionality. And instead, I’ve been settling with very plain and simple designs because I didn’t know how to add the pizazz imagined in my head.

New concept

Before diving into the nitty-gritty, I wanted to ensure this next iteration of my site was up-to-date and a bit more fun. Here’s what I had in mind:

• Minimalist yet impactful: Strip away excess pages and irrelevant links to create a zero-click navigation experience.

• Distinctly personal: Add playful, hand-drawn illustrations to bring some personality to the visuals.

• Smooth and dynamic: Introduce page load animations and smoother hover interactions to make the experience feel interactive and polished.

• More contrast: Update the hero typeface to a bold serif and experiment with elegant yet imperfect design details.

My tool stack

To bring my vision to life, I leaned on three powerful tools:

1. Webflow: My go-to website builder for both design and coding, offering rich functionality despite a learning curve.

2. ChatGPT-4o: My AI assistant for guiding and educating me when I get stuck.

3. Midjourney: My creative companion for generating supporting visuals.

How I used each tool

Webflow

Webflow serves as a design editor that has drag-and-drop elements and a style panel control center used to customize the looks and layout of those elements. I love it because of its powerful set of features and functionality (e.g. interactions, custom css properties and values) that enable you to customize and personalize your site more so than other drag-and-drop website builders like Wix and Squarespace. There’s a bit of learning curve to understand how it works, but once you figure it out, you can build some unique and stunning websites.

My initial site was built using Webflow, so I decided to use the same tool/project to work off.

ChatGPT

If Webflow was my main instrument, then ChatGPT was my help assistant. I used ChatGPT to troubleshoot my problems that came up.

Use case #1: Guiding me through implementation

When I wouldn’t know how to build a specific animation interaction pattern in my head, I used ChatGPT to walk me through it. Some of the tips it gave weren’t a 1-to-1 match for the existing version of Webflow, but that was okay. Once it told me where else to look, I was able to find the matching keywords in the current live version that got me to where I needed.

Use case #2: Keeping my classes structured and well-organized

There were times when I’d realize that I’d need to apply the same exact interaction effect to similar elements. For example, the tooltip interactions were all the same. However, I would have to re-build the same interaction three times based on the way I named and identified each tooltip element. This felt unnecessary so I posed the question to ChatGPT to suggest a class folder structure that would enable me to do the work once and save me twice the time.

Use case #3: Educating me on web terminology and best practices

When it comes to sizing (text, padding, margin, divs, viewports, etc), there are several units of measurement you can choose from: px, %, em, rem, ch, vw, vh, svw, and svh. Why so many? Can’t everything be set in pixels?

Well, it turns out that there are different benefits of using each of these units. It depends on the nature of your design and the element you’re styling.

Different units of measurement (like px, %, rem, and vw) have specific uses depending on design needs. For example, pixels are best for small, fixed elements requiring precise control (like icons and borders), while percentages are better for elements that need to adapt to flexible layouts. I used ChatGPT to help demystify these nuances.

I wouldn’t have known any of this without the help of ChatGPT to explain it all in a table breakdown. ChatGPT is definitely a great companion to have at your side when working in a new domain with low-risk consequences should it ever hallucinate and lead you astray.

Use case #4: Brainstorming and consulting design ideas

ChatGPT gave me a starting point that I often used but built upon later. I think it’s really good at providing leads or clues for what to explore next. When I asked ChatGPT how to add an animation on page load, it proactively provided a few simple and slightly more fancy ideas I could start with. It also raised some nifty suggestions that made the design more dynamic and less clunky such as adding a bézier keyframe transition to each animation.

Overall, ChatGPT handled a lot of unwanted thinking for me in seconds, leaving me in the pilot’s seat to control the creative direction.

Midjourney

I knew I wanted some illustrations on my site, but I’m not artist. My options would have been 1) spend days learning how to draw ($ in time, bad quality), 2)commission someone to do it for me ($ in money); or 3) find some existing digital assets that someone is selling ($ in money, but low in precise expression/customization). But lo and behold, times have changed. Midjourney exists!

I paid $7 for a monthly subscription on Midjourney to generate some nice visuals on my site. It did not disappoint. I used 118 prompts, iterating and building upon each one to tweak the first set of Clip Art-y images that divulged my prompting ineptitude. I’m so embarrassed by some of the initial images that I immediately clicked on the ‘Hide’ button on a few of them to sweep them under the rug and forget that they ever existed. The more and more I played around with Midjourney’s features and keywords, the better the images became. By the end, I was extremely elated by the results.

Here are a few fun ones I created with the following prompt:

A flat vector playful, hand-drawn illustration of a [fill in the blank] in the style of Matisse 

Once I got a few images that I liked, I was able to use the “Use in prompt” feature to reference the style in my next prompt. This was one of the most delightful features I came across since it made all the illustrations look cohesive.

Final result

Here it is! Now, with newer personality-filled animations and hand-drawn illustrations, it finally reflects the personality I wanted when I first decided to start a website.

Takeaways

1. AI tools unlock limitless possibilities, with human imagination and clear communication as the only constraints. Even the most complex interactions that once felt exasperating and made me want to (╯°□°)╯︵ ┻━┻ are now easily achievable, empowering creators to surpass their own skills.

2. Webflow + supplemental AI tools are breaking down barriers, making design and development more accessible to non-designers and non-engineers like me. Together, these tools enable individuals to tackle creative and complex projects independently, redefining the traditional roles of product, design, and engineering in the process. Each function may begin to shift their focus towards the more complex and creative work, such as motion and interaction design.

3. ChatGPT is a powerful assistant, but switching between tools remains a challenge. Despite the friction of tab-switching, its ability to answer questions and provide solutions far outweighs the inconvenience, and deeper integrations could streamline its utility even further by introducing contextual help and up-to-date internal knowledge.

   1. Update: I think Webflow is building this as we speak! Webflow AI Assistant is currently in limited beta as of Dec 2024.

Future plans

This project gave me a taste of how distributed generative AI tooling can enhance and transform design and development workflows. With the pace of innovation accelerating, I’m eager to dive deeper and see how these tools will reshape our workflows in ways we can’t yet imagine.

Up next:

🌶️ Test-drive in-house copilots like Webflow’s AI Assistant to see how seamlessly it integrates into the design workflow.

🌶️ Go all-in using next-gen full-stack generators like v0, bolt.new, and lovable.dev to build a website from the ground up using just human language prompting.

🌶️ Combine a full-stack generator with co-pilot LLM support to code more complex design patterns and interactions

Stay tuned!

Wanna see the full result? 👀 Check out the refreshed site at kacinguyen.webflow.io (view on desktop for the best experience!)

1. Your manager holds disproportionate power over your growth and happiness both inside and outside of work. If you can, make it your #1 goal to choose a great manager. They won’t control your happiness directly, but they can create a positive work environment that encourages you to prioritize your well-being by promoting healthy work-life balance and encouraging open communication about your needs. Ask other RPMs which PMs they admire and respect. You’ll get a vetted list that you can use to further narrow down through meet-and-greets.

2. Your title can subconsciously affect how others respond to your requests. ‘Product Manager 1’ connotes inexperience and can unfortunately also subliminally signal ‘this person is not important, I won’t respond to them and/or take them seriously’. ‘Product Manager’ removes leveling as a signal and can help bring focus to the problem and not the person. This stems from the organizational philosophy that “it’s about what you do, not what you’re called”, practiced at both Stripe and OpenAI.

3. Don’t be afraid to be wrong and fail. In fact, aim to prove yourself wrong. These programs have built-in learning environments for you to make mistakes with virtually no risk.

4. Some of the most growth can come from thinking like a Principal PM, even if you aren’t one. Don’t put yourself in a box based on what your current title says you are and limit what you can do.

5. You need to be the biggest advocate for yourself and your career - no one else will be. Always keep an inventory of your work and your impact, and share it loudly and proudly, especially when it comes to your mid-year/year-end reviews.

6. Related: Never assume your work speaks for itself; speak for your work in all forums–1:1s, experience reviews, year-end reviews, launch posts, etc. Expose your work and make your value visible and known.

7. There’s magic in working with a cross-functional team that hold the same values and motivations as you: doing what’s best for the customer, raising the bar of excellence for the craft, staying curious, and enjoying the process more than the outcome. Seek these people out. They’ll push your thinking and keep you sane.

8. You can realistically(!) achieve financial independence early if you start investing in tax-advantaged accounts now! Take the time to learn (or bother RPMs passionate about personal finance) about personal finance, especially now that you’ve got a proper job and are earning more than you ever have before. It’ll pay dividends down the road en route to early retirement.

9. A healthy amount of skepticism couldn’t do you harm. Question the data and the results when something seems too good to be true.

10. Fake it ‘til you make it; that’s what everyone else is secretly doing.

11. Community becomes especially important when you aren’t getting what you need from your direct manager. Lean on the community to fill in where your manager or team cannot. It’s likely that someone has encountered and survived a similar situation as you. Ask for help, and then return the favor by providing help to keep the community thriving.

12. Whether you’re going for speed or quality, make it clear what you’re prioritizing and declare it. As important as it is to have both, you can only really do one of them well. By declaring one, you end up moving faster than attempting both since everyone understands what the goal is and can rally behind it to achieve it.

13. A paradox to innovating in 0-1 products quickly is to throw more people at the problem. But by introducing more opinions into the mix, you increase the coordination costs of needing discussion and alignment. The best teams to work on these projects are nimble, self-sufficient, and lean, which ultimately expedites the time to execution.

14. Only focus on what you can control. It’s a massive waste of energy to focus your attention on people, ideas, and processes you can’t change.

15. Related: Work on the most impactful things; don’t spend much time on the rest. But also be a good team player and don’t say no to everyone and everything.

16. Find the right hills to die on. (Save your lives and your energy! No one should be dying three times a week. Seriously, that’s a lot of death for a week.)

17. A lot of problems can be solved when leadership is aligned at the top—this is where escalations can be useful and often necessary. Consider escalations as a tool in your toolbox, and learn how to wield them.

18. When you see something, say something. Be a productive complainer.

19. Rest assured, you’re not crazy!!! When you feel like you’re going mad, talk it out with someone you trust—ideally your manager, but if not your manager, then a trusted mentor who can provide an additional perspective and sanity check.

20. The key difference between the different PM levels and titles, and what vastly differentiates a principal PM from a junior PM, is the ability to influence (imo one of the most DIFFICULT skills to master).

21. Consider the conditions in which research was conducted before you use it as empirical data to not move forward with an approach because “it’s been tried before.” The world moves quickly, and sometimes the assumptions you’ve held in the past just no longer remain true.

22. You can make your own luck by simply asking for what you want. Put it out there in the world, then put it out there again, then put it out there again. The magical powers that be will make it happen.

23. Relationships and skills are a few durable assets that no one can take away from you, not even a company. Invest in building them, they’ll yield the largest returns.

24. Remember to have fun! Take advantage of the light baggage of responsibilities you have as a new grad just entering the workforce. Enjoy the extra pockets of time to learn, explore, and try new things. And as much as you think the whole fate of the company rests on your shoulders, it fortunately does not. That would be maddeningly stressful. Log off at 5. Take PTO. Go travel the world while you still can.

25. The best part of any rotational product management program is the other RPMs you meet in the program. They’re not just co-workers, colleagues, or work friends – they can be your personal board of advisors, figures of inspiration, and friends for life who were there with you when you transitioned from an unsure baby new grad apprentice to a confident (but weathered) adult-turned PM veteran. Make time each month to check in, catch up, and send them cool/funny things you find on the Internet.

Hey, hi, ho! We’re three months into my second rotation, but I still don’t know what I’m doing! And that’s okay! Because I’m learning, and that’s what really matters.

In this rotation, I’m charting a new land of PM. One lush with ambiguity, sprawling with dependencies, and lurking with pivots. This is the land of generative AI, the 21st-century California gold rush into uncharted product territory.

Throughout a series of posts, I’ll be mapping out that land acre by acre as I learn how to wield the power of the latest technology, starting with new ways of operating.

Mindset shifts

#1: Learn first, launch later

Throughout the course of a product’s lifecycle, product managers will typically spend time in one of these phases:

In my first rotation, I fluttered mostly between building and releasing a capability feature that could apply to several products across the ecosystem. Build the feature for X offering, ship. Build the offering for Y product, ship. Occasionally, I dabbled in the Design phase to create a design that could scale with the number of use cases we were launching the capability for.

It was a Cinderella slipper, perfectly sized, fitting what I was looking for at the time. (In my summer internship before this role, I never saw my feature see the light of day. So you can imagine how eager I was to see the culmination of my work live in the product being used by real(!) customers.) The team already validated the customer problem and proved the technology worked. The research & planning and design stage were complete, and all I had to do was take the baton and run with it.

Then generative AI entered the picture.

I switched to the generative AI team when we were just falling from the Peak of Inflated Expectations into the Trough of Disillusionment of the Gartner Hype Cycle.

The new technology is like the Tesseract from Marvel. It glows and radiates and teases the power to do incredible things, and everyone wants their hands on it.

But what does it do? What exactly can it do (well)? And when should we wield its power without imploding the universe and pulverizing everyone into dust?!

After learning it can’t do that much very well in our product space, we drew a Go back 3 spaces card and entered learning mode.

Our team research spanned across the customer, the technology, the processes, the metrics— pretty much everything. Things were changing so rapidly that there was just too much to learn overnight for one individual to handle. To handle this, one of the team’s rituals was sharing what we hoped to learn at the beginning of every week and what we learned at every standup. Whatever we learned individually was shared with the rest of the team to expedite every stage of the product development phases we were in.

Generative AI ushered in a new way of operating. In this world, launching takes a backseat to learning until we feel confident about what types of problems the technology is world-class at solving.

#2: Building new norms

Onboarding onto this team, I often found myself in different situations asking “What does the team typically do?” only for my manager to reply “There’s nothing typical yet.”

You’re telling me that this team hasn’t yet figured out all the secrets to working with generative AI?!

I assumed they had all the answers neatly laid out in front of us, everything figured out. Alas, that was far from reality. It took me a bit to internalize that we were working with technology so fundamentally new and different that it confounds almost everyone in tech.

We are an early-stage product working on a mature product with millions of users. Naturally, I expected existing practices and a few “this is how we’ve been doing it on the team” to learn from. I was awaiting tried-and-true steps to take and patterns to follow because they’ve been known to work in the past. But there weren’t, not with generative AI. We were trained and experienced in making product iterations and incremental improvements, not launching new products altogether and focusing on the minimum viable product let alone an AI-MVP. The new norm on the team became having no norms at all.

No norms to work with can be a pretty exciting place to be. A blank canvas means having the unfettered freedom to build new norms and heavily shape the team culture. As PMs, we get to be the ones to build unencumbered by any pre-existing traditions or engrained practices.

I’ve never worked at a startup, but this intuitively feels like one with its embryonic team rituals. I like it.

#3: Timely escalations as a habit

Generative AI poses an existential threat to many large tech incumbents. After all, it's quite powerful and anyone can harness that power if they take two seconds to search ‘How to create an LLM.’ Being on an AI team, we’re reminded of this threat on our heels quite frequently and are constantly prodded to move fast to thwart it.

Move fast. A phrase notoriously inculcated by startups where it’s easier to achieve due to a lack of bureaucracy and tech debt. At a big company that has more than its fair share of both of those, it looks like quick escalations.

Take this scenario:

Me: I’ve validated a feature with a customer and know I want to build it.

*Goes to Person A, B, and C from Team Apple, Blueberry, and Cantaloupe who I know work on components that my feature will need*

Me: Ok, I also know I have to work with Team Dewberry since they own the security component of my feature but I don’t know who Person D from that team should be.

Now I’m two days into building out this feature and Person G and H from Team Guava and Honeydew emerge from the woodwork and unveil that their teams own the identity and motion components of my feature and that they’re already working on it.

Tada! Suddenly, we have two similar but slightly different versions to reconcile since there are platform teams we didn’t know about moving in different directions.

Me: Ok. Which components do we keep and which do we replace?

*Churn, churn, and churn… oh, do I see butter forming?*

Platform dependencies are important to building one cohesive and seamless product experience and reducing redundancy, but they do so at the cost of velocity. Adding teams can stretch out the time it takes to align on decisions and prolong the time it takes to build when the platform team has competing priorities. When teams aren’t prioritized, they may go off and build their duplicate version of the solution. Later on, these versions must be reconciled and the decision churn renews.

When you encounter a knot of platform dependencies that your team alone can’t untangle in a reasonably swift manner, lean on your leaders to step in and help reconcile. As a team expected to build up defenses against generative AI-breathing dragons, we’ve been encouraged to employ this skill whenever we experience undue churn. It turns out that what takes you days or maybe even weeks to do can be done in an hour-long meeting by leadership. Who knew?

Escalate as necessary to get the teams aligned and marching back together in the same direction.

Mindset constant: customer needs first

Our job as PMs is to advocate for our customers, understand their needs, and solve their problems. It doesn’t matter to the customer what technology we use to do this. What matters most is what technology can do for them. How does technology solve their problems better than existing solutions or workarounds?

It’s all too easy to get swept up by the hype of new technologies. As exciting as generative AI is, we need to remember that technology remains just a means to an end. Our focus should always remain on the individuals we’re building solutions for: our intrepid customers.

It’s been a while since we last talked! I’ve procrastinated on writing this for various reasons (see learning #3 for the main reason). But I’m learning to go against my perfectionist tendencies and just get my imperfect thoughts out there.

So here goes it: nuggets from my first six months in a rotational product management program. Delivered straight to your internet door. 📩

What goes up must come down

You know those first two weeks of freshman year in college when it feels like someone just hit the refresh button on life? It’s a new chapter, and suddenly we have the freedom to write whatever story we’d like. You mean, I can have ice cream for dinner? Indeed. Life is good.

But then: the not-so-fun parts of college begin to creep in—the midterms stress, the homesickness, the loneliness, the club rejections—all chiseling away at your idealistic image of what college is supposed to be like.

Enter the same story, aged a little with a wrinkle here and there.

Six months in put me just past the honeymoon stage of early grad PM life. Alas, the shininess of the program’s promises has worn off leaving me to face off with the reality of being a young new grad in a large tech company.

It went a little like this:

• From I’m going to learn fast, move quick! → To I’m blocked. I don’t have access to XYZ team’s dependent data. Guess I’ll have to wait for Sally to get back from vacation.

• From I’m going to solve problems X, Y, and Z → To I’m just going to solve X. Y isn’t prioritized by leadership to be resourced. We don’t have the right technology in place to solve Z.

• From I’m going to develop and apply all my technical design & data analysis skills → To I’m going to develop my stakeholder management, triad partner collaboration, and communication skills.

• Most tragic one yet, from New grad? Attend this development workshop and receive a free Uber Eats voucher! → To You’re on your own! Get your own food. Gone are the golden days.

It’s a classic coming-of-age tale. Girl starts work with an abundance of optimism and naivete. Girl struggles with various obstacles to ship a feature. Girl must come to terms with the limitations and characteristics of big organization and limitations: bureaucracy, politics, and dependencies that can hamper velocity and autonomy. But in the process, girl becomes woman. A working woman, I might add. Aheh.

What goes up, must come down. Innocence lost, but wisdom found.

Get comfortable with the “yes, and’s”

Surpise, plans change! Your team becomes understaffed after a staff engineer moves teams, an unexpected dependency is discovered setting back the timeline, and you’re asked to share aloud thoughts on a strategy or design you’ve never seen before on the spot.

As a fastidious planner, I would be aghast if I wasn’t given the heads up for these things — I need to plan for it! I’d exclaim.

But product management is a continuously running five-act play of improvisation. It involves taking what you’re given and running with it time and time again.

I’m learning to get better at this skill. Curveballs are expected and normal so best to plan for them by keeping flexibility in mind and brandishing the courage to march forward even when things don’t go to plan.

Procrastinator perfectionism (my worst enemy)

I‘m gonna put this off until I have the right information to get started.

I’ll hold off on committing until I feel more confident it’s the right decision for me.

Famous last words.

I tend to wait for the perfect conditions before I start anything. But in doing so, I hold myself back because the perfect conditions tend never to arise.

When these feelings surface, I try to step back and remind myself that now is a good time to start. Perfect won’t happen right away. In fact, it may never happen. But that shouldn’t hold you or anyone back from striving towards something that’s still really great. Almost always, something is better than nothing.

Re-defining self-worth

From the moment I entered the workforce, I began tying my worth to that defined by the corporate world. If I didn’t perform well against the PM competencies, I felt inferior like I didn’t belong in this role at this company on this team. In retrospect, this sounds silly.

1. For starters, Growth Mindset ™! Anyone and everyone can improve with time and deliberate effort. It’s good to be self-aware about where there’s room to grow.

2. But most importantly, your self-worth should not, I repeat, should not, be calculated by measures of capitalist productivity. Life is much grander than work. Remember that you play many roles beyond an employee or a coworker. How would you calculate your self-worth if being a good friend/daughter/son/plant mother/cat father/home cook/part-time student/etc. was the judging criteria?

You are doing the best you can given your circumstances that only you have visibility on.

Optimism as a double-edged sword

In many situations, optimism is great to have. When you’re optimistic, you tend to persevere.

I’m often told that I’m quite an optimistic person. I cherish my optimism more than I deplore it. However, every quality becomes a weakness when taken to an extreme. At its extreme, optimism means seeing everything as an “opportunity to learn” and taking on additional work that I probably otherwise shouldn’t. Other times, it means not being critical enough to question the viability of an approach since I’m optimistic what we have will work.

Over-optimism leads to an overestimation of the benefits and an underestimation of the costs.

I’m practicing pausing, debating with myself, and pushing back more often. When it comes to countering the opportunity to learn, I think about being intentional about the work I take on and correspondingly setting up the right boundaries to protect my time to do what’s best for my growth. When it comes to plans and ideas, I’m trying to get better at playing devil’s advocate to help the team arrive at the best and most accurate solution.

Being more assertive

When I started the role, most of what I worked on was drawn out for me. My projects had already been scoped and my training sessions were pre-selected. I was essentially working off a script written with my name on it.

A little bit of passivity is normal when you first start a new job at a new company. After the first few months of onboarding though, you’re expected to take the reins of your job and write the stories that will give your career your happy ending.

If you want a fulfilling rotation (and career!), be assertive. Identify what you want to do and make it happen.

See original post

The PM Diaries is a new outlet of mine to document my career journey. But secretly, it’s a forcing mechanism to surrender my thoughts to pixels & paper and produce something I could call my own, all at a sunk cost of $5/month. Here’s hoping that $5 stretches further for you than it does for me.☺

~ Kaci

Around this time last year, I breathed a sigh of relief as I closed all of my product management interview prep tabs. Each click of an X lifted a weight off my shoulder, decluttering my mind as it had my browser. Recruiting was over, I got the job.

I remember spending +100 hours in my spare time unraveling articles, devouring highly recommended books, and overpacking as much PM in my brain as it could hold before concepts would start springing back out.

Who knew that, despite cramming my brain with theories, anecdotes, and principles, I could never be adequately prepared for stepping into the role myself?

Books and videos cover theory in a perfect world, but the real world is imperfect. The real world introduces people and events as variables that you can’t calculate yet that can drastically change your performance.

Over the past five months, I learned a few things that nothing except actually being in the role could prepare me for.

About how frequently I’d question my abilities and qualification

As a senior in college, I was considered top of the chain. I had four years of college experience under my belt, more than every other class (except the super seniors, though they’re lumped with the seniors in my head.) I knew which classes to take, which professors not to take, where to study, and which orgs to join. My fellow seniors and I– we were suave, at least in the eyes of freshmen. We had that coolness factor simply because we were seniors with four years of college wisdom, and we could legally drink.

When I started this entry-level PM role, my social capital was reset to zero. I was once again the baby who’s just been birthed into the corporate world with nothing to my name. I knew nothing about the company internally, which training to take, who the best managers were, where to find the best coffee and snacks in the building, and which Slack channels to join. And, to rub salt in the wound, everyone here could legally drink. On this new campus, I was the fumbling, bright-eyed, and bushy-tailed freshman who looked up to the senior PMs.

I felt incompetent and small starting out. In one of my projects, I was in charge of a feature launch that was delayed multiple times due to code freezes, an application migration, and a misaligned deployment schedule with a dependent team. My inner critic would pester me: You should’ve asked the right questions to the engineers beforehand to set the right timeline expectations. You should’ve worked faster, harder, and more diligently to avoid this. If you had a technical background, you would’ve seen this coming!

In another one of my projects, I was working with multiple dependent teams to scale an existing feature to a new global market. While ramping up on this project, I’d already reached an impasse. It’s not like there were any disagreements (yet), but rather no one would respond to my questions and pleas for information. Again, my inner critic would prance on my shoulder touting: Of course, no one would respond to you, why should they? Your questions and requests are dumb and not worth their valuable time.

Things never seemed to work out the way I planned them to, and I couldn’t help but blame myself. However, my manager reassured me that a lot of those things were just out of my control. She put it into perspective: I’m coming into a large, relationships-based, functionally-structured organization as a newbie with zero social capital and zero work experience. I can’t anticipate everything. Escalate when you’re blocked. It’s not your fault.

Dear diary, give yourself grace and permission to fail as an entry-level new grad. Make a lot of mistakes and learn from them because forgiveness for not knowing now is a lot easier than later.

About the importance of owning who you are and voicing your beliefs

Growing up in an Asian household, I was taught to just do my job, go with the flow, keep my head down, stay in my lane, and let my work speak for itself. In the American corporate world, especially as a product manager, that couldn’t be further from what you should do.

In my first month and a half, I was often invited to small and large group meetings where I never said a word. I’d sit and nod, trying to absorb what was being said and make sense of it, and then leave. I felt guilty for being there and adding extra clutter and noise to the room even when I said nothing.

As a PM, you’re hired and paid for the way you think. You create value for the company when you share your opinion and make good decisions. What kind of PM am I if I don’t say something useful? Of course, I was still onboarding onto the product, the customers, the industry, and the job itself. These meetings were purely observational learning opportunities. I had to give myself grace.

Following my 90-day mark, I was asked more and more often, “Kaci, what do you think?” whenever the wider PM team was discussing a problem, approach, or situation. I’d feel an instant pang of panic reverberate throughout my body.

Yes, I had a better understanding of the product after playing around with it. Yes, I formed a clearer picture of who the customers were after reading customer feedback and leading customer interviews. Yes, I strengthened my grasp on the industry and its competitors after perusing internal decks and articles online. Yes, I could pull from these repositories of knowledge to proffer a meaningful, informed opinion that my team could seriously consider. But everyone else in the room already had a deep, growing knowledge of all of the above. Could I really add anything new? What do I know that they don’t?

Maybe not much. Maybe my knowledge was incomparable. But as it turns out, the knowledge you lend to the team sometimes isn’t as important as your perspective.

One day, I told my manager that I felt like I could never contribute something worthwhile while I was so new to the team and the company. Everyone seemed to know everything already, and that didn’t leave much space for me.

She shook her head and posed, “You carry with you so many unique perspectives as a Gen Z, Vietnamese-American woman coming out of college that we (the team) couldn’t bring to the table. That is already so valuable. We want to hear from this perspective.”

It took a while for me to internalize what she was saying. But she’s right. It doesn’t always matter how much we know about something. We don’t have to be the subject-matter experts of our fields. Some of the most creative thought comes from the woven, disparate events we experience in our lives starting in childhood. Each of us has a uniquely constructed perspective that’s been shaped and sculpted throughout our life: every experience you go through and every person you encounter chip away at how you see the world until it forms the lens we look through today. Apply that to whatever repositories of knowledge you have, and that becomes your value worth creating a space for.

Dear diary, remember to honor and celebrate your unique portfolio of experiences, knowledge, and insights by sharing it. Everyone, including those you’re building for, is better off when you do.

About how easily PM can easily transform work into life

In product management, there’s so much to learn, so much to read, and so much you can do as someone who’s supposed to have a whole closet of hats to wear. As someone both new to PM, new to the company, and new to the 9–5 schedule, it’s been a challenge for me to draw the line between when work ends and when life starts. My backlog of work would multiply by the hour:

• Complete HR & compliance training.

• Read through project doc.

• Read through dependent project doc to understand first project doc.

• Research what microservices are.

• Set up interview guide.

• Respond to Slack message. Respond to another Slack message. Set Slackbot reminder to respond to Slack message 1 & 2.

• Set up calendar invites for 1:1 meetings.

• Learn data schemas.

I was itching to complete it all as soon as possible, so I could start adding value to the company and not anchor the team as a dead weight. And so I kept going past 5 pm, and past 6 pm, and sometimes past 7 pm so I could continue checking off pre-requisite boxes to prove my belonging and worth.

The more I did this, the more life felt less vibrant and exciting. Is that all to it in life? To work and meet your company’s KPIs year over year? To grow only in your career and nothing else?

There’s so much more to life than that. Life’s about growing more into yourself and your potential: exploring and doing more of what you love, exercising and eating healthy, building and strengthening relationships with those you love, and simply loving and feeling loved.

Your growth continues no matter where you choose to invest your time. Just be intentional with how you want to invest it, and make every second of that time count.

See original post

The PM Diaries is a new outlet of mine to document my career journey. But secretly, it’s a forcing mechanism to surrender my thoughts to pixels & paper and produce something I could call my own, all at a sunk cost of $5/month. Here’s hoping that $5 stretches further for you than it does for me.☺

~ Kaci