Either You Die a Developer, or Live Long Enough to See Yourself Become a Product Manager

📌 Read here: For a slightly better reading experience Sarthology.com

I'm not implying that Product Managers are bad or that they are not good at their job. Although I have seen my engineer friends hating on Product Managers and Testers all the time 😄. Being a Product Manager with a technical background, I have seen both sides of the coin. Luckily enough, when I was a tech lead, my PM also had a technical background. Instead of tension, there was mutual respect and even inspiration.

If you ask me, I have a perspective on it. So if a Developer is a Pokémon, they might evolve into a Manager and later a Technical Lead and then a VP of Engineering—if they like being founders too. But this doesn’t mean all of us will, or even should.

Then here comes the AI and the irony…

If you think about it, vibe coding has not only shifted the tech landscape but also turned the tables, hasn’t it? Suddenly you might find yourself in the shoes of a tester 😅, and writing a good prompt feels exactly like writing a detailed user story.

Working Feature = Well-Defined Spec x Rigorous Testing

You are now wearing three hats: Product Manager + Tester + Developer. 🤯

---

🌓 The Changing Tech Landscape

I don't want to be Baba Vanga or something, but the tech job exodus is on the horizon now. When my old mentees ask me for advice, I tell them that they're great developers, but it's time for the Pokémon to evolve. I tell them to develop product sense. But the question is—can everyone adapt to it?

If I have to categorize developers, I would put them into three broad categories:

1. Product-Minded 🧙🏻:

Signature traits: You naturally think like a user. You write stories before code. You notice friction, propose better flows, and often pre‑empt bugs with thoughtful tests.

For example: You may have seen the OG OSS developers—yes, I'm talking about them. They relate to a problem at a user level. Most OSS developers (from my experience) are trying to solve a problem for themselves. So planning comes easy; defining user stories is easy. A few of them have good design sense, and they end up creating loved and viral products. Not just solving problems, but solving problems with style. They are like Michelin‑star restaurant owners, baking a good experience along the way.

🤔 What it looks like at work: You push a story from “works” to “feels right.” Testers rarely find surprises.

✨ Why this thrives now: AI supercharges people who give it crystal‑clear specs.

🚀 Trajectory: PM/Tech Lead comes naturally—you’ve been doing the job without the title.

2. Problem Solvers 🥷🏻:

Signature traits: You love hard problems, patterns, and clean solutions. LeetCode is your playground. UI polish isn’t always your first instinct, but you can flex when needed.

🤔 What it looks like at work: You crush tricky tasks, sometimes under‑invest in UX.

💊 Hard pill: If you don’t evolve into clear spec + user lens, you’ll be arm‑wrestling AI that’s getting better at pure problem‑cracking.

🚀 Trajectory: With a bit more user empathy and end‑to‑end testing, you’ll drift into Category 1.

3. Job Holders 👻:

Signature traits: You ship volume but miss acceptance criteria, hand off bugs to QA, and treat stories as tickets rather than user outcomes.

Sadly, these developers are more in number, thriving in big corporate environments. They don’t care to read user stories and often miss the acceptance criteria. These are basically junior developers with fancy job titles, which they got just because of their time in the industry. They have no motivation to evolve and are sadly milking big cash because they have been like this for 5+ years. God knows why companies value numbers over quality. They are valuable because there is an ecosystem that supports them: bad coder → more testers → longer product timeline → more money to milk from the client. So everyone wins except the client of these companies (sorry for my rant there 😅 and also I acknowledge some time bad leadership also lead to this practice).

🤔 What it looks like at work: Projects stall, cycles stretch, and quality debt grows.

🤷🏻 Reality check: This model won’t survive long.

🚀 Trajectory: Start with specs, acceptance criteria, and your own test checklist— or themarket will do the sorting for you.

If you never stop learning, you’ve already tilted the odds in your favor.

Evolving is part of human existence, but today it has become more than that—it’s about survival.

So where to start your journey....

All of this assumes you can read and write code with semantic clarity. Fundamentals stay non-negotiable; product thinking is an extra layer, not a substitute.

---

📜 Spec‑Driven AI Tools (Why ‘Vibe Coding’ Works)

Vibe coding: using AI with rich context and clear specs so models produce predictable, testable output.

AI performance rises or falls with how clearly you define the problem. And that’s not just for coding—check my article on context engineering (for prompting win with AI).

But this mindset might not come easy for everyone, and that’s why vibe coding tools are themselves shifting your attention there.
A few notable ones include:

• Kiro (by Amazon): focuses on specs‑first development, pushing you to think about requirements clearly before writing code. AI can draft specs for you, but you still need to review them to avoid hallucinations.
• Agents.md: helps structure prompts and tasks in a systematic way.
• Spec Kit (by GitHub): an open‑source toolkit for spec‑driven development. Read more about it here.

Pick one tool and run a 1‑sprint pilot. Start with a 5‑minute spec template, then compare bug counts and review cycles before/after.

✨Tips

Product‑Minded → formalize with Spec Kit;
Problem Solver → narrate user acceptance with Agents.md;
Job Holder → enforce acceptance criteria with Kiro before coding.

---

🧠 Developing a Product Mindset

Some may say a product mindset is an inbuilt feature for most people, but I disagree. With hard work, everything can be learned and mastered.

The first step is simple: OBSERVE. Every day we interact with countless apps and products as users. Your learning can start there. These apps are filled with hidden gems. Ask: Why do you love a product over its competitors? What feature do you love and why? What design choices are ingenious? That’s where you develop a sense of what might work and what doesn’t.

Observe → Frame → Test → Ship → Measure

1️⃣ Observe: Screenshot two moments you loved or hated in apps you used today and write one sentence on why.

2️⃣ Frame: Turn each into a problem statement and a desired outcome.

3️⃣ Test: Draft acceptance criteria (Given/When/Then) so “done” is unambiguous.

4️⃣ Ship: Build the smallest coherent change that proves the idea.

5️⃣ Measure: Pick one HEART metric (Happiness, Engagement, Adoption, Retention, Task success) and watch it for two weeks.

Lastly, build an OSS of your own—a problem personal to you and a hinge that others want a tool or app for. Launch it on Product Hunt and ask users for feedback. In no time, you will develop the product mindset—and who knows, you might build a business around it too.

Principles to steal: Start with the problem. Think big, start small, learn fast. Ship often.

---

📌 The Product‑Minded Dev Playbook (6 Steps) 📚

Here is a small playbook to develop with a product mindset 👉

1. User story: Who is the user? What pain? What job‑to‑be‑done?
2. Acceptance criteria: Given/When/Then, including edge cases.
3. Tests first: Red → Green → Refactor. (Even one tiny test!)
4. Generate: Ask AI for the smallest implementation to satisfy the tests.
5. Review: Read the diff like a PM—does this match the intent?
6. Ship & measure: Add analytics or a measurable proxy for value.

---

📌 Two Pocket Checklists 📋

Checklist to keep in mind, if you want create prefect spec for AI:

👉 Spec checklist

• User → Problem → Outcome in one sentence.
• 3–5 acceptance criteria with edge cases.
• Non‑goals (what this won’t do).
• Observability (how we’ll know it works).
• Rollback plan (what if it fails?).

Checklist if you are working on a small feature and prefer vibe coding:

👉 Prompt checklist

• State role and constraints (language, style, deps).
• Provide examples (tests, input/output).
• Ask for a diff or single file, not essays.
• Request assumptions and uncertainties explicitly.
• Cap scope (“only implement X to make tests pass”).

---

📌 Product‑Minded Shifts (Mindset Upgrades) 🧠

• From output to outcomes: “I closed 5 tickets” → “I reduced signup drop‑off by 12%.”
• From features to jobs: Tie every PR to a user job‑to‑be‑done.
• From perfect to iterative: Ship a walking skeleton, then layer quality.
• From solo to orchestration: Treat AI/agents as teammates.
• From intuition to measurement: Add a metric to every spec.

---

✨ An Optimistic Future

The safest path is evolution: widening your impact beyond code so your career compounds.

🤞 Here’s why I’m optimistic:
Developers have a tactical advantage in this age of AI. If they understand the product, test it, guide the AI to fix an issue in code—or fix it themselves—they can be a solo force‑multiplier. They will ship better products, faster, and create more jobs in the market. SaaS will be built and iterated like fast fashion—short cycles, rapid feedback, constant remix.

Open source and local‑first are accelerating; smaller teams can ship meaningful fixes faster. Pick one OSS you use, close a small bug this month, and document before/after in a 5‑line changelog.

Evolve your lane: formalize specs (Product‑Minded), narrate acceptance (Problem Solver), or enforce criteria (Job Holder)—then ship.

---

💪 30‑Day Challenge: Become a Product‑Minded Dev (While Still Coding)

• Week 1 – Pick one user pain; write a crisp spec; ship a walking skeleton.
• Week 2 – Add tests, observability, and one measurable outcome.
• Week 3 – Run a mini user check (1–3 users/stakeholders); revise spec; ship v2.
• Week 4 – Write a short retro: what moved the needle? What didn’t? Publish it.

May the force be with you.

---

Last remark

I’d love to hear your story—did you drift toward product, stay deep in code, or carve a hybrid path? What skill actually moved the needle for you? Drop a comment 👇

P.S. If you want an advice shoot me dm anytime @sarthology, or I do a few 1:1 sessions each month,Check out that here

See you next time. Until then.

Evolve, don’t wait. ⚡️

Comments

[Emma]

So maybe the real question is no longer whether you’ll live long enough to become a Product Manager, but whether you’ll evolve enough to make AI your ally instead of your replacement. And for that reason, you need to think like a Product-Minded developer, right? 🙄

[Sarthak Sharma]

Absolutely correct. The title was just a fun way to put it.

[Utkarsh Talwar]

Golden advice as always, mate. Really liked how you dismantle the developer → PM narrative and force us to re-think what “growth” even means in tech. The “product-minded dev” playbook is great. It forces us to change our mindset and act in more outcome-oriented ways.

These days, it seems AI is writing more than 90% of code (according to some surveys), and yet the chasm between a great and mediocre dev only seems to be widening. It's all about the mindset! (Now, if only Jira tickets could close themselves with the help of AI, that would be true ascension 😛)

[Sarthak Sharma]

Rightly said.

Btw regarding Jira. You will be surprised to know that you can do it with MCPs. 🤣

[Willie Harris]

A brilliant and humorous take on the evolving role of developers in today's tech landscape. The article cleverly highlights how developers, especially those with a technical background, often find themselves stepping into roles like Product Manager, Tester, or even Technical Lead. It's a reminder that adaptability and a product mindset are becoming essential in our careers. The evolution analogy is spot-on—developers are indeed evolving, and embracing this change can lead to exciting new opportunities.

[Sarthak Sharma]

Thanks 🙏

[J3ronimo]

AI commenting on AI written articles about AI. xD The internet is so dead.

[Shubham Arora]

I consider it one of the best advice. I remember you always emphasized to every student of yours to focus on building product understanding first, then development..

Thanks for sharing another wisdom...

[Sarthak Sharma]

Thanks Shubham 😊

[Akshat Austin]

The title perfectly captures what I've observed in my more then 5 years in tech. What's interesting is that the developers who thrive as PMs are often those who were already naturally asking 'why are we building this?' rather than just 'how should we build this?

[Sarthak Sharma]

Yes, But again I believe this can be learned as well.

[Ali Farhat]

Amazing!! 🙌

[Sarthak Sharma]

Thanks Mate ✨

[daniel carvajal]

amazing!!!

[Vanshika]

Loved the Pokémon -> PM metaphor — made me rethink my own trajectory. Thanks for writing this!

[Sarthak Sharma]

Pleasure is mine 😊

[Aaron Rose]

awesome article! thanks 💯❤

[Not Operations]

Good!