Think about what product work actually looks like right now, across the teams you know.
Someone vibing up a working prototype in Claude Code over the weekend. A team ditching the PRD altogether and sending a rough cut straight to engineering. A product person spending their energy not on a roadmap, but on building a team of agents to do the work they used to hand off.
Maybe this isn't the way your product team looks today. But for many teams, it's starting to become what the new normal looks like.
In those conversations I keep having with product people, I keep noticing something else – the people doing this new kind of work are energized in a way that's hard to fake. More hands-on and closer to what they're building. For some, it's the most alive they've felt in their careers. And yet for others, it's terrifying.
Both reactions make sense. Because what's exciting and frightening are often the same thing. I recently had the opportunity to meet with a couple dozen technology executives and product leaders in Rochester, NY and the group was very open with each other about what excited them and what kept them up at night.
One product leader there – a Head of Product at a regional cancer institute – said: "The compression of time to build something – and therefore time to data and insights – is a double-edged sword. We can build faster than ever. But we can get to the wrong thing faster while waiting for clarity and judgment to catch up."
It’s like AI just delivered us all Lamborghini’s to drive – and those fancy high-performance sports cars go twice the speed as our standard-issue commuter cars. But it assumes we all know exactly where we’re going in the first place. Because if you don’t know the right path, sure – you can go faster than ever. But it means you can also go in the wrong direction faster than ever.
One of the leaders in Rochester shared how his company now has 2,000 people accessing raw customer data directly through Claude. He’s excited about data being more accessible to him than ever before. But he’s also worried about what this may mean. He remembered when companies first started opening up Google Analytics company-wide where there could be 12 different people trying to pull the same data point, but would interpret it 12 different ways. More access meansmore speed, but more ways to get it wrong.
When you look at the job market for product roles, there’s another glaring discrepancy. It’s been reported that there are more open product jobs than ever – with salaries most product people would have found unimaginable five years ago. Yet, some of the most experienced product people I know have been out of work for months. So, what gives?
What this means for the future
I think this gap has to do with us all witnessing a re-write of what product management actually means. We're seeing a transition away from the product person as the communicator – the person who's corralling the various groups like designers, developers, management, sales, and other stakeholders – where the value they offer lies in the mechanics of product rather than the actual building of product. Those focused on the mechanics of product are more concerned with applying the frameworks, running the process, and producing the artifacts like roadmaps, PRDs, and retros.
Nikhyl Singhal, Founder of the Skip Community and former VP of Product at Meta, believes that this type of product person is one that’s not long in the tech world. On a recent episode of Lenny Rachitsky's podcast, Singhal said, "The information mover is essentially going to become a dinosaur." It’s a bold statement to make, but he may be right. The product people whose careers were built on carrying context between teams may very well be at risk and are probably the ones feeling disruption the most right now – struggling in a job market that seems rosy, but not for them.
The companies hiring are instead favoring the builder.
The builder is still a product person, but one who shows up with something that exists, the way that engineers and designers have always done. Somebody who can compress the distance between an idea in your head and something an actual human can touch. It means no longer describing ideas – and working to actually prototype them rather than relying on a static deck.
The builder is leveraging today’s AI tools to do all of this faster than they ever could before. They’re leaning into agentic workflows. They’re introducing the rest of their company to new tools that can help everybody else go faster, too. And they’re having fun doing it all.
I've heard product people describe building with today's AI tools with the way I would have described Tecmo Bowl when I first popped it into my Nintendo as a kid… staying up too late, forgetting to eat, genuinely delighted. It also means they’re perpetually exhausted. But it’s mostly self-induced. Mostly.
In a way, the role of the builder is a merging of the product, designer, and developer roles. One builder could potentially play all three roles if they have the right background. Another person I talked to at that event in Rochester had a really interesting analogy about this merging of roles. He compared it to "positionless basketball” – a style of the sport where the rigid role assignments that traditionally define who does what on the court get thrown out. Every player is expected to be a complete player – they’re all meant to handle the ball, create shots, facilitate for teammates, and guard anyone on the floor… no matter their size or where they line up.
This means product people doing design and engineering work. Engineers doing product work. Designers shipping code without waiting for a handoff. So maybe the future role of tech products is more like… positionless product?
Again, it can be an exciting future. But I can understand why it’d be a slightly terrifying one for many, too. Because positionless basketball only works when everyone on the court has skills to compete and the judgment to know when to pass and when to take the shot.
Of course, the type of person who can do it all isn’t brand new. This type of person used to be referred to as a unicorn – somebody who was rare because the skills were hard to stack. The path to being a builder is more accessible than that today. AI is essentially lowering the floor. You don't have to master engineering or design to prototype and build now. You just have to be curious enough to try.
And curiosity is easy to overlook, but I think it may be the most important characteristic of the type of product person who will make it in this new AI-everything wave. For those that have a decade or more of product experience, you may have to think back to the early days when you first got into product. If you were like me, you didn’t go to school to be a product person. That path didn’t exist for you. So you learned on the fly. You experimented. And maybe over time, you “figured it out” and finally became comfortable with being a product person.
But now… things have changed. Transforming from being the product person of the past to builder of the future may require you to get comfortable with being uncomfortable again. You may need to be OK with looking a little silly while you figure things out. It requires you to dive head-first into new tools that you have no experience working with. Because you have to start somewhere.
How I’m getting my hands dirty
A few months ago, my colleague at Pendo, Dave Killeen, built his own AI Chief of Staff. He calls it Dex. Watching Dave build Dex in public triggered two instincts in me all at once: a subtle pressure to tense up and feel behind. But also a quieter one that won out – I just wanted to try. So I started using Dex which was fun to learn. But then I decided to start digging in and experimenting with building my own tools (admittedly nowhere near as complex and elegant as Dex).
Look, I'm not technical. I never was. But I learned that I didn't have to be. My curiosity alone led me to start to experiment with Openclaw, which I now use to help me in my current role as Head of Product Evangelism at Pendo. I literally fed it my vision for my new role and writing samples from the book I'm working on, let it interview me, and started talking to it regularly through Telegram. And yeah, it broke often… even during setup. So I'd screenshot the errors, paste them into Claude, and let Claude walk me through the fix.
What surprised me was how it changed my relationship with my own work. One night, late, I was still grinding. The assistant finished a task, paused, and essentially told me: we've done a lot today, you'll get more done tomorrow after a good night's sleep. Go to bed.
Shifting into “builder” mode
So… am I a builder? I wouldn’t put that label on myself quite yet. But then again, when I took on my first product role over a decade ago, it took me a long time to feel comfortable enough to call myself a product person. But… I am keeping my mind open. I’m trying to stay curious. Because the curious ones are the ones getting energized right now. And the thing about curiosity is you don't need permission to start.
And if we’re being real, we may not have the choice to opt out of this future. Just last week, Brian Armstrong sent a memo to his team at Coinbase announcing 14 percent layoffs and naming two converging forces: a down market and AI. He's now experimenting with "one-person teams" where engineering, design, and product responsibilities sit in a single role. He's eliminating pure managers in favor of player-coaches who still build alongside their teams. He described his goal plainly: rebuilding Coinbase as "an intelligence, with humans around the edge aligning it."
There’s another line in his memo that still stays with me.
"The biggest risk now is not taking action."
I think that’s a direct statement to all of the product people who aren’t so sure if it’s even necessary to embrace this new AI-everything world. The ones who question whether this is all just a passing fad. They can choose to be skeptical. But there’s risk in that.
The question – what does a product person actually do at this company now? – is being answered in writing, by real CEOs at real public companies. It's no longer a thought experiment.
So now the real question is… are you curious enough to rewind back to the days when you didn’t know what you didn’t know? Can you get comfortable with being uncomfortable again? And most importantly…
Are you ready to build?
If you are but just need some help on where to start, let me offer some ideas. Don't try to build something elegant on your first weekend. Pick one small thing in your week you find yourself doing over and over. Maybe at first, it’s a simple status update, recurring research, or meeting prep. Try to build something that handles one of those jobs for you. Pick one tool and just start. When it breaks (and it will), screenshot the error, paste it into Claude, and let it walk you through the fix one step at a time. Ship it ugly. Use it for a week. Then do it again. The reps are the point. And if you need some helpful resources to get you in the right mindset, I have a few to recommend:
Lenny's Newsletter & Podcast: Lenny Rachitsky has become the central chronicler of the builder-PM shift. The Nikhyl Singhal episode quoted above is one of many; episodes with Claire Vo, Aman Khan, and Boris Cherny dig deeper into this theme.
How I AI with Claire Vo: Claire (Founder of ChatPRD) interviews operators about exactly how they use AI in their day-to-day work – what tools, what prompts, what failed. The closest thing to looking over someone's shoulder, and most guests are PMs and operators rather than AI researchers, so the workflows actually translate.
The Vibe PM with Dave Killeen: The most explicitly PM-becoming-builder resource on this list, written by someone living the transition (and the person who built Dex). Dave’s show is like a living field manual.
Product Growth with Aakash Gupta: Probably the most prolific PM writer who's pivoted hard into AI. Practical, frameworks-heavy, and very PM-vocabulary friendly. Good for the reader who wants a bridge from old-school PM thinking into this new world without learning a new dialect.
Every, especially Dan Shipper's "How Do You Use ChatGPT?": Dan has been documenting his own builder transition for years. His interview series with operators using AI in real work is excellent, and his essays make the "everything is software now" case better than anyone I've read.
One Useful Thing with Ethan Mollick: The most respected accessible AI writer for non-technical professionals. He's a Wharton professor, so the lens is "how does a thoughtful operator who isn't an engineer actually work with these tools?" His book Co-Intelligence is the long-form version.
The Skip with Nikhyl Singhal: Since I quoted him above, his newsletter and community are where many senior PMs are gathering to figure out what comes next. It's where the "information mover going extinct" conversation is happening openly, with the people most affected by it.
Greg Isenberg's YouTube channel: Greg interviews indie builders and AI-native operators weekly. His videos with Riley Brown, Pieter Levels, and others show what "positionless" actually looks like in practice – one person, no team, real product shipping.
Riley Brown's YouTube channel: Greg's channel focuses on the interviews, while Riley's provides the actual tutorials. He's become the most accessible voice on vibe coding for non-technical builders. Watching him build is the fastest way to get over the "I could never do that" feeling.
