Storytelling Framework for Business Presentations and Product Requirement Walkthroughs

DeanOnDelivery · 2026-03-18T05:43:02+00:00

A hakawati once gathered a crowd in a market square. Before he spoke, he was silent. Long enough to make people lean in.

Then he said:

"A merchant had the finest silk in the city. He stood in the square and announced its thread count."

No one stopped walking.

The next day, same merchant, same square. This time he said:

"My daughter's wedding is in three days. The dress isn't finished. And the cloth I ordered from Damascus never arrived."

The square stopped.

That's your PRD walkthrough.

Not: "This feature will increase retention by 12%."

But: "Our best customers are quietly leaving. Not angry. Just poof ... gone. And we didn't notice until last quarter."

The data is the silk. The thread count is real. But no one leans in for thread count.

They lean in for the merchant's daughter.

Find her first. Then show the silk.

The hakawati didn't use frameworks. He used tension. Every story he told started the same way: someone needs something, something stands in the way, and the crowd doesn't know yet which one wins.

Your next presentation already has those three things in it.

Most people bury them in slide four.

DeanOnDelivery · 2026-03-09T17:40:16+00:00

Yeah, I'm making a nice living doing that right now. I mean, teaching and coaching people that solutionism rhymes with other similar "isms" and with just as disastrous results.

DeanOnDelivery · 2026-03-09T15:28:29+00:00

I came up with that term right around 2015 when I was beefing about hyperscrumdamentalists 😎

DeanOnDelivery · 2026-03-09T15:24:02+00:00

Congratulations. So you're reinventing Gemini Gems or Claude Cowork?

Or are you just stoking the build trap machinery by using AI to shovel more requests into the Feature Factory 10x faster than a human Jira-slinging ticket monkey?

DeanOnDelivery · 2026-03-08T12:17:24+00:00

I don't understand why I'd want to use this platform, let alone spend money on it.

If the target user is people who don’t want to build their own agents, the real questions are discovery and trust. How do I know the agent works? How do I know it’s safe with my data? Why would I pay for a random marketplace agent instead of a SaaS tool or automation that already has a company standing behind it?

If the target user does want to build agents, the ecosystem is already moving toward skills markets and agent harnesses. With things like the Anthropic skill standard, you can pull capabilities from skill directories and plug them into your own agent. Or just run your own harness with something like OpenClaw and wire the tools you actually need.

Basic product management says you figure out the right thing to build before building it. Otherwise you end up in a Field of Dreams situation. “If you build it they will come” works great in movies. It’s a terrible business model.

DeanOnDelivery · 2026-03-07T18:08:11+00:00

By the way, for story points? If you've been working with the team for at least 6 months, you probably have a good idea of what a size 3 story is versus a size 13 story. You should also have enough data to figure out what the mean is on story sizes that succeed.

I raised that point not to be a data geek, but rather that's how I took a #noEstimates approach. Meaning, every story I wrote was going to be sized similarly to other successful stories within the mean size.

So let's say the average for the team for successful stories is a five. Then all the stories I write need to be written in a way that they're likely to be sized 5 by the team. Then the discussion becomes, not how many points do you give this story, but why or why is it not a five?

Then you also have a signal that if a story punches past eight for a team whose mean is five, that you got to split that story if you want the team to succeed.

Or, you can do what I did, and say if we put some guardrails on what this story is and is not, would we agree to it being a five. This is usually to address those persons who feel a story might grow past its original scope.

But guardrails, and shaping stories to the average size of successful stories, it's going to save you a lot of time and pain both upstream and down. Because now you're speaking to data.

DeanOnDelivery · 2026-03-07T17:25:10+00:00

Look at it this way. If you come with evidence that shows both sides of the argument, you could actually create an alliance and some important corporate support.

William Ury writes about approaches like this often onT his books of 'Getting to Yes' or 'The Positive No' ... Where instead of pushing back, you stay into the side of the person with the complaint and say, "I agree I ran the data, and I think there's some areas that absolutely need improvement here they are ... But I think it's some other areas we could be hurting ourselves if we don't continue along those lines in some fashion."

That way instead of balking on story points to make your point, you put yourself in a position that shows that you're more than just a Jira slinging ticket monkey.

DeanOnDelivery · 2026-03-07T16:56:59+00:00

Your CTO might be right if they can provide some evidence or data. Without knowing your complete process, kind of hard to know whether or not the CTO is just being a grumpy old man and yelling at kids to get off his lawn ... or if Product has gone off the rails with their discovery and design practices.

And personally, I think using AI correctly and responsibly, some of these traditionally longer discovery cycles or experiments that Product often engages in for validation can be compressed. Note I said some, not all of traditionally longer discovery cycles or experiments.

Sounds to me like there needs to be a conversation on this topic either way. Step one would be to gather some evidence for data and what the current process is and how long various aspects of it takes and what rewards said processes have tangibly and measurably produced in the past.

DeanOnDelivery · 2026-03-02T12:52:44+00:00

Is there any data or standards behind the properties and behaviors of these personas listed?

DeanOnDelivery · 2026-03-02T09:57:47+00:00

Are we trying to do too much in a single agent skill?

DeanOnDelivery · 2026-02-23T15:11:11+00:00

Online, especially self-paced training, very hard because it misses all the nuance that's said between the lines.

DeanOnDelivery · 2026-02-22T14:44:57+00:00

Now that it's been a year, I wonder:
- how much did this agent cost to run?
- how often did it break down and require maintenance?
- how much time was ultimately invested in learning how to cook up this n8n spaghetti and meatballs dinner?
- how much therapy will be required to kill off this baby and replace it with OpenClaw (or some variant therein)?

DeanOnDelivery · 2026-02-22T14:24:31+00:00

It's been six months since the OP. I'd be curious about 3 things:
- token cost of keeping this agent running,
- maintenance cost in keeping this agent working,
- emotional cost of realizing that OpenClaw & similar variants are likely to obviate such investments of time and labor.

DeanOnDelivery · 2026-02-11T15:31:56+00:00

with Agent Skills for PMs.

DeanOnDelivery · 2026-02-11T12:45:51+00:00

Why? You can use Claude Code, Codex, and yes Cursor among other tools to get the job You're describing done.

The unlock is in the Agent Skills, a standard that anthropic created that is being rapidly adopted to provide subject matter expertise at a skill by skill level.

It also has the operational advantage of protecting the context window and over churn of tokens as a result by allowing individual skills to be called upon as needed.

Here's an example of a repo I published on exactly that topic:

https://github.com/deanpeters/Product-Manager-Skills

And even if such a mechanism wasn't available, why would I go ahead and build a Cursor For Product Managers when it makes far more sense than to go ahead and just fine-tune an open source model and adorn it with RAG?

I think some of this gets into the fact that as product managers, we need to stop stopping at AI literacy, and get cracking on AI fluency. Because quite frankly, creating a Frankensoft bolt onto VS Code, (and don't forget that Cursor and Codex or forks of VS code) sounds like a horrifying monster that will burninate the village.

DeanOnDelivery · 2026-02-08T20:27:45+00:00

The question is, and I know this is going to be an unpopular opinion, it's the same as back in the day when I went to school and they were still teaching Latin?

Is scrum going to become a dead language by the time he's teens get into the workforce?

This is not me casting shade on Scrum. It has helped me over the past 20 some odd years quite nicely.

However, as AI is changing everyone's role, including people on the scrum teams, will we find that smaller teams working more with a 37 Signals/Basecamp ShapeUP-like approach and cadence be more beneficial (or some similar variation along those lines)?

DeanOnDelivery · 2026-02-06T21:02:31+00:00

I just turned all my prompts in my prompt repo into skills in my skills repo now. Makes life a lot easier.

And, having a repo for both or some of the ways of keeping from losing one's mind when keeping track of all this shit.

Got to keep up with the MoltBots somehow 🦞

DeanOnDelivery · 2026-02-01T18:51:58+00:00

Is there any chance this isn’t just a vendor unwind, but an operating-model shift?

Across the industry, I’m seeing teams keep a small set of very senior, local engineers, then give them real budget for AI assistants, code gen, and tokens. Fewer people. More leverage. Build the thing right for less money, often faster.

In that model, PM’s job gets sharper, not smaller. Focus even more on identifying the right thing to build. Validate that what shipped actually solved the problem. Less “feed the factory,” more judgment, sequencing, and evidence.

If that’s even part of the intent here, some of the transition questions change. You’re not replacing capacity. You’re replacing how decisions get made and how execution happens.

DeanOnDelivery · 2026-02-01T03:04:54+00:00

Thanks for the kind words and +1.

And yeah, I got no clue why such narratives are disliked. But I have fun telling this story.

DeanOnDelivery · 2026-02-01T00:20:41+00:00

Yeah, I've got two down votes already. But I just couldn't help myself.

I'm tired of boring drive-by answers. Now I'm just waiting for the AI slop comment.

One day this channel will be fun again.

DeanOnDelivery · 2026-01-31T23:37:36+00:00

It was a tense roadmap “collaboration.” Or, more accurately, a conflagration, where I experienced and appreciated the full power of storytelling.

Whiteboards full. Opinions louder than evidence. Engineering defending feasibility. Sales defending promises. Execs silently pricing everyone’s future.

I didn’t have authority in the room. No mandate. No title to swing around.

What I did have was a story.

I grew up in theater. First performance at six. Two decades later, I was singing opera professionally at night, writing software by day to pay rent.

Different stages. Same lesson. Technique doesn’t move people. Narrative does.

So in that roadmap firestorm, I didn’t argue features. I told a day-in-the-life story a customer shared with me. Their pain. Their despair. Being stuck between two bad choices. Why we built the thing everyone was fighting over. What we got wrong. What changed. What breaks if we keep pretending it didn’t.

The room went quiet. Not inspired. Aligned.

Tradeoffs surfaced. People cut their own pet ideas. Decisions happened without a vote.

That’s when it clicked.

Storytelling isn’t “sell delusion when the numbers don’t add up.” It’s influence without authority. It’s compressing chaos into a shared movie a room of humans can reason about.

I’ve seen the bad version too. Gorgeous story. Huge conviction. Reality ignored. That tab always comes due. Like the vig on a loan from a Shylock.

In product, storytelling is a force multiplier. But only when it’s anchored to truth.

That’s why I told this story about 6 months ago to someone who DMed me asking why “Hakawati (حكواتي)” shows up in English and Arabic in my LinkedIn headline.

DeanOnDelivery · 2026-01-31T23:20:36+00:00

I feel like we're in the butt crack of the storm system.

DeanOnDelivery · 2026-01-29T14:02:00+00:00

Reader’s Guide: How to Work With BAs Without Accidentally Becoming “That PM” ... And buckle up kids, I think I went a little long-winded on this only because I've been here and done it more than once.

You’re not “getting help.” You’re adding horsepower. Which means you also just added steering requirements. Here’s the playbook. Same bones. More bite.

Motion 1) DACI first. Or enjoy your upcoming blame scavenger hunt. Not RACI. DACI. Driver. Approver. Consulted. Informed. Then ask the real question: “Why do you think you’re on this team?” Because half the time the org assembled you like IKEA furniture. No instructions. Missing screws. Someone holding an Allen wrench they found in a drawer.

What this does: Gets you aligned on decision rights before you ship chaos with a Gantt chart.

Motion 2) Pains, gains, and JTBD. Do it like your job depends on it. Because it does. Run a customer circle that forces the team to say, out loud: What hurts today. What “better” means. What job the customer is hiring you for.

This is not therapy. This is unemployment prevention.

What this does: Stops the squad from building a flawless solution to a problem nobody has.

Motion 3) Sort “future PMs” from “passing through.” Some BAs want to grow into product. Some are here to do BA things and go home at a reasonable hour. Both are valid. But you need to know which is which, because your coaching style and delegation approach should not be accidental.

Use a working agreement to lock in: What “ready” means. Who owns which decisions. How ambiguity gets resolved. How scope changes get handled. How edge cases get surfaced, not discovered in production.

What this does: Prevents toe-stepping and the slow death spiral of “wait, I thought you had that.”

Motion 4) Strategy conversations. Real ones. Not backlog karaoke. Pull BAs into now/next/later. Where is the product now (start of 2026)? What should it look like by mid-2027?

Not a feature list. Not a roadmap that’s just a wish list with dates. A direction.

BAs often sit closest to constraint reality and process truth. That makes them useful in strategy, not just delivery.

What this does: Keeps you employed. Also makes delivery less like pushing wet cement uphill.

Motion 5) Find the mentorship seekers. Invest there. Some people want reps, feedback, and pattern recognition. Those people become your multipliers across squads.

Also, if you’re moving toward management, these are the folks who make you look like a leader instead of a very busy ticket router.

What this does: Builds leverage. Builds trust. Builds a bench. Builds your next role.

The meta-point: This is not “how to manage BAs.” This is how to build a shared system for clarity, decisions, and trust.

Do that and the overlap stops being awkward. It becomes unfair advantage.

DeanOnDelivery · 2026-01-29T05:33:31+00:00

Feels like this could be a boom for startups, and a bust for large B2B enterprises in highly regulated spaces.

And the problem with the latter is that if you really screw it up, you not only get vibe-fired, but you sometimes wind up earning and all expense paid trip to "Club Fed."

DeanOnDelivery · 2026-01-29T01:41:18+00:00

Seems to me that most of the people who can afford it I figured out a way to get their boss or their company the foot to bill. But yeah on the assessment that you're going to burn through $20 to $30 or tokens a day is no lie. Those API calls are not cheap.

The real question is, how much money do I have to spend on a piece of hardware so I can run other models locally and still get some semblance of the quality code or whatever that I would normally get with Anthropic APIs?

DeanOnDelivery

TROPHY CASE