--- title: "I'm cosplaying as a Product Manager, and I think I'm onto something" description: "After twenty years of engineering, I accidentally ended up running multiple product lines. My approach (build first, spec later, let AI handle the translation) isn't traditional PM work. But it might be where the role is heading. Here's why engineers who produce before they plan might have an unfair advantage in the age of AI." date: "2026-02-14T10:00:00.000Z" url: "https://timbenniks.dev/writing/cosplaying-as-a-product-manager-and-i-think-im-onto-something" canonical_url: "https://timbenniks.dev/writing/cosplaying-as-a-product-manager-and-i-think-im-onto-something" image: "https://res.cloudinary.com/dwfcofnrd/image/upload/v1771056546/website/tim-drawn.png" tags: ["craft", "product-strategy", "career"] reading_time: "8 min read" --- # I'm cosplaying as a Product Manager, and I think I'm onto something 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: 1. **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 2. **Developer Experience tooling**: all SDKs, the CLI, starter kits, and the overall DX surface area 3. **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](https://timbenniks.dev/writing/the-age-of-the-super-t-product-person): 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.