A PM I know spent three weeks on a spec. Twelve hundred lines, edge cases, sequence diagrams, the works. By the time it was "done," half of it was already wrong — a dependency had shipped, a stakeholder had changed their mind, an assumption had gone stale. And the feature still hadn't shipped a single line of code. The spec was the deliverable. That's the trap.
Here's the reframe: running async dev teams well isn't about writing a better spec. It's about writing a better task. The detailed up-front requirements document feels like control, but it's mostly waste. Requirements change, and a lot of what you carefully specify never gets touched — one oft-cited study found roughly 64% of software features are rarely or never used. (It's a small, dated study, so treat it as illustrative rather than law — but the direction rings true to anyone who's watched a feature ship to silence.) Worse, ambiguous and changing requirements are a top cause of project failure in the first place. The longer your spec, the more surface area there is to go stale before anyone builds it. The fix isn't more pages. It's a tighter loop.
Asynchronous software development means engineers work in long focused blocks, communicate in writing, ship in small increments, and you review at gates — instead of pinging each other in real time. The team's source of truth is the written record, not a standup.
The difference matters because of how building software actually works. Async development is not a standup-driven, always-on team pinging each other in real time — it's writing-first, increment-by-increment work, and that design lines up with the way engineers actually produce good code.
Builders need long, uninterrupted stretches. Paul Graham's "Maker's Schedule" makes the case better than I can: makers think in half-day units, and "you can't write or program well in units of an hour." A single meeting dropped into the middle of an afternoon doesn't cost an hour — it blows the whole half-day, because it splits the time into pieces too small to hold a hard problem in.
And the modern workday is already shredded. Microsoft's Work Trend Index found knowledge workers get interrupted roughly every two minutes — about 275 times a day. Meetings pile into exactly the wrong windows: half of them land in the 9–11 and 1–3 peak-focus blocks, more than half are ad hoc, and nearly half of people describe their work as chaotic and fragmented. Once you're knocked out of focus, getting back in is slow. Attention spans on a screen now average about 47 seconds, and research by Gloria Mark found it takes around 23 minutes to refocus after an interruption. Do that math against a 275-interruption day and it's a wonder anything ships at all.
Written-first async work gives those blocks back. People contribute when they're actually "on" rather than when the calendar says so, and the writing itself becomes a durable record — a single source of truth you can read later instead of reconstructing from memory. It also removes the timezone tax: nobody has to be awake at the same moment for progress to happen. That's deep work by design — distraction-free concentration close to the cognitive limit, which is where good engineering actually comes from.
So what replaces the spec-then-wait model? A loop. You submit a task in plain language. The engineer ships the first one within about five business days, then you settle into a steady three-day cycle — daily async updates as they work, and an approval gate before the next task starts. That's the whole mechanic. It's the opposite of "write a spec, hand it off, and disappear for three months."
The reason small batches win isn't ideology, it's feedback. Short cycles catch a wrong turn after three days instead of after three months, when it's cheap to fix instead of catastrophic. DORA's research identifies working in small batches as a core capability that drives both speed and stability — you go faster and break less, at the same time. A three-day task is a three-day blast radius. A quarter-long spec is a quarter-long one. (More on why small batches beat big ones in our piece on batch size and predictable delivery.)
A good developer task names the problem, not the solution. Describe the what and the done in plain language — the outcome in one line, how to reproduce it, what "done" looks like, and any constraints — then let the engineer own the how.
This is the actual skill, so let's get specific. The core move: you describe the what and the done. The engineer owns the how. Atlassian puts it cleanly — good acceptance criteria "describe the result, not the recipe". You are not writing a technical design. You're writing a crisp definition of the problem and a checkable definition of finished.
A good plain-language task has four parts:
Now watch the difference on the same problem.
Bad task: "Fix the broken checkout."
No way to reproduce it, no definition of done, no scope. The engineer has to come back and ask three questions before starting, or guess and get it wrong. Every ambiguity is a round-trip you'll pay for later.
Good task:
Problem: Users can't complete checkout on mobile — they tap "Pay" and nothing happens. Reproduce: iPhone Safari, add any item, go to checkout, tap "Pay." On desktop Chrome it works. Done: A user on iPhone Safari can buy one item end to end and see the order confirmation. Context: Web checkout repo. Don't touch the desktop flow. We'd like this before Friday's promo.
Notice what you didn't do. You didn't write a line of pseudo-code. You didn't name a function, pick a library, or sketch a database table. You don't need to — closing the gap between "here's the problem" and "here's the working code" is exactly what an AI-augmented engineer is fast at. In one controlled study, developers using an AI assistant finished a task 55% faster than those without — about 1 hour 11 minutes versus 2 hours 41. The engineers running these tasks come with Claude Code and Copilot as standard kit. Your job is the crisp definition. Theirs is the technical design.
"But how do I stay on top of it without a daily meeting?" You read. The daily async update replaces the standup — you get a written note on what moved and what's blocked, and you can read it in ninety seconds whenever it suits you. When there's a question, it gets answered in writing, so the answer is recorded instead of evaporating in a hallway. This is the heart of a healthy product manager developer workflow: the handoff lives in text, not in a meeting.
Your real control point is the approval gate. Nothing advances to the next task until you approve, which means the moment to weigh in is at the gate, not constantly. Day to day the rhythm is small: read the update, unblock with a quick written reply, approve or redirect when the task lands. Keep a thin layer of synchronous time for the genuinely ambiguous stuff — a fifteen-minute call to untangle a fuzzy requirement is fine. Async isn't a religion. It's a default you break on purpose.
Be honest about the limits, because async has them. It needs a definable "done." Open-ended discovery, "I'm not sure what I want yet," a live incident burning in production, or a high-conflict decision with real disagreement — those still want a conversation. Async strips tone and nonverbal cues, and it slows decisions when feedback comes in lagged bursts instead of a live back-and-forth. Forcing those moments through a task queue makes them worse, not better.
The rule of thumb: if you can't write the "done," it isn't a task yet — it's a conversation. Have the conversation, reach the clarity, then write the task. And right-size what you do queue. A task is a few days of work, not a quarter dressed up as a ticket. If it can't ship in a single short cycle, it's a spec wearing a task's clothes, and you're back in the trap.
Here's the practical sequence. Start by building a small backlog of well-scoped tasks — three or four, each with a problem, a "done," and its constraints. You don't need fifty; you need enough to keep the loop fed.
Submit the first one and just learn the rhythm: the five-day first delivery, the three-day cycle after that, the gate. Give your feedback at the gate, not mid-task. Let the engineer get all the way to "done" before you react, because feedback on half-finished work usually just churns the work. Once you trust the loop — and it takes about a week to feel it — add a second parallel stream for work that can run alongside the first. One stream is one engineer; a second stream runs independent work in parallel without stepping on the first.
This rhythm is the case for a subscription model over hiring a full-timer or rolling the dice on a marketplace gig — you get a steady cadence and a known engineer without a headcount fight or a hiring cycle. (We compared those trade-offs here.)
Strip it all down and the PM's job when running async dev teams is three things: define the problem crisply, trust the how, review at the gate. That's most of what separates teams that ship from teams that spec. The teams stuck in spec-land aren't failing because their writing is bad — they're failing because they're writing the wrong document.
It's also, not by accident, exactly how Dev On Demand runs: one task, one developer, daily async updates, and you own 100% of the code, cancel anytime. The model is the method.
So don't open a blank spec template. Write the task you'd want to receive — one line of problem, a checkable "done," the constraints that matter. Then send it.
What is asynchronous software development? Asynchronous software development means engineers work in long focused blocks, communicate in writing, ship in small increments, and you review at gates instead of pinging each other in real time. The source of truth is the written record, not a standup.
How do you write a good developer task? Write the problem, not the solution: the outcome in one line, how to reproduce it, what "done" looks like, and any constraints — all in plain language. You define the what and the done; the engineer owns the how.
How do you manage developers without daily standups? A daily async update replaces the standup — a short written note on what moved and what's blocked that you can read in under two minutes. Your real control point is the approval gate: nothing advances to the next task until you approve.
When is async the wrong approach? Async needs a definable "done." Open-ended discovery, ambiguous "I'm not sure what I want yet" work, live production incidents, and high-conflict decisions all still want a real-time conversation, because async strips tone and slows decisions when feedback arrives in lagged bursts.
Does writing plain-language tasks instead of specs actually work? Yes — small batches give you fast feedback and AI-augmented engineers close the gap between a clear problem and working code quickly, so you don't need to specify the implementation. The trick is to describe the result, not the recipe.
