Your compression matrix is not your team
Compression has a domain shape. Run the map per domain and the limits stop landing in the same place.
Chuck Ros published a piece last week making the case that we measure AI's impact at the wrong altitude. Jobs are portfolios of tasks, AI compresses each task differently, and occupation-level claims like "engineers are 30% more productive" average away the detail leaders need. He is right, and I want to push the model one level further.
A generic compression matrix treats knowledge work as one landscape. Compression has a domain shape. Run the same exercise separately for the product development lifecycle and for go-to-market and the two maps disagree, in ways that change how you staff and where the next limit lands.
So I ran it. The bands below are directional estimates, drawn from the published research and calibrated against two years of shipping AI-native product. They describe the industry, and they do not describe your team. That distinction is the whole point.
When one task gets dramatically faster, another task becomes the limit.
| Task | Judgment | Compression | |
|---|---|---|---|
| Product operations / SDLC | |||
| Status and cycle reporting | Standups, cycle summaries, dashboards | Low | 80–95% |
| Documentation and release notes | Tech docs, changelogs, SOPs | Low | 70–90% |
| Test authoring | Unit and integration coverage, eval cases | Low | 70–90% |
| Code generation | Features, refactors, boilerplate via agents | Medium | 60–90% |
| Spec and PRD drafting | Requirements, acceptance criteria, context docs | Medium | 50–80% |
| Customer signal synthesis | Feedback triage, interview and ticket rollups | Medium | 50–80% |
| Code and design review | Judging agent output, catching what matters | High | 20–40% |
| Roadmap prioritisation | What is worth building, sequencing, tradeoffs | Very high | 10–30% |
| Architecture decisions | System design, build vs buy, model routing | Very high | 0–10% |
| Ship / no-ship call | Final quality bar, accountability for landed | Very high | 0% |
| Go-to-market | |||
| Lead research and enrichment | Account lists, firmographics, contact data | Low | 80–95% |
| Competitive intelligence | Gathering and summarising market moves | Low | 70–90% |
| Content production | Blog, social, email, SEO drafts | Low | 70–90% |
| Campaign assets and creative | Landing pages, ads, visuals, variants | Low | 60–90% |
| Sales collateral and battlecards | Decks, one-pagers, objection handling | Medium | 50–80% |
| Outbound sequencing | Personalised sequences at scale | Medium | 50–80% |
| Pipeline reporting and forecasting | Rollups, board slides, forecast drafts | Medium | 40–70% |
| Positioning and messaging | Category framing, narrative, what not to say | Very high | 10–30% |
| Pricing and packaging | Tiers, value metric, margin structure | Very high | 0–10% |
| Sales conversations and negotiation | Discovery calls, closing, relationships | Very high | 0–10% |
High >50%Moderate 10–50%Minimal <10%, human judgmentDirectional estimates, not evidence-scored
Read the two halves against each other and notice where the green sits. In the lifecycle, compression concentrates in the production middle: code, tests, documentation, first-draft specs. In go-to-market it concentrates at the top of the funnel: account research and content volume. The compressible work in both domains is the work whose output was already text, code, or structured data.
Then look at where the green stops.
First finding: the constraint lands in a different place per domain. The cleanest published version is the code result. In an NBER study of AI coding tools, developers using agents produced several times more code and 65% more pull requests, and releases rose only 20%, because delivery stopped being constrained by writing and started being constrained by review, integration, and approvals. Compress go-to-market and the constraint lands somewhere else entirely: on positioning, pricing, and the conversations that close. Same mechanism, different choke point, different owners in the room for the redesign.
Second finding: go-to-market compresses more and yields less. More of its volume work automates aggressively, but its human-advantage zone is relational: trust and negotiation. Review capacity grows when you redesign the process; trust grows at the speed of relationships. So compressed lifecycle time can convert to throughput, while compressed go-to-market time mostly buys volume that piles up against a relational limit. Microsoft's field experiment across thousands of knowledge workers found the same asymmetry: email hours fell by around a third for regular users, and meeting time barely moved. Individual work compresses faster than collaborative work.
Third finding: both maps end at the same cell. Ship or do not ship. Close or do not close. Zero compression, full accountability, one owner. When one task gets dramatically faster, another task becomes the limit. Every task upstream can compress, and the operating model still terminates in a call a person makes and answers for. If you are redesigning roles around AI, start at that cell and work backwards.
Used correctly, a map like this is a directional instrument. Multiply band by exposure: 80% compression on a task worth 2% of the week is a rounding error, and a 40% band on a task that eats a third of it is the roadmap. Watch the constraint, not the compression: freed hours mean nothing if review, pricing, or the sales calendar cannot absorb them. And score what landed: more code, more content, and more pipeline are production metrics, and the number that matters is whether more of what shipped landed.
That is the limit of any matrix, including the two in this note. Estimated bands say what is generically compressible across an industry. They cannot say what your team's evidence shows, or where your constraint sits this quarter. The teams that get this right will read their own signals, task by task. The rest will keep quoting a poster.
Sources and credit: the code result is the NBER working paper "Writing Code vs. Shipping Code" (Demirer, Musolff, Yang); the email and meetings result is Microsoft's randomised field experiment with M365 Copilot across dozens of firms. The bands are my estimates, informed by that research, and this note exists because Chuck Ros's "We're Measuring the Wrong Thing" made the altitude point well enough to build on.