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:

• LLM, ML, AI: What’s the Difference — and Why It Matters for Product Managers?

• What is Product Management all about?

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

• How to Turn Your Metrics into a Product Growth System

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

Subscribe now

When I first started working in product, I thought a Product Manager was just the person who decided which features to build next.
Pick the important stuff, hand it over to the dev team — done.

But then came the Product Owner. Then the Program Manager. Then Project. Then the Product Marketing Manager.

And suddenly you’re not sure anymore:
Are you still managing the product — or just running between meetings, taking stakeholder requests, and assigning tasks?

It’s funny, but even in 2025, people still confuse these roles — and it’s not just a terminology issue.
It’s about focus, ownership, and all the places where things can go wrong.

In one case, the backlog is empty because no one wrote the tasks.
In another, the roadmap is filled with features someone saw in a competitor’s LinkedIn post.
And in a third — the product is live, but no one knows how to sell it.

This article is for anyone who wants to finally make sense of who’s responsible for what.
If you’re a new PM, prepping for interviews, building a team, or just trying to clear the fog in your head — welcome.

We’ll keep it simple:
Five roles. Five key questions they answer. And one table you’ll probably want to bookmark.

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

• 40 AI Tools to Supercharge Your MVP

• AI Agents 101: What They Are — and Why PMs Should Care

• How to Turn Your Metrics into a Product Growth System

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

Subscribe now

Seems like every other startup these days calls itself an “AI-powered platform for smarter workflows.”
And every other PM writes in their resume: “building with AI.”

But let’s be honest — most people are just winging it.
– What’s ML vs. Generative AI?
– How is LLM different from plain old AI?
– And most importantly — what does this all mean for you as a product manager?

When everything is becoming “AI-powered,” it’s crucial to know what’s actually under the hood.
Not for the buzzwords — but so you can:

– avoid falling for hype and the promise of magic buttons
– understand what the tools can (and can’t) do
– and, finally — integrate AI into real product features, not just add shiny “Generate” buttons

This article is your short, practical breakdown of key terms — with real-life examples where PMs are already putting them to work.

AI, ML, LLM, Generative AI — what’s the actual difference?

If you’re confused by all the acronyms — don’t worry.
Even some so-called “AI specialists” throw these terms around without knowing where one ends and the next begins.

Let’s break it down. In plain English — with product examples.

AI (Artificial Intelligence) is the big umbrella.
Anything that lets a machine “think,” make decisions, or draw conclusions — things only humans used to do — now counts as AI.

If your inbox automatically sorts emails into Important vs. Promotions — that’s AI.

📌 Examples: Gmail Smart Reply, Google Translate, Tesla Autopilot

ML (Machine Learning) is how AI is usually built.
Instead of writing all the rules manually, we give the model a ton of examples — and it learns to recognize patterns.

For instance, a bank’s fraud detection system studies thousands of shady transactions — and then catches similar ones on its own.

📌 Examples: Amazon Recommendations, LinkedIn “People You May Know,” Grammarly

Deep Learning is a turbocharged subset of ML.
Here, models go deep — literally. They use neural networks with dozens or even hundreds of layers. This makes them great at handling complex inputs like text, images, speech, or video.

If ML is like a high-schooler, Deep Learning is a neuroscience grad.

📌 Examples: facial recognition, live translation, voice cloning

And yes — LLMs are built using Deep Learning. They’re just specialized for text.

LLMs (Large Language Models) are a specific type of model designed to work with language.
They’re trained on billions of words — so when they talk to you, it feels like chatting with a philosophy major.

They’re not pulling answers from a database. They generate them on the fly — word by word — based on probabilities. Sounds boring, works like magic.

📌 Examples: ChatGPT, Claude, Gemini, Mistral

Important to know:
LLMs aren’t the only game in town. There are SAMs (for visual data), VLMs (for text + image), MoE (mixture-of-expert models), and more.
But LLMs dominate most product use cases today: messaging, analysis, ideation, automation.

Most LLMs are built using transformers — a type of neural network architecture that’s great at handling context and meaning. You don’t need to go deep into it, but it’s good to know it exists.

Generative AI isn’t a model — it’s a capability.
If AI helps decide, Generative AI helps create.

Text, images, code, music — you give it a prompt, it gives you something new.
All LLMs are part of Generative AI, but not all Generative AI is based on LLMs.

📌 Examples:
— Text: ChatGPT, Jasper, Copy.ai
— Images: Midjourney, DALL·E
— Video: Runway, Pika
— Music: Suno, Udio

📍Quick recap:
• AI — the umbrella
• ML — the learning method
• Deep Learning — souped-up ML using neural nets
• LLM — language-focused models
• Generative AI — anything that creates, not just responds

If that made sense — great.
If your brain still feels a bit scrambled — don’t worry.
Next up, we’ll look at how this actually connects to your work as a product manager.

Why should PMs even care about these terms?

Simple:
AI is getting deeper into our products, features, and internal processes.

At first, it was enough to throw around “AI,” “ML,” or “LLM.” But the landscape keeps evolving — and so do the opportunities.

Now we’re dealing with the next layer: AI workflows, AI agents, RAG, memory, and more.
And these aren’t just buzzwords from conference slides. They’re practical tools that open new doors for product teams:

• Automate repetitive tasks (for your team or users)
• Rapidly build MVPs using pre-trained models
• Launch features that used to require 10× the time and budget

But to actually use these tools, you need to understand what’s behind them — at least at a basic level.

Not just “LLM is a big model,” but:
“Right — this means I can build a bot that reads my documents, understands the context, and pulls data from external APIs — not just answers chat prompts.”

That’s why it’s worth getting familiar with the layers. And that’s exactly what we’ll do next — walk through how a simple ChatGPT bot evolves into a full-blown AI agent.

Step by step. No magic required.

From ChatGPT to AI Agents: Step by Step 🔄

When people hear “AI in the product,” they still often picture ChatGPT — a chatbot you type into, and it replies.

But that’s just the starting point.

AI tech is evolving fast — and so are expectations for what we can actually build with it.

📌 From casual chatting → to advanced automation and decision-making.

To avoid repeating myself — I already broke down this evolution in detail in a previous article:
🔗 [AI Agents 101: What They Are — and Why PMs Should Care]

That article covers each step, from:
– memoryless LLMs,
– to tools with data access,
– to full AI agents with planning, memory, and tool usage.

👉 If you haven’t seen it yet — I highly recommend checking it out.
It’s packed with real examples, no fluff, and an easy-to-follow visual.

For now, here’s a quick snapshot to understand the spectrum 👇

🧠 RAG (Retrieval-Augmented Generation) is a method to connect your LLM to actual data.
It gives the agent not just “intelligence,” but access to relevant info — from your help center, CRM, wiki, you name it.

If you're building an AI assistant that needs to answer real product or policy questions — you probably need RAG.

Want to go deeper? Here's a hands-on guide to building your own RAG-based AI assistant:
📌 Guide: Build your first RAG-based assistant

Just getting started with prompt writing?
📌 Prompt Engineering Guide (Google Cloud)
📌 OpenAI Cookbook Prompting Guide

🧩 Now let’s break down the real difference between an AI workflow and an AI agent — and why it matters more than you think.

AI Workflow or AI Agent — What Counts as “Real AI”?

You’ll often hear someone say they “built an agent” — but in reality, it’s just a two-step Make automation:
receive an email → save it to Notion.

Or the opposite: a product executes a complex multi-layered flow, but no one on the team calls it an agent — because “we just fine-tuned a model.”

🎯 Everything gets blurred. And yeah, that makes it harder to communicate —
whether you're working with your team, pitching to investors, or hacking through a weekend project.

Let’s clear it up. No fluff.

🧩 AI Workflow = Automation with a Brain

Think of it like your usual automation — but with a touch of intelligence.

Example: you build a Make scenario that:
• collects form submissions from your website,
• sends them to GPT for a short summary,
• and posts the output to Slack.

Smart? Sure.
But it’s still a linear pipeline. GPT is just one clever step in the flow — not an autonomous player.

📌 Tools: Make, Zapier, Pipedream, n8n + OpenAI API
📌 Your PM role: Spot opportunities to embed AI — to remove manual work or speed up decision-making.

🧠 AI Agent = Autonomous Behavior

Now compare that to an agent. You say:
“Process incoming requests, prioritize them, and post a summary to Slack — but only if the priority is over 7/10.”

What does the agent do?
• It analyzes the inputs,
• figures out which ones are worth acting on,
• decides what to send, and to whom,
• remembers who was already processed,
• and adapts the steps if something breaks.

It’s not just following instructions — it’s working toward a goal.
More like an assistant than a pipeline.

📌 Tools: n8n with decision logic, LangChain, CrewAI, AutoGen
📌 Your PM role: Define the behavior, constraints, and goals.
Not coding — designing what should happen and why.

🤔 So where’s the line?

That’s the tricky part — it’s all starting to blur:
– Some workflows in Make are almost agents already
– And some “agents” are just glorified workflows with fancy labels

So here’s a simple way to tell the difference:

👉 Workflow answers: "What to do and when?"
👉 Agent answers: "What am I trying to achieve — and how can I get there?"

📌 If you’re defining goals (not just steps) — you’re building an agent.

📍And yes — next we’ll look at what that actually means for you as a Product Manager:
How to design these systems, what real-world use cases look like, and where to even begin.

How a Product Manager Can Use LLMs, Workflows, and Agents in Real Work

So — you’ve figured out what counts as an agent and what’s just a clever workflow.
Now comes the real question:

How can this actually help in product work?

The answer depends on your team’s maturity, infrastructure, and use cases.
But here are three practical scenarios where AI tools actually work for the PM — not just entertain them in a browser:

📌 Scenario 1: Fast automation without devs

What you use: ChatGPT, Make, Zapier
What you automate: one-off tasks, quick wins, repetitive work

Examples:
• Enrich incoming leads with company info from the web
• Turn call transcripts into summaries and send to Notion
• Prompt-check your PRD for logical gaps

💡 PM Bonus:
You don’t need engineers. You don’t write code.
You just do it yourself.
Low barrier, visible results.

📌 Scenario 2: Custom AI tool for your team

What you use: Custom GPT, Copilot, Make + GPT API
What you automate: repeated requests, content generation, personalization

Examples:
• A Custom GPT that knows your company’s support processes
• An AI assistant that writes cold emails based on client profiles
• A generator that creates test cases from user stories in the backlog

💡 PM Bonus:
You build an actual “AI feature” — no backend required.
Speed is high, and the output quality depends on your prompts and internal knowledge base.

📌 Scenario 3: Designing logic for complex processes

What you use: n8n, LangChain, AutoGen, CrewAI
What you automate: tasks with logic, adaptation, memory

Examples:
• An agent processes support tickets: classifies, detects duplicates, routes to the right team
• It scrapes competitor data, aggregates it, and sends weekly insights
• An AI assistant reviews pull requests and comments when something breaks the rules

💡 PM Bonus:
You define goals, roles, and behavior.
You’re not coding — you’re architecting logic.
You might need a technical helper, but you are the conductor.

🛠 Alternative Use Cases: What This Looks Like in Real Life

If the above still feels abstract, here are three real examples of how AI is already helping in product work:

1. 🤯 “No one reads our Help Center — and Support is drowning in repeat questions”

The pain:
Support wastes hours answering the same questions.
You don’t want to pay for Zendesk AI or build a bloated chatbot.

The fix:
Build a Custom GPT trained on your FAQ, internal docs, and guidelines.
Embed it on your site with a chat widget.
Users ask questions, get answers — from a bot that knows your product.

Result:
• Up to 50% of repeat requests are handled without human support
• Support team is thankful for “a real assistant”
• Users are happier — they get precise answers, not just buttons and links

2. 📊 “We have data — but I still run to the analyst every time”

The pain:
You want to see key metrics (like Retention) fast, but SQL isn’t your thing, and dashboards are often outdated.

The fix:
Connect AI to your BI tool (e.g., ChatGPT + Metabase or Google Sheets API).
You type: “Show Retention for cohort X” — and get a chart.
Follow up with: “Compare to campaign Y.”

Result:
• Less manual work
• Closer to the data
• Faster, data-informed decisions

3. ⚙️ “Everything’s automated… but 80% still happens manually”

The pain:
You built a workflow in Make: lead → GPT summary → Slack.
Nice. But you still manually check relevance and remove duplicates.

The fix:
Add agent logic in n8n:
• Agent identifies high-value leads
• Checks for duplicates
• Tracks what’s been processed
• Sends notifications only when needed

Result:
• Less noise
• Less routine
• The team starts trusting automation

Wrapping up

AI tools for PMs aren’t about the future. They’re about the now. It’s not about a bot writing your backlog. And you don’t need to be an ML engineer.

But here’s what you do need:

• Know when AI solves a real problem — and when it’s just hype
• Break down agent behavior: what should happen, under what conditions, with what data
• Explain to your team why you’re building a system — not just writing another prompt
• Evaluate risks: privacy, answer quality, need for human review

🧩 And most importantly — don’t be afraid to experiment. The real entry barrier to AI today isn’t technical.
It’s product thinking.

💡 Want to go deeper? A couple more useful links:

• Here's a curated list that covers the full GenAI landscape — from tools to best practices: 📌 Awesome Generative AI Guide

• If you want to test different LLMs side by side — 📌 this tool lets you switch between GPT, Claude, and Gemini in one window. Great for testing and side projects. Just $10/month. (I’m not affiliated.)

Thanks for reading Atomic,

Stay in touch😉

— 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:

• Design Thinking: How to Think Like a Product Manager

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

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

• How to Prioritize When Everything Looks Important

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

Subscribe now

Advice on how to grow in product is everywhere — maybe more than actual product managers.
Read books. Watch videos. Learn by doing. Take ownership. Build your own product. Go to meetups. The list goes on.

These are all good suggestions. But they can be noisy and overwhelming.
The real problem? You still don’t know what you should do next.

– If you're already a PM but feel stuck — how do you figure out where to grow?
– If you're just getting started — what should you learn first, and how?

This article isn’t about motivation. And it’s not another philosophy piece.
It’s a hands-on map: where to look, how to plan your growth, what tools to use — and how to get better in real life, not in theory.

You’ll find:
– Curated links to books, courses, blogs, and tools I wish I had at the beginning
– A few practical ways to build a learning plan (and actually stick to it)
– And some underrated ideas for growing as a PM — even without a “perfect” project

This is not “the ultimate truth.”
Think of it as an entry point — into the profession, into this blog, and into a more systematic approach to growth.

Bookmark it. I’ll keep updating the guide with new materials over time.

Step one: Understand where you are

Learning everything all at once doesn’t make you better. Before building a plan, you need to know where you're starting from.

You might be:
• just exploring product management and not sure where to begin
• a working PM stuck at a plateau
• a mid-level PM aiming for CPO but unsure what’s missing
• even a senior with years of experience, yet struggling to grow “horizontally”

Wherever you are — the starting point is always the same: build a map of your territory.
Figure out what you already know — and where the gaps are.

🔍 How to start

1. Get the big picture
If you haven’t read it yet — start with this article:
→ What is Product Management all about?

It covers:
• how different companies define the PM role
• how your tasks depend on the product’s stage (from discovery to decline)
• and which skills remain core no matter where you work

This matters. Without a clear view of the whole landscape, you can’t choose your next step.
A product career isn’t a ladder — it’s more like a maze. You need to know what wing you’re in.

2. Assess your current skillset
Pick any framework — from the Mind the Product model to my simplified version.
It typically includes blocks like:
• Product Discovery
• Research & Analytics
• Stakeholder Communication
• Roadmapping
• Delivery & Team Process

Go through each block and ask yourself honestly:
– Can I do this?
– How confident am I?
– Do I use this in real work?

🎯 You can just score each from 0–3 in Excel or Notion. Even better — write down real examples.

3. Connect it to your career goals
Want a raise? A lead role? A switch to AI products?

Your growth priorities will change depending on where you’re headed.
The article above breaks down how the PM role shifts by product stage — check where you are, and what you’re missing.

Next step?
Don’t try to “level up everything.” Build a personal plan — even if it’s just scribbled on a napkin.

Step two: Build your PDP (and not abandon it a week later)

PDP is your way of staying afloat in the chaos of tasks, courses, and ideas.

Most PMs walk around with a brain full of thoughts like:

“I want to improve my metrics — but no clue where to start”
“There’s just too much — Discovery, UX, analytics, strategy…”
“I feel like I’m constantly busy — but not really moving forward”

But here’s how a PDP can actually help.

🔹 What is it, really?

PDP = Personal Development Plan.
In practice, it’s a simple tool to:

• Define what skills you want to level up

• Understand why they matter to you

• And attach concrete steps to each one

💡 It’s not “take a course for the sake of it.”
It’s your answer to:
“What do I want to be able to do — and how will I actually learn it?”

🔹 How to build your PDP in 5 steps

1. Pick 2–3 focus areas per quarter
   Don’t try to improve everything at once. Fewer goals — deeper growth.

2. Describe what exactly you want to improve
   Not just “analytics,” but “I want to learn how to formulate hypotheses and validate them using SQL + Amplitude.”

3. Assess your current level (scale: 0–3)

• 0 — “Heard about it, never touched it”

• 1 — “I get the basics, but don’t use it”

• 2 — “I use it sometimes”

• 3 — “I use it confidently and help others”

4. Write down your plan — how will you learn it?
   For example:

• Take a course (and specify which one)

• Build a mini-project

• Discuss it with a mentor

• Apply it in a real work project

5. Set a deadline and a checkpoint
   e.g. “By the end of the quarter” or “First user interviews by end of the month”

🔹 What if you have zero time?

If you’re in “firefighting mode” and can’t sit down even for 30 minutes, just answer these 3 questions:

• What do I want to be able to do in 3 months?

• What’s stopping me from doing it now?

• What’s one step I could take this week?

Sometimes that’s enough to shake off the paralysis and get moving again.

How to Actually Grow as a Product Manager

There’s too much content. Too little time. Courses, books, podcasts, interviews, meetups, certifications… It’s easy to get lost.

But there’s one mental model that helps cut through the noise.

🔄 The 70:20:10 Model — A Practical Way to Grow as a PM

Many people think product growth = a bunch of courses and certificates. But real growth works differently.

The 70:20:10 model, used in corporate learning programs, offers a more grounded approach:

• 70% — Learning by doing
  That’s the core. Growth happens when you run discovery, write hypotheses, ship features, make mistakes, and try again.

• 20% — Learning through others
  Team retros, peer feedback, mentoring, stakeholder reviews — all help you see blind spots and sharpen your thinking.

• 10% — Formal learning
  Courses, books, lectures, articles. Still useful — but don’t overestimate it. You can finish every Reforge and Product School course and still write weak specs with zero hypotheses.

Use this model to structure your development. Real growth starts not with “one more course” — but with changing how you think and work.

When theory becomes practice — and sticks.

How to Build Product Skills (with Tools & Resources)

Let’s break down what you can actually do — and where to learn it.
This is not a checklist. Choose what fits your goals, budget, and context.

📚 Must-Read Books to Build Product Thinking

Books aren’t just inspiration — they offer structure, logic, and mental clarity.
No podcast can match that depth. But good books? They change how you think.

Start here:

• Inspired by Marty Cagan
  The PM bible. Why discovery matters — and how great products are really built.

• The Lean Product Playbook by Dan Olsen
  From idea to launch — with metrics, MVPs, and practical examples.

• The Mom Test by Rob Fitzpatrick
  How not to get lied to in user interviews. The best no-fluff guide to discovery.

• Continuous Discovery Habits by Teresa Torres
  How to make discovery a habit — not a quarterly ritual.

• Escaping the Build Trap by Melissa Perri
  Features ≠ value. This one’s about culture, outcomes, and product strategy.

👉 Bonus list: 14 Must-Read Books for Every Product Manager

Tip: Don’t binge-read.
Highlight insights. Apply them. Re-read next year — and notice how your lens changes.

🎥 YouTube & Podcasts That Actually Make You Smarter

Not all learning happens in courses.
Top PMs share real insights on YouTube and in long-form podcasts.
Pick a few, watch during commutes or lunch breaks — and treat them as micro-trainings.

Here are some worth your time:

• Dan Olsen – Product-market fit, metrics, feedback loops.

• Lenny’s Podcast – Deep convos with PMs from Airbnb, Figma, Stripe.

• Pawel Huryn – Strategy, discovery, roadmaps. Fast, clear, and practical.

• Mind the Product – Talks, trends, and case studies.

• Product School – Free webinars with PMs from Google, Meta, Amazon.

• Productized – Interviews with global experts. Less fluff, more substance.

• Diego Granados – How to land a PM job in Big Tech.

• Dr. Bart Jaworski – Culture and strategy, explained through real cases.

• Strategyzer – Deep dives on customer jobs and value props.

• Atlassian – How they build Jira, Confluence, Trello. Learn from toolmakers.

Tip: Pick 2–3 channels. Watch 1 video per day.
Even one good idea can shape your next retro, roadmap, or user flow.

💻 Best Free Courses for Product Managers

No budget? No problem.
There are great free courses out there — but choose them based on your real needs.

📍Just starting out? These will build your foundation.
📍Already working as a PM? Pick one to sharpen a specific skill.

Top picks:

• Product Analytics Certification — Mixpanel
  Metrics, retention, funnels, A/B tests — all signal, no noise.

• Google Data Analytics — Coursera
  Intro to analytics, SQL, and visual storytelling.

• IBM Product Manager Certificate — Coursera
  A structured intro to the PM craft.

• Design Thinking — Great Learning
  Learn how to build user-centric solutions with case-based thinking.

• Micro-Certifications — Product School
  Quick wins on topics like prioritization, JTBD, and KPIs.

• Product-Led Certification — Pendo
  Learn how to grow through product, not just sales — a must for modern PMs.

📎 Full article: Top 28 Free PM Courses in 2025 (link is coming soon 😉 )

Tip: Don’t collect certificates.
Ask yourself: What skill do I need right now? Then pick one course that helps build it.

Free ≠ useless. It’s all about how you apply what you learn.

💰 Paid Schools That Are Actually Worth It

There’s no shortage of courses on the market — but let’s be honest: most of them are fluff wrapped in shiny packaging.

If you’re going to invest, choose schools that teach you to think and do, not just memorize frameworks.

Here are three I can genuinely recommend:

• Product School
  Great for beginners or people transitioning from adjacent roles (design, analytics, engineering). Lots of foundational content, real-world tasks, and case studies. Especially useful if you need to close basic gaps fast.

• Reforge
  This is next-level stuff. Programs are led by active product leaders from Meta, Uber, Figma. No one explains what a backlog is here — they dive into growth systems, discovery ops, and how PMs can impact the P&L.

• SVPG (Silicon Valley Product Group)
  The team behind Inspired and Empowered. This is the closest thing to a true school of product thinking. Less about frameworks — more about how to think, set bold goals, and lead without fear. Best for those who want to go beyond “just running the process.”

💡 Pro tip:
Don’t take everything just because it’s popular. Figure out your growth gap — and choose the course that helps you practice in that exact area.

Otherwise, you’ll end up a theory collector. Real growth comes not from knowing — but from doing things differently.

🎯 Preparing for PM Interviews?

Don’t wait until you start job hunting.

Interviews are not events — they’re skills.
And like any skill, you should train regularly, not cram.

Write answers. Say them out loud. Record yourself. Ask a friend for feedback.

Start here:

• Interviewing.io — mock interviews with real PMs. The closest simulation to the real thing.

• Exponent — peer practice, video lessons, and coaching sessions.

• PM Exercises — daily prompts for product, feature, and analytics challenges.

• Daily Product Prep — bite-sized daily questions to sharpen your thinking.

• HelloPM — templates, guides, and problem sets for structured prep.

• Product Manager HQ — questions for all interview types + walkthroughs.

• Product School Interview DB — one of the biggest interview databases, filtered by company and question type.

📌 Weekly practice beats “reading one more article.”
Set a goal: one question or mock task per week — with reflection and feedback.
When your real shot comes — you’ll be ready.

🛠 Real-World Practice at Work (The Missing 70%)

This is the most powerful growth lever — and the most underrated one.

We often think “learning” means signing up for a course.
But in reality, it’s doing — inside the mess of real product work — where real skills form.

And the best part?
You don’t need a promotion, a new job, or permission to start.
Here’s what you can do right now — no budget, no title, no perfect timing:

• Write hypotheses for every task — even if no one asks you to.
  Not “add a button,” but:
  “If we simplify the first step of sign-up, we’ll increase CR by 10%.”
  This mindset shifts how you see the backlog — and your role in it.

• Launch a side project using Notion, Glide, n8n, Tally, or Webflow.
  Could be an internal tool or a mini-product for friends.
  Just going from idea to MVP is more valuable than ten tutorials.

• Ask for reviews and feedback — even if it’s not expected.
  Ask your analyst to walk you through a funnel.
  Share your user story draft with a designer.
  Discuss with an engineer how to simplify the build.
  That’s growth.

• Run a user interview — formal or informal.
  Even if you’re not the PM.
  Ask support what users complain about most.
  Run a quick discovery using The Mom Test script.
  Any real user contact = levelling up.

• Build a dashboard if it doesn’t exist. Or improve the current one.
  Goal: Understand what’s happening in the product without asking your analyst.
  Even if it’s just a Google Sheet or Amplitude chart — it matters.

• Do a monthly retro — for yourself.
  What did you learn?
  Which bets flopped?
  What will you try again?
  Without reflection, self-growth is just busywork.

• Write.
  Doesn’t matter if it’s a Notion doc, LinkedIn post, or email to a friend.
  Writing your product thinking makes it sharper.

📌 Here’s a simple rule:
If you regularly stretch beyond your comfort zone — you’re growing.
If you’re only closing Jira tickets — you’re working, not developing.

🚫 Don’t wait for “the right moment.”
Growth doesn’t start when someone gives you a title.
It starts the moment you act like a product manager — even if your job title says otherwise.

🚀 Final Thoughts

It doesn’t matter where you are right now:

– Just starting out and unsure where to begin
– Feeling stuck in PM routine
– Wanting to level up but lacking confidence

What matters is this: don’t wait for perfect conditions.

Pick 1–2 areas. Add practice. Start moving.
Even 15 minutes a day can shift your entire trajectory.

Write notes. Analyze other people’s decisions.
Form hypotheses even when no one asks you to.

You don’t need a new job to get stronger.
Get stronger — and the right job will find you🫵

Keep reading Atomic Product!

A blog that cuts through the BS and speaks product in practical terms.

— Dmytro

Share

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 past posts you might find useful:

• How to Prioritize When Everything Looks Important

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

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

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

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

Subscribe now

Not long ago, a colleague of mine admitted:

“I feel like I’m falling behind. Everything’s changing so fast. I just got used to ChatGPT — and now everyone’s talking about agents, orchestration, RAG, MCP... I can’t even keep up with the terminology.”

And he’s not alone.

A lot of smart, experienced professionals are realizing they can’t keep pace with how fast AI is evolving. The industry isn’t just moving fast — it’s accelerating.

And it’s no longer hype. This is a real shift.

AI agents have arrived. They don’t just help you — they act, make decisions, remember, trigger other services, and... change the very logic of how digital products work.

This article is my attempt to help people like my colleague (and maybe you too) cut through the noise — and stay ahead.

We’ll walk through:
– the steps we’ve already taken in AI (from LLMs to agents — and beyond)
– how agents differ from workflows
– what tools like Zapier, Make.com, and n8n are really bringing to the table
– what’s already working in the wild — and where all of this is heading

This isn’t an “Intro to AI” (that’s coming in a separate piece).
It’s a practical guide to help you stay grounded in a world that’s moving fast.

Let’s dive in.

How It Evolved: From LLMs to Agents (and Beyond)

When ChatGPT first launched, it felt like a smart calculator for words. You type — it replies. Sometimes witty, sometimes dry, but almost always within a “question–answer” format.

But things started to shift.

At some point, you stop asking “Can you summarize this article?” and start saying: “Read this doc, find key insights, look for similar case studies — and turn it into slides.”

And it works. No script. No hand-holding.

That’s when language models started quietly morphing into agents.

If we look back, the path has been surprisingly evolutionary. Here’s how it unfolded — in plain English:

1. Just LLM
   Like a talkative companion. You ask — it answers.
   📌 Example: “Write me a presentation outline” → you get 5 bullet points. That’s it. No docs, no memory, no tools.

2. LLM + Documents
   Now it can read files and summarize content.
   📌 Example: “Summarize this deck” → and it gives you a neat recap, like a student taking notes.

3. LLM + Tools
   It can now use external tools — search, math, APIs.
   📌 Example: “Find the lowest price for this product on Amazon and eBay” → and it actually does it.

4. LLM + Retrieval (RAG)
   Instead of Googling, it looks into your internal docs and vector databases.
   📌 Example: “Find all mentions of client X over the last 3 months” → and you get precise snippets from internal data.

5. Memory kicks in
   It doesn’t forget what you said yesterday.
   📌 Example: “Continue the strategy we discussed last week” → and it actually does, instead of starting from scratch.

6. Agents emerge
   This isn’t just reaction anymore — it’s initiative.
   📌 Example: “Plan my week” → the agent checks your calendar, sets priorities, writes emails, and sends you a summary. No clicks required.

7. Agent orchestration
   One agent is good. A team of agents is better.
   📌 Example: one drafts a blog post, another edits it, a third saves it to Notion. All hands-off.

8. MCP (Model Context Protocol)
   Here’s the real shift. Agents can now “ask” what tools are available and how to use them.
   📌 Example: “What can I do with Airtable?” → and it gets back a list of commands, formats, and limitations. No hardcoding, just live context.

Put simply: you used to build workflows step by step — like old-school PowerPoint animations. Now the agent builds its own path, selects the tools, and figures out how to reach the goal.

Workflow vs Agent: What’s the Difference — and Why It Matters

Let’s start with a scene. You wake up, and someone has already:
– sent your morning newsletter,
– rescheduled useless meetings,
– built your to-do list,
– and even signed your kid up for chess club.

You think: “Is this magic?” Nope. That’s an agent.

And this is where definitions start to matter. Because a lot of what people call “AI agents” today... is actually just automation.

So what’s the real difference between a workflow and an agent?

In plain terms:
A workflow is like an Excel macro — useful, but rigid.
An agent is like a smart assistant — you say “make it good,” and it figures out what that means.

How We Got Here: A Hands-On History

The difference between workflows and agents is easiest to grasp when you look at the tools we’ve used over time.

It started with Zapier — dry, structured, but effective. No visuals, just forms and logic chains. I still remember setting up “new lead → welcome email → CRM entry” and feeling like I’d just built a mini-robot. Even though it was just a sequence of dropdowns.

Then came Make.com — and everything got visual. Arrows, blocks, filters, loops. Suddenly it felt like system design, not just task automation. I remember thinking, “Why didn’t Zapier ever make it this intuitive?”

And then n8n entered the scene with a bold new question: “What if we stopped scripting every step — and just gave the system a goal?” Now you can say, “Plan my week,” and it decides what steps to take, which data to pull, and where to send it. It’s no longer automation. It’s initiative.

To sum it up:
– Zapier is a macro
– Make is a visual editor
– n8n is already becoming a digital assistant

So who’s really ready for the AI agent era?

Let’s take a closer look at how three popular automation platforms — Zapier, Make.com, and n8n — stack up in a world that’s moving from rule-based flows to true AI agents. We’ll walk through key capabilities, from basic GPT integration to memory, RAG, orchestration, and agent behavior.

What does this mean in practice?

• Zapier is great for “If A, then B” logic. You can hook up GPT, but everything else — memory, context, decisions — is manual. It’s a template machine, not a smart system.

• Make.com gives you serious flexibility. You can build complex flows, use OpenAI, parse documents. But in the end, it’s still a workflow: it does what you told it to do, nothing more.

• n8n plays in a different league. It has a built-in AI agent, memory, vector search, JavaScript support, and even something close to an MCP system. It doesn’t just follow orders — it makes its own decisions about what tools to use, and in what sequence. That’s not a macro or a flow. That’s a digital teammate.

What an AI Agent Is Made Of: Architecture, Not Magic

An AI agent isn’t just a “supercharged ChatGPT.”
It’s a modular system — a composition of tools that work together to receive a task, process it, make decisions, and take action.

In practice, you don’t use “one big assistant.” You build a stack, where each component plays its role. Here are the core pieces:

1. The Brain (LLM)

This is the engine that understands text, interprets commands, and generates responses.
Depending on the task, you can use different models:

• ChatGPT – a universal conversationalist, great for general reasoning and content generation.

• Claude – softer tone, excellent at analyzing documents and rewriting.

• Perplexity – great for pulling info from external sources (web search).

• Mistral, LLaMA, GPT-NeoX – open-source options for self-hosted setups.

The LLM is the heart of your agent — but without memory, tools, or contextual awareness, it’s still “just” a smart chatbot.

2. Memory

LLMs operate on a “here and now” basis. Without memory, they forget what happened 10 steps ago.
That’s where memory systems come in:

• Short-term memory (context window) – built into the LLM but limited (a few thousand tokens).

• Vector databases (e.g. Pinecone, Weaviate, Qdrant) – allow you to store and semantically retrieve chunks of information.

• Long-term databases (PostgreSQL with JSON, Supabase, etc.) – good for structured storage of sessions and user data.

Memory makes agents smarter. They can now “remember” previous tasks, conversations, or user preferences — and make better decisions as a result.

3. Tools (APIs, Plugins, External Systems)

LLMs can plan — but they can’t act.
They can’t send an email, create a task, or check today’s exchange rate.
That’s why we add tools — external APIs and plugins:

• Google Calendar API – schedule meetings, fetch availability.

• HubSpot API – create a contact, update a deal.

• Jira / Notion / Slack / GitHub – your internal stack, accessible via API.

You typically connect these tools via middleware like n8n, LangChain agents, Make.com, or your own backend.

To use tools, the agent needs to know what’s available — and that’s where context comes in.

4. Context & MCP (Model Context Protocol)

You can’t expect the agent to magically “know” what tools exist.
You either hardcode them or provide a dynamic description — that’s what MCP does. It describes:

• Available tools

• Input/output formats

• How to call them

• What actions are permitted

For example, instead of hand-coding “Use this POST to Airtable,” you just define a JSON or YAML schema. The agent reads it and uses the tool correctly.

The MCP approach is scalable: Add a new tool → Describe it → The agent knows how to use it.

5. Execution Environment (Orchestration)

Finally, you need something that runs all of this.

• Where does the LLM get its task?

• How does it decide what to do next?

• Who manages the chain of actions?

Options include:

• LangChain / CrewAI / AutoGen – for building complex agent logic

• n8n / Make.com – for visual orchestration with embedded LLMs

• Custom backend (FastAPI, Express.js) – when you need full control

This is how modern AI agents are built — not as one big brain, but as systems that combine memory, reasoning, tools, and coordination.

And now that we’ve broken down how agents work under the hood — let’s take a step forward.

What trends are shaping the future of this technology?
And more importantly — what does that mean for us as product managers, developers, and team leads?

What’s Next? 3 Trends Reshaping the Game

While some teams are just experimenting with agents for small tasks, others are already building workflows, roles, and even full departments around them.
Here are three shifts every future-proof PM should be aware of.

1. Agent Teams: When One Isn’t Enough

It used to be simple: one agent = one task.
But what happens when there are ten tasks — and they depend on each other?

That’s where agent orchestration comes in: one agent doesn’t do everything but delegates to others.

Real-life example:

• One agent retrieves the documents

• Another drafts the content

• A third edits and publishes it

• A fourth monitors performance and triggers follow-up

You used to need a human for this. Now it’s a YAML file.
Frameworks like CrewAI, AutoGen, and LangGraph make this multi-agent setup surprisingly real and accessible.

2. MCP: When Tools Describe Themselves

Even a smart agent needs to know what tools it can use.

Enter Model Context Protocol (MCP) — not a formal standard, but an architectural pattern where tools self-describe what they can do.

Example:
An agent connects to Airtable and gets a list of available actions:
"I support GET, POST, filtering, here are my parameters."

This speeds up development — the agent picks the right tool based on context.
But here's the catch: MCP is a trust contract. If a tool lies or suggests a dangerous command, the agent might execute it blindly.

That’s why AI agent security, governance, and trust frameworks are quickly gaining traction.

3. Specialization: Agents with Character

Generic GPTs are like Swiss Army knives: decent at everything, masters of none.
But in real-world practice, specialized agents win.

Examples:

• A finance agent who understands reporting formats

• A legal agent trained to review contracts

• A marketing agent focused on e-commerce analytics

You don’t train them from scratch.
You just set the role:
"You’re a copywriter. Write like Brand X. Avoid jargon. Target C-levels."
And it works.

These role-based agents are already being embedded in CRMs, analytics tools, and customer support platforms.

AI agents are no longer just a “cool feature.”
They’re becoming a new interface layer, where you don’t click buttons — you set goals.

Final Thought

When ChatGPT first showed up, the title “AI Product Manager” started making noise — but it didn’t mean much.
Everyone was talking about the “art of prompting” and treating it like a new profession.
In reality, ChatGPT already understood most prompts just fine. The so-called “prompt engineers” felt more like hype merchants than real specialists.

That started to shift with the rise of AI workflows.
And now — with agents — we’re in a whole new territory.
You can’t just “ask the model.”
You need to understand how the whole system works — how data flows, where context is stored, how tools connect behind the scenes.

And that changes the PM role, too.

You're no longer just the person saying “let’s add ChatGPT to the product.”
You’re designing how the system behaves: how an agent makes decisions, how it learns, how it interacts with others.
You’re not writing code — but you need to understand the architecture.

The real AI PM isn’t a “prompt whisperer.”
They’re a behavior architect — someone who sets the goals, boundaries, and logic for a new kind of digital entity.

That’s what makes AI Product Management real.
No magic. No hype.
Just a new skill set — a little technical, a lot logical, and 100% hands-on.

Thanks for reading The Atomic Product.

Stay curious and stay sharp

— Dmytro

Share

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

Full list of courses — at a glance:👇

1. Introduction to Generative AI (Google Cloud)

2. Elements of AI

3. Intro to AI (Great Learning)

4. AI for Everyone (Andrew Ng)

5. Google’s AI for Everyday Tasks

6. Responsible AI (Google Cloud)

7. Software Product Management

8. Prompt Engineering for ChatGPT

9. Big Data, AI & Ethics

10. IBM SkillsBuild – AI Track

11. Google Cloud AI/ML Training Hub

12. Microsoft AI for Beginners

13. IBM AI Product Manager Certificate

14. Generative AI for PMs (IBM)

15. Ethics of AI (Helsinki)

16. Generative AI with LLMs

17. Microsoft AI & ML Engineering

18. OpenCV PyTorch Bootcamp

19. RAG Agents with LLMs (NVIDIA)

Share

Ready to go deeper?
I’ve grouped the courses by level — with clear notes on price, time, and certification.👇

🟢 Beginner Level

1. Introduction to Generative AI (Google Cloud)

⏱ ~45 minutes
Price: Free
Certificate: Yes
Why it’s in the list: A fast-paced, hands-on intro to how generative AI works and how to write better prompts. Great if you're just starting and want something short, visual, and easy to digest.
🔗 Link

2. Elements of AI

⏱ 4–8 hours
Price: Free
Certificate: Yes
Why it’s in the list: An accessible, theory-based course for anyone curious about AI — even if you have zero tech background. It gives you the confidence and language to engage with AI topics.
🔗 Link

3. Intro to AI (Great Learning)

⏱ ~1.5 hours
Price: Free
Certificate: Yes
Why it’s in the list: A quick, no-nonsense intro with projects like face detection and sentiment analysis. Good mix of theory and practice in a short time.
🔗 Link

4. AI for Everyone – Andrew Ng

⏱ ~6 hours
Price: Free
Certificate: Yes
Why it’s in the list: A legendary course that explains what AI actually is, how it works, and why it matters — in plain language. Best non-technical starting point for PMs, designers, and execs.
🔗 Link

5. Google’s AI for Everyday Tasks

⏱ ~2 hours
Price: Free
Certificate: Yes
Why it’s in the list: Learn how to boost productivity using AI in Gmail, Docs, Sheets, Meet, and more. Great for marketers and everyday professionals.
🔗 Link

Liked the first few picks?
Join 7K+ readers learning how to stay sharp with AI and product thinking — and let’s keep going.

Subscribe now

6. Responsible AI – Applying Principles (Google Cloud)

⏱ ~1 hour
Price: Free
Certificate: Yes
Why it’s in the list: A thoughtful, quick course about ethics and fairness in AI. Short, practical, and important if you're planning to build with AI.
🔗 Link

7. Software Product Management (UAlberta)

⏱ ~4.5 hours
Price: Free
Certificate: Yes
Why it’s in the list: Not AI-specific, but teaches foundational product skills: agile, roadmaps, backlog grooming. Especially useful if you're building AI products in teams.
🔗 Link

8. Prompt Engineering for ChatGPT (Vanderbilt)

⏱ ~18.5 hours
Price: Free
Certificate: Yes
Why it’s in the list: Teaches prompt engineering as a thinking skill, not just tips and tricks. Useful even if you've used ChatGPT before.
📌 Beginner+, due to its depth and duration.
🔗 Link

9. Big Data, AI & Ethics (UC Davis)

⏱ ~9 hours
Price: Free
Certificate: Yes
Why it’s in the list: Practical cases, ethical frameworks, and real-world dilemmas. Makes you think deeply about consequences.
🔗 Link

10. IBM SkillsBuild – AI Track

⏱ Varies
Price: Free
Certificate: No
Why it’s in the list: A beginner-friendly hub with modular lessons on AI basics, chatbot building, and ethical AI. Especially good for students and educators.
🔗 Link

11. Google Cloud AI/ML Training Hub

⏱ Varies
Price: Free
Certificate: Depends on the course
Why it’s in the list: A curated collection of Google’s latest ML and AI training. Ideal if you want to explore options before diving deep.
🔗 Link

12. Microsoft AI for Beginners

⏱ ~12 weeks (self-paced)
Price: Free
Certificate: Yes
Why it’s in the list: A fully open-source, structured curriculum that covers the full AI development cycle. Feels like a real course, not just a sampler.
📌 Beginner+, best suited for those ready to commit to a deeper, more structured learning path.
🔗 Link

🟡 Intermediate Level

13. IBM AI Product Manager Certificate

⏱ ~3 months
Price: Free
Certificate: Yes
Why it’s in the list: A rare course focused on AI product strategy. Helps PMs lead AI initiatives without needing a technical background.
🔗 Link

14. Generative AI for Product Managers (IBM)

⏱ ~3 months
Price: Free
Certificate: Yes
Why it’s in the list: Teaches how to apply GenAI at every product stage — from discovery to design. Great next step if you're already in product.
🔗 Link

15. Ethics of AI (University of Helsinki)

⏱ 5–10 hours
Price: Free
Certificate: Yes
Why it’s in the list: A grounded, thoughtful look at ethics, fairness, and accountability in AI. Important context for any builder.
🔗 Link

16. Generative AI with LLMs (AWS + DeepLearning.AI)

⏱ ~3–4 hours
Price: Free
Certificate: Yes
Why it’s in the list: Gives you a technical, hands-on look at large language models. Great for understanding the core building blocks.
🔗 Link

17. Microsoft AI & ML Engineering Certificate

⏱ ~6 months
Price: Free
Certificate: Yes
Why it’s in the list: A comprehensive engineering track with hands-on labs. Perfect if you want to go from theory to model deployment.
📌 Intermediate+, requires Python and basic ML knowledge.
🔗 Link

🔴 Advanced Level

18. OpenCV PyTorch Bootcamp

⏱ ~5 hours
Price: Free
Certificate: Yes
Why it’s in the list: A code-first course that dives into neural networks, tensors, and object detection. For builders who learn by doing.
🔗 Link

19. Building RAG Agents with LLMs (NVIDIA DLI)

⏱ ~8 hours
Price: Free
Certificate: Yes
Why it’s in the list: RAG (retrieval-augmented generation) is the cutting edge of AI. This course helps you build real, production-grade agents.
🔗 Link

✨ My personal top 5 (if you're in a rush)

Not sure where to start? These are the 5 I’d recommend to most people — based on clarity, practicality, and long-term value:

1. AI for Everyone – Andrew Ng
   Best for business/product intro → coursera.org/learn/ai-for-everyone

2. Prompt Engineering – Vanderbilt University
   Best for writing better prompts → coursera.org/learn/prompt-engineering

3. Generative AI for Product Managers – IBM
   Best for PMs applying GenAI in product work → coursera.org/specializations/generative-ai-for-product-managers

4. Microsoft AI for Beginners
   Best for full structured learning → microsoft.github.io/AI-For-Beginners

5. OpenCV PyTorch Bootcamp
   Best for getting hands-on with real code → opencv.org/university/free-pytorch-course

   Share

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

• What is Product Management all about?

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

• 5 STEPS to Building a Product Strategy

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

• 14 Must-Read Books for Every Product Manager

Leave a comment

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

• What is Product Management all about?

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

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

• Design Thinking: How to Think Like a Product Manager

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

Subscribe now

You open LinkedIn for the fifth time today.
Another rejection. Another recruiter who never replied.
Another job that looked perfect — and just disappeared.

If you’ve ever tried to break into international product management — or shift into a PM role from another background — you know the feeling.

The doubt. The noise. The pressure to “sell yourself” while trying to stay sane.

A year and a half ago, I was there too.

Despite years of experience, launching a funded startup, and building a strong career in my local market — abroad, none of that mattered.
New rules. New expectations. New speed.
And a lot of moments where I thought: “Maybe I’m not cut out for this.”

I kept going. I adapted. I made mistakes, fixed them, made new ones — and eventually landed a role as Product Manager at a large international company.

This article is not a feel-good story.
It’s not about “believing in yourself” or “manifesting success.”
It’s what actually helped me — practical things I learned, applied, and still use today.

If you’re serious about getting into product management internationally — keep reading.
I wrote this for you.

1. Set up your LinkedIn and CV properly

Let’s start with the foundation — because if this part isn’t right, everything else gets harder.

A few years ago, a solid CV could carry you.
Today? It’s just the starting point.

Your LinkedIn profile is your storefront, your pitch deck, your SEO layer — and often, your first filter.

More than 70% of the roles I applied for came through LinkedIn.
So don’t treat it as a digital version of your resume. It’s something else entirely — and you need to approach it that way.

What are my key takeaways here?:

🔹 CV ≠ LinkedIn

Your CV should be short. 1–2 pages PDF max. Focused on the last 3 roles or the past 10 years.

But LinkedIn - that’s where you show the whole story.
Your career arc. The pivots. The side quests. The glue between roles.

📌 Before publishing it, take a step back and ask:

“Does this show a coherent path — or just a list of jobs?”
“Would someone who doesn’t know me see what I’m good at — and where I’m headed?”

Don’t assume recruiters will Google your past companies. They won’t.
Always add one line explaining what each company does.

🔹 Use the XYZ formula

When describing past roles, don’t list responsibilities. Show impact.

Use this format:

Achieved X, measured by Y, through Z

Example:
Increased retention by 17% (X), measured over 3 months (Y), by revamping the onboarding journey (Z).

This simple structure makes results easier to scan and remember.

🔹 No PM title yet? That’s fine

I didn’t have it either when I started. But product work doesn’t start with the title.
If you’ve done anything related to discovery, prioritization, experimentation, or working with devs — it counts.

Don’t invent things. But don’t hide the product-shaped parts of your experience either.

You can absolutely tell a PM-shaped story — even if you were a BA, designer, marketing lead, or founder.

🔹 Fill out the “About” section

Most people skip it. You shouldn’t.

Keep it short and informative. Include:

• Your domain (e.g., SaaS, marketplaces, fintech)

• Your industry

• Your specialization (e.g., B2B growth, onboarding, retention)

• Your current focus and responsibilities

• A solid list of relevant skills

📌 The more relevant skills you add, the more visible you become in recruiter searches. LinkedIn's algorithm works like a search engine.

🔹 Add a clear one-liner under your name

This helps recruiters understand who you are at a single glance.

For example:

Product Manager • E-commerce | SaaS | PLG | Monetization | Retention

It doesn’t have to be flashy — just accurate and keyword-aware.

🔹 Skip the “Open to work” badge

Yes, really.

It might feel like a helpful signal, but it often backfires.
Some recruiters skip profiles with the badge — assuming the candidate is too junior or too desperate.

Instead:

• Add your email to the About section

• Include a line like “Currently open to new opportunities”

That’s more than enough. And it keeps the tone on your terms.

📎 At the end of this article, I’ll share the exact CV I used during my job hunt — feel free to steal what works.

2. Apply smart

At some point, you realize: sending out 50 applications is easy.
Getting even one meaningful reply — that’s the hard part.

But here’s the thing: you don’t need to become a full-time cover letter writer.
You just need to stop doing it blindly.

Here’s the approach that worked for me — and kept me (mostly) sane.

🔹 Personalize just enough

Everyone says, “Write a personalized cover letter for each role.”

Sure. Sounds noble. But if you’re applying to 20+ jobs a week, that advice will crush your soul.

What I did instead:

• Wrote one solid base letter in my voice

• Tweaked 1–2 sentences depending on the company

• Always updated names and context

That was enough to show I cared — without burning out after the third application.

🔹 Don’t rewrite your CV — just reframe it

I never built a new CV from scratch. But I always adjusted the focus:

• Moved up the most relevant bullets

• Reworded key lines using phrases from the job description

• Highlighted results that matched what the company clearly cared about

You’re not “optimizing for ATS.” You’re making it easy for humans to see the match.

🔹 Start networking before you need a job

When I first got serious about the international market, my LinkedIn felt like a museum — polished, but quiet.

So I started connecting. Not spamming — just reaching out to PMs, recruiters, team leads. People whose work I respected. People I wanted to learn from.

Networking isn’t asking for favors. It’s showing up consistently — with curiosity, not an agenda.

A few weeks in, people started replying.
A few months in, some of them became interviewers. Or referrals.

🔹 Why networking actually boosts visibility

LinkedIn is a visibility game.

The more 1st-degree connections you have, the higher you appear in recruiter searches.
It’s not just about who you know — it’s about who can see you.

Engage with people. Comment on posts. Add context when you connect.
You don’t need to be loud — just present.

🔹 Don’t be afraid to reach out

Frankly, this was a game-changer for me. I used to hesitate: “Why would they reply to me?”

Then I tried. Once. Twice. Dozens of times.
And they did reply. PMs. Recruiters. Founders. People I’d never met.

If you’re polite, specific, and not pushy — your odds are better than you think.

From personal experience, I got replies in about 60–70% of cases.
Not always long answers. But often helpful. Occasionally, transformative.

📌 At the end of the article, I’ll share my exact stats:
How many applications I sent, how many interviews I had, and how many responses came through cold outreach or networking.

3. Prepare for interviews

Here’s something that genuinely surprised me - A lot of people don’t prepare at all.
They show up to the interview, open Zoom, and just… wing it.

They think, “I’ve got experience — I’ll improvise.”
Spoiler: that usually doesn’t go well.

Because interviews — especially in product — aren’t about dumping your resume.
They’re about narrative clarity, strategic thinking, and self-awareness under pressure.

And all of that? It’s trainable.

You wouldn’t launch a product without testing it, right?
So why would you launch yourself without prep?

Here’s what worked for me — not just in theory, but in real interviews:

🔹 Read: Cracking the PM Interview

It’s a classic for a reason. It's an absolutely must-read book and industry standard.

The book breaks down the whole process:

• Interview stages

• Typical PM questions

• How to structure product cases

• What good answers actually sound like

🎯 Don’t just read — practice out loud.
There’s a huge difference between knowing what to say and being able to say it smoothly when the pressure’s on.

🔹 Watch: YouTube mock interviews

My favorite channel: @tryexponent

They publish real mock interviews with PM candidates for companies like Google, Amazon, and Meta.

Watching them helped me:

• Spot common patterns

• Learn how top candidates think

• Understand where people stumble

It’s like watching game replays before a big match.
The more you observe, the sharper your instincts get.

🔹 Practice: Pramp.com

Yes, it’s awkward at first.
Yes, it’s 100% worth it.

Pramp pairs you with other job-seekers for live peer interviews. It’s free for the first few sessions.

I did 5-6 in total. By the third, I noticed something shift —
I stopped panicking. I started flowing. I began to recognize question types and structure my thoughts faster.

It wasn’t magic. It was muscle memory.

🔹 Build your prep doc — and use it

Just a simple Word document or piece of paper.

Mine included:

• A “Tell me about yourself” script

• STAR-format stories from real experience

• Answers to 10+ common PM questions (I always update it when I see more patterns)

• Specific product examples I could reference

• A few notes on each company I applied to

I reviewed it before every call. Sometimes for 3 minutes, sometimes for 10. And here’s why:

Because the real secret to nailing interviews is to stay calm, focused, and well-prepared.

Normal life is already chaotic. Your prep doc becomes your anchor. This is your personal command center.

Believe me, that one habit made a huge difference. I didn’t sound robotic — I sounded ready.

4. What does the hiring process actually look like?

When the interviews started rolling in, I didn’t feel confident. I felt disoriented.

“What do they expect? Where are we in the process? What’s coming next?”

I knew there were resources out there. YouTube is full of mock interviews. Books like Cracking the PM Interview break the whole thing down stage by stage.

But what I really needed back then was clarity — a sense of what actually matters.

In reality, the process almost always boils down to three core stages.
Sure, companies might split them into more steps, shuffle the order, or add their own flavor depending on size and maturity — but the essence stays the same.

This is how it usually worked for me — and what I learned at each point.

🔹 Stage 1 — Intro call with HR

Think of this as the first gate. You don’t need to prove you’re a product genius here — but you do need to come across as sharp, structured, and credible.

They’ll ask you to walk through your experience. They’ll ask why you applied.
Sometimes, they’ll throw in light product questions like:

• “How do you define a successful product?”

• “How do you prioritize features?”

One recruiter even asked me to explain what a product manager actually does —
not because she didn’t know, but to see if I could explain it clearly.

📌 My takeaway: This call isn’t just a “formality.” It’s a screen.
And they’re often talking to dozens of candidates. You need to stand out — fast.

What helped me:

• Having a clear, practiced intro

• Showing curiosity about the product (even from a user’s point of view)

• Researching the company’s latest news, blog posts, or funding updates before the call

🔹 Stage 2 — Deep dive with a PM, CPO, or CTO

This is where it gets real.

You might be asked to walk through a past project. You might get a product case. You might get hit with a take-home assignment and 48-hour deadline.

They’re trying to understand:

• How you approach ambiguity

• How you break down complex problems

• How you think about users, teams, data, and priorities

• And whether you can explain your decisions clearly

Some interviews were more conversational. Others were structured like exams.
One even asked me to critique their own onboarding flow — live.

What helped me:

• Building 3–4 strong product stories (with real metrics, not fluff)

• Speaking in structure, but not sounding rehearsed

• Saying, “Let me take a second to think,” instead of panicking

And the big one:

I stopped trying to impress — and focused on showing how I think (but more on that later).

🔹 Stage 3 — Final call with hiring manager or executive

This one’s different.

Here, they’re not testing your frameworks. They’re trying to feel the fit.

Would they trust you in a high-stakes meeting? Would they enjoy working with you every day? Would you mesh with the team and culture?

Sometimes it’s warm and friendly. Other times it’s quiet and intense.
A few of mine felt more like long coffee chats. Others? Straight-up curveball hour.

I’ve been asked:

• “Tell me about a failure you never talk about.”

• “What’s something you’ve built that no one asked for?”

• “What frustrates you about product management right now?”

📌 The goal here isn’t perfection — it’s presence.
They want to see if there’s energy, honesty, and depth behind the title.

🔹 And yes — “Tell me about yourself” always comes first

Please, don’t underestimate it. This isn’t a warm-up. It’s your moment to shape the rest of the conversation.
In 3–5 minutes, you need to show:

• What drives you

• What connects your experience

• And why you’re a match — now

I iterated mine over and over. Practiced it like a mini-pitch. Not robotic — just fluent.

If you fumble here, the interview never really recovers.
If you nail it, everything else flows.

This is your moment to shine, so make it count!

🧭 Final note — don’t try to be perfect

Sounds weird, but there are no right answers in most PM interviews.
Seriously.

Interviewers aren’t looking for rehearsed scripts. They’re trying to understand how you think — how you weigh trade-offs, navigate ambiguity, make decisions under pressure. Just like in real product work.

And for that, showing your thought process is way more powerful than delivering the “perfect” answer.

So here’s my advice:

• Pause when you need to

• Ask for clarification if needed

• And most of all: be yourself.

If you get hired pretending to be someone else, you’ll either burn out — or have to maintain a role that doesn’t fit you. Neither ends well.

The best interviews I had felt like real conversations — because I wasn’t trying to pass a test. I was trying to find the right fit.

5. Run a retro after every interview

Here’s something no one told me when I started:

The best way to get better at interviews… is to treat them like product sprints.

You don’t need to guess what went wrong. You can learn what worked — and what didn’t — if you actually take the time to look back.

So after every interview, I did a quick retro. Nothing fancy. Just 10–15 minutes with a blank doc and a few key questions.

What I wrote down:

• What questions did they ask?

• How did I answer them?

• How did they react?

• Where did I feel strong?

• Where did I hesitate or ramble?

• Did I prepare enough — or miss something obvious?

Sometimes I wrote bullet points. Sometimes just messy thoughts.
But after a few rounds, patterns started to emerge — and that changed everything.

One time, I realized I always fumbled when asked about cross-functional collaboration.
Another time, I noticed I gave the same example three interviews in a row — and it was starting to feel thin.

By reviewing each round, I stopped repeating mistakes.
I got faster at spotting weak points.
And my answers started feeling more grounded — less like guesses, more like practiced judgment.

Not everything is in your control — but reflection is

You can’t control if a company ghosts you.
You can’t control if they already had an internal hire in mind.

But you can control how you show up next time.
And that starts with seeing each interview not as a pass/fail moment — but as a step in a bigger loop.

PMs run retros after every sprint.
This is the same mindset — just applied to yourself.

6. Avoid common mistakes

After enough interviews — both good and bad — I started noticing a strange pattern.

Some people with less experience got through.
Others, with great backgrounds, dropped out early.

Why?

Often, it came down to simple, fixable things.
So before we move on, here’s a quick list of the most common mistakes I saw (and made).

🔻 1. Not reading the job description carefully

It sounds basic. But I’ve seen candidates jump into interviews without even knowing which product line the role was for.

One time I asked a recruiter, “So… what’s the product exactly?”
She blinked and said, “It’s in the job post. Line three.”

Lesson learned.

🔻 2. Talking about salary too early

Bringing up compensation too soon can shift the tone.
Unless they ask — don’t make it the headline.

When they do ask (usually at the end of stage 1), it helps to:

• Research via Glassdoor, Levels.fyi, or local benchmarks

• Give a reasonable range, not a fixed number

• Be honest about flexibility, but don’t undersell yourself

This isn’t a trap. But it is a test of how you handle negotiation and uncertainty.

🔻 3. Freezing on curveball questions

Every PM interview will have one unexpected moment.

Something like:

“How would you improve our onboarding flow — assuming you had no dev resources?”

Or:

“What would you do if your team completely disagreed with your roadmap?”

There’s no perfect answer. But panicking and blurting out “I don’t know” — that’s where most people lose the thread.

📌 Better approach:
Take a breath. Say: “Let me think this through.”
Then walk them through your reasoning — even if you’re unsure.
Interviewers don’t expect certainty. They want to see how you explore ambiguity.

🔻 4. No prep, no post-mortem

We already covered this in the last section, but it’s worth repeating:

Walking into an interview without prep is like launching a product without a prototype.
And skipping the retro after? That’s just leaving insight on the table.

🔻 5. Trying to be someone else

And let me also repeat this one. This one’s subtle and dangerous.

It’s tempting to perform. To sound like the “perfect PM.”
But here’s the truth: you’re not just interviewing for them. You’re testing the match for yourself.

If you show up as someone else and get the job, guess what?
You now have to be that version of you. Every day.

That’s exhausting. And unnecessary.

The best interviews I had were the ones where I was clear, honest, and relaxed —
not flawless, just real.

7. My path, in numbers (no sugarcoating)

This whole journey took 58 weeks — just over a year.

In that time, I:

• Sent 599 applications (mostly via LinkedIn)

• Got 233 responses

• Took part in 38 interviews

• Completed 9 take-home tasks

• Got 3 offers — 2 full-time, 1 part-time

• And finally chose one — the right one

That’s it. No overnight success story.
No lucky break. No, “I just knew a guy.”

It was a strategy. Persistence. Growth.
And more than once — it was just about showing up again the next day.

✅ CV I used during my job hunt → [link]

Before we wrap — one last thing

Before you send out your 200th application, take a moment and ask yourself:

“Do I actually meet the core requirements for this PM role?”
And if not — what am I doing about it?

It’s okay to admit gaps. Everyone has them.

What matters is what you do next.

📌 If you’re light on product analytics or Agile — study it.
📌 If English isn’t your first language — get a tutor. I used Preply and italki.
📌 If you’ve never touched a roadmap — start one. Even as a side project.

And when it gets frustrating — because it will — remember this:

Think of yourself as a product.
You’re iterating toward product-market fit.

Every application is top-of-funnel.
Every interview is a conversion point.
Every rejection is feedback — not a verdict.

Your job search is a product.
Test. Analyze. Improve.

📚 And while you’re doing that — keep sharpening your skills.

Not just tools or certifications, but actual product thinking.
Read books. Watch breakdowns. Join communities. Build tiny things.
Talk to users, even if they’re imaginary.
Think in hypotheses, not assumptions.

This mindset doesn’t just get you hired — it makes you better once you are.

And above all — don’t quit too soon.

Even when it feels like nothing’s working, momentum is quietly building.
Every action counts. Every attempt matters.

You’re not lost. You’re in progress.
Stay with it.

And keep reading The Atomic Product.

— Dmytro

Share

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

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

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

• Design Thinking: How to Think Like a Product Manager

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

Subscribe now

Every week, someone drops a hot new AI tool on Product Hunt. LinkedIn is flooded with “10x productivity hacks.” Your X (Twitter) feed is a carousel of shiny screenshots. It feels like everyone is building faster, smarter, and shipping sooner — all thanks to AI.

But here’s the reality: most people aren’t using these tools in a meaningful way. They either tinker endlessly without focus or chase every new viral prompt. That’s not product thinking — that’s just digital noise.

This article is here to cut through the noise.

If you're a PM, a startup founder, a no-code builder, or a designer tired of hearing that “AI will change everything” without seeing how — you're in the right place.

Instead of hype, you’ll get:

• ✅ A practical breakdown of how AI actually helps at each MVP stage — from idea validation to user research, design, building, and iteration.

• ✅ 40+ hand-picked AI tools you can really use — explained clearly and matched to the right moment.

• ✅ Honest notes on AI’s limitations — when to leverage it, and when to stick to old-school methods.

• ✅ Ready-to-use tables for comparing tools and building your own lightweight MVP stack.

Because AI won’t magically save your product.
But if you know how to use it — it will save you time, budget, and momentum.

How AI Accelerates MVP Development (Without the Hype)

Let’s be honest — trying to "understand AI" today can feel like free-falling through a jargon black hole.

LLMs, agents, no-code workflows, generative UIs, RAG, orchestration layers... 🤯
Good news: you don’t need a PhD in AI to build a smart MVP.

You need one simple shift in thinking: Stop seeing AI as a set of buzzwords.
Start seeing it as a tool to speed up your MVP development — and make smarter bets with fewer resources.

• ✅ Efficiency and speed — Build prototypes, apps, and experiments faster than traditional teams.

• ✅ Cost-effectiveness — Launch and test ideas without spending thousands on full dev teams or agencies.

• ✅ User feedback integration — Collect, cluster, and act on user feedback faster, without drowning in spreadsheets.

• ✅ Iterative improvements — Test, tweak, and evolve your product continuously — not once every few months.

• ✅ Innovation acceleration — Discover and build new features or ideas you might not have imagined without AI.

And if you still want to dive into what all those AI terms mean — LLMs, RAGs, agents, orchestration layers — don’t worry.
👉 I’m breaking them down clearly (and without the jargon overdose) in the next article: [WTF is the Difference Between AI, ML, LLM and Generative AI?] (link coming soon 😉).

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