Exploring vs Exploiting: The Two Modes of Product Discovery
Hey Ant here 👋 I write a newsletter that won't go viral - and that's the point.
Because hot takes, clickbait and AI slop won't help you ship better products. But practical content grounded in real work will - the kind I do every day on my own products and the product leaders I coach.
Join 15,000+ product people who subscribe. Same applies to my YouTube channel!
Recent posts you might have missed:
- Product Discovery Should Speed Up Delivery, NOT Slow it Down
- Let's talk Dual Track: Continuous Discovery and Delivery
- The AI Chasm
Most teams are great at exploiting but few teams are really good at exploring what's possible.Product Discovery has two modes:
Exploring
Exploiting
Most teams I work with are great at exploiting.
They're really good at optimising what they already know. E.g. “make the onboarding flow better” or “improve churn”.
But few teams are really good at exploring.
Exploring what's possible. Gathering insights that shape their product strategy and uncover untapped opportunities (potentially whole new products!)
Explore vs Exploit
When I talk about product discovery, most people think of ‘validating the problem space → ideating solutions → testing those solutions’.
And that’s all really important but it’s only half the picture.
Discovery actually runs in two distinct modes:
Exploring — broad, slower, more divergent. Looking for new problems worth solving, new segments, new opportunities, new bets.
Exploiting — narrow, faster, more convergent. Taking known problems and known opportunities and extracting value from them.
And this isn’t a new concept or some framework I’ve invented.
It’s been around in innovation theory for decades.
In 1991, James G. March published a paper called "Exploration and Exploitation in Organizational Learning" that's now one of the most-cited papers in management research. His core argument: organisations have to balance exploring new possibilities with exploiting old certainties, and most fail because they over-index on the latter.
I’m sure you can think of some famous examples of this.
Kodak famously buried the digital camera because film accounted for 70% of their profits and 90% of the US market. They were so busy protecting the past that they missed the future.
We saw the same with Blockbuster, who doubled down on the in-store experience while Netflix was already pivoting to streaming. Even Netflix could have fallen into this trap; they could have spent the late 2000s perfecting DVD mailing instead of building a streaming empire.
Apple is another example of getting the balance right. When they launched the iPhone, the iPod made up nearly half of their revenue. Instead of clinging to their best-seller, they chose to replace it, eventually sunsetting the iconic iTunes app in 2019 to make way for Apple Music - again favouring the future over the past.
"Adaptive systems that engage in exploration to the exclusion of exploitation are likely to find that they suffer the costs of experimentation without gaining many of its benefits. Conversely, systems that engage in exploitation to the exclusion of exploration are likely to find themselves trapped in suboptimal stable equilibria." - James G. March, Exploration and Exploitation in Organizational Learning
Why Explore is often missed
One of the reasons why we have so few Netflix and Apple examples but so many Kodak, Blockbuster, Nokia, Polaroid, Blackberry and Yahoo’s of the world is because you can’t build a business case for exploratory work.
Exploit on the other hand has clear inputs and outputs.
It’s often a known problem that you can either quantify with existing data upfront or at least can quickly do so in the first few days of discovery.
The output (if we proceed with the opportunity) is a solution that we have high conviction on because of data.
The outcomes in exploitative work are often immediately measurable and it’s easy to draw a line between discovery and how it impacts the outcomes stakeholders care about.
Explore has none of that.
Exploration is messy and the output is unclear - unknown even.
It’s often "we understand this problem space better." Which isn’t easy to defend in a quarterly business review when revenue is flat.
So I get it. I understand why this isn’t something that’s widely adopted but as Charles O'Reilly and Michael Tushman found in their work on ambidextrous organisations, the companies that survive long-term aren't the ones that are best at exploiting their current business, they're the ones that can do both at the same time.
Doing Both: What "Exploring" actually looks like
Exploration isn't a single activity. It's a ‘mode’ that you operate in.
For example, goals in Explore are very different from Exploit. It’s common that in discovery you’ll have an outcome that you’re driving towards. But in Explore it might be more an open ended question - or even nothing at all other than curiosity.
This changes how you operate. You’re not looking at dashboards, reading customer feedback to find the highest leverage opportunity to drive an outcome. Instead you’re pulling threads and operating with often no data - and that’s the point.
To make this practical, here are some examples of activities that you might do for exploratory discovery.
1. Exploratory Interviews
Not user testing concepts or scripted user interviews to test your assumptions.
These are open ended interviews focused on learning context and exploring your users lives and environment.
I still prepare for these interviews but they’re not as scripted as the ones I run when I’m exploring.
I’ll have some open-ended questions - broad ones like “walk me through a typical day” or "If you could wave a magic wand…” but I don’t stick to them. I’m guided by the conversation and I’m looking out for interesting threads to pull.
Whilst this may seem like a simpler form of user interviewing it’s actually a more advanced skill.
Exploratory interviewing relies on your ability to identify potential insights, frame effective questions and steer the conversation in real time.
And this is what I mean by a different operating ‘mode’.
In Exploit I’m focused on a set of assumptions I want to test.
This means:
I want to ask the same questions so I can get reliable data-points across multiple interviews
I’ll likely log threads rather than chase them so I can prioritise testing my riskiest assumptions.
Explore on the other hand I’m not testing assumptions, I’m looking for threads to pull.
Therefore:
My questions are open ended and I’m not going to chase threads.
I’m not looking to validate anything, so I’m ok with a single data point - validation across a larger segment can happen later.
Both are user interviews on the surface but you operate through very different frames and approaches.
2. ‘Always-On’ Exploring
Beyond exploratory interviews you can also do what I refer to as ‘always-on’ exploring techniques.
Things like:
Feedback forms: great source of continuous insights from users.
One-question surveys: not to validate a problem but to ask exploratory questions.
I have a version of this on this newsletter. When people subscribe they receive an email that’s “One quick question” where I simply ask; “what’s happening in your world that made you sign up?”
And I’ve gotten a goldmine of data over the last 2 years since I started doing it.
Just like regular interviews the idea is to have ways to get a steady stream of insights.
3. AI Research
AI has unlocked another version of this. You can create AI agents that do market or competitive research for you.
You can even get AI to go monitor social media, reddit threads, etc and pull insights on how your customers are talking about your product.
A great way to identify possible opportunities and underserved needs.
My pre-AI version of this - that I still do - is to sign up for competitors products, their newsletters, etc. It’s a great way to have a steady flow of intel landing in your inbox.
4. Dog-fooding
Dogfooding is of course a popular technique and it’s exploratory in nature.
For those who aren’t familiar with ‘dogfooding’ - it’s simply using your own product.
When you dogfood you’re not trying to test anything specific, instead you’re trying to build empathy with your users and uncover opportunities, painpoints, problems, etc. Very much exploratory.
5.Observation
A past client of mine was a SaaS company in the logistics space so the CPO got all her PMs to spend a day in a couple of their main customers' warehouses.
No agenda, no assumptions to test or problems to validate. Just to go and observe.
This is classic exploratory discovery and perhaps one of the easier examples of why it’s hard to put an ROI and build a business case for it - what do you expect the output of the day to be? What’s the measurable outcomes? It’s learning!
Threads not validation
A fundamental part that makes exploratory discovery different is you’re looking for threads of potential problems, not trying to validate them.
The idea is that exploration should help you identify potential opportunities that you didn’t even know about, you still need to exploit and validate them.
So there’s a natural graduation.
An opportunity identified in explore will end up on the backlog/roadmap - you’ll need to still prioritise it and then dedicate time to validate it, ideate solutions and test them.
Exploit
Quickly on exploitative discovery, since we’ve spent the whole time talking about explore. This is the mode of discovery that you already probably know really well. It’s what most people picture when they hear "discovery."
It’s where you start with a known problem - it doesn't need to be validated, you could have just had some data or insights into it - and your job is to validate that problem, ideate solutions and run assumption tests before you commit to building.
It's the classic loop: validate the problem space → ideate solutions → test those solutions.
Where Explore is about identifying potential opportunities, Exploit is about actioning them.
This makes exploitative discovery much tighter cycles, focused on feedback and iterations.
The key is you need to be doing both. Don’t get stuck only exploiting and never exploring.
Explore Teams
Whilst I believe all teams should be doing both explore and exploit at all times, just like they should be doing continuous discovery and delivery there are scenarios where Explore focused teams make sense.
For example, exploring new opportunities in completely new areas, not related to your current products, customers or core business.
You see this a lot with the 70-20-10 portfolio management split where:
70% of your total capacity should be focused on your core products
20% focused on adjacent products
10% on moonshot bets
When you’re at a portfolio level that 10% is often a whole team - or multiple teams depending on your company size.
These teams are often Explore Teams. Focused on finding potential new opportunities and often working on them until product-market fit. At which point, you can make the decision of whether that team continues with the new product or if they hand it over (either to a new team you hire or to an existing team).
Handovers whilst not ideal often make sense because you need a different set of capabilities in a growth team than an Explore team or a team managing a mature product.
The boring (but important) stuff
It's not an either-or. You need both.
They happen at different speeds. Exploit can be rapid, testing assumptions daily. Whereas Explore is often slower and more 'always on'.
Explore helps to uncover innovative ideas. Exploit is more incremental improvements.
One leads to the other. Exploring to uncover opportunities for you to prioritise and exploit later.
You might use different terms for these activities but principles are the same.
Hope that helps.
Want to go deeper on product discovery best practices? Topics like this are exactly what’s covered in the Product Discovery course. Worth a look if this feels like something that’s lacking in your organisation.
If this resonated, it’ll resonate with others so spread the love!
And as always, any questions hit reply, it comes straight to me.
Thanks as always for reading!
/Ant
Your OKRs don’t live in a vacuum.
Yet this is exactly how I see many organizations treat their OKRs.
They jump on the bandwagon and create OKRs void of any context.
Here’s what I see all the time…