These are my reflections from the past year - the ideas about building products that reshaped how I work. Some of them come from my current work, others from conversations with other product people.
It's less about me, and more about what I think is changing in how we build products.
The deeper shift is one every product person is living through: the way we build, communicate, and plan is changing under the pressure of AI faster than we can write it down.
The product roles are collapsing into one another
"We're still here with the same brain we had yesterday." - Julie Bedard, Boston Consulting Group (2026)
It used to be enough to say a PM should "know a little about technology." That bar is gone.
The classic product trio - Product Manager, Designer, Engineer - and the build-adjacent roles around it, like QA and BA, increasingly overlap.
AI tooling is a good symbol of this: protocols like MCP let a single model (and the person driving it) reach across a design file, a codebase, and a test suite at once.
Everything is mixing and connecting with ease - note and knowledge apps, cloud drives, issue trackers and project boards, wikis, team chat, code editors, and design tools all increasingly talk to one another.
The blur reaches further out too - sales, marketing, and support converge on the same product data and AI assistants - but through a different mechanism: shared context, not shared tooling.
Either way, each of us now has to understand more of the adjacent domains - not to replace the specialists in them, but to weave their work into one coherent whole. This isn't the end of deep expertise; if anything, depth matters more, because depth is what lets you judge whether the model's output actually holds up. What's changing is that the borders between specialties are getting more porous.
This isn't just my read. ProductPlan's 2026 State of Product Management survey found that 73% of PMs expect the role to become more hybrid - blending product, design, and engineering - while flagging the same risks I'd name: blurred boundaries and skill gaps. Breadth is widening; the bar on depth isn't dropping.
There's a lot of good in this. But there's a cost, and it has two faces:
- Brain fry. A recent Harvard Business Review study named the mental fatigue that builds when we spend our days prompting, supervising, and juggling AI tools beyond what our attention can hold. It's not classic burnout - it's closer to having too many tabs open in your head.
- Over-reliance. The quieter risk: handing our analysis to the model until we stop doing it ourselves.
The lesson is the same either way: this demands better navigation and resource management - and not just of tokens.
The day still has 24 hours, and our cognitive context window is still exactly the size it has always been.
Vibe coding is a door opener
Vibe coding turned out to be a genuinely effective way to open conversations about a target solution and its business value. Quickly building a working - if limited - app lets you move from notes, diagrams, and wireframes to something you can actually touch.
That changes the conversation:
- It centers on the outcome, the functionality, and the experience instead of abstractions.
- A prototype can carry interactions, simple memory, event logging, and basic flows - which makes shared understanding far easier.
- You generate useful artifacts along the way: diagrams, schemas, architecture proposals.
There's a bigger shift hiding in this. As vibe coding gets democratized - you no longer need to code to make something real - it opens a new way of building a product with the client.
Instead of scheduling meeting after meeting and bouncing versions A, B, and C past them, both sides can push on the same working thing until someone says: yes, that's it.
But these need distance. The solutions a prototype suggests aren't always optimal, or directly usable in the real product. The real value is fast idea validation and sharper expectations before implementation begins.
…and a new set of problems
The same speed that makes vibe coding useful also creates new problems.
For engineering, there's the gap between a vibe-coded prototype and a production system that meets the bar for quality, security, scalability, and maintenance - especially where correctness hits the business or users directly, as in billing or operational processes. What looks convincing as a prototype often needs significant work to ship.
For product, it's the opposite trap. Vibe coding makes it easy to visualize an attractive vision fast - which can set expectations that later collide with technical, cost, or organizational limits. The discipline becomes managing the boundary between a prototype for exploration and a real plan for delivery.
And there's a cultural risk worth naming: speed of delivery getting mistaken for quality or readiness. Another HBR-published study has a word for what happens when it does - workslop: confident-looking AI output that quietly creates more work for whoever has to fix what the model got wrong. The simplest solution isn't always the best one.
Atlassian's State of Teams 2026 puts numbers on this: around 89% of leaders say AI has made work faster, yet only about 6% can point to clear, company-wide returns. Speed and value, it turns out, are not the same thing.
The answer to that gap is discipline: asking, again and again, whether an idea genuinely adds value or just sounds interesting. Enthusiasm on its own is easy to mistake for progress.
This is why governance matters more, not less - standards, reviews, automated tests, monitoring, validation, and clear ownership of the code that gets produced. In the long run, organizations will be judged not on how much they can generate, but on how well they can control and safely maintain it.
Short-term wins vs long-term bets
Not all AI value is the same kind, and it pays to be deliberate about which you're chasing.
Some of it pays back once: a quick automation or a single-purpose app that does X, Y, Z. Cheap, fast, satisfying - and easy to over-invest in, precisely because the payoff is immediate and visible.
The other kind compounds: assistants and systems that accumulate context and get more useful the longer they run - building leverage rather than just saving you an afternoon.
The trap is filling your days with disposable wins that never add up to a durable advantage. Fast value is easy to see; compounding value is easy to neglect.
The verification problem is the one to watch
"You can outsource your thinking, but you can't outsource your understanding." - a line Andrej Karpathy keeps citing
Right now we're in a comfortable spot. Most of what AI generates falls in areas where we have enough knowledge to judge whether it's correct. AI speeds the work up, but the human is still the final reviewer.
That comfort has an expiry date. We may reach a point where AI produces solutions beyond the knowledge and experience of the people using it. Then the traditional model breaks: you can no longer personally assess every part of what you ship.
That raises a real question about the source of trust in what we build. A few answers, and they reinforce each other:
- Keep growing our own competence - stay close enough to the work to judge it.
- Build systemic controls - independent verification by other models, agents from different providers, automated tests, formal validation, guardrails. Just be careful with the word independent: models trained on similar data can share blind spots and agree, confidently, on the same wrong answer.
- Lean harder on the team. As AI generates more, there is more to verify at every stage - concept, requirements, design, and delivery - and a single reviewer quickly becomes both a bottleneck and a single point of failure. Many perspectives catch what one person can't, which makes collaboration less of a nice-to-have and more of one of the most valuable controls we have.
Longer term, the key skill may not be creating solutions at all, but designing the processes that let us evaluate and control what AI produces.
The direction I see is the same one the whole field is moving toward - autonomous, agentic systems. But there's still real work between here and there, and it won't arrive in one leap: it will come in stages, with the autonomy and the controls that keep it trustworthy maturing together.
Documentation is becoming an interface
For years documentation was written for humans - developers, analysts, testers, new joiners. Increasingly, the reader is also a model.
That changes the expectations. Documents need to be unambiguous, precise, consistent, and context-rich enough to be used by systems that automatically generate code, tests, diagrams, and analysis. The way we describe functionality shifts toward structured process descriptions, clear definitions, and formalized requirements - artifacts both humans and machines can interpret.
The tension is obvious: docs written only for models become less accessible to people, and docs written only for people are hard for tools to use.
It's a point Abrar Abutouq at Userpilot makes well about 2026: plug a copilot into drifting docs and contradictory tickets and it becomes a "confident summarizer of stale information" - output that feels almost right but never quite is. A better model won't fix that; only a real source of truth will.
So the goal is no longer "how much documentation" but "is it precise enough to be understood the same way by a human and a machine." In effect, documentation becomes an executable specification - though honestly, most organizations (mine included) are still some distance from that ideal in practice.
A few things I'm still working through
Not everything here is settled - a few threads I keep coming back to.
On chasing the newest tools. New ones land every day, but my instinct is to let the first wave pass - to wait until the limits and the real possibilities of each are mapped before betting on it. I don't see much evidence that whoever ships the newest AI feature first wins the market. Being early and being right aren't the same bet.
On the real obstacle. Reading what others post on LinkedIn, I keep landing on the same conclusion: the hard part right now isn't the technology, it's redesigning how a company actually works - making automation and the flow of knowledge the default rather than the exception. In other words, connecting what today stays disconnected.
On communication. AI is changing not just how we work and talk - including how we talk to the models - but how people receive things written with AI. That puts the end reader back at the center. I'm trying to cut unnecessary noise and focus on what really matters.
On the PM's job. The core hasn't changed: addressing the real need - what Uri Levine calls falling in love with the problem, not the solution. You can prototype at enormous scale, but on the other side is a client who still has the same 24 hours - in practice far fewer - to absorb what you're trying to show. The constraint was never how much you can produce; it's how much the other person can take in.
The shift underneath all of it
The most important change isn't the arrival of AI or vibe coding.
It's the shift of effort from creating to defining, verifying, and managing. The cost of building solutions is dropping sharply, while the value of a precise problem description, the ability to judge results, and the design of control mechanisms is rising.
As Setu Shah of Oracle put it in ProductPlan's 2026 survey, AI hasn't replaced roles so much as raised the bar: "execution got faster, but thinking became the real differentiator."
In a world where building gets cheaper and faster, the edge won't belong to the organizations that generate the most code. It will belong to the ones that best decide what should be built, verify that the results are correct, and ship them safely into the real world.
Sources
- "AI brain fry" and the Julie Bedard quote - When Using AI Leads to "Brain Fry", Harvard Business Review, March 2026 (quote via CBS News).
- "Workslop" - AI-Generated "Workslop" Is Destroying Productivity, Harvard Business Review, September 2025.
- Speed-vs-ROI figures - The future of product craft / State of Teams 2026, Atlassian.
- Copilots on stale docs - What is product management (in 2026), Abrar Abutouq, Userpilot.
- Product-management role and AI-adoption figures, and the Setu Shah quote - State of Product Management 2026, ProductPlan.
- Andrej Karpathy quote - remarks at a Sequoia Capital fireside chat ("You can outsource your thinking, but you can't outsource your understanding").