If you're new here, here are a few past posts you might find useful:

• Stop Copying Features: A PM’s Guide to Competitor Product Analysis

• How to Stop Shipping Perfect Features Nobody Uses

• 5 Product Team Roles Breakdown

• How to Turn Your Metrics into a Product Growth System

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

There’s one question I’ve heard more than any other.
Across different companies I’ve worked at, and every time I teach my product management course, students always ask the same thing:
“Where do we find respondents for interviews?”

For some people, this is a real pain point. They spend weeks preparing questions, arguing about scripts, but… simply don’t know who to invite.
Instead of real conversations with users, they start making things up — and that’s how classic product hallucinations are born.

This has always surprised me a little. For me, finding respondents is just routine — almost like checking my inbox. But I get why for many PMs it feels like a dead end. There’s no clear playbook, just a messy list of tips scattered across blog posts and chat threads.

That’s why I decided to share my own approach: how to line up 5–10 relevant interviews in 48 hours without turning it into a side project that eats up half your life.
It’s not “the one true way.” It’s just my working method — tested both in scrappy startups and in big corporations.

My system: Find → Qualify → Convert

When people ask me “Where do I find respondents?” I usually answer: it doesn’t really matter where. What matters is how you run the process.

My logic is simple and built on three steps:

1. Find — I always run 2–3 channels in parallel. Why not just one? Because every channel is a hypothesis. Today LinkedIn might work, tomorrow it’s a Slack post, the day after it’s an old colleague who introduces you to the perfect fit.

2. Qualify — before I drop someone into the calendar, I ask a couple of quick filter questions. Who are they? When was the last time they dealt with this problem? Do they have influence over the decision? Those five minutes can save hours (sometimes days) of wasted interviews.

3. Convert — I keep it dead simple: a calendar link with three immediate slots. No “maybe next week.” People live in their own rhythms, and if you don’t catch them today or tomorrow, it won’t happen.

I also have a personal Stop/Go rule:
if after ~100 touches I get fewer than 3–5 interviews booked, the issue isn’t volume — it’s my message or my targeting. That’s the moment to switch wording or channels instead of just pushing harder.

It sounds almost too simple. But this exact system has helped me — from small startups to large corporations — line up the right people quickly and without the stress.

Where to Actually Find Respondents

Whenever the topic of recruiting respondents comes up, I often hear vague advice like “try social media” or “ask your colleagues.” That’s like telling someone to “look for a needle in a haystack.”

In reality, it’s more down to earth: you just need a few working channels and the right combination.

I don’t believe in one magic source. Sometimes LinkedIn works, sometimes it’s conferences, and occasionally it’s niche communities nobody thinks of. Here are the channels that have actually worked for me.

1. Friends-of-friends

The simplest way to get moving. Your own friends probably aren’t your target audience, but they know people who are closer to your niche.

💡 How I do it: I send the same short message to 20–30 friends:

“Hey! We’re currently researching how small businesses manage expenses. Do you know anyone who actually deals with this?”

From 20 messages I usually get 5–6 warm intros. Enough to test a script and kick off conversations.

2. Social posts (LinkedIn, Twitter, Reddit)

The formula is simple: short post, clear segment, and a low barrier to respond (“drop a + in the comments”). Then you DM them with a calendar link.

💡 Example: I once posted on LinkedIn:

“Looking for 5–6 B2B SaaS sales professionals for a 30-min interview. If you’re up for it — just leave a +.”

Within two days I had several replies and a handful of interviews booked.

This works best if you have an active audience. But even with 300–500 connections, you can still get a decent pool. The key is clarity: the more specific your ask, the higher the response rate.

3. Communities and professional groups

There are spaces where people gather naturally: forums, private groups, professional clubs. You can find surprisingly narrow segments there — from farmers to procurement managers.

The catch: it’s usually a cold audience. If you just show up and drop “Looking for respondents,” you’ll get nothing.

💡 What works better: join early and “live” in the community a bit. A few comments, a couple of helpful posts. Then, when you ask:

“Looking for 5–6 people who recently implemented a CRM — happy to chat,”

it feels like a normal request instead of spam.

Once, we were looking for small farmers. LinkedIn and Facebook gave us zero. But a niche community responded — two people joined, and each gave us a couple more contacts. That snowballed into 5–6 solid interviews in what first looked like a dead segment.

4. Existing users or clients

If you already have a product, your users are a goldmine. But the approach depends on whether you’re in B2C or B2B.

• B2C: you can go broad — email, push, in-app banners. Typical conversion is 5–10%, with loyal audiences sometimes hitting 15–20%.
  💡 In one edtech project we pushed: “Want to help us improve your learning experience? 20 min interview.” → 12% said yes.

• B2B: it’s much tougher. Decision-makers are busy and rarely see the value. If 3–5% agree, that’s already a win.
  💡 In one case, account managers sent out invites to their clients. Out of 20, just 1–2 said yes. Small numbers, but those conversations gave the deepest insights.

5. Paid platforms (User Interviews, Respondent.io, TestingTime)

These are your “insurance policy” when time is short or the segment is too niche.

• User Interviews:

  • General consumers: $40–60

  • Professionals: $80–120

  • Executives / B2B decision makers: $150–250

• Respondent.io: similar rates, plus ~30% platform fee.

• TestingTime (Europe): €50–150 depending on profile.

Yes, it’s more expensive — but you can fill your quota within a day.

6. Conferences & events

The most underrated channel. Online outreach is slow; conferences give you live conversations right there.

How I do it:

1. Research relevant conferences in advance.

2. Ask for the attendee or speaker list (often public).

3. Reach out a week before: “I’ll be at [conference], would love to hear about your experience with X. Do you have 30 min?”

4. On site, I walk up after a talk:

“Really interesting point about automation. Can you share where it’s been painful in practice?”

💡 At a SaaS event in Berlin, I ran three face-to-face interviews in a single day. That was more than I’d gotten in a full week of LinkedIn back-and-forth.

🎯 The takeaway: There’s no universal channel.

• In B2C, scale works: posts, pushes, communities.

• In B2B, you need targeted hits: LinkedIn, conferences, account managers.

My strategy: always combine. Two channels for speed + one “backup” channel in case things stall. That mix usually gets me 5–10 interviews in 48 hours, even in tough segments.

Why People Say Yes to Interviews

A lot of PMs assume the only way to get someone on an interview is to pay them. That’s not true. Over the years I’ve noticed: people have plenty of reasons to say yes — and money is rarely at the top of the list.

Here’s what actually works:

1. Ego: “I’m an expert”

People like being listened to. When you write something like:

“You’re one of the most experienced CRM users in your company, and your perspective is really valuable to us,”

the chance they’ll say yes goes up dramatically. They feel their expertise matters.

💡 I once had a case with call center managers. Out of 10 messages that stressed “your experience is critical,” four agreed. When I just wrote “we need an interview,” nobody even replied.

2. Altruism: “I want to help”

Some people simply enjoy helping. They’ll agree if they see their input could improve a product or process.

💡 In an edtech project, we wrote to users:

“Your feedback will help us make learning easier for you and your colleagues.”

Even inactive users came back to talk.

3. Curiosity: “This might be useful for me too”

Interviews often feel like a mini therapy session: people talk through their pains, organize their thoughts, sometimes even find their own answers.

💡 One SMB founder told me after an interview:

“Thanks, I actually see more clearly now where the chaos is in our processes.”

It was just as valuable for him as it was for us.

4. Value: “This could improve my life”

If someone is genuinely struggling with a problem, just having the chance to talk about it can feel valuable. Especially in B2B:

“We’re building a tool to simplify procurement workflows. We’d love to hear your experience.”

If the message hits a real pain point, the odds of them saying yes go way up.

5. Perks (payment, bonuses, gifts)

This works when nothing else does.

• In the US, gift cards worth $25–50 are common.

• In Europe, discounts or free product months are popular.

• In B2B, execs may expect $150–250, but often agree more because they see the product’s relevance than for the money.

💡 I try not to start with payment. But for rare segments or tight deadlines, a small reward speeds things up a lot.

🎯 The takeaway: money isn’t the main motivator.
In 80% of cases, ego, altruism, or clear value are enough. Payment is just a backup for harder segments.

My go-to scripts & cases

I’ve tested dozens of different wordings. Over time I realized something simple: what works isn’t polished “corporate speak,” but short, human messages. Here are the scripts that have actually worked for me.

1. LinkedIn DM (B2B)

Message:

“Hi [Name], I’m a product manager currently researching how companies handle [X]. I see you have experience in this area. Would love to hear your perspective — just 20–30 minutes. Would next week or the one after work for you?”

💡 In cold B2B outreach, it’s always “slow and few.” If 1 out of 10–15 people replies, that’s already normal. Sometimes less. But if it’s the right person, even one interview is gold.

2. Warm intro (friends & colleagues)

Message to a friend:

“We’re looking into how small businesses manage their finances. Do you know anyone who actually deals with this? Could you intro me?”

💡 Conversion here is much better. One friend often brings 1–2 intros. Out of ten such asks, you might get a couple of interviews. The trick is not to overthink it — just ask directly.

3. Community post (B2C / SMB)

Post in a group or forum:

“Hi everyone! Looking for 5–6 entrepreneurs who recently launched online stores. Short interview (20 min). If you’re up for it — just drop a + in the comments and I’ll DM you.”

💡 Depends on the group. In a big community, you might get several replies in a day. In a small niche one, maybe one or two per week — but those are often the most valuable.

4. Referral ask (my favorite trick)

At the end of every interview I ask:

“Thanks for the chat, this was super helpful. Do you know 1–2 other people with a similar experience I could talk to?”

💡 This almost always works. Even if they don’t have names on the spot, they often follow up later. Sometimes one respondent can snowball into a whole chain: one person → two more → two more.

5. Case: when I messed it up

Once I blasted LinkedIn with a template like:

“Your opinion is important to us, we’d like to improve our service.”

Zero response. Why? It sounded like corporate spam.
I rewrote it to be more personal: “I see you actually work with this — I’d love to hear your experience.” And people started replying.

🎯 The takeaway: the simpler and more honest the message, the higher the chance of a reply.
Don’t expect magic conversion rates. In B2B, if you land one interview from 20 touches, that’s fine. In communities or via friends, it’s usually higher — but there’s always a lottery element.

Involving the Team

There’s an old joke: a PM comes back with research results, and the developers look at him as if he’s just returned from vacation and is telling them “it was really interesting there.”

And it’s true: reports and slide decks rarely change minds. Developers and designers don’t feel users through PowerPoint. They only start believing when they actually hear people live.

💡 On one project, we invited a developer to join a user interview for the first time. After the call he said:

“Now I get why they’re so frustrated with that button. I thought we’d already simplified it.”

That single conversation did more for prioritization than three previous research reports.

How I usually do it

• If the interview is online, I bring at least one team member in “silent mode.” Just listen and take notes.

• Sometimes I ask the designer to take notes. They end up noticing patterns themselves — and argue less during reviews.

• Occasionally I run a mini-session for the whole team: 2–3 users, 2–3 short interviews in a single morning. By the end, everyone shares a clearer picture of who our user is and what’s really blocking them.

Advanced format

The “heavy artillery” is workshops like Product Backlog Refinement sessions with users. Yes, they take prep and time. But if you need to ground a team in reality fast — they work wonders.

🎯 Takeaway: one hour of the team hearing users directly is worth more than 20 pages of a report.
Sometimes just sitting in on a single interview saves weeks of debate.

Conclusion

Finding respondents isn’t magic or luck. It’s discipline — and the right mix of channels.

• In B2C, broad tactics work: posts, push, communities.

• In B2B, it’s all about targeted hits: LinkedIn, conferences, account managers.

And remember: interviews are oxygen for your product. Without them, the team lives in hallucinations, arguing over features “from their own heads.”

I’ve shared the playbook that’s saved me more than once, across very different contexts.
And no, I don’t have the universal “do this and you’ll always succeed” recipe. But I do know this: if you run 2–3 channels in parallel, filter respondents clearly, and never hesitate to ask for referrals — you can line up 5–10 interviews within 48 hours, even in tough niches.

📎 If user interviews are on your mind, you might also like my other guides:

• Practical Guide to User Interviews (Part 1)

• Practical Guide to User Interviews (Part 2)

• User Interviews: How to Understand Your Users

Thanks for reading. Glad to have you here.

Take care and talk soon.
— Dmytro

Share

If you're new here, here are a few past posts you might find useful:

• How to Stop Shipping Perfect Features Nobody Uses

• 5 Product Team Roles Breakdown

• How to Turn Your Metrics into a Product Growth System

• Starting a New Product? Use CJM and Story Mapping Together

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

Have you ever looked at your roadmap and thought: “Half of these ideas are here just because our competitors already did them”?

It’s a common story. A stakeholder drops a screenshot of someone else’s product, someone in Slack says “hey, they have this feature,” and suddenly there’s a new task in your backlog.

And honestly, there’s nothing wrong with that. Watching competitors is normal — users will compare you to them anyway. The real question isn’t “to copy or not to copy” — it’s how to analyze competitors’ products so you can turn their solutions into your own insights.

In my previous article on Product Discovery, I wrote that ideas come from many sources: research, customers, data… and, of course, competitors. But the real challenge is this: how do you turn someone else’s features into your own hypotheses? That’s what this article is about.

Read more

If you're new here, here are a few past posts you might find useful:

• 5 Product Team Roles Breakdown

• MVP Is Not a Product. It’s a Question.

• From Features to Problem-Solving. 4 Steps to Mature Product Work

• B2B or B2C PM? Take the checklist and choose your side

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

Have you ever caught yourself thinking your team is moving fast, building beautifully… and completely missing the mark?

The feature is polished, deadlines met, the demo went great. But users? They smile politely — and never come back.

That’s the classic story of building “by gut feeling” or chasing the loudest stakeholder’s request — instead of checking if anyone actually needs it.

Product Discovery isn’t just a trendy term from a book. It’s your insurance against shooting in the dark. And today, I’ll show you how to make it part of your workflow without turning it into yet another box-ticking exercise.

1. What is Product Discovery

Ask ten product managers what Product Discovery is, and you’ll get ten different answers.

For some, it’s “the step before handing work to engineering.”
For others, “a couple of user interviews.”
And for some, it’s that mysterious ritual “UX researchers do.”

In reality — it’s the process of finding and validating opportunities that are actually worth building.

And process is the key word here. Discovery isn’t a one-off phase at the start of a project. It’s a habit of checking whether we’re still heading in the right direction — while we’re moving.

The simplest distinction:

• Discovery answers “what” and “why.”

• Delivery answers “how” and “when.”

I like Product School’s take — three checkpoint questions for any idea:

1. Is this problem worth solving?

2. Will this solution work?

3. Will it be better than the alternatives?

If the honest answer to even one of these is “no” — better not to waste the team’s time and the company’s budget.

In framework terms, this fits neatly into the first half of the Double Diamond — where we start by exploring the problem as broadly as possible, then narrow the focus to a clearly defined challenge.

Product Discovery is closely connected to Customer Development and Jobs To Be Done. The difference is that Customer Development is a method of collecting data, while Discovery is a broader process that brings together data, hypotheses, tests, and decision-making.

2. Why it matters

Most companies have two favorite ways of deciding what to build next:

1. Ask the loudest (or highest-ranking) stakeholder.

2. See what competitors are doing — and copy it.

Both are convenient. No need to waste time asking “extra” questions — you can jump straight into Jira, create tickets, and start “working.”

Except… that’s not really work. That’s a lottery.
If you’re lucky — you’ll guess right.
If not — you’ll bury months of effort and a chunk of budget into something nobody needs.

Product Discovery exists to remove the guesswork.
To stop measuring success by the number of features in your release notes, and start measuring it by how much those features actually move the product toward its goals.

In short — it’s the shift from a project mindset (“we shipped the project — success”) to a product mindset (“we changed user behavior — success”).

Instead of bragging about output, we focus on outcomes.

B2C example
In B2C, you can test dozens of hypotheses a month.
Ship a quick feature, release it to part of your audience, measure the metrics, kill it or improve it.
The cost of a mistake is low, and cycles are short.

B2B example
In B2B, the stakes are higher.
Build the wrong feature — and you don’t just lose one user, you lose a contract worth hundreds of thousands of euros.
Implementation cycles are long, and fixing a miss takes time you often don’t have.
That’s why Discovery here isn’t just “nice to have” — it’s survival.

3. The risks of skipping Discovery

If you think skipping Discovery saves time — in reality, you’re just moving the cost of mistakes down the line. And that cost always grows.

Risk #1: “We already know”
One of the most common scenarios: the team and stakeholders are convinced they know what users need.
So instead of testing the hypothesis, they jump straight into development.

Later it turns out people use the product differently — or the “problem” you solved ranks about tenth in their priorities.

B2B case: In one document management SaaS, the team decided to add a “team comments module” to make collaboration “easier.”
After launch, they found all major clients were already using Slack or Teams — and had no intention of duplicating conversations inside our product.
The feature sat unused, yet we kept maintaining it for six months.

Risk #2: Falling in love too early
Once the team has a concrete idea, the brain switches to defending it.
We stop seeing alternatives and start bending any data to fit the desired outcome.

Discovery helps you avoid falling in love with the first thought, keep a portfolio of options, and test them with real users.

Risk #3: Fake success metrics
Without Discovery, we often treat the mere fact of shipping as success.
“We launched” = “We built something useful.”

In reality, user behavior might not change at all — or might even get worse.
In B2C, this means marketing spend goes down the drain.
In B2B, it means that at the next contract renewal, the client will ask you to remove that “useless” feature.

Risk #4: Expensive fixes
Any flaw caught before coding is cheaper to fix than after release.
In large systems with lots of integrations, rework can cost 10–20 times more than validating the idea with a prototype.

4. How the Discovery process works

Discovery isn’t a “one-off” workshop. It’s an ongoing process, built into the way the product team works.

To avoid drowning in it, it’s useful to understand the basic logic.
If we simplify, there are three key steps:

1. Define what outcome you want to achieve

2. Find opportunities that could lead to that outcome

3. Test potential solutions

One of the clearest ways to visualize this is Teresa Torres’ Opportunity Solution Tree:

• Top of the tree – a clearly defined product outcome linked to a business goal.
  (For example: reduce churn among paying users by 15% in six months.)

• Opportunity branches – what we’ve learned about user needs, pains, and desires that could help reach that goal.

• Solution leaves – specific ideas for features, improvements, or processes that could address those opportunities.

Based on Teresa Torres’ Opportunity Solution Tree. You can read the original explanation here

Double Diamond in Discovery

Another useful lens is the Double Diamond:

1. Discover – widen the view, collect insights, talk to users, research the market.

2. Define – narrow down to the key problem you’ll solve.

3. Develop – open up again, generating multiple possible solutions.

4. Deliver – narrow down to the best ideas and test them quickly.

In Discovery, we’re especially focused on the first half (Discover + Define), but the best teams keep going and run hypotheses through the whole “figure-eight.”

What it looks like in practice (weekly rhythm)

Strong Discovery teams maintain constant contact with users.
Instead of “doing a round of interviews once a quarter,” they:

• Run at least one interview or test every week.

• Regularly update their opportunity map so they’re not working with outdated insights.

• Run assumption testing to check if an idea is truly desirable, viable, feasible, usable, and ethical — an adaptation of the approach popularized by Marty Cagan and the Silicon Valley Product Group.

Minimum Discovery toolkit:

• Customer interviews – not “What do you want?” but real usage stories.
  (More on this here → User interviews: how to understand real needs)

• Journey mapping / Story mapping – to see context and critical steps.
  (More on this here → Starting a new product: use CJM and story mapping)

• Prototyping – from paper sketches to clickable mockups.

• A/B and demand tests – to validate demand without a full launch.

5. Who Owns Discovery

Short answer — everyone who will have to live with the product later.
But there’s a core to the process, and it’s definitely not “a lone genius PM doing everything.”

Product Trio

In many teams, the core of Discovery includes:

• Product Manager — connects the work to business goals and sets priorities.

• Design Lead — ensures the solution delivers a great user experience.

• Tech Lead / Engineering Lead — evaluates technical feasibility and risks.

Important: a Tech Lead’s involvement in interviews and research depends on the product and context.
In B2C products, they may actively join early research to quickly understand constraints and opportunities.
In B2B — especially with complex architecture and long sales cycles — their role often focuses on assessing feasibility and integrations after the initial user interviews are done.

How others get involved

Discovery isn’t a closed club. The exact list of participants depends on the product, market, and stage. For example:

• Analysts — find patterns in the data and confirm (or disprove) insights.

• Marketing — understands which audience segments respond best to new ideas.

• Support — hears the real customer pain every single day.

• Sales (B2B) — give context on the needs of key accounts.

• Supply / Vendor Ops (marketplaces, e-com) — know the real experience of sellers and suppliers.

• Legal / Compliance (fintech, healthtech) — flag regulatory and ethical risks early.

A common mistake

Turning Discovery into “the PM’s side project.”
Decisions end up being made in a vacuum, and the team only hears about them once development starts.
This kills engagement and often leads to:

“We built exactly what you asked for, but we don’t believe in it ourselves.”

💡 Bottom line: yes, there’s a core trio — but it’s not a closed circle.
If you want strong results, involve everyone who can contribute a unique piece of the puzzle.

6. How to Make Discovery Part of Your Everyday Work

The biggest mistake is thinking Discovery is just a “phase” at the start of a project.
In reality, it’s not a stage — it’s a way of working.

1. Set a minimum cadence
The more often you talk to users, the less likely you are to miss the mark.

In startups, this can happen almost daily.
In corporations, you can bake it into sprints.
The key is to make sure you’re getting fresh feedback every month — not relying on a slide deck from a year ago.

2. Embed Discovery into sprints

• Before sprint planning: validate key hypotheses.

• During the sprint: run quick assumption tests on prototypes.

• After the sprint: review metrics to decide where to dig deeper.

This way, Discovery stops being “a separate process” and becomes part of delivery.

3. Make small bets
Don’t wait for “the perfect study.”
Three quick tests on clickable prototypes will teach you more than a massive survey of 2,000 people six months from now.
Better to have 10 small iterations than one giant, painful rework.

4. Save and reuse insights
In B2B — especially with long sales cycles — one interview can stay relevant for years.
Set up a central repository (Notion, Confluence, Airtable) with:

• a short description of the pain/need,

• the source (link to recording or notes),

• date and context.

This is your capital, not “waste material.”

5. Balance the plan with flexibility
Yes, you have a roadmap and quarterly goals (more on roadmaps here).
But if Discovery shows you’re heading in the wrong direction, it’s better to adjust than to stubbornly build something nobody needs.

💡 Bottom line: Continuous Discovery isn’t about “research for the sake of research.”
It’s about constantly fine-tuning your course so every week of development moves the product toward real value for users and the business.

Final thought

Product Discovery isn’t “research first, build later.”
It’s making sure you never build into the void.
Whether you work in B2B with half-year sales cycles or in B2C where every week counts — the team that learns faster what users truly need (and tests it in practice) will win.
Discovery is your filter — saving resources and sanity by keeping bad ideas out of the build queue.

If you like the Double Diamond logic or want to go deeper into combining Discovery with Design Thinking, I’ve covered it here with concrete steps and examples:

👉 Double vs. Triple Diamond — Why Two is Enough

👉 Design Thinking: How to Think Like a Designer

Recommended books on Product Discovery:

1. Continuous Discovery Habits — Teresa Torres

2. Inspired: How to Create Tech Products Customers Love — Marty Cagan

3. Lean UX — Jeff Gothelf & Josh Seiden

If you would like more recommendations for books, YouTube talks, or product creators to follow, check out my resource collection in 👉 the Atomic Product Library.

Thanks for staying with Atomic Product!

Take care😉

— Dmytro

Share

If you're new here, here are a few past posts you might find useful:

• 5 STEPS to Building a Product Strategy

• How to Grow as a Product Manager in 2025

• Starting a New Product? Use CJM and Story Mapping Together

• MVP Is Not a Product. It’s a Question

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

When you’re just launching a product — you want to track everything.
When your product starts growing — you want to track even more.
And then one day you open your dashboard… and realize:

You have no idea which of these numbers actually matter — and which ones just look nice and flashy.

It’s not an analytics problem. It’s not because you forgot to set up GA4 or didn’t integrate Amplitude. 👉 It’s because you don’t have a metric tree.
— Sounds like yet another buzzword, like AARRR or HEART?
— Nope. It’s something entirely different.

Today we’ll fix the chaos.

We’ll walk through how to bring clarity to your metrics,
how to track less but understand more,
and how to build your own metrics tree — tailored to your product, your stage, and your real goals.

We’ll use our fictional product NutriTrack [from this case study: How to Solve an 80% Drop-Off in a Mobile App] as a hands-on example.
Step by step — from the North Star to the smallest behavior metric.
With formulas, examples, and mistakes you’ll want to avoid.

Let’s get into it.

What is a Metrics Tree — and Why You Need One

A metrics tree is a way to connect your business goals to measurable, actionable product metrics.
It’s a structure — not a dashboard.
It shows how things are connected, not just how they’re doing.

Imagine it as a hierarchy:

• At the top: a North Star or goal-level metric that defines product success

• In the middle: key drivers that influence it

• At the bottom: metrics you can actually measure and act on — today

This isn’t about “tracking everything.”
It’s about understanding what’s worth tracking — and why.

🔍 A quick example:

Goal: We want users to come back.
Metric: Retention 7 day
What influences it?
– Did they get value fast?
– Did they return on Day 2 or Day 3?
– Did they see a reminder?
– Was there a reason to come back?

→ So under Retention we add:
First Value Rate, Push Open Rate, Weekly Return Rate, and so on.

That’s your tree.
It’s not about beautiful dashboards — it’s about seeing what really drives your product forward.

🛑 What happens when you don’t have a metrics tree?

1. You’re looking at nice graphs — but can’t answer: “Are we actually growing?”

2. Different teammates look at different numbers — and pull in different directions

3. You optimize numbers that… don’t matter
   (like MAU going up while retention and revenue tank)

There’s No Such Thing as a Universal Metrics Tree — And That’s Okay

Every product goes through different stages.
And at each stage — different goals matter.
And for every goal — you’ll need a different set of metrics.

That’s why:

• you can’t just grab a “Top 10 startup metrics” list and slap it onto your product,

• and you can’t start by asking “What should we track?” —
  You should start with: “What matters to us right now?”

🧪 Let’s make it real: Where is NutriTrack right now?

Quick recap:
NutriTrack is a fictional product we introduced in the case study “How to Solve an 80% Drop-Off in a Mobile App”.
It helps users track meals and build healthier eating habits.

🔬 As of now:

• it’s just starting to acquire users,

• it’s not monetized yet (revenue comes later),

• and it’s suffering from massive early-stage churn.

👉 So the main question we’re trying to answer is:

Are we delivering enough value to make users stay?

💡 That means the top of our metrics tree shouldn’t be revenue or growth — it should be something like:

7-Day Retention, or even better — Sustainable Usage
→ Are people coming back intentionally — not just tapping the app out of habit?

🧭 But here’s the thing:
“Retain users” is not a strategy. It’s not even a metrics tree.

Next, let’s talk about how to define a proper North Star, then break it down into clear drivers, and how to tell which metrics you can actually influence — versus the ones that just sit there looking pretty.

How to Choose a North Star and Start Building Your Tree (Using NutriTrack)

Before you start building a metrics tree, you need to ask yourself:
Where is this tree even going?
In other words — what sits at the very top? And why?

What is a North Star Metric (NSM)?

In simple terms — it’s the one metric that reflects the core value your product delivers to users.

A good NSM should:

• be tied to real usage, not vanity numbers like likes or clicks

• reflect a repeatable and meaningful scenario

• grow when your product genuinely gets better

❌ Examples of bad North Stars:

• MAU (Monthly Active Users)
  → Sounds impressive, but doesn’t tell you whether users are actually doing anything valuable.

• App downloads
  → Useless on its own — you can run a promo and get downloads with zero engagement.

• Number of food logs per day
  → Might look good, but fake or one-time logs don’t equal real value.

So what could be the North Star for our example (NutriTrack)?

Let’s think for a second:
What do we actually want from a user?
Not just to download the app — but to keep coming back and use it for something real.

💡 That leads us to a possible NSM for NutriTrack:

“Number of users who come back 3+ times per week for at least 3 consecutive weeks.”

Why this works:

• It shows repeat usage → a sign of perceived value

• It reflects sustained behavior, not just random taps

• It’s measurable — using event logs or analytics

Now let’s figure out what influences this NSM.

Breaking the NSM into Drivers (Level 1 of the Tree)

Practical formulas for these drivers

• First Value Rate = % of new users who log their first item on Day 0

• Notification Open Rate = % who opened a push notification within the first 3 days

• Habit Loop Init = % who used the product on 3+ consecutive days in Week 1

• Onboarding Completion = % who finished all onboarding steps

This gives us the first full level of the tree — a direct connection between the North Star and the key drivers that push it forward.

Going Deeper: From Driver to Action

We’ve defined one of NutriTrack’s key NSM drivers:
First Value Experience —

Did the user get that first meaningful win that makes them want to come back?

Now it’s time to break that driver down.
Not just say “value matters” — but actually figure out:
where the value delivery breaks — and what we can do about it.

How does a user actually get value in our example (NutriTrack)?

Before you track anything, you need to map out the real user journey, not just the numbers.

In our case, the flow might look like this:

1. User opens the app

2. Starts onboarding

3. Reaches the food logging screen

4. Logs their first meal

5. Sees a chart or feedback

6. Thinks, “hey, this is actually useful”

7. Comes back the next day

What can we measure along this journey?

💡 Heads up:
Everything below the first level of your tree isn’t just numbers —
these are signals you can use to improve the product.

A quick example: Turning metrics into actions

Let’s say you notice:

• First Log Completion is low
  → Maybe the logging flow is too confusing or tedious.

• Value Perception Proxy is near zero
  → Users don’t see the benefit right away.
  → Try auto-generating insights or visual feedback.

• Time to First Value is too high
  → Consider cutting onboarding steps or surfacing the CTA earlier.

👉 That’s the whole point of a metrics tree:
To help your team figure out where things break — and what’s fixable.

📌 A few key rules when going deeper:

1. Every level should logically connect to what’s above it
   → If a metric doesn’t push the NSM, cut it.

2. Metrics should be actionable
   → If you don’t know what to do when it drops — it’s not useful.

3. Better to track 5 real metrics you act on
   than 20 pretty ones you ignore.

Vanity vs Actionable: Which Metrics Actually Matter

Worse than not tracking metrics at all?
Tracking everything — and thinking that more numbers = more control.

But not all metrics are equal. Some tell you what’s really happening in your product.
And some… just look good on a slide.

What are vanity metrics?

Vanity metrics are the ones that:

• go up on their own (thanks to ads or seasonality)

• say nothing about real user value

• and most importantly — can’t be influenced by the product team

Common examples of vanity metrics:

So what are actionable metrics?

These are metrics that:

• are tied to user behaviors you can improve,

• give you a reason to form hypotheses,

• and can change when you change the product.

Examples of actionable metrics:

How to tell the difference?

Here’s a quick checklist:

✅ Can your team actually influence it?
✅ Will it change if you test something?
✅ Does it reflect real behavior — not just totals?
✅ If it drops — will you know why and what to do?

If the answer is no — chances are, it’s vanity.

💬 A quick real-life example:

You see your MAU has jumped. Nice!
But… retention hasn’t moved.
Neither has LTV.

What happened?
→ You just bought a bunch of empty traffic.
Still looks great in the report, though!

⚠️ Bottom line:

• Vanity metrics feed your ego.

• Actionable metrics help you make decisions.

So when you’re building a metrics tree:

If a branch leads to vanity — cut it off.

How to Build Your Own Metrics Tree — A Step-by-Step Checklist

So, you’ve mapped your North Star.
You’ve broken it into drivers.
You’ve gone deep enough to turn metrics into actions.

Now what?

That’s where OKRs come in.

If your team is writing quarterly goals and they have nothing to do with your metrics tree —
your metrics are just sitting there, disconnected from reality.

So before we wrap, let’s make sure your tree actually works for you.

✅ Quick Checklist: How to Build a Metrics Tree That Doesn’t Rot

1. Start with your product stage
   PMF, growth, monetization?
   → Your stage defines your North Star.

2. Frame a question that really matters
   Not “how’s our dashboard doing?”
   → Ask: “Are we delivering value that keeps people coming back?”

3. Pick your North Star Metric
   Can you measure it?
   Does it reflect real, repeatable value?
   Can you influence it through product changes?

4. Break it into 2–4 key drivers
   What behaviors directly move the needle?

5. Drill down each driver into concrete behavior metrics
   Keep it real. Use formulas, not just acronyms.

6. Cut anything that’s vanity
   If it looks good but tells you nothing — it goes.

7. Link your tree to team goals (OKRs)
   If you’re setting “retention” as a goal, and your drivers don’t touch First Value or onboarding —
   something’s off.

8. Update your tree every quarter or when focus shifts
   Metrics are alive. Your tree should evolve with your product.

💡 Final Thoughts

A metrics tree isn’t a reporting structure.
It’s a thinking structure.

It helps you move from “hmm, what’s happening?”
to “we know exactly where things break — and what to do about it.”

It’s not about tracking more.
It’s about tracking less — and knowing exactly why.

Keep reading Atomic Product!

— Dmytro

Share

If you're new here, here are a few past posts you might find useful:

• From Features to Problem-Solving. 4 Steps to Mature Product Work

• Your Roadmap Is Lying to You. Here's How to Fix It.

• MVP Is Not a Product. It’s a Question

• How to Solve an 80% Drop-Off in a Mobile App — A Practical Case Study

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

When I give lectures on product development, there’s one question that comes up almost every time:
“So… what’s the actual difference between a Customer Journey Map and a User Story Map? Aren’t they basically the same thing?”

To most students, these terms sound like a pile of fancy words. And when I worked at a startup, no one there had even heard of these maps — let alone understood how they could help the team🙈 .

But once you show real examples — how a CJM helps uncover where the user is struggling, and how a Story Map helps turn that into something functional — it all starts to make sense.

So today, let’s unpack these two tools without the academic fluff. We’ll see where the theory ends and the practical value begins. And we’ll try to answer the real question: are these just nice-looking visuals for stakeholder decks — or are they genuinely useful for building better products?

So what's the difference?

Read more

If you're new here, here are a few past posts you might find useful:

• How to Grow as a Product Manager in 2025

• Product Hypotheses ≠ Ideas — Or Why You’re Not Seeing Results

• How to Prioritize When Everything Looks Important

• MVP Is Not a Product. It’s a Question

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

One of the biggest challenges in product education today is the gap between theory and real-world decision-making. Frameworks are great — but they won’t help much if you’ve never applied them under real constraints.

Recently, I was asked to solve a mobile product case as part of a hiring process. The task focused on a common but tough challenge: user retention during the first week.

In this case, I’ll walk you through how I apply product thinking in a real scenario:

• 🔎 How I analyze behavioral and qualitative data

• 💡 How I form 5 product hypotheses and score them using a light ICE framework

• 🎯 How I select one hypothesis for MVP testing

• 🛠 How I build a team plan — including user story, UX ideas, success metrics, and edge cases

• 🚨 (Bonus) Link to the full Figma prototype preview

This breakdown might be helpful if you:

– are preparing for a PM interview
– want to see what practical product thinking actually looks like
– work in a startup with limited resources

📌 Full breakdown below — curious to hear what you'd do differently!

The Case Setup

Imagine you’ve just launched a mobile app called NutriTrack — designed for people who want to eat healthy without spending hours planning meals.

Here’s what it does:

• Automatically generates a personalized weekly meal plan

• Tracks calories and macronutrients

• Helps users stay on track with daily meal check-ins

When a new user signs up, they:

• Choose a goal (lose weight, maintain, or gain)

• Go through a short onboarding survey

• Receive a tailored weekly nutrition plan

• Can mark meals as “completed” or swap items any time

The Problem?
Despite a smooth onboarding and personalized suggestions, over 80% of new users stop using the app by Day 2 or 3, without completing even one week of the plan.

Let’s dive into the solution 👉

Read more

If you're new here, here are a few past posts you might find useful:

• How to Prioritize When Everything Looks Important

• Your Roadmap Is Lying to You. Here's How to Fix It.

• 5 STEPS to Building a Product Strategy

• B2B or B2C PM? Take the checklist and choose your side

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

When I joined a large corporation and took over a mature product, I expected the backlog to reflect that maturity.

What I found instead… was chaos.

There were lots of tasks — but not much use. Some were just raw ideas with zero context. Some were technical items disconnected from any product goal. Some were low-priority bugs. And half of it? Random stakeholder requests.

It wasn’t a backlog. It was a pit. And the worst part? I couldn’t even prioritize it — because there was nothing to prioritize. No structure. No lifecycle. Not even a clear source of where these tasks were coming from.

That’s when it hit me: this isn’t a beginner’s problem.

Even experienced teams with strong technical skills often work without a system. They collect feature requests, confuse ideas with hypotheses, and spend entire sprints on things that don’t move the product forward.

That’s what this article is about.

How hypotheses are really born.
How they move through your system.
And how to keep your backlog from turning into a museum of failed ideas.

What a Hypothesis Really Is (and why “let’s just try it” doesn’t count)

When I first started working with hypotheses, I thought it was something out of a textbook. You write a smart sentence — and boom, you’re halfway to product/market fit. But reality is messier. In most teams, especially under deadlines or pressure from the top, the word “hypothesis” means anything: “Let’s add AI — maybe it’ll help”, “Our competitor has this, we need it too”, “The stakeholder says it’s a must-have”.

But none of these are real hypotheses. They’re just ideas or assumptions — usually with no goal, no metric, and no clear “why” or “for whom”.

A real hypothesis is a bet. It doesn’t start with a feature. It starts with an observation or a goal. Like this: if we show the CTA earlier during onboarding, users will engage faster, and activation will increase by 15% in 2 weeks. Now we’re talking: clear change (CTA earlier), expected outcome (faster engagement), a metric (activation), and a timeframe.

Why does it matter? Because you can’t test an idea — you can only build it. But you can validate or reject a hypothesis. And that changes how your team thinks. Instead of “this sounds cool, let’s ship it”, it becomes: what are we trying to change? why should it work? how will we measure it?

Here’s a real-world example. A PM on a B2B product suggested adding an eNPS report. Why? “Clients asked for it.” But when we dug into it, we found: who exactly? One client during a demo. Will it affect retention? Not really. Will people use it? Probably not. It just “sounded professional.”

If we had framed it as a hypothesis — “If we add an eNPS report, HR users will log in more often, and WAU will increase by 10%” — we would’ve seen it had no data or logic behind it. And maybe we wouldn’t have spent 3 weeks building it.

A hypothesis is not a feature. It’s a testable assumption linked to a goal and a metric. Everything else is just an idea — and should stay in a draft space, not in your backlog.

Where Do Good Hypotheses Come From? (Not from your head)

One of the most common problems I see — in my teams and in others — is this: tons of ideas, but zero real hypotheses.

Teams feel like they’re brainstorming strategically, staying close to the user, thinking ahead…
But in reality? They’re just throwing around interesting thoughts. “Wouldn’t it be cool if…” or “I’d love this as a user.”

That’s why the real skill isn’t inventing hypotheses — it’s extracting them from real signals. Here’s where I usually find them:

👂 1. User interviews and observations
Don’t ask “what do you want?” — listen for confusion, friction, hesitation.
Example:
“I didn’t get why that step was there — I thought I was done.”
→ hypothesis: remove the step or add clarity
→ metric: drop-off on that screen

📊 2. In-product behavior (funnels, Hotjar, GA, Amplitude)
60% of users abandon the form?
→ “If we simplify the form, activation rate will increase.”

📞 3. Support tickets, live chat, complaints
If users keep saying the same thing — it’s not noise.
→ “If we make X clearer, the number of tickets will drop.”

💡 4. Your team
UX, Devs, Sales, Ops — everyone sees things from a different angle.
They often spot low-level pain that never makes it to the backlog.
→ “If we give X to this role — they’ll do Y faster / better / easier.”

Idea ≠ hypothesis.
Idea = raw input.
Hypothesis = idea + context + goal + metric.

You can gather 30 ideas in a day.
But without structure and validation, it’s just a wish list. Not a system for growth.

How to Actually Write a Hypothesis — and Why “Let’s Just Try It” Doesn’t Work

When I first started working with hypotheses, it felt simple. You’ve got an idea → you test it → you see if it worked. But in practice, it was messier. We’d launch something “cool,” wait for feedback, a few weeks would pass… and then:
– we couldn’t say what we were actually trying to prove,
– no one had defined what “success” looked like,
– and even if something improved, we weren’t sure the feature caused it.

That’s when it clicked: an idea ≠ a hypothesis. And “ship it and see” isn’t a strategy — it’s a dice roll.

A real hypothesis is a logical bet: it has a reason, an expected effect, and a way to validate if it worked.

A good hypothesis answers three simple questions:

1. What are we changing? (action — X)

2. What do we expect to happen? (outcome — Y)

3. How will we know it worked? (metric — Z)

📌 Example:
If we reduce onboarding from 6 to 3 steps (X),
users will reach the first action faster (Y),
and activation rate will increase by 10% (Z).

Sometimes I call this the “X–Y–Z formula.” It’s simple — but it forces clarity around goals, impact, and measurability. Some teams prefer using the SMART model to frame hypotheses:
• Specific — clearly defined change
• Measurable — trackable outcome
• Achievable — realistic to test
• Relevant — tied to a goal
• Time-bound — has a deadline

It can be a good checklist, especially for less experienced teams.
But to be honest, I usually stick with the X → Y → Z format.
It’s faster, sharper, and pushes you to focus on outcomes and metrics right away.

🎯 Examples — so you can feel the difference

Here are real-world hypothesis drafts I’ve seen in teams — and how they can be improved.

❌ Raw or flawed hypotheses:

1. “Let’s add AI — maybe it’ll improve things”
   → What exactly improves? For who? Based on what metric?

2. “Add social login”
   → Why? For ease of use? For virality? For activation? What’s the goal?

3. “Let’s try a new button color”
   → Are we testing style? Or CTR? Define what success looks like.

4. “Show a discount banner to everyone”
   → Cool. But how will we know it worked? What’s the control?

5. “Competitors have this — we should too”
   → That’s not a hypothesis. That’s a fear of missing out.

✅ More structured, testable hypotheses:

6. “If we cut signup from 6 to 3 steps, more users will complete it”
   → Clear change, clear goal, measurable outcome.

7. “If we add onboarding tooltips, 20% of users will complete their first action faster”
   → Clear action → expected result → measurable metric.

8. “If we show doorstep delivery, conversion rate on product pages will rise 5%”
   → Business-focused, tied to funnel impact.

9. “If we add grouping by manager in the report, Finance will spend less time aggregating manually”
   → Clean B2B hypothesis. Metric = time saved or CSAT.

10. “If we send push notifications in the evening instead of morning, CTR will increase by at least 10%”
    → Simple, measurable, ready for an A/B test.

💡 Quick Hack: Turn a vague idea into a real hypothesis

Sometimes a teammate shares a rough thought. You feel it’s promising — but it’s not quite there yet. Ask the “triple question”:
→ What are we changing?
→ What do we expect?
→ How will we measure it?

Keep refining until you get to X → Y → Z.

Example:
❌ “Add social login”
✅ “If users can log in via Google, drop-off on the login screen will drop from 35% to 20%”

Train your team to think this way — and your hypotheses will instantly get sharper. So will your results.

What to Do With Hypotheses — And How They Enter the Backlog

Let’s say you now have solid hypotheses. Clear, testable, well-formed. What’s next? This is where most teams get messy.
– Someone drops a hypothesis in Slack — and it vanishes.
– Someone turns it into a task — and it sits in the backlog forever.
– Someone starts building — with no discussion, no validation, no priority check.

It’s like a mailbox where newsletters, bills, and half-written drafts live side by side. Useful things get lost.

🔄 A hypothesis needs a flow — from idea to action. Here’s how I usually handle it:

1. Formulation.
   Write it using the X → Y → Z format.

2. Context.
   Capture right away:
   – where it came from (data, users, founder insight, market signal),
   – what product or business goal it supports,
   – what kind of effort or resources it requires.

3. Task type.
   A hypothesis ≠ a feature. It can become:
   – a discovery task (interviews, UX research),
   – a growth experiment (e.g., A/B test),
   – or eventually a dev-ready feature (if validated and prioritized).

4. Backlog entry.
   Don’t just dump it into the backlog. Structure it: clearly marked as a bet, with goals, metrics, and next steps defined.

In my team, we split our backlog into three lanes:

📥 Ready for Refinement

The raw incoming stream: ideas, signals, stakeholder requests.
These usually sound like “we should probably look into this.”
Goal: turn that vague thought into a concrete X → Y → Z hypothesis.

🧪 Ready for Development

Validated and prioritized hypotheses.
We know why they matter and how we’ll test them.
Tasks here have scope, success criteria, and clarity.

🚀 Sprint (In Progress)

Stuff we’re actively working on.
Each item is clear about:
– what’s changing,
– what effect we expect,
– how we’ll measure results.

This structure doesn’t just bring order — it brings clarity. You don’t confuse a half-baked idea with a dev-ready story — but everything still lives in one place, with structure and flow.
When everyone understands the “maturity level” of an idea, there are fewer arguments and more alignment.
You don’t confuse an urgent bug with a deep research task, or a raw thought with a ready solution. Everything lives in one place — but with clear navigation.

📌 Why it matters
This setup helps the team stay on the same page. Stakeholder asks, long-shot bets, bug fixes, support issues, hypotheses — all mixed together.
It’s like stuffing your passport, a banana, and socks into the same backpack.
All important — but good luck finding anything when you need it.

💡 A well-structured backlog isn’t just a task list. It’s a reflection of how your team thinks and works.
It shows:
– How systematically you make decisions
– How you evaluate risks and opportunities
– Which tasks actually move the product — and which are just “nice to have”

What Hypothesis Prioritization Really Means

You’ve brainstormed, framed the ideas into hypotheses, and the team is ready to go.
But let’s be real: you can’t do everything.
There’s not enough time, people, or focus — and not every idea is worth the same.

🎯 That’s when prioritization kicks in. Not as a Jira checkbox, but as a way to say:
→ “This — we build first,”
→ “That — only if we have capacity,”
→ “And this — maybe later, not urgent.”

In mature teams, I’ve seen one pattern again and again:
A hypothesis enters the backlog — and instantly becomes a task.
No debate. No validation. Just: “Well, it’s written down, guess we’re doing it.”

But that’s not the point.
The point is to make a bet — which hypothesis is most likely to move the business forward?
And that means asking three simple questions:
– What does this change?
– Is it tied to our current goals?
– Do we believe it will work?

📌 To make this easier, have 2–3 frameworks your team can use on autopilot.

So… Which Framework Should You Use?

RICE, ICE, Impact vs Effort, WSJF — each has its strengths.
We broke them down in detail in a previous article.
If you missed it — here’s the link: How to Prioritize When Everything Looks Important
(yes, with tables, examples, and real-world tips for startups and corporates)

But if we keep it short:
The framework matters less than picking the one that fits your context.

– Got 10 hypotheses and 3 days? Use ICE.
– Planning a full quarter? RICE is your friend.
– Need a quick gut-check? Draw an Impact vs Effort chart.

💬 A quick tip
Sometimes prioritization turns into a taste war. Everyone has their favorite. No one backs down. That’s when I ask just one question:
📌“Does this help us reach our quarterly goal?”

If no — we park it.
If yes — we move forward, but with a clear “why.”

How to Build a System for Managing Hypotheses

Chaos begins where structure ends.
If your hypotheses are scattered among bugs, feature requests, and “please build this” emails from Sales —
you’ll quickly lose track of what you’re testing and why.

❗ Managing hypotheses isn’t just “running experiments.”
It’s the journey from messy input → to focused action.
Here’s what that system might look like:

📌 This structure not only brings clarity to your backlog — it also raises the level of thinking on your team. You’re not just building features. You’re making intentional bets.

Final thoughts

Many teams call hypothesis work “discovery” — and that’s not wrong.
But it’s important to understand: Product Discovery isn’t just about hypotheses (link for the article coming soon).
It’s the whole process — from identifying problems to exploring solutions, running interviews, tests, and building confidence along the way.
Working with hypotheses is a critical part of that — but it’s not the full picture.

At the same time, your backlog isn’t just a warehouse of features.
It should reflect how you think and make decisions.
And if you want your product to evolve with intent — not just instinct — start with something simple: learn to write and validate hypotheses.
Once you have that, prioritization, roadmaps, and team alignment will start falling into place.

Keep reading The Atomic Product

— Dmytro

If you're new here, here are a few posts to get you started:

• MVP Is Not a Product. It’s a Question.

• How to find a PM job and not go crazy?

• Your Roadmap Is Lying to You. Here's How to Fix It.

• B2B or B2C PM? Take the checklist and choose your side

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

At the startup, we were trying to survive. At the corporation — we were drowning.
In the first case, we had 100 ideas and 3 people. In the second — 300 requests and 5 engineers.

In both cases, prioritization was critical. But it worked in completely different ways.

At the startup, it helped us figure out what might actually work.
At the corporation, it was a filter — only the tasks truly worth the team’s time got through.

Two different kinds of pain. But one thing in common: if you can’t prioritize, your product is ruled by randomness.

At first, it feels like you’re just doing everything. But in reality, you’re spending resources blindly:
– “This came from the top — so it must be important.”
– “This one’s easy, let’s just knock it out.”
– “And this… well, let’s keep it — just in case.”

That’s how I burned the first few months on one project. We had a roadmap. We had frameworks. We even had metrics. What we didn’t have was clarity on why this, and why now.

🙃 And that’s the common trap: everyone knows WSJF, RICE, ICE, and all those clever frameworks — but no one explains where they actually work.

This article is not just another list. It’s a field guide:
when frameworks help, when they don’t — and how to choose what truly matters.

Why Prioritization Matters (Even If You Have a Roadmap)

In my previous articles, I wrote about building a product strategy and turning it into a roadmap — how to choose direction and lay out a path.

But here’s the thing: even with a crystal-clear strategy and a beautifully structured roadmap, things can go sideways.

Just open the backlog — and instead of a plan, you’ll hear a chorus of voices:

– “Marketing needed this yesterday!”
– “This is easy — we can knock it out in a day!”
– “It’s not really our job… but let’s keep it anyway.”

Prioritization isn’t just a buzzword for slides. It’s what protects your product from randomness.

Here are three scenarios where I’ve personally messed it up:

1. Startup: More ideas than users
We’d build whatever the founder came up with on a Friday night.
He’d come back from a conference saying,
“We need an AI feature — everyone has one now!”
No point arguing. We’d put it at the top of the list — just in case it worked.
Then spend the next month wondering why our retention was dropping.

2. Corporation: More tasks than engineers
Sales wants one thing. Finance wants another. Legal sends over tasks “for review.”
Without a formal system like WSJF or RICE, you end up circling in meetings saying,
“I’ll think about it.”
And then you do the thing that’s easiest to explain to a stakeholder.

3. Team dynamics skew everything
Even without external pressure, the loudest argument often wins.
– “This is critical for our users!”
– “No, this one is quick and easy!”
– “Let’s build that nice-looking placeholder — maybe it’ll click?”

Without a simple way to step back and look at the whole picture, your team stalls.

That’s where prioritization brings back objectivity.
Not “who’s more persuasive,” but:
– What are we doing now
– What’s next, if we still have capacity
– What’s nice to have — but not urgent

📌 Prioritization isn’t about a spreadsheet.
It’s about clarity and alignment.
And sometimes — it’s the only thing that saves your quarter from being wasted.

Read more

If you're new here, here are a few past posts you might find useful:

• MVP Is Not a Product. It’s a Question.

• From Features to Problem-Solving. 4 Steps to Mature Product Work

• Design Thinking: How to Think Like a Product Manager

• B2B or B2C PM? Take the checklist and choose your side

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

I’ve yet to meet a product team that doesn’t have a roadmap. But look closer — and in half the cases, it’s just a wish list spread across quarters. Or a slide deck made for investors the night before the deadline. Or a polished Miro diagram no one’s touched since last summer.

📌 The word “plan” sounds serious. But the further you look, the more it’s filled with vague features, artificial deadlines, and launches no one’s really tracking. As a result:
• The team loses focus
• The business ends up misaligned
• The product lives a life of its own

I’m not claiming to have the one true way. But in this article, I’ll show how we actually use roadmaps in real B2B practice — to align goals, actions, and people. Not as a formality, but as a working tool.

You’ll see how we structure initiatives, what makes it into the roadmap (and what doesn’t), and why some tasks matter more than others. All of it grounded in real-life product work — Jira tickets, FigJam boards, and weekly syncs with the team.

Read more

If you're new here, here are a few past posts you might find useful:

• 5 STEPS to Building a Product Strategy

• From Features to Problem-Solving. 4 Steps to Mature Product Work

• Double vs. Triple Diamond: Why two Product Diamonds aren’t always enough

• 14 Must-Read Books for Every Product Manager

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

Back in the early days of digital products, building something new felt like constructing a cathedral: years of work, an army of craftsmen, and a budget fit for a duke.

But times have changed. Today, if you don’t show the world at least a rough sketch of your idea — the market simply forgets you exist.

A Minimum Viable Product (MVP) isn’t some half-baked prototype, like many still assume. It’s the first working version that does one single important thing — but does it so well that users are willing to overlook everything else. Sometimes it tests just one hypothesis. But the key is: fast, cheap, and focused.

Take Dropbox.
Instead of launching the product, the team doubled down on something simpler: a video.

Drew Houston recorded a 3-minute screencast showing — as if the product already existed — how the service worked: file syncing, clean UX, a little magic. Viewers watched his mouse glide across the screen — and that was enough.

📌 Within a few days, the site got over 100,000 visits. Beta signups jumped from 5,000 to 75,000. The video got over 10,000 views — in just one day. And only then did the team start public development.

That’s the essence of MVP: not to build — but to first find out if you even should.

And that’s why MVPs aren’t just for startups. In large companies — where projects often drown in approvals — MVPs can cut through the red tape and validate if an idea has real potential. It could be an internal tool, a revamped service, or a process redesign. The point is to test value before making a big investment.

There are plenty of misconceptions here:
❌ MVP isn’t a “student project.”
❌ It’s not “let’s just launch and figure it out later.”

The point of an MVP is not to release something crappy.
It’s to learn — quickly — whether anyone actually needs what you’re building. And if so, what exactly they need.
The sooner you know that, the less time and money you’ll waste.

How MVP Differs from a Wireframe, Mockup, or Prototype

Let’s be honest — there are way too many terms out there.
Wireframe, mockup, prototype, MVP — sounds like you need a UX design degree just to make sense of it all.
But if you zoom out, it’s actually pretty simple.

Read more

If you're new here, here are a few past posts you might find useful:

• From Features to Problem-Solving. 4 Steps to Mature Product Work

• 14 Must-Read Books for Every Product Manager

• Design Thinking: How to Think Like a Product Manager

• User Interviews: How To Understand Users And Avoid Building The Wrong Product

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

Imagine an engineering team that has everything — resources, tools, skills. Everything but one thing: a shared understanding of where they’re headed. Every day they’re doing something useful, but it doesn’t add up to a clear picture.

This isn’t a scenario from a business book — unfortunately, it’s the reality for many product teams.

Product Strategy isn’t a beautiful presentation or a formality for investors. It’s your navigator.

It defines which user problems are worth solving first, where the product should evolve, and how it supports the company’s goals.

When there’s no strategy, the team moves blindly. Priorities constantly shift, initiative gets diluted, and the product loses focus.

Without a strategy, you’re not managing a product — you’re just putting out fires.

If this sounds familiar, it’s time to pause and build a strategy intentionally. This article offers concrete steps on how to do it.

Read more

If you're new here, here are a few past posts you might find useful:

• 14 Must-Read Books for Every Product Manager

• B2B or B2C PM? Take the checklist and choose your side

• Practical Guide to User Interviews — Part 1: Preparation & Execution

• Practical Guide to User Interviews — Part 2: Analysis & Insights

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

Product development is rarely a straight line from idea to success. Most of the time, it’s a set of parallel streams — signals, hypotheses, urgent features, unfinished initiatives, and eternal promises to “refactor later.”
Sounds familiar?

One of the most common issues teams face is the lack of a holistic, structured approach to product work. Sure, frameworks like Double Diamond, Lean Startup, or Design Thinking are great navigational maps — they tell you what to do.

Methods like Jobs-to-be-Done, Customer Journey Mapping, or A/B testing help answer how to do it.

But there still remains a gap with the question of “when exactly to do this” and in what order.

Most product managers understand (in theory) that we should start by exploring the problem, validating a hypothesis, and only then writing code.
But in practice, things get blurry.
Teams jump into solution mode and reverse-engineer the problem to justify it. Or they get stuck in endless discovery and never reach delivery.
And what comes next? Chaos.
And chaos in product = a guessing game. Maybe it works, maybe it doesn’t.

To avoid this, you need a conscious product cycle — one where each step helps you make smarter decisions in the next. A process with no wasted motion or meaningless delivery. Where the team knows how to separate signal from noise — and real solutions from quick fixes.

In this article, I’ll walk you through what such a cycle looks like in real life (in my team). No glorified case studies or LinkedIn theater — just a practical, four-step framework that covers what, how, and when:

1. How the team recognizes a real problem — instead of trying to fix everything at once

2. How we verify that the problem actually exists and is worth solving

3. How we search for and validate the right solution — before writing a line of code

4. And only then — move to development and rollout

This isn’t a universal truth — it’s a practical model you can adapt to fit your own team, tools, and culture. Depending on your product’s maturity and team setup, this cycle may look different — and that’s okay.
What matters most is that a cycle exists at all.

Read more

If you're new here, here are a few past posts you might find useful:

• 14 Must-Read Books for Every Product Manager

• What is Product Management all about?

• Double vs. Triple Diamond: Why two Product Diamonds aren’t always enough

• User Interviews: How To Understand Users And Avoid Building The Wrong Product

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

This is the second part of our hands-on guide to user interviews.
If you missed the beginning — start with Part 1 here: [Practical Guide to User Interviews — Part 1: Preparation & Execution]

In Part 1, we focused on preparation. Now it’s time to dive into the real action — how to conduct interviews in the wild. Step by step, we’ll explore how to listen actively, ask better questions, follow the conversation, and extract real insights that can shape your product.

Step 5. Interview Process: How Not to Mess It Up

You've done the prep — you’ve got your objective, your guide, your respondents. You're technically ready and know how to start. Now comes the most important part: running the interview itself.

If the interviewer talks more than the respondent, asks leading or overly complex questions, or dominates the conversation — the value of the interview drops to zero. Below are key principles to help you get real insights, not just “a nice chat.”

Read more

If you're new here, here are a few past posts you might find useful:

• Design Thinking: How to Think Like a Product Manager

• Double vs. Triple Diamond: Why two Product Diamonds aren’t always enough

• B2B or B2C PM? Take the checklist and choose your side

• 14 Must-Read Books for Every Product Manager

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

In the first part of this series, we covered why user interviews matter and the mistakes even experienced PMs often make [link]. Now it's time to get down to the practical side of things — we’ll break the user interview down to its atomic components.

I’ve put together a detailed guide (in two parts) to help you run interviews that actually lead to insights and impact.
Ready? Let’s go. 🚀

Preparing for the interview: 60% of success happens here

If you’re asking yourself, “Do I really need to prepare?”, the answer is simple: a poorly prepared interview is worse than no interview at all.

A user interview isn’t just a “chat with a user.” It’s a research tool — one that should influence your product strategy. But if you’re not prepared, the whole thing turns into a waste of time.

🚨 Without proper prep:

• ❌ You’ll ask vague questions and get useless answers.

• ❌ Your interviewee will be confused and give you superficial feedback.

• ❌ You won’t be able to compare interviews or extract patterns.

An interview ≠ conversation. It’s a decision-making tool. And like any tool, it works only if it’s properly set up.

Proper prep includes three key steps:

1. Defining your objective: What exactly do you want to learn?

2. Choosing the right people: Who should you talk to and where do you find them?

3. Building your interview guide: What questions will lead to real insights?

Let’s break each one down.

Read more

If you're new here, here are a few past posts you might find useful:

• Design Thinking: How to Think Like a Product Manager

• What is Product Management all about?

• B2B or B2C PM? Take the checklist and choose your side

• User Interviews: How To Understand Users And Avoid Building The Wrong Product

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

Ever heard of the Double Diamond?

That two-diamond model everyone loves to sketch on whiteboards — one for exploring the problem, one for solving it. It pops up everywhere: UX courses, strategy workshops, design thinking books.

But what if I told you the UK Design Council didn’t exactly invent it? That it’s more of a tidy package of long-standing ideas, wrapped up neatly in a visual everyone could get behind? And that the concept itself has gone through several evolutions — all the way to systemic design thinking?

If you’re curious about the full backstory — how the Double Diamond came to life, how relevant it still is, and how it evolved into the Systemic Design Framework — check out the official UK Design Council page or Benjamin P. Taylor’s deep dive into its intellectual roots.

But my goal — as always — is to save you time and cut straight to the essence:
Why did the Double Diamond become a cult classic in product work? What’s really behind it? And most importantly — how do you actually use it without turning it into a dogma?

The Double Diamond

The Double Diamond (a.k.a. the double rhombus) is a simple four-step model for design and problem-solving.

The Four Stages of the Double Diamond

Here’s the core idea behind the process:

Read more

If you're new here, here are a few past posts you might find useful:

• Design Thinking: How to Think Like a Product Manager

• What is Product Management all about?

• Practical Guide to User Interviews — Part 1: Preparation & Execution

• Practical Guide to User Interviews — Part 2: Analysis & Insights

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

Imagine you're building a bridge across a river. You don’t know how wide it is, how strong the current runs, or what the riverbed is made of. But you start building anyway, hoping for the best.
Now imagine you studied the river beforehand: measured the depth, analyzed the current, picked the right materials.
Which bridge would you trust more?

Building a product is no different. If you don’t understand your users, you're building a bridge to nowhere. It might look great — but no one will want to use it.

🔹 This article is your first step to avoiding that trap. Here's what we'll cover:
✔️ Why user interviews are one of the most powerful tools in a product manager’s toolbox
✔️ How they help at every stage — from idea to launch
✔️ Common mistakes even experienced PMs make (and how those lead to failure)

If you already get the “why” and want to jump into the how, check out the next article where we dive into the practical side: how to write good questions, avoid vague wording, and run the interviews effectively [link].

Why skipping interviews puts your product at risk

You came up with a brilliant idea. You told your friends, and they said:
— "Wow, sounds cool, I’d totally use that!"

You spent six months building it. Tens of thousands of dollars. You launched… and nothing happens. Silence.

What went wrong?
You trusted words, not behavior. People often say they’re interested in something, but that doesn’t mean they’ll actually use it — or pay for it.

Here are a few classic failure scenarios that interviews could have prevented:

🚨 Solving the wrong problem
You built a dating app that matches people based on IQ. You thought people were looking for smart conversations. Turns out they just want quick matches and hot photos.

🚨 Real problem, but not painful enough
You launched a tool to help corporate teams plan their yearly goals. People say: “Sounds useful,” but in reality, they’re fine with Excel and Slack — and don’t want to switch.

🚨 You can’t explain the value
You created a platform that speeds up call center workflows by 30%. Sounds important, right? But when you try selling it to B2B clients, they don’t get it. You’re not speaking their language.

In all these cases, user interviews would’ve helped you see the truth before burning time and money on the wrong build.

Where Do User Interviews Help?

First, remember: user interviews are not some isolated ritual. They’re part of your research process.
Before you sit down with users, you need to be clear on a few things:
– What’s your research goal?
– What hypotheses are you testing?
– Who is your target audience?
– What questions really matter right now?

If you haven’t figured this out yet — it’s too early for interviews. Otherwise, you’ll collect a bunch of scattered, low-value answers.

User interviews are conversations with users that help you understand:
✔️ What real problems they have
✔️ How they’re currently solving them
✔️ Why existing solutions don’t work for them

But it’s not just “opinion polling.” People don’t always tell the truth (more on that later).
A proper interview helps you cut through surface talk and get to the insights that really matter.

When are interviews essential?

1️⃣ Product Discovery – You’re at square one. Trying to figure out if there’s even a real problem.
2️⃣ Product Strategy – You know the problem exists, but not sure which solution will win.
3️⃣ Go-to-Market (GTM) – You need to figure out how to position and sell your product.
4️⃣ Pivot – The product isn’t working. You need clarity on why — and where to go next.

🔥 Example: Instagram
Back when Instagram was still called Burbn, it was packed with features — geolocation, check-ins, all sorts of social mechanics. The team thought users wanted gamification.
But interviews revealed something different: people just wanted beautiful photos.
Users were only uploading pictures to use the filters.
So the team stripped everything else away — and Instagram as we know it was born.

Common Mistakes in User Interviews

Even if you know interviews are important, it’s easy to do them wrong. Here are the most common traps:

🚨 1. You’re looking for validation, not truth
You ask:
— “What do you think about our smart-dating app idea?”
And people say:
— “Sounds cool!”
But that tells you nothing. People tend to agree out of politeness or to keep the conversation going.

👉 Fix it: Don’t ask if they like the idea. Ask:
✔️ “When was the last time you had this problem?”
✔️ “How did you solve it?”
✔️ “What didn’t work for you?”

🚨 2. You ask about the future instead of the past
People are terrible at predicting their behavior.
They’ll say they’d pay for something — but when the moment comes, they don’t.

🔥 Example: Airbnb
Early on, they asked homeowners:
— “Would you rent your home to travelers?”
Everyone said “yes”… but nobody signed up.
Only when the team asked about past behavior did they learn people were worried about safety and legal risks.

👉 Fix it:
✔️ Focus on past actions, not hypotheticals
✔️ Use the “5 Whys” technique to dig deeper

🚨 3. You’re talking to the wrong people
A common mistake: interviewing friends, coworkers, or just random folks.

🚨 Building something for HR managers? Don’t talk to developers.
🚨 Targeting freelancers? Skip the 9-to-5 crowd.

👉 Fix it:
✔️ Go where your real users are (Reddit, LinkedIn, Telegram, niche forums)
✔️ Prioritize people who’ve already tried solving the problem

🚨 4. You’re interviewing without a clear purpose
Another trap: running interviews without knowing what you're trying to learn.
The result? A messy chat and vague takeaways.

👉 Fix it:
✔️ Define a clear research question before you begin
✔️ Stay focused on specific user experiences — not abstract ideas

🚨 5. You’re drawing shallow conclusions
If your insight sounds like “people order food delivery because they’re hungry” — your interview didn’t dig deep enough.

👉 Fix it:
✔️ Don’t just focus on what users do — ask why they do it
✔️ Analyze the full context behind their decisions

What’s Next?

Even experienced product managers — people who’ve launched million-dollar products — often avoid or underestimate interviews.

Why?
In my experience, I’ve heard things like:

🚨 “I’ve launched products worth millions. I know what users want.”
That’s confirmation bias at work — when we look for proof that we’re right instead of seeking the actual truth.
But markets evolve, and so do user behaviors. What worked yesterday may fall flat tomorrow.

🚨 “It’s too slow and complicated.”
At first glance, interviews feel like endless conversations that are hard to analyze.
But here’s the irony: the cost of being wrong is 10x higher than the cost of doing proper interviews.

🚨 “Let’s just launch an MVP and see what happens.”
But launching an MVP without a validated hypothesis is just gambling.
You're hoping to hit the mark, but you don’t even know what you're testing.

The Real Reason Interviews Get Ignored

User interviews seem simple — but that’s what makes them tricky.
The devil’s in the details:

❌ Poorly phrased questions can distort reality
❌ The wrong people can lead you to false insights
❌ Shallow analysis won’t uncover real motivations

That’s why we put together a follow-up article — a practical guide to running user interviews.

In the next piece, we’ll walk through:

✔️ How to create an interview guide that actually works
✔️ Common mistakes in question phrasing — and how to fix them
✔️ How to structure and run the interview process to get valuable, actionable insights

📌 Ready for the “How”?

User Interviews aren’t just conversations. They’re a method. A mindset.
When done right, they help you make smart product decisions based on real data — not gut feelings or guesses.

This was the “why” behind user interviews — why they matter and how they can make or break your product.

If you’re ready to dive into the “how,” check out the next parts of this series:

👉 Practical Guide to User Interviews — Part 1: Preparation & Execution
How to plan, write good questions, recruit the right people, and run interviews that surface real insight.

👉 Practical Guide to User Interviews — Part 2: Analysis & Insights
How to make sense of what you heard, identify patterns, and turn raw conversations into product decisions.

🔥 Want to go deeper? Here are three must-read books on the topic:

📖 The Mom Test by Rob Fitzpatrick — how to ask better questions and get honest feedback
📖 Lean Customer Development by Cindy Alvarez — how to validate ideas without wasting time and money
📖 Talking to Humans by Giff Constable — how to find the right people to interview and actually learn from their answers

Thanks for reading Atomic Product.

If this resonated, feel free to reply, share your thoughts, or tell me how you approach user interviews.
Talk soon,
— Dmytro

Share

If you're new here, here are a few past posts you might find useful:

• Double vs. Triple Diamond — why two aren’t always enough

• What is Product Management all about?

• B2B or B2C PM? Take the checklist and choose your side

• User Interviews: How To Understand Users And Avoid Building The Wrong Product

Hit subscribe if not on the list yet— and let’s roll 👇

Subscribe now

Imagine you’re building your own product — say, a mobile app that helps people learn to play guitar. How do you make sure users don’t just download it because “a friend said it was cool,” but actually find real value in it?

That’s where Design Thinking comes in. It keeps you from building something no one needs — and instead guides you toward the right insights from real users. So today, let’s talk about what Design Thinking is, where it came from, how it works, and why every successful product manager should know how to use it.

What is Design Thinking?

The concept of Design Thinking dates back to the 1960s, but it really gained traction in the 1990s thanks to IDEO (one of the world’s top design consultancies) and Stanford professors like David Kelley and Terry Winograd. The core idea? Solve problems that actually matter to users — by deeply understanding their needs and pain points.

Design Thinking is especially powerful for product teams because it:

• Helps you test ideas quickly without massive budgets.

• Leads to solutions that people actually want.

• Encourages cross-functional collaboration within the team.

Plenty of well-known companies rely on this approach. For example, Airbnb used Design Thinking to uncover why users weren’t booking places to stay — and revamped the search experience accordingly. IBM baked the method into their company culture to create more intuitive user interfaces. And Apple? They’ve made Design Thinking a standard part of how they improve product experiences.

Bottom line: Design Thinking is now used across industries — from tech and fintech to healthcare and beyond.

Design Thinking vs. Double Diamond

Some product managers might confuse Design Thinking with frameworks like Double Diamond or Triple Diamond. While all of them are about solving problems, they focus on different things.

Double Diamond is a structured, linear process: research → define the problem → generate ideas → implement. Triple Diamond adds a scaling phase to that process.

Read more