How I use Claude Code to build products as a PM

I have a confession. I'm a Principal PM at a company with 150 million users, and I ship code every day. Not because I'm secretly an engineer. Because the barrier between "having an idea" and "shipping it" has collapsed.

In the past year, I've built PeerWealthy (a SwiftUI iOS app), ScreenshotEdits (a macOS utility), this website, and dozens of internal tools. All with Claude Code. None of these would exist if I had to write the code myself.

This isn't a review. It's a workflow guide from someone who uses Claude Code 6-8 hours a day, every day.

The Setup

My workspace looks nothing like a typical developer's. I run Claude Code from a central directory that contains my projects, a knowledge base, and a skill library. Think of it as a cockpit.

The key pieces:

• A CLAUDE.md file that acts as my operating manual—project context, priorities, coding conventions, team dependencies
• A skills system with 40+ reusable prompts for common tasks like creating blog articles, generating landing pages, or writing JIRA tickets
• MCP servers that connect Claude Code directly to our CMS, SEO tools, Notion, and more
• Session context that carries over between conversations so I don't re-explain everything

This setup didn't happen overnight. I've iterated on it for months. But the core insight is simple: Claude Code gets dramatically better when you give it structured context about your world.

What I Actually Build With It

Full Applications

PeerWealthy is a finance comparison app for shared households. It's built in SwiftUI with The Composable Architecture (TCA) and a Supabase backend. I'd never written a line of Swift before starting it.

Claude Code writes the implementation. I make the product decisions. When I say "add a comparison view that shows the delta between two financial profiles," it generates the SwiftUI views, the TCA reducers, the Supabase queries. I review, test, iterate.

The same goes for ScreenshotEdits—a macOS app for annotating screenshots. Built entirely through conversation with Claude Code.

Automation Systems

At Picsart, my team of two engineers and I built over 50 tools in a year. Many of those are automations I prototyped with Claude Code before handing off.

I've built custom MCP servers that let Claude Code talk directly to our Strapi CMS, Google Search Console, and internal APIs. When I say "create a landing page for 'AI background remover' with these components," it builds the page structure and pushes it to our CMS. No Postman. No Swagger docs. Just conversation.

The skill library is another example. Each skill is a structured prompt that encodes best practices—our SEO checklist, our landing page conversion principles, our brand voice. When I invoke /blog-article-creator, it loads the right context, asks me focused questions, then writes to spec.

Content at Scale

We generate programmatic SEO pages and landing pages through Claude Code connected to our CMS. What used to take a designer and engineer a week now takes me an afternoon.

Not because the quality is lower. Because the repetitive parts—component assembly, meta tag generation, internal linking—are automated. I focus on the creative and strategic decisions.

My Daily Workflow

Here's what a typical day looks like:

Morning: I open Claude Code and say "good morning." It loads my session context—what I worked on yesterday, active blockers, today's priorities. It checks my calendar through Notion. It gives me a briefing.

Working sessions: I switch between projects. For each one, Claude Code knows the tech stack, the repo structure, the design system. I describe what I want in product terms: "Add a filter for subscription tier on the comparison page" or "Create a landing page for our new video generator tool."

Content creation: When I need a blog post, a LinkedIn update, or a strategy doc, I use skills. They enforce quality—no AI-sounding phrases, correct brand voice, proper structure. The output needs editing, but the first draft is 80% there.

End of day: I tell Claude Code to update the session context. Tomorrow's session picks up where today left off.

The Skills System

This is the piece I'm most proud of, and the one that makes the biggest difference.

A skill is a structured prompt stored as a markdown file. It defines:

• What the skill does and when to use it
• Dependencies to auto-load (style guides, examples, context files)
• An interview protocol—what questions to ask before generating output
• A quality checklist to verify before delivering

For example, my /landing-page-generator skill auto-loads our conversion optimization checklist, our design system components, and examples of high-performing pages. When I invoke it, it asks me about the target keyword, the user intent, and the CTA strategy. Then it generates the complete page structure.

I have skills for everything: SEO audits, JIRA ticket creation, LinkedIn posts, weekly growth reports, PRD writing. Each one encodes weeks of learning into a reusable system.

The pattern is always the same: I do something manually, notice what works, then encode it into a skill so the next time is faster and more consistent.

What Works Brilliantly

Translating Product Thinking Into Code

I think in user flows, not functions. Claude Code bridges that gap. I describe behavior: "When a user taps compare, show a side-by-side view with the difference highlighted in green or red." It figures out the implementation.

This is genuinely transformative for PMs. You can prototype ideas in hours, test them with real users, and throw away what doesn't work—without consuming engineering sprint capacity.

Maintaining Context Across Sessions

The session context system means I don't start from zero every day. Claude Code knows my projects, my priorities, my blockers. It's like having a colleague who took perfect notes yesterday.

Enforcing Quality at Scale

Skills with quality checklists mean the output is consistent. Our landing pages follow the same conversion principles whether I create them on Monday morning or Friday evening. Our blog posts pass the same AI detection checks every time.

Connecting to External Systems

MCP servers changed the game. Instead of copying data between tools, Claude Code reads from our CMS, writes to our CMS, queries our analytics, and creates JIRA tickets—all in the same conversation.

What Doesn't Work

I'd be lying if I said it was all smooth. Here's where I hit walls.

Complex Refactoring

When you need to restructure a codebase—change an architecture pattern, rename a core concept across 50 files—Claude Code struggles with the scope. It's great at focused changes but gets confused when the blast radius is large.

I've learned to break these down. One module at a time. Clear boundaries. Explicit instructions about what not to touch.

Debugging Production Issues

When something breaks in production and you need to trace through logs, network requests, and state management simultaneously, conversational debugging is slow. Sometimes print statements and a good mental model are faster than explaining the full context.

UI Polish

Claude Code can build functional UIs fast. But the last 20% of polish—pixel-perfect spacing, animation timing, gesture feel—requires visual iteration that's hard to do through text. I end up in Xcode's preview mode making manual adjustments.

Over-Reliance

This is the subtle one. When you can generate code quickly, you're tempted to add features instead of simplifying. I've caught myself building complexity that a better product decision would have avoided.

The PM discipline matters more, not less, when building is easy.

The Full-Stack Builder Argument

Here's why I think every PM should learn to build with AI tools.

It's not about replacing engineers. My team's engineers do things I can't—system design, performance optimization, production reliability. What changes is the type of work that requires engineering time.

When I can prototype a feature, test it with users, and hand off a working reference implementation, the engineering conversation changes. Instead of debating specs, we discuss tradeoffs in a working system. Instead of a 3-week sprint, we do a 1-week polish.

This is the "small teams beat big teams" thesis in practice. Two engineers and a PM who builds shipped 50+ tools in a year. That's not because we worked harder. It's because the PM stopped being a bottleneck between ideas and implementations.

Getting Started

If you're a PM curious about Claude Code, here's my advice:

Start with your own problems. Don't build something ambitious. Automate a report you make every week. Generate a document template. Build a script that saves you 30 minutes a day.

Invest in context. Write a good CLAUDE.md file. The time you spend structuring your context pays back tenfold. Claude Code with good context is a different tool than Claude Code without it.

Build skills incrementally. Every time you do something twice, make it a skill. Every time a skill produces bad output, improve the prompt. Your skill library compounds over time.

Stay in product mode. The danger is becoming a hobbyist developer who tinkers. Keep asking: does this solve a real problem? Would a user care? Is this the highest-leverage thing I could build right now?

The Mindset Shift

The biggest change isn't technical. It's identity.

For 13 years, I was a PM who wrote specs and convinced engineers to build things. Now I'm a PM who builds things and brings engineers in for the hard parts. The feedback loop between "what if we tried X" and "here's X, working" went from weeks to hours.

That changes how you think about products. You prototype more. You test more. You throw away more. And counterintuitively, you ship better products—because you explored more of the solution space before committing.

I'm not suggesting every PM needs to become a developer. But the PMs who can build—even imperfectly, even with AI assistance—will have an unfair advantage in the next decade.

The tools are here. The barrier is just willingness to start.