Product Management

Your Team Is Not Misaligned. Your Metrics Are.

I have been thinking about something lately. Something I noticed a while ago but only recently got to do something about.

At one of the companies I worked for a couple of years back, we had four different dashboards tracking the same product. Four. The PM team had one. Sales had one. Operations had one. Customer Success had their own.

Same product. Four different versions of what success looked like.

It was like four people watching the same movie but somehow describing completely different plots. At full volume. In a meeting room with bad coffee.

And we wondered why decisions took forever. Why alignment meetings felt like negotiations. Why everyone showed up with data that somehow, miraculously, supported their own position.

We were not slow because of bad people or bad process. We were slow because we were not even looking at the same reality. Which, when you say it out loud, is kind of hilarious. And also kind of sad.

That stuck with me. For a long time actually.

What if that is the actual problem? Not prioritization. Not roadmap quality. Not team structure. Just four teams, each staring at their own slice of the truth, each fully convinced their slice is the whole picture.

This year, with one of the companies I have been working with, I finally got to do it differently. We built one shared dashboard. Product metrics next to commercial metrics next to customer metrics. In one place. Updated in real time. Every team looking at the same numbers every week.

No translation layer. No “let me pull that from our system.” No version of the data that was three weeks old because someone forgot to refresh the export. No more showing up to a meeting with a spreadsheet that contradicts the other guy’s spreadsheet and then spending forty minutes figuring out whose spreadsheet is lying.

Just one shared view of what was actually happening.

The difference was immediate. Not in the data itself. In the conversations around it.

I read something recently from Product School that put it plainly. The winning teams in 2026 are building shared dashboards that mix product, commercial, and customer metrics so PMs, engineers, designers, and GTM teams are all looking at the same outcomes every week and adjusting in real time. Siloed metrics, they said, are a root cause of slow and misaligned teams.

That landed differently after what I had seen in the field. Because it is not just about speed. It is about trust.

When everyone has their own dashboard, every meeting becomes a debate about whose numbers are right before you can even get to what to do about them. You spend the first twenty minutes of every decision-making conversation just trying to agree on the current state. That is exhausting. And it is invisible. Nobody puts “reconciled four versions of the same data” in a retrospective. But it costs more than people think.

What if the fix is not another framework or another process? What if it is just one screen, visible to everyone, showing the same thing at the same time?

It sounds almost too simple. Suspiciously simple, even. But I keep coming back to it.

The teams I have seen move fast are not necessarily smarter or better staffed. They just spend less time arguing about what is true and more time deciding what to do about it.

That is the whole game, really. And it starts with everyone looking at the same dashboard.

AI Prototyping for Product Managers. Why Weeks of Work Now Feel Like Overkill

If you still spend weeks building prototypes, I say this as a friend. You are working too hard.

AI changed prototyping in a quiet but rude way. The kind of change where you look back and think, why did we agree to suffer like this.

Over the past year, working as a product consultant, I watched AI reshape how Product Managers work day to day. I already talked about discovery and prioritization. Prototyping needed its own moment.

Because the old way was slow. Painfully slow.

The old prototyping life

Prototyping used to feel serious. Like “put on a calendar invite and lower your voice” serious.

You waited on design.
Then you waited some more.
Then engineering got pulled in.
Then someone said “this is just a prototype,” while acting like it was shipping tomorrow.

Weeks passed. Energy faded. Context leaked out of everyone’s brain.

I watched teams protect weak ideas because they already invested time. Not because the idea was good. Because letting go hurt.

That is not learning. That is emotional attachment.

What AI prototyping for product managers really means

AI prototyping for product managers means turning ideas into testable things fast. Not perfect things. Testable things.

You generate UI flows. You generate copy. You spin up variants. You test before anyone feels married to the solution.

The goal stays simple. Reduce risk before writing production code.

The difference is timing. Feedback shows up while the idea still feels disposable. That feeling is gold.

A real example, no corporate voice

A team I worked with wanted to reduce onboarding drop-off. Not flashy. Very important.

Old approach would have produced one flow after weeks of effort. Big reveal. Mild disappointment.

Instead, they used generative AI plugins in Figma. In a few hours, they had multiple onboarding flows. Different layouts. Different copy. Different pacing.

They pushed those screens into Maze. They tested with a small group of beta customers.

One question drove the test.
Which onboarding flow makes fewer people quit halfway through.

Within a week, the answer was obvious. They killed the weaker options early. No sunk cost guilt. No drama.

Speed changed behavior. People stayed curious instead of defensive.

Why this speed messes with your head

When something takes less effort, people stop protecting it.

That is the sneaky benefit of AI prototyping. Cheap experiments lead to honest conversations.

When prototypes cost weeks, feedback feels threatening.
When prototypes cost hours, feedback feels useful.

This shift alone improves decision quality.

The tools matter less than you think

Everyone asks about tools. Totally fair.

Here is the boring truth.

One AI-assisted design tool.
One testing tool.
One clear success metric.

That is enough.

I have seen teams drown in tools and still learn nothing. I have seen tiny stacks produce strong decisions.

Habits beat tooling every time.

What teams learn faster with AI prototypes

AI prototyping shines early. Before roadmaps lock. Before Jira tickets multiply.

Teams learn quickly about:

• Onboarding clarity
• Feature discoverability
• Value proposition confusion
• Flow complexity

Watching a user hesitate for a few seconds teaches more than ten stakeholder opinions.

Confusion shows up fast when you expose ideas early.

The risk nobody warns you about

AI prototypes look good. Too good.

This creates a new trap. People confuse “looks real” with “is validated.”

I have watched leaders approve directions based on polished prototypes alone. Users touched the product later. Pain followed shortly after.

Speed does not remove the need for validation. It increases the need for discipline.

How AI quietly reshapes the PM role

AI prototyping shifts where Product Managers spend time.

Less coordination.
Less chasing assets.
More thinking.

The job leans harder into problem framing and signal interpretation. Vague thinking breaks fast now. Which is uncomfortable. Also healthy.

Clear thinking compounds when execution speeds up.

What this does to roadmaps

Roadmaps feel lighter in teams who prototype fast.

Ideas get tested before promises get made. Fewer surprises pop up mid-quarter. Fewer “how did we miss this” moments.

Roadmaps turn into collections of bets backed by evidence, not opinions.

Leadership alignment improves when data shows up early.

All actionable takeaways, in one place

Use these as guardrails. Print them. Tattoo one. Your call.

• If a prototype takes weeks, you are pre-building
• Write the test question before opening design tools
• Test one flow for one use case at a time
• Pick one success metric per experiment
• Test with real users, not coworkers
• Label prototypes as learning artifacts in reviews
• Delay roadmap commitments until signals repeat
• Kill ideas early while it still feels easy
• Focus on behavior, not polish
• Bring test results into roadmap conversations

Conclusion

AI prototyping for product managers changes the pace of learning. Hours replace weeks. Signals arrive earlier. Bad ideas die younger.

The risk sits in polish. Discipline keeps learning real.

This shift is already here. Teams who adapt move faster with fewer regrets.

I will keep sharing what I see. Mostly because watching bad ideas die early never stops being satisfying.

How to Recruit Talent for AI Product Work. A VP Product Answer I Did Not Expect

I asked a VP of Product a simple question.

“How do you recruit talent for AI product work?”

I expected a long answer full of model names, frameworks, and words people only use on LinkedIn.

Instead, he paused. Took a breath. Then said something uncomfortable.

“I try to avoid people who sound too confident.”

That answer stuck with me.

Over the past year, as a product consultant, I’ve had this conversation with multiple leaders. Everyone struggles with the same thing. Hiring for AI feels different. Old signals stop working. New ones feel fuzzy.

So I want to walk you through how this VP thinks about hiring for AI product work. Not theory. Not hype. Just what actually changed in his hiring bar.

Why AI hiring breaks old habits.

The VP started with a confession.

“Our hiring process worked fine before AI.”

Product roles moved slower. Problems stayed stable longer. Skills aged gracefully.

AI broke all of that.

Tools rotate fast. Techniques expire. Yesterday’s best practice becomes tomorrow’s cautionary tale.

He told me he hired people who looked perfect on paper. Strong resumes. Big company names. AI everywhere.

Then reality hit.

Models behaved weirdly. Data quality disappointed. Users misunderstood outputs. The confident hires froze.

“They wanted the right answer,” he said. “AI work rarely gives you one.”

What AI product work really looks like.

He described AI product work as a constant negotiation with uncertainty.

The model works in one case and fails in another. User trust fluctuates. Accuracy looks good until edge cases show up and ruin your week.

Success depends less on knowing tools and more on how someone reacts when things stop behaving.

He looks for people who stay calm when systems feel incomplete.

Not optimistic. Not pessimistic. Curious.

“The best people don’t panic when the model surprises them,” he said. “They lean in.”

Why resumes stopped being useful.

I asked him how he screens candidates.

He laughed. Not a happy laugh.

“Resumes lie more now than ever.”

People list models. Platforms. APIs. None of that predicts performance.

Instead, he listens for stories.

He asks candidates to talk about:

• A time AI did not behave as expected
• A decision they had to reverse
• A metric they thought mattered but did not
• A moment users lost trust

Candidates who struggle here usually struggle on the job too.

People who only share success stories worry him. AI work is mostly about recovering from failure.

How he interviews differently now.

The biggest shift sits in interviews.

He avoids trivia. He avoids quizzes. He avoids “design an AI system on the whiteboard.”

Instead, he gives candidates messy situations.

A half-working AI feature. Conflicting metrics. Unclear user feedback.

Then he watches how they think.

Strong candidates ask clarifying questions. They challenge assumptions. They talk about tradeoffs.

Weak candidates rush to solutions. Or worse, try to sound smart.

“The moment someone pretends certainty,” he said, “I get nervous.”

Why did confidence become a red flag?

This part surprised me the most.

He actively distrusts confidence in AI interviews.

Not insecurity. Not hesitation. Overconfidence.

AI systems change too fast for certainty to age well. Confident people ship faster. Curious people learn faster.

He hires people who say things like:

“I don’t know yet, but here’s how I’d find out.”
“This metric worries me.”
“This feels brittle.”

Those sentences signal maturity.

How this changes the hiring bar?

He admitted that hiring feels slower now.

Good candidates take longer to identify. Interviews feel more exploratory. Decisions feel less obvious.

But the payoff shows up later.

Teams adapt faster. Less blame. Fewer panic moments when models drift or users behave unexpectedly.

Hiring the wrong AI talent hurts more than waiting.

“Replacing someone who can’t operate in uncertainty is brutal,” he said.

What leaders often miss?

He made one last point before we wrapped.

AI hiring reflects leadership culture.

If leaders demand certainty, teams hire confident talkers.

If leaders reward learning, teams hire thinkers.

AI exposes culture faster than most technologies. Hiring mistakes surface quickly. There is nowhere to hide.

All actionable takeaways, in one place…

Here is how this VP hires for AI product work.

• Hire for curiosity, not confidence
• Ask about failure, not just success
• Focus interviews on messy scenarios
• Avoid tool trivia and quizzes
• Look for comfort with uncertainty
• Prefer reasoning over memorization
• Treat AI as a system, not a hero role
• Slow hiring beats fast regret
• Reward learning speed over certainty
• Watch how candidates react when unsure

Recruiting for AI product work feels hard because the work itself resists certainty.

This VP does not look for experts. He looks for people who stay calm when systems break, assumptions fail, and users surprise you.

Buzzwords fade fast. Judgment compounds quietly.

I will keep asking leaders this question. Mostly because watching confidence collide with reality in AI work never stops being educational.

Vibe Coding Is Essential for Modern PMs. Here’s My Proof

If you are a Product Manager in 2026 and you still need a full sprint to test an idea, you are choosing friction.

The distance between idea and working product has collapsed. AI copilots, LLM APIs, and lightweight hosting stacks let you move from “what if” to “try this” fast.

That shift changes the PM role.

Vibe coding is becoming essential for modern PMs because it removes excuses. You can prototype. You can test. You can learn. Today.

And I proved that to myself by building a chatbot on my own website in a couple of hours.

What vibe coding actually means

Vibe coding is not about becoming a full-time engineer.

It is about describing the behavior you want in plain language and using AI to generate the implementation. You refine by iterating, not by memorizing syntax.

You focus on:

The user job
The outcome
The constraints
The edge cases

The AI handles boilerplate. You handle judgment.

This idea is not fringe. Andrej Karpathy famously said the hottest new programming language is English. GitHub Copilot adoption data shows strong acceleration across development workflows. Microsoft pushes Copilot as a productivity layer across roles, not just engineering.

The pattern is clear. The interface between product thinking and software creation is shifting.

PMs who understand this gain leverage.

Why this matters specifically for PMs

For years, PMs operated at arm’s length from code.

You wrote specs.
You waited.
You aligned.
You reviewed.

Now you can:

Spin up micro tools for your own workflow
Prototype AI features before committing engineering time
Test UX flows with real logic behind them
Create small internal bots
Validate assumptions with something tangible

This compresses decision cycles dramatically.

Instead of asking “is this feasible,” you ask “is this valuable.”

That shift changes conversations.

My example. A chatbot that explains my career

I got tired of repeating the same explanations in different formats.

So I built a chatbot on my website that answers questions about my professional experience and skills.

You can try it here: https://benjaminlecam.info

People can ask:

What I built in marketplaces and logistics
How I used AI for document automation and verification
How I approach roadmaps and tradeoffs
Where I drove measurable impact

Instead of a static resume page, visitors interact with my experience.

It behaves like a searchable Q and A layer for my career.

I vibe coded it.

How I got it live

I kept the stack simple.

Tools and software:

Claude. I vibe coded the whole thing
Anthropic API. Powers the chatbot responses
Vercel. Hosts the backend
Terminal. Deploys to Vercel
WordPress. Runs the website
TextEdit. Edits the backend code

At a high level:

I defined strict boundaries so the bot answers only from my documented experience
I built a small backend endpoint that calls the Anthropic API
I deployed it on Vercel
I embedded the chatbot into my WordPress site

Total time. A couple of hours.

That is the headline.

Low time cost means high experimentation velocity.

Why I’m now hooked

Since building the chatbot, I keep creating small programs and tools for my daily life.

Tiny automations. Micro dashboards. Small utilities that remove friction from how I work.

None of them are massive products. That is intentional.

They are:

Fast to build
Narrow in scope
Focused on one clear job

Every time I build one, I understand systems better. I think more clearly about constraints, data flow, and failure modes.

Vibe coding stopped being a trick. It became part of how I operate as a PM.

And I am honestly hooked.

Other vibe coding projects worth noticing

This is not just me playing with tools.

Look at builders like Pieter Levels, who uses AI to ship focused micro products quickly and iterate in public. His approach shows how small scope plus AI leverage can move from idea to live product fast.

Many indie AI builders stitch together LLM APIs, lightweight backends, and simple front ends to launch vertical tools without large teams. They validate first, scale later.

Reforge has leaned into AI prototyping and rapid experimentation in its advanced product programs, reinforcing that operators who can build small things move faster and learn more.

The pattern stays consistent:

Small scope
Clear problem
Fast release
Real feedback

That loop compounds product intuition.

What this changes in decision cycles

When you can build fast, meetings shrink.

Stakeholders react to artifacts instead of slides.
Feedback becomes concrete.
Edge cases surface earlier.

You stop arguing in abstracts.

Decision cycles shorten because evidence shows up sooner.

You do not replace engineering. You de-risk engineering investment.

All actionable takeaways, in one place

Start with one small tool that solves a real problem
Keep the scope tight so you ship in hours, not weeks
Add guardrails early so your AI feature stays trustworthy
Deploy something real and get feedback fast
Treat the first version as a learning probe, not a final product
Document what broke and what surprised you
Iterate before you overthink
Repeat the cycle until the signal gets clear

If you have a project idea or want quick feedback on something you’re building, I’d love to take a look. Reach out through benjaminlecam.info or message me on LinkedIn.

And if you’re curious about the small tools I’ve been building for myself, I’m happy to walk through them and share the process on a quick call.

Conclusion

Vibe coding is becoming essential for modern PMs because it collapses the gap between idea and artifact.

My chatbot on benjaminlecam.info is not a startup. It is proof of leverage.

In a couple of hours, using Claude, the Anthropic API, Vercel, Terminal, WordPress, and TextEdit, I turned an idea into a working product.

That speed changes how you think.
It changes how you decide.
It changes how you lead.

And once you experience that shift, waiting weeks for your first draft feels outdated.

Your Roadmap Is Not a Plan. It Is a Comfort Blanket.

I stopped building roadmaps about a year ago.

Not because I got lazy. Because I kept watching the same thing happen across every company I consulted for.

We would spend weeks building the roadmap. Color-coded. Quarterly. Beautiful. The kind of thing you print, hang on the wall, and feel genuinely proud of.

Then reality would show up. Unannounced. Usually on a Tuesday.

A competitor ships something unexpected. A key engineer leaves. Users start behaving in ways nobody predicted. And suddenly that gorgeous 12-month roadmap is just a very expensive piece of fiction hanging on the wall.

The moment that really got me was at a real estate software company I joined as a consultant. They had a roadmap. They had sprints. They had ceremonies for their ceremonies. They also had a product that was quietly losing relevance while the team was busy executing a plan nobody had pressure-tested with real users.

I asked a simple question in one of my first sessions. “When did you last sit down with an agent who uses this platform every day?”

Silence. Not the “we’re thinking” kind. The “oh no” kind.

The roadmap had become the product. The team was shipping features to satisfy a document, not a real estate agent trying to close deals. And nobody had noticed because everyone was too busy being busy.

Here is what I have come to understand after eighteen months of seeing this pattern repeat itself. A 12-month roadmap is a bet on a future you cannot see, written with confidence you should not have, committed to a timeline that will definitely change. And then everyone acts surprised when it does.

The best teams I have worked with lately do not operate this way anymore. They run short cycles. Six weeks maximum. One clear hypothesis. One measurable signal that tells them whether they were right. If they were wrong, they learn fast and adjust. If they were right, they double down. No drama. No wasted quarters.

I came across an article recently that stopped me mid-scroll. It talked about how companies like Slack have stopped committing to big fixed roadmaps entirely. They now run tiny cross-functional squads, sometimes just one designer and one engineer, using AI to prototype fast and get feedback faster. The piece called the traditional 12-month plan a liability, not a plan. After what I have seen in the field over the past year and a half, I think that description is actually generous.

Dropping the fixed roadmap costs something real. You lose the illusion of certainty. Stakeholders who need a 12-month plan to sleep at night will push back. Some will not let go easily.

But here is what you gain. Shorter cycles force real conversations with real users more often. Explicit hypotheses force the team to agree on what success looks like before they build anything. And teams move faster. Not because they are rushing. Because they are not dragging the weight of a plan that stopped being relevant three months ago.

The thing I learned, and genuinely did not expect, is that the roadmap was never really about the product. It was about managing anxiety. Leadership anxiety. Stakeholder anxiety. Sometimes PM anxiety too.

Once I understood that, the conversation changed completely. The goal was not to kill the roadmap. It was to replace the anxiety with something more honest. A clear problem to solve. A short bet on how to solve it. A real signal to know if we were right.

That is a plan worth building.

Three Product Managers Were Just Replaced by One Engineer With an AI Tool

Three PMs out. One engineer with AI in. Shipped faster. Costs down. Leadership satisfied.

Nobody outside the company noticed.

I heard this story at an online PM meetup last week. One of those Thursday evening Zoom calls where people are honest because no one’s boss is on the call.

Someone shared it. The room went quiet for a second.

Then everyone started talking at once.

What actually happened

When someone pushed for details, the picture got uncomfortable fast.

Those three PMs were spending most of their time doing:

Writing tickets
Summarizing Slack threads into Confluence pages nobody opened
Updating roadmaps that changed every two weeks
Translating what engineers said into what executives wanted to hear

That is not product management.

That is coordination theater. And AI does it better, faster, and for $20 a month.

The engineer who stepped in was not doing any of that. He was talking directly to customers, making calls, and shipping. The AI handled the documentation, the summaries, the spec formatting.

The output went up. The overhead went down.

But then the conversation shifted

A GPM on the call pushed back hard.

He said something that stuck: AI can write the PRD. It cannot sit across from a customer who is about to churn and figure out in real time that the actual problem is not the product. It is that nobody ever called them.

And he is right.

The PMs who are not losing sleep right now are doing the work AI cannot structure:

Making unpopular calls backed by data, not consensus
Holding context when the company pivots, a key engineer leaves, and a competitor ships in the same week
Reading between the lines of a NPS comment, a support ticket, or an awkward user interview
Owning outcomes, not just outputs

AI can generate fifty feature ideas. It cannot be accountable for whether they were the right fifty.

That accountability is what makes a PM irreplaceable.

The role is not dying

A version of it is. And honestly, good riddance.

The ticket manager PM is getting compressed into tools that cost less than a lunch.

What replaces it is harder, higher-stakes, and more interesting.

A PM who thinks like a founder.
Speaks the language of engineers.
Obsesses over customer outcomes.

That version of the role is not threatened. It is in demand.

The uncomfortable question the meetup ended on

The call wrapped without a real conclusion. People logged off with more questions than answers.

But one thing was clear.

The PMs who were scared could not clearly articulate what they did that AI could not replace.

The ones who were not scared answered that question before it was even asked.

The gap between those two groups is closing fast.

Which side are you on?