STED
2026
STED - What if teams caught the risk before making the promise?
81% of project professionals say projects have become more complex, while only 41% of agency teams trust that things don’t slip through the cracks.
STED is a pre-project decision workspace for small agencies that brings delivery expertise into the decision earlier — surfacing uncertainty before it becomes a client commitment.
PMI — Pulse of the Profession 2026 ↗ · State of Agency Operations 2026 ↗
STED
The Cost of Committing Too Early
For small agencies and product studios, winning new work is only half the challenge. The other half is knowing whether the team can actually deliver what is being promised.
A new opportunity can move quickly from a client brief to an estimate. Delivery Leads may need to assess timelines using the information and past experience available to them — before designers, engineers and other specialists have validated what the work actually requires.
What begins as a rough estimate can quickly become a client expectation.
When that estimate is wrong, the cost is real:
Tighter margins · Unplanned contractors · Overtime · Missed deadlines · Damaged client trust
How might we help teams move from a rough estimate to a commitment they can confidently deliver?
Problem
The Problem Wasn’t Missing Information. It Was Hidden Uncertainty.
I started with a simpler question: could teams move from a new opportunity to an estimate more efficiently?
The research pointed to a deeper problem.
Resource and capacity constraints can affect what teams are able to promise, while specialist input can arrive after important decisions have already started taking shape.
My product analysis showed another gap: existing tools tend to support either the sales pipeline or project delivery. The handoff connects the two, but often happens after the opportunity has already been won.
Source: State of Product Management 2026 ↗
What mattered wasn’t simply whether information was missing. It was whether the team knew what was still uncertain before acting on it.A timeline might depend on an integration being possible. An estimate might assume specialist capacity is available. A requirement might still need technical validation. An unresolved question becomes dangerous when it starts behaving like a fact.
Rationale
The Delivery Lead sits in the middle
The Account Lead brings the client context. Specialists understand what the work actually requires. The Founder brings the commercial perspective.
The Delivery Lead has to bring those perspectives together and assess what the team can realistically deliver.
That made the Delivery Lead my primary user — not because they own every decision, but because they’re closest to the point where commercial expectations have to become delivery reality.
I was no longer asking:
How can teams create estimates faster?
I was asking:
How can teams understand what they know, what they don’t, and what still needs validating before they commit?
STED focuses on one decision:
Should we commit to this opportunity — and under what conditions?
Not every unknown needs to be resolved before work moves forward. Some need answers; others can become explicit assumptions or accepted risks, with their potential impact on time, cost or resources visible to the team.
STED doesn't eliminate uncertainty. It makes clear what uncertainty the team is willing to carry forward.
AI
AI finds the signal. People decide what it means.
STED uses AI both inside the product and in my design process. In both cases, the principle was the same: AI could accelerate the work without owning the judgment.
Before generating UI, I defined STED’s roles, decision ownership and AI boundaries, then built its visual foundations in Figma. I gave Claude that system and those product constraints before exploring the interface.
SYSTEMISE — I built STED’s visual foundations in Figma using variables, visual rules and reusable patterns.
GENERATE — I gave Claude Design the product constraints and Figma system to generate the first interface direction.
CHALLENGE — I tested Claude’s output against the product model and challenged decisions that didn’t fit how STED should work.
REFINE — I took the strongest direction back into Figma and refined it into the final interface.
I tested the highest-risk product moments first, then expanded the direction once the system and product behaviour held up.
CLAUDE PROPOSED — Linear 1–8 journey · Generic AI findings · “Requires clarification”
I CHALLENGED
→ Persistent context
Opportunities evolve as information changes. The interface needed persistent context rather than a mandatory sequence.
→ Evidence over certainty
AI findings needed to explain why something was flagged and show their source where possible.
→ Human review
“Needs your review” replaced system-authoritative language, while Accept / Edit / Remove kept control with the Account Lead.
→ PRODUCT CONSEQUENCE
· Persistent opportunity navigation
· Evidence-backed AI findings
· Explicit human review
AI accelerated the first pass. Product judgment determined what survived it.
Reflection
Proving Ground
STED is a product hypothesis, not a shipped product.
The next step wouldn’t be adding features, but testing whether the workflow helps agencies make better decisions without making the process feel heavier.
First, I’d test the decision model
I designed STED around Delivery assessing feasibility and the Founder / Account Lead making the commercial decision.
But agencies work differently. I’d test whether those responsibilities should remain fixed or whether teams need configurable decision ownership.
Then I’d measure what happens after commitment
The important question isn’t whether people can use STED. It’s whether the decisions hold up once the work becomes real.
I’d measure:
Estimate accuracy · Post-kickoff surprises · Scope changes · Unexpected resources · Decision time
Together, these would show whether STED improves clarity before commitment without simply slowing opportunities down.
The clearest sign that STED is working would be fewer surprises after commitment.
And I’d close the loop
STED currently captures what the team believed before the project started:
Estimate · Assumptions · Risks · Conditions · Dependencies
The next question I’d explore is:
What if STED could compare those expectations with what actually happened?
What we expected → What happened → What we learned → Better next decision
Over time, that could reveal where an agency repeatedly underestimates work, which assumptions create problems and where specialist input needs to happen earlier.
Instead of making the next decision from memory, the team could learn from its own delivery history.