In 2012, 37signals (now Basecamp) was deep into rebuilding their project management software. The team had sprint plans, prioritized backlogs, and weekly standups with shared docs. By conventional productivity standards, they were doing everything right.
They were also, by their own account, consistently shipping features nobody was asking for in the ways people actually needed them.
Jason Fried and David Heinemeier Hansson have written about this period in Rework and later in Shape Up, their internal methodology document that eventually went public. The core diagnosis they arrived at was uncomfortable: structured meetings were producing the illusion of alignment while masking genuine disagreement. Everyone left knowing what was decided. Almost nobody left knowing why, or whether they actually agreed with it.
The fix they landed on was a specific kind of unstructured conversation they called a “shaping” session. No agenda. No Jira tickets open in a browser tab. No slide deck. Just a small group of people, usually a designer and one or two senior engineers, in a room with a whiteboard, talking around a problem until something crystallized.
This is worth sitting with for a moment, because it sounds like the opposite of what productivity culture tells you to do. Every meeting best-practices article will tell you to circulate an agenda beforehand, assign a timekeeper, end with documented action items. Basecamp did the opposite and got better outcomes. Why?
The agenda problem is subtler than it looks. When you send an agenda before a meeting, you are not just organizing the meeting. You are also pre-framing the problem space. You are telling people what the relevant considerations are before they have had a chance to think about it fresh. People arrive having already formed positions. The meeting becomes a negotiation between pre-baked views rather than a genuine exploration.
Software engineers will recognize the analogy immediately. It’s the difference between writing tests before you understand the problem versus writing tests after. Test-driven development (TDD) works well when you know what “correct” means. When you don’t know what correct means yet, writing tests first just locks in your current misunderstanding.
An agenda-first meeting does the same thing. It locks in the current misunderstanding of the problem at precisely the moment when you most need to question it.
Basecamp’s shaping sessions had one constraint, and it mattered: the output had to be a concrete concept with rough boundaries and explicit unknowns, not a list of features and not a project plan. Fried describes this as giving the problem “an appetite” before giving it a solution. They would decide how much time a problem was worth (say, two weeks of engineering work) before deciding what to build. This forced the conversation to stay connected to tradeoffs rather than drifting into wishlist territory.
The absence of an agenda did not mean the absence of structure. It meant the structure was generative rather than procedural. The goal was to think together, not to process a queue.
This distinction matters enormously in technical work, where the shape of a problem changes as you understand it better. A bug that looks like a frontend rendering issue often turns out to be a caching misconfiguration upstream. A feature that sounds simple in a product spec often reveals a database schema problem that was papered over two years ago. (If this dynamic sounds familiar, the engineer who fixes the bug rarely knows why it existed is a useful frame for why that keeps happening.)
When you have a rigid agenda item that says “Discuss user onboarding flow,” you tend to discuss the onboarding flow. When you have a blank whiteboard and a vague prompt like “users keep dropping off, what’s actually going on,” you are more likely to discover that the real problem is something adjacent to what you thought you were solving.
The team at Basecamp was not the only one to notice this. Amazon’s famous “six-pager” culture operates on a related insight. Jeff Bezos banned slide deck presentations for senior leadership meetings and required written memos instead, partly because the act of writing full sentences forces clarity that bullet points allow you to fake. The meeting then starts with everyone silently reading the memo, which functions as a kind of synchronization step before open discussion. No pre-formed positions from a circulated agenda. The structure lives in the document, not in the meeting’s procedural scaffolding.
What both approaches have in common is that they treat the meeting as a place for genuine cognitive work, not status reporting. The agenda-heavy meeting is optimized for accountability and coverage. The agenda-light (or agenda-free) meeting is optimized for discovery and synthesis. Both are legitimate. Most organizations use the former when they need the latter.
The practical question is when to apply which. A few rough guidelines from watching teams work:
If you already know what decision needs to be made, an agenda is useful. If you’re not sure what decision needs to be made, an agenda is a liability. If the people in the room have roughly equal context on the problem, structured discussion works fine. If context is asymmetric, you need a format that lets the person with the most context download it before you start debating solutions. If the output needs to be a list of tasks, structured meetings are efficient. If the output needs to be a shared understanding, structure often gets in the way.
Basecamp eventually codified their shaping process into a six-week cycle where shaped work was handed to teams who then had full autonomy over implementation. The shaping sessions were still agenda-free. The downstream work was highly structured. They were solving different problems.
The broader lesson is not that agendas are bad. It’s that organizations tend to apply meeting structure uniformly across all kinds of thinking, and that’s where they go wrong. Exploration requires slack. Definition requires constraint. Most meeting culture applies constraint to everything and then wonders why teams keep solving the wrong problems precisely.
If your team is consistently shipping things that don’t quite fit what users needed, or making decisions that seem coherent in the meeting and confused three weeks later, it is worth asking whether your meetings are structured for the kind of thinking you actually need. Sometimes the most productive thing you can do is clear the calendar invite description, show up with a marker, and start asking questions that don’t have answers yet.
