The nine tools on this site start from an initiative someone has already chosen. This page covers what happens before and around that: where ideas for development come from, how they're sorted, and how each kind of work gets funded. I'm designing it as a lightweight, Kanban-based alternative to traditional agile methods, with AI assisting four things: inputs, the workflow, verification, and support after release. It's a proposal, and the toolchain changes it calls for aren't built yet.
One portfolio, one value stream. Every portfolio is built around a single value stream with its own architecture, applications, teams and business concerns. Each portfolio runs this framework separately, with its own intake, lanes, funding gates and capacity split.
Some architecture spans portfolios. Everyone uses Jira, and most portfolios share enterprise front-end and back-end technology such as identity, a design system, the data platform and cloud infrastructure. I group those into six shared platform portfolios, each funded on its own, shown at the bottom of the diagram.
Ideas come in at the top, get sorted once, and land in one of three places. Both funded lanes draw on the same delivery teams.
Signals keep personas (01 Discover) and journeys (02 Map) current.
Feeds 03 Intake when a theme grows.
Validate runs UX research, architecture work and a proof of concept to size the build before the second gate.
Standing budget, no per-item approval
08 Plan (Backlog Builder) → 09 Deliver (Build Planner) → Jira
Both lanes draw on the portfolio's teams.
Placeholder. Each portfolio's executives set its split.
A source can start work, add evidence to work already moving, or both. The full list is below.
The size test is one feature: one to four team-weeks, the toolchain's own feature size. Signals that aren't actionable yet go to the insight pool.
Invest pays twice. A small amount, fixed before work starts, buys discovery. A large amount buys the build, after discovery has sized it.
Run work is ordered continuously against a fixed share of capacity, with no business case per ticket.
AI drafts and people decide at each of the four points. Code recomputes every number a draft states, so a model's figures are never taken on trust.
| Point | What AI drafts | What people own | Status |
|---|---|---|---|
| Inputs | Clusters tickets, account notes, research and reviews into themes, and proposes how each theme should be sorted, citing every excerpt. Code counts the tickets, accounts and revenue. | The sort and its thresholds | Proposed |
| Workflow | Drafts each step's document: initiative and epics, business case, ranking inputs, roadmap, requirements, backlog, batch plan, and a build prompt for each story. Code recomputes scores, the funding cutoff, requirement coverage, batch loads and dependency order. | Review and edits at every step, and both funding decisions | Built, on sample data |
| Verification | Today, a named person must confirm or defer each assumed requirement before the backlog is built. Proposed: tests drafted from acceptance criteria, and a check that each build meets its requirements before release. | Release approval | Partly built |
| Support after release | Sorts incoming tickets into Fix and Enhance, summarizes incidents, and compares results with the benefits plan set at Initiative Intake (03). | Severity, on-call, and whether an initiative keeps its funding | Proposed |
Twenty-eight sources in five families. A filled dot means the source often starts work at that step. A ring means it adds evidence there.
Each level answers a narrower question on a shorter clock, and lands at a different step.
Economy, regulation, demographics
Category size, growth, analyst views
Who buys, and which needs go unmet
What rivals ship and charge
What has become possible or cheaper
| Insight | Invest | Run | Deliver | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Source | 01Discover | 02Map | 03Intake | 03bValidate | 04Justify | 05Rank | 06Schedule | 07Spec | 08Plan | Fixqueue | Enhancequeue | 09Deliver |
| Market & technology | ||||||||||||
| Macro and regulatory trendsEconomy, policy, demographics | ||||||||||||
| Industry and category researchAnalyst reports, market sizing | ||||||||||||
| Segment researchNew or under-served buyers | ||||||||||||
| Competitive intelligenceLaunches, pricing, feature gaps | ||||||||||||
| Technology researchEmerging tech, vendor capabilities, cost curves | ||||||||||||
| Customer voice | ||||||||||||
| User research (generative)Interviews, field studies, jobs to be done | ||||||||||||
| UX research (evaluative)Usability and prototype tests, accessibility audits | ||||||||||||
| Customer supportTickets and chats | ||||||||||||
| Customer successAccount health, renewals, escalations | ||||||||||||
| Surveys and reviewsNPS, CSAT, app stores, community | ||||||||||||
| Product analyticsFunnels, adoption, experiments | ||||||||||||
| Sales & marketing | ||||||||||||
| Win/loss analysisWhy deals close or don't | ||||||||||||
| Deal requests and RFPsAsks tied to named deals | ||||||||||||
| Marketing feedbackCampaign results, positioning and message tests | ||||||||||||
| Launch and event datesConferences, campaigns, seasonal peaks | ||||||||||||
| Partner and channel requestsIntegrations, reseller asks | ||||||||||||
| Leadership & internal | ||||||||||||
| Strategy and OKRsAnnual plan, Hoshin Kanri, board goals | ||||||||||||
| Executive asks and internal commsChat, email, town halls | ||||||||||||
| Budget and financial targetsBudget envelopes, cost-reduction goals | ||||||||||||
| Internal users and operationsBack-office pain, process gaps | ||||||||||||
| Legal and complianceRegulation, audits, contract terms | ||||||||||||
| Engineering & operations | ||||||||||||
| Portfolio architectureRunway, end of life, scalability | ||||||||||||
| Shared platform portfoliosDelivery, cloud, security, data and AI, integration, digital experience | ||||||||||||
| Technical debtAging code, upgrade backlog | ||||||||||||
| Incidents and reliabilityPostmortems, missed service-level objectives | ||||||||||||
| Security findingsPenetration tests, vulnerability scans | ||||||||||||
| Delivery metricsCapacity, cycle time, DORA metrics | ||||||||||||
| Engineer proposalsHackathons, spikes, design proposals | ||||||||||||
Fix and Enhance would both land in the Backlog Builder (08 Plan) through a run intake that doesn't exist yet. The 08 column under Invest is today's path, where a requirements document becomes the backlog.
A large initiative gets two funding decisions. The first is small and fixed before work starts. It pays for the UX research, architecture and proof of concept needed to size the second, which is large.
Two to eight weeks, sized to the unknowns, with a small team: a designer, an architect, one or two engineers and a product manager. The length is set at the gate and holds, so the cost is known before anyone approves it.
Initiative Intake (03) already records each epic's riskiest demand, feasibility and viability assumptions. Discovery tests them.
Scope in and out, an estimate range, the architecture runway, and the risks that remain. Stopping here is a good outcome, because the loss is small and known.
The business case (04 Justify) is built on the readout and ranked (05 Rank). Money is released milestone by milestone from the roadmap (06 Schedule), so each release is a checkpoint.
| Discovery track | Tests | Work | Gives the business case |
|---|---|---|---|
| UX and user research | Demand: will people want it and use it? | Concept and prototype tests, journey validation | Scope: what's in and what's out |
| Architecture | Feasibility: can we build and run it? | Target-state design, integration spikes, key non-functional requirements | Runway epics, dependencies, non-functional requirements |
| Proof of concept | Feasibility: the single riskiest unknown | Build the hardest piece at small scale and measure it | An estimate range from actual build data |
| Business | Viability: is it worth it? | Cost model, pricing, conversations with design-partner customers | Cost, benefits and KPI baselines |
The budget lane and the accounting treatment are separate questions. Invest is planned as CapEx. Under US GAAP for internal-use software, FASB's ASU 2025-06 starts capitalization once management has authorized and committed to funding a project and it's probable the project will be completed and the software used as intended.1 The threshold isn't met while significant development uncertainty remains, such as unproven functions that coding and testing haven't resolved yet, or significant performance requirements that are still being substantially revised.2
So discovery and proof-of-concept work is usually expensed, and it's also the work that clears the way to capitalize the build. The update applies to annual periods beginning after December 15, 2027, with early adoption allowed.2 Software sold to customers follows different rules, and so do IFRS reporters. Each company's controller makes the call.
Run work is funded as a fixed share of team capacity. Items are ordered against each other continuously, with no business case per item.
Six themes, each funded as its own portfolio. Their customers are the value-stream portfolios, which take platform changes to the platform's intake as requests and track them in their own roadmap as dependencies.
| Portfolio | What's in it | Main customers |
|---|---|---|
| Software Delivery Platform | Jira configuration, source control, CI/CD, test frameworks and environments, supply-chain security scanning, feature flags, release verification, observability and on-call, DORA and flow metrics, a developer portal, guardrails for AI coding assistants | Engineering teams |
| Cloud & Infrastructure | Cloud accounts and landing zones, networking, containers, managed databases, backup and disaster recovery, cloud cost management | Applications at runtime |
| Security & Identity | Customer and workforce sign-on, multi-factor authentication, access control, secrets and keys, security monitoring, vulnerability management, privacy and consent | Everyone |
| Data & AI Platform | Warehouse or lakehouse, data pipelines, event streaming, catalog and governance, BI, analytics instrumentation, model hosting, a model gateway and evaluation tools | Analysts, data scientists, AI features |
| Integration & APIs | API gateway, partner API portal, messaging and events, an integration platform, B2B and partner integrations, webhooks | Partners and other systems |
| Digital Experience Platform | Design system and components, front-end frameworks, content management, notifications, search, localization, accessibility standards | End users, through every interface |
Two more groups usually stay with corporate IT, outside this framework: the digital workplace (chat, email, office suites, laptops) and corporate systems of record (ERP, CRM, HR and finance, often including payments and billing).
Both lanes are boards with work-in-progress limits. Work moves when the next column has room, and teams deliver in batches of two days to two weeks. There's no fixed planning cycle to commit to.
Each part of the framework builds on published work. This is where each idea started, and how the framework uses it. What it adds is the AI layer: each step drafted from cited evidence, every number recomputed in code, and a named person making each decision.
| Idea | How this framework uses it | Where it comes from |
|---|---|---|
| Value streams | One portfolio per value stream | Lean Enterprise Institute, definition of a value stream3 |
| Resources made available as needed, without fixed annual budget allocations | Executives set each portfolio's split, and initiatives earn discovery money before build money | The Beyond Budgeting principles4 |
| Stream-aligned teams, and platforms run as products | Value-stream portfolios and the six shared platform portfolios | Matthew Skelton and Manuel Pais, Team Topologies5 |
| Pull, limits on work in progress, explicit policies | The Invest and Run boards, replenished at the weekly intake review | The Kanban Method, from David J. Anderson's work6 |
| Flow metrics | Cycle time, throughput, work in progress and work-item age on both boards | The Kanban Guide7 |
| Flow distribution across kinds of work | The Invest, Enhance and Fix split | Mik Kersten, Project to Product, and its Flow Framework8 |
| Cost of delay, and weighted shortest job first (WSJF) | Ranking epics in the Epic Prioritizer (built) | Donald G. Reinertsen, The Principles of Product Development Flow (2009)9, with Joshua Arnold's cost of delay divided by duration10 |
| RICE scoring | The alternative score in the Epic Prioritizer (built) | Sean McBride, Intercom11 |
| Desirability, feasibility and viability | The riskiest assumptions recorded at 03 Intake, and the 03b Validate tracks | IDEO's design thinking12 |
| Minimum viable product; build, measure, learn; pivot or persevere | The Validate readout: proceed, pivot or stop | Eric Ries, The Lean Startup13 |
| Appetite, the betting table, and the circuit breaker | A discovery time-box that holds once set, and funding gates treated as bets | Ryan Singer, Shape Up14 |
| Software delivery performance metrics | How the Software Delivery Platform measures itself | DORA15 |
| Change | Where | Status |
|---|---|---|
| Sort each input by size and uncertainty. This can start as a weekly intake review before it becomes a tool. | A new front step | New |
| Tie every run to one portfolio, and show dependencies on shared platforms as cross-portfolio enablers. Today there's one implied portfolio. | 03 Intake, 06 Schedule | Change |
| Let signals keep personas and journeys current between initiatives | 01 Discover, 02 Map | Partly exists |
| A discovery plan and readout, built from Initiative Intake's riskiest assumptions | New step 03b Validate | New |
| Build the business case on the readout, with the estimate as a range | 04 Justify | Change |
| Two funding decisions: discovery first, then the build released by milestone | 03 Intake, 05 Rank, 06 Schedule | Change |
| A run intake that takes tickets and requests straight into the backlog | 08 Plan | New |
| Each batch holds the portfolio's capacity split | 09 Deliver | Change |
Both lanes run as Kanban boards with WIP limits. Teams deliver in batches of two days to two weeks, with no fixed planning cycles and no added roles.
One to four team-weeks. It matches the toolchain's own feature size, so the sort uses a unit the tools already understand.
The first gate picks the length to fit the unknowns: about two weeks for one technical question, up to eight for a new product area. The length holds once it's picked, so the gate approves a known cost.
It has its own outputs and its own funding gate. Numbering it 03b keeps every existing step number and link stable.
Each portfolio's executives set its split, and it will differ by portfolio. A new product may run mostly Invest, while a mature one with a heavy support load may carry more Run. The 60/25/15 in the diagram is only a placeholder.
They're funded on their own, grouped by theme, with the value-stream portfolios as their customers.
The nine tools this framework would sit around are live and run on fictional sample data. Document Flow shows each step as built, and Proposed Architecture covers what a production version would add.