Stop Calling It a Product | How to ensure that you're going big enough in Discovery
Treating every challenge as a “product” problem can be limiting. Sometimes, the most innovative solutions emerge when we think in terms of services and experiences.
Too often, teams rush into feature-mode. While still fully in the problem space teams start describing solutions as dashboards, or portals, or tools. Before anyone has articulated the real need, they’ve already jumped to solving it.
That kind of framing limits thinking. It leads to siloed solutions, disconnected touchpoints, and short-term wins that don’t scale.
Here’s the shift I advocate for -
In discovery, frame the challenge as a service or experience, not a product.
Why design can & should lead discovery
Discovery is a core design capability—but it’s often assumed to be a product responsibility. The logic tends to be: product leads the business case, so they should lead the exploration.
But in reality, that often means narrowing too fast.
That doesn’t mean Product shouldn’t lead discovery. It means we should be intentional about who on the team is best placed to facilitate it. And often, it’s the designer—because they bring the skills and mindset to open the space, lead with questions, and explore without prematurely converging.
Design, at its best, creates the conditions to think without constraints—at least initially. That open space isn’t fluffy; it’s essential. It enables deep thinking before tradeoffs. And only once the possibilities are on the table should we reintroduce the limits: regulatory, technical, or operational.
Red flags you’re narrowing too early
The team talks in features before they’ve defined the problem.
There’s no articulation of user goals or pain points.
Ideas are presented as “the solution” with no alternatives.
No one can name what’s known vs. what’s assumed.
There’s no clear audience or job-to-be-done defined.
Rituals that open the canvas
Before diving into solutions, it helps to use activities like:
Crazy Eights – to unstick default thinking and train creative thinking muscles, because everyone is ideating fast and crazy.
Problem Framing – to clarify knowns, unknowns, and define the problem clearly - potentially even in a full prep-workshop prior to a Design sprint
Assumption mapping - e.g. through a FOG exercise where you map out "facts, observations & guesses"
Building a User Segmentation Matrix – to align on who we’re designing for, and why.
Joint journey mapping - to clearly map out touchpoints over time and encourage longer term thinking
Root cause analysis - Why might this be a problem? Why? Why? Why?
This isn’t about delaying delivery. It’s about creating a foundation that can carry meaningful, measurable work forward—without backtracking.
Discovery as de-risking
Not using words like "product" or feature" during Discovery isn’t just strategic—it’s pragmatic. When we're trying to avoid bias by including a mixed group of people in Discovery (different disciplines, genders, strengths, perspectives) to look at the challenge holistically - we should also ensure that the language we're using doesn't introduce bias or rather a solution already.
Only by generating multiple viable paths can we begin to eliminate the ones that don’t fit—whether through evaluation, rapid prototyping, or aligning with actual constraints and requirements.
This kind of divergent, then convergent, thinking significantly de-risks delivery. It helps teams avoid building the wrong thing fast—and instead move toward shared value with confidence. In other words if the whole team thinks about a solution as "a dashboard" - you're likely going to get exactly that, when there might be several other ways to solve the same problem (the reason you're doing Discovery in the first place).
A real-world example: designing a knowledge service
I recently ran a design sprint (as a follow-up to a problem framing workshop) with a team tasked with “increasing industry knowledge across the company.”
If we’d framed the challenge as a "product", we’d have ended up with a portal or internal dashboard for sure. Instead, we framed it as a service or program — a repeatable, integrated experience. That small shift unlocked much bigger thinking.
The team split into three sub-teams:
Career pathing – connecting knowledge to personal growth & performance.
Living knowledge base – not just content, but governance, accessibility, and sustainability.
Internal comms strategy – rituals, quizzes, and cadences to embed learning into everyday flow.
None of that would’ve emerged from a feature-first brief or if the team had used language like “learning hub” or "portal" straight from the get go, because they would have likely NOT considered the experience over time.
Final thought
Discovery isn’t about filling a backlog or getting all your requirements out on the table immediately. It’s about framing the right problem, exploring the widest range of options, and making better decisions—together. Which is a key reason to not leave all this work to AI but instead use it as the fun team work part that connects everyone around shared ideas. It is also the time to be aware of your own biases and make sure you're expanding your canvas wide enough.
So next time someone says, “We just need a feature that…”
Try asking instead: “What kind of experience would create value here—over time, and across touchpoints?”
Assuming of course you’re clear on which problem you’re trying to solve for which group of people before even going into solution mode. And that broad focus on problem and user groups is a key reason why I believe designers are so well placed to facilitate discovery. They can enable the whole team to expand the canvas and encourage divergent thinking, giving you options that the team can then narrow down on.
Need to get a bigger canvas?
If you need help going broader with your ideation so that you have more options to test - get in touch with me. I facilitate Problem framing sessions, Design Sprints, Portfolio or Journey Mapping exercises - to get teams to share their thinking, co-create and collaborate.
