You Didn't Sign Up for This
You're an engineer. You write code. You solve technical problems. And somewhere along the way — maybe when the startup hit 12 people, maybe when the PM quit, maybe because the founder said "you've got good product sense, just handle it" — you became the PM.
Not officially. Nobody updated your title. But you're the one deciding what gets built next. You're the one writing specs (or not writing them, and regretting it). You're the one triaging customer feedback, prioritizing the backlog, and explaining to stakeholders why the timeline slipped.
You didn't get training for this. You don't have a methodology. You have a Linear board, a gut feeling, and a growing sense that you're spending more time managing product than building it.
This is the reality for most engineers at startups between 15 and 80 people. There's no PM. There's no budget for one. And the product decisions still need to get made.
The Role Nobody Prepared You For
Drew Breunig calls this the "Application PM" — a hybrid engineer-PM building fast alongside customers. It's the role that emerges as AI coding tools accelerate engineering and the PM-to-engineer ratio inverts. Andrew Ng reported teams considering 2 PMs per 1 engineer. At your startup, the ratio is more like 0.2 PMs per 5 engineers.
The good news: engineers often make excellent product decisions. You understand technical constraints. You know what's actually hard versus what sounds hard. You can estimate effort from experience, not from a formula. You talk to customers and understand their problems in concrete terms.
The bad news: the overhead of product management is real, and it compounds. Without a system, you'll spend your Mondays in planning purgatory, your Wednesdays chasing context across five tools, and your Fridays wondering where the week went.
The Minimum Viable Product Process
You don't need Scrum. You don't need SAFe. You don't need a certification. You need a process that takes less than 3 hours per week and keeps things from falling apart.
Here's the minimum viable process for an engineer running product.
1. One source of customer signal
Pick one place where feedback lives. One. Not "Slack plus Intercom plus the founder's notes plus that Google Sheet from the sales call." One place.
Export everything there. Paste customer quotes. Dump support tickets. Copy Slack messages. The medium doesn't matter — what matters is that when you sit down to decide what to build next, all the signal is in one place.
Most teams at this stage don't need a feedback tool. They need a discipline: everything goes in the doc, the spreadsheet, or the database. The format can be ugly. The coverage needs to be complete.
2. A weekly 30-minute review
Every week, spend 30 minutes reading the accumulated feedback. Look for patterns. Three customers asking for the same thing is a signal. One customer asking for something complex is a data point, not a mandate.
Cluster the feedback by theme. Not with a fancy tool — with your brain. Group the "it's slow" complaints. Group the "I can't find X" complaints. Group the "I wish it could Y" requests. Count the clusters. Rank them by frequency and severity.
This is the product work. Not the spec writing, not the board management, not the stakeholder update. This — reading what customers actually say and finding the patterns — is the part that determines whether you build the right thing.
3. A spec before you build
You're an engineer. You know what happens when you start coding without a plan. The same thing happens at the product level, just slower and more expensive.
Before any feature bigger than a bug fix, write a spec. Not a 10-page PRD. A spec. Here's the minimum:
That's it. Problem, solution, acceptance criteria. If you can write this in 20 minutes, you're doing it right. If it takes 2 hours, you're either over-engineering the spec or the feature isn't well understood yet — and that's valuable information.
If you need a more detailed framework, there's a guide specifically for engineers writing PRDs that covers edge cases, technical context, and success criteria.
4. A board that doesn't require maintenance
Your kanban board should reflect reality without you touching it. If you're spending time dragging cards between columns, your board is a maintenance burden, not a visibility tool.
The ideal: your board updates from GitHub activity. Branch created means work started. PR opened means in review. PR merged means shipped. You never touch the board. You glance at it once a day to see what needs your attention.
If your current tool doesn't do this, simplify. Three columns: To Do, In Progress, Done. Move cards when you notice. Don't build an elaborate workflow that requires daily grooming — you don't have time for it and it won't get done.
5. A decision log (not a meeting)
Every product decision should be written down somewhere. Not in Slack — Slack is where decisions go to die. In a persistent place. A section in the spec. A running doc. A comment thread on the relevant ticket.
The log doesn't need to be formal. "2026-04-01: Decided to scope out push notifications for v1. Reason: requires third-party service, adds a week, not critical for launch." That's it. Future-you will thank present-you when someone asks "why doesn't this support push?"
The Tools That Respect Your Time
Most PM tools are built for PMs. They assume a user who spends 8 hours a day in the tool, who enjoys configuring views and filters, who measures productivity in dashboard completeness.
That's not you. You need a tool you open for 10 minutes, make a decision, and close. Here's what to look for:
Fast input. If it takes more than 5 clicks to create a spec or add a ticket, it's too slow. You'll stop using it within a week.
GitHub integration. Your code lives in GitHub. Your board should know what's happening there without you telling it. Auto-status from branches and PRs isn't a luxury — it's the difference between a tool you maintain and a tool that maintains itself.
AI that knows your codebase. When you write a spec, the tool should know what code exists. It should suggest relevant files, identify complexity, and flag things you haven't considered. Not generic AI — contextual AI.
No configuration tax. No custom fields to define. No workflow rules to configure. No permissions matrix to set up. The tool should work out of the box for a team of 3-15 people. If it requires an admin, it's too complex.
The Anti-Patterns
After talking to dozens of engineers in the PM role, the same anti-patterns emerge:
Over-speccing. You write a 15-page PRD because you think that's what PMs do. Nobody reads it. You spent a day writing a document that should have been a paragraph. Match the depth of the spec to the complexity of the feature.
Under-speccing. You skip the spec entirely and start coding. Three days in, you realize you didn't account for permissions, error states, or the edge case where the user has no data. You rewrite half the feature. The spec would have taken 20 minutes.
Process cosplay. You implement sprint ceremonies, story points, velocity tracking, and retrospectives for a team of four. You spend more time managing the process than doing the work. Process is a scaling tool. At 4 people, you need a list and a weekly conversation.
Tool hoarding. You sign up for Notion, Linear, ChatPRD, Productboard, and Miro because each one does something useful. Now you spend 30% of your product time keeping five tools in sync. The cost of tool fragmentation is real and it compounds.
You Don't Need PM Training. You Need PM Tooling.
Ethan Mollick identified the defining skill of the AI age: "delegation documentation" — the ability to write clear specs that serve as effective AI prompts. Every spec is really the same thing: an attempt to get what's in one person's head into someone else's actions. Whether that someone is an engineer, an AI agent, or your future self.
Engineers are good at this. You write documentation every day — in code comments, in README files, in pull request descriptions. You know how to be precise. You know how to define acceptance criteria. You know the difference between "it should work" and "GET /api/users returns 200 with a paginated list of user objects."
What you're missing isn't the skill. It's the tooling that makes the skill efficient. A tool that reads your repo so you don't explain your architecture from scratch. A tool that generates a board from your spec so you don't copy-paste into tickets. A tool that watches your PRs so you don't manually update status.
You didn't sign up to be a PM. But if the tooling is right, you don't have to be one. You just have to make good product decisions — and you're already doing that.