A few weeks ago, we talked about why every PM needs a GitHub account. The immediate response: "OK, but what do I actually do once I have one?".
This playbook answers that with three scenarios from a 20-minute fix to owning a full feature with a clear framework for what to build, how to build it, and what to never skip.
But first, two uncomfortable truths.
The "I'm not technical" era is over
The gap between PMs who can build and PMs who can only spec is becoming a gap in career trajectories. AI has collapsed the learning curve.
This isn't about becoming a engineer, it's about closing the gap between your ideas and working software, fast enough that you stop being dependent on someone else's bandwidth to validate your thinking.
You need to be dangerous enough to prototype, to fix, to show rather than tell. That's the new baseline: get technical asap.
AI builds fast, and it exposes your taste
The hardest part of product was never the building, it's the deciding. AI builds fast, but it can't decide what to build or why… yet. It executes with terrifying confidence, give it a half-formed idea and it will hand you back a polished version of the wrong thing.
That's why discovery still matters: understand the problem so deeply that the solution becomes obvious. Gain more conviction and faster, before you start building.
AI can accelerate parts of this work, but it can't replace it. Discovery is yours, judgment is yours, and judgment has a name: taste.
Taste is hearing "we need a dashboard" and shipping a single number instead. Taste is killing the feature that tested well because it clutters the experience. Taste is choosing the boring solution that ships Monday over the clever one that ships never.
AI amplifies your taste, or exposes your lack of it.
Discovery is more alive than ever
Every case in this playbook starts with the same four questions. Skip them and AI will happily build the wrong thing for you in record time (and not even complete).
What problem am I solving? Not the feature request, the underlying opportunity to improve, validated, not assumed.
What does "done" look like? The behavior change, the metric that moves, if you can't articulate it, you're not ready.
What's the smallest version I can test? The version that answers your riskiest question fastest.
Who do I check with before shipping? Eng, design, legal, your manager, skip them now, get blocked later.
This is design thinking, compressed. You can run this entire process with 021 - from problem to scoping what to build, before you start vibe coding. It's the methodology layer that makes everything else in this playbook work.
The Playbook: The Three Cases
These build on each other: Case 1 teaches you the workflow and earns you credibility, Case 2 lets you validate ideas without waiting on anyone, Case 3 changes how your team ships entirely.
Don't skip ahead, each case builds skills and trust you'll need for the next one.
CASE 1: The Quick Fix | "Ship it yourself instead of waiting 2 sprints"
There's something small stuck in the backlog: a button label that confuses users, a broken link in the onboarding flow, a copy change legal approved three weeks ago that nobody's had time to implement.
You could write another Slack message asking when it'll get prioritized, or you could fix it yourself.
Why this matters
Your first fix will take two to three hours, including setup and fumbling with Git commands you've never used before. You'll feel lost in the codebase, but by your fifth fix, you'll do the same thing in twenty minutes without thinking about it, the learning curve is steep but short.
When you fix them yourself, two things happen: the problem is solved, and engineering sees that you respect their time enough to handle what you can handle. That respect compounds into trust, which compounds into influence over time.
What you need before you start
Access to your team's repo (see Section below “How to Get Started” for how to earn this)
Cursor or Claude Code installed on your machine.
How to actually do it
In Cursor / Claude code, in Agent mode, describe what you want in plain language: "Find where the button text 'Submit' is defined in the signup flow and change it to 'Continue'." The AI Agent does the search, the fix and shows you the changes.
Run it locally, review it carefully, does it make sense? Is it only touching what you expected? Request your agent to review it, to analyze risks of your change in Ask mode: “Are we ready to push our changes? Are we touching something else besides our desired fix?”
Once you're confident, commit and open a pull request: you can do it manually in the Changes section, or ask your agent to do it. Ensure you write a clear description: what you changed, why, and any context a reviewer needs. Then tag and ask the engineer for review.
What can go wrong
You break something, so:
Only touch isolated changes, ask the AI agent about the blast radius before you start.
Use proper corporate Cursor rules / Claude skills that follow engineer guidelines
Always open a pull request instead of pushing directly to main.
If you follow these rules, the worst case is that your PR gets rejected and you learn something.
You fix the wrong thing. You assume a broken link is blocking conversions, you fix it, but conversions don't move. You've just learned your assumption, so use product frameworks and revisit question one: is this actually what's blocking the metric?
Engineers feel territorial. Some see PM involvement as overstepping. Ask permission first: "Can I take a shot at this so it's off your plate?" Most will appreciate the help. A few won't, read the room.
What success looks like
A merged PR with your name on it. A metric that moves because you moved it, a quiet shift in how you see yourself: you're someone who fixes things now.
Your PR will get comments: maybe you missed a spot, or there's a cleaner approach. This is the process working, so make the changes, learn from the feedback, don't take it personally.
What failure looks like
Your PR sits for a week, remember to follow up. You break something in staging, flag it immediately, revert, learn. You spend four hours and give up, try again next week with something smaller. The mechanics get easier every time.
CASE 2: The Prototype | "Bring Evidence, Not Slides"
You have a hypothesis, maybe users are dropping off at step three of onboarding because you ask for too much information upfront. You're reasonably confident you're right, but you don't have proof.
The traditional path: spec → design → prototype → test → synthesis. This cycle takes four to eight weeks, and sometimes it never finishes so the prototype gets deprioritized, the learning never happens, and the hypothesis lives forever in a Google Doc nobody reads.
You can now compress this process to days or hours.
Why this matters
When you show up with a prototype that real users have touched, with their feedback attached, the conversation changes. You're not asking people to imagine how users might react, you're showing them, that's a different kind of authority.
What you need
A v0 or Lovable account, OR comfort branching from the repo using Cursor / Claude code.
A clear hypothesis (revisit the four discovery questions if you're unsure)
Access to users who can test
Choosing your tool
You have two paths: standalone prototyping tools (v0, Lovable) or branching directly in your product's codebase with Cursor / Claude code.
v0 or Lovable work best when you're exploring a new concept that doesn't exist in your product yet, when you want to test something radically different from the current experience, or when you need to move fast without any codebase dependencies.
These tools generate clean, functional prototypes in minutes.
The tradeoff: your prototype lives outside the product, so you can't leverage existing components, design systems, or real data. It's a simulation, not the real thing.
Branching in Cursor works best when you're iterating on something that already exists, a modified flow, a new step in an existing process, a variation on current UI.
You create a branch, make changes against the real codebase, and deploy a preview.
The tradeoff: you need repo access and enough codebase familiarity to navigate (Case 1 skills). The upside is significant, your prototype uses real components, real styling, and can pull real data: users are testing something much closer to what they'd actually experience.
For your first few prototypes, v0 or Lovable will feel easier. As you get comfortable with Case 1 workflows, branching becomes more powerful.
What can go wrong
You prototype the wrong thing. You skip the hypothesis and just start building. A week later you have something polished that proves nothing. Write your hypothesis first, every time: "I believe [user segment] will [behavior] if we [change]."
Define what validated looks like before you build.
Stakeholders mistake your prototype for a commitment. They see a working thing and assume it's on the roadmap. Frame clearly every time you share: "This is a research prototype to test a hypothesis. It's not a commitment."
Design feels bypassed. If you build without involving designers, you create political friction. Loop them in early: "I want to get early signal before we invest design resources". Most will appreciate the approach.
Users tell you what you want to hear. You ask "do you like this?" They say yes because they're polite. Don't ask for opinions, give them a task. Watch where they hesitate, behavior reveals what politeness conceals.
How to do it
Write your hypothesis with precision: vague hypotheses produce vague learnings. "Users will like the new flow" tells you nothing, "If we show users their first dashboard preview before asking for company size, onboarding completion will increase by 15%" tells you exactly what to build and measure.
Build the prototype:
In v0 or Lovable, describe what you want with your product’s screenshots attached:
"A three-step onboarding flow where users see a dashboard preview before we ask for company information"
If you're using Cursor, create a branch and describe the changes in Plan mode, then approve to build it:
"We are building a prototype to test it, so don't focus on backend / api code, just focus on components and UI and if necessary mock behaviours. The goal is to modify the onboarding flow to show the dashboard preview component after step two, before the company info form"
Review what the AI generates. Resist the urge to polish, the goal is testable, not beautiful.. When you commit and publish this branch, Vercel (or similar) should create the build and give a working URL.
3. Get the feedback:
You can embed a simple form at the end, or reaction buttons after key steps. Every user who touches your prototype should leave data behind.
Run user sessions, and share the link. Watch people use it via screen share or async video. Note where they hesitate, what questions they ask, what they try to click that doesn't work. Just watch.
Synthesize with AI. Paste your notes into GPT or Claude: "Here are notes from five user tests. Identify patterns in what confused users, what worked, and any unexpected behaviors". You'll get a synthesis in minutes that would take an hour manually.
Decide: validated, invalidated, or inconclusive. If validated, you have evidence for prioritization. If invalidated, you've saved your team from building the wrong thing. If inconclusive, refine and test again.
What success looks like
You walk into a roadmap discussion and say: "I tested this with eight users last week. Six completed the flow in under two minutes, 40% faster than current onboarding. Here's the prototype, here's the feedback, here's my recommendation".
What failure looks like
Users hated it, good, you learned this in a week instead of a quarter. Synthesize why and test a different approach.
Nobody engaged with your prototype, your distribution was wrong, not your idea. Find better channels. You built something beautiful that didn't test your hypothesis, go back to step one. Write the hypothesis first next time.
CASE 3: The Full Feature | "Hand Engineering a Reference, Not a Doc"
You're leading a feature from discovery through delivery: real scope, real stake, engineering will spend days or weeks on it.
Traditional handoff: you write a spec, they skim it, they build what they understood. You review and say "that's not what I meant", timeline slips.
Different approach: after discovery, you build a working reference yourself, not a throwaway prototype, but something close enough to production that engineering can use it as a foundation.
They see exactly what you mean: behavior, edge cases, flow. They refactor if necessary and harden it rather than rebuild from scratch.
How this differs from Case 2
In Case 2, you're testing a hypothesis. Speed matters more than code quality, you mock behaviors, skip backends, and throw the prototype away once you've learned what you needed.
Case 3 is different: you're building something engineering will actually ship. Your reference needs to be clean enough that they can work with it. Real components, real data flows, patterns that match your codebase, and code that follows your team's standards.
This means slower, more deliberate work: planning before building, following your team's rules and conventions, creating PRs that could actually be reviewed.
Why this matters
Handoff ambiguity is product development's biggest hidden cost. An engineer reads "simple onboarding flow" and pictures something different than you did.
A working reference eliminates that ambiguity: they click through edge cases, they ask "should the error state look like this?" instead of "what should the error state look like?"
But the real unlock in Case 3 is that engineering doesn't start from zero. They inherit your structure, your component choices, your state management, they refactor and improve rather than interpret and guess.
Weeks of back-and-forth compress into days of refinement.
Expect to spend fifteen to thirty hours over two to three weeks. Reserve this for features where stakes justify the investment.
What you need
Genuine comfort with Cases 1 and 2 (multiple completed examples of each)
Ability to read and navigate a codebase (with the help of the AI)
Buy-in from engineering that they'll use your reference
Strong methodology discipline, this is where skipping steps gets expensive
What a reference implementation actually is
A working version of the feature that shows engineering exactly what you mean. How close it gets to production depends on the feature.
Frontend-heavy features: new flows, UI changes, components, your reference can be production-ready. Real components, real styling, real state. Engineering reviews, hardens edge cases, adds tests, and ships: your code becomes the foundation.
Features needing backend work: you build the frontend, mock the data layer, document what the API needs to return. Engineering wires it to real infrastructure.
Complex system changes: your reference covers the happy path with placeholder data. Engineering builds the system underneath.
The principle: get as close to production as your skills allow. If you can ship the frontend, ship it. If you need backend work, mock it and spec what you need. Give engineering something they can see and click through, not a document they have to interpret.
How to do it
Plan first. Before writing code, use Plan mode in Cursor or Claude Code to think through the approach. Describe what you're building, ask the AI to outline the components and data flows, review the plan before approving any code. This catches architectural mistakes before they compound.
Follow your team's rules. If your team has Cursor rules, Claude skills use them, if they don’t have yet, ask for them. Your reference should feel familiar to engineering, not like foreign code dropped into the repo.
Build incrementally. Don't try to build the entire feature in one session, work in small, logical chunks: authentication flow first, then the main interaction, then error handling. Commit after each chunk, this makes your work reviewable and your mistakes recoverable.
Ask AI to review your work. Before sharing with engineering, ask the AI to audit what you've built. "Review this code for gaps, edge cases I missed, error handling issues, and improvements" .AI catches things you'll miss, accessibility issues, loading states, error boundaries, inconsistent patterns. Fix what you can, note what you're leaving for engineering.
Create a real PR. Don't just share a branch link, open a proper pull request with a clear description: what you built, why, what's intentional, what's placeholder, what you need engineering to finish. Treat it like a handoff document that happens to include working code.
Request review before handoff. Ask your engineering partner to review the PR before you consider it done. Not a full code review, a directional check. "Does this architecture make sense? Am I using components correctly? What would you do differently?" Incorporate feedback, this surfaces issues while you can still fix them.
What can go wrong
You skip discovery and build the wrong thing fast. This is the most common failure, as it always happens with your engineering team. You spend two weeks building a functional reference for a feature nobody needs, the craftsmanship is impressive but the direction is wrong. You can now build quickly and decide poorly, so before you write a single line of code: talk to users, validate their needs and plan how you will validate the solution
Engineering feels undermined. If they perceive your reference as "doing their job" or questioning their competence, you create political problems that outlast the project. Frame correctly every time: "I built this to show what I mean — you'll refactor all of it to production standards. I'm trying to communicate more clearly, not replace your expertise".
Your reference is so messy it confuses more than it clarifies. You hack together something that technically works but is so convoluted that engineering can't tell what's intentional versus what's accidental. Focus on the happy path and key edge cases. Ask your AI Agent to write a .md file explaining what you did, what's incomplete.
You become the bottleneck. If you spend sixty hours on a reference while the team waits, you've slowed everyone down. Timebox aggressively, set a limit upfront, and if the reference isn't useful after that, ship the spec alone and learn for next time.
You can't let go. You built it, you're proud of it but when engineering suggests a different approach, you resist because it feels like criticism. Remember: the reference is a communication tool. Engineering will and should refactor everything, your job is to convey intent, not to ship your code.
What success looks like
Engineering ships in half the usual time. There are no "that's not what I meant" conversations because they could see what you meant. The spec and reference together eliminated the ambiguity that usually burns cycles. Reviews go faster, estimation is more accurate. Engineering wants to work this way again: you've changed how your team ships.
What failure looks like
You skipped discovery and built something impressive that nobody needed, painful, but instructive: do the discovery next time.
Engineering ignored your reference entirely: ask why. Maybe it wasn't useful, maybe it was too messy. This is feedback for your next attempt.
The project took longer because of your involvement, possible on your first try. Track whether it improves on attempts two and three. You burned out, you didn't timebox: set harder limits next time.
Collaborate with Engineering
You can learn Cursor and create a GitHub account on your own, or do one of our courses. But getting repo access, getting eng to trust you with their codebase, getting your manager to see this as valuable , that's a different challenge. Here's how to navigate it.
Build your case before asking for access. Don't start by asking eng for repo access out of nowhere. Start by showing you're serious, create a personal project first: build a side prototype with v0 or Lovable, push it to your own GitHub. Show your contributions graph, show you've done the basics.
Start with a specific, low-risk ask. Don't ask for "repo access”, ask for access to fix ONE specific thing.
Earn trust incrementally. Your first PR will probably need changes, that's fine. That IS the process. Don't try to impress, try to be useful. Fix small things, ask good questions in the PR review. Every PR you merge earns you more trust and more access
Find your internal ally. Find the person who's patient, curious, or who's already interested in PMs getting more technical. Ask them to be your code buddy. This relationship is the single most important thing for making this work inside a company.
The future is bright, if you get technical
The PM role is evolving in real time, building with AI is one part of a larger shift in how we work, and we're all still figuring out what that shift means. There's a new skillset forming around how to write prompts that actually get results, how to structure project docs so AI can work with them, how to think about markdown files as your new specs, how to set up workflows that let you move from idea to working prototype in hours instead of weeks.
Nobody has this fully figured out yet. The best practices are being written right now, by people who are experimenting and sharing what they learn.
So let's learn together. What are you struggling with? What do you wish someone would explain? What did you try that failed, and what did you try that worked?
The PMs who figure this out first won't just keep up with the shift. They'll define it. They'll set the pace for everyone else.
Get started, build something with your own hands!
—
Nicole Sigmaringo | @SigmaNik
Ariel Mathov | @arielmathov