This is a open edition of The Product Voyagers. To unlock full playbooks, tools, templates and expert takes — go Prime and get everything in your inbox.
What started as discovery became delay. What started as empathy became entropy.
Right?
We’ve all heard it: “Talk to your users.” But when interviews become a reflex instead of a choice, they can quietly kill momentum.
At Product Voyagers, we believe interviews are a tool—not a rule. And knowing when not to talk is just as important as knowing how to.
And in order to explore how modern product teams can strike that balance, we’re bringing in someone who’s been living this tension for years — and shipping through it.
Meet Magdoub: A Voyager of Lean Discovery and Product Speed!
Magdoub is Director of Product at Instabug (A Global flagship Solution that Boost Mobile Growth with AI-Powered Insights & Management), helping mobile teams squash bugs and ship fast. He’s scaled tools for developers, built across enterprise and SaaS, and still writes code when he can.
His core belief? Great PMs don’t gather requirements — they define sharp problems and rally teams to solve them together.
🎤 Now over to Magdoub 👇
Hi, Voyagers 👋
More than a decade ago, I was working at Orange. Tasked to build an internal tool to automate paperwork, I carried a notebook and one question:
“What problems do you currently face in the paperwork process”
Every employee I met answered. Their words guided our tool and for a while that was perfect. Then it became paralysis..
“I want the tool to remember my birthday”
“Will I be able to rearrange the modules with drag and drop”
“Can I scan the paper and auto upload to the tool?”
Shipping slowed. Nothing was released. We were learning and “brainstorming” but not moving.
Since then I have learned two inconvenient truths:
Interviews come in many flavors. Some are light and fast, others are heavy and expensive. Using the wrong one is like trying to cut a steak with a spoon.
You do not always NEED an interview. Sometimes the fastest progress starts with a biased assumption and a quick experiment.
The cult of the customer interview
Books, bootcamps, and expensive conferences preach that talking to users is the highest virtue. The advice is well-intentioned. The danger is treating it like a rule.
Picture a writer who edits every sentence before finishing the paragraph. The story never moves forward.
This is exactly what happened…
When teams obsess over interviews they reach a local maximum: perfect knowledge and zero momentum.
Interviews are a Spectrum
Most people imagine a user sitting across the table while we ask open questions. That is only one type on a broad spectrum of discovery ideas. Below is the field guide that explains this spectrum.
#1: Zero-Contact Discovery
Use these when you need data super fast and no calendar invites.
Check support tickets Filter yesterday’s Zendesk/intercom tickets for the word “X,” copy the top ten, highlight the common problems. AI is becoming super helpful in analyzing support tickets.
Crunch your numbers Graph feature usage for the last 30 days, circle sharp drops and unexplained spikes.
Competitor tear-downs Sign up for the closest competitor, click every button, map each screen, note where their choices differ from yours. Gaps appear in minutes, not weeks.
Review mining Scrape App/Play Stores, and G2 reviews. Sort by the extreme stars. Zero- and one-star ranks point to problems you might share.
#2: Low-Contact Discovery
Light touch + no scheduling overhead.
Micro “Lazy” polls Insert a single-question Typeform inside the empty state of your feature. Ten clicks later you have some signals.
Fake-door test Ship a disabled button labeled with the future feature, measure click-through for a week. This is like a demand forecast for an unshipped feature.
Pre-recorded Zoom call snippets Search “pricing objection” in Zoom/Gong recordings, watch five minutes. Listening to raw objections is much better than reading second-hand summaries every time.
Dog-food sprint This is incredibly helpful, yet very few teams do it. Force the whole squad to use the feature all week. You will be surprised from the output.
Session replay watch-party Play ten Hotjar/FullStory recordings, pause at every rage-click. Watching frustration with your team brings empathy to your whole team.
#3: High-Contact Discovery
Live interactions when the details matter.
45min Customer interview Recruit three target users for 45m-1hr calls. Ask five open questions, show no slides, stay silent after each question. You will surface the important motives in under an hour.
Customer advisory Slack Share a Figma mockup in a private Slack channel and ask “Would you pay for this?” Instant thumbs-up or down with zero friction.
#4: Embedded Discovery
Deep immersion when you are don’t understand the problem space at all
Shadow your customers Spend a day in the customer’s office, do their job shoulder to shoulder. Pain becomes real; you will never debate priority again.
Two stories, One lesson
Story one: The new cutting edge tool that no one used At Raisa Energy we rebuilt an internal tool. Six weeks of interviews told us petrophysicists loved the new redesign. We even revamped the code to a new react library (3 months of work).
We shipped and they ignored it.
Their Excel muscle memory beat our shiny UI. Watching them fight the tool in real life taught us more in one afternoon than six weeks of “feel good interviews”.
Story two: A simple fix that won the customer’s heart Last year, Instabug’s dashboard was becoming slower for one customer. We suspected sampling Non-important info would cut load time by half.
Instead of interviews we ran a one-day experiment on a shadow environment. Numbers dropped, performance spiked, panic ended.
Only then did we call our customer and ask if we can sample some types of Non-important info.
One assumption, one test, one relieved customer.
When to Talk, When to Build
Here is the rule I live by and advice my teams to do:
Talk when the cost of a wrong release is high or irreversible: pricing pages, data models, big navigation changes.
Build when an experiment is cheap and usage will speak louder than words: UI tweaks, novel ideas, ranking algorithms.
As much as possible try to push problems in the “Build” bucket instead of the “Talk” bucket.
Advice for the road ”A Discovery Survival Kit”
1. Label your mode Are you in exploration or execution? Don’t pretend to be researching when you’re just stalling.
2. Write the hypothesis first If you can’t write your assumption in one sentence, you’re not ready to talk to users.
3. Time-box discovery With AI and sharp framing, one week is enough for most product questions.
4. Default to building Push problems into the “Build” bucket when risk is low. Shipping is the fastest form of learning.
5. Trust your judgment Bias isn’t bad. Start small, ship fast, watch what happens.
Last Takeaway to Every Product Voyager
Customer conversations are powerful, but they are a tool, not a rule. Choose the right tool and you will move faster than teams who worship the process/ritual.
Now close this tab, make a biased assumption, and ship something small.
Trust your judgment.
🔭 So, What’s Next?
Thanks, Magdoub 🙌. This article has laid the foundation — and reminded us what the real work truly means.
To keep navigating this journey, we’ve created a companion piece that dives into generative, evaluative, and destructive discovery — not as steps, but as ongoing, intentional mindsets.
Because discovery isn’t just about speed — it’s about clarity, intent, and momentum.
If you’re ready to go deeper into the roles, tools, and rituals behind each mode, your next read is right here 👇
Years ago I was leading an initiative where we had every reason to believe we were on the right track. The team had done “discovery,” or so we thought: a few user interviews, a quick market analysis, and some internal brainstorming. But when we launched, the new feature didn’t resonate at all. I remember staring at the metrics in disbelief.
