That's a bold confession to open with, but here goes: I'm an engineer cosplaying as a product manager. Twenty years of building platforms for global brands, shipping SDKs, architecting developer tools, and now I'm running multiple product lines, making roadmap decisions, writing PRDs, and having the kind of stakeholder conversations that would make my younger self break out in hives.
And somehow, it's working.
How I ended up here
Through a series of organic moves at Contentstack, I ended up owning product for three areas:
- Marketplace & Developer Hub: a platform for end users to create apps and extend the Contentstack platform, both internally on the platform and externally via API
- Developer Experience tooling: all SDKs, the CLI, starter kits, and the overall DX surface area
- MCP Hub: a full MCP product that lets users create MCP profiles and agent skills to work with the Contentstack platform based on their RBAC permissions
None of this was planned. I didn't campaign for a PM title. These products needed someone who understood the technical landscape and could talk to stakeholders, and I was standing in the right spot at the right time. Now I'm figuring it out as I go, one prototype at a time.
Build first, spec later
Traditional product management follows a well-trodden path: research, write the PRD, get stakeholder alignment, hand it to engineering, iterate on feedback, ship. It's structured. It's proven. And for someone who thinks in code, it feels like writing a recipe without ever tasting the food.
My approach is different. Some might say backwards.
For the MCP Hub, I didn't start with a PRD. I started by building. Multiple production-ready prototypes, each with different architectural approaches and feature sets. After each prototype, I wrote a new PRD, reshaped the ideas, built a new version, and went through the whole cycle again. Not once. Not twice. Multiple times.
Why? Because I can't evaluate whether something works by describing it in a document. I need to feel it. I need to use it. I need to watch it break and understand why it breaks.
I call this spec-based vibe engineering. Every prototype is architecturally intentional. Every iteration has a thesis. The building is the discovery. And the PRD? That comes after, as documentation of what was learned, shaped by what actually worked in practice.
Where AI changes everything
I think the traditional PM playbook starts looking outdated.
Once I've built a prototype that feels right, the AI writes the PRD based on my code. Read that again. The documentation is generated from the implementation. Because the engineering is solid and intentional, the PRDs and technical documentation practically write themselves. We're in a phase now where AI covers all edge cases and refines the specs based on working software if you prompt it right.
I also produce code with AI, in a structured, spec-driven way. The AI helps me process bug reports, synthesize customer feedback, and organize feature requests. All of it feeds back into the product thinking.
AI bridges the gap between my engineering brain and the PM responsibilities I've inherited. Working code becomes business documents. Customer noise becomes signal. Architectural decisions become roadmap items that leadership actually understands.
You still need the product instinct. AI just lets you spend more time building and less time formatting slide decks.
The T-shaped product leader
There's this concept of being T-shaped: deep expertise in one area with broad competency across others. I'm T-shaped with a long, deep root in engineering and branches into leadership, developer relations, and now product management.
The PM role as traditionally defined assumes a certain kind of generalist. Someone who can talk to engineering, talk to customers, talk to leadership, and synthesize all of that into a coherent product direction. That's genuinely hard. It requires product instinct, organizational structure, customer empathy, and management skills, all at a high level simultaneously.
But what if the starting point shifts?
What if instead of a generalist who learns enough engineering to be dangerous, you have an engineer who learns enough product management to be effective? And what if AI fills in the gaps that used to require a dedicated specialist?
The combination of deep technical ability, AI-augmented workflows, and hard-won soft skills might just produce a different kind of product leader. Maybe a better one?
It's not all sunshine and rainbows
Let's be honest about where the cosplay analogy shows its seams.
Product management goes well beyond knowing what to build. Stakeholder management, roadmap politics, saying no to features that important people really want, managing up when the priorities shift under your feet. These skills live outside the codebase entirely.
For me, they come from many years of convincing boardrooms full of C-suites that developer teams are actually worth investing in. That background in developer relations and technical leadership gave me a toolkit for the political side of product work that I'd never have learned from engineering alone.
I can't pretend this part is easy. It isn't. But the leadership muscles I built throughout my career (presenting to executives, defending technical investments, translating engineering value into business language) transfer surprisingly well to PM responsibilities. The cosplay costume fits better than I expected because I'd been rehearsing for the role without knowing it.
If you're an engineer thinking about this path, know that the soft skills matter as much as the technical ones. Maybe more.
The future PM produces
My bold claim: the future of product management is closer to producing and architecting than it is to traditional spec writing.
The PM who can:
- Build functional prototypes to validate ideas before committing team resources
- Use AI to generate documentation from working implementations
- Synthesize customer feedback with AI-assisted analysis at scale
- Architect solutions that account for technical constraints because they understand them natively
- Communicate at every level, from code review to board presentation
...that PM has an unfair advantage. And they might not even call themselves a PM.
I think I accidentally fell into the right direction. The industry is moving toward a world where the line between "building" and "managing" blurs. Where AI handles the translation between technical artifacts and business artifacts. Where the most valuable product leaders are the ones who can produce.
The counter-argument
I can hear the traditional PMs reading this and thinking: "You're just describing a tech lead with extra steps."
Fair point. And there are products where deep customer research, market analysis, and pure strategic thinking matter more than the ability to ship a prototype over a weekend. Consumer products with millions of users need PMs who think in behavioral psychology, not system architecture.
But for technical products? Developer tools? Platforms and APIs? The build-first, spec-later approach might actually be the stronger play. In these domains, the product is the architecture. The developer experience is the product decision. You can't spec your way to a great SDK. You have to build it, use it, feel where it's wrong, and iterate until it feels right.
Simply put: the product sense comes from the producing.
Concluding: cosplay might be the new meta
I started calling myself a "cosplaying PM" as self-deprecating humor. Something to acknowledge that I don't fit the traditional mold. But the more I lean into this approach (build, iterate, generate specs from code, refine with AI, repeat) the more I think this isn't cosplay at all. It's what the role is becoming.
The future PM produces, architects, iterates, and uses AI to bridge the gap between building and planning.
If you're an engineer who keeps drifting into product conversations, who can't stop building prototypes nobody asked for, who instinctively knows what's wrong with a product because you've felt it in the code... you might not be cosplaying.
You might just be early.
Frequently asked questions
Can an engineer effectively take on a product management role?
Yes, especially for technical products like developer tools, SDKs, and platforms. An engineer with deep domain expertise, AI-augmented workflows, and strong soft skills can bring a build-first perspective that validates ideas faster than traditional spec-first approaches. The key is combining technical depth with leadership and communication skills built over years of cross-functional work.
What is spec-based vibe engineering?
Spec-based vibe engineering is a structured approach where you build intentional, architecturally sound prototypes to validate product ideas, then generate documentation and PRDs from the working code. It's distinct from vibe coding because every prototype has a clear thesis and architectural intent. The building itself is the discovery process.
How does AI change the product management workflow?
AI acts as a translation layer between engineering artifacts and business documents. It can generate PRDs from working code, synthesize customer feedback, organize feature requests, and produce technical documentation. This allows technically-minded product leaders to focus on building and iterating while AI handles the communication and documentation overhead.
Is the build-first approach suitable for all types of products?
Not necessarily. Consumer products with millions of users may still benefit from PMs who think in behavioral psychology and market research. But for technical products (developer tools, platforms, APIs, and SDKs) the build-first approach is often superior because the product is the architecture, and you can't spec your way to a great developer experience.
