Become a PM and you'll never look at the developer job the same way


Goal

At some point in my career, I decided to step into the role of a Product Manager (PM) for a small team while still leveraging my background as a senior frontend developer. What I wanted to figure out was how transitioning from a developer to a PM would reshape my understanding of software development and team dynamics. I also wanted to explore how I could give back to others by sharing these insights and fostering better collaboration within teams.

Approach

I ran a tight SCRUM process and chose React + TypeScript with MUI to prioritize type-safe, fast UI development. We emphasized collaborative work via Git and GitHub and used GitHub Projects for project management.

  • SCRUM: one-week sprints, daily standups (short meetings at the same hour Monday-Friday), focused sprint goals, short retros:
    • Monday: sprint planning,
    • Tuesday: just standup,
    • Wednesday: sprint review,
    • Thursday: backlog refinement,
    • Friday: retrospective.
  • Tech: React + TS + MUI, Vite; GitHub Actions.
  • Delivery: small vertical stories, rapid prototypes; branch-based collaboration and pair work via Git/GitHub.

This kept scope disciplined, accelerated feedback loops, and made collaboration explicit.

Results

After ~6 months of after-hours work we delivered a functional MVP of a decision-making web app that helps users evaluate options based on multiple criteria. The result can be seen live at trc.simplemented.com.

More about this project you can read here.

Takeaways

Switching from a senior frontend developer to PM while leading a small group of React adepts on a decision-making web app changed my perspective completely. As a developer, I was used to thinking in terms of code quality, clever abstractions, and delivering features myself. As a PM, I learned the real challenge is not technical — it’s about people, scope, and alignment. I also saw how easy it is for developers (myself included) to overengineer when the app only needs to stay simple.

Key learnings from this shift:

  • clear communication matters more than perfect code;
  • scope discipline is harder than writing components;
  • empowering others delivers more value than doing it all yourself;
  • a “simple” app still requires deliberate structure and planning;
  • the role change forced me to zoom out from code to collaboration: it reshaped the way I think about building software.