I spent four years in the Navy not as a pilot, but as the person telling pilots where to go.

The E-2C Hawkeye is an unglamorous aircraft. No missiles. No guns. Just a massive radar dome bolted on top and a crew inside watching screens. While fighter pilots got the glory, we saw the whole picture. Tracked contacts. Coordinated assets. Made the calls.

The pilot flew the plane. We directed the fight.

Ten years later, I realized I'd been training for something that didn't exist yet.

Recently I shipped features on two side projects and built a presentation automation tool for work. Something that would've taken months to spec and build. I still can't write production code.

What changed wasn't my technical skills—those remain bad. What changed was the feedback loop. The gap between having an idea and seeing it exist in the world collapsed from weeks to hours. Sometimes minutes.

PMArchetype - Discover Your PM Archetype

Based on Peter Deng’s framework used at OpenAI, Facebook, Instagram, and Uber. Find your primary + secondary archetype in just 12 minutes.

Discover Your PM ArchetypePMArchetype

The strange part? I don't understand most of what gets built. I can't read the code my tools produce. But I can read the output. I can see when something's wrong. I can steer.

I should be honest: the first few months were rough. I'd give vague instructions, get back something that looked right, ship it, and then watch it break in ways I couldn't diagnose. I once spent an entire weekend trying to fix an authentication bug that turned out to be a single missing environment variable. I didn't even know what an environment variable was.

But here's what I learned: the failures weren't random. They happened when I was lazy about constraints, when I assumed the agent understood context I hadn't given it, when I skipped the feedback loop because I was in a hurry. The failures taught me what the skill actually was.

Turns out, that skill matters now more than syntax ever did.

The Bottleneck Broke

The bottleneck that kept ideas trapped in non-technical heads just broke.

Three things converged at once:

Component libraries matured. The building blocks went production-grade. When the Lego bricks are that solid, assembling them becomes the easy part.

AI learned to wire things correctly. The boilerplate disappeared. The tedious glue work—state management, CSS alignment, all of it—tools handle that now. The gap from "design intent" to "working draft" used to be days. Now it's hours.

Platforms abstracted the hard parts. Authentication, databases, hosting, deployment—used to require specialized knowledge. Now they're checkboxes.

The result? If you can clearly express what you want, you can build it. Not because you understand how it works, but because you understand what you need and why.

Good prompting feels less like magic words and more like navigation.

You're not writing code. You're steering.

Everything I Needed to Know I Learned from StarCraft

Looking back, I'd been practicing this since I was eleven without knowing it.

Age of Empires. StarCraft. Command & Conquer. Total Annihilation. Warcraft (2 & 3).

In RTS games, you don't control every unit. You don't click each peasant to harvest each tree. You set rally points. You issue high-level commands. You manage resources and production. You scout the fog of war and make decisions with incomplete information.

You intervene when things go wrong—micromanage when you have to—but the goal is building systems that work without constant attention.

Great RTS players understand macro vs. micro. When to zoom out and think about economy and strategy. When to zoom in and control a critical engagement.

Working with AI agents is the same game. You're not typing code. You're issuing commands, managing context, setting constraints. You're building repeatable patterns that start every session consistently—build orders in RTS terms. You're scouting what the agent produces and intervening when it drifts.

I spent thousands of hours training for this in my parents' basement. I just didn't know it had a professional application. When I picked my Navy job, I chose the E-2C specifically because it felt like the real-world version of what I'd been doing since age eleven—watching the whole map, managing resources, calling the shots.

Three Builders Who Changed How I Think

I've been trying to understand who's actually succeeding in this new world. Not the hype—the people quietly shipping things that work. Three stood out.

Ben Tossel: The Practitioner

Ben shipped 50+ projects in four months. Used 3 billion tokens doing it. He can't read the code he produces, but he reads the agent output religiously.

His workflow is deceptively simple: Feed context about what you're building. Switch into "spec mode" to pressure-test the plan. Question everything you don't understand. Then let the agent run while you watch and steer.

The part that stuck with me: "The fastest learning path is building ahead of my capability and treating bugs as checkpoints—fail forward."

He's not waiting to understand before he builds. He builds, hits problems, and learns from the gaps. The problems ARE the curriculum.

Sunil Pai: The Framework

Sunil applied Steven Johnson's "Where Good Ideas Come From" to agent work and landed on something useful: a map of where agents are strong and where they drift.

where good ideas come from (for coding agents)

(and the part where users have to level up)

Solving the decision problemSunil Pai

Agents handle incremental steps—the "adjacent possible." Small diffs from what already exists. Pattern completion. Fast iteration on defined problems.

What they're weak at: anything requiring reality to push back. They'll generate plausible nonsense all day unless you give them constraints, context, and feedback loops.

His core insight: what changed across the week wasn't the model — it was the user.

The agent didn't get smarter. The person using it got more explicit about what they wanted.

Angus Chang: The Business Model

Angus built Bank Statement Converter. It takes PDF bank statements and converts them to CSV. That's it. The whole product.

Bank Statement Converter | About

Convert bank statement PDFs to Excel for free

About

It makes over $20,000 per month in profit with minimal maintenance. He launched during the Web3 hype. It grew through the AI hype. He ignored both trends and kept solving a boring problem for accountants.

The lesson I took: boring problems + simple solutions + fair prices = sustainable business. You don't need to chase what's hot. You need to solve something real and charge for it.

But the reason it works isn't his technical skill. It's his product judgment: picking a boring problem, keeping it simple, charging fairly, saying no to enterprise clients who wanted to own his roadmap. The code is table stakes. The navigation is the differentiator.

These three aren't traditional engineers. They're a new class of builder. And the skill they share has nothing to do with syntax.

The Navigation Stack

If agents make code cheap, what becomes expensive?

Sunil Pai's framework breaks it down:

![[navigation-stack.png]]

The formula: Constraints + Context + Oracle + Loop

Constraints aren't vibes. They're laws. What can't change? What breaks everything if the agent touches it? Write those down.

Context is what the agent needs to know about your world. Not generic best practices—your specific codebase, your conventions, your definition of "good." A portable instruction manual that follows you across projects.

Oracle means: how do you know when it's right? Not "looks good to me"—actual tests, benchmarks, something that creates a gradient toward truth. Hope is not a verification strategy.

Loop means small diffs, run checks, iterate. Not big-bang deployments. Tight feedback.

"Agents make code cheap," Sunil writes. "They don't make judgment cheap."

The scarce skill isn't typing. It's expressing constraints clearly. Designing oracles. Curating context. Running tight loops. Navigation.

What to Build: Simple, Lovable, Complete

Product people obsess over MVPs—Minimum Viable Products. Build small, ship fast, learn from customers.

The problem is most MVPs are too "M" and never actually "V." They're incomplete. Embarrassing. Customers don't want products that embarrass their creators.

Jason Cohen's alternative: SLC. Simple, Lovable, Complete.

Simple because complex things can't be built quickly, and you need to ship to learn.

Lovable because people have to WANT to use it. Products that do less but are loved beat products with more features that are disliked.

Complete because customers accept simple products but hate incomplete ones. v1 of something simple, not v0.1 of something broken.

Bank Statement Converter is the perfect SLC:

• Simple: One function. PDF in, CSV out.
• Lovable: Clean interface. Just works.
• Complete: Does the job on day one.

The pattern for the new technical class:

1. Solve a problem you personally have
2. Check if it applies to businesses (B2B beats B2C for revenue)
3. Build the simplest complete version
4. Make it lovable before feature-rich
5. Charge fairly—and raise prices until the math stops working

Angus doubled his prices and made more money with fewer customers. Most people undercharge.

How to Start

If you're a PM, data leader, or analyst reading this and feeling the itch, here's where to start:

Pick one tool and go deep. Stop hopping between Cursor, Claude Code, Replit, v0. Pick one. Learn its patterns. The switching costs of tool-hopping exceed the benefits of the "best" tool.

Start with your own problems. Angus needed to track his spending. Ben needed internal tools. Your best ideas are already in your frustration list. What do you keep waiting for someone else to build?

Build your portable config. Create your version of agents.md or CLAUDE.md. Your preferences, your constraints, your definition of "good." Every session should start from your context, not zero.

Fail forward. Bugs are checkpoints, not failures. You don't study first and build later—you build and learn from the gaps. The problems are the curriculum.

Read the output, not the code. You're developing a new literacy. Watch what the agent does. Ask why when you don't understand. Close knowledge gaps as they appear. You won't become an engineer, but you'll become fluent enough to steer.

Ship complete before complex. One simple thing that works beats ten features that don't. SLC over MVP. If it's not lovable and complete, it's not ready—no matter how minimal.

Coordinator, Not Operator

In the Hawkeye, we had a saying: "The picture is the weapon."

It didn't matter how fast the fighters could fly or how many missiles they carried if nobody knew where to point them. The tactical picture—knowing where everything was, what it was doing, and what needed to happen next—that's what won fights.

The same is true now.

The AI is fast. It can write code I can't read. It can spin up features in minutes that would take engineering sprints. But it doesn't know where to point itself. It doesn't have the picture.

You do.

The question isn't "can you code?" It's "can you navigate?"

Can you see the whole battlespace? Can you express intent clearly? Can you set constraints that keep things on track? Can you intervene when things drift and let things run when they're working?

That's not engineering. That's command.

You've probably been training for it longer than you realize. Especially if you've been a PM or data leader. Coordinating stakeholders. Managing roadmaps. Understanding a domain deeply enough to know what should exist.

The tools finally caught up. The bottleneck broke.

What's the first thing you'd build if shipping was cheap?

You probably already know. It's the thing you've been waiting for someone else to build for you.

Stop waiting.

Last week I read Peter Yang's "25 Things I Believe in to Build Great Products."

25 Things I Believe In to Build Great Products

What I believe in is often the opposite of how big companies like to work

Behind the CraftPeter Yang

His first principle? "Speed is the only moat."

I nodded. Then I stopped.

I've spent 9 years building data products in healthcare. Started at a consulting company in Nashville, worked for a massive health system, led analytics at a company scaling from Series A to exit, shipped three products solo in six months using AI tools.

Peter's framework is excellent—for most products - its awesome, honestly. But data products play by different rules so there is some nuance.

In software, the feature is the value. In data products, the data is the value. Different game entirely. You can't recreate context. You can't speed your way to a new workflow.

Here's what I actually believe. Some of this will sound obvious. Some of it contradicts what's popular. All of it comes from things I got wrong before I got them right.

Trust is Compounding

1. Trust compounds slowly and is destroyed instantly.

Morgan Housel wrote that

growth is driven by compounding, which takes time—but destruction is driven by single points of failure, which can happen in seconds.

That's data products in a sentence. You spend months building credibility. One bad number in front of the wrong executive and you're back to zero. I've seen it happen. I've caused it to happen.

2. Your data quality IS your reputation.

In SaaS, a bug is annoying. In data products, a wrong number is existential. When someone pulls a metric from your product and puts it in a board deck, your reputation is on the line. They don't remember the 47 accurate numbers. They remember the one that made them look foolish.

3. Credibility comes before features.

I used to think we needed more dashboards, more metrics, more capabilities. Wrong. What we needed was for people to trust the three dashboards we already had. Feature roadmaps don't matter if your users are double-checking your numbers in Excel.

4. Validation is not bureaucracy.

In my 20s as a data engineer/analyst, I resented data quality checks. They slowed us down. Then I shipped a cohort analysis with a join bug that inflated our numbers by 40%. The client's analyst found it before we did—in a board meeting. Now I don't ship anything without validation. It feels slow. It's actually the fastest path to trust.

5. Your users are experts — treat them that way.

Docs, nurses, seasoned healthtech sales reps, pharma leaders, and researchers know their domain better than you ever will. When they say a number looks wrong, they're usually right. I've learned more from users questioning my dashboards than from any product review. The skeptics are your best QA team.

Teams Need Operating Systems

6. Data products need the Product Squad, not the Trio.

The Product Trio (PM, Tech Lead, Design Lead) works for SaaS. Data products need a fourth seat: the Data Lead. Someone who owns data quality, data model, and data governance as first-class concerns. Without this, data quality lands on everyone—which means nobody actually owns it.

Learn more here Beyond the Product Trio - Why Data Products Need a Squad

7. Each role needs its own operating system.

I spent years trying to force Scrum onto data teams. It doesn't fit. Data scientists need deep exploration time. Data engineers need uninterrupted flow. Analysts need rapid iteration. One methodology doesn't work. Each role needs workflows tuned to how they actually think. (hint hint: more to come here)

8. Handoffs are where things break.

The interesting part of team coordination isn't the ceremonies—it's the handoffs. When the PM's requirements become the engineer's spec. When the analyst's insight becomes the designer's dashboard. I once watched a three-month project fail because the handoff between analysis and engineering lost a critical assumption about how dates were formatted. One team assumed UTC. The other assumed local time. Nobody wrote it down. Make these explicit. Document what context needs to transfer. Most failures trace back to a lossy handoff.

9. Ceremonies designed for software teams suffocate data teams.

Two-week sprints fragment data work that requires deep exploration. Daily standups interrupt flow states. Sprint planning assumes you know what you'll discover. You don't. Data work is exploratory by nature. Your process needs to accommodate that.

10. The best teams ship context, not just artifacts.

A data model without documentation is a liability. A dashboard without a data dictionary is a guessing game. The artifact is only half the deliverable. The context—why it exists, what it assumes, where it breaks—is what makes it usable.

Applying Shape Up for Data Product Teams

The best way to look at a problem is not to view it as a problem at all but as an opportunity to grow stronger, more skilled, more confident. - John C. Maxwell The Continuous Sprint Dilemma Six months into leading Revive’s data product team, I faced a familiar problem.

Kevin HollandKevin Holland

The Ground is Always Shifting

11. Data is alive, not static.

Software code does what it did yesterday. Data doesn't. Upstream systems change. Coding practices drift. New edge cases appear. What was clean last month is dirty this month. If your mental model assumes data is stable, you'll be constantly surprised.

12. Yesterday's clean data is today's mess.

I've never worked with a dataset that stayed clean. Every data product I've built eventually discovered data quality issues we didn't anticipate. Not because we were sloppy—because the world changed. A new hospital joined with different coding practices. A vendor updated their schema without telling us. A field that was always populated started coming in null from one site. We had a pipeline that ran perfectly for eight months, then broke because a single provider started entering diagnoses in a free-text field instead of using the structured codes. Stuff happens. Plan for it.

13. Build for change, not perfection.

In 2018, I tried to build "the perfect data model." Wasted four months. Now I build for change. Modular. Documented. Easy to extend. The perfect model doesn't exist because the requirements will evolve. Design for evolution, not permanence.

14. Governance is enablement, not control.

Data governance gets a bad reputation because it's usually implemented as a series of "no's." Good governance is actually a series of "yes, and here's how." It's documentation that helps people self-serve. It's guardrails that prevent mistakes without blocking progress.

15. Document like the future will question you.

Six months from now, someone will ask why a metric is calculated a certain way. If the answer lives only in your head, you've failed. Document your assumptions. Document your decisions. Document the edge cases you chose to ignore. Your future self will thank you.

Think in Value, Not Capabilities

16. Start with business impact, not data.

The biggest mistake data teams make is starting with "what data do we have?" instead of "what decision are we trying to improve?" I've built dashboards nobody used because we started with available data. Now I start with: what changes if this works?

17. Products over projects.

Projects end. Products evolve. When you treat data work as a project, you deliver something and walk away. When you treat it as a product, you own it through its lifecycle. You iterate. You respond to feedback. You improve. I once inherited a data warehouse that a previous team built as a "project" in 2019. That team was long gone by the time I arrived. Nobody understood why certain decisions were made. Nobody owned it. It was technically working but practically useless because nobody trusted it enough to use it. The product mindset is the difference between one-time value and compounding value.

First Principles Thinking for Data Product Teams

A New Approach for Complex Environments: As a young business analyst, I started my first contract in a warehouse and operations plant. A hundreds of years old manufacturer that had no ERP (enterprise reporting platform) or inventory tracking yet was wildly profitable for decades (their products were sold in cans

Kevin HollandKevin Holland

18. If you wouldn't charge for it, don't build it.

I ask myself this question constantly: "If we had to charge our internal stakeholders for this, would they pay?" It's a brutal filter. Cuts through a lot of "nice to have" requests. If the answer is no, maybe we shouldn't build it.

19. Reusability is a design constraint, not an afterthought.

Single-use data products are expensive to maintain and hard to justify. When I design something now, I ask: "Can this serve three use cases, not just one?" Sometimes the answer is no. But asking the question changes how you design.

20. Outcome-driven beats deliverable-driven.

I used to measure success by what we shipped. Dashboards delivered. Pipelines built. Models deployed. Wrong metric. Now I measure by outcomes changed. Decisions improved. Time saved. Revenue impacted. Shipping is easy to count. Impact is what matters.

Domain Expertise is the Moat

21. A nurse who can code beats a coder who doesn't understand nursing.

I've hired both. The domain expert who learned technical skills consistently outperforms the technical expert who tries to learn the domain.
(Actually, let me be more precise: consistently outperforms in the first two years. After that, the gap narrows. But most data products don't have two years to wait.)

Healthcare is complicated. Coding practices vary by system. Clinical workflows have nuance. We once had a data scientist with impeccable credentials build a model to predict patient readmissions. Technically flawless. But they'd included "arrival by ambulance" as a feature, which correlated strongly with readmissions. A nurse on the team pointed out the obvious: sick people arrive by ambulance. We weren't predicting readmission risk—we were predicting how sick someone was when they arrived. You can teach SQL. You can't quickly teach 20 years of clinical experience.

22. The business can't be Googled.

Technical problems have Stack Overflow answers. Domain problems don't. Understanding why a certain ICD-10 code is used differently across health systems isn't documented anywhere. This knowledge lives in people—clinicians, analysts, operational staff. Cultivate these relationships.

23. Healthcare doesn't work like tech.

Moves slower. Regulations constrain everything. Stakeholders are risk-averse for good reasons—mistakes hurt patients. I've watched people from consumer tech companies try to bring "move fast and break things" to healthcare. It doesn't work. The culture is different. The constraints are different. Adapt.

20 Leadership + Product Lessons from a Healthdata Guy

Here are 20 lessons covering building data products, working with teams, and being a better version of who you already are.

Kevin HollandKevin Holland

24. Regulated context changes everything.

HIPAA isn't just a compliance checkbox. It fundamentally shapes what you can build, how you can build it, and who can access it. I've seen beautiful product ideas die because they required data sharing that wasn't legally possible. Know your constraints before you start designing.

What Meta’s 2025 Restrictions Mean for Data and Product Leaders

Meta’s new healthcare ad restrictions aren’t just another privacy update - they’re a fundamental shift in how we’ll have to think about healthcare growth. Drawing from my years measuring health system campaigns at Revive Health, I break down what this means for data and product leaders, why CDPs mig

Kevin HollandKevin Holland

25. Your users know more than you—learn from them.

Healthcare analysts have spent years understanding their data, their systems, their edge cases. I approach every user conversation assuming they know something I don't. Because they do. The best product improvements I've made came from users who told me I was wrong.

These are lessons, not rules. Your context is different. Healthcare is different from fintech is different from e-commerce. Data products serving researchers are different from those serving operations.

But if I had to bet, I'd bet on trust over speed. On domain expertise over technical flash. On products that evolve over projects that end.

What do you believe about building data products that the industry hasn't figured out yet?

That's probably worth writing down. (I'm still figuring some of mine out.)

Last Thursday at 3pm, I coached a PM through her first 30 minutes in Claude Code. She'd never touched a terminal. By minute 7, she stopped being scared. By minute 20, she was synthesizing customer feedback across 12 call notes—something that used to take her half a day. By minute 30, she stopped asking permission to try things.

This isn't a coding tool. It's Claude, living on your computer. And once you see what it can do with your files, your meeting notes, your backlog of half-finished docs... you won't go back to copy-pasting into chat windows.

The Naming Problem

Claude Code shouldn't be named Claude Code.

The name scares PMs, analysts, and business folks. Recently, political analyst Matt Yglesias tweeted his shock at discovering Claude Code "is NOT just for developers." He's right to be surprised—and he's not alone. Most people see "Code" and think "not for me."

But here's what Anthropic actually shipped: browser automation, reading your files, persistent memory. The name is misleading. The capability is real.

Forget the name. Think "Claude Local"—an AI that lives on your computer and works where you work.

Three Ways to Use Claude

1. Claude in the app (what you probably already use)

You're having conversations. Writing summaries. Getting help with meeting recaps. It's chat, but smarter. No setup beyond your account. Best for quick questions and back-and-forth thinking.

2. Claude in Chrome (browser automation, no terminal required)

This one's newer. Claude lives in Chrome's side panel. It navigates websites, clicks buttons, fills forms. Think of all the repetitive browser work you do—competitive research, data entry, copying information from one system to another. Claude can do that while you watch.

Best for: Repetitive browser work. And here's the key—if you're terminal-averse, you can stop here. Path A. You'll save hours weekly from Chrome automation alone.

3. Claude Code (the terminal tool)

This is the full capability. Claude reads your local files without copying and pasting. Processes entire folders at once. Creates and edits files directly. Connects to Jira, Notion, databases.

Best for: Working with files and multi-step workflows. Path B for folks comfortable copy/pasting commands. This unlocks everything.

The Real Difference

File access and persistent memory.

When you ask chat Claude to "analyze my meeting notes," you copy-paste them. Token limits. Context loss. Tedious.

When you ask Claude Code to "read my meeting notes from this week," it actually reads them from your computer. No pasting. No limits. It remembers what you worked on yesterday.

Both paths are valid. If you only want browser automation, you never have to touch the terminal. If you want the full system—file operations, memory, integrations—the setup takes 5 minutes of copy/pasting commands.

Helen Lee Kupp (from Lenny's article): "I'm a mom who voice-records ideas during morning stroller walks, not a developer. The terminal interface? Overwhelming at first. But I discovered Claude Code isn't about coding at all."

Teresa Torres (product discovery expert): "Using Claude Code isn't about being technical. It's about being willing to try three to four simple commands."

Pick your comfort level. Start where it feels safe. You can always add more capability later.

The Memory Advantage

Here's why this matters: Chat Claude has amnesia. Every session starts from zero.

Claude Code has memory. A file called CLAUDE.md stores everything about your projects—your context, your preferences, even your voice. Next session? It remembers.

Before: "Let me re-explain my company, my role, my project, my constraints..." (every. single. time.)

After: Claude just knows. You start where you left off.

How it works is simple. CLAUDE.md is your project brain. It auto-loads when you start. You add to it over time. Claude references it before responding.

The problem isn't AI capability—it's context loss. Claude Code solves context loss.

The PM I coached? By session two, she'd added her project context, her stakeholder map, and her communication preferences to CLAUDE.md. Now when she asks Claude to draft an update, it already knows who she's talking to and what matters to them.

Teresa Torres runs her entire business this way—every morning, she types /today into Claude Code. It pulls tasks from Trello, generates a daily plan, and she's working. No re-explaining. No context loss. "You didn't have to remember how you did it last time. You didn't have to hunt for any files. You didn't have to copy and paste."

That's the transformation. You stop using AI as a question-answering service. You start building systems that get better over time.

Pick Your Path

Both paths work. Choose your comfort level.

Path A: Browser Only (No Terminal)

For: Terminal-averse folks who want browser automation without touching command line

Setup takes 5 minutes:

1. Install "Claude for Chrome" extension from Chrome Web Store
2. Pin the extension (click puzzle icon, then pin Claude)
3. Open Claude side panel, sign in
4. Critical safety setting: Choose "Ask before acting"

I learned this the hard way. The first time I used Claude in Chrome, I didn't enable "Ask before acting." Claude was... enthusiastic. It clicked through a form faster than I could verify the inputs. Nothing broke, but I didn't enjoy watching my browser move without my approval.

"Ask before acting" means Claude pauses at each step. Shows you what it's about to do. Waits for your thumbs-up. It's slower, but you'll sleep better.

What you can do:

• Fill forms from spreadsheet data
• Extract competitor pricing from websites
• Navigate admin panels and update records
• Pull data from dashboards into structured formats

The moment it clicks: When Claude fills a 20-field form while you watch, saving you 15 minutes of data entry.

Stop here if you want. This alone saves you hours.

Path B: Full Setup (Terminal + Optional Chrome)

For: Folks comfortable copy/pasting commands who want file access and persistent memory

Setup takes 5 minutes:

Step 1 - Install:

curl -fsSL https://claude.ai/install.sh | bash

That's it. One command. Copy it, paste it into Terminal (Mac/Linux) or Command Prompt (Windows), hit Enter. It installs everything you need.

Step 2 - Launch:

claude

Type claude and hit Enter. Claude Code opens. You're in.

Step 3 - Try your first prompt:

Summarize what files are in this folder and help me organize my thoughts on [current project]

The moment it clicks: When Claude reads your files without you pasting anything. No token limits. No context loss.

Optionally add Chrome integration: If you also want browser capabilities from the terminal, start Claude with claude --chrome and connect it to the Chrome extension. Now Claude can verify file work in actual browsers.

My recommendation: Start with Path A or B. Don't try to learn everything at once. Get one surface working, build confidence, then add more.

Key Concepts for Non-Coders

The One Pattern That Matters Most: Plan First, Execute Second

This is THE most important pattern in Claude Code: Always get the plan before the action.

Before Claude touches any files, browsers, or data—have it show you what it's going to do. Review the plan. Then approve execution.

Why this works:

• Catches Claude thinking "update all files" when you meant "update the draft file"
• Teaches you how Claude interprets your instructions
• Builds trust (you see the thinking before the doing)
• Saves hours of cleanup from well-intentioned wrong actions

How to do it (use this exact pattern):

[Your task description]

Before doing anything, show me your plan:
- What you're going to do
- What files/pages you'll touch
- What the output will look like

Do NOT execute yet. Just show the plan.

Then review the plan. If it looks right: "Proceed with the plan."

In Claude Code, Shift+Tab twice activates plan mode (Claude's built-in version of this). But you can also just add "show me the plan first" to any prompt.

Kevin's rule: Anything new? Always plan mode. It's never led me astray. It'll feel slow at first. It will save you 20 minutes of cleanup.

When I coached that PM, we used plan mode for everything the first session. By minute 15, she said "this is tedious." By minute 22, Claude had caught a misunderstanding in its plan—it was about to rename all her files instead of just organizing them into folders. She became a plan mode convert.

File Reading

Claude reads your docs directly—no pasting. Works better with markdown and txt than .docx (honestly, most things do). Point it at synced folders: Dropbox, Google Drive, OneDrive.

The PM I coached keeps all her customer call notes in Google Drive. They sync locally. Claude reads them there. No exports. No manual transfers. Just "read my customer calls from this week."

Agents vs Skills (Know the Difference)

Agents: Conversational hats you manually put on.

Create specialized agents for different contexts: "QA PM hat," "Leadership communication hat," "Engineering update hat." Each has a unique voice and focus. You invoke them—you choose which one to use.

The PM I coached created her first agent in under 5 minutes. She called it "Customer Voice." Its job? Always push back if her language gets too internal-focused. Always ask "would a customer understand this?"

Skills: Workflows that auto-activate when Claude recognizes context.

Unlike manually selecting an agent, Skills engage automatically when relevant. Your "meeting notes processor" Skill activates whenever you paste a transcript. Why this matters: Consistency without remembering to invoke it. Build once, applies forever.

Think of it this way: Agents are like putting on different hats. Skills are like trained habits Claude just does.

Start with agents. Skills are advanced, but once you nail a workflow, turn it into a Skill so it runs consistently every time.

5 Quick Wins for PMs

These aren't coding tasks. They're thinking tasks that Claude handles better than any chat interface.

1. Meeting Notes → Action Items (The Rigorous Version)

Here's what a detailed prompt looks like. The others can be simpler—this one shows you the pattern.

Read this meeting transcript and create a structured summary.

OUTPUT FORMAT (markdown):

## Meeting Info
- Date: [extract from transcript or write "not stated"]
- Attendees: [list names mentioned as present]

## Decisions
[ONE bullet per decision with format: Decision (who confirmed it)]

## Action Items
| Owner | Task | Due Date | Context |
[If no due date stated, write "TBD". If no owner assigned, write "unassigned"]

## Open Questions
[Unresolved items or items marked for follow-up]

## Risks or Concerns Raised
[Or write "None explicitly raised" if none]

## Slack-Ready Summary
[Exactly 3 sentences for someone who wasn't there]

RULES:
- Only include decisions that were actually confirmed, not just discussed
- Do NOT invent owners or due dates—only use what's explicitly stated
- If someone said "I'll do X," that person is the owner
- Distinguish "we should do X" (not a decision) from "we're going to do X" (decision)

PROOF (add this section at the end):
For each decision and action item, include a short quote from the transcript (max 15 words) that supports it. Format: "Quote" — [Speaker if known]

This lets me verify you captured things accurately.

Why this works: Explicit structure, rules for edge cases, proof for verification.

Time saved: 15-20 min per meeting. That's 1-2 hours weekly if you have 5+ meetings.

The others don't need this much detail—once you see the pattern, you can simplify. This one teaches rigor.

2. Document Synthesis Across Sources

Read all files in ~/Documents/CustomerCalls/ and tell me what patterns emerge across these conversations

Point it at 7 call notes. 12. 20. It doesn't matter—Claude reads them all and finds the patterns you'd miss staring at a spreadsheet.

Verification: Ask Claude to "Show me 3 specific patterns and list which files they came from." Spot-check a couple files to confirm the patterns are real, not hallucinated.

Time saved: Half a day → 10 minutes.

This is what made the PM I coached stop asking permission to try things. She had 12 customer call notes sitting in a folder (probably more like 15, but she'd lost count). Been meaning to synthesize them for two weeks. Felt like it would take hours. She asked Claude. Got patterns in 8 minutes. Verified them in 3 more. She looked at me and said "I can just... do this now?"

Yes. You can just do this now.

3. Technical Concept Ramping

Explain [technical thing] using the Feynman method. Break it down so I can have an informed conversation with engineering tomorrow.

My current understanding: [what you know]
What I need to discuss: [the decision or question]

This one's huge for PMs who feel intimidated in technical discussions. Claude won't just explain—it'll prep you with questions to ask.

Verification: After Claude explains, ask: "What's one thing I should clarify with engineering about this?" Tests whether Claude actually understood the concept or just paraphrased docs.

Time saved: The anxiety of walking into a meeting underprepared. (Hard to quantify, but real.)

4. Status Report Generation

Help me draft a status update for leadership.
What I accomplished: [bullets]
What I'm focused on: [current work]
Blockers: [if any]
Format: scannable, concrete, no fluff

Verification: Read the draft back and ask yourself: "Would I say this out loud to my boss?" If it sounds like AI-generated fluff, add: "Make this sound like I wrote it, not a bot."

Time saved: 20-30 min weekly. More importantly, your updates stop reading like corporate word salad.

5. Stakeholder Communication

Draft a Slack message to engineering about [decision/update].
Context: [what happened]
What I need from them: [the ask]
Tone: clear, direct, not self-congratulatory

That last line matters. Claude defaults to cheerful corporate-speak. Tell it not to.

Verification: Before sending, check the tone. If it has exclamation points or says "excited to share," rewrite. Engineering teams can smell AI-generated cheerfulness.

Time saved: 10-15 min per message, plus the draft usually needs less editing.

Two Tips That Matter

Dictation Changes Everything

Here's something that changed how I use Claude Code: I don't type most of my prompts. I dictate them.

Why it matters for non-coders: You think out loud faster than you type. When you're explaining context, constraints, and what you actually want, dictation captures it all.

How: I use WisprFlow (Mac app Talk through your context, it transcribes, paste into Claude Code. Other options: MacOS dictation, Superwhisper.

The PM I coached? She started dictating by minute 25. Her prompts got better immediately—more context, more specific asks. Turns out when you're talking instead of typing, you naturally explain things more thoroughly.

Structure Your Prompts

The difference between prompts that work and prompts that don't: Structure.

Vague fails:

Research competitors

Structured works:

Research the top 5 competitors to [Company] in [Industry].

For each, provide:
- Company name
- Founding year
- Estimated revenue range
- Key differentiator (one sentence)
- Source URL

Output as CSV.

Do not include companies outside [Geography].
If you can't find revenue data, write "Not disclosed" with a note explaining what you searched.

See the pattern? Tell Claude what you want, what format to use, what rules to follow, and how to prove it worked.

This is what turns "help me with X" into "produce Y in Z format with these constraints."

You don't need this level of detail for every prompt. But when a prompt fails, adding structure fixes it.

What NOT to Do

Common mistakes:

1. Skipping plan mode on new tasks - Just... don't. It's 2 extra keystrokes that save you 20 minutes of cleanup.
2. Using .docx files - Claude can read them, but markdown and txt work better. Convert when you can.
3. Never clearing context - After a big task, type /clear. Context accumulates. Claude gets confused.
4. Vague prompts - "Write a PRD" fails. "Write a PRD for healthcare provider workflow targeting hospital systems, focusing on scheduling" works.
5. Never testing in plan mode first - New workflow? Always dry-run it before trusting Claude with 200 files.

Warning signs Claude is lost:

• References files that don't exist
• Repeats tasks you already completed
• Output starts contradicting itself

The fix: Type /clear and start fresh. Claude's context has limits—about 200,000 tokens. Long sessions fill that up. Sometimes you just need to reset.

The Mindset Shift

You're not learning to code. You're learning to direct an AI that happens to live in your terminal.

The terminal stopped being scary for her at minute 7. Maybe minute 10. Definitely before minute 15. She said "wait, I can just... ask it things?"

Yes. You can just ask it things. About your files. Your projects. Your computer. Your apps. Your half-finished docs that you've been avoiding.

Start here: Pick one prompt from the quick wins section. Try it Monday. See if you save 15 minutes.

This isn't just a productivity tool. The persistent memory, the agents, the file access—it's the beginning of a data PM operating system. A command center that remembers your projects, knows your voice, and scales your thinking.

But that's a story for another post.

What's the one repetitive task you'd love to never do again?

Resources

• Lenny's Newsletter: Everyone should be using Claude Code
• Teresa Torres: Claude Code - What It Is, How It's Different
• Teresa Torres: Full Tutorial - Automate Your Life with Claude Code
• Nate Jones: Claude Code Workflow Guide - Comprehensive setup and mental models (adapted for PMs in this post)
• Atlassian MCP Setup Guide

It's 10:47am on a Wednesday. In the last 47 minutes, I've switched contexts six times:

Reviewed a dbt pull request changing how master_person_stats.total_psych_visits is calculated

• Debugged why the exec dashboard shows different numbers than Marketing's report
• Analyzed a CSV with 200 customer feature requests
• Responded to Engineering asking what breaks if we rename user_id to customer_id
• Updated next quarter's roadmap priorities
• Switched back to Slack to answer "quick questions" from two different teams

This is Data PM work. Not planning in Google Docs. Not writing specs in Notion. Actual work happens across technical systems - code repositories, database schemas, BI tool configs, data files, pipeline logs.

And I'm constantly translating between two worlds: technical depth (understanding SQL logic, tracing dbt dependencies) and business strategy (presenting to executives with zero jargon).

For years, I thought the problem was that I needed better tools. Faster BI dashboards. Smarter query builders. More automated pipelines.

I was wrong.

The problem wasn't the tools. The problem was that I didn't have an operating system to stitch them together.

The Data PM Reality: You Work Across Systems, Not In Them

Let me paint you a complete picture of yesterday (Tuesday, typical week).

10:00am: Analytics engineer pushed changes to our dbt repository. The SQL logic for calculating active users changed. I need to understand what changed, validate it matches product requirements, and check if any downstream dashboards will break. I'm in Cursor, reading SQL, tracing table dependencies.

10:23am: Data Engineering Slack lights up: "Why does the exec dashboard show 52,000 active users but Marketing's report shows 47,000?" I switch to Databricks, open the dashboard config, compare the SparkSQL: definition to the underlying dbt model, trace where the metrics diverge. Back in Cursor to check the SQL. Then to Databricks to run the raw query. Three different systems to answer one question.

11:15am: Back to Slack. Sales team forwarded a prospect question: "Can your platform filter by symptoms (by Mental Status Exam) at the encounter level?" I need to check our data model. Open the Notion docs site and cross reference with github repo. Search for encounter tables. Verify the schema. Write a technical answer. Translate it into sales language. Two more context switches.

1:30pm: Customer Success sent a CSV with 22 feature requests from Q3. I need to categorize them by theme, identify most-requested features, and prioritize for the roadmap. The data is sitting in a file. Analysis needs to happen today. Roadmap meeting is tomorrow morning.

2:45pm: VP Slacks me: "Quick question - if we rename person_id to patient_id in the warehouse, what breaks?" I need to find all references across dbt models (Cursor), Databricks views (Databricks), downstream dashboards (Metabase), and any scripts or notebooks (GitHub). Four systems. Need the answer in an hour.

4:00pm: Presenting roadmap priorities to the executive team. No technical jargon. Pure business outcomes. I switch from reading SQL to translating technical constraints into strategic decisions.

This is the Data PM middle space. You're not technical enough to be an engineer (you're not writing production pipelines). You're not business-focused enough to stay in documents and strategy (you can't make good decisions without understanding how data actually works).

You live between two worlds. And you context-switch constantly.

Every PM book says "partner with engineering" for technical work. In practice, that means I'm blocked waiting for someone else's calendar while my deadline doesn't move. Engineering has their priorities. Data analysis can't wait three days.

I tried using ChatGPT and Claude (desktop) for this work. The pattern was always the same:

1. Find the dbt model I need (in VS Code)
2. Copy the SQL into chat
3. Ask my question
4. Remember this model references three other models
5. Go back to VS Code
6. Find those three models
7. Copy all of them into chat
8. Re-ask my question with full context
9. Get a better answer, but I've lost 15 minutes to copy-paste

The problem wasn't the AI capability. The problem was the environment mismatch.

Chat AI lives in one tab. I work across five systems.

The Insight: You Don't Need Better Tools. You Need an Operating System.

Here's what finally clicked for me.

I don't need faster individual tools. I need something that sits across all my technical environments - the dbt repository, the data warehouse, the BI tool configs, the CSV files, the pipeline logs - and remembers context as I move between them.

Not a tool that does one thing better. An operating system that creates a layer across everything I touch.

This is different than what traditional PMs need. Traditional PMs work in documents. Specs in Notion, designs in Figma, feedback in spreadsheets. Their work lives in files they control.

Data PM work lives in systems others build. The data warehouse. The transformation pipelines. The BI tools. These systems are constantly evolving. Schemas change. Models get refactored. Dashboards drift from their sources. I don't control when or how they change. I work WITH them and get influenced by them.

And that requires a fundamentally different kind of support.

I need:

• Persistent memory about my data systems (what tables exist, how they join, where quality issues hide)
• Reusable workflows across all my projects (not rebuilding analysis patterns every time)
• Parallel work capacity (one agent analyzing dbt logic while another debugs a dashboard - matching my actual context-switching)
• Direct access to where I work (the file system, the databases, the configs - not copy-pasted into a chat window)

This is what I mean by an operating system. Not a collection of tools. A coherent layer that sits across all my technical environments and amplifies how I work.

CLI tools like Claude Code created that layer for me. And its working.

The Three Layers of a Data PM Operating System

After eight months using Claude Code as my primary work environment (since March 2025), I've realized it's not just "AI in the terminal." It's a complete operating system with three distinct layers that work together.

Layer 1: Persistent Memory (CLAUDE.md)

Every project gets a CLAUDE.md file. This is the brain. It remembers context about this specific data environment so I don't have to re-explain it every session.

My NeuroBlu Analytics CLAUDE.md contains:

• Data model overview (which tables exist, how they join, what each one represents)
• Known data quality issues (encounter dates before patient birth dates in 0.3% of records)
• Team conventions (we use _id suffix for foreign keys, _at for timestamps)
• Product context (we serve pharma researchers analyzing 36M patient records)
• Strategic priorities (cohort builder enhancement is Q4 focus)

This isn't instructions for the AI. This is project memory. When I switch contexts from marketing dashboards to clinical data models, the memory persists. Claude Code reads the relevant CLAUDE.md and already knows the data landscape.

Compare this to ChatGPT, where every new chat starts from zero. I'd spend the first 10 minutes of every session explaining what NeuroBlu is, what our data model looks like, what I'm trying to accomplish. With CLAUDE.md, that context is already loaded.

The memory layer follows a simple principle: low friction creates sustainable discipline.

If remembering context is hard, I won't do it consistently. If it's automatic, it compounds over time. CLAUDE.md makes memory automatic.

Layer 2: Skills and Commands (Reusable Workflows)

Skills are portable expertise packages. I build a workflow once, package it as a skill, and it works across all my projects.

My "customer-feedback-analysis" skill:

• Takes any CSV with customer queries
• Categorizes by theme (feature request, bug, data quality, how-to)
• Identifies most-requested features
• Generates executive summary
• Creates prioritized list for roadmap discussions

I built this for NeuroBlu customer feedback. But it works on any product's customer data. The skill is portable.

Here's where it gets powerful: progressive disclosure.

When I load Claude Code, it doesn't dump all my skills into context. It loads metadata only (~100 tokens per skill). When I start working with customer data, Claude recognizes the task and loads the full customer-feedback-analysis skill (~2,000 tokens). When I switch to analyzing dbt models, that skill unloads and the dbt-analysis skill loads.

This solves the context overload problem. I can have dozens of skills available simultaneously without overwhelming the AI's context window. They load on-demand, exactly when needed.

Skills also stack (composability). My "dashboard-audit" skill works with my "data-quality-check" skill. When I audit a dashboard, both skills activate automatically. One validates the dashboard config. The other checks if the underlying data has quality issues. They compose without me orchestrating them.

Commands are simpler - one-shot automations for daily tasks. I have a /roadmap command that reads my project files and generates a prioritized list based on customer feedback frequency. It runs in 30 seconds. Before, this took me 2 hours manually.

The skills/commands layer follows another principle: focus on inputs, not outputs.

I can't control when analysis is finished or how good the insights are. But I can control having the right workflows ready when I need them. Skills let me package the "right input" (the analysis process) and reuse it consistently.

Layer 3: Sub-Agents (Parallel Cognitive Work)

This is where it gets wild.

Data PM work requires parallel processing. I'm debugging a dashboard (technical, detail-oriented) while simultaneously analyzing customer feedback (pattern recognition, strategic thinking). These are different cognitive modes.

Sub-agents let me spawn isolated Claude instances that work in parallel, each with their own focus.

Real example from last week:

• Main session: Reviewing dbt pull request for active user calculation change
• Sub-agent 1: Analyzing impact on downstream Looker dashboards
• Sub-agent 2: Checking if Marketing's reports use the same metric definition
• Sub-agent 3: Scanning customer feedback for any requests related to active user metrics

All four running simultaneously. Each sub-agent has isolated context (no cross-contamination). They report back when done. I review, synthesize, make the decision.

This matches how Data PM work actually happens. I don't do things sequentially. I work on multiple parallel tracks, synthesize insights, make decisions.

The sub-agent layer follows a third principle: break the constraint.

The constraint isn't "I need to work faster." The constraint is "I can only hold one context in my head at a time." Sub-agents break that constraint. They gave me space to run builds at different phases.

The Transformation: From Scattered Tools to Integrated System

Here's what changed when I shifted from "using AI tools" to "operating a system."

Before (Chat AI scattered across tabs):

• Morning planning: 15-20 minutes of friction, often skipped
• Customer feedback analysis: 6 hours of manual Excel grinding
• dbt model review: Copy-paste SQL into ChatGPT, lose context, start over
• Dashboard debugging: Switch between 4 systems, manually trace logic
• Strategic drift: Spend weeks on work that doesn't actually matter
• Forgotten projects: Start analysis, lose context, start again later

After (CLI operating system):

• Morning planning: 2 minutes (system reads my files, generates prioritized roadmap)
• Customer feedback analysis: 30 minutes (skill does categorization, I review and synthesize)
• dbt model review: Direct file access, full context always loaded, sub-agent checks downstream impact
• Dashboard debugging: One environment with access to dbt repo, Looker configs, and warehouse
• Strategic alignment: Every task scored against my documented priorities
• Complete traceability: All work logged, context never lost

The time savings are real (3-4 hours per week). But that's not the transformation.

The transformation is mind peace.

I know I'm working on the right stuff. There's continuity. Nothing gets lost. When I switch contexts, the system remembers where I was. When I need a workflow, it's already packaged as a skill. When I need parallel work, sub-agents handle it.

This is what an operating system does. It doesn't make individual tasks faster (though it does). It makes the entire work environment coherent.

Why Low Friction Actually Matters

The key productivity principle: low friction creates sustainable discipline.

If something is hard to do, I won't do it consistently. If it's easy, it becomes automatic.

Chat AI had friction at every step - copy data into chat, re-explain context when switching projects, manually recreate good workflows every time. Every friction point burns mental energy.

CLI tools remove those friction points. Data access is automatic. Context persists in CLAUDE.md. Workflows are packaged as skills. This compounds - less friction today means I'm more likely to do it tomorrow. Habit becomes sustainable discipline.

And sustainable discipline equals freedom.

The Evolution From Tools To System

If you're still thinking "I just need better AI tools," I get it. I was there six months ago.

Here's how my thinking evolved:

March 2025: Discovered Claude Code can read files directly. Game-changer for customer feedback analysis. (Still thinking: better tool)

April 2025: Started writing CLAUDE.md files for each project. Context stopped disappearing. (Starting to think: memory system)

May 2025: Built first agent - customer feedback analysis became portable across all projects. (Realizing: reusable workflows)

July 2025: Experimented with sub-agents for parallel work on dbt review or discovered and adopted BMAD + Cursor: The First AI Framework That Actually Makes Sense for PMs. (Aha moment: this is an operating system)

October 2025: Added 5 more skills, refined CLAUDE.md structure . (Operating at a different level)

The shift from "tool" to "system" happened gradually. But the implications are massive.

What's Next

This is Part 0 of a three-part series on CLI tools for Data Teams. Understanding that you need a system (not just better tools) that works to change your ehaviors.

Part 1 tells the transformation story - the exact moment I stopped waiting for engineering, the customer feedback analysis that took 30 minutes instead of 6 hours.

Part 2 explains the technical fit - why CLI tools sit where Data PMs actually work, how MCPs connect to every system you touch, why sub-agents match your context-switching reality.

The tools exist (Claude Code, Codex, Cursor, Gemini CLI, other CLI environments). The question is whether you're using them as scattered tools or building them into a coherent system.

I chose system. Its working so far.

Continue Reading:

• Part 1: I Stopped Waiting for Engineering to Analyze Data. Here's What Changed. - Getting up and running with a CLI tool
• Part 2: Data PMs Work Across Technical Systems, Not Just Documents - Why CLI tools finally fit where we work

About the Series

This is Part 0 of "CLI Tools for Data Teams" - a three-part series exploring how CLI-based AI tools like Claude Code create an operating system for Data Product Managers. The series covers the foundation (why you need a system), how to get started (real workflows and onboarding), and the technical fit (environment alignment).

References and more learning

The Claude Code Complete Guide: Learn Vibe-Coding & Agentic AI

Unlock Anthropic’s terminal-based AI: From 5-minute setup to multi-agent workflows, learn best practices, cost control & vibe-coding tricks to build faster, safer, and with plenty of fun along the way

Nate’s SubstackNate

Claude Code Best Practices

A blog post covering tips and tricks that have proven effective for using Claude Code across various codebases, languages, and environments.

20 Tips to Master Claude Code in 35 Minutes (Build a Real App)

My 20 best tips to master Claude Code while building a personalized family activity finder app step-by-step

Behind the Craft by Peter YangPeter Yang

Everyone should be using Claude Code more

How to get started, and 50 ways non-technical people are using Claude Code in their work and life

Lenny's NewsletterLenny Rachitsky

"Your gut is the world's most sophisticated machine learning model ever created." - David Lieb, General Partner at YC

The $2M Dashboard That Nobody Used

Three months into my role at a healthcare analytics company, our CEO pulled me aside with a problem. We'd just spent $2M building what our data team called "the most comprehensive patient experience dashboard in the industry." It had every metric you could imagine: bed utilization rates, patient throughput times, staffing efficiency scores, patient response scores, and predictive models for everything from readmissions to length of stay.

Hospital executives loved the demos. The visualizations were beautiful. The data was "accurate" - the feed from the EHR was clean.

Nobody used it.

"What are we missing?" he asked. I thought I knew the answer: more data, better visualizations, maybe some AI-powered insights. I was wrong.

The breakthrough came during a casual conversation with Dr. Martinez, a nursing supervisor at one of our pilot hospitals. She mentioned something that never showed up in our metrics: "I wish I could just know when Mrs. Chen in room 302 is getting anxious about her discharge. That's when problems happen."

Our dashboard could predict average length of stay across thousands of patients, but it couldn't tell Dr. Martinez what she actually needed to know about the one patient causing her stress at 2 PM on a Tuesday.

That's when I realized the fundamental problem: we'd built a quantitative masterpiece that ignored qualitative reality.

Why Data PMs Are Caught in the Quant vs. Qual Trap

Data product managers face a unique challenge that traditional software PMs don't encounter. We live in the intersection of two worlds that often feel incompatible:

The Quant World: Dashboards, metrics, A/B tests, and statistical significance. Great for answering "what" questions, terrible for "why" and "what should we do about it?"

The Qual World: User interviews, support tickets, anecdotes, and edge cases. Rich with context and emotion, but difficult to scale and prone to bias.

Most data teams pick a side. The analytically-minded gravitate toward dashboards and metrics. The user-focused lean into research and interviews. Both approaches miss the magic that happens when you combine them.

As Sachin Rekhi points out in his work on product intuition: "Market research and customer surveys can become proxies for customers. Good inventors and designers deeply understand their customer... They study and understand many anecdotes rather than the averages you find on surveys."

But here's the problem: understanding "many anecdotes" doesn't scale. Traditional user research is painfully manual, slow to generate insights, and expensive to maintain. Meanwhile, dashboards give us averages that miss the nuanced stories where real opportunities hide.

Product Intuition(Sense) as Your Internal ML Model

The best data product managers I know have something that's hard to define but easy to recognize: product sense. As Jules Walter defines it in Lenny's Newsletter,

They can look at a metric anomaly and immediately know which customers to call. They spot opportunities in customer complaints that others dismiss as edge cases. They make bets that seem risky but consistently pay off.

This isn't magic—it's pattern recognition built through exposure to both quantitative signals and qualitative stories. Product sense relies on both empathy to discover meaningful user needs and creativity to come up with solutions that effectively address those needs.

David Lieb's quote about gut instincts being "the world's most sophisticated machine learning model" isn't just clever—it's a profound insight into how product intuition actually develops. Like any ML model, building strong product sense requires:

High-Quality Training Data: Direct, unfiltered customer feedback connected to product outcomes, not summaries or averages.

Lots of Iterations: Fast feedback loops where you can see the immediate impact of product decisions on real user behavior.

Pattern Recognition: Exposure to enough examples that you start seeing connections between seemingly unrelated signals.

The challenge? Most data product teams never get enough "training data" to build strong intuition. They're too removed from customers, too focused on metrics, or too buried in feature delivery to develop the pattern recognition that separates good PMs from great ones.

The AI Shift: From Process to Intuition

Here's what's changing: AI is automating much of the mechanical work that used to define good product management. Data analysis that took hours now happens in minutes. Competitive research that required days can be done with a few prompts. A/B test results that needed statistical expertise are now interpreted automatically.

As Brian Balfour argues in his recent work on AI-native product teams, this automation creates a fundamental shift in what makes product managers valuable. Process skills are becoming commoditized. The new differentiator is intuition—the ability to synthesize disparate signals into confident product bets.

But here's the opportunity: the same AI tools that are commoditizing process can also help us build intuition faster than ever before.

Feedback Rivers: Merging Quant and Qual in Real Time

The concept of "feedback rivers" isn't new—Sachin Rekhi pioneered the approach while building LinkedIn Sales Navigator. The idea is simple: create continuous streams of unfiltered customer feedback flowing directly into teams' existing workflows.

But AI has transformed what's possible with feedback rivers. Instead of choosing between overwhelming fire hoses of information or sterile dashboard summaries, we can now create intelligent, personalized streams that surface both quantitative signals and qualitative context.

This approach mirrors what Jules Walter calls "observing people interacting with products"—one of the key practices for building product sense. The difference is that AI now lets us do this observation at scale, systematically, rather than just in occasional user research sessions.

Here's how it works in practice:

Step 1: Set Up Your Feedback Infrastructure

Connect multiple data sources into a unified stream:

• Support tickets and chat logs
• User interview transcripts
• Sales call recordings (with permission)
• Product usage analytics
• NPS surveys and feedback forms
• Social media mentions and reviews

Step 2: Intelligent Routing and Personalization

Use AI to automatically:

• Tag feedback by product area, feature, or user segment
• Route relevant feedback to the right team members
• Surface anomalies and patterns that need attention
• Connect quantitative spikes or drops to qualitative explanations

Step 3: Active Exploration

When you have a hypothesis or idea, use AI to instantly:

• Pull all relevant feedback and data
• Identify customers to interview
• Quantify potential impact
• Generate follow-up questions

Step 4: Close the Loop

Track how feedback translates to product decisions:

• Connect insights to shipped features
• Measure before/after impact
• Build institutional knowledge that survives employee turnover

A Real Example: Intuition in Action

Let me share a concrete example of how this approach changed everything for our team.

We were building a patient medication adherence tool for a large health system. Our dashboard showed that medication compliance was dropping among diabetes patients, particularly in the 55-75 age group. The metric was clear, but the "why" was missing.

Traditional approach would have been to schedule focus groups, design surveys, or dig through support tickets manually—all taking weeks to organize and execute.

Instead, our AI-powered feedback system immediately surfaced relevant signals:

• 12 support tickets mentioning "confusing medication reminders"
• 3 sales calls where nurses mentioned "patients don't understand the app"
• Usage data showing 73% of users abandoned the medication logging flow at step 3
• Interview transcript from one month prior: "My mom gets overwhelmed by all the buttons"

Within 30 minutes, we had a hypothesis: the medication logging interface was too complex for our core demographic. We called three patients from the feedback system and confirmed the hunch. Two weeks later, we shipped a simplified interface.

Result: 34% improvement in medication logging completion rates and a 28% increase in overall adherence scores.

The breakthrough wasn't the individual pieces of data—it was the ability to connect quantitative signals (dropping compliance) with qualitative context (interface confusion) in real time. This example illustrates several key insights about user behavior that experienced PMs learn to recognize: people are time-crunched and distracted when using products, they drop out as soon as they feel confused, and too much information at once creates overwhelm.

Common Pitfalls and How to Avoid Them

After implementing feedback river approaches across multiple data product teams, I've seen the same mistakes repeatedly:

Drowning in Data

The Problem: Teams set up comprehensive feedback systems but get overwhelmed by volume.

The Solution: Start narrow. Pick one product area and one type of feedback. Build your pattern recognition gradually.

Over-Relying on AI Summaries

The Problem: AI-generated summaries lose nuance and emotional context that's crucial for understanding customer pain.

The Solution: Always dig into raw feedback. Use AI to surface relevant examples, but read the actual customer words.

Ignoring Edge Cases

The Problem: Focusing only on majority feedback and missing outliers where the best opportunities often hide.

The Solution: Specifically look for anomalies and edge cases. The patient who uses your tool in an unexpected way might reveal your next major feature.

Feedback Without Action

The Problem: Collecting lots of feedback but not connecting it to product decisions and outcomes.

The Solution: Create clear processes for translating insights into roadmap changes. Track which feedback led to which features.

Building a Culture of Merged Intelligence

The technical setup is only half the battle. Building intuition requires cultural changes that support both quantitative rigor and qualitative empathy:

Share Stories, Not Just Stats

In team meetings, lead with customer anecdotes that provide context for metrics. Instead of "engagement dropped 15%," try "engagement dropped 15%, and here's what Sarah told us about why she stopped using the feature."

Create Feedback Rituals

Build regular touchpoints where teams discuss both quantitative trends and qualitative insights:

• Weekly "signal review" meetings combining metrics and customer feedback
• Monthly deep dives into edge cases and outliers
• Quarterly retrospectives on how feedback influenced product decisions

Democratize Customer Access

Don't gate customer interactions behind specialized roles. Make it easy for engineers, designers, and data scientists to access customer feedback and participate in user research.

Document Pattern Recognition

Create shared repositories where teams can document the connections they've found between metrics and customer behavior. This institutional knowledge becomes invaluable as teams grow and change.

The New PM Workflow

Here's what the day-to-day workflow looks like for data PMs who have successfully merged quant and qual:

Morning Routine: Check your personalized feedback stream alongside your metrics dashboard. Look for connections between quantitative anomalies and qualitative signals.

Hypothesis Formation: When metrics raise questions, immediately query your feedback system for relevant customer context. Use AI to surface related conversations and behavioral patterns.

Decision Making: Before committing to product changes, validate hypotheses with a quick outreach to customers identified through your feedback system.

Impact Measurement: After shipping features, track both quantitative metrics and qualitative feedback. Connect outcomes back to the original insights that drove decisions.

Knowledge Sharing: Document successful connections between signals and outcomes. Share patterns with your team and contribute to institutional learning.

As you implement this workflow, you'll likely notice improvements in your product sense: you'll start anticipating non-obvious user problems, develop higher-quality hypotheses about product experiences, and contribute more unique insights to your team. Most importantly, you'll be right more often about what impact changes will have on both metrics and user behavior.

The Future of Data Product Intuition

As AI continues to evolve, I believe we'll see an even tighter integration between quantitative and qualitative signals. The best data product teams will be those who:

• Build AI systems that enhance human pattern recognition rather than replacing it
• Create feedback loops that connect customer insights directly to product outcomes
• Develop institutional knowledge that transcends individual team members
• Balance statistical rigor with empathetic understanding of user needs

The goal isn't to choose between data and stories—it's to build systems where both inform each other in real time.

Getting Started: Your 30-Day Action Plan

Ready to start building your own feedback river and scaling product intuition? Here's a practical 30-day plan:

Week 1: Audit Your Current State

• Map all your existing feedback sources (support, sales, research, analytics)
• Identify gaps where quantitative signals lack qualitative context
• Choose one product area to focus on initially

Week 2: Set Up Basic Infrastructure

• Connect 2-3 feedback sources into a unified stream (Slack channel, shared dashboard, etc.)
• Start routing relevant feedback to appropriate team members
• Begin tagging feedback by theme and product area

Week 3: Active Exploration

• Pick one metric anomaly from the past month
• Use your feedback system to find related customer conversations
• Interview 2-3 customers to validate or challenge your hypotheses

Week 4: Close the Loop

• Implement one small change based on your merged insights
• Measure both quantitative and qualitative impact
• Document what you learned and share with your team

The Bottom Line

In the genAI era, the competitive advantage for data product managers won't come from better processes or more sophisticated dashboards. It will come from the ability to synthesize quantitative signals with qualitative insights and build strong product sense.

The teams that master this synthesis—that can spot opportunities in the intersection of metrics and customer stories—will build products that don't just work, but that users actually love.

Your gut instinct is indeed the world's most sophisticated machine learning model. But like any ML system, it's only as good as the training data you feed it. Start building your feedback river, start training your intuition, and start making product bets that combine the rigor of data with the wisdom of real customer stories.

The future belongs to data product managers who can think like algorithms and feel like humans.

References

1. Brian Balfour + Sachin Rekhi - How To Use AI To Build and Scale Product Intuition
2. Jules Walter - How to develop product sense (Lenny's Newsletter)
3. Marty Cagan - Product Sense Demystified (SVPG)
4. Aakash Gupta - What the Product Sense Interview is Evaluating
5. Shreyas Doshi - Product Sense Course (Maven)

What's your experience with merging quantitative and qualitative insights? I'd love to hear your stories and lessons learned. Connect with me on LinkedIn or drop a comment below.