Shape Up Method

Point: Replace task breakdowns with "hills" to emphasize deliverables rather than task completion, avoiding misjudgment and false progress in progress tracking.

Logic chain: Completing tasks does not mean the output is close to usable. A hill is a visible, verifiable piece of output; only when hills are crossed one after another does real project progress occur, shifting the team's focus to completion status rather than busyness.

Failure condition: If the nature of the project is closer to maintenance or reactive work, where efforts are hard to define as clear, identifiable "hills," this progress management method needs adaptation.

Related fields: Product & Operations, Technical Engineering

The six-week project cycle represents a sound balance between value delivered and effort invested. It is long enough to complete meaningful work, yet short enough for the team to feel the deadline from the start and use time wisely.

The logic chain is: shorter than six weeks → fragmented requirements and frequent planning → higher management costs; longer than six weeks → the deadline feels distant → the team loses awareness of progress → higher risk of delays. Six weeks is the sweet spot between urgency and output scale.

When it fails: for innovation projects that require a longer exploration phase, or mobile projects with very short iterations, six weeks may not be optimal; it should be adjusted based on business type.

Related areas: Product & Operations, Project Management.

Point: Requirement analysis should not be treated as a mechanical step on an assembly line. Instead, it should carry the responsibility and authority to own the quality of requirements, transforming business ideas into actionable plans.

Logic chain: Traditional processes assign requirement analysis as a segmented task to "workers" who lack ownership. Shaping, by contrast, requires turning an idea into a Pitch that clarifies the problem, solution, boundaries, and risks—without making the final decision (betting). This positioning improves requirement quality and reduces downstream waste.

Failure conditions: The organizational culture does not recognize the Shaper role, granting responsibility without authority; or Shapers lack business or technical judgment, producing low-quality Pitches.

Related areas: Product & Operations; Management & Team

Opinion: Shaping work requires a combination of skills, including product design, business understanding, and basic technical feasibility assessment.

Logic chain: To propose the right high-level requirements, one needs to design product solutions, judge business value (appetite), and assess technical risks. It is often difficult for a single person to possess all these capabilities, so multi-person collaboration is usually required. This also raises the bar for the professional competence of the people involved.

Failure conditions: If team members have narrow skill sets and cannot collaborate effectively, or if the team relies too heavily on a single full-stack shaper, bottlenecks can arise. If technical assessment is not thorough, significant risks may still be hidden.

Related areas: Career Development, Product & Operations

Perspective: Effective requirement documents must clearly specify exclusions (No-gos), setting boundaries to focus on value.

Logic Chain: By formally agreeing in the pitch on which features and use cases are intentionally out of scope, you can prevent scope creep, keep the team focused on the core problem, and make the appetite and time frame realistic, keeping the problem manageable.

Failure Conditions: Exclusions omit critical scenarios, or stakeholders later overturn the agreement and forcibly add back previously excluded content; alternatively, boundaries are drawn so narrowly that the product cannot meet the minimum viable standard.

Related Areas: Product and operations.

Viewpoint: Fixed Time, Variable Scope is an effective strategy for preventing project delays.

Logic chain: Leave flexibility in the implementation approach to the team, lock only core requirements and the deadline, and you can manage uncertainty and avoid delays caused by over-engineering. Variable scope protects the time box.

Failure conditions: Core requirements are unclear or change too frequently, leading to scope creep; the implementation team lacks the capability to deliver basic value within the limited time; or the fixed time is too tight, seriously compromising delivery quality.

Related areas: Product & Operations, Management & Team

Viewpoint: Requirement analysis should first determine the time budget (appetite) and business value, and then look for solutions within those constraints.

Logic Chain: Rather than asking how long something takes, ask how much time we are willing to spend—and how much time this idea is worth. Shaping requires defining the appetite first, using the cost ceiling to limit the solution space, ensuring that business value matches investment, and preventing blind development.

Failure Conditions: Value estimation may be inaccurate, or stakeholders may not agree on the appetite. When the market changes quickly, a fixed appetite can cause missed opportunities. Technology assessment errors can make it impossible to deliver a valuable solution within the time limit.

Related Fields: Product and operations, business model.

Viewpoint: True efficiency gains should start upstream in requirements definition, rather than merely optimizing downstream development processes.

Logic chain: Management problems require top-level design; efficiency problems should be answered at the most upstream point. By bringing value judgment and cost constraints forward through the Shaping phase, low-value requirements are filtered out at the source, avoiding projects that waste resources.

Failure conditions: If the organization lacks the multi-skilled talent required for Shaping, or if senior leadership does not support it, Shaping cannot take root and may degenerate into a ritualized process.

Related areas: Product & Operations; Management & Teams

Perspective: Product development should adopt a betting model rather than a planning model, to emphasize business judgment and accountability for outcomes.

Logic Chain: Planning merely fills a time window with work and prioritizes tasks, without demanding deep judgment on input-output returns. Betting, by contrast, requires management to weigh business value and strategic direction as if placing a wager, and to take responsibility for the decisions. Because bets are constrained by short cycles (e.g., six weeks), potential losses are limited, which encourages bolder decisions.

Failure Conditions: Betting becomes a mere formality when management lacks business judgment or a sense of accountability; short cycles are unsuitable for business contexts that require long-term planning.

Related Areas: Product strategy, R&D management, organizational decision-making.

Viewpoint

When everyone is only responsible for the tasks assigned to them, and no one feels accountable for the overall project outcome, the results often go off course. Therefore, the team must be held end-to-end accountable for value delivery (Pitch) within a defined scope.

Logic Chain

Task orientation tends to cause local optimization, interface wrangling, and the "done but not done well" phenomenon. End-to-end responsibility shifts the team's focus from isolated tasks to complete user value, prompting members to proactively fill the gaps between tasks—moving from "I completed my part" to "We delivered the outcome together."

Failure Conditions

If the team lacks the corresponding cross-functional skills and decision-making authority, forcing end-to-end accountability will only increase a sense of helplessness and a culture of blame. In mega-projects, a single team cannot be responsible for all value delivery; end-to-end responsibility must be broken down into manageable subsystem teams.

Related Areas

Accountability design, value delivery, task granularity.

Viewpoint: Managers should assign entire projects to the team rather than specific tasks. The team itself creates the tasks it deems necessary; no one acts as a task allocator, and no architect breaks down the project for others to implement.

Logic Chain: Assigning the project as a complete unit of value to the team—combined with the boundaries set by the Pitch—gives the team full autonomy to decide its own implementation path and task breakdown. This motivates technical staff by fostering self-drive and creativity, preventing them from becoming "code monkeys," while also giving the team a genuine sense of ownership over the final value delivered.

Failure Conditions: When team members are relatively inexperienced and lack the ability to break down tasks and self-organize, full autonomy may lead to misdirected efforts or missed critical tasks, requiring more scaffolded guidance. If the organizational culture remains command-and-control, granting autonomy but then frequently interfering afterward will undermine trust and create chaos.

Related Areas: Delegative management, autonomous teams, task allocation.

Viewpoint: Operational work accompanying a new feature—such as writing tasks, market launch, and user notifications—is usually not part of Cycle work and should be planned as separate activities.

Logic chain: Cycle focuses on software development itself. If operational tasks are mixed into the development timebox, they slow down the development cadence and fragment the team's attention. Operational preparation before and after product launch can proceed in parallel or later at its own pace; decoupling the two helps each become more specialized.

Failure conditions: If a feature launch strongly depends on certain operational actions to deliver value—for example, help documentation must go live at the same time to avoid overwhelming the service desk—then such tightly coupled operational items should be treated as one whole with feature delivery. Completely ignoring operational alignment leads to a delivery gap where "the feature is built but nobody knows how to use it."

Related domains: Development and operations collaboration, project boundary management.

Viewpoint: Backend programmers should write only the minimum code needed to move forward, mock the dependent technical components and unfinished external services as necessary, and prioritize getting core functionality working.

Logic chain: Replacing real dependencies with mocks (such as login systems, payments, and third-party APIs) prevents core logic from being blocked by surrounding parts that are not ready. Getting the critical functionality working first allows the highest-risk areas to be validated early, while real dependencies can often be added in a measured way after the core becomes stable.

Failure conditions: If the mocked parts are themselves high-risk or core functionality (such as core algorithms or authentication security), overusing mocks can distort early validation and delay exposure of the real risks. Without a follow-up mechanism, mock code may become leftover fake implementations that contaminate tests and production.

Related areas: Test doubles, risk front-loading, continuously evolving architecture.

Viewpoint

It is acceptable to first build a very rough UI just to get the functionality working end to end. Visual polish only matters before final delivery; it does not need to be a daily acceptance criterion during the project.

Logic Chain

Polishing visual details too early takes time away from validating core functionality and increases rework costs. Letting features run through a lowest-fidelity interface first allows the team to focus on logic and integration issues; visual refinement can then be completed through rapid iteration once the functionality is stable.

Failure Conditions

For products whose core selling point is visual experience—such as showcase websites or brand marketing pages—starting from a rough UI may make it difficult to later adjust the experience to match the brand tone. If the rough UI is retained for a long time without follow-up, the team may become accustomed to low standards, leading to lower delivery quality.

Related Domains

MVP development, interface fidelity, iteration strategy.

Viewpoint Because the Shaping phase produces sufficiently rich information—including concepts, boundaries, and rough wireframes—programmers do not need to wait for designers to finish final designs before starting development. Everyone on the team can begin actual work at the same time.

Logic chain The pitch has already conveyed the core interactions and constraints, so engineers can build the functional skeleton accordingly. Designers and engineers work in parallel, and design output can be implemented directly within the existing skeleton, reducing sequential time dependencies and shortening overall delivery time.

Failure conditions When product visual experience is critical and the basic interaction model cannot be agreed upon in advance—such as zero-to-one innovative interactions—development without design may lead to substantial rework. When Shaping quality is low and the information is insufficient, programmers cannot independently understand the requirements, and waiting for design is still necessary.

Related fields Design-development collaboration, parallel work, agile design.

Viewpoint: In projects with separated frontend and backend, integrable vertical features must be treated as the smallest unit of work. Never wait until late in the project to integrate the frontend and backend for the first time.

Logic chain: Working in vertical slices (such as “user avatar upload”) rather than by technical layers (all frontend pages, all backend APIs) ensures that each slice can be independently integrated and tested. Early and frequent integration immediately reveals interface mismatches, inconsistent data structures, and similar problems, avoiding the massive integration pain of late-stage integration.

Failure conditions: For some pure backend data pipeline or pure frontend refactoring projects, vertical slices are difficult to define; in such cases, other integration verification points are needed. If team members specialize in a single technical layer, deliberate pairing or rotation is needed to avoid isolated development.

Related domains: Full-stack development, continuous integration, feature slicing.

Viewpoint: The team should first aim for something that can be demonstrated and used, completing a small, usable end-to-end slice as early as possible within the first week.

Logic chain: Producing a runnable slice early quickly validates the technical approach and integration points, exposes hidden risks, and gives stakeholders a concrete artifact to respond to. This is a “tracer bullet” strategy: it builds confidence and momentum instead of waiting until the end for the first integration.

Failure conditions: If the project depends heavily on upfront infrastructure setup, such as database selection or authentication systems, the first usable slice may be difficult to wire up safely within one week. In that case, the first path through the core infrastructure should be treated as the slice goal. If the team ignores code base quality for the sake of speed, the early slice may become a burden for later refactoring.

Related domains: Incremental delivery, front-loading risk, agile engineering practices.

Viewpoint

Scope and tasks in a project are not fully planned at the beginning; they are progressively discovered, refined, and created during development.

Reasoning

Planning all tasks in advance is often based on immature assumptions. As coding begins, the real complexity and dependencies are exposed; allowing tasks to emerge enables the team to adjust plans based on the latest information, focus on the most important current work, and reduce waste and rework caused by premature decisions.

Failure conditions

If the team lacks the ability to autonomously break down and organize tasks, or if there are no effective visualization tools to track emergent tasks, scope may get out of control. In environments with strong cross-team dependencies, certain upstream tasks may need to be locked in early, and a fully emergent planning approach can cause blocking.

Related domains

Rolling wave planning, emergent design, task decomposition.

Viewpoint

The mark of project completion is that the code actually goes live—not merely finishing the code or ending testing. Testing is work within the Cycle. The project allows no delays, and there are only two states: done and not done.

Logic Chain

Treating go-live as the definition of done eliminates the progress illusion of “development complete but not released,” forcing the team to complete all necessary work within the Cycle, including testing and deployment. Disallowing delays reinforces the “fixed time” principle, prompting the team to proactively cut scope or seek simpler solutions and avoid a culture of procrastination.

Failure Conditions

If the deployment path is constrained by external approval or compliance processes, and the team cannot autonomously control the go-live time, then “go-live equals done” may not hold. For hardware-related projects, manufacturing, logistics, and other steps may blur the concept of go-live, requiring an alternative agreed-upon Definition of Done.

Related Areas

Definition of Done, Continuous Delivery, Progress Management.

Viewpoint: Within each scope, the team explicitly divides the tasks that need to be completed into two categories: Must-Have and Nice-To-Have, thereby protecting the delivery of core functionality within a fixed timeframe.

Logic Chain: The dichotomy lets the team clearly know throughout the project what is a baseline requirement and what is an added bonus. When time is tight, they can decisively drop Nice-To-Have items without harming core value. This explicit prioritization also reduces decision fatigue and the tendency to invest equally in everything.

Failure Conditions: If the definition of Must-Have is too broad, or the team lacks consensus on priorities, almost all tasks will be marked as Must-Have and the classification becomes ineffective. In highly regulated or safety-sensitive systems, some compliance items that appear to be Nice-To-Have are actually indispensable, so the dichotomy requires more granular levels.

Related Domains: Task prioritization, project scope control.