SPECIFICATION

SLICE — A Product Delivery Framework for the AI Era

Founding specification · Version 0.1 · 16 October 2026

Archived version. Superseded by v0.2 on 16 October 2026. Written by Milber with OpenAI's models and reproduced from the text he provided; formatting converted to markdown and the interface label "Copy feature card" omitted. Wording is otherwise unchanged.

A lightweight, evidence-driven framework for planning, estimating and delivering digital products with AI-assisted teams.

I agree with your observation that planning can now take longer than implementation, particularly for relatively straightforward applications built with Lovable, Claude Code, Cursor and similar tools.

But that observation points to a deeper issue: we are increasingly using heavyweight, human-effort-based planning processes to coordinate systems where implementation is becoming cheaper, faster and less predictable.

The goal should not be to remove planning. It should be to make the cost of planning proportionate to the uncertainty and consequences of the work.

After comparing the established approaches, I propose that we formalise two complementary methods under one framework:

SLICE — Strategic, Lightweight, Iterative, Confidence-led Execution

SLICE Roadmapping — An outcome-led, continuously updated roadmap that connects strategy, initiatives, feature slices, milestones and measurable evidence.

SLICE Forecasting — A relative-sizing and probabilistic estimation method that accounts for AI acceleration, engineering risk, human capacity and actual delivery performance.

Core principle: Shape only what matters. Build in small slices. Forecast from evidence.

SLICE is a working proposal, not an established industry standard. A preliminary web review has not established uniqueness of the name, and a formal trademark, domain and literature clearance remains necessary before public launch.

1. Why a new framework is justified

Scrum and Kanban are not obsolete. Their fundamentals—empiricism, transparency, feedback and managing work in progress—remain useful.

What is changing is the economics of execution.

The 2025 DORA research found that AI acts as an amplifier of an organisation's existing engineering strengths and weaknesses, rather than providing a universal productivity multiplier. Meanwhile, METR's February 2026 follow-up explicitly cautioned that newer AI-agent productivity gains were difficult to quantify reliably because of participant-selection effects.

Shape Up already recognised the problem of excessive planning overhead and introduced fixed time appetites with flexible scope. The Kanban Guide establishes empirically useful flow metrics. Scrum deliberately leaves estimation techniques open.

SLICE should build on these foundations, while introducing five AI-era design decisions:

• Planning has a budget. We explicitly limit planning overhead rather than treating unlimited specification as a virtue.
• Specification is progressive. The team defines outcomes before details, and expands details only when uncertainty or consequences justify it.
• AI is an execution resource, not a capacity multiplier. Its benefits are measured in delivered outcomes, not assumed from tool capabilities.
• Forecasts are evidence-backed. Dates are separated into hypotheses, targets and genuinely supported commitments.
• Small teams are the default design case. The framework scales through coordination between teams, not through additional ceremonies imposed on everyone.

The distinctive proposition is the integration of these rules, not a claim that relative sizing, flow metrics or outcome roadmaps are new inventions.

2. The five principles of SLICE

These are the governing principles. A team can use them without adopting any particular project management software, AI vendor, sprint length or organisational structure.

3. Method One: SLICE Roadmapping

The roadmap is organised into five levels, but only the first four need to be visible in normal product management.

An initiative can contain multiple features; a feature can contain multiple slices; a slice can contain many AI-agent actions. Dates may be attached at different levels, but an estimate for one level must not be mistaken for an estimate of the entire parent.

The roadmap uses three planning horizons

Unlike fixed-quarter roadmaps, the horizons are not necessarily tied to calendar durations. Each team defines its own commitment boundary: how far ahead it can meaningfully commit to delivery.

For a solo founder, Now might span one or two weeks. For an established team, it may span four to six weeks. A regulated enterprise programme might require substantially longer lead times.

Four classes of roadmap item

Every item must have one of these types:

This avoids forcing every activity into the language of a feature. Discovery and risk reduction are legitimate investments, and not every task requires an invented revenue estimate.

Three rules for prioritisation

Prioritisation should be simple enough to use during a normal product discussion.

First, identify obligations and critical dependencies. A required security fix, for example, should not compete with an animation based on a RICE score.

Second, rank discretionary initiatives by expected value, urgency and available evidence. RICE, Cost of Delay or a simpler impact/effort comparison can be used depending on the quality of the available data.

Third, set a time or investment appetite. Rather than allowing a high-priority feature to expand indefinitely, decide how much capacity it deserves and reduce scope where appropriate.

There is deliberately no mandatory weighted priority formula in SLICE. A universal formula would encourage invented numbers and create a false sense of objectivity.

4. The Planning Budget: the first distinctive SLICE mechanism

Your observation that planning can take longer than implementation deserves an explicit framework rule.

I propose the Planning Budget.

Planning is treated as an investment with a cost and a stopping condition.

Progressive shaping

Choose the lightest planning mode that is safe for the decision and the work.

The time ceilings are starting policy proposals, not established empirical standards.

The stop-planning rule

Planning should stop when the team can answer four questions:

• What outcome or obligation are we addressing?
• What is the smallest useful, acceptable next slice?
• What is the most consequential unresolved risk?
• What evidence will demonstrate completion?

If those questions are answerable and the work is safe to begin, additional detail needs a specific justification.

If uncertainty prevents safe implementation, the next action is not a longer speculative document. It is a bounded investigation, prototype, customer test or technical spike that will reduce the uncertainty.

The point is not to maximise speed of coding. It is to minimise the time between an important decision and trustworthy evidence.

Measure planning overhead

SLICE records:

A team might initially aim to keep routine, low-risk feature planning below 20% of combined human effort. This is a suggested improvement hypothesis, not a universal performance target.

The metric should be reviewed alongside rework and defects. Planning that prevents a costly production incident is valuable even when its ratio is high.

5. Method Two: SLICE Forecasting

The estimation system separates three concepts that traditional planning often blends together:

Size describes the relative scope of deliverable work.

Risk describes uncertainty and potential consequences.

Forecast describes when accepted delivery may happen, given capacity and evidence.

AI execution capability is an additional contextual variable, not a substitute for these three.

5.1 Five sizes, no story points required

The most important decision is that sizes do not have fixed global hour or day equivalents.

A medium feature in an established codebase may take longer than a large frontend implementation in a clean, well-structured project.

Teams must calibrate size categories against their own completed work.

5.2 AI leverage

Assign one qualitative rating:

Do not automatically reduce a size when leverage is high. Leverage is a forecasting input, not a discount multiplier.

5.3 Delivery risk

Assess risk using four dimensions.

For normal work, a Low / Medium / High overall classification is sufficient, with the dominant risk recorded in plain language. A high consequence or difficult-to-reverse change cannot be averaged away by low scores elsewhere.

5.4 Forecast evidence levels

These are evidence labels, not guarantees of accuracy. A statistical forecast may still be misleading if its historical reference class no longer reflects the current product, team or tools.

5.5 The forecast calculation

For a single bounded slice:

For an initiative, the calendar forecast must also respect dependencies and parallel capacity. It is not necessarily the sum of all slice durations.

Once enough comparable delivery history exists, the forecast distribution should be calculated using an empirical model, such as resampling historical throughput or cycle times.

Recommended outputs are:

These probabilities are only meaningful when supported by a defensible and reasonably calibrated model. A judgment-based three-point estimate should not be relabelled as P50/P85/P95.

For work involving significant dependencies, the model should represent those dependencies or use a conservative scenario-based approach until adequate data exists.

5.6 Human capacity is the constraint

Instead of counting the number of AI agents, record effective human delivery capacity: the attention available to specify, integrate, review, approve and operate their outputs.

A single founder running six coding agents still has limited time to inspect generated changes and resolve conflicts.

AI concurrency is useful only until the next bottleneck—review, integration, deployment or decision-making—becomes saturated.

Therefore SLICE recommends limiting active work by available verification capacity, not by the number of agents that can be started.

6. The complete SLICE workflow

1. Strategy — Identify the outcome and prioritise the initiative.
2. Shaping — Define the smallest useful slice and its acceptance evidence.
3. Forecasting — Size, assess risk and establish a delivery window.
4. Execution — Build with human and AI capabilities.
5. Acceptance — Verify quality, release and observe.
6. Learning — Compare forecast with actual delivery and update the roadmap.

Continuous feedback into strategy, shaping and forecasting. This cycle is continuous. No sprint or ceremony is mandatory.

7. A minimal SLICE Feature Card

A team should be able to start most normal development work with one compact card.

SLICE FEATURE CARD · EXAMPLE · F1 forecast

Self-service subscription checkout

Outcome: Enable new customers to purchase and activate a subscription
  without manual intervention.
Size: L    AI leverage: High    Risk: High
First deliverable slice: A test-mode checkout flow that creates the correct
  customer entitlement after a confirmed payment.
Acceptance evidence: Successful payment, failed payment, delayed webhook and
  duplicate webhook scenarios pass automated tests.
Primary uncertainty: Webhook integration and entitlement consistency.
Forecast: Two to three weeks, judgment-based planning range, assuming existing
  authentication and a configured payment account.
Execution approach: Lovable for interface work; Claude Code or Cursor for
  backend implementation and tests; human approval for payment and database changes.

The card should expand automatically when the work is technically complex or high-consequence. It should not expand merely because someone prefers longer documentation.

8. How SLICE scales from one founder to hundreds of engineers

The same core structure should apply at every team size. Only coordination and assurance policies change.

The crucial scaling rule is that teams should preserve local autonomy. A central portfolio roadmap should not require every individual team to adopt identical cycle-time targets or velocity numbers.

Cross-team coordination requires explicit dependency ownership, interface contracts and integration milestones—not simply adding the individual estimates together.

9. The minimum metrics

I would define a small mandatory operational dataset, with additional measures for teams that need them.

The first four flow concepts are established Kanban practices; the planning and forecasting additions are SLICE proposals.

Beyond these, track product outcomes, delivery cost and operational risk when relevant.

Avoid turning the metrics into performance targets for individual engineers. People will naturally game measures that affect their evaluation, and AI-assisted engineering makes raw output metrics particularly easy to inflate.

10. Investor communication and commitment rules

An investor roadmap should present what the company intends to achieve, what it expects to deliver, when that might happen and which assumptions could change the outcome.

SLICE defines three commitment types.

Even a commitment can carry risk. SLICE does not equate a committed date with certainty.

The investor view should separate software completion from commercial success. Launching subscription billing may be a delivery milestone; achieving 100 paying customers is a business outcome and requires a different forecast.

11. Naming: what I would use publicly

I investigated several candidate directions. There are meaningful collisions in this space: for example, PACE is already used for an AI-driven sprint execution framework, while Proofline and Loom are used by existing AI-related products.

The shortlist I would carry forward is:

I would provisionally establish the naming architecture as:

• SLICE Framework — the full operating system.
• SLICE Roadmapping — the strategic planning method.
• SLICE Forecasting — the estimation and delivery prediction method.
• SLICE Guide — the openly published specification.

The word SLICE is common enough that distinctiveness and trademark suitability cannot be assumed. The full name and abbreviation need clearance before claiming ownership or investing in branding.

The public positioning should not be that SLICE replaces Scrum. It should be:

SLICE is a lightweight product planning and delivery framework designed for teams where AI accelerates implementation but human judgment, uncertainty and accountability still determine what ships.

12. What must be proven before calling it a formal methodology

We can finalise a coherent v0.1 specification today. We cannot honestly claim that the model has been validated or deserves industry adoption yet.

I propose three validation stages.

1. Internal pilot — Apply SLICE to several genuinely different digital products. Record planning effort, forecast errors, delivery throughput, integration failures and rework for at least 6–8 weeks.
2. Independent team pilots — Test the same core rules with solo founders, 2–5-person AI-first teams, conventional engineering teams and at least one larger multi-team organisation. Compare against each team's previous process.
3. Public community specification — Publish a short guide, templates, anonymised results, worked examples and an open feedback process. Revise the framework based on reproducible evidence rather than testimonials.

Success should be evaluated on more than perceived speed. The initial hypotheses are that SLICE reduces unnecessary planning effort, maintains or improves release quality, improves forecast calibration and makes investor communication more trustworthy.

Some improvements may conflict. If less planning produces more defects or costly reversals, the framework should adapt rather than declaring the experiment successful.

13. Initial conformance rules

To make SLICE a genuine framework rather than a collection of suggestions, v0.1 needs a small normative core.

An organisation using SLICE should:

• Maintain an outcome-connected roadmap with explicit Now, Next and Later distinctions.
• Break scheduled delivery work into independently verifiable slices, decomposing oversized items.
• Apply proportionate planning with risk-based escalation.
• Record relative size, dominant delivery risk and forecast evidence level.
• Distinguish delivery targets from commitments and business outcomes.
• Verify work against explicit acceptance criteria before counting it as delivered.
• Track delivery flow, planning effort, rework and forecast performance, using that evidence to update future plans.

The specific tools, project management platform, sprint cadence, AI models, role names and priority formula remain optional.

This is essential for adoption: teams should be able to practise SLICE without buying or installing anything.

14. Final v0.1 decisions

Final assessment

I would freeze this as the SLICE Framework v0.1, a sufficiently complete initial methodology for practical use and pilot testing.

Its potentially meaningful contribution is not inventing another set of ceremonies. It is establishing a coherent relationship between proportionate planning, progressive specification, AI-assisted execution, risk-based assurance and evidence-backed delivery forecasts.

The most important thing to test is the planning budget. If AI has dramatically reduced implementation effort for certain types of work, then requiring hours of meetings and documentation to authorise minutes of reversible development is economically irrational.

But equally, if AI makes implementation cheap while increasing the volume of code requiring review, a framework that merely encourages faster coding will make the bottleneck worse.

SLICE should optimise the whole system—from a valuable opportunity to a verified outcome—not the speed of one agent or developer.

That is the foundation I would put forward for community review.