Making agents work

Applying Work, Friction, and Waste to our human-AI allocation // officially retiring the DeejDrone 9000 😢

This is the last post in a three-part series on which parts of work are valuable. It started with creating a ridiculous biodiesel drone to show how AI can generate perfect-looking garbage, then updating the Work-Friction-Waste framework to spot which activities actually matter.

Now, let's put it all together to figure out how to actually use agents without destroying what makes your team valuable.

If agents can't replace PMs, what can they do? Lots, as it turns out. Just not what you'd expect from following the hype train.

The Work of PMs

So, we know how Work works, and we know the PRD isn’t the Work, but the Friction, for the PM. What does that mean for the VP who wants to assign agents as PMs?

Good news and bad news. Bad news first: you still need PMs.

The danger of replacing PMs with agents - at least in this scenario - is threefold:

1. The agent making PRDs is not doing the Work. It’s handling the Friction (which - can be a good thing! But more on that in a sec).

2. The person prompting the agent is imposing all of their biases onto the agent, and disguising those biases as good ideas with rigor and research. (Like I did with the DeejDrone 9000). The key insight here is that none of my ideas were any better after they were put into the PRD than they were before: I didn’t do any Work to validate anything. But now that they’re in PRD format, it’s way harder to tell that they’re terrible. Friction that doesn’t carry any Work is Waste, by definition.

3. To top it all off, because we’ve replaced all our PMs with agents, the only people who can see through my PRDs and tell that they don’t have any merit are the people we let go. We lost our BS detectors, so we can’t tell when we’re lying to ourselves anymore¹.

But let’s say I know PRDs aren’t the end goal of a PM. Can I train an agent to be a PM if I open up the scope?

Again, probably not, not yet. Agents aren’t great at the Work PMs do. It takes some savvy to handle discovering the Voice of the Customer and reading between the lines, and humans tend to be more effusive and expressive in front of other humans. (Ever “interviewed yourself” for a job with one of those automated video systems, or trialed one you were considering using? You’re not likely to “warm up to the interviewer” during the process; people still like talking to other people).

You need the LLM to have a thesis, interrogate the thesis, and subtly test their thesis while also looking out for “unknown unknowns” during these conversations… but the state-of-the-art realtime voice call agents these days tend to be just a little better than call center phone trees.

PRHs and Product Gap Agents

Good news: agents can still help, a lot. There’s a ton of ways to throw agentic automations against Waste and Friction in the average Product org, but for this conversation, we followed the PRD thread specifically.

First: low-hanging fruit. PM comes back from their customer interviews with notes, dumps them into an LLM, and the LLM summarizes them into PRD format. That’s not agentic behavior by any means, but it’s still pulling Friction out of the PRD process, assuming you can fact-check in less time than writing the document outright.

But let’s get more creative and find more value. Start from the point where your PMs go talk to customers and work backwards. The output of all of that is going to be a PRD; but is there a utility to having a PRD as an input too?

I could see it - for the sake of argument, let’s call it a PRH - a Product Requirements Hypothesis:

1. Try this out: take the exact same format, but fill it in based on your initial best guess - what do you think the right answers are going to be? Generate a PRD as though you knew the right answer based on your “day zero” knowledge - using an agent to research across the enterprise’s data sources - and then react to it. Do the details and assumptions and logical conclusions match what you expected?

2. Iterate on this and expose what would make your hypothesis wrong explicitly in the document. This step is key: otherwise you’re just biasing yourself, poisoning your own well. The end state for a PRH is not a draft PRD - you’re gonna redo all of this - but an experimental survey design that explains exactly what you think the options are for each element of the product design, the sensitivity and impacts of each decision change, and the things you want to listen for and explore in conversations.

3. The final piece of the PRH is the customer inventory - the conversations that you want to have that could get at the level of detail you’re looking for. Again, an LLM can help you run through CRMs or CX datasets to check for specific info, or at least give you guesses that you can react to and reject or edit. You’re looking to get more prescriptive on who to talk to - rather than “whoever my CSMs proffer up” - so you can test really specific elements of your hypothesis (or, also interestingly, find out that the things you expected to find aren’t as easily-discoverable as you hoped)².

4. This would result in - in my experience - way more prep for customer conversations than most PMs walk in the door with³. If you’re sitting there testing for both high-level questions and a bunch of little details that you wouldn’t have thought of but could materially affect the end picture, the agent’s done a lot of actual Work helping you prime yourself to extract Customer Voice from what could be otherwise less-structured conversations⁴.

Ok - then let’s go one step earlier. How do I prime a PRH? Again, I really don’t want to set up a system where I take my innate biases about the product or the business and polish them up so that no one else can tell that they’re hollow and backed by nothing. I’d love to set up chains of events that feed me good triggers and data to inform my hypotheses: my agents should be setting me up for success.

The #1 place that this breaks down in most customer orgs is the product gaps process. Product gaps reporting is often sketchy at best, even among companies that design products for reporting product gaps! The feeds of information are inconsistent, the identity deduplication is rare, the supporting data is scarce, prioritization is done by squeakiest wheel, and at a certain length of backlog no automated gap feed is actually entering the working memory of any team member until a long-overdue-hygiene process goes through and flushes months-old cards off the board.

But an agent, operating in the right environment with the right framework, could do a couple interesting things:

1. They could (obviously) feed and organize new product gaps into the right streams at the right times. That’s easy. That’s not even agent work - that’s API + WHERE statements, maybe embeds to make the sorting less fragile.

2. They could reference existing projects or PRHs and ask requestors or gap filers targeted questions at the time of filing - what was the source of the bug? Where does the enterprise customer want this API to feed into? You filed 12 P0 gaps - if I can only do 3 this quarter, which ones would you vote for⁵?

3. They could build and maintain profiles on the requestors - both the internal parties, and the actual end requestors (the customers, the Twitter personalities, the vendors, the partners) to build context over time, so that gaps get richer over time. Lots of folks have pined wistfully for the opportunity to do this over my career, basically no one has the time to do it. Prime agent work - stuff humans can only conspire but to dream of because they have actual shit to do.

4. When it comes time for customer interviews or CABs, agents can shortlist the requestors (filtering for things like red accounts and churn) closing the loop on the information pull⁶.

My prompt to the VP at this point - how do you go one step before this? How do you use agents to prime a product gap process that feeds you great information and returns great sentiment? I won’t go into the answers here: I think the point’s been made and the ideas here start getting very tactical and very real. It’s much more exciting and useful than I, PMBot: the energy in the room is different because we’re targeting real problems with precise solutions instead of employing unguided AI for its own sake.

Bias for action

I want to close on a note my cofounder Deji brought up when we were discussing this concept. He mentioned his initial gut reaction: doesn’t this push back against conventional startup wisdom to just go do something?

There’s the classic cliche “bias for action.” Brian Armstrong famously put this as “action generates information” - when you’re pre-PMF, taking action is the best way to learn, even if you’re not sure it’s the right action⁷.

I like that. I don’t think the frameworks clash. Instead, I’d say the two mesh with one simple phrase: don’t confuse activity for action. Or, if I were to paraphrase Brian’s quote into our framework: “All Work generates information: any Work, even the wrong Work. Waste does not.”

It’s easy to run around looking busy, doing productivity theater, making yourself feel busy, doing everything but what matters most. That’s common for larger businesses layering on process for the sake of process; that’s equally common for small startups procrastinating and doing everything but getting in the van, talking to customers, and building what they want. If you spend all your time as a startup on Waste, you’re not taking real action, and you’re not getting real information.

The only difference for pre- and post-PMF companies is that, before you know your customers want to pay you for your Work, you just have to take your best guess. It’s still critical to minimize things that aren’t Work or supporting it - maybe more so - because you need to try so many different types of Work until you find the right one.

Work is the highest revenue-bearing activity. Work is also the highest information-bearing activity. Friction is your Work delivery vehicle.

Everything else is just in your way.

Framing exposes opportunities

Is the point of all this that you should turn your Product team onto making PRHs now? No. It’s an experiment, we ran it once, the jury’s still out on if it’s worth the effort or not. Feel free to play with it and let me know if it fits with how you build.

The actual point is: see the difference better framing makes? By lining up agents to destroy Waste, improve Work outputs, and cycle out Friction to improve throughput, we get a way different Product org that makes the PMs feel like they’re omniscient. The alternative - having agents make fake PRDs - doesn’t feel remotely as cool in comparison.

It's intellectually easy to swap humans for AI 1-for-1. It feels tempting to take all your Waste and task an LLM to do it for you. But I guarantee it's worse. There are better problems to target, and you can spot them using this framework. Tap your AI to eliminate Waste, minimize Friction, and improve your real Work.

Every company using AI is about to learn this lesson. The question is whether they'll learn it the easy way or the hard way.

You’ll be able to tell by how many DeejDrones they launch.

---

Coming off of Inbound, there have been a lot of cool conversations about how people in Sales & Marketing roles are using agents productively - and not - and I’ll try to bring this back to earth a little bit and share what I’m hearing starting tomorrow.

1. We talked about hypocognition in an earlier post - this is sort of hypocognition-by-design, and it’s pretty dangerous.

2. We had a saying when I was in the Air Force - “negative intelligence is still intelligence.” Basically - don’t discount when you find out that something you wanted to learn cannot be learned.

3. Example of a simpler customer interview template. Nothing’s wrong with it, but there’s nothing setting you up to challenge exactly what you need to evaluate to get your product right; it’s mostly a blank piece of paper, ideal if you have no idea what your next product looks like, but the more you know about what you want to test, the weaker a template like this is. You can fill a template this generic out, exactly as written, without testing a single hypothesis. A PRH done well might guardrail you away from that outcome.

4. Here’s the draft PRH we made based on the DeejDrone concept: C003A2 - DD9K PRH. Again - the drone’s still a bad idea. But the template now is designed to expose that in customer interviews and get us detailed information about the viability of going into the commercial drone industry at all, and where the nuances are. This template filled in, plus the interview notes, turned into an actual PRD, will be infinitely better than the result at the beginning of the series.

5. This is, by the way, the exact reason I dislike the P# system and why we don’t use it.

6. Your product gaps process may be wildly different than these folks, but we set up an agent with fairly straightforward system instructions to run off a Slack webhook and feed disparate gap reports back to the Product team with some basic enrichment, which was enough to get the wheels turning on other long-neglected problems: https://github.com/centaurprise/deej-drone-9000/tree/main/agents

7. The original interview is here: