Product Field Work All writing
WritingCommunication

Less status, more story

When agents do more of the work, and the system already knows what’s moving, a meeting to report status is a meeting to read aloud what’s already written down. The time is better spent deciding things, and on something that gets harder as products change faster: telling the company and customers a clear story about what changed and why it matters to them.

The problem

Status meetings, standups and sprint ceremonies were built for a world where people did all the work and the only way to know where things stood was to ask them. A project manager’s week went to collecting updates, and everyone else’s went to giving them. That made sense when work moved at human speed.

Two things break it now. Agents and tools already record what’s happening, in more detail than anyone would say out loud. And the product can change weekly, so the harder problem isn’t knowing what shipped. It’s making sure sales can sell it, support can support it, finance and compliance aren’t surprised, and customers understand why it’s good for them.

275interruptions a day, one every two minutes, from meetings, email and chat, in Microsoft’s 2025 Work Trend Index
122%spike in PowerPoint edits in the ten minutes before meetings: status being assembled at the last minute
322,000hours of recurring meetings Shopify removed in one purge, which its COO likened to adding 150 employees
How I’d measure the change
  1. Hours a week in meetings whose only purpose is reporting
  2. Decisions made per meeting hour
  3. Lead time: how many days before customers see a change that the teams supporting it know about it
  4. Customer reaction to change, support contacts and sentiment after each release
Why I wrote it

I’ve sat in many status meetings where the most useful minute was the one where someone finally raised a real decision. And I’ve watched good features land badly because the people who had to sell and support them heard about them the same day customers did.

The ideaLet status fall out of the system. Save meetings for decisions, customers and strategy. Brief every department before customers see a change. And tell customers a consistent story, tied to their pain and the product’s direction, instead of handing them a list.

1A week, then, now and next

One product manager’s calendar

My illustration of a typical week. Switch eras to see reporting give way to deciding.

Status and standupsSprint ceremoniesDecisionsCustomersStrategyTeam connection

2Status is a byproduct

When work runs through tools and agents, the system already knows what moved, what’s blocked and what shipped. Asking people to type that into a status report, or say it in a meeting, is duplicate work that interrupts the work itself. The useful version of status is automatic, and it only asks humans about the exceptions.

“Where are we on the import project?”

The same question, asked two ways on a Thursday afternoon.

Chasing status

Reading the live status

Nobody should have to report what the system already knows. People should only be asked for what it can’t know: judgment.

3What meetings are for now

This isn’t an argument for no meetings. Shopify’s purge worked because people were asked to bring back only what earned its place. What earns it now is anything that needs people together: deciding, understanding a customer, setting direction, and simply knowing each other.

Meeting triage

Pick a meeting to see what I’d do with it.

4No surprises inside the company

When the product changes weekly, every department needs to know what’s coming before customers do, in terms that matter to its job. Sales needs a talk track, support needs to know what will break habits, finance needs to know if billing changes, and compliance needs to know what to validate. Each department’s agents need their skills updated too.

AI makes this practical. The same approved release can produce a brief for every team, written for their role, days before customers see anything.

One release, a brief for every team

Release: bulk actions on the list screen. Pick a team to see its brief, generated from the same approved release.

5Tell customers a story, not a list

A release note that lists ten items tells customers the product changed again and they have to figure out whether they care. A story tells them what used to be painful, what’s easier now, and why the company built it, often because they asked. The first feels like homework. The second feels like being listened to.

For AI features especially, the framing matters. “This does the tedious part so you can spend your time on the judgment calls” lands very differently from “this automates your job.” And with AI, the same release can be told differently to each kind of customer, at no extra cost.

The same release, told four ways

Start with the list, then see it as a story for each persona.

6One story, many chapters

Consistency comes from a spine. Every release hangs from a quarter’s theme, every theme from the product strategy, and the strategy from the company’s goal. When a customer or a salesperson hears about a new feature, they should be able to trace it back, and each release should feel like the next chapter, not a random addition.

The narrative spine

Releases as chapters under the quarter’s theme, all traced back to the goal.

7A rhythm, not a firehose

More change needs more structure in how it’s told, not more messages. I’d set four rhythms, each with a clear audience, and keep them predictable so nobody is caught off guard.

ContinuousThe live statusGenerated from the work. Anyone can look; only exceptions interrupt anyone.
WeeklyThe internal briefWhat’s shipping next week, by team, with briefs and updated skills ready before customers see it.
MonthlyThe customer storyBundled changes told as one story per persona, with a short video and in-product walkthroughs.
QuarterlyThe strategy narrativeWhere we’re going and why, so every release that quarter has something to hang from.
Reporting hoursTime spent in meetings that only share status
Decisions per meeting hourWhat the remaining meetings produce
Internal lead timeDays teams know about a change before customers do
Surprise rateChanges a team first heard about from a customer
Customer reactionSupport contacts and sentiment after each release
Story coverageReleases that trace clearly to a theme and goal

Choices

Exceptions, not updatesPeople are only interrupted for decisions the system can’t make. Everything else is visible without asking.
Brief the company firstNo team should hear about a change from a customer. Internal lead time is a release requirement.
Chapters, not listsEvery release is told as part of the product’s story, in each customer’s terms.
Where this can go wrong

Cutting meetings can cut connection, and teams that never talk stop trusting each other; keep time that’s just for people. An automatic status feed can become surveillance if it’s used to watch individuals rather than the work. Personalized customer messaging can slide into spin; the story has to be true, including what’s not better yet. And in regulated products, some ceremonies exist for good reasons, like formal change review, and should be made faster, not removed.

Sources

  1. Microsoft Work Trend Index 2025, reported by UNLEASH: interruptions every two minutes, 275 a day; 57% of meetings ad hoc.
  2. Business Today on the same report: a 122% spike in PowerPoint edits in the last ten minutes before meetings.
  3. Fortune, June 2025: Microsoft’s researchers on AI speeding up a broken system rather than fixing it.
  4. NPR, February 2023: Shopify’s calendar purge, 322,000 hours, and bringing back only what earned its place.
  5. Daniel Florian: why the number of meetings is a poor measure on its own.
  6. “Defeating Feature Fatigue,” HBR 2006: why piling on change without a story wears customers out.