Seed - Designing a Process Intelligence Platform from First Principles
“What if the moment a team decision started pulling the product off its original intent - silently, between tools, across handoffs - your stack could surface it as a question before it became a problem?”
Every product development project starts with a clear intent. Someone has identified a user problem, articulated the business motivation, and rallied a team around a shared goal. Then the work begins — and very quickly, that intent starts to bleed out.
This is the problem Seed is designed to solve.
The disappearing "why"
A PM writes the requirement in Notion. A designer interprets it in Figma, making dozens of micro-decisions that quietly reframe the original problem. An engineer receives a Jira ticket stripped of almost all context. Six weeks later, the product ships and nobody can clearly articulate the chain of reasoning that produced it.
This isn't a communication problem. It isn't solved by more meetings, better documentation, or switching tools. It is a structural problem: the current stack of product development tools was built around _artifacts_, not _intent_.
The most critical casualty in product development isn't the timeline or the scope. It's the "why" — the original intent that triggered the work, quietly lost between handoffs.
Documents don't carry the reasoning that produced them forward. Designs don't know why they exist. Tickets don't know what outcomes they contribute to.
The result at every scale:
- Features that solve the wrong problem
- Decisions made without full context
- Rework driven by misalignment discovered too late
- Weak connection between outcomes and the goals that motivated them
Where intent degrades
The handoff chain is where intent dies:
| Role | Tool | Intent retained |
|---|---|---|
| PM | Notion / Confluence | ~100% — fully articulated |
| Designer | Figma | ~60% — reconstructed from interpretation |
| Engineer | Jira / Linear | ~20% — stripped to "what", not "why" |
| Production | Shipped feature | ? — original user problem: unknown |
Artifacts persist. Reasoning doesn't.
What users actually told us
Before committing to any architecture, I ran structured research across product archetypes — simulated interviews and synthesis sessions grounded in my experience at Whatfix, where the DAP team operates at exactly this intersection of tools, process, and organisational intent.
Four personas emerged with distinct but overlapping friction patterns:
Product Manager
"I know what we're building and why. But three sprints in, I'm not sure everyone else does."
Gap: No living record of intent. Every retrospective starts from scratch.
Engineering Lead
"I get tickets. I build tickets. I don't always know what problem we're solving."
Gap: Decision context stripped from every task. Engineering in the dark.
Designer
"I'm constantly reconstructing the why from other people's artifacts. It's archaeology."
Gap: Designs made from interpreted intent, not source intent.
CTO / VP Engineering
"Cross-team dependencies are invisible until they blow up. Then it's too late."
Gap: No system-level view of how decisions interact across teams.
Three patterns cut across all personas:
- Intent erosion — reasoning degrades with every handoff
- Dependency blindness — cross-team impacts are invisible until damage is done
- Retrospective paralysis — teams can't learn from a shipped product because the reasoning chain no longer exists
The core insight: the latent friction layer
The insight that shaped Seed's design came from a specific question: _where does user intent meet product constraint, and what happens in that gap?_
Most product tools manage the visible layer of work — tickets, designs, roadmap items. But there's a latent layer underneath: the invisible surface where what a user is trying to do encounters what the product actually makes possible.
The most valuable product intelligence isn't hidden in feedback forms. It's hidden in the gap between what users attempt and what your product makes possible.
Seed's premise: if you can model intent explicitly — make it structured, visible, and continuously connected to every downstream decision — you can surface these gaps _before_ they cause damage.
The Smart Canvas: a living ontology for product decisions
The theoretical core of Seed is the Smart Canvas — an ontological substrate: a structured representation of the relationships between the decisions, entities, and intentions that constitute a product at any given moment.
The four entities of a product decision
| Entity | Description | Effect |
|---|---|---|
| Intent | What the user is trying to achieve | shapes |
| Context | The state the product and user are in | constrains |
| Decision | The product's designed response | produces |
| Outcome | The resulting user state or action | feeds back |
Three layers
Entity layer — _What exists._ Users, goals, features, states, touchpoints. The named things in your product's world, defined precisely enough to reason about.
Relationship layer — _How things connect._ Dependency, conflict, enablement, sequence. Typed edges between entities that carry meaning.
Inference layer — _What the canvas can reason._ Given current entities and relationships, what decisions remain unmade? What conflicts are latent? What intent signals are unserved by any existing node?
"Intent without context is a wish. Context without intent is noise. The canvas holds both — and the relationship between them — at once."
Technical architecture: kernel and domain packs
The kernel (invariant)
Five invariants that hold across every domain:
- Every node has provenance — it knows which tool and text produced it
- Every decision carries a confidence score
- Every tension is expressed as a question (not a warning)
- Every intent is continuously tracked against all nodes
- No decision can be committed while there is an open high-severity tension with a shared resource
Domain packs
| Pack | Levels | Cost model |
|---|---|---|
| Software | Platform → Product → Feature → Service | Linear (1×) |
| Hardware | Program → System → Component | Exponential (EV 3×, DVT 40×, PVT 150×) |
| Service design | Policy → Programme → Channel | Compliance weight ×2.5 |
Org customisation layer
Sits on top of domain packs. Companies add their own gate policies, approval rules, and regulatory requirements without touching the underlying architecture.
The tension detection engine
The most distinctive design decision: tensions are expressed as questions, not warnings.
Every tension in a product development process is a question someone hasn't asked yet. Expressing them as direct questions — with concrete paths forward and explicit tradeoffs — changes the emotional register from "warning to dismiss" to "decision to make."
Four tension types
Level mismatch — a feature-level decision is silently modifying a platform-level contract.
Scope drift — work that wasn't in the original intent is appearing in the process graph.
Dependency blindspot — a change affects downstream systems or teams who haven't been informed.
Intent conflict — two decisions in the graph are pulling the product in contradictory directions.
Examples from the Spotify demo
level_mismatch · high
The ad-targeting endpoint touches the shared monetisation contract — also consumed by Premium, Duo, and Student plans. Does the Platform team know this contract is being modified?
scope_drift · medium
Offline download mode for monetised episodes has been added to the sprint. This was not in the Q3 charter. Does this change the launch date?
dependency_blindspot · medium
The creator analytics node depends on the event-tracking service owned by the Growth squad. Has Growth been notified of the new event schema?
Design constraint: The intent coherence score cannot increase while there is an open high-severity tension. This prevents the illusion of progress while a structural problem remains unresolved.
Intent coherence scoring
The most visible metric in Seed: a continuously updated percentage measuring how well the current process graph serves the program's stated intents.
It's not a health score. It's a measure of directional alignment — whether the work being done pulls toward or away from the original intent.
Spotify — Podcast Monetisation squad:
- Launch ad insertion API for podcast creators — 84% (product · tactical)
- Grow monetised podcasts by 40% — 76% (product · strategic)
- Maintain ad-serving API contract integrity — 91% (platform · strategic)
Three reference organisations
Spotify — Software pack
Podcast Monetisation squad. Platform → Feature levels. 6 data sources: Jira, Confluence, Figma, Slack, GitHub, Productboard. 3 active tensions.
Dyson — Hardware pack
AM-12 Purifier Air Max program. Exponential cost model (EV: 3×, DVT: 40×, PVT: 150×). 5 data sources: PTC Windchill, Altium Designer, Octopart, Confluence, LabVIEW. Key tensions: 47mm vs 52mm housing conflict, MCU 28-week lead time vs 12-week buffer, FCC Part 15 certification gap.
GDS UK Gov — Service design pack
Universal Credit digital claim journey. Compliance-weighted cost model. 5 data sources: Jira, Confluence, Miro, GOV.UK ↗ Design System, axe. Key tensions: WCAG 2.1 AA failures blocking beta, missing DPIA for biometric identity data, 23% abandonment from channel inconsistency.
The Dyson demo made something clear that software demos obscure: the cost of a decision isn't just its complexity — it's its reversibility at the stage you're in. A design conflict discovered during EV costs hours. In DVT, weeks.
The live engine
The conceptual test application integrates with Claude's API. Type a process step and the engine:
- Extracts a structured node from the input
- Infers its level and type from the domain pack vocabulary
- Assigns an owner from the team list
- Checks whether the new node creates tensions with existing nodes
- Updates the process graph in real time
"The goal isn't to replace the tools your team already uses. It's to give those tools a shared memory — and to surface the questions your process is already generating, before they become blockers."
What building Seed taught me
Intent is a data structure, not a document.
Treating intent as something you write in a PRD and then reference in meetings is the root cause of almost every product alignment problem. Intent needs to be a first-class data structure — something the system stores, updates, and reasons about continuously.
Tensions are better expressed as questions.
Every tension is a question someone hasn't asked yet. Expressing tensions as direct questions changes the emotional register from "error state" to "decision to make."
Domain vocabulary matters more than generic features.
The same underlying engine produces completely different product intelligence when given the vocabulary of hardware engineering versus software versus service design. A generic engine with a domain-specific language layer is the right abstraction.
The hardest problem is irreversibility.
Software teams systematically underestimate the organisational cost of changing direction late because code feels reversible. A process intelligence platform should model irreversibility explicitly — as a live cost attached to every staged node.
What comes next
- Slack integration — reading decision signals from conversation, not just structured tools
- Hardware canvas — a proper physical component graph with BOM integration and tolerance stackup detection
- Tension surface redesign — moving tension detection into source tools. A Jira ticket that creates a tension should surface it in Jira.
- Multi-workspace graph — mapping intent relationships across programs, not just within a single squad
Discussion (0)
Loading...