Speculative design isn't an art school concept — it's a strategic foresight tool that helps SaaS product teams pressure-test their roadmaps, surface hidden assumptions, and make confident bets about where their product should go before the market tells them.
The strategic design practice that helps SaaS teams build for the future.
Most SaaS product teams are excellent at optimising the present. Sprint velocity is high. The backlog is groomed. Features ship on time. Retention is tracked, activation is measured, and the roadmap is locked for the next quarter.
And then a competitor ships something your users didn’t know they wanted, and suddenly your roadmap looks like a maintenance schedule.
The teams that avoid this pattern aren’t just better at execution. They’re better at imagination. Specifically, they’ve built a practice of asking what their product could become — not just what it should do next quarter — and they’ve found a structured way to translate those questions into strategy. That practice has a name: speculative design.
Speculative design is one of the most misunderstood tools available to product teams. It’s been framed as an art school discipline, an academic provocation, a design agency luxury. What it actually is — when adapted for the realities of SaaS product development — is a structured method for making better bets about where your product should go before the data tells you where it’s going. At Groto, we’ve brought speculative design into design-led product strategy work with SaaS teams across fintech, edtech, and analytics platforms, and the results consistently show up in roadmap clarity and feature confidence long before they show up in metrics.
What Is Speculative Design?
Speculative design sits at the frontier of the UX disciplines — a practice that uses designed artefacts (prototypes, scenarios, mockups, narratives) to explore possible futures rather than to solve present problems. Instead of asking “how do we fix this user friction today?” speculative design asks “what would our product look like if this friction didn’t exist, the technology changed, or our users’ context shifted entirely?”
The methodology was formally developed by Anthony Dunne and Fiona Raby at the Royal College of Art, whose 2013 book Speculative Everything framed the discipline as a counterweight to purely commercial design. This reflects a design philosophy built to question commercial assumptions rather than execute against them: design can be used not just to make things work, but to make people think — about what could exist, what should exist, and what exists now that we should question.
In a product context, speculative design means building artefacts from a 3–5 year horizon and working backwards — asking which digital product design principles remain durable across multiple possible futures, and what decisions made today increase the probability of reaching a preferred one.
The Futures Cone: A Framework for Thinking Ahead
The futures framework most commonly associated with speculative design is Stuart Candy’s Futures Cone — a model that maps four categories of possible futures:
Probable — the likely extrapolation of present trends. This is where most product roadmaps live.
Plausible — futures that could happen given different market or technology conditions. Realistic, but not guaranteed.
Possible — futures enabled by significant technological or behavioural shifts. Requires more of a leap.
Preferable — futures that represent a meaningful improvement over the present. The “what we’d build if we could build anything” zone.
Speculative design operates deliberately in the Plausible and Possible zones — far enough from today to be genuinely exploratory, close enough to be actionable.
Most roadmaps only operate in the Probable zone — they extrapolate from what users say today. Speculative design pushes teams to explore the Plausible and Possible zones, so they’re not caught off-guard when a competitor ships something users “didn’t know they wanted.”
Why Speculative Design Matters for SaaS Products
1. The Tools Most Teams Use Are Optimised for the Present
Common UX design methodologies — design thinking, design sprints, agile UX — are excellent frameworks for solving known problems faster. They’re built for iteration and validation of what already exists. None of them are built for invention or long-range strategic direction. The result? Teams get very good at optimising their current product, but miss the shifts happening just outside the frame of their current roadmap.
2. Users Can’t Tell You What a Better Paradigm Feels Like
User research and A/B testing are powerful tools for improvement. But they have a fundamental limitation: users can only give feedback on things they’ve already experienced. They can tell you what they struggle with inside the current product. They can’t tell you what a fundamentally different version of it would feel like — or whether they’d prefer it. Speculative design fills that gap. It lets teams explore design directions that don’t yet exist in any form their users could react to.
3. Design-Led Strategy Is Measurably Better for Growth
McKinsey research shows companies that excel at design outperform industry benchmarks by 2:1 in revenue growth. The differentiator isn’t execution quality alone — it’s strategic design vision. The products that compound over time are built by teams that had a clear idea of what they were building towards before the market validated it.
4. It Builds Shared Direction Across the Team
When a product team has no shared vocabulary for where the product is heading, every roadmap discussion becomes a negotiation from scratch. Speculative design gives teams a set of documented scenarios, assumptions, and design artefacts that everyone can reference. That shared language makes decisions faster, reduces misalignment between product and engineering, and gives founders a more compelling vision to communicate to boards and customers.
Speculative Design vs. Design Thinking vs. Design Sprints — When to Use Which
These three approaches are frequently confused because they all involve design and all claim to produce better products — a confusion that runs parallel to the broader question of what the difference between UX and product design means in practice. They do not do the same thing.
Design thinking is a problem-solving methodology. It's optimised for deeply understanding a current user problem and generating creative solutions to it. The output is a solution prototype for a validated pain point. Use it when you have a specific problem that needs creative reframing.
Design sprints (the Google Ventures methodology) are five-day structured processes for rapid prototyping and user testing of a specific hypothesis. They're optimised for reducing risk on a near-term product decision. Use them when you have a product question that a week of focused work and user testing can resolve.
Speculative design is a strategic foresight tool. It's optimised for exploring possible futures and identifying which design decisions made today position you best across multiple scenarios. The output is not a solution — it's a set of artefacts, scenarios, and strategic questions that change how you think about the next 12–36 months of product development. Use it when you need to reset the strategic frame, not solve a problem within the current one.
The teams that use all three well don't use them interchangeably — and the strongest agencies embed speculative design at the top of the UI/UX strategy framework they use to drive growth. They use speculative design to set direction, design thinking to solve the hardest problems within that direction, and design sprints to validate specific bets along the way.
The SaaS Speculative Sprint: Our Approach at Groto
Most speculative design guidance assumes an open-ended research timeline — month-long explorations with no deliverable deadline. That doesn't fit how SaaS product teams actually work.
At Groto, we've developed what we call the SaaS Speculative Sprint — a two-half-day structure that brings speculative design into the working rhythm of a product team without asking them to slow down. The goal isn't to produce a creative exercise. It's to produce documented strategic artefacts that are useful in the next roadmap conversation.
Half Day 1 — Expanding the Frame
We open with three future scenarios for the product's domain — one Probable, one Plausible, one Possible. These aren't predictions. They're pressure points. The team's job is to react to them, not evaluate them.
From there, we do assumption mapping — surfacing every assumption embedded in the current roadmap. What would have to be true about users, technology, and market conditions for the roadmap to succeed? Seeing those assumptions written down and visible together is frequently the most clarifying moment of the entire engagement.
The half-day closes with teams designing speculative artefacts — a product screen, a user workflow, an interface pattern — from inside one of the future scenarios. The artefact doesn't need to be realistic. It needs to be coherent within the scenario it's imagining.
Half Day 2 — Translating Into Strategy
We look for recurring patterns across artefacts — design decisions that appeared across multiple scenarios, and tension points where the current roadmap and speculative direction conflict.
Insights get mapped onto a 3-horizon framework:
Near — decisions that affect the next quarter
Medium — items worth putting on the 12-month roadmap
Far — design or technology investments that position the product for 2–3 year scenarios
The most significant artefacts get refined into one-page documented scenarios: the speculative context, the design artefact, and the strategic implication. For teams building out a structured product design roadmap, these become living documents referenced in roadmap reviews, used in investor conversations, and revisited at the next speculative session.
The full SaaS Speculative Sprint produces three to five documented scenarios, a surfaced assumption map, and explicit strategic bets mapped across all three horizons — in seven hours of focused team time.
Real-World Examples of Speculative Design in Practice
Turning Speculative Artefacts Into Roadmap Priorities
The most common failure mode after a speculative design session is treating the output as inspiring but inactionable — a creative exercise that doesn’t change anything downstream. The SaaS Speculative Sprint is designed to prevent this, but the translation step requires explicit process.
The filter we use at Groto is the Recurrence Test: any design pattern, interaction model, or product assumption that appears in more than one speculative scenario is a candidate for roadmap consideration. A pattern that appeared in two out of three futures scenarios isn’t a prediction — it’s a signal that the pattern is robust across uncertainty. That robustness is what makes it worth investing in before the market confirms it.
Speculative artefacts that pass the Recurrence Test should be brought into the product team’s regular review cadence — not as features to ship, but as strategic hypotheses to track. As real-world signals accumulate (competitor moves, user behaviour shifts, technology releases), the team has a framework for interpreting them against a documented strategic context rather than reacting in isolation.
Common Mistakes SaaS Teams Make With Speculative Design
Treating it as a design exercise, not a strategy exercise
Speculative design produces designed artefacts, so it’s easy to treat it as a design team activity— a misread of what product designers actually do in product development. The most important participants are the people who make product and technology decisions. If the CTO and Head of Product aren’t in the room, the outputs won’t influence the roadmap.
Evaluating artefacts instead of learning from them
The natural product team instinct when presented with a speculative prototype is to critique it: “this isn’t technically feasible,” “users wouldn’t use this.” Both responses miss the point. Speculative artefacts aren’t proposals — they’re probes. The question is what assumptions they surface and what strategic questions they raise, not whether they should ship.
Running it once and stopping
A single speculative session is better than none, but its value compounds over iterations. The first session produces scenarios. The second session tests those scenarios against what’s changed. The third produces genuinely predictive strategic clarity. Teams that run one session and conclude “it was interesting but inconclusive” have stopped exactly when the method starts paying off.
Keeping it separate from the roadmap
Speculative outputs left in a Notion page or a Figma file are not strategy — they’re decoration. The SaaS Speculative Sprint is designed to produce artefacts that get reviewed in roadmap sessions, referenced in quarterly planning, and used as benchmarks for evaluating new product bets. If the outputs aren’t in the same rooms where product decisions are made, the session didn’t finish.
Conclusion: What Speculative Design Actually Gives Product Teams
The argument for speculative design isn’t that product teams should spend less time optimising the present. It’s that optimisation without direction produces products that iterate towards irrelevance. The SaaS products that compound over years aren’t the ones with the smoothest onboarding or the fastest load times — they’re the ones whose teams had a clear picture of where they were going and made consistent bets to get there.
A few things worth taking away:
• Speculative design is a strategic foresight tool, not a design school exercise — most valuable when product and technology decision-makers are in the room.
• The SaaS Speculative Sprint is a two-half-day format that integrates speculative design into sprint-cadence teams without requiring them to slow down.
• The Recurrence Test is the translation mechanism: design patterns that appear across multiple future scenarios are worth roadmap consideration regardless of whether any single scenario is confirmed.
• Run it every six months, not once — the value compounds across sessions as documented assumptions get stress-tested against real events.
• The output isn’t a feature list. It’s a shared strategic language that makes every subsequent roadmap conversation faster and more directional.
If your product team is planning its next roadmap cycle and wants to pressure-test your current strategic assumptions against where the market is heading — that’s the conversation our discovery calls are built for.
