I stopped writing user stories

Context

Your development team has shifted to agentic coding, and it’s unclear where the boundaries between PM work and dev work should sit. Stories are a point of contention. It seems like you should be able to automate user story generation, but when you try this, the stories come out with weird detail and the engineers dislike working with them.

Discussion

Some decades back I drove up Sunshine Canyon in the foothills west of Boulder, Colorado. Two engineers had quit their jobs in medtech and needed help with their startup. They saw a chance to build better software to help doctors measure lung capacity with a device called a spirometer. The two of them had some savings - enough to get started, but not enough that they could afford to waste time. They felt PHP was the way of the future (yes, that PHP, the one an AI model recently found a massive hole in) and as I was an expert in this, they invited me to meet them at a house perched among the rocks and spruce trees to guide them to get started.

Together, we took apart the problem, wrote down user stories on index cards, arranged them on a table, and worked out what was the smallest possible product increment we could use to start testing with real people.

I'd been using this method for a number of years already, and it was something I loved doing and teaching. Taking an idea, breaking it down, and rearranging the pieces has been an essential part of my entire career. Especially the prioritization, in forced rank order: this felt like the most essential task of a product manager.

It used to be that every story cost real money - at least a day or so of someone's time to implement, and often a couple of days. This meant it was important to be careful and avoid building unnecessary things in order to manage costs and move quickly. Also, people hate building things that aren't used; it's depressing.

So user stories have been a core part of the agile playbook for decades, and a few plays here touch on them: Story Mapping, Triage Prioritization

Are User Stories Over?

But generative models are changing the constraints of software. Now Claude can implement a story in minutes.

I started building an AI-native product a couple of weeks ago as a learning experience. When you're leading a product org you have little extra time, and as I'm looking for my next team I find myself with an abundance of it. The idea was to help recruiters with some of the challenges of the current market.

In previous attempts, I've tried to guide Claude to work the way I think work should be done, but I know I need to unlearn some things. Steve Yegge has written a lot about the importance of having conversations with agents about their preferred ways of working. So this time, I used a different approach.

First, I asked the bot to question me about the goals and purpose of the initiative, so that it could develop a good understanding of the context. Then I asked it to think about architectural considerations for how we should approach the work. Finally, I asked it to recommend a brief format and work tracking approach.

What came out of all of this was a brief that I then handed over to a fresh Claude Code session. I asked it to make a plan for the first 'week' and generate its own GitHub issues.

Interestingly, I did not read the brief carefully before starting.

Even though they're in English, some docs are not meant for humans

In her talk at ProductLab last month, Guannan Li mentioned that in her speedboat team at Ablefy, they realized that sometimes, nobody was reading the spec. Not the engineers. Not even the PM. They didn't need to read it, because it was just a handoff tool between two different bot conversations.

In my case, I did scan the brief quickly. It looked basically ok. It was 10 pages long, readable, reflected our discussion, and was not overly bot-ish. But I resisted the temptation to really analyze it. These models generate a lot of text. If we try to read all of it, we are INCREASING the mental burden of this work. I knew I would be testing out the software as soon as it was usable, and actually looking at the software was the best way to see if it was going in the direction I wanted.

When I looked at the issues the bot had generated, they looked OK. Maybe not exactly the sequence I would have done, but close enough. Then we started building, and after a few rounds of issues without a UI, I got tired of flipping between markdown files to evaluate results. I asked the bot to build a UI so I could try it myself, and it did this in minutes.

This is important: you must actually use the software. When I was a PM working with a team every day, I had an explicit step for every story to sit down with the dev, post-implementation, try it out myself, ask about tests, and ask what else they wish they had time to do. (Often engineers will skip a 2-hour cleanup because they feel rushed, even though as a PM I want them to do this!) This review becomes even more important if there's an agentic loop involved.

I do look at the GitHub list from time to time. But largely I'm in dialogue with the bot about the software I see. Rather than telling it how to rank issues, I ask the bot which issue is next.

This works because the brief is really clear about the larger goals of the project. The bot knows WHY we are doing this project. The one thing I did really look at in the brief was its 4-week plan, and I generally agree with that. (Each 'week' seems to finish in about 8 hours of Claude Code time, but OK).

Below the level of the brief, the text in the issues is written for the agents. The humans work at the level of the brief and the running software. That's why generated issues feel so strange to engineers - they were never written for them.

My lesson here is that I will no longer be using user stories when working with agentic coding teams. Instead, I'll focus on really strongly clarifying intent.

Play: Steer Agentic Teams with an Intent Brief

Replace user stories and detailed Jira tracking with a product brief that expresses intent, and allow the model to generate and manage the detailed plan. Engage in frequent dialogue with the bot to keep the plan on track.

This happens in 4 steps:

1. Question: Invite the model to question you about your bigger initiative until you develop a shared understanding of the goals.
2. Architecture: Ask the model what architectural considerations are in play. For an existing system, this means connecting it to a source of architectural information - ideally a learning stream that coding agents are generating about the system as they work.
3. Discussion: As the model comes back with reflections, summaries, and proposals, this will jog your memory about further issues that need to be considered. Engage in dialogue until you're satisfied that you have explained what you know.
4. Handoff: Ask the model to create a brief that summarizes the plan, and to give you a prompt you can use to kick off the coding agent. Why do it this way, rather than having the whole conversation in Claude Code? The brief provides a cleaner context that you can later adjust and debate with everyone. Your emotions and reactions were an important input, but they're not the actual intent - they were just helping you to find the intent.

Once you have a brief, talk to your engineers. You need to work out the approach together, but not everyone has embraced agentic coding in the same way, so start by asking:

"I know a lot is changing with agentic coding. What's changed for you?"

Then:

"It seems like we're wasting time with stories when, if I gave you the right brief, you could run with it. What if we rethink our handoff approach? What kind of context do you need from me to really enable your agents to go fast?"

There is no fixed answer for who supervises the breakdown of the brief - it depends on the team. Guannan's team decided that the PM would work with the agent to turn the brief into a prototype, doing the UX iteration, and then work with an engineer who uses their own agents to assure quality and production readiness. In a B2B situation, with a ton of GTM work, a PM might simply hand over the brief to the engineer and check in daily to try out the software that's been built.

Review the handoff together: We still need to iterate on our process. So sit down together every week or every couple of weeks and talk about what's working and what needs to change. Include the bots in the conversation - they should be keeping learning logs along with their work, and this enables them to contribute.

What about reporting?

The status you, as a PM, should understand and own is at the initiative and feature level - what are the business goals behind your team's existence, and what are the larger features that need to be explained to your customers, partners, and organization. Let the model manage the linking of its work back to the features.

If those two engineers in Sunshine Canyon came to me today, I'd skip the index cards. I'd have them start with a 20-questions session with the model, about the why. With me watching? Maybe. The bots can help us a lot with breaking work down, getting organized, building, and tracking. What they need from us is guidance on why.