Shape Up: The Basecamp Method Made Practical in 2026
- What Shape Up actually proposes
- Why most teams break the method
- The five things to actually adopt
- How to start the practice without breaking everything
Ryan Singer published Shape Up in 2019. Since then, a thousand product teams have tried to adopt it, broken it, and gone back to two-week sprints. The method works. The adoption usually doesn't. The reason is almost always the parts teams skip—the "uncomfortable" structural changes that require moving away from micromanagement and toward high-agency autonomy.
In 2026, the landscape of product development has shifted. We have better AI-assisted tools for drafting, more distributed teams, and a higher expectation for velocity. Yet, the core struggle remains: how do we stop shipping "features" and start shipping "solutions" without burning everyone out?
What Shape Up actually proposes
Shape Up is Basecamp's response to the agile-industrial complex. It isn't just a different way to organize tickets; it’s a wholesale rejection of the ticket-based philosophy. The methodology rests on three pillars: Six-week cycles, fixed time/variable scope, and the concept of "Shaping."
The core insight: most product work is messier than two-week sprints can hold, and most agile rituals optimize for predictability over outcomes. Two weeks is enough time to fix bugs or polish a button, but it’s rarely enough time to solve a meaningful user problem from scratch.
A Shape Up cycle starts with shaped work. Someone—usually a founder, PM, or senior designer—writes a pitch. The pitch defines the problem, the rough solution boundaries, the "appetite" (Small Batch = 2 weeks, Big Batch = 6 weeks), and the "rabbit holes" to avoid. The pitch isn't a 50-page PRD; it’s a high-level sketch that leaves room for the team to breathe.
When the cycle starts, the team has full autonomy. No daily standups required. No story points. The team owns the project end-to-end. Time is fixed; if the six weeks are up, the project is done (or it’s "circuit-broken" and discarded). Scope flexes to fit the deadline. This connects deeply to better product thinking—Shape Up forces you to think about whether work is shaped before you commit six weeks of expensive engineering time to it.
Why most teams break the method
The first failure is keeping the "Agile Reflex." Teams try to adopt Shape Up but insist on keeping daily standups and Jira tickets. When you do this, you kill the autonomy that makes the six-week cycle work. Shape Up requires "The Betting Table," not "The Backlog." If a project doesn't get finished in the cycle, it doesn't automatically roll over. It’s gone. You have to bet on it again if you want to keep working on it. Most teams find this level of discipline terrifying.
The second failure is the "Shaping Bottleneck." In many organizations, the PMs are so busy managing the current cycle that they don't have time to shape the next one. This leads to teams starting a cycle with "unshaped" work—vague ideas that haven't been de-risked. When a developer hits a "rabbit hole" three weeks in because the technical constraints weren't explored, the cycle collapses.
Finally, teams skip the "Cooldown." The cooldown period (usually 2 weeks between cycles) is when teams catch up on bugs, infrastructure, and explore new ideas. It's not optional rest; it's structural breathing room. Without it, the "Big Batch" projects feel like a never-ending treadmill, and technical debt accumulates until the product becomes a legacy mess.
Making Shape Up Practical in 2026
In 2026, we have an advantage Ryan Singer didn't have in 2019: AI as a shaping partner. Today’s expert PMs use LLMs to stress-test their pitches, asking the AI to "act as a skeptical lead engineer and find the rabbit holes in this pitch." This speeds up the shaping process significantly.
To make Shape Up work in a modern, often remote-first environment, you need to lean into three specific adjustments:
- The "Async-First" Standup: Instead of a 30-minute Zoom call, use Hill Charts. A Hill Chart represents work in two phases: "Figuring it out" (uphill) and "Getting it done" (downhill). It provides a visual status of where the team is without requiring them to explain every sub-task.
- The Distributed Betting Table: In 2026, the "room where it happens" is usually a shared document or a Loom video. Record the pitch, let the stakeholders comment asynchronously, and make the "bet" based on written evidence of the appetite.
- Modular Cooldowns: For larger teams, you don't need the entire company to be on cooldown at once. You can stagger cycles so that the "Platform" team is on cooldown while the "Growth" team is mid-cycle. However, be careful—this can lead to the very silos Shape Up aims to break.
A Practical Example: The "Adaptive Learning" Module
Imagine we are building a new "Adaptive Learning" feature for a platform like Omie.
The Appetite: 6 weeks (Big Batch). The Pitch: "Our users are overwhelmed by the course list. We want a 'Smart Path' that suggests the next three lessons based on their previous quiz scores. We aren't building a full AI tutor yet—that’s a rabbit hole. We are just building a logic engine that maps quiz tags to lesson tags." The Shaping: The designer provides "Fat Marker Sketches"—rough UI that shows the flow but doesn't specify the font size or the exact hex code of the buttons. The lead dev spends two days checking if the database schema can support tag-based querying without a total refactor.
Week 1-2 (Uphill): The team realizes the "quiz tags" are inconsistent. They spend this time normalizing the data. The Hill Chart shows them "Uphill" for the logic engine. Week 3-4 (The Peak): The logic is figured out. Now it's just implementation. They move to the "Downhill" side of the Hill Chart. Week 5-6 (The Finish): They realize they won't have time for the "Fancy Animation" when a path is generated. Because the scope is variable, they cut the animation and focus on the accuracy of the recommendations. The Result: At the end of week 6, they ship a functional, accurate logic engine. They use the Cooldown to fix the minor CSS bugs and plan the "Fancy Animation" as a Small Batch for the next cycle.
Conclusion: Trading Predictability for Progress
Shape Up is a commitment to quality over quantity. It acknowledges that software development is a creative, non-linear process that cannot be squeezed into 80-hour increments without losing its soul. By defining the "Appetite" instead of the "Estimate," you shift the conversation from "How long will this take?" to "How much is this problem worth to us?"
In 2026, the teams that win aren't the ones who move the most tickets from left to right. They are the ones who solve the most meaningful problems with the least amount of wasted effort. That requires the discipline to shape, the courage to bet, and the trust to let your teams build.
Curious if your current product processes are helping or hurting your velocity? Run a quick scan to identify where your team's "rabbit holes" are hiding.