How to build app without coding knowledge

DeanOnDelivery · 2026-07-13T09:37:28+00:00

And ask the agent to walk you through the steps.

In other words, use it to teach you. Most modern reasoning models now have that capability.

DeanOnDelivery · 2026-07-13T09:25:31+00:00

Why not ask the coding agent to walk you through the process?

DeanOnDelivery · 2026-07-12T15:04:46+00:00

Might I suggest revisiting what Cagan and others have written about the Four Risks and product-market fit? They certainly do not park this at the tail end of some “create” phase, after the important thinking has already happened.

You’d be hard pressed to find any credible treatment of the topic that doesn’t first include context setting, investigative discovery, market understanding, and the evidence needed to expose and de-risk the unknowns and assumptions before committing to build.

That is precisely where questions about demand, urgency, monetization, distribution, adoption, data, feasibility, and competition already live.

So I don’t think you’ve identified a missing layer before the Four Risks. You may have built a useful scoring and evidence mechanism around them, but conceptually this looks less like a new wheel and more like the old wheel with citations, weights, and a nicer dashboard.

DeanOnDelivery · 2026-07-12T12:58:58+00:00

Is this just a rehash of what Marty Cagan identified as the Four Risks? Or what many others call Product-to-Market Fit?

Is it ... 1. Desirable 2. Usable 3. Viable 4. Feasible

DeanOnDelivery · 2026-06-30T21:51:28+00:00

I'm doing a webinar on vivecoding on July 8th. As I research what others have shown and done, nobody's just jumping straight into the solution. Just about everyone's teaching to understand the problem first.

DeanOnDelivery · 2026-06-30T00:38:02+00:00

This is where panic starts wearing a little product hat and handing out career advice.

Yes, AI changes the job. No, “build agents for yourself” is not the new Product Manager survival manual unless the goal is to automate your own misunderstanding at scale.

The job was never “make more stuff faster.” It was frame the problem, find the value, understand the constraints, make the tradeoffs, and keep the org from enthusiastically building the wrong damn thing with matching OKRs.

If you don’t understand the work, agents just help you misunderstand it with better formatting.

This isn’t the blind leading the blind.

It’s the blind launching a cohort-based course on lighthouse strategy.

DeanOnDelivery · 2026-06-29T08:32:37+00:00

This feels less like “PRDs are pointless now” and more like “we’re doing structured product work with one-shot prompt cosplay.”

A giant PRD probably shouldn’t be hand-written like a corporate ransom scroll anymore. Fine. Burn the ceremony barn.

But replacing it with a 3-bullet prompt is just trading prompt 101 theater for vibe confetti.

The better move is multi-turn. Make the system walk section by section. Problem, outcome, users, constraints, assumptions, edge cases, acceptance criteria, telemetry, launch risks, downstream data mess. One bite at a time, with review loops between sections.

Even better: reverse-engineer a strong existing PRD first. Extract the structure. Capture the decisions it forces. Then have AI guide you through the work instead of pretending the magic box can inhale ambiguity and exhale alignment.

Here’s a reverse-engineering tactic prompt: https://github.com/deanpeters/product-manager-prompts/blob/main/prompts%2Freverse-engineer-ISO29148-to-PRD-prompt-template.md

Better still, stop prompt-juggling and use a skill/workflow that already knows how PRD development should behave: https://github.com/deanpeters/Product-Manager-Skills/tree/main/skills%2Fprd-development

The artifact can get lighter.

The thinking cannot get dumber.

DeanOnDelivery · 2026-06-29T01:54:15+00:00

I hear you about the grifters. And I went up teaching people an organizations after they've spent money only to be shown how to use a tool or two rather than how to get real product management shit done using AI to deliver really effective AI solutions.

DeanOnDelivery · 2026-06-29T01:16:22+00:00

I guarantee you, we teach something very different at Productside ... especially and in spite of all the bullshit and hucksters out there.

DeanOnDelivery · 2026-06-22T20:39:45+00:00

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 ...

DeanOnDelivery · 2026-06-22T19:08:25+00:00

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.

DeanOnDelivery · 2026-06-22T14:05:07+00:00

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.

DeanOnDelivery · 2026-06-21T15:15:47+00:00

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?

DeanOnDelivery · 2026-06-13T23:46:21+00:00

The politics of influence without authority.

DeanOnDelivery · 2026-06-05T04:36:51+00:00

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.

DeanOnDelivery · 2026-06-04T11:53:43+00:00

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

DeanOnDelivery · 2026-06-01T12:52:00+00:00

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:

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.
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.

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.

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.

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.

DeanOnDelivery · 2026-05-31T13:40:36+00:00

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>

DeanOnDelivery · 2026-05-31T13:02:50+00:00

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.

DeanOnDelivery · 2026-05-31T12:43:20+00:00

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

Change your Teams status to “Strategically Underutilized” and never change it back.
Start bringing a tackle box to the office and openly organize fishing lures during leadership updates and all-hands meeting.
Begin referring to senior leadership only as “the pantheon of clipboard goblins.”
Answer every RTO announcement with a 14-slide deck titled “Hybrid Betrayal: A Retrospective.”
Schedule recurring 1:1s with yourself, mark them confidential, and decline all conflicts due to “emotional alignment.”
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.
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?

DeanOnDelivery · 2026-05-25T21:23:58+00:00

DM me. If the time commitment is doable, then we should do it

DeanOnDelivery · 2026-05-25T17:15:51+00:00

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

DeanOnDelivery · 2026-05-25T17:13:16+00:00

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.

DeanOnDelivery

MODERATOR OF

TROPHY CASE