One of my favorite books is "The Survival of the Bark Canoe" by John McPhee. In meticulous detail, it celebrates Henri Vaillancourt's preservation of ancient craftsmanship, building birchbark canoes using techniques unchanged for centuries. Sitting on the bookshelf near this book is "Inspired" by Marty Cagan. I have been thinking a lot about these books recently and the parallels between them. In this fast-paced era of product and AI, Cagan's book feels like it is also a reflection on ancient craft. The big difference between these books is that while Henri can find deep satisfaction in choosing the harder path, if PMs try to do things the old way, all that awaits them is irrelevance and being left behind.

This isn't meant to be another "AI will change everything" prediction. This is about understanding which version of product management survives the AI and automation era. But before we talk about where we are going, let's talk about how we got here.

When I read Marty Cagan's work today, it feels aspirational, if everyone did things perfectly, this is how it would work. But talking with mentors who've been in the industry longer, I'm convinced he's actually describing how things used to be. There probably was a time when product trios functioned like he describes in his books. Most of us working today missed it, it was before our time. This era had clear role boundaries, defined expectations, and standard operating models. Product managers owned strategy and requirements. Designers owned user experience. Engineers owned implementation. The triangle was sacred, handoffs were expected, and everyone knew their lane.

This is when many of us entered the field. Companies wanted PMs for everything. The joke about having a "PM for a single button at Google" was farcical but anchored in truth. Everyone getting into tech wanted to be a PM because it sounded fun and cool, being the "CEO of the product." The problem? This combination led to a lot of people who aren't actually "product people" getting PM roles. With cheap capital flooding the market, companies could afford to have PMs managing projects instead of products. Growth at all costs meant revenue was an afterthought. I don't think it was a huge problem at the time, but it's caused massive problems now that PM roles are scarce and the job market is flooded with people who have PM titles.

Interest rates rose, capital became expensive, and suddenly every role faced intense scrutiny. Companies got back to fundamentals and discovered that many of their "product managers" were really project managers in product clothing. The pressure to demonstrate clear revenue impact exposed that a significant portion of PMs had been surviving on coordination rather than creation. The "let me check with the team and get back to you" PMs suddenly found themselves vulnerable.

Here's where things get interesting and terrifying for traditional PMs. If you look at the previous eras, PMs were always the ones under pressure. Design and engineering have been pretty consistent. The tools evolved, but the core roles remained stable. The same was not true for PMs. And this is even more pronounced today. AI is compressing traditional PM workflows at an unprecedented pace:

If you spend your time doing research, writing docs, and managing tickets, you're in trouble. There's a short timeline before AI can do all of that better than you can.

The coordination-heavy, meeting-scheduling, ticket-updating PM is becoming extinct. You know the type: they're always "checking with the team," perpetually stuck in "alignment mode," and their biggest accomplishment this quarter was getting everyone to agree on a roadmap format.

If your daily work consists of synthesizing meeting notes, updating Jira tickets, and writing status reports, you're not managing a product. You're managing logistics. And logistics management has a very short shelf life in the AI era.

But from this compression, entirely new archetypes are emerging. These aren't just evolved versions of the old PM but fundamentally different roles that AI enhances rather than replaces.

This is the "10x engineer" version of Product Managers. They're the classic PM but only doing the value-add parts of the work. They understand the market, business, and product at a granularity few others achieve, generating unique insights that no one else can. (Reality check: If you're getting started in product today, this role is probably out of reach. You need extensive experience, deep knowledge, and an executive-level view. There will be few of these at each company.)

These strategists design business models and monetization strategies that others miss, identifying the hidden levers that drive sustainable growth. They excel at spotting platform and ecosystem opportunities before competitors recognize them, positioning their companies to capture network effects and build defensible moats. Their ability to navigate complex competitive dynamics allows them to anticipate market shifts and position products advantageously. Perhaps most critically, they drive cross-functional alignment at scale, translating vision into executable strategy across engineering, design, sales, and marketing teams.

These PMs excel at building and maintaining strategic partnerships that create competitive advantages. They understand when to build versus buy versus partner, and they can structure deals that align incentives across organizations. They're equally comfortable presenting to boards and working with individual engineers, adapting their communication style while maintaining strategic consistency. Most importantly, they can make high-stakes decisions with incomplete information, using their deep market knowledge to fill gaps that data can't cover. They're the ones who can look at early signals and predict where entire industries are heading, positioning their products to benefit from those shifts rather than react to them.

Design PMs possess a unique blend of strategic product thinking and hands-on design execution. They understand design systems at an architectural level, knowing how to build scalable component libraries that maintain consistency across products while allowing for innovation. They can conduct user research themselves, synthesizing behavioral data into actionable design principles rather than relying on others to interpret user needs. When they prototype with AI tools, they're testing interaction patterns, information hierarchies, and user flows that directly impact business metrics. Pretty interfaces are just the starting point.

These PMs excel at translating abstract product requirements into concrete user experiences. They understand the psychology behind interface design, knowing why certain button placements increase conversion rates or how cognitive load affects user retention. They can speak fluently with engineers about implementation constraints while maintaining design integrity, and they know when to push back on technical limitations that would compromise user experience. They understand how great design creates competitive advantages and drives product adoption.

Data Product Managers operate at the intersection of technical infrastructure and business intelligence. They design the data architecture that generates those reports. Consuming data reports is just the end result. They understand data warehouse design, ETL processes, and can write complex SQL queries to extract insights that others miss. They know the difference between batch and real-time processing, when to use each approach, and how data latency affects business decisions. When they encounter data quality issues, they can trace problems back through the pipeline to identify root causes rather than just flagging symptoms.

These PMs excel at identifying which metrics actually matter versus vanity metrics that look impressive but don't drive decisions. They understand statistical significance, can design proper A/B tests, and know when correlation might indicate causation versus when it's meaningless noise. They work closely with data engineers to optimize data collection, ensuring that the organization captures the right signals at the right granularity. Perhaps most critically, they can translate complex data findings into clear business narratives, helping executives understand not just what the data shows, but what actions they should take based on those insights. They're the bridge between data science teams who can build sophisticated models and business teams who need to make decisions based on those models.

While hands-on coding isn't strictly required today, those who can write Python scripts, build data pipelines, or manipulate datasets directly have a significant advantage. As data tools become more sophisticated and AI automates routine analysis, the ability to go hands-on-keyboard will likely become table stakes rather than a nice-to-have differentiator.

(Important distinction: This is NOT someone who uses ChatGPT at work. That's like saying you're an "agile PM" because you use Jira.)

AI Product Managers operate at the intersection of cutting-edge technology and practical business applications. They understand the nuances of different AI architectures. They can evaluate AI model outputs not just for accuracy but for bias, fairness, and ethical implications. When working with ML engineers, they can discuss concepts like overfitting, regularization, and feature engineering, contributing meaningfully to technical decisions rather than just translating business requirements.

These PMs excel at designing AI product experiences that feel magical rather than mechanical. They understand prompt engineering, retrieval-augmented generation, and how to structure AI workflows that maintain context across interactions. They know when to use human-in-the-loop designs versus fully automated systems, and they can design fallback mechanisms for when AI fails. They're equally comfortable discussing transformer attention mechanisms with engineers and explaining AI capabilities to non-technical stakeholders. Perhaps most importantly, they maintain a healthy skepticism about AI capabilities, understanding the difference between demo-quality results and production-ready systems.

The valuable AI PM is the one who can tell stakeholders "this is not an AI problem" and explain why. They understand when traditional algorithms outperform AI, when the data requirements for effective AI solutions are unrealistic, and when the cost-benefit analysis doesn't support an AI approach. They can identify use cases where AI adds genuine value versus where it's just technological novelty, helping organizations invest their AI efforts where they'll have the greatest impact.

While you don't need to be able to train models from scratch, those who can write code to experiment with APIs, build prototypes, or analyze model outputs have a massive advantage. As AI development tools become more accessible, the expectation for hands-on technical skills will only increase—being able to go from idea to working prototype will separate the truly effective AI PMs from those who can only talk about AI conceptually.

Platform PMs operate like technical architects with business acumen. They understand distributed systems, microservices architecture, and can reason about scalability constraints, latency requirements, and failure modes. When they design APIs, they're thinking about versioning strategies, rate limiting, and how changes will affect downstream consumers. They know the difference between REST and GraphQL not just conceptually, but understand the performance and complexity trade-offs of each approach in different contexts. They can read system architecture diagrams, understand database design decisions, and know when technical debt is accumulating to dangerous levels.

These PMs excel at making platform decisions that seem purely technical but have massive business implications. They understand how authentication and authorization systems affect user experience, how data consistency models impact feature development speed, and how infrastructure choices constrain future product possibilities. They work closely with DevOps and infrastructure teams to ensure platform reliability, but they also collaborate with product teams to understand their needs and translate them into platform requirements. Their strategic thinking extends beyond immediate technical needs; they anticipate how the platform will need to evolve as the business grows, ensuring that foundational decisions made today won't become bottlenecks tomorrow. Most importantly, they measure platform success not just by uptime and performance metrics, but by how effectively they're enabling other teams to build and ship products faster.

Platform PMs are usually "technical PMs." They often have engineering backgrounds and need some of deepest technical knowledge of all PM archetypes. While they don't necessarily need to write production code, those who can prototype solutions, debug issues, or contribute to architecture discussions have significant credibility advantages. As platforms become more complex and development cycles accelerate, the ability to understand and sometimes implement technical solutions will become increasingly valuable for platform PMs who want to remain effective leaders rather than just coordinators.

The traditional PM-Designer-Engineer triangle is fragmenting, and the images I've seen from other teams confirm what I'm experiencing: we're moving toward hybrid roles that compress multiple functions. This new reality looks like:

Here's the uncomfortable truth: PMs are at the most disadvantage in this transition. Engineers already have technical skills and many have developed product sense. Designers understand user experience and many have strong business instincts. PMs have the most to learn and grow. That's why every successful transition requires ambition and willingness to fundamentally change how you work.

The best engineers I work with are already good designers and product thinkers. The best designers have product chops that rival most PMs. If you're a PM who can't code, can't design, and can't analyze data at a technical level, what unique value are you providing? Even the "Super Technical PM" role I see emerging requires hands-on keyboard skills. But here's the trap: if you use AI to write all your code and then blindly take it to engineering, you'll lose all credibility. You either need to learn to code or at least understand it well enough to explain why the AI chose specific APIs, how the functions work, or how authentication is incorporated. "Vibe coding" with AI could help or hurt here—it depends on whether you use it as a crutch or a learning accelerator.

Speaking from personal experience, learning to code has fundamentally transformed my effectiveness as a PM. It has brought me a new level of trust with engineering teams who now see me as someone who understands their constraints and challenges rather than just someone making requests from the outside. I've been able to actively contribute to the codebase, whether it's fixing small bugs, building prototypes, or implementing simple features. This not only helps the team but gives me credibility when I'm making technical decisions or trade-offs. Perhaps most importantly, it has given me a systems-level view of how the product actually works, allowing me to spot potential issues, understand performance implications, and make more informed architectural decisions. The difference between knowing about technical concepts and actually working with them daily is a superpower, it changes how you think about product possibilities and constraints.

Maybe that was a bit too much doom and gloom. The reality is that while the landscape is shifting rapidly, there are clear paths forward for PMs who are willing to adapt. The key is being intentional about your evolution rather than hoping things will return to how they were. The PMs who thrive in the AI era won't be the ones who resist change, but those who lean into it strategically.

Step 1: Audit your current value proposition Take an honest inventory of what you do that AI can't automate and where you provide unique insight or judgment that others can't replicate. Ask yourself what would happen to your product if you disappeared tomorrow. If the answer is "someone else could easily fill in," you're in the danger zone. This exercise will reveal whether you're providing strategic value or just coordinating work that could be streamlined or automated.

Step 2: Choose your specialization Pick one of the archetypes and commit fully rather than trying to be all things to all people. Depth beats breadth in the AI era, and companies will increasingly reward PMs who can go deep in one domain rather than those who know a little about everything. Make this choice based on your natural strengths, interests, and the market opportunities you see in your industry.

Step 3: Start building technical skills now Whether it's learning to code, understanding data pipelines, developing design capabilities, or diving deep into AI systems, you need hands-on skills that complement your strategic thinking. Don't just read about these topics. Actually build projects, write code, analyze datasets, or create prototypes to develop real competency. The gap between PMs who can talk about technical concepts and those who can actually work with them will only widen as AI makes technical work more accessible.

Step 4: Embrace the hybrid future Start taking on projects that blur the traditional boundaries between PM, design, and engineering roles. Prototype alongside engineers, analyze data yourself, design user flows, and get comfortable being uncomfortable with tasks that traditionally weren't "PM work." This cross-functional experience will prepare you for the compressed roles that are already emerging and give you credibility when working with specialists in other domains.

This transformation isn't happening slowly. Teams are already experimenting with compressed structures. Organizations are restructuring around these specialized roles. The market is rewarding PMs who can demonstrate technical depth alongside strategic thinking. Henri Vaillancourt could choose the harder path and find satisfaction in tradition. We don't have that luxury—our craft lies not in preserving the past, but in defining what product management becomes next.