Shaping the Future: Applying Product Management Wisdom to AI Coding

It's almost a daily headline: another AI promising to write our code faster, better. But beyond the hype, the real question is, how do we actually use these tools effectively? How do we guide them to build what we need without getting lost in generated code? Enter Shape Up, the product development methodology famed for guiding human teams at Basecamp, now evolving and adapting in diverse contexts. Its core principles offer a robust and practical framework for strategically directing AI coding agents, moving beyond simple commands towards genuine collaboration.

By adapting Shape Up's phases - particularly the evolved concepts around Framing, Shaping, Betting, and Building - we can unlock a more structured, efficient, and ultimately more valuable way to work with AI. This isn't about rigidly applying Basecamp's specific original practices (like fixed six-week cycles), but about leveraging the underlying, adaptable principles.

Framing & Shaping: Defining the Problem Before the Prompt

The foundation of Shape Up lies in crucial upfront work: first Framing the problem (understanding why it's worth solving, making the business case) and then Shaping it (designing the solution concept). This deliberate approach is especially vital when working with AI, which can easily veer into complexity or irrelevance without strong guardrails. The goal of Shaping is work that is rough (leaving room for implementation details), solved (the core elements and connections are defined, often collaboratively with technical input), and bounded (clear limits and exclusions).

Setting the Appetite

Forget vague requests. Shaping involves defining the "Appetite" - the fixed time budget allocated to a specific task or exploration. This embodies the principle of fixed time, variable scope. Instead of asking an AI to "build a login system," you first define the time budget. You might set a constraint like: "AI, spend no more than four hours exploring different encryption methods for user auth." This time-boxing focuses the AI, prevents it from going off on endless tangents (like trying every algorithm under the sun), and forces realistic solutions tailored to the investment you're willing to make. A smaller appetite naturally leads to simpler, more focused outcomes because the "best" solution is relative to the constraints. While Basecamp often used 6-week cycles, the principle of appetite applies flexibly - it could be hours for an AI exploration or weeks for a larger feature chunk.

Narrowing the Problem (Framing)

Vague problems yield sprawling, often useless, solutions - a pitfall amplified with AI. A broad prompt like "make the website faster" might return generic advice. Shape Up demands specificity, often starting with Framing: "What's really going wrong?" or "What's driving this request?" Is the issue conversion rates, user complaints, or a specific performance bottleneck? Narrowing the focus to "optimize image loading time on product pages to improve mobile conversion rates" guides the AI towards generating targeted, actionable code. This framing step clarifies the why and ensures the subsequent shaping focuses on the right problem.

Finding the Elements & Sketching the Solution (Collaborative Shaping)

Before prompting for code, outline the key components and workflow. This is Shaping proper. For an AI tasked with processing user data, sketch the expected inputs, core processing steps, and desired output format. Crucially, this often requires collaboration. As Ryan Singer emphasizes in the evolution of Shape Up, involving technical expertise during shaping is critical. It's not a "lonely genius" designer task. Product, design, and technical perspectives ensure the concept is viable. Techniques like Breadboarding (rough UI/workflow sketches focusing on places, affordances, and connections) and Fat Marker Sketches (low-fidelity conceptual drawings deliberately lacking detail) provide invaluable context. Giving the AI this high-level blueprint - collaboratively vetted for feasibility - helps it understand the purpose and generate more relevant solutions. The idea isn't necessarily a perfect, polished design but a solved concept where key trade-offs and the core architecture are understood. The level of detail ("latitude") can be adjusted based on the project and team needs.

De-risking (Spiking) and Declaring "No Gos"

Shape Up emphasizes proactively identifying potential pitfalls ("Rabbit Holes") and explicitly defining what not to do ("No Gos"). This is paramount with AI. Rather than just listing risks, effective shaping often involves Spiking - targeted investigation during the shaping phase to resolve critical unknowns before committing. If a particular API integration looks risky, the shaping process might include a small spike (potentially even tasked to the AI or a human expert) to verify assumptions. Clearly stating constraints like "do not alter the database schema" or "avoid introducing new dependencies without asking" prevents costly mistakes. Presenting the shaped concept for review helps catch potential issues before committing AI time.

The culmination of Shaping is a Package (an evolution from the term "Pitch") - a structured summary capturing the framed problem, appetite, collaboratively shaped solution concept, resolved risks (through spiking), and defined boundaries (no gos), ready for consideration. It's packaged in a way that's useful for the specific "builders" (AI + human reviewer) who will execute it.

Betting: Strategic Allocation of AI Capacity

With well-defined packages, the next phase is Betting. This involves consciously deciding which shaped tasks warrant committing resources - in this case, AI compute time and your review effort - potentially within a defined cycle (though the cycle length is flexible).

Instead of an endless backlog, Betting encourages selectivity: Bets, not backlogs. Prioritize the most promising, well-shaped packages based on factors like: Does the problem matter (Framing)? Is the appetite right? Is the solution attractive and technically viable (Shaping)? Is this the right time? Crucially, embrace the Circuit Breaker concept. If an AI task significantly exceeds its allocated appetite (e.g., budgeted 4 hours, running for 8+) without delivering useful results, don't let it run indefinitely. Intervene. Reassess the prompt, reshape the problem, or cut your losses. This prevents sinking endless compute resources into an unproductive task and forces a strategic rethink - failure within budget might indicate flawed shaping. Note that unlike Basecamp's original model, many teams may only shape one viable package at a time, making the "bet" more about whether to proceed with that single option rather than choosing between multiples.

Building: Guiding the AI Towards Completion

Once a bet is placed, the Building phase begins. Shape Up's principles provide guidance here too, fostering a more effective working relationship with your AI partner:

Hand Over Responsibility (Within Boundaries)

Just as Shape Up empowers small, autonomous human teams by assigning projects (shaped packages) not just granular tasks, give your AI a clear objective based on the package. Define the "what" and the constraints, but allow the AI reasonable autonomy on the "how." This contrasts sharply with ticket-based systems where work is pre-digested into tiny pieces. Giving the AI the higher-level goal and trusting it (within defined boundaries and "no gos") respects its capabilities and often leads to better solutions. This autonomy is empowering for the process, even with an AI.

Get One Piece Done

Tackle complexity by focusing on delivering a small, end-to-end slice of functionality first. Prompt the AI to create a working, albeit minimal, version of a core component. Choose a piece that is core to the concept, small enough to finish quickly, and ideally novel or risky to eliminate uncertainty early. This provides tangible progress, allows for quick feedback, and helps verify if the AI is on the right track.

Map the Scopes

Break down larger features into independent, manageable parts, or scopes, often discovered during the building phase. Address each part with separate, well-shaped prompts if needed. This modular approach makes complex tasks tractable and simplifies review. Scopes become the language for tracking progress.

Show Progress (Mentally)

While AI doesn't need a Hill Chart, the concept of work moving from uphill (figuring things out, unknowns) to downhill (execution, knowns) remains useful as a mental model for the human reviewer. Recognize the AI's internal "uphill" - interpreting prompts, exploring solutions - reaching the "crest" (converging on a plan), and then the "downhill" phase of code generation. This helps manage expectations.

Decide When to Stop

Resist endless refinement. Apply scope hammering - evaluate the output against the original shaped requirements and appetite. Compare the result down to the baseline. Ask: Does it solve the framed problem within the appetite? If yes, stop polishing. Cutting scope isn't lowering quality; it's making deliberate choices about what matters most. Stop when the job defined in the bet is done. Meaningful iteration happens after shipping, based on real-world feedback, rather than getting stuck in pre-launch refinement cycles.

Distinguish Planned vs. Reactive Work

Recognize that Shape Up is best suited for planned, strategic work where you can shape the problem and control the timebox. It's less suited for reactive work - urgent bugs, immediate stakeholder demands, tasks with uncontrollable external dependencies (like waiting on a third-party API provider). For reactive work, a Kanban or ticket-based system is often more appropriate to manage flow and urgency. Don't try to force everything into a Shape Up cycle; use the right process for the right type of work.

From Command to Collaboration

By thoughtfully adapting these evolved Shape Up ideas, we move beyond simply throwing prompts at an AI. We learn to proactively frame problems, collaboratively shape solutions with technical grounding, make deliberate bets, and guide the AI within clear boundaries. This methodology provides the structure needed to harness AI not as a magic black box, but as a powerful collaborator, leading to more focused, efficient, and valuable results. It's about bringing deliberate strategic thinking to how we integrate these tools.

As AI tools evolve, how might these principles adapt further? Could AI participate more actively in Framing and Shaping? Will the lines blur further? The underlying principles of clear problem definition (Framing), viable solution design (Shaping), fixed time variable scope (Appetite/Betting), bounded autonomy (Building), and deliberate decision-making, however, will likely remain essential for effectively integrating AI into the future of software development.

Glossary

Here are definitions for some of the key Shape Up terms used and mentioned in this article, incorporating nuances from its evolution: