Async vs. Meetings: What 6 Months of Requirements Data Told Us

The setup

Two teams. Two projects. Six months.

Both teams were building custom web applications for mid-market clients in the professional services sector. Both had comparable team sizes (5–7 developers), similar tech stacks, and comparable budgets (€120,000–€150,000).

The difference: how they collected requirements.

Team Alpha ran weekly requirements workshops — 90-minute video calls with client stakeholders, followed by a BA writing up the output as Jira tickets. The classic approach.

Team Beta used a structured async intake process. Clients submitted requirements through a shared link at any time. An AI tool generated first-draft user stories, which a PM reviewed and pushed to Jira.

We tracked both teams across the full project lifecycle.

The numbers

Requirement cycle time

The time from "client has a requirement" to "story is in Jira and ready to sprint":

Team Alpha's cycle time was dominated by the weekly cadence — if you missed a meeting, you waited a week. Team Beta's cycle time was limited only by PM review availability.

Story quality

We measured quality by tracking downstream events: how often a story needed to be reopened, how often a developer asked clarifying questions, and how often a sprint review led to rework.

The structured intake format reduced developer clarification questions by more than half. This had a significant downstream effect on sprint velocity.

Client satisfaction

Both teams ran NPS surveys at project midpoint and completion. We also conducted exit interviews.

The biggest driver of Team Beta's higher NPS: clients felt heard. Several specifically mentioned that the intake form gave them a way to capture ideas "whenever they came up, not just in meetings."

One client quote that stuck with us: "With the old way, I'd have an idea on a Friday and by Monday I'd forgotten half of it. Now I just submit it and it appears in the project two days later."

PM time

Team Beta's PM spent 77 fewer hours on requirements work. Those hours went into earlier sprint planning, more thorough review, and strategic conversations with the client.

What didn't work (and what they fixed)

The async approach wasn't perfect out of the gate.

Problem 1: Client education. Some clients submitted single-sentence requirements with no context. The AI could generate a story, but it often flagged the ambiguity correctly — and the PM had to chase for more detail.

Fix: Team Beta added onboarding instructions to the intake page, explaining what a good submission looks like. Quality improved significantly after week three.

Problem 2: Priority blind spots. Without a weekly sync, it was harder to understand what the client considered highest priority.

Fix: They added a "How urgent is this?" field to the intake form, and held a brief fortnightly priority call (30 minutes) to review the queue together.

Problem 3: Complex discussions.

Some requirements were genuinely complex enough to need a conversation — technical constraints, competing stakeholder interests, strategic trade-offs.

Fix: They kept the option for a discussion open. The rule became: simple requirements go through intake; complex ones get a call, then documented in intake afterwards.

What this means for your team

The async model isn't for everyone. Teams with clients who prefer high-touch engagement, or projects where requirements are deeply intertwined with strategic decisions, will still need synchronous sessions.

But for the majority of standard software delivery projects, the data suggests the async model produces:

• ▸Faster cycle times
• ▸Higher quality stories
• ▸Less PM overhead
• ▸Better client satisfaction

The transition takes about four weeks to feel natural — for both the team and the clients. After that, most PMs we spoke to said they wouldn't go back.

Ready to try structured async intake on your next project? [Start with Storygate →](/register)