· Valenx Press · 11 min read
First 90 Days as a PM: Action Plan with Cursor Windsurf AI Coding Tools
First 90 Days as a PM: Action Plan with Cursor Windsurf AI Coding Tools
TL;DR
Your first 90 days as a PM are not about proving you can build features fast with AI tools — they are about establishing judgment credibility with engineers who distrust AI-generated code and managers who need predictable delivery. The product managers who survive month three are those who use Cursor and Windsurf to accelerate their own technical fluency, not to bypass engineering ownership. Most new PMs overestimate how much coding speed matters and underestimate how much trust erosion happens when they ship AI-generated PRDs without engineering partnership.
Who This Is For
You are a new product manager joining a Series B to public tech company where engineers already use Cursor, Windsurf, or similar AI coding assistants — or where leadership expects you to demonstrate technical fluency that previous PMs lacked.
You have 2-10 years of experience, possibly an engineering background you are rusty on, and you are negotiating the gap between “I can prototype” and “I can ship with a team.” You are not reading this to learn to code. You are reading this because you watched a demo where someone built a full app in 20 minutes and you need to know whether that helps or harms your credibility in your first staff meeting.
What Should a New PM Actually Build in the First 30 Days?
The first counter-intuitive truth is that your output volume in month one signals anxiety, not competence.
In a Q2 debrief I sat on, a hiring manager from a fintech company described their new PM’s first month: three Figma prototypes, two Cursor-generated demo apps, and a Notion dashboard tracking “technical debt metrics.” The engineering lead’s feedback in the 30-day review was blunt: “Impressive energy. Still don’t trust their judgment on what to build.” The PM was managed out by day 75.
The problem is not your ability to generate working code. The problem is your judgment signal.
Engineers do not need PMs who can replace junior developers. They need PMs who understand what is technically possible enough to have constraint-aware conversations. Cursor and Windsurf become dangerous when they create the illusion that you understand tradeoffs you have never executed.
I watched a PM in a debrief explain that a feature would take “two days because I built it in Windsurf over the weekend.” The engineering manager’s face tightened. The actual implementation required database migrations, API contract changes, and security review. The PM’s estimate destroyed credibility for the next two quarters.
What you build in the first 30 days: one deeply understood technical system, not multiple surface-level demos.
Pick the core user flow your team owns. Use Cursor to trace through the actual codebase — not to generate new code, but to read, annotate, and question. I tell new PMs to spend 10-15 hours in their first two weeks using AI coding tools purely as an accelerated reading comprehension device.
Ask Cursor to explain a specific function. Then ask it to explain what would break if you changed that function. Then ask what the second-order effects would be on downstream services. This is the technical fluency that earns respect: not “I can build this,” but “I understand why this breaks when we change that.”
The script for your first engineering one-on-one: “I spent this week in the auth service codebase. I used Cursor to trace the token refresh flow. I want to confirm my understanding — when we hit the rate limit here, the fallback logic seems to depend on this Redis cache. Is that right?” This lands differently than “I built a prototype of our auth flow.”
📖 Related: Google L4 Data Scientist SQL On-Call Template for Interview Prep
How Do Cursor and Windsurf Change the PM-Engineer Relationship?
They do not replace the relationship. They expose its fault lines faster.
The second counter-intuitive truth: AI coding tools accelerate trust formation when used invisibly, and destroy it when performed.
In a hiring committee debate last year, a director argued against promoting a senior PM to staff because “they demo too much.” The pattern was consistent: every product review included a live Cursor session where the PM would “quickly show” a working implementation. Engineers stopped attending. The VP of Product eventually intervened. The PM’s intent — demonstrating technical credibility — produced the opposite effect by making the engineering team feel surveilled and substituted.
The effective use pattern is asymmetric: you use Cursor and Windsurf to prepare, not to perform.
Before a roadmap discussion, spend 30 minutes with Windsurf exploring the feasibility of a proposed approach. Do not bring the generated code. Bring the constraints you discovered. “I explored two implementation patterns for the real-time collaboration feature. Pattern A adds 200ms latency on the sync path but avoids schema migration. Pattern B requires the migration but enables offline-first. My instinct is A to preserve velocity this quarter. What am I missing?”
This framing does something critical: it positions your technical exploration as input to engineering judgment, not replacement of it. The engineer can correct your understanding, refine the tradeoff, or reveal a constraint you missed. Either way, the conversation advances. The alternative — “I built this in Cursor, we should ship it” — collapses the space for engineering ownership.
The organizational psychology principle here is status negotiation. New PMs enter with unearned status from their title and assumed authority. Engineers guard their technical territory carefully. When you use AI tools to generate code in shared spaces, you trigger territorial response even with collaborative intent. When you use the same tools privately to elevate your understanding, you signal respect for their expertise while still contributing technical depth.
What Should Your 60-Day and 90-Day Milestones Look Like?
The third counter-intuitive truth: your 90-day review is decided by day 45, and day 45 is decided by who you chose to disappoint.
In a debrief for a healthtech company, the hiring manager described two PMs who started the same month. PM A optimized for visible output: shipped three small features, generated dashboards, presented at all-hands. PM B spent two weeks in apparent inactivity, then surfaced a technical constraint that saved six weeks of misdirected engineering effort. PM B received the stronger 90-day review. PM A was “fine, still watching.”
The 60-day milestone is not a deliverable. It is a relationship state.
By day 60, you should have one engineer who will correct you privately before correcting you publicly. One designer who trusts you to represent user constraints in technical discussions. One engineering manager who asks your input before finalizing sprint scope. These relationships do not form from shared tool usage. They form from demonstrated judgment in moments where you could have accelerated and chose to understand instead.
The specific milestone: lead one technical decision review where you argue against a feature you personally want, based on technical constraints you discovered through codebase exploration.
I coached a PM through this at a Series C company. They had strong user evidence for a feature their team was excited to build.
Two weeks of Cursor-assisted codebase exploration revealed that the user identity model would require touching seven different services, including one owned by a team with a six-week backlog. The PM presented this in roadmap review with a specific quote from the codebase and a proposed alternative that achieved 70 percent of user value with zero cross-service dependency. The engineering manager later told the VP: “First PM who ever came to us with a no that made sense.”
The 90-day milestone: own one area of technical context that no one else in the product org has developed.
This could be the analytics pipeline, the deployment process, the mobile release cycle. Use Cursor and Windsurf to build depth, not breadth. The PM who can explain why the last mobile release was delayed and what specifically changed in the build pipeline becomes indispensable in ways that the PM with thirty shallow prototypes never will.
📖 Related: amazon-pm-rejection-what-next
How Do You Avoid Being Seen as “The AI PM”?
You become “the AI PM” when your tools become your identity. The solution is deliberate tool invisibility.
In a quarterly review last year, a senior PM was described as “competent, but everything is Cursor this, AI that.” The characterization was unfair — their actual product judgment was strong — but the pattern of tool-centric self-presentation created a caricature that outran their substance. They were passed over for the principal promotion in favor of a PM with weaker output but more neutral presentation.
The practical boundary: never name your tools in product reviews, never demo generated code to non-engineers, and never use “I built this in [tool]” as a credibility claim.
The deeper boundary: cultivate one explicitly analog or slow practice that signals deliberation.
One PM I work with hand-draws user journey maps before digitizing them. Another writes decision memos in long-form prose before any presentation, forcing clarity that AI-assisted drafting sometimes obscures. A third maintains a physical notebook of technical debt observations that they review weekly with their tech lead. These practices are not performative Ludditism. They are counterweights that prevent tool dependency from flattening your thinking into whatever generates fastest.
Preparation Checklist
- Spend your first two weeks using Cursor exclusively for codebase comprehension, not code generation; trace one complete user flow through frontend, API, and data layers
- Schedule technical exploration time before every roadmap discussion; use Windsurf to validate feasibility, then discard the generated code and bring only the constraints discovered
- Identify one engineer, one designer, and one engineering manager to develop explicit trust relationships with by day 45; use your technical fluency to make their work easier, not to demonstrate replacement capability
- Build one technical context area to depth by day 90 that no other PM owns; document your understanding for the next PM who joins
- Establish one deliberately slow, non-AI practice that signals judgment over velocity; protect this practice against the pressure to optimize everything
- Work through a structured preparation system (the PM Interview Playbook covers first-90-day technical credibility building with real debrief examples from FAANG hiring committees, including specific scripts for engineering partnership conversations)
Mistakes to Avoid
BAD: “I built a working prototype of the feature in Cursor over the weekend. We could ship this by Friday.”
GOOD: “I explored two implementation approaches in Cursor to understand the tradeoffs. The auth service dependency adds risk I want to validate with you before we commit.”
BAD: Demoing generated code in product review to prove technical feasibility.
GOOD: Summarizing the constraint analysis from your exploration, with specific codebase references, and asking engineering to validate your understanding.
BAD: Using AI coding tool output as the basis for engineering time estimates.
GOOD: Using your exploration to ask better questions about unknown unknowns, then letting engineering own the estimation process with your informed input.
FAQ
Should I tell my engineering team I use Cursor or Windsurf?
Disclose if asked directly; otherwise, operate invisibly. The test is whether your tool usage every appears in retrospectives or feedback. If it does, you have made it part of your identity rather than your infrastructure. One engineer described their PM as “surprisingly technical” for six months before learning about the AI-assisted exploration — the compliment landed harder because the tools were not part of the narrative.
How much actual coding should I do in my first 90 days?
Enough to understand, not enough to ship. The boundary is code review: if your changes require engineering review, you have crossed into territory that creates accountability confusion. One PM at a late-stage startup maintained a personal branch for six months, using Cursor to explore implementation approaches that they discussed with engineers but never merged. This built technical credibility without ever threatening engineering ownership.
What if my manager expects me to “move fast” and use AI tools aggressively?
Negotiate the definition of fast. In a hiring committee I sat on, a director’s expectation of “AI-native PMing” collapsed when their aggressive PM shipped three features with critical security gaps. Fast in month one, fired in month four. The counter-offer: “I’ll use these tools to de-risk our biggest technical bets faster, which means fewer surprises in sprint planning and more accurate roadmap commitments.” This reframes speed as predictability, which engineering managers and executives both value more than raw velocity.amazon.com/dp/B0GWWJQ2S3).