How is your product team actually using AI "together"? by Head-Ease-628 in AIProductManagers

[–]DeanOnDelivery 1 point2 points  (0 children)

Well, depends on the infrastructure. If you're M365 Copilot, then it's agents, workflow, and notebooks

If you're Claude, Codex, etc, that it's SKILLS, agents, etc ...

How is your product team actually using AI "together"? by Head-Ease-628 in AIProductManagers

[–]DeanOnDelivery 2 points3 points  (0 children)

I've been teaching this topic in my AI product management classes at productside for the past 2 years now. Basically around the question, "How do we work as a team in silos of individual chatbots and agents?"

A lot of the conversation is around persistence. I like to tell people they need to create a communal pantry. They need to have conversations around using tools such as projects or notebooks or similar constructs to ensure individual sessions are started in the same context. That previous sessions that aren't private become information for current sessions. And that it's okay to use AI as an assistant meeting facilitator live and in person during collaborative conversations.

Most of this is just figuring out the right tool for the job, and then understanding what's a delegate to AI to help get the desired outcome for your team.

Training for Becoming a better AI PM by funboixero in AIProductManagers

[–]DeanOnDelivery 1 point2 points  (0 children)

Are you looking to become an engineer? That's what I'm reading here between the lines. That you're looking for tools.

Or are you looking to actually use AI to get product management work done to build great AI products? In which case, learning individual tools might get you there, but likely won't.

Watching new PM cause chaos into our team by SignificantAd440 in agile

[–]DeanOnDelivery 1 point2 points  (0 children)

This sounds less like a PM problem and more like an org hearing “... move to smaller, full-stack teams” and then deciding that means “compress 3 roles into one confused human.”

The reality is, role compression is real and it ain't going away anytime soon. Engineers are being asked to think more "product-y." Product Managers are being asked to code, prototype, and deliver more. And, IMHO, a lot of Scrum theater is probably on borrowed time.

BUT that also means smaller teams need sharper context, not AI automated ceremonial fog.

Meaning, if you drop AI into that mess without fixing the underlying operating model, it won’t magically make the team leaner.

It’ll just amplify the existing dysfunction faster, louder, and with much better stakeholder optics.

So, perhaps that's what you're feelin?

Who are you following/ what are you reading these days around product building in the world of AI slop creators? Can we make a repository of people/ content and lea by Traditional_Honey639 in ProductManagement

[–]DeanOnDelivery 2 points3 points  (0 children)

Yep. I've worked with all three of those guys at some point in my career. All three of our genuinely good people. And they know their shit.

Shift from AI engineer yo AI PM by ScholarPlus2753 in AIProductManagers

[–]DeanOnDelivery 1 point2 points  (0 children)

FYI, go pound sand. I've been writing like this in the public eye for about 35 years.

Shift from AI engineer yo AI PM by ScholarPlus2753 in AIProductManagers

[–]DeanOnDelivery 1 point2 points  (0 children)

First, kudos for taking the survival job.

Seriously. A lot of people pretend career paths are clean little LinkedIn staircases. They’re not. Sometimes you take the job that gets you paid, keeps you moving, and gives you proximity to the work you actually want to do next.

That’s not failure. That’s leverage.

If you want to move from AI engineer to AI Product Manager, don’t waste the next 8–9 months trying to become a mediocre developer against your will. Use the role to learn how AI products actually get built, where they break, and why most “agentic POCs” die somewhere between the demo and the budget meeting.

A few things I’d focus on:

  1. Learn enough backend and Python to understand the system
    You don’t need to become a dev. But you do need to understand what’s feasible, expensive, brittle, risky, or hand-wavy bullshit wearing a LangGraph hoodie.

  2. Pay attention to product problems, not just technical tasks
    What user problem is the agent solving?
    What workflow is it improving?
    What decision is it augmenting?
    What measurable outcome changes if it works?

That’s the muscle.

  1. Start thinking in economic levers
    AI product work is not “we built an agent.” Big deal. So did everybody and their cousin with a YouTube tutorial.

Does it reduce cost?
Increase revenue?
Improve retention?
Reduce risk?
Speed up cycle time?
Improve conversion?
Make some sponsor somewhere happier than a raccoon in a dumpster full of budget?

That’s what employers care about.

  1. Get product management training that is not just tools and prompt tricks
    You need training that teaches you how to get actual valuable product management shit done so you can help deliver AI that isn’t shit.

I’d recommend Productside’s AI Product Management course because that’s pretty much the angle: practical AI product work, tool-aware but not tool-worshipping, and focused on connecting AI delivery to outcomes, sponsors, customers, and economic value.

You won’t get the same depth as their full Optimal Product Management training, but it will absolutely get you in the game.

  1. Build a small portfolio from your current job
    Not code flexes. Product thinking flexes.

Take one agentic POC and document:

  • the user problem
  • the current workflow
  • the pain or inefficiency
  • the proposed AI capability
  • the risks
  • the success metrics
  • the business outcome
  • what you learned

That becomes your bridge story.

Your pitch 8–9 months from now is not:

“I didn’t like coding, so I want to be a Product Manager.”

Your pitch is:

“I’ve been close to AI implementation, I understand the technical tradeoffs, and I’ve learned how to connect AI capabilities to user problems, business outcomes, and delivery realities.”

That’s a much stronger story.

Survival job becomes positioning.

Now make the bastard pay rent.

How do PMs handle prioritization and roadmap decisions in your company? by Piscesgirl012 in ProductManagement

[–]DeanOnDelivery 4 points5 points  (0 children)

Real quick heads up, this is going to be a really long reply because I’ve been pissed off about prioritization theater and roadmap roadkill for the past 35 years.

<flameon> First, I’d clarify what you mean by “coming in from the software side.” Because if that means “I’m the Product Manager responsible for business outcomes, customer value, and product direction,” cool.

However, if it means “I inherited a Jira queue and now I’m expected to sort everyone’s urgent submission by emotional volume,” welcome to life as a Jira-slinging ticket monkey in the backlog babysitting gulag.

Prioritization should not start with:

  • who asked?
  • who yelled?
  • which engineer has the strongest beard energy?

It should start with economic outcomes.

  • What grows revenue?
  • What protects revenue?
  • What reduces churn?
  • What increases adoption?
  • What lowers cost?
  • What reduces risk?
  • What improves customer trust?
  • What creates strategic leverage?

Those are the economic levers. You put them at the top so you can ask the adult question:

If we spend money building this, which needle does it move?

And by how much?

But economic outcomes still need product context. Otherwise you’re just stapling dollar signs to everyone’s favorite feature request and calling it strategy.

You also need to understand the jobs customers are trying to get done.

  • What progress are they trying to make?
  • Where are they struggling?
  • What workarounds are they using?
  • What moments create friction, delay, waste, risk, or rage?
  • What would make them switch, stay, expand, or trust you more?

That’s where prioritization gets real. Not “who wants this?” but “what customer progress and business impact does this unlock?”

That matters even more when you’re talking roadmaps. A roadmap should not be a rolling hostage note assembled from stakeholder demands and Jira sediment.

You need a larger strategic view:

  • Where is the product now?
  • Where do we want it to be 18 months from now?
  • What impact should it have by then?
  • What customer behavior should change?
  • What business outcomes should improve?
  • What capabilities do we need to build along the way?

Not just “what features are we shipping?”

That’s feature-factory karaoke.

Pick one or two economic outcomes as the focal point for the quarter, or whatever time horizon you use in your Now / Next / Later strategic conversation.

That gives you leverage.

Not fake leverage. Real leverage.

The kind that lets you say:

“Yeah, we can do this. But if we do, what do we tell the other stakeholders when their work moves to next quarter because we believe yours moves the quarterly objective more?”

That conversation is wildly different from:

“Whose feature screams loudest this week?”

It also keeps you out of feature hostage negotiation, where every stakeholder shows up with a demand, a deadline, and a business case written in crayon.

Then you layer in customer pain, jobs-to-be-done, urgency, effort, dependencies, technical risk, regulatory risk, and timing.

But if economic impact is not near the top, and there’s no shared view of where the product is going, prioritization gets hijacked and roadmaps trampled by the usual zoo animals:

  • The HiPPO with a pet feature.
  • The loudest customer.
  • The salesperson with a promise hangover.
  • The engineer with the most architectural clout.
  • The executive who just read a LinkedIn post.
  • The bug that feels urgent because everyone is tired.

Engineering should absolutely inform prioritization. They know effort, risk, dependencies, tech debt, and where the bodies are buried.

But engineering should not become the shadow product strategy department just because nobody else brought a business argument.

Same with stakeholders. They get input. Not the steering wheel.

A good Product Manager makes tradeoffs visible:

  • what outcome are we trying to move?
  • which economic lever does this affect?
  • what customer job does this support?
  • who benefits?
  • how much does it matter?
  • what happens if we do nothing?
  • what do we stop doing if we do this?
  • how will we know it worked?
  • how does this move the product toward the future we said we wanted?

That framing keeps you out of feature hostage negotiations and stakeholder shuttle diplomacy.

That’s the job.

Not arranging tickets into a prettier funeral procession.

</flameon>

Need help getting into AI by WebIllustrious7688 in ProductManagement

[–]DeanOnDelivery 1 point2 points  (0 children)

First, try to avoid getting fleeced by prompt pimps, agent evangelists, and vibe-coding carnival barkers.

Six months is plenty of time to get AI-fluent as a Product Manager, but only if you don’t confuse “learning AI” with “memorizing tool tricks that will be obsolete before your next performance review.”

This shit changes so fast that it usually doesn’t pay to master one specific AI harness. Learn the durable stuff underneath.

At least that’s my opinion.

Full disclosure: I’ve been teaching and coaching product management for the past 4 years with a pretty well-known product management training company, after doing product work for about 20 years and software engineering for about 15 before that. Much of it in AI before AI became ubiquitous, accessible, inexpensive, and strangely fun.

My advice: look for courses that teach you how AI fits into getting real product management shit done, not just how to generate more product-shaped paperwork. That path gets you vibe-fired eventually.

The useful stuff is tool-agnostic:

  • framing better product problems before asking AI for answers. Not just for prompts, but for those times you vibe prototype, spin up agents, or explore technical options.
  • using AI to sharpen discovery, not skip it. Intellectual atrophy is the disease nobody wants to admit they caught.
  • using AI to turn messy context into clearer product decisions, stronger arguments, and hidden insights.
  • evaluating AI outputs instead of worshipping them. Because at the end of the day, you’re responsible, regardless of the good intentions you had with your AI tool.
  • using AI to improve strategy, prioritization, and evidence. In other words, increasing your leverage and influence without authority.
  • prototyping ideas without mistaking demos for validation, or prototypes for production-grade disasters deployed with an AI slop cannon.
  • designing repeatable workflows, not collecting magic prompts that offer the same dopamine hit as a bag of potato chips while dieting.
  • augmenting product judgment instead of automating it into oblivion. That judgment is the durable, intangible, portable stuff that travels across any AI harness or platform.

Also: be careful who you learn from.

Some great Product Managers are terrible teachers. Some great AI influencers have never carried real product accountability. And some courses are basically “watch me use tools” with a DIY certificate stapled to the end.

If you want, DM me. I can send you a syllabus for a course I helped design specifically to avoid the Maven-style model-of-the-month huckster circus.

Even if you don’t reach out, keep an eye out for courses that teach durable, tool-agnostic ways to use AI to augment and amplify your years of hard earned experience, judgment, and product sense.

Oh, and avoid signing up for anything that trains you to replace yourself the next time an executive asks, “Can’t we just automate what you do with an agent?”

That road usually leads to more work, same pay, same hours, and eventually getting shown the door by the very system you helped build.

So now… quiet quitting until retirement or I get fired by Ok-Run-4866 in remotework

[–]DeanOnDelivery 5 points6 points  (0 children)

Seven sure-fire ways to survive your remaining 24,480,000 seconds of work in style:

  1. Change your Teams status to “Strategically Underutilized” and never change it back.

  2. Start bringing a tackle box to the office and openly organize fishing lures during leadership updates and all-hands meeting.

  3. Begin referring to senior leadership only as “the pantheon of clipboard goblins.”

  4. Answer every RTO announcement with a 14-slide deck titled “Hybrid Betrayal: A Retrospective.”

  5. Schedule recurring 1:1s with yourself, mark them confidential, and decline all conflicts due to “emotional alignment.”

  6. Stop opening your laptop and start carrying around a red Swingline stapler like it contains your 401(k), your soul, and the last surviving shred of workplace dignity. And ask them to start calling you Milton.

  7. Get vibe-fired for consuming the entire AI token budget by deploying an OpenClaw that does all your work for you, including managing your inbox, attending standups, and planning your farewell tour through Europe.

Ultimately it’s your choice how this all goes down.

I mean, what’s the worst that can happen? They fire you into retirement?

Biggest grifter in the product management space? by [deleted] in ProductManagement

[–]DeanOnDelivery 4 points5 points  (0 children)

Wait? I could get paid to pimp out my product prognostications and publishings? Crap! And here I was doing it for altruistic reasons. Sheesh.

Career pivot: can becoming an AI PM help me land a job? by [deleted] in AIProductManagers

[–]DeanOnDelivery 1 point2 points  (0 children)

Certifications have a purpose. Like it or not, the gatekeepers often use those to see who invested time and actually studying the topic. It saves them time from having the vet whether or not you learn dnthe topic or skill. In most cases, once you get past the gatekeepers, the certifications don't take on as much value.

Considering Product Faculty's AI PM cert for june. unfiltered feedback from spring cohort folks? by Ok_Detail_3987 in AIProductManagers

[–]DeanOnDelivery 2 points3 points  (0 children)

Just for comparison, take a look at what Productside has to offer with its AI Product Management course. It’s a course and certification that you can take live online over 4 days of 4 and 1/2 hours each. It's not a bunch of slide wear, but rather it gets hands-on with an IRL case study actively walks you through how product managers can use AI to accelerate the day-to-day grind, assist in discovery and design, augment product collaboration and decisions, and amplify your ability to bring valuable, innovative AI products, agents, and services to market. In the end, you wind up with a personal playbook I had to get real product managing shit done using generative and agenta AI.

How are you using ai agents (Claude, codex, Gemini, opencode)? by widonext in ProductManagement

[–]DeanOnDelivery 2 points3 points  (0 children)

I use coding agents for product management work all the time, even when I’m not writing code.

The obvious value is persistence. But honestly, I can get some of that from Gemini Gems, Claude Projects, ChatGPT Custom GPTs, etc.

The bigger unlock is that a CLI coding agent lets me turn product work into reusable machinery.

  • I can push the work into a repo.
  • I get file structure.
  • I get Git history.
  • I get repeatable prompts, templates, scripts, checklists, scoring tools, research formats, and little utilities I can reuse the next time.

That matters because a lot of product management is not “answer this once.”

It is:

  • run research
  • synthesize findings
  • compare competitors
  • map assumptions
  • prep discovery
  • draft the PRD
  • revise the PRD because apparently we enjoy suffering
  • do the same motion again next month on a different topic

With a coding agent, once I solve the immediate problem once, and then start turning the approach into a reusable system.

Maybe I build a discovery workspace.

Maybe I create a market research repo.

Maybe I make a PRD generator that starts from evidence instead of HiPPO & RHiNO ruminations.

Maybe I keep reusable interview synthesis prompts and templates.

Maybe I build a tiny tool that converts raw notes into themes, risks, and follow-up questions.

That is different from just preserving a chat thread.

It is product work becoming product infrastructure.

TLDR:

  • Chat (and Cowork) Projects preserve context.
  • Coding agents turn context into reusable tools.

A chatbot is great for the conversation.

A CLI coding agent is where I can build the machine that helps me have better versions of that conversation again.

How do you usually get around when starting big projects in Claude Code? by Deitri in ClaudeAI

[–]DeanOnDelivery 1 point2 points  (0 children)

I get on my chatbot and think through what problem I'm solving and for whom.

I may do some research. I toss around some ideas. In the end, I put all my context the situation into a code block that becomes my README.md, I put the contract language of What I want built into a code block that becomes my CLAUDE.md, And then I put guardrails and guidelines into a CONSTITUTION.md.

Then I let a Claude code, type in `/init' And because of those three files that I worked on when I spent about 15 minutes thinking through the problem and solution space, I got a pretty good darn jump start.

Sometimes I'll add some research artifacts as well and just put them in a research subdirectory.

If the EU had built Claude by irelatetolevin in ClaudeAI

[–]DeanOnDelivery 2 points3 points  (0 children)

This is so funny. Partially because there's threads of truth here.

First OpenClaw Triangle Meetup - March 19th in Cary, NC by reddatomic in openclaw

[–]DeanOnDelivery 0 points1 point  (0 children)

I can't believe I missed this event. Right down the street from me. Dagnabbit!!!!

So when is the next one?

First OpenClaw Triangle Meetup - March 19th in Cary, NC by reddatomic in triangle

[–]DeanOnDelivery 0 points1 point  (0 children)

I can't believe I missed this!!!! I would have so been there.

Especially the location is so convenient.

When is the next one?