# Stoa - Full Content > Multiplayer room for product teams who ship with agents. Live video, in-room AI agent that builds code, decision capture, runnable prototypes. Local-first. By SpecStory, Inc. App: https://meet.withstoa.com --- # The jig is back > Skilled craftspeople have always built jigs - small tools for one job in one shop. In software that cost a day or two, too much for a one-off. Agents change the math. Published: 2026-05-19 - Author: nate - URL: https://withstoa.com/blog/the-jig-is-back Agents are good at writing code. They're worse at the parts you have to see to judge, especially when there's no template, and what you want isn't on a Pinterest board or in another product's UI. I was building the hero animation for [withstoa.com/sharelocalhost](https://withstoa.com/sharelocalhost) ... a paper plane that flies along a curve from the Share button at the top of the page down into the install steps below. The plane's flight path is an SVG cubic Bézier, which is a string of numbers that defines a curve. The agent wrote the first few versions by hand: ```ts const PLANE_PATH = "M 545 70 C 720 95, 720 270, 525 295 S 285 385, 165 470"; ``` ![Hand-written paper-plane flight path in the hero](/blog/the-jig-is-back/hand-written-curve.png) We weren't converging. I wanted the plane to loop through the headline and land in a particular spot, and the curves kept coming out wrong, and we'd be guessing - adjust some numbers, reload, look, adjust again. Cubic Béziers are weird. Small numeric changes produce big shape changes, and you can't predict what looks good without seeing it. What I noticed after a while was that the agent and I were stuck for the same reason. The agent could write the path. I could see the result. But the loop between writing it and seeing it had a round-trip in it - me, reloading the page, eyeballing the curve, telling the agent what felt off. With each round we were both guessing. Neither of us could see what we were doing while we did it. The obvious move was Illustrator - draw the path in a vector tool with handles, copy the `d` string out, paste it back into the source. That would have closed the loop for me, but it would have done less than I needed. Illustrator doesn't know about my easing curve, my motion ramp at takeoff, my plane-rotation logic, my dotted trail. What I was actually designing wasn't a static curve. It was the motion of a plane along the curve. And it would have taken the agent out of the loop entirely - every iteration becomes a handoff, the agent waiting at the end of each pass. ## I asked the agent for a tool instead > can you code a tool that allows me to edit and view the path live in the localhost hero and then copy something for you to see? It built one in about 5 minutes. A path editor as a React component that took over the hero when I added a URL parameter. Drag handles for anchors and control points, with dashed tangent lines back to their anchors. A live plane animating along the current path so I could see the motion at full speed while I edited. A textarea with the current `d` string and a Copy button so I could paste paths back to the agent. ![The path editor taking over the hero, with drag handles and a Copy button](/blog/the-jig-is-back/path-editor.png) The thing that mattered most: the editor and the production hero shared the same animation code. The editor wasn't a model of production. It *was* production, with drag handles on top. The motion I saw while editing was the motion that would render in the real page. We were back to designing the actual thing. ![The dialed-in flight path looping through the headline](/blog/the-jig-is-back/final-path.png) ## The jig Skilled craftspeople have always made tools for jobs the off-the-shelf ones couldn't handle. A woodworker making chairs builds a jig to cut the same compound angle six times. A photographer rigs a piece of cardboard onto a light to shape a shadow. A blacksmith makes tongs for the specific shape they're forging. The jig isn't fancy. It's not for sale. It exists for one job in one shop. That's the point. In software, building a small project-specific tool has cost a day or two - too much for a problem you only had once. The default has been to reach for the closest off-the-shelf product, accept the friction, and move on. Agents change that math. A lot of small tools that didn't quite justify themselves before now do. Custom debug overlays for the specific state shape of an app. Project-local scripts to reproduce a stubborn bug. Eval rigs tuned to the exact behavior a team is trying to verify in an LLM. Path editors for paper-plane animations. The category is wide and most of these tools never leave the project. They don't need to. They exist for one job in one project. That's the point. ---
--- # Remote Collaboration is becoming Multiplayer: What AR VR teaches us about AI-Native Work > AR, VR, and MR research reframes remote collaboration as shared environments, presence, interaction, and now agency. Published: 2026-05-08 - Author: antaripa - URL: https://withstoa.com/blog/remote-collaboration-ar-vr Remote collaboration has improved a lot, but it still feels oddly flat. We can talk, share screens, write docs, and record meetings. Yet the actual feeling of building together often gets lost across tabs, transcripts, tickets, and follow-ups. The paper "[A Survey on Synchronous Augmented, Virtual and Mixed Reality Remote Collaboration Systems](https://arxiv.org/abs/2102.05998)" is useful to visit. It reviews AR, VR, and MR collaboration systems and the interesting part is this paper does not treat remote collaboration as one category. Instead, it breaks these systems into three things: - Environment: where the work happens - Avatars: how people show up - Interaction: what people can do together ![Paper screenshot](/blog/remote-collaboration-ar-vr/paper-screenshot.png) This is a better model than the usual "remote work equals video calls" framing. A good collaboration system is not just a communication layer. It is a room. And a room is valuable because it creates shared context where people can point, react, decide, sketch, and move together. The paper’s first idea, environment, is the most important one. Every tool creates a place, whether it is a Zoom grid, a Figma canvas, a GitHub PR, or a VR room. The quality of collaboration depends on how useful that place is. Can everyone see the same thing? Can the work and the conversation stay connected? Can decisions survive after the call ends? The second idea, avatars, is really about presence. In AR and VR, this might mean hands, bodies, gaze, or spatial position. But the broader point is that collaborators need to be legible to each other. You should know where someone’s attention is, what they are reacting to, and what they are doing. That becomes even more interesting with AI agents. What is the **avatar** of an agent? Not a cartoon face. Its avatar is its visible work. The team should know what the agent is editing, what context it is using, what it changed, and why. The third idea, interaction, is where most remote tools fall short. Many tools let teams talk about work. Fewer let them actually do the work together. The gap between **great discussion** and **someone needs to turn this into something** is where momentum dies. This is where the paper connects to AI-native collaboration. It gives us three layers, but today we need a fourth: agency. So the stack becomes: - Environment: where we work - Presence: how humans and agents show up - Interaction: what we can do together - Agency: what the system can do with us That is the direction we care about at **Stoa**. Remote collaboration is moving from communication to production. The meeting should not just create a transcript. The room should help create the spec, capture the decision, update the artifact, and let agents act on the shared context. The big takeaway from the paper is simple: remote collaboration is not about making distance disappear. It is about designing better shared contexts. AR, VR, and MR tried to rebuild the room visually. AI-native collaboration makes the room active. The next generation of remote tools will not just connect people. They will give teams a multiplayer space where people and agents can think, decide, and build together. --- Try https://withstoa.com for saving meeting context in an agent-friendly way. --- # Measuring Decision Lag, the New Long Pole > When agents can ship in hours, the slow part is deciding what to build. Intent Lead Time measures the gap between a product decision and the first implementation commit. Published: 2026-05-05 - Author: isaac - URL: https://withstoa.com/blog/intent-lead-time-audit When agents can ship in hours, the bottleneck is the decision. Most teams know when code landed. They do not know how long the decision sat before anyone wrote the first implementation commit. A shipped change has a commit timestamp. The work before that commit is harder to see. When did the team decide to make the change? Stoa defines that gap as [Intent Lead Time](https://withstoa.com/guides/intent-lead-time): the time from product decision to first implementation commit. ![Intent Lead Time audit timeline](/blog/intent-lead-time-audit/cover.png) We measured it by tracing recent Stoa work through four points: idea, decision, artifact, and first commit. Tracing a single decision back to its origin could take up to an hour of manual review across transcripts, docs, and git history. Even then, we still were not sure we had found the earliest signal. ## 1. Start With a Commit The audit started with commits because Git gives the timestamp, message, and patch. The harder endpoint is the decision, which might live in a meeting transcript, meeting note, topic summary, Claude Code agent log, design doc, Slack thread, or nowhere structured at all. `Intent Lead Time = first implementation commit - captured product decision` The endpoints rarely sit next to each other. Some decisions never become commits, and some commits trace back through several earlier discussions. To diagnose bottlenecks, each record tracked four dates: - When was the idea first mentioned? - When did we first decide to pursue the idea? - When did the first tangible artifact, such as a design spec or prototype, get created? - When was the first commit? ## 2. Pull Together the Sources Each trace drew from four source groups: 1. Conversations. We exported sessions, transcripts, topics, meeting notes, summaries, and metadata from our database into local files. 2. Git history. We pulled commit metadata, changed files, and patches from the Stoa repo so implementation evidence could be inspected next to meeting evidence. 3. Design docs. We collected specs, prototypes, and other planning artifacts. 4. Slack and other side channels. We left these out of scope for this pass. No source maps cleanly to one stage. A discussion may introduce the idea, record the decision, sketch a prototype, or only hint at the work. A prototype may follow a decision or start as the loose idea. A commit may implement the feature or preserve an experiment before the team has decided to pursue it. The audit had to separate four kinds of evidence: - intent evidence - decision evidence - design-doc evidence - implementation evidence ## 3. Build Records From the Evidence A record ties several artifacts to the same piece of work. A valid record might include: - this meeting note introduced the idea - this meeting transcript is where we decided to act - this doc defined the approach details - these commits implemented it The initial target was the last week of work. The workspace grew beyond that because recent work pointed back to earlier docs and meetings. The current corpus covers a broader April window: - 1,156 ingested commits - 583 indexed docs - 1,530 extracted doc items - 94 current intent records - about 1,000 evidence objects Of the 94 records, 48 currently link to implementation commits, 42 are design-doc-only, and 4 have no commit found. Most records are still medium or low confidence. ## 4. Audit Whether the Records Are True One feature, the starter-space template, showed why manual audit mattered. New users should land in a prepared starter space when they first create an account, with files and examples already waiting in the workspace. The first pass traced the decision to an April meeting. The team discussed how onboarding should copy the canonical starter space into a new org and decided to publish the files into Supabase/S3. Manual audit found an earlier transcript: new users landed in Stoa without enough context. Several looser conversations circled the same fix: give users hands-on examples after signup. The implementation had a longer lead-in than the first trace showed. The trace became: 1. Transcript: activation problem identification 2. Transcript: comment that we should give users a warm start 3. Transcript: discussion about pre-loaded use cases for new users 4. Transcript: explicit assignment to an individual 5. Design doc: onboarding flow 6. Implementation commits Even with search and agents, this chain took manual audit. Slack was out of scope, so the trace may still miss earlier decisions. ## 5. Fix the Other Failure Modes The same source-order problem appeared in another record. The first pass pointed to an April 22 implementation doc, but manual review found April 13 meeting evidence for the same work. A second record failed differently: it used broad, noisy evidence and an April 14 decision timestamp that looked like follow-up context. The better source was an April 6 doc that described the idea before the later discussion. If the source is wrong, the lead time is wrong. If the record combines several pieces of work, the number is a blend. If a follow-up note is treated as the original decision, the lead time stops meaning anything. In both cases, the number changed only after manual review. ## 6. Use Semantic Search for Candidates Semantic search helped because names drifted across systems. The same work might appear as `starter teammate` in a commit, `Theo` in a doc, and a first-meeting experience in meeting notes. Agents seeded searches from commits, docs, and extracted meeting-note items. They expanded those searches with exact phrases, keywords, and semantic matches. An agent reviewed the large candidate pool and clustered the candidates into possible records. Starting with candidates gave the agent evidence to verify, but manual audit still found missed links. The pass produced 2,289 proposal files: - 14 commit-first seeds - 108 doc-first seeds - 167 doc-item seeds - 2,000 meeting-item seeds Since most proposals required review, this workflow held up best: 1. Seed searches from commits, docs, doc items, and meeting items. 2. Use exact, keyword, and semantic search to gather possible matches. 3. Have an agent review and cluster the candidates. 4. Verify the source artifacts. 5. Apply the best-supported records. ## 7. Capture the Work Thread Earlier The audit showed why this cannot stay a historical reconstruction exercise. We need a workspace that lets reviewers see meetings, docs, transcripts, and commits together, then inspect proposed links and missing pieces. A record needs auditable evidence that the artifacts describe the same work. We also need to capture intent, decisions, docs, and implementation as work happens, so the trace exists before the audit starts. We built 94 records, and most are still medium or low confidence. A single feature trace could touch six or more artifacts across four systems. Rebuilding the chain after the fact from disconnected systems is too fragile for an ongoing business metric. Intent Lead Time has to be captured inside the way the team already works. --- # AI Broke the Spec Handoff > AI makes implementation move faster than traditional spec handoffs can carry context. Teams need to build the spec and prototype together. Published: 2026-04-29 - Author: isaac - URL: https://withstoa.com/blog/ai-broke-spec-handoff A PM can sketch a feature in the morning. By lunch, an agent-backed engineer can turn it into a working version with tests and docs. If the spec hides an assumption, the team finds out after it's done. That changes what a spec has to be. A spec can't stay a handoff that one person writes and another person interprets later. The people who understand the product, design, and system constraints need to build the spec with the prototype together. ## The Old Loop Assumed Work Was Slow Software teams reduce risk by moving slowly in small steps. ``` Spec ↓ Engineering review ↓ Design review ↓ PM finalization ↓ Engineering build ↓ QA ↓ Customer reaction ↓ Adjust ↺ back through the loop ``` Sprints, demos, and backlog reviews all assume the team can learn from mistakes before any bad ideas spread too far. Small steps helped with this product uncertainty, and that worked well because implementation took enough time that small steps is all you could do. The tail of implementation (testing, hardening) is still real. But work can get much further before the next check-in, which means a small misunderstanding can turn into an implemented pattern that work is being built on top of in a day. ## Handoffs Leak Judgment A good spec saves wasted motion. I like specs. A spec usually travels as a handoff. The PM clarifies the problem, the engineer reads the document later, and the document is implemented in the product. On complex work, design and product review add more passes, and each pass loses a little context. A document can record decisions but it cannot carry all the judgment behind them. The PM remembers which user quote mattered most. The engineer knows which service is about to change, which means we should sequence differently. The designer sees where a flow will confuse people. Those details shape the spec, but not every consideration is transferred with the spec. For example, an engineer might make a small implementation choice to simplify implementation of the spec. To the PM, it removes future flexibility that they wanted to build toward but needed more customer feedback first. Writing and better specs help, but the leak wasn't a big deal when the loop was slow. ## The Leak Costs More Now It's very easy for a document or an idea meant as a conversation starter can become a working flow before the PM realizes it was interpreted as direction. You can just build it. A small engineering shortcut can have tests, docs, and UI assumptions before the person rebuilding a server has time to review and say, "We have to reverse this next week". These divergences can be in several repos in hours, and untangling them may take longer than creating them. And frustrating to the team. The team followed the process, interpreted the artifact in front of them, and then were told they didn't have the full picture and have to revert it. Demoralizing. The team needs to catch these leaks while the work is being shaped, before it is customer ready work people are proud of. ## Build the Spec With the Prototype With AI it's possible to build the prototype together with all the people who understand the problem (engineer, PM, designer, etc). Before that would be a live call where everyone waits for an engineer to code, which is miserable for everyone (especially for the engineer). An agent can build and change the prototype in seconds so everyone can stay in the discussion. The PM is going to have things they learned from user interviews in mind. The designer is figuring out how to make it so a understandable and without footguns that will surprise the user. The engineer is pointing out which decisions require a huge change or new infrastructure, which let's the PM weigh how important that piece would be to users. All of this makes the prototype and the spec that comes from it sticky. The mental model for this feature was built together, and the spec is just solidifying details. That is the point of a shared agent in a shared workspace. Everyone needs to see the same artifact and steer it while the spec is still forming. By the end there will be some artifact that is the first phase of work (not notes, but maybe a spec, a prototype, or whatever the point of the meeting was) ## A Meeting Can Be Engineering Work I say this as an engineer because my instinct has always been to build first. I used to write code to understand the problem, and a lot of that happened in Jupyter notebooks because the code and visual feedback lived in the same place. Shared agents move that loop into a room with everyone else on my team. The PM and designer do not have to wait for me to return with an interpretation. They can watch the interpretation form, build prototypes with me, and when I go build the final feature I don't have to guess what the PM/Designer had in mind on all the small implementation decisions that come up as I go. And PMs often feels like pulling an engineer into a room feels like taking time away from code. That worry is often right. I would often be frustrated with high level notes and decisions. I know there's many layers of product decisions in the implementation details, but when I talk about implementation details I feel like nobody is interested and just want to talk general direction. I end up noting these as things to make a video about when I have a prototype or V1 built, because I can't seem to get the point across otherwise. I am blocked until I have these discussion with others which means I know I will need another meeting to get the info I actually need. I've been so annoyed at this that, I've done toastmasters speaking clubs and hired communication coaches to try to communicate better so I can get my point across. But building the whole prototype and getting into those details that's part of my implementation work live in the meetings solves all of that for me. And when the meeting ends I just continue building. ## Keep the Reasoning With the Work The co-built spec only helps if the reasoning stays attached. In many companies, the spec is in Google Docs, prototype in github, debates in Slack, call notes in granola, tasks in linear/jira. That's...normal? Nobody searches five systems well to reconstruct one decision, and the coordination and syncing between all those systems gets skipped. If you do try to keep all those systems up to date, and update them whenever any of them changes then you've rebuilt the handoff problem. The context cannot split across tools. The next person or agent needs the spec and decision trail in one place, because things will be missed otherwise. ## Scaling Without Putting Everyone in the Room Fifty people cannot sit in every conversation. Some teams avoid coordination by staying tiny. Some let one person make all the taste calls. Some give each person a separate area. These choices work for a while, but they turn into bottlenecks with scale. If adding people feels scary because of management overhead, the team has not solved coordination yet. Scaling means everything is together for the next person to join later. The prototype, transcript, agent session, spec all stay together. People can read a summary first, then ask their agent to dig into the source material when they need the details. AI makes the work move faster. The reasoning has to move with it. --- # Distance Still Matters: Why Context Slips Away in Remote Teams > Why remote teams lose shared context faster, and how treating decisions as first-class artifacts can keep alignment intact. Published: 2026-04-27 - Author: antaripa - URL: https://withstoa.com/blog/distance-still-matters-why-context-slips-away-in-remote-teams In 2000, the paper [*Distance Matters*](https://doi.org/10.1207/S15327051HCI1523_4) made a point that still feels uncomfortable today. No matter how good our tools get, working at a distance comes with a cost that does not fully go away. Back then, the concern was email and early video calls. Today teams run on Slack, Zoom, shared docs, and a growing layer of AI tools. Communication is constant. Everything is recorded somewhere. But that does not automatically mean teams are aligned. ## What Actually Breaks When Teams Move Apart What the paper gets right is that collaboration is not just about exchanging information. It is about maintaining a shared understanding of what is happening and why. When people sit together, that understanding forms almost without effort. You overhear decisions, pick up context, notice when something is unclear, and resolve it quickly. Most of that never gets written down, but it keeps everyone moving in the same direction. Once that environment disappears, nothing moves by default. Context has to be reconstructed, decisions have to be captured, and alignment has to be actively maintained. That is usually where things begin to drift. This is what the paper was really pointing to. Remote work does not fail outright. It starts to strain in specific ways: - teams lose shared context more easily - tightly connected work becomes harder to coordinate - tools help, but do not replace informal awareness - processes can fix some gaps, but add overhead - staying aligned simply takes more effort at a distance None of this sounds dramatic on its own. But together, it explains why things start to feel slower, less clear, and harder to track as teams grow remotely. ## Where It Shows Up Today You can see the same pattern in how teams describe their own setups today. ![Context shared across tools](/blog/distance-still-matters/context-shared-across-tools.png) One founder laid it out bluntly. Their work was spread across Slack, Notion, Linear, Figma, GitHub, and more. Everything existed somewhere, but nothing was easy to track. So even though, all information were available but scattered, so people still felt lost. In another discussion, the problem shows up even earlier. ![Saas Remote teams](/blog/distance-still-matters/saas-remote-teams.png) A SaaS founder described how things start to break around ten people. At some point, with enough information moving around, you stop knowing who knows what. And once that happens, alignment becomes slower and more fragile. This is the modern version of what Distance Matters described as a loss of common ground. ## The Problem Isn’t the Tools The tricky part is that most tools are doing exactly what they are supposed to do. Messages are captured, documents are stored, code is tracked, but they do not stay connected. The reasoning behind a decision, the conversation that led to it, and the final implementation often live in different places. Over time, that gap shows up in small ways. A decision gets revisited because no one remembers why it was made. A new team member struggles to understand how things evolved. A discussion moves forward without realizing that part of the context is missing. None of this feels like a major failure, but it slows everything down. For smaller remote teams, this tends to show up early. There is less structure to absorb the gaps, so alignment depends heavily on shared context. When that context is scattered, progress starts to depend on reconstruction instead of momentum. That is the lasting insight from Distance Matters. The real issue is not communication. It is the effort required to keep context intact as teams work apart. ## A Simple Shift That Helps There is no single tool that fixes this. But there is a simple shift teams can make. **Treat decisions as first-class artifacts.** Decisions are not something that lives inside a meeting, or a thread, or someone’s memory. It should be captured, connected, and easy to find later. In practice, this can be as simple as: - writing down decisions as they happen, not after - linking them to the work they affect - making them visible to the team by default It sounds small, but it changes how teams stay aligned. Instead of reconstructing context later, they carry it forward. Although that does not remove the cost of distance, but it makes the cost visible, and easier to manage. ### Reference - Olson, G. M., & Olson, J. S. (2000). Distance Matters. *Human-Computer Interaction*, 15(2-3), 139-178. https://doi.org/10.1207/S15327051HCI1523_4 --- [Try Stoa](https://meet.withstoa.com/sign-up) for saving meeting context in an agent-friendly way. --- # The PRFAQ Is Dead. Long Live the Product Landing Page. > The PRFAQ was a breakthrough in working backwards from the customer. But plain documents drift toward internal language and feature lists. A Product Landing Page keeps you honest. Published: 2026-04-17 - Author: jake - URL: https://withstoa.com/blog/the-prfaq-is-dead-long-live-the-product-landing-page The PRFAQ is one of the most influential product frameworks ever created. Amazon popularized it. Colin Bryar and Bill Carr codified it in [*Working Backwards*](https://workingbackwards.com/resources/working-backwards-pr-faq/), and thousands of product teams adopted it. The core idea to write a press release and FAQ before you build anything is genuinely brilliant. It forces you to work backwards from the customer. To use their language. To articulate the benefit before you spec the feature. I've written dozens of them. I've read hundreds more. And I've watched them miss their marks over and over again. Not because the idea is wrong. Because the format is. ------ ## What the PRFAQ Gets Right Before we bury it, let's honor what it got right. The PRFAQ's core insight is that **alignment starts with the customer's perspective, not your roadmap**. By forcing a team to write a something an outsider would read (i.e. a press release) it pulls you out of the internal bubble. You stop talking about "system capabilities" and start talking about what someone actually gets. The FAQ section does something equally important: it surfaces the hard questions early. Pricing. Competitive positioning. Technical constraints. The stuff that usually gets deferred until it becomes a crisis. When it works, a PRFAQ gives everyone across engineering, design, sales, leadership a single document to rally around. They all can read it and understand what you're building and why. That's powerful. That's worth preserving. ## Where the PRFAQ Breaks Down Here's where it goes wrong in practice. **The press release itself is an anachronism.** When Amazon invented this process, press releases were how products reached the world. That hasn't been true for a long time. Most product managers today have never written a real press release and couldn't tell you what makes one good. The format is a relic of an era when journalists were the gatekeepers of attention. Today, customers discover products through landing pages, search results, social posts, and word of mouth. Asking a team to write a press release in 2026 is like asking them to draft a telegram. The working-backwards principle is timeless, but the container it shipped in is showing its age. **Internal language creeps in.** And because nobody actually knows what a press release should read like, the format offers no natural resistance to internal drift. The document says "press release" at the top, but it's circulated internally. Reviewed internally. Revised internally. Within two rounds of feedback, the customer language is gone. You're back to phrases like, "leverage our platform to deliver seamless experiences". Thease are things that no customer has ever said or wanted to read. **Features overwhelm benefits.** The press release format nudges you toward announcing what the product *does*. But customers don't care what it does. They care what it does *for them*. A PRFAQ that lists features without grounding each one in a specific customer outcome is just a spec dressed up in marketing clothes. **It's missing half the product.** A PRFAQ typically covers the what and the why. But it says nothing about pricing, packaging, visual design, information hierarchy, or how the product actually *feels*. These aren't cosmetic details; they're core to whether the product succeeds. A product with the right features and the wrong pricing page fails. A product with a brilliant value proposition and a confusing layout fails. The PRFAQ is silent on all of this. ## What a PRFAQ Should Be in 2026 The insight that you should work backwards from your customer is more important than ever. Software development is faster. AI compresses the build cycle. The bottleneck has shifted from "can we build it" to "should we build it" and "are we building the right version of it." Alignment is the new constraint. And alignment requires something richer than a document. **It requires a Product Landing Page.** ## The Product Landing Page: A PRFAQ You Can See A Product Landing Page (PLP) is exactly what it sounds like: a real landing page for a product that doesn't exist yet. Not a mockup in Figma. Not a wireframe. A web page, with a headline, subhead, feature/benefit sections, pricing, FAQ, testimonials, and a call to action. And yes, you should put it on the internet. Before the product is ready. This isn't radical. It's what Y Combinator tells every batch to do. It's what lean startups have done for fifteen years. Ship the page, collect signups, learn what resonates. Your landing page can be your first experiment product experiment. Nothing drives alignment like outside feedback. Here's why a PLP succeeds where a PRFAQ stalls: **It forces outside-in thinking automatically.** When you're designing a web page, you instinctively think about the visitor. What do they see first? What do they need to understand in five seconds? What would make them scroll? You don't have to remind yourself to use customer language becayse the format demands it. Nobody writes "leverage our platform capabilities" on a landing page. They write "Ship faster with fewer meetings." **It makes you commit to positioning.** A headline is a position. A subhead is a promise. A landing page doesn't let you hedge. The PRFAQ lets you bury your positioning in a paragraph halfway down the document while the PLP puts it in 60-point type at the top of the page. If your team can't agree on the headline, that's a signal you haven't converged on what the product actually is. **It includes what the PRFAQ leaves out.** Pricing. Packaging. Visual hierarchy. The information architecture of how you present your product to the world. A PLP makes these first-class concerns, not afterthoughts. When you draft a pricing section, you're forced to answer: who is this for? What do they pay today? What's the anchoring? These questions surface months earlier than they would in a traditional PRFAQ process. **It's tangible.** A document is abstract. A page is concrete. When your engineering lead looks at a PLP, they don't just understand the product, they can *see* it (or at least squint at it). When your CEO looks at the page, they can react to the actual framing, not a description of the framing. This collapses feedback cycles and improves the quality of the feedback you receive. ## How to Write a PRFAQ as a Product Landing Page The PLP isn't a rejection of the PRFAQ's principles. It's a better container for them. Here's how the pieces map: **The press release becomes the hero section.** Your headline is the one-sentence version of what this product does for the customer. Your subhead is the expanded benefit. Your hero section is the press release distilled and sharpened, with no jargon. **The customer quotes become testimonials.** In a PRFAQ, you write imaginary customer quotes. In a PLP, you write imaginary testimonials and you place them on the page where they'd actually appear. This small change is surprisingly powerful. A testimonial on a landing page has to sound like something a real person would say. A quote in a document just has to sound plausible to the PM who wrote it. **The FAQ stays an FAQ.** This is the one piece that transfers directly. Keep it. Put it at the bottom of the page where FAQs live. But now it sits in the context of everything above it so the questions and answers are sharper. **The feature list becomes benefit sections.** Instead of bullet points in a document, you design sections with headlines, descriptions, and visuals. Each section has to earn its place on the page. If a feature doesn't warrant its own section with a clear benefit headline, maybe it's not a headline feature. **Visuals go on the page, not in a separate deck.** This is where the PLP pulls furthest ahead of a document. Add wireframes, rough prototypes, screenshots of a prototype, short videos, animations or whatever gives the product visual bones. You're not building the product yet, but you're showing what it could look and feel like. AI makes this fast. You can generate a helpful product wireframe in an hour or two, drop it into a hero image or feature section, and suddenly the page *feels* like a real product. A PRFAQ with an attached Figma link is two artifacts fighting for attention. A PLP with visuals inline is one coherent story. **Pricing gets a section.** You don't need final pricing. But you need a pricing *shape*. Free tier? Per-seat? Usage-based? Enterprise? Putting a pricing section on the PLP forces this conversation early, which is exactly when you want to have it. Pricing shapes the product, not the other way around. ## The Ideal Customer Testimonial Test Here's a technique that works especially well in the PLP format. Write three testimonials from your ideal customers. Not real quotes but aspirational ones. The testimonial you'd *want* to earn after the product ships. Then look at them honestly: - Do they describe outcomes, or features? - Would a real person say this, or does it sound like marketing? - Do they represent different use cases or customer segments? - Does the rest of your page actually deliver on what these testimonials promise? If your ideal testimonial says *"We cut our planning cycle from six weeks to two"* but nothing on your page explains how, you've found a gap. If your testimonial sounds like something only a product manager would say, you've drifted back inside. The testimonials are your compass. They tell you what the page should prove. ## Why This Matters More Now The pace of software development has changed. AI-assisted development means a small team can build in weeks what used to take months. The constraint now isn't speed, it's direction. When you can build fast, building the wrong thing is more expensive than ever. Not in dollars, but in opportunity cost. Every day spent on the wrong feature is a day you could have spent on the right one. And the teams that win aren't the ones that ship the most code, but ones that align the fastest on what to build. A Product Landing Page creates alignment that a document can't. It's visual, so designers engage with it. It's concrete, so engineers can respond to it. It has pricing, so business stakeholders can react to it. It uses customer language, so everyone is oriented around the same outside-in perspective. It's a PRFAQ you can see. And seeing is aligning. ## Getting Started: PRFAQ to Product Landing Page in Practice You don't need a designer. You don't need a developer. You need a tool that lets you draft a real page. 1. **Start with the headline.** Write ten versions. Pick the one that a stranger would understand in five seconds. That's your product. 2. **Write the subhead.** One sentence that expands the headline into a promise. 3. **Draft three benefit sections.** Each one gets a headline, a two-sentence description, and an imaginary screenshot or wireframe. If you can't describe the benefit in a headline, it's a feature not a benefit. 4. **Add a pricing section.** Even if it's rough. Especially if it's rough. The arguments you have about pricing now are arguments you won't have in month four. 5. **Write the FAQ.** Steal this straight from the PRFAQ playbook. What would a skeptical customer ask? 6. **Write three ideal testimonials.** Then check: does the page above actually deliver on what these testimonials claim? 7. **Share it.** Not as a doc. As a published web page. Send the link. Watch people react to it like a real product page. ------ The PRFAQ was built for a world where writing a document was the fastest way to align a team. That world has changed but the principles haven't. Work backwards, use customer language, surface the hard questions early. A Product Landing Page preserves everything that made the PRFAQ great and adds everything it was missing: visual design, pricing, information hierarchy, and the automatic outside-in discipline that comes from building something a customer might actually see. Your next product spec shouldn't be a press release. It should be a landing page. If you're not yet ready to build a PLP - if you're still pressure-testing whether the opportunity is real - start one step earlier with a [Lean Canvas](https://www.leanfoundry.com/books/running-lean). It forces you to articulate your problem, solution, unfair advantage, and revenue model on a single page. Once that canvas feels solid, you have everything you need to draft a Product Landing Page that brings it to life.
Lean Canvas template with numbered fill order

The Lean Canvas gives you a one-page snapshot of your product opportunity - problem, solution, key metrics, unfair advantage, and revenue streams. Fill it out before you write a single headline.

Download the Lean Canvas (SVG)

--- # Sharing the Thinking Behind the Thinking > AI makes human reasoning invisible. Four practices to close the new communication gap. Published: 2026-03-29 - Author: jake - URL: https://withstoa.com/blog/sharing-the-thinking-behind-the-thinking Here's a scene playing out in thousands of teams right now: ![img](/blog/sharing-the-thinking-behind-the-thinking/image_2.webp) Two AI calls. Zero thinking transferred. A perfectly efficient system for communicating almost nothing. ------ We laugh, but the joke lands because we've all been on one side of it. And the real problem isn't the wasted tokens, it's what's missing from the middle. The author had *reasons* for those three bullets and depth behind each. They knew which one mattered most. They knew the second one was controversial. They had context from a customer call that shaped the third. None of that made it into the polished doc even though the document looked done. The recipient, reading something that looked done, treated it as if it were authored with human intent. They didn't push back, didn't ask questions, didn't engage with the thinking because the artifact presented no thinking to engage with. Just conclusions, wrapped in confident prose that a machine wrote and a human sort of endorsed. This is the new communication gap. It's not a lack of clarity; it's a lack of *provenance*. The person reading your work doesn't know what's yours and what's the machine's. They don't know what you wrestled with, what you rejected, or where your judgment actually shaped the output. And without that, they can't do their job, which is to bring their own context and judgment to the thing you made. ------ ### The ironic inversion Here's what's strange about this moment: AI reasoning is becoming *more* visible while human reasoning is becoming *less* visible. Models now ship with chain-of-thought, reasoning traces, "thinking" blocks. You can literally watch the machine show its work. But the human? The person who chose this framing over that one, who rejected the first approach because they knew something about the system the AI didn't, who re-prompted a dozen times before the output matched what they actually meant? Their thinking has no artifact. No format. No convention. No place to live. The AI's reasoning is now more recoverable than the human's. If someone ships code and the model used chain-of-thought, you can at least reconstruct some of the AI's path. The human's twelve prompt iterations and the approach they rejected? Gone. We've arrived at a world where the machine shows its work and the person doesn't. ------ ### Why this breaks teams For solo work, the invisible thinking problem is fine. You remember your own reasoning. You were there. For teams, it's corrosive. And it compounds. Solo AI works because context is unified in one head. The person *is* the memory layer. Teams break because the faster individuals move with AI, the more invisible their reasoning becomes to everyone else. AI-generated output accelerates this because it looks *finished*. Polish forecloses the questions that rougher work would naturally invite. When you get a half-formed sketch from a teammate, you naturally ask: "What are you thinking here?" When you get a polished document, you assume the thinking is done. You might disagree with the conclusion, but you engage with it as a conclusion and not as a draft of someone's reasoning that needs your input. The fastest approach (for an author) is to just copy the AI output, and throw it over the wall. It's tempting because the output looks finished. The code compiles. The doc is well-structured. BUT there's no obvious signal that the person who sent it spent three minutes with it or three hours. When you send too quickly, you're not just skipping your own quality check, you're transferring the cognitive burden to everyone downstream. Someone else now has to figure out whether this thing is good, whether it fits, whether the assumptions behind it hold. You had that context. You just didn't share it. And here's the trust spiral: once people get burned by polished-but-hollow work a few times, they stop engaging carefully with *any* AI-assisted output. The team's collective quality bar drops, not because the AI got worse, but because nobody trusts the human layer anymore. ------ ### What to do about it This isn't a problem you solve with a policy memo. It's a set of small habits that change how your team communicates. Here are four that work: **1. Label the provenance.** Start marking your internal docs and artifacts as AI-generated, human-generated, or human-edited. It sounds almost too simple, but try it for a week. What changes is how your team *reads*. When people know a doc was AI-assisted, they bring more skepticism to the structure and more attention to whether the reasoning holds. When they know it was human-written, they trust that there's intention behind it and can engage more deeply. The label doesn't slow anything down. It just restores a signal that AI quietly removed. A lightweight version: just add a line at the top. "Drafted with Claude, edited and restructured by me. The recommendations in section 3 are mine; the market analysis is mostly AI-generated." **2. Annotate your reasoning, not just your output.** The opposite of slinging slop isn't perfecting, it's annotating. When you share AI-assisted work, include a few lines about your decisions: - "I asked for three approaches and picked this one because X" - "The AI suggested including Y but I cut it because we tried that last quarter and it didn't move the needle" - "I'm least confident in the pricing section; that needs someone with more context on enterprise deals" This takes sixty seconds and transforms how the next person engages. They're no longer evaluating a finished artifact, they're joining a conversation about decisions, with enough context to add their own judgment. **3. Share the intent, not just the conclusion.** Write your plans before your implementations. Not a polished spec but a working doc. The problem you're solving, the approaches you considered, the one you picked and why. Put it next to the code or presentation. Share it before you start building. If you already do this, try giving each other feedback on these docs before jumping to implementation. You'll be surprised how much misalignment surfaces in five minutes of reading someone else's reasoning. **4. Make "show your work" a team norm, not a personal virtue.** "Show your work" used to mean math class. Now it means: show the decisions you made on top of what the AI gave you. This only works if it's a team norm, not something one conscientious person does. In practice: PRs include a sentence about which parts were AI-generated and what the human shaped. Design docs have a "decisions made" section. Slack threads about AI-generated analysis include what the person checked and what they didn't. The format doesn't matter. What matters is the habit of making human judgment visible alongside the AI output. Because your teammates need *your* thinking to do their jobs. ------ ### The team that shares thinking compounds Here's the payoff for getting this right: the team that shares thinking compounds its intelligence. Every artifact carries context. Every handoff includes reasoning. The next person doesn't start from zero; they start from where you left off, with enough understanding to build on your judgment instead of just reacting to your output. The team that shares only output stays flat. Each person re-derives the context. Each handoff loses information. The AI gets better every month, but the team's collective understanding doesn't improve because nobody's thinking is making it into the shared record. You have three bullet points. Instead of inflating them into a polished doc, you share the bullets, with a line about why each one matters, what you're not sure about, and what you need from your team. Your team reads it in two minutes instead of twenty. They respond with their own context. A real conversation happens. No AI required. (This article was generated using Claude against a corpus of draft ideas and transcripts of conversations and monologues I've had over the past year. I did 4 passes of prompting on the overall doc, and 4 passes of prompting on the comic image. I then read and hand-edited the entire document.) --- # Turning a White-Glove Process Into a Self-Serve Workflow > Denise is CEO and co-founder of Variata, an AI-powered testing platform. Her product lets teams validate their websit... Published: 2026-03-24 - Author: jake - URL: https://withstoa.com/blog/turning-a-white-glove-process-into Denise is CEO and co-founder of Variata, an AI-powered testing platform. Her product lets teams validate their websites and apps by describing what they want tested instead of writing brittle, step-by-step automation scripts. Variata AI figures out how to navigate the site, run the flows, and report what broke. It works. Enterprise customers love it. But there's a catch: every new customer goes through a white-glove onboarding where Denise's team manually authors the test scenarios alongside them. They identify the highest-value flows, tune the inputs to the right level of specificity, and build a working setup that would've taken weeks for in-house QA teams to develop in just a day's time. That process produces great outcomes and teams are already saving lots of time with Variata. But now Denise is thinking about scale. ![Turning a White-Glove Process Into a Self-Serve Workflow](/blog/turning-a-white-glove-process-into/image_1.webp) So she set out to build the self-serve version including an authoring tool that would help users create their own test scenarios without her team in the room. She's done discovery across paying customers, free trial users, and casual evaluators. She's identified a spectrum of user inputs ranging from "just test my site" to granular click-by-click scripts. She's built three prototype classifiers to guide users toward the sweet spot. These are all the pieces. The question is how they fit together. Denise and I help each other as founders, and this month we used her self-service challenge as the topic of our conversation. It gave me a chance to work through a real product planning scenario that will help us build Stoa (our conversational planning tool) and it gave her an outside perspective. This session led us past some strong product principles so I decided to write it up and share it. --- ## **The Spectrum Problem** Here's the tension Denise was staring at. Variata's AI works best when it gets input at a middle level of abstraction -- milestones and expected outcomes, not pixel-level instructions. "Verify the sign-up flow works and the user lands on the dashboard" is better than "click the email field, type test@gmail.com, click the password field, type abc123, click Submit." The specific version latches onto details that change constantly. The milestone version is durable. But users don't naturally land in that middle zone. QA engineers tend to over-specify. Product managers and executives tend to under-specify. And the "just test my site" crowd gives almost nothing to work with. So the question Denise was trying to answer: how do you build an AI-assisted authoring experience that nudges users toward the level of detail that actually produces reliable tests? She'd prototyped three approaches. (1) A binary gate that gives a simple yes/no depending on whether your test prompt is sufficient. (2) A gap coach that shows you specifically what's missing. And (3) a clarifying Q&A coach that asks questions until it has enough to work with. Before evaluating any of them, though, there's a more fundamental question we decided to tackle. --- ## **Whose Problem Is This?** It's easy to describe this challenge in system terms: *how do we ensure users provide input that maximizes Variata's success rate?* That framing is accurate. It's also a trap, because it centers the product's needs rather than the user's. Flip it around. What's the user actually trying to do? Denise described a Product Leader she'd spoken with- someone who manually runs twenty user flows every morning. An hour of clicking through their own site with a coffee, testing that the promo codes work, the checkout completes, the filters behave. Not because it's in their job description. Because they feel personally responsible for their site. That person's problem isn't "I need to author test scenarios at the right level of abstraction for an AI system." Their problem is: *I have a process that works, I want it to keep working, and I'd like my morning back.* That reframe matters because it changes what success looks like. The authoring tool isn't asking users to learn a new skill. It's asking them to hand over something they already do and trust that it'll be done right. > **Reframe the problem from the user's side before designing solutions.** "How do we get better input for our system" and "how do I get my morning back" lead to very different products. --- ## **Who Exactly Are You Building For?** Denise had mapped out several personas: QA testers, product managers, developers, enterprise buyers, self-serve evaluators. She'd segmented by release cadence and personal risk. The users who keep coming back are the ones who have to sign off on revenue-driving releases at least monthly. But "people who sign off on releases" is still a broad group. And a self-serve product can only have one front door. The narrowing question: who, specifically, is going to try this tool on their own, fall in love with it, and then fight to get it adopted inside their company? Not the QA engineer; at least not at first. Some will resist a tool that automates their core job. The person who will champion Variata from the bottom up is the product leader or VP who does QA out of intrinsic motivation. They're doing it because nobody else will, they care about quality, and they'd happily hand it off to a system they trust. That person also happens to have the organizational leverage to push deals forward from below while the Variata sales team works with executives from above. > **Pick the champion, not the job title.** The user most likely to adopt and evangelize your self-serve product isn't always the one whose role most obviously matches your category. Look for intrinsic motivation plus organizational influence. --- ## **What Already Works** Here's where the conversation got interesting. Before evaluating the three prototypes, it's worth asking: what happens in the manual version that works so well? When Denise's team onboards a new customer by hand, what does the session actually look like? What's on the screen? Where does the input come from? Her answer was surprising. Users don't typically pull up their live product and walk through it together. Instead, they show up with requirements documents from Jira tickets, specs, runbooks, and email attachments describing features they need tested. Sometimes the features don't even exist in a live environment yet. The user is working from a written description of something they didn't build and may never have seen running. So Denise's team takes that document and, sitting alongside the user, translates it into testable scenarios at the right level of abstraction. They author a few together so the user can see the pattern. Then they send the user off to do the rest as homework. That's the workflow. And it reframes the entire product challenge into one sentence: **help people turn their requirements documents into testable scenarios.** Not "build a chatbot that asks smart questions." Not "create a test recorder that watches you click." Just: take the artifact the user already has and transform it into something Variata can run. > **Study your manual process before automating it.** The best self-serve products don't invent new workflows. They bottle the proven ones. If your team already knows what works in the white-glove version, the product's job is to encode that, not reimagine it from scratch. --- ## **The Case Against Questions** Back to the three prototypes: (1) a pass/fail binary gate on your testing inputs, (2) a coach that shows you the gaps between your input and expected structure, and (3) a Q&A workflow. With the problem compressed to "requirements in, testable scenarios out," each approach looks different. The binary gate is clearly too blunt. Telling someone "not enough detail, try again" when you have an LLM that can reason about exactly what's missing is, as Denise put it, "a little bit lazy." The clarifying Q&A flow is more sophisticated. It mimics the experience of Claude Code or Codex- thinking, then surfacing questions like "What's the expected outcome of a successful sign-up?" with selectable options. It feels smart. But there's a structural problem with questions: how do you know when to stop asking them? There's a fine line between "your questions are helpful" and "your questions are annoying," and that line moves depending on the user's patience and context. Ask too few and you don't have enough to work with. Ask too many and the user gives up. More importantly, questions don't teach. If the AI asks clarifying questions today, it'll have to ask clarifying questions again tomorrow. The user never learns what a good testable scenario looks like. Instead they just get walked through one instance. The gap coaching approach does something different. It shows the user a target that lets them build a mental model; here's what a complete, well-formed scenario looks like. This, along with highlights of the specific gaps in what they provided can be powerful. Instead of an interrogation, it's a progress bar toward a visible standard. That means the user learns the shape of a good scenario. Next time through, they need less help. The product is building user capability, not user dependency. > **Show what good looks like instead of interrogating toward it.** A coaching UI that reveals the target teaches users to self-serve over time. An open-ended Q&A creates a recurring dependency on the system. The best onboarding doesn't just get users through -- it makes them better. --- ## **The Bigger Pattern** Denise walked into this conversation with a clear picture of Variata's overall story and ROI journey. All we did together was zoom into one specific moment in that journey and get concrete about who's there, what they're holding, and what they need next. The pieces were all present in her research. The Product Leader with the morning coffee ritual. The requirements docs that users show up with. The white-glove process that already works. The insight that coaching beats interrogation. Sometimes product work isn't about generating new ideas. It's about compressing what you already know until the next move becomes obvious. --- Want a workspace to have your own product clarity sessions? Try [https://somehow.sh](https://somehow.sh) --- # Solo AI Keeps Getting Better. Team AI Keeps Getting Worse. > The problem isn't the tools - it's context fragmentation. Solo productivity is up, team coherence is down. Published: 2026-03-20 - Author: jake - URL: https://withstoa.com/blog/solo-ai-keeps-getting-better-team-ai-keeps-getting-worse Solo AI keeps getting better. Every month the tools improve with faster models, better context windows, smarter agents. A single person with a clear idea can turn it into working software in an afternoon. That loop is getting tighter and tighter, and there's no ceiling in sight. ![Solo AI Keeps Getting Better. Team AI Keeps Getting Worse.](/blog/solo-ai-keeps-getting-better-team-ai-keeps-getting-worse/image_1.webp) Team AI keeps getting worse. Not because the tools are bad, but because the faster individuals move, the more visible the gaps between them become. Decisions get made in private sessions. Context lives in one person's head. The team's shared understanding fragments a little more every week. AI didn't create this problem, but it's accelerating it. ------ Here's what we've been sitting with at SpecStory. A tight team should beat a solo operator. Not because of more hands but because of more angles on the same problem. Greg talked to users the others didn't. I have context from sales calls that never made it into a doc. Sean knows which part of the system will buckle under a particular design choice. No one has the full picture. Everyone has a piece. And even though we're all coding, we need to align on something higher level than the code. That diversity of context is a genuine multiplier if it can actually be harnessed. Right now, it can't. It's trapped in people's heads, scattered across Slack threads, buried in meetings that ended without a record. The conversations where the real thinking happened are gone by the time anyone needs them. So what happens instead? Each one of us tries to hold it all together. We become the memory for our team, trying to preserve every insight, tradeoff, and decision. When it was just three of us, that worked (barely). Now it's breaking as we approach ten. And while all we want to do is build and sell, we're now spending half our time revisiting or re-explaining context we've already built up but just can't find anymore. ------ A lot of people reach for "new workflows" as the answer. More check-ins. Better handoff docs. Daily standups with AI on the agenda. We resist these reflexively. These help at the margins. But they're treating the symptom rather than the cause: the intent that produced the work was never captured as a shared artifact in the first place. The habit shift that actually matters is treating intent as something the whole team owns. Not just prompts, whole conversations. The sync where someone pushed back on the original approach. The design review where a tradeoff got made. The customer call that reframed the whole problem. That context exists. It just evaporates the moment a meeting ends, inaccessible to the next person who needs it and invisible to the agents that could use it. One concrete thing we do to mitigate this is to **write our plans in markdown and share them.** Just a working doc, not a polished spec. The problem we're solving, the approaches we've considered, the one we picked and why. Then we show it to each other. This is an easy habit to adopt, and if you already have, try going one step further and give each other feedback on these docs (not as an implementation gate, just as a way to build shared understanding and improve). You'd be surprised how much misalignment surfaces in five minutes of reading someone else's reasoning. ------ As we started doing this, we noticed a related trust problem that snuck up on us. As more of our output, including these plans, were written with AI assistance, reading became not only a bottleneck but also required a new lens. Is this doc the product of an hour of thinking, or sixty seconds of prompting? Did someone shape this, or just ship it? The artifact often looks the same either way. And when we couldn't tell, we started discounting each others' work (or worse, we stopped reading with care). A simple fix if you're hitting this same problem: **label your internal docs as AI-generated, human-generated, or both.** Give some indiction of how much time and effort you spent iterating on them. It sounds almost too simple, but try it for a week. What changes is how your team *reads*. When people know a doc was AI-generated, they engage with it differently by bringing more skepticism to the content and more attention to whether the reasoning holds. When they know it was human-written, they trust the judgment (or at least the intent) behind it more. The label doesn't slow anything down. It just restores a signal that AI quietly removed. ------ The team AI problem isn't a tools problem. It's a context problem. How do you make the distributed knowledge of a team like reasoning, tradeoffs, and context available to the people and agents doing the work? We don't have a complete answer yet. But we're increasingly convinced the path runs through intent. Not capturing what got shipped, but why. Conversations as a team resource. Context as something you manage deliberately, the way you manage code. Solo AI is simple. One person, one mental model, clean execution. Team AI is harder. Multiple people, distributed intent, conversations that need to compound instead of evaporate. That's the frontier we're building toward. See more at https://withstoa.com --- # Please Review the Safety Card Before Airdropping Your Prototype > At a recent product and engineering leadership roundtable, a PM director said: \"I built a prototype that shows exactl... Published: 2026-03-16 - Author: jake - URL: https://withstoa.com/blog/please-review-the-safety-card-before At a recent product and engineering leadership roundtable, a PM director said: "I built a prototype that shows exactly what I want, with more clarity than any PRD I've ever written and my engineers weren't excited. They were *resistant*." Then a long debate followed about changing roles and AI code quality and the shifting job market. But I don't think any of that was the real reason for resistance. I asked a simple question: "when did you share your prototype?" A confused look and then a hesitant, "after I finished building it." And there was the problem: **what feels like resistance is actually an ask for inclusion.** Not "give me a more detailed specification", not "fix your prototype's broken code", but "bring me along for the ride". ![Please Review the Safety Card Before Airdropping Your Prototype](/blog/please-review-the-safety-card-before/image_1.webp) --- Think about what happens when a PM drops a fully-formed prototype on an engineer's desk. The PM has spent hours, maybe days, in conversation with an AI tool, exploring options, hitting dead ends, making tradeoffs, arriving at a solution that feels *right* to them. They've weathered the whole storm of the creative process. Then they hand over the sunny outcome and say: "Here. Build this." The engineer looks at it and feels... something. Not excitement. Something more like being airdropped into the eye of someone else's brain storm. The air is calm here, but they can see the wreckage of decisions they weren't part of. Why this data model? Why this flow and not the obvious alternative? What got tried and rejected? What tradeoffs were made, and who decided? The prototype answers "what." It doesn't answer any of the "whys." And without the "whys," the engineer can't do their job because engineering is the art of making good local decisions when you hit unexpected constraints, and you can only do that if you understand the *intent* behind the thing you're building. **Nobody likes to be airdropped into the middle of someone else's storm.** But everyone loves a good story -- a clear sequence of thinking they can follow, with a beginning, a middle, and a chance to shape the ending. --- Every great PM already knows this. It's why the best PRD reviews have never been signoff sessions. They're conversations where the team pokes at the solution together: "What happens when the user doesn't have an account?" "What if the API call fails mid-flow?" "This edge case seems ambiguous; can we nail it down right now?" Traditionally we justified this discussion in terms of cost. Clarifying questions, surfaced in a review, cost an hour to resolve. The same questions surfaced after engineering is underway cost a week. Surfaced in QA? A month. Now, with the cost of rework plummeting, it feels like these tradeoffs no longer hold. But there was another subtler reason for these meetings. The PRD review worked because the document *felt* open. It was words on a page. It was clearly a draft of thinking, not a finished product. People felt invited to push back, ask questions, and shape the direction. The document said, implicitly: "This is what I'm thinking. Help me think better." A working prototype sends the opposite signal. It looks *done*. It runs. It has buttons that click and screens that flow. Even if the PM knows it's held together with duct tape and AI hallucinations, the engineer sees something that looks finished and hears: "I've already decided. Just make it production-ready." That's the resistance. It's not about the prototype. It's about being handed a conclusion without the reasoning. --- So what do you do? You don't stop prototyping. The ability to express product thinking as working software is a genuine superpower that we shouldn't lose. But you **turn over your thinking in stages**, even if those stages happened quickly. At SpecStory, we've been working on this problem, and we call the practice an **intent review**. It's distinct from a code review. A code review asks: "Did we build it right?" An intent review asks: "Are we building the right thing and does everyone understand *why*?" Here's what that looks like in practice: **Share the problem before the solution.** Before anyone sees the prototype, share the customer insight or the problem statement that motivated it. Give the team the same starting point you had. Let them sit with the problem for even a few minutes before you show them your answer. **Show your exploration, not just your conclusion.** What did you try that didn't work? What tradeoffs did you make? What alternatives did you consider? This is the "story" part -- the sequence of thinking that makes the conclusion make sense. If you explored three approaches and chose one, show all three. Let the engineer see *why* this one won. **Name your confidence level.** There's a huge difference between "this is what I think we should build" and "these are two approaches I'm deciding between" and "this is an initial exploration, let's iterate." Naming where you are changes how people engage with what you're showing them. **Invite the storm, don't shelter people from it.** The messiness of the creative process isn't a bug, it's where the best engineering input happens. When an engineer sees the problem space, not just the solution, they bring constraints and possibilities that make the product better. That's not resistance. That's collaboration. --- Our new tools don't change our humanity. AI can collapse the time between idea and prototype from weeks to hours, but it can't collapse the human need to understand *why* before committing to *what*. An engineer who understands the intent behind a prototype will make a hundred good decisions during implementation that you never anticipated. An engineer who's just been handed a thing to rebuild will ask you about every single one. The fastest path to production isn't a better prototype. It's a team that shares your understanding of the problem. So the next time you're excited to show your team something you built (and you should be), pause for just a moment. Don't airdrop them into the eye of your storm. Tell them the story of the storm first. Then show them where you landed. Then ask them where *they* think you should go. That's not slower. That's how you get there together. --- # Why Your Product Decisions Keep Getting Relitigated > Relitigated decisions stem from mixing divergent and convergent thinking. Name the mode before you start. Published: 2026-03-10 - Author: jake - URL: https://withstoa.com/blog/why-your-product-decisions-keep-getting-relitigated I just ended a team meeting with that familiar, slightly hollow feeling. ![Why Your Product Decisions Keep Getting Relitigated](/blog/why-your-product-decisions-keep-getting-relitigated/image_1.webp) Everyone talked. A lot. We'd spent over an hour together. Slack will no doubt soon show another dozen follow-ups. Someone must've taken notes, right? And yet I couldn't answer the one question that mattered: Did we actually decide anything? Nobody said it out loud, but you could see it on people's faces as the call ended. The subtle hesitation before leaving the Zoom. The quiet, "okay… talk later." It's the feeling of motion without progress. I've seen this pattern enough times to recognize it now. It isn't about personalities, and it isn't even really about meeting facilitation. It's about something much simpler. We were mixing two completely different kinds of thinking in the same conversation. In the language of design thinking, we had a divergence / convergence problem. ------ Every productive conversation moves through two distinct phases, and they're not compatible with each other. **Divergent thinking** opens things up. It asks: what are we missing? What alternatives haven't we considered? What does the person who disagrees with us see that we don't? This mode is generative. It requires psychological safety, patience, and a willingness to sit with ambiguity. **Convergent thinking** closes things down. It asks: given what we know, what's the best path forward? It requires criteria, tradeoffs, and the courage to leave good options on the table in service of a decision. Great teams move between these modes intentionally. Most teams blur them together and wonder why nothing sticks. The tell is in the friction. When someone pushes back with a new idea during what the leader thought was a decision moment, that's divergent energy colliding with a convergent expectation. When someone asks "so what are we actually deciding?" in the middle of an open brainstorm, that's convergent pressure crashing into a divergent space. Neither person is wrong. They're just in different modes, and nobody said which mode the room was in. ------ The fix isn't complicated, but it requires intentionality. **Name the mode before you start.** Before any agenda item, say out loud which phase you're in. "For the next fifteen minutes, I want us to think expansively. Nothing is decided yet, all options are on the table." Or: "We've done the exploration. Now I want to converge on a recommendation." These aren't magic words, but they orient the room. People stop fighting the current when they know which direction it's flowing. **Signal the transition and acknowledge the shift.** Most meetings have a natural inflection point where the conversation wants to move from exploration to decision. Most facilitators miss it and let the meeting drift. The better move is to name it out loud: "I think we have enough on the table. Let's converge." But the transition is also the moment some people feel unheard, so a small acknowledgment goes a long way: "We've heard the concerns. Let's hold those and move toward a recommendation." **Match your mode to the stakes.** Not every topic deserves a full divergent phase. Small decisions don't need open-ended exploration - jumping straight to convergence is efficient and appropriate. But big decisions that haven't had a real divergent phase are dangerous. You're choosing between options someone already filtered, without knowing what got left out. The bigger the decision, the more intentional you need to be about earning your convergence. **Write to converge.** When you think the room has landed somewhere, don't just say it. Write it. Share your screen or open a shared doc and try to put the convergence into words in real time: what did we decide, and what's the reasoning? This does two things. It exposes gaps immediately, and it creates a record that everyone can push back on before the meeting ends, rather than relitigating it over Slack three days later. The goal isn't a polished document. It's a single sentence or two that the room can read and say "yes, that's what we decided." If you can't write it, you haven't converged yet. ------ There's a deeper reason this matters. When a team doesn't distinguish between modes, two bad things happen over time. The people who are naturally divergent start to feel like the deciders run everything. The people who are naturally convergent start to feel like exploration is performative - that the real decision was made before the meeting started. Both perceptions corrode trust. Both are avoidable. The goal isn't to rush through exploration or drag out decisions. It's to make each phase feel real. When people believe the divergent phase actually influenced the outcome, they commit more fully to the convergent one. When they trust the convergence is real, they explore more freely before it arrives. That's the rhythm. Open, then close. Expand, then decide. Not once in a meeting - sometimes two or three times, as you work through different agenda items or surface new information that reopens a question. The best meeting facilitators I've seen don't just manage time. They manage energy. They read the room, feel when it wants to open up and when it wants to close down, and they name it. Not with elaborate ceremony - with a simple sentence. "Let's explore this for a while." "Okay. Let's converge." That's it. That's the whole practice. Try it in your next meeting. Name the mode. Signal the shift. Watch what happens to the energy in the room. The conversations won't feel shorter. But they'll feel like they went somewhere. --- # The Rise of the Producing Manager > What cognitive science says about managing AI coding agents. Developers are becoming producing managers. Published: 2026-02-08 - Author: jake - URL: https://withstoa.com/blog/the-rise-of-the-producing-manager ### What Cognitive Science says about Managing AI Coding Agents ![The Rise of the Producing Manager](/blog/the-rise-of-the-producing-manager/image_1.webp) ------ ### Executive Summary Modern developers managing AI coding agents are engaged in a fundamentally new type of cognitive work-one that combines elements of people management with technical deep work in ways that have no historical precedent. This analysis synthesizes research from cognitive psychology (dual-task performance, bottleneck theory), management science (span of control, nature of managerial work), and emerging empirical studies on AI-assisted development to understand the implications for productivity, team structure, and tool design. The central finding: managing AI agents creates a workflow that oscillates between two cognitively distinct modes-a shallow "dispatch" mode amenable to parallelization and a deep "review" mode that is strictly serial and bottleneck-bound. Success depends on recognizing this duality and building systems that externalize intent across parallel workstreams. ------ ### Part 1: The Nature of Managerial Work ### Mintzbergs Foundational Insight Henry Mintzberg's *The Nature of Managerial Work* (1973) fundamentally challenged assumptions about what managers actually do. Through direct observation, he found that managerial work is characterized by: - **Brevity**: The median time spent on any single issue was shockingly short - **Variety**: Managers handle many different types of issues in rapid succession - **Fragmentation**: Work is constantly interrupted; sustained focus is rare - **Preference for verbal communication**: Managers favor live interaction over written documents - **Reactive orientation**: Responding to immediate demands rather than strategic contemplation Tengblad's 2006 replication study, conducted 30 years later, found the basic pattern held-managers still worked at an unrelenting pace through brief, varied activities. The main differences were more emphasis on group interactions with subordinates and somewhat less extreme fragmentation. ### Why This Matters for Cognitive Load Mintzberg's description maps directly onto what cognitive scientists call "supervisory cognition"-a mode of processing that draws on verbal communication, social judgment, and rapid task-set reconfiguration. Critically, for most managerial interactions, the depth of novel problem-solving is relatively low. Asking "what's blocking you?" and responding "try X, loop in Y if that doesn't work" engages working memory briefly, makes a pattern-match to prior experience, and moves on. In terms of the Problem State Bottleneck (Borst et al., 2010), most managerial interactions don't deeply engage the problem-state slot. This is why managers can handle many brief interactions without catastrophic performance degradation-each interaction is relatively self-contained and draws on practiced schemas rather than requiring novel problem construction. ------ ### Part 2: Span of Control and Employee Experience Level ### The Core Finding The span of control literature converges on a critical insight: the key variable isn't the raw number of direct reports-it's the **cognitive demand per report**. The factors that determine appropriate span of control include: - **Task complexity**: Routine, standardized work allows wider spans; complex, judgment-intensive work requires narrower spans - **Employee experience level**: Senior staff need less oversight; junior staff need more - **Manager role**: "Producing managers" who do their own technical work can supervise fewer people than pure managers ### Junior vs. Senior Staff: Fundamentally Different Cognitive Loads **Managing junior staff** typically requires a narrow span of control (4-6 direct reports) because juniors demand: - Frequent directive interactions (not just answering questions, but framing problems) - Detailed review of output (more errors, missed edge cases, need for architectural guidance) - Heavy context loading for each interaction (cannot assume they've considered relevant factors) In cognitive terms: reviewing a junior's work engages the problem-state bottleneck heavily. The manager must load full context, mentally simulate execution, and check for issues at multiple levels. **Managing senior staff** allows a much wider span (10+ reports) because seniors require: - Occasional strategic check-ins (they self-direct between interactions) - Light review of output (trust in patterns; checking for alignment, not correctness) - Less context loading per interaction (shared mental models, shared vocabulary) In cognitive terms: reviewing a senior's work is more like monitoring-scanning for misalignment with broader intent, which can be done with less deep engagement of the central bottleneck. ------ ### Part 3: AI Coding Agents as an Unprecedented Hybrid ### Neither Junior Nor Senior Developer Current AI coding agents present a cognitive load profile unlike any human report. They combine characteristics of both junior and senior workers in ways that create new challenges. **Like ultra-productive juniors:** - Need clear, specific instructions to perform well - Produce work that requires real review (cannot be trusted implicitly) - Don't understand broader architectural context the way a senior colleague would - May introduce subtle bugs or misalignments that require expert detection **Unlike any human report:** - No 1:1s, motivation, career development, or emotional support needed - Don't get blocked by organizational politics - Work continuously without breaks - Dispatch cost is minimal (typing a prompt vs. conducting a standup) - Can be parallelized without coordination overhead between agents ### The Two-Phase Cognitive Profile Managing AI agents breaks into two distinct phases with very different cognitive properties: **Phase 1: Task Specification and Dispatch** This is relatively **shallow work**. The developer translates intent into instructions, drawing on existing mental models of the codebase and problem domain. For experienced developers, this maps onto what Sarkar (2025) calls "planning-style instructions"-structured, goal-oriented prompts that leverage existing schemas. Dispatch can be interleaved with other work because each dispatch is a brief verbal-output task that doesn't hold the problem-state slot for extended periods. Multiple agents can be dispatched in sequence without catastrophic interference. This phase resembles Mintzberg's managerial work: brief, varied, action-oriented. **Phase 2: Output Review and Integration** This is unambiguously **deep work**. Code review research consistently shows it's among the most cognitively demanding activities in software engineering. Baum (2019) and Bacchelli & Bird (2013) document that review requires loading someone else's mental model into working memory-their architectural choices, naming conventions, edge cases considered, and assumptions made. One study found developers spend 58% of maintenance time simply understanding existing code before making changes. Review demands this same cognitive effort compressed into a shorter window. This phase engages the central bottleneck fully. You cannot meaningfully review two pull requests simultaneously. The problem-state slot is occupied, and attempting to interleave review tasks will incur the full dual-task costs documented in the cognitive literature (20-40% performance degradation, increased errors, attention residue effects). ------ ### Part 4: Empirical Evidence from AI-Assisted Development ### The Faros AI Study (2025) Analysis of telemetry from 10,000+ developers across 1,255 teams found: - Teams with high AI adoption completed **21% more tasks** and merged **98% more pull requests** - However, **PR review time increased 91%**-the bottleneck shifted from production to review - AI adoption was associated with a **9% increase in bugs per developer** and **154% increase in average PR size** - Developers were interacting with **9% more tasks** and **47% more pull requests per day** The study explicitly noted: "Historically, context switching has been viewed as a negative indicator, correlated with cognitive overload and reduced focus. AI is shifting that benchmark... developers are not just writing code-they are initiating, unblocking, and validating AI-generated contributions across multiple workstreams." ### Sarkars Higher-Order Thinking Study (2025) Suproteem Sarkar's SSRN paper analyzing 323,589 code merges across 32 companies found: - Software output increased **39% after agents became the default** code generation mode - **More experienced workers accept agent-generated code 6% more often** than junior colleagues - Experienced workers give **clearer, planning-style instructions**, improving alignment with intent - This positive experience gradient for agents **contrasts with autocomplete**, where juniors benefit more The study concludes: "Agents may shift the production process from the syntactic activity of typing code to the semantic activity of instructing and evaluating agents... abstraction, clarity, and evaluation may be important skills for workers." ### The 70% Problem (Osmani) Addy Osmani's widely-cited observation captures the senior/junior divide: - AI coding assistants can get you **70% of the way** to a solution - For **seniors**, the last 30% is where their expertise shines-they can efficiently evaluate and complete the work - For **juniors**, the last 30% is often **slower than writing it themselves** because they can't reliably evaluate what they're looking at This aligns with the cognitive science of expertise: seniors have built deep schemas through years of practice that enable faster pattern-matching during review. The bottleneck is still present, but they process through it more quickly (stage shortening). Juniors lack these schemas and cannot distinguish correct-looking code from subtly wrong code. ------ ### Part 5: The Producing Manager Problem ### The Hardest Role in Management The span of control literature identifies the "producing manager"-someone who splits time between managing others and doing their own technical work-as occupying the most cognitively demanding role. When managers must also do individual contributor work: - Span of control should be **narrower** than pure managers - They face constant switching between **incompatible cognitive modes** - The fragmented, reactive supervisory mode conflicts with the deep, sustained problem-solving mode ### Developers as Producing Managers of Agents A developer managing coding agents is essentially a producing manager. They're attempting to: 1. **Do their own deep thinking**: Architecture decisions, system design, understanding user intent 2. **Simultaneously supervise autonomous workers**: Dispatching tasks, checking status, reviewing output, integrating results The dual-tasking research predicts exactly what the empirical data shows: throughput increases, but quality pressure rises, and the bottleneck shifts from production to review and integration. Simon Willison captured this dynamic in his Pragmatic Engineer article: > "I was pretty skeptical about this at first. AI-generated code needs to be reviewed, which means the natural bottleneck on all of this is how fast I can review the results... Despite my misgivings, over the past few weeks I've noticed myself quietly starting to embrace the parallel coding agent lifestyle. I can only focus on reviewing and landing one significant change at a time, but I'm finding an increasing number of tasks that can still be fired off in parallel without adding too much cognitive overhead to my primary work." This maps perfectly onto the research: dispatch is shallow work, review is deep work, and you can layer shallow tasks around a deep task if they don't compete for the same bottleneck resources. ------ ### Part 6: Implications for Practice and Tool Design ### What Works: Leveraging the Two-Phase Structure **For individual developers:** - Recognize that dispatch and review are cognitively distinct-don't try to interleave reviews - Batch agent dispatches during natural breaks in deep work - Use the deep work period for the most cognitively demanding review task; dispatch to agents while reviewing output from a previous dispatch - Senior developers should embrace agent management; juniors should be cautious about over-reliance **For engineering managers:** - Expect review bottlenecks to intensify as agent adoption increases - Consider dedicated "review specialist" roles or time allocations - Recognize that agents shift the constraint from coding speed to evaluation speed - Junior developers may need more support, not less, in an agent-heavy environment **For tool designers:** - The biggest cost isn't dispatching or reviewing individual outputs-it's **maintaining coherent intent across parallel workstreams** - Developers running 4-8 agents simultaneously need to track not just what each is doing, but how pieces fit together and what the original user need was - Systems that **externalize intent**-preserving the "why" behind each dispatch, tracking relationships between workstreams, providing context for efficient review-fill a critical gap - Traditional project management tools aren't built for this; the "intent layer" is missing ### What Doesnt Work: Ignoring the Bottleneck Common failure modes include: - **Assuming agents eliminate cognitive load**: They shift it from production to review, often intensifying it - **Treating all agent interaction as equivalent**: Dispatch is cheap; review is expensive - **Expecting juniors to benefit equally**: The experience gradient runs opposite to autocomplete tools - **Ignoring review time in productivity calculations**: The 91% increase in review time is real cost that doesn't appear in "tasks completed" metrics ------ ### Part 7: Future Research Questions 1. **Training effects for agent management**: Can developers be trained to review agent output more efficiently, similar to stage-shortening effects in dual-task training? Or does the novelty of each review task prevent automatization? 2. **Optimal agent parallelization**: What is the empirically optimal number of concurrent agents given human review bottlenecks? How does this vary by developer experience? 3. **Intent preservation systems**: What tool designs most effectively support intent maintenance across parallel agent workstreams? How should context be captured and presented to minimize review cognitive load? 4. **Junior developer development**: If AI handles tasks that traditionally trained juniors, how do they develop the schemas needed for effective review? What new training approaches are needed? 5. **Age effects**: Given that older adults show reduced capacity for bottleneck bypass in dual-task training, are there age-related differences in adapting to agent management workflows? ------ ### Key References ### Cognitive Science: Dual-Task Performance and Bottlenecks Borst, J. P., Taatgen, N. A., & Van Rijn, H. (2010). The problem state: A cognitive bottleneck in multitasking. *Journal of Experimental Psychology: Learning, Memory, and Cognition*, 36(2), 363-382. Pashler, H. (1994). Dual-task interference in simple tasks: Data and theory. *Psychological Bulletin*, 116(2), 220-244. Leroy, S. (2009). Why is it so hard to do my work? The challenge of attention residue when switching between work tasks. *Organizational Behavior and Human Decision Processes*, 109(2), 168-181. Newport, C. (2016). *Deep Work: Rules for Focused Success in a Distracted World*. Grand Central Publishing. ### Management Science: Span of Control and Managerial Work Mintzberg, H. (1973). *The Nature of Managerial Work*. Harper & Row. Mintzberg, H. (2009). *Managing*. Berrett-Koehler Publishers. Tengblad, S. (2006). Is there a "new managerial work"? A comparison with Henry Mintzberg's classic study 30 years later. *Journal of Management Studies*, 43(7), 1437-1461. Bandiera, O., Guiso, L., Prat, A., & Sadun, R. (2012). Span of control and span of attention. *Harvard Business School Working Paper*, 12-053. ### Code Review and Developer Cognition Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. *Proceedings of the International Conference on Software Engineering (ICSE)*. Baum, T. (2019). The cognitive aspects of code review. *Empirical Software Engineering*. Mayer, R. E., & Moreno, R. (2003). Nine ways to reduce cognitive load in multimedia learning. *Educational Psychologist*, 38(1), 43-52. ### AI-Assisted Development: Empirical Studies Sarkar, S. K. (2025). AI agents, productivity, and higher-order thinking: Early evidence from software development. *SSRN Working Paper*. Faros AI. (2025). The AI productivity paradox research report. https://www.faros.ai/blog/ai-software-engineering Willison, S. (2025). New trend: Programming by kicking off parallel AI agents. *The Pragmatic Engineer*. Osmani, A. (2025). The 70% problem with AI coding assistants. *Pragmatic Engineer*. ### AI and Workforce Implications IEEE Spectrum. (2025). AI shifts expectations for entry level jobs. December 2025. arxiv. (2025). Coding with AI: From a reflection on industrial practices to future computer science and software engineering education. arXiv:2512.23982. Pajo et al. (2025). Towards decoding developer cognition in the age of AI assistants. arXiv:2501.02684. ------ *Analysis prepared February 2026. Synthesizes cognitive science research on dual-task performance with management literature and emerging empirical evidence on AI-assisted software development.* --- # Planning Work for Our Single-Threaded Brains > When dual-tasking works, when it doesn't, and why - what cognitive science tells us about managing AI coding agents. Published: 2026-02-05 - Author: jake - URL: https://withstoa.com/blog/planning-work-for-our-single-threaded-brains ## When Dual-Tasking Works, When It Doesn't, and Why ### The Core Architecture: Your Brain Has a Bottleneck The foundational finding in multitasking research, replicated hundreds of times since Pashler's landmark 1994 review, is that the brain's response selection mechanism operates serially. When two tasks both need the central processor to make a decision, one waits for the other. This is the **Psychological Refractory Period (PRP) effect**: present two stimuli in rapid succession, and the response to the second one is reliably delayed by however long the first one is still occupying the central stage (Pashler, 1994; Sigman & Dehaene, 2006). This isn't a minor lab curiosity. The PRP effect is described as "highly robust" across decades of research and is observed regardless of whether the two tasks use the same hands, different hands, voice responses, foot responses, or eye movements (Pashler, 1994). It persists even when the tasks seem completely unrelated. But the bottleneck story is more nuanced than "you can't do two things at once." It depends critically on *what kind* of cognitive resources the tasks require. ### Wickens Multiple Resource Theory: The Key Framework Christopher Wickens' 4-Dimensional Multiple Resource Model (1980, 2002, 2008) explains why some task pairs interfere catastrophically while others coexist relatively well. The model identifies four dimensions along which cognitive resources are differentiated: 1. **Processing stages**: Perceptual/cognitive vs. response 2. **Sensory modalities**: Visual vs. auditory 3. **Processing codes**: Spatial vs. verbal 4. **Visual channels**: Focal vs. ambient The prediction is straightforward: two tasks that draw on *different* resource pools along these dimensions interfere less than two tasks that draw on the *same* pools. Listening to a podcast (auditory/verbal) while driving (visual/spatial/motor) works reasonably well because the tasks draw on largely separate resource pools. Reading a text while listening to someone speak (both verbal) is much harder because they compete for the same verbal processing resource. Wickens' computational model yields high correlations between predicted and observed interference across dozens of task combinations (Wickens, 2008). This is the best empirical framework we have for predicting when dual-tasking will or won't cost you. ![Planning Work for Our Single-Threaded Brains](/blog/planning-work-for-our-single-threaded-brains/image_1.webp) ### The Problem State Bottleneck: Why Knowledge Work Is Different Beyond the general central bottleneck and Wickens' resource pools, there's a more specific bottleneck that is especially relevant to knowledge work: the **problem state bottleneck**, identified by Borst, Taatgen, and van Rijn (2010). The "problem state" is the intermediate mental representation you hold while working through a task - the current step of a multi-step calculation, the logical structure of an argument you're building, the architectural pattern you're implementing in code, the thread of reasoning in a document you're editing. Borst et al. demonstrated experimentally that people can maintain only one active problem state at a time. When two tasks *both* require maintaining a problem state, interference is severe and "overadditive" - worse than the sum of each task's individual demands. When only one task requires a problem state (and the other is more automatic), interference is minimal. This finding was confirmed across three experiments and validated with computational models in the ACT-R cognitive architecture. Subsequent work (Held, Rieger, & Borst, 2024) showed that working memory contention, not a general central coordinator, best explains the interference pattern in dual-task settings. **This is the critical insight for anyone doing coding, writing, planning, or analytical work.** These tasks *all* require maintaining a complex problem state. Writing a spec requires holding the logical structure of the document. Coding requires holding the state of the implementation. Debugging requires holding a mental model of data flow. They all contend for the same limited problem-state resource. ### Salvucci & Taatgens Threaded Cognition: When Interleaving Can Work The most sophisticated model of multitasking is Salvucci and Taatgen's **Threaded Cognition theory** (2008), which treats concurrent tasks as independent "threads" that are coordinated by a serial procedural resource and executed across other available resources (visual, auditory, motor, memory). The key mechanism: when one thread is waiting for a slow resource (e.g., a motor response, a memory retrieval, an external event), other threads can use the procedural resource in the gap. Tasks interleave through the *idle slots* in each other's processing, not through parallel execution. This means dual-tasking can approach zero cost under specific conditions: - **One or both tasks have substantial idle/waiting periods** where the procedural resource isn't needed - **The tasks use different peripheral resources** (e.g., one visual, one auditory; one manual, one vocal) - **Neither task's problem state is disrupted** by the other task's processing When these conditions hold, threading is efficient. When they don't - particularly when both tasks compete for the problem state resource - interference is substantial and unavoidable. ### Can Training Improve Dual-Task Performance? A natural question follows from the bottleneck research: if the bottleneck limits dual-tasking, can practice reduce or eliminate that limit? The answer is nuanced - training can dramatically improve dual-task performance, but the mechanisms and boundary conditions matter enormously for anyone hoping to apply this to real work. ### Three Competing Hypotheses Ruthruff, Van Selst, Johnston, and Remington (2006) tested three hypotheses about how practice reduces dual-task interference: 1. **Task integration**: Practice teaches you to efficiently coordinate a specific task pair as a unit 2. **Automatization**: Practice makes individual tasks automatic, allowing them to bypass the central bottleneck entirely 3. **Stage shortening**: Practice speeds up the bottleneck stages (response selection gets faster), but the bottleneck itself remains intact Their transfer-of-training experiments found that for most participants, the third hypothesis - stage shortening with an intact bottleneck - fully explained the improvement. The bottleneck didn't disappear; tasks just moved through it faster. However, a minority of participants in certain conditions did show evidence of genuine automatization, bypassing the bottleneck altogether. ### The Neural Evidence: Faster Processing, Not Parallel Processing Dux, Tombu, Harrison, Rogers, Tong, and Marois (2009) provided the clearest neural account. They trained participants daily for two weeks on two simple sensorimotor tasks while tracking brain activity with fMRI. Key findings: - Training reduced dual-task costs by approximately 50% over two weeks - The improvement was driven by faster, more efficient information processing in the posterior lateral prefrontal cortex (the neural locus of the bottleneck) - Training did *not* create parallel processing pathways - the brain was still processing one task at a time - As Dux stated: "Even after extensive practice, our brain does not really do two tasks at once. It is still processing one task at a time, but it does it so fast it gives us the illusion we are doing two tasks simultaneously." The prefrontal cortex showed decreased and more efficient activation patterns with training, and pattern analysis revealed that neural representations of the two tasks became more distinct - the brain was sharpening its task representations rather than learning to run them simultaneously. Verghese, Garner, Mattingley, and Dux (2016) followed up with a 100-person study showing that the volume of the left dorsolateral prefrontal cortex predicted individual training gains - meaning some people are structurally better positioned to benefit from dual-task training than others. ### Bottleneck Bypass: Possible but Extremely Narrow While stage shortening is the dominant mechanism, genuine bottleneck bypass - where a practiced task runs in parallel with an unpracticed one - has been demonstrated under very specific conditions. Schumacher, Seymour, Glass, Fencsik, Lauber, Kieras, and Meyer (2001) showed that after relatively modest practice (five sessions), some participants achieved "virtually perfect time sharing" on basic choice reaction tasks. Maquestiaux, Lague-Beauvais, Ruthruff, and Bherer (2008) found that after six sessions of single-task practice on a simple auditory-vocal task, 17 out of 20 young adults could bypass the bottleneck when that task was paired with an unpracticed visual-manual task. But the conditions required for bypass are revealing: - **The tasks must be simple sensorimotor mappings** with consistent stimulus-response associations (e.g., press left for low tone, press right for high tone) - **Sensory-motor modality compatibility matters enormously**: bypass works best with compatible pairings (visual-manual + auditory-vocal) and fails with incompatible ones (visual-vocal) because incompatible pairings create conflicts within modality-specific working memory (Maquestiaux, Ruthruff, Defer, and Ibrahime, 2018) - **The practiced task must not greedily recruit central resources**: even tasks that *can* run automatically will seize the bottleneck when it's available, re-creating interference (Maquestiaux et al., 2008) - **It requires thousands of training trials on consistent mappings** - the kind of repetitive practice that has no analog in knowledge work ### Age Sharply Limits Bypass Capacity Maquestiaux, Lague-Beauvais, Ruthruff, Hartley, and Bherer (2010) found a dramatic age difference: while the vast majority of young adults bypassed the bottleneck after training, at most 1 out of 12 older adults could do so - even with identical training. Maquestiaux, Didierjean, Ruthruff, Chauvel, and Hartley (2013) replicated this with *double* the training (10,080 trials across 12 sessions). Older adults' single-task reaction times dropped to levels identical to young adults, yet they still could not bypass the bottleneck. The ability to automatize novel tasks to the point of bottleneck bypass appears to decline with age, independent of overall processing speed. ### The Coordination Skills Hypothesis Strobach and Schubert (2024) reviewed evidence for a "memory hypothesis" of dual-task improvement: practice doesn't eliminate the bottleneck or make tasks automatic, but instead improves the executive ability to rapidly load both task sets into working memory at the start of a dual-task trial. This coordination skill - efficiently instantiating and switching between task representations - explains why dual-task practice sometimes transfers to new task combinations that share similar coordination demands. However, the authors explicitly note that this hypothesis has only been investigated with relatively easy component tasks. Whether it generalizes to complex tasks with high working memory demands remains unknown. ### Transfer Is Severely Limited Perhaps the most practically important finding: dual-task training benefits are overwhelmingly task-specific. Bender, Filmer, Garner, Dux, and colleagues (2017) trained participants on a combined visuomotor tracking and discrimination task for six sessions. Multitasking performance on the trained tasks improved substantially, but this improvement "did not generalize to a wide range of cognitive tasks that are theoretically linked to the current dual-task paradigm." The conclusion: training induces learning of task-specific coordination skills, not a general enhancement of multitasking ability. Ewolds, Broeker, de Oliveira, Raab, and Kunzell (2021) found that even when two tasks were made individually predictable through practice, the benefits of predictability remained contained within each task - they didn't combine to reduce overall dual-task interference. Dual-task practice didn't change this. Meta-analyses of cognitive training more broadly (Sala & Gobet, 2017; Kassai, Futo, Demetrovics, & Takacs, 2019) consistently find that training produces "near transfer" (improvement on similar tasks) but not "far transfer" (improvement on dissimilar cognitive abilities). As one review summarized: training a component did not have a significant effect on untrained components. ### One Notable Exception: NeuroRacer Anguera, Boccanfuso, Rintoul, and Gazzaley (2013), published in *Nature*, demonstrated something unusual. Older adults (60-85) who trained on NeuroRacer - a custom 3D video game requiring simultaneous driving and sign detection - not only improved their multitasking performance beyond untrained 20-year-olds, but showed transfer to *untrained* cognitive abilities including sustained attention and working memory. These gains persisted for six months. Neural measures showed enhanced prefrontal theta power resembling patterns seen in younger brains. The critical nuance: the researchers argued this transfer occurred because NeuroRacer enhanced general *cognitive control* processes (the ability to maintain an engaged, goal-directed state under interference), not multitasking ability per se. The game's adaptive difficulty algorithm continuously pushed participants beyond their comfort zone, preventing the automatic processing that typically limits training effects. This is more about training the executive control system than about making dual-tasking easier. ### What This Means for Knowledge Work The training research carries a clear, somewhat uncomfortable implication for knowledge workers: **What training \*can\* do**: Speed up processing of well-practiced, routine task components. If you process the same types of Slack messages, the same types of code review comments, or the same types of form-filling operations hundreds of times, the response selection for those tasks will get faster, leaving more room for interleaving with other work. **What training \*cannot\* do**: Make novel, complex cognitive tasks run in parallel. You cannot "practice" your way into simultaneously writing a design doc and debugging a production issue. These tasks inherently require the problem state resource, involve novel combinations of information, and demand the kind of central executive engagement that resists automatization. The bottleneck isn't a skill deficit - it's a structural feature of how cognition works. **What training \*might\* do**: Improve your general cognitive control - your ability to maintain focus, resist distraction, and manage interference. But this is best achieved through sustained, adaptive cognitive challenge, not through practicing multitasking itself. ### What Happens Beyond Two Tasks Research on triple-tasking is limited but the results that exist are stark. Stefani, Sauter, and Mack (2025) directly tested the transition from dual-task to triple-task performance. Key findings: - Response times increased from single to dual to triple tasks, but the increase from dual to triple was only about 43% of the increase from single to dual, suggesting a non-linear (but still costly) scaling pattern - Unlike in dual tasks where typically only one of the two responses is delayed, in triple tasks *all three subtasks* showed elevated response times - Even with extensive dual-task training beforehand, triple-task costs persisted - preparation helped initially but the advantage diminished over sessions - Task coordination, rather than simple stimulus-response mapping, became the dominant source of interference Konishi, Berberian, de Gardelle, and Sackur (2021) found something arguably more alarming: triple-tasking didn't just degrade performance on the three tasks - it degraded participants' *awareness of how well they were performing* (metacognitive sensitivity). People became worse at the tasks *and* worse at knowing they were worse. This metacognitive impairment was independent of the performance cost itself, suggesting it reflects an additional resource demand that monitoring and self-evaluation place on the same limited cognitive machinery. This means that the subjective feeling of "managing well" during heavy multitasking is itself unreliable evidence. ### The Conditions Where Dual-Tasking Actually Works Synthesizing across the bottleneck research, multiple resource theory, threaded cognition, and the problem state findings, dual-tasking provides net benefit over mono-tasking specifically when: **1. One task has genuine idle time that the other can fill.** This is the throughput argument. If Task A involves 40% active cognition and 60% waiting (for a build, a query, a response from someone), and Task B can productively fill those wait periods without disrupting Task A's problem state when Task A becomes active again, total throughput increases. This is not multitasking in the popular sense - it's efficient scheduling of a serial processor. Examples: monitoring CI output while drafting notes; reviewing a slow-loading dashboard while composing a message; waiting for a deploy while scanning a queue of simple approvals. **2. The tasks draw on different resource pools (per Wickens).** Listening to ambient music (auditory, no verbal processing demand) while coding (visual, verbal, spatial). Walking while having a phone conversation. These work because the tasks don't compete for the same perceptual, cognitive, or motor resources. What *doesn't* work: reading Slack while writing a document (both visual, both verbal, both require a problem state). Reviewing code while participating in a meeting (both require verbal comprehension, both require a problem state). **3. One task is highly automated and doesn't require a problem state.** Tasks that have been practiced to the point of automaticity don't consume central bottleneck resources or the problem state resource. Driving on a familiar highway is automatic enough that you can carry on a conversation. Typing is automatic enough that you can focus on the content you're composing rather than the keystrokes. But notice: for knowledge workers, the "tasks" that matter - writing, reading code, debugging, designing, reviewing - are virtually never automatic. They are inherently novel, requiring active problem state maintenance and central executive engagement. The things you can automate alongside them are relatively trivial. **4. Context-switching cost is low because the problem state is simple or externally stored.** If you can fully offload the problem state of Task A to an external representation (a document, a checklist, a clear stopping point) such that re-entry is cheap, then alternating between A and B becomes more viable. The cost of switching is dominated by problem-state reload time. If there's no complex mental model to reconstruct, the cost is low. This is why alternating between two *procedural* tasks with clear checkpoints (e.g., process this form, then process that form) is much cheaper than alternating between two *creative* or *analytical* tasks (e.g., write this section of the spec, then debug this architectural issue). ### The Conditions Where Mono-Tasking Dominates Single-task focus is unambiguously superior when: - **The task requires deep problem-state maintenance**: Any work where you need to hold a complex mental model - writing a design doc, debugging a multi-component system, conducting a code review that requires understanding architectural intent, synthesizing research into a coherent argument. - **Both potential tasks are cognitively demanding and share resource pools**: Two verbal-cognitive tasks, two tasks requiring visual attention and working memory. The research is unequivocal that performance on both degrades. - **Quality matters more than throughput**: Dual-tasking doesn't just slow you down; it increases error rates. For tasks where errors are expensive (writing contracts, reviewing security-sensitive code, making strategic decisions), the quality cost of divided attention exceeds any throughput gain. - **The task benefits from sustained attention and flow**: Csikszentmihalyi's flow state and Newport's deep work framework are consistent with the cognitive science here. The central bottleneck and problem state resource work most efficiently when focused on a single demanding task. Interruptions, even brief ones, force problem-state reloading that can take minutes for complex cognitive work (Mark, 2005, found 23+ minutes for full re-engagement after significant interruptions; Carnegie Mellon research found even brief interruptions increased task completion time by up to 23%). ### Why Multi-Tasking (>2) Is Almost Always Wrong for Knowledge Work The research case against juggling three or more cognitively demanding tasks simultaneously is strong: - **Triple-task costs persist even after extensive dual-task training** (Stefani et al., 2025). The skills that help you manage two tasks don't cleanly transfer to three. - **Metacognitive monitoring degrades** (Konishi et al., 2021). You lose the ability to accurately assess your own performance, which means you can't effectively self-correct or prioritize. - **Task coordination itself becomes a resource-consuming activity**. With two tasks, coordination is relatively simple (alternate). With three or more, the scheduling problem becomes its own cognitive burden, consuming resources that could be devoted to the actual work. - **Error rates compound non-linearly**. Each additional task doesn't just add its own error probability - it degrades the executive control that would catch errors in the other tasks. For knowledge work - coding, design, writing, analysis - where tasks almost universally require problem state maintenance, verbal/spatial processing, and central executive engagement, multi-tasking beyond two is a net negative on both throughput and quality. ### Practical Framework ![img](/blog/planning-work-for-our-single-threaded-brains/image_2.webp) ### Key References - Pashler, H. (1994). Dual-task interference in simple tasks: Data and theory. *Psychological Bulletin*, 116(2), 220-244. - Wickens, C. D. (2002). Multiple resources and performance prediction. *Theoretical Issues in Ergonomics Science*, 3(2), 159-177. - Wickens, C. D. (2008). Multiple resources and mental workload. *Human Factors*, 50(3), 449-455. - Salvucci, D. D., & Taatgen, N. A. (2008). Threaded cognition: An integrated theory of concurrent multitasking. *Psychological Review*, 115(1), 101-130. - Borst, J. P., Taatgen, N. A., & van Rijn, H. (2010). The problem state: A cognitive bottleneck in multitasking. *Journal of Experimental Psychology: Learning, Memory, and Cognition*, 36(2), 363-382. - Sigman, M., & Dehaene, S. (2006). Dynamics of the central bottleneck: Dual-task and task uncertainty. *PLoS Biology*, 4(7), e220. - Held, M., Rieger, J. W., & Borst, J. P. (2024). Multitasking while driving: Central bottleneck or problem state interference? *Human Factors*, 66(5), 1564-1582. - Stefani, M., Sauter, M., & Mack, W. (2025). Multi-tasking costs in triple-task performance despite dual-task preparation. *Memory & Cognition*, 53(6), 1637-1655. - Konishi, M., Berberian, B., de Gardelle, V., & Sackur, J. (2021). Multitasking costs on metacognition in a triple-task paradigm. *Psychonomic Bulletin & Review*, 28(6), 2075-2084. - Schumacher, E. H., et al. (2001). Virtually perfect time sharing in dual-task performance: Uncorking the central cognitive bottleneck. *Psychological Science*, 12(2), 101-108. - Ruthruff, E., Van Selst, M., Johnston, J. C., & Remington, R. (2006). How does practice reduce dual-task interference: Integration, automatization, or just stage-shortening? *Psychological Research*, 70(2), 125-142. - Dux, P. E., Tombu, M. N., Harrison, S., Rogers, B. P., Tong, F., & Marois, R. (2009). Training improves multitasking performance by increasing the speed of information processing in human prefrontal cortex. *Neuron*, 63(1), 127-138. - Verghese, A., Garner, K. G., Mattingley, J. B., & Dux, P. E. (2016). Prefrontal cortex structure predicts training-induced improvements in multitasking performance. *Journal of Neuroscience*, 36(9), 2638-2645. - Maquestiaux, F., Lague-Beauvais, M., Ruthruff, E., & Bherer, L. (2008). Bypassing the central bottleneck after single-task practice in the psychological refractory period paradigm. *Memory & Cognition*, 36(7), 1262-1282. - Maquestiaux, F., Lague-Beauvais, M., Ruthruff, E., Hartley, A., & Bherer, L. (2010). Learning to bypass the central bottleneck: Declining automaticity with advancing age. *Psychology and Aging*, 25(1), 177-192. - Maquestiaux, F., Didierjean, A., Ruthruff, E., Chauvel, G., & Hartley, A. (2013). Lost ability to automatize task performance in old age. *Psychonomic Bulletin & Review*, 20(6), 1206-1212. - Maquestiaux, F., Ruthruff, E., Defer, A., & Ibrahime, S. (2018). Dual-task automatization: The key role of sensory-motor modality compatibility. *Attention, Perception, & Psychophysics*, 80, 752-772. - Strobach, T., & Schubert, T. (2024). A mechanism underlying improved dual-task performance after practice: Reviewing evidence for the memory hypothesis. *Psychonomic Bulletin & Review*, 31, 1035-1053. - Bender, A. D., Filmer, H. L., Garner, K., Dux, P. E., et al. (2017). Dynamic, continuous multitasking training leads to task-specific improvements but does not transfer across action selection tasks. *npj Science of Learning*, 2, 14. - Anguera, J. A., Boccanfuso, J., Rintoul, J. L., et al. (2013). Video game training enhances cognitive control in older adults. *Nature*, 501(7465), 97-101. - Strobach, T., & Schubert, T. (2017). No evidence for task automatization after dual-task training in younger and older adults. *Psychology and Aging*, 32(1), 28-41. - Mark, G., Gonzalez, V. M., & Harris, J. (2005). No task left behind? *Proceedings of CHI '05*. --- # Conversation → Decisions → Strategy > Watch a live conversation become a strategy document. Decisions with context, not just notes. Published: 2026-01-27 - Author: jake - URL: https://withstoa.com/blog/conversation-decisions-strategy No Google Doc. No Notion page. No one taking notes.