DEV Community: Ege Pakten

AWS Basics But Needs to Be Known Before You Start Your Certification

Ege Pakten — Fri, 27 Mar 2026 16:30:23 +0000

You don't need to memorize 200 services to start your AWS journey. But you do need to understand the foundations. Here's everything I wish someone had explained to me before I started studying for my AWS certification.

1. What Even Is Cloud Computing?

Let's start from the very beginning. Cloud computing sounds fancy, but the core idea is simple: there's a physical server somewhere, and you're renting it over the internet.

Instead of buying your own hardware, setting up a server room, and hiring people to maintain it — you use someone else's infrastructure (like AWS) and pay only for what you use.

Here's the official NIST definition:

"A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of **configurable computing resources* that can be rapidly provisioned and released with minimal management effort or service provider interaction."*

Let's break that down into human language:

On-demand → You get resources whenever you want them
Shared pool → Multiple customers share the same physical infrastructure
Configurable → You choose how much CPU, RAM, storage you need
Rapidly provisioned and released → Spin up a server in minutes, shut it down when you're done
Minimal management effort → No need to physically touch any hardware

2. What's Actually Behind the "Cloud"?

Behind the cloud, there are real, physical server racks sitting in massive data centers around the world. AWS has these data centers spread across the globe, and the infrastructure is organized in a clear hierarchy:

Region

A large geographic area (e.g., eu-west-1 for Ireland, us-east-1 for N. Virginia). You choose a region based on where your users are, compliance requirements, or pricing.

Availability Zone (AZ)

Each Region contains multiple AZs (e.g., eu-west-1a, eu-west-1b, eu-west-1c). An AZ is one or more data centers with independent power, networking, and connectivity. Multiple AZs exist for redundancy — if one goes down, the others keep running.

Edge Locations / Points of Presence (PoP)

These are smaller, lightweight locations spread even more widely than Regions. They're used primarily for caching content closer to end users.

3. Edge Networks and CDN — Speed Matters

Imagine your origin server is in the US, but a user in Southeast Asia wants to load your website. Without any optimization, every single request travels across the Pacific Ocean and back. That's slow.

This is where Edge Networks and CDN (Content Delivery Network) come in.

How it works:

Your original content lives on the Origin Server (e.g., in us-east-1)
AWS caches copies of your static content (images, CSS, JS, videos) at PoP / Edge Locations around the world
When a user in Singapore requests your site, they get the cached version from the nearest PoP — not from the US
Result: dramatically lower latency

CDN vs Edge Network — are they the same thing?

Not exactly. The Edge Network is the infrastructure — the distributed network of servers worldwide. CDN is the most well-known use case of that infrastructure. In practice, people use the terms interchangeably, and that's mostly fine.

AWS's CDN service is called CloudFront, and it leverages these Edge Locations.

4. Virtualization and the Hypervisor

Here's where it gets interesting. When you launch an EC2 instance, you're not getting a dedicated physical server. Here's what's actually happening:

Host Computer → The physical AWS server rack in a data center
Host OS → The operating system running on that physical machine
Hypervisor → Software that sits on top of the Host OS and splits the physical machine into multiple virtual machines
Your EC2 Instance → One of those virtual machines

So if a physical server has 64 CPUs and 256 GB RAM, the hypervisor might split it into four isolated instances of 16 CPUs / 64 GB RAM each. Different customers can be using the same physical hardware without ever knowing about each other — completely isolated.

AWS built their own hypervisor called Nitro, which operates at the hardware level for minimal performance overhead.

Key takeaway: EC2 instances are virtual slices of physical servers, managed by a hypervisor. Multiple instances from different customers can live on the same physical machine, fully isolated from each other.

5. The Shared Responsibility Model — Who's Responsible for What?

This is probably the most important concept for your certification exam. AWS and the customer share security responsibilities, but the line between them is very clear.

Security OF the Cloud → AWS's Job

AWS is responsible for protecting the infrastructure that runs all the services:

Physical security — data center access, cameras, biometric entry
Hardware — servers, storage, networking equipment
Software — compute, storage, database, networking services
Global infrastructure — Regions, Availability Zones, Edge Locations
Host OS & Hypervisor — you can't even access these

Security IN the Cloud → Your Job

You are responsible for everything you put in and configure on the cloud:

Customer data — whatever you upload, store, or process
Platform, applications & IAM — who has access to what, roles, permissions, secret keys
OS & firewall configuration — if you launched an EC2 with Ubuntu, patching it is on you
Encryption — client-side, server-side, in-transit, at-rest decisions
Network traffic protection — security groups, NACLs, VPN configurations

The Three Control Categories

Category	Who?	Examples
Inherited	AWS only	Physical & environmental security, host OS, physical servers
Shared	Both	Patch management, configuration management, awareness & training
Customer-Specific	Customer only	Guest OS, custom applications, data encryption strategies

Quick Quiz — Test Yourself

Question	Answer
Patching your EC2 instance's operating system?	You
Guest OS security patches?	You
Running the host OS and virtualization layer?	AWS
Managing IAM user access and secret keys?	You
Maintaining the server under your Lambda functions?	AWS
Physical security of data centers?	AWS
Encryption-at-rest strategy for your RDS database?	You

Simple rule of thumb: If you can configure it in the AWS Console or CLI → it's your responsibility. If you can't even touch it → it's AWS's responsibility. If both sides need to do their part → it's shared.

Think of it like renting an apartment: AWS gives you a secure building (locked doors, fire alarms, security guards). But whether you lock your own door, put your valuables in a safe, or leave your windows open — that's entirely on you.

6. AWS Support Plans — Developer vs Business

When you create an AWS account, you'll need to choose a support plan. Here's the practical difference between the two most common ones:

Feature	Developer (~$29/mo)	Business (~$100/mo or % of usage)
Who can open tickets	1 person (primary contact)	Unlimited team members
Response time (critical)	12 hours	1 hour
Support channels	Email only	Email + Phone + Chat
Trusted Advisor	Limited checks	Full access
Third-party software support	No	Yes

Which one should you pick?

Developer → Great for learning, experimenting, and building prototypes. Start here if you're just getting started.
Business → Essential when you're running production workloads with real users. The 1-hour critical response time alone is worth it when something goes down.

Good news: You can start with Developer and upgrade to Business anytime from the AWS Console (Support Center > Change Plan). Billing is prorated, so you only pay for what you use. You can also downgrade later if needed.

Wrapping Up

Before diving into specific services like S3, Lambda, or DynamoDB, make sure these foundational concepts are solid:

Cloud = renting virtual resources from physical infrastructure over the internet
Regions → AZs → Edge Locations form the backbone of AWS's global presence
CDN / Edge Networks cache content close to users for speed
Hypervisors split physical servers into isolated virtual machines (EC2 instances)
Shared Responsibility Model — know what's yours vs what's AWS's (this will be on the exam)
Support Plans can be upgraded/downgraded as your needs evolve

These aren't glamorous topics, but they're the bedrock everything else is built on. Nail these, and the rest of your certification journey will make a lot more sense.

Happy cloud learning! If you found this helpful, drop a reaction or follow for more AWS certification notes.

What I Learned from "The Mom Test" - Chapter 8: Running the Process

Ege Pakten — Wed, 11 Mar 2026 09:59:08 +0000

A developer's guide to turning customer conversations from a solo guessing game into a team-wide learning machine

You've learned the skills: asking good questions, avoiding compliments, pushing for commitments, finding conversations, and choosing your customers. But skills alone aren't enough. If you don't have a process to capture and share what you learn, it all falls apart.

Chapter 8 is the final chapter of The Mom Test, and it ties everything together. It's about the nuts and bolts of actually running customer conversations as a repeatable, team-wide process — not just something the "business person" does while everyone else codes.

Outline

In this post, I'll break down Chapter 8 into the following sections:

Prepping for the Conversation — Why going in with a clear list of your riskiest assumptions saves you from aimless chats.
Who Should Show Up — Why the whole founding team needs to hear customer conversations firsthand, and what goes wrong when they don't.
How to Write It Down — The note-taking system that actually works: exact quotes, emotions, and constraints — not just "they liked it."
Reviewing with Your Team — How to turn a pile of messy notes into clear decisions, and why reviewing together prevents the "telephone game" problem.
Talking to Customers Is a Team Sport — Why delegating all customer conversations to one person is a recipe for disaster.
The Process — Fitzpatrick's lightweight, practical process for weaving customer learning into your weekly rhythm.

Prepping for the Conversation

Before you walk into a customer conversation, you need to know what you're trying to learn. This sounds obvious, but most people skip it. They just show up and "see what happens."

Fitzpatrick recommends sitting down with your team before any batch of conversations and asking: "What are the three biggest questions we need to answer right now?"

These should be your scariest, riskiest assumptions — the ones that could sink the whole business if you're wrong. Maybe it's "Do people actually switch tools for this?" or "Will managers pay for something their team uses?" or "Is this problem painful enough to justify the effort?"

If you go in without a clear list, you'll default to comfortable topics. You'll talk about features you're excited about instead of risks you're afraid of. And you'll come out feeling good but learning nothing.

You don't need a rigid script — that kills the natural flow of conversation. But you need a cheat sheet of the big questions. Glance at it before the meeting. Make sure you hit the important stuff before the conversation ends.

Rule of Thumb: If you don't know what you're trying to learn, you're not ready for the conversation. Prep your three big questions before every batch of meetings.

Who Should Show Up

This one surprised me. Fitzpatrick is adamant: the whole founding team should be in customer meetings. Not just the CEO. Not just the "business person." Everyone.

Why? Because customer learning that passes through a middleman always gets distorted. It's like a game of telephone. The person who was in the meeting says "they seemed really excited about feature X" and everyone else nods along. But were they actually excited? Or were they just being polite? Only the person in the room can judge the body language, the tone, the hesitations.

When the whole team hears the same thing at the same time, two things happen:

You avoid arguments about what the customer "really meant." Everyone heard it themselves.
The technical co-founders hear constraints and problems directly, which means they can often come up with better solutions than what the customer (or the business co-founder) would have suggested.

Obviously, this doesn't scale forever. You can't have five people show up to every coffee chat. But in the early days — when every conversation shapes your product direction — it's worth the investment.

If you absolutely can't have everyone attend, rotate who goes. But NEVER let one person become the sole keeper of customer knowledge. That's a single point of failure, and when they're wrong about something, the whole team is wrong.

Rule of Thumb: Everyone on the team who is making big product or design decisions should be sitting in on at least some customer conversations. Don't let secondhand summaries replace firsthand experience.

How to Write It Down

Taking notes during customer conversations is critical, but most people do it wrong. They write down summaries, interpretations, and vague impressions: "She seemed interested in the analytics dashboard" or "He thought the pricing was fair."

The problem? Those aren't facts — they're your interpretations. And interpretations are where bias creeps in.

Fitzpatrick recommends a specific note-taking format. Write down:

Exact quotes — The actual words they used. Not your paraphrase. Not your interpretation. Their exact words. Put them in quotation marks so you can distinguish them from your own notes later.
Emotions — Did they light up when talking about a particular problem? Did they seem bored? Angry? Dismissive? Emotions reveal what matters to people in a way that words sometimes don't.
Constraints — Hard facts about their situation. "Their team has 12 people." "They spend $2,000/month on the current tool." "They've been looking for a solution for 6 months." These are the concrete details that help you make decisions later.

What NOT to write down: your own ideas, feature requests you thought of during the conversation, or your emotional reactions. Those go in a separate section. Keep the raw customer data clean and uncontaminated.

Fitzpatrick also suggests using shorthand symbols to quickly flag important moments. For instance, use a smiley face or an exclamation mark for strong emotions, a dollar sign for anything related to money or budget, and a star for particularly important quotes.

After the meeting, spend five minutes cleaning up your notes while the conversation is still fresh. Fill in the gaps, clarify the shorthand, and highlight the most important bits. If you wait until the next day, you'll have forgotten half the nuance.

Rule of Thumb: Write down exact quotes, emotions, and constraints. Keep your interpretations separate from the raw data. Spend five minutes cleaning up notes immediately after every conversation.

Reviewing with Your Team

Raw notes from individual conversations aren't very useful on their own. The magic happens when you review them together as a team.

Fitzpatrick recommends a regular review session — ideally weekly — where the team sits down and goes through the recent conversation notes together. The goal isn't just to share what you heard. It's to look for patterns, update your beliefs, and decide what to do next.

Here's how a good review works:

Share the raw notes. Read out the exact quotes, the emotions, the constraints. Don't editorialize. Let the data speak for itself first.
Look for patterns. Are multiple people saying the same thing? Are you hearing the same pain point from different customers? That's a strong signal. Are you hearing wildly different things? That might mean your segment is too broad (go back to Chapter 7).
Update your assumptions. Remember those three big questions you prepped? Based on what you've heard, which ones have been answered? Which ones are still open? What new questions have emerged?
Decide on next steps. What conversations do you need to have next? Do you need to talk to more of the same type of customer, or a different segment? Do you have enough signal to start building something?

The key is that this review should be a conversation, not a presentation. If one person just summarises what they heard and everyone else nods, you've missed the point. Everyone should engage with the raw data and form their own conclusions.

This process also catches mistakes. If one team member misinterpreted a conversation, the others can catch it during the review. If someone got excited about a compliment disguised as a commitment (Chapter 5 flashback!), the team can flag it.

Rule of Thumb: Don't let customer learnings sit in one person's notebook. Review notes together as a team regularly, look for patterns, and update your beliefs based on the evidence.

Talking to Customers Is a Team Sport

Fitzpatrick keeps hammering this point home because it's so often ignored: customer learning is not one person's job.

In many startups, there's a division of labour: the "business person" talks to customers, and the "technical person" builds the product. This feels efficient, but it's actually a disaster.

Here's why: the technical co-founder ends up building based on secondhand information. They hear "customers want feature X" and build it. But if they had been in the room, they might have heard the underlying problem behind the request and come up with a completely different (and better) solution.

Engineers tend to think of customer conversations as someone else's responsibility — something that takes them away from "real work." But talking to customers IS real work. It's arguably the most important work in the early stages of a startup, because it determines whether you're building the right thing.

Fitzpatrick even goes so far as to say: if someone on your team refuses to participate in customer conversations, that's a serious red flag. It means they're comfortable building in the dark, which is a recipe for building something nobody wants.

This doesn't mean every engineer needs to lead conversations. Some people are naturally better at it than others. But everyone should at least be present for some conversations, take turns leading when possible, and participate actively in the team review sessions.

Rule of Thumb: Customer conversations are everyone's responsibility. If only one person on the team talks to customers, you have a bottleneck that will eventually break.

The Process

So how does all of this come together in practice? Fitzpatrick outlines a lightweight process that you can adapt to your situation. It's not complicated, but it requires discipline:

Before a Batch of Conversations:

Sit down as a team and identify your three biggest learning goals (your scariest assumptions)
Decide who you're going to talk to (your customer segment from Chapter 7)
Decide where to find them (your "who-where" pair)

During Each Conversation:

One person leads the conversation, asking questions and steering the discussion
Another person takes notes — exact quotes, emotions, constraints
Keep it casual (Chapter 4) and follow the Mom Test rules (Chapters 1-3)
Push for commitment at the end (Chapter 5)

Immediately After:

Spend five minutes reviewing and cleaning up notes together
Flag anything surprising or particularly important
Note any follow-up actions or commitments you made

Weekly (or After Every Batch):

Team review session — go through notes together
Look for patterns across conversations
Update your assumptions and beliefs
Decide: do you need more conversations, or is it time to build?
Identify your next three big questions for the next batch

The beauty of this process is that it's fast. Each cycle takes about a week. In a single week, you can have 5-10 conversations, review them as a team, and make a clear decision about what to do next. Compare that to spending months building something in isolation and then discovering nobody wants it.

Fitzpatrick emphasises that the process should be lightweight. If it feels like bureaucracy, you've over-complicated it. The notes should be quick. The reviews should be short. The goal is to learn fast and stay nimble.

Rule of Thumb: Keep the process simple. Prep → Conversations → Notes → Review → Decide → Repeat. If you're spending more time on process than on actual conversations, something's wrong.

Key Takeaways from Chapter 8

Prep before every batch of conversations. Identify your three scariest assumptions and make sure you address them. Don't just "wing it."
The whole team should hear customer conversations. Secondhand summaries always lose nuance. Everyone who makes product decisions needs firsthand exposure.
Take notes the right way. Exact quotes, emotions, and constraints — not interpretations. Keep the raw data separate from your opinions.
Review notes as a team. Look for patterns, catch misinterpretations, update your beliefs, and decide on next steps together.
Customer learning is everyone's job. Don't delegate it to one person. Engineers, designers, and founders all benefit from being in the room.
Keep the process lightweight. Prep → Talk → Note → Review → Decide → Repeat. One cycle per week. Don't let process become bureaucracy.
Learning is the goal, not meetings. Every conversation should move you closer to a clear picture of what to build and who to build it for.

Previously: Chapter 7 - Choosing Your Customers

That's a wrap on The Mom Test! If you've been following along, I hope these posts have been as useful to you as writing them was for me. Now go talk to your customers — the right way.

What I Learned from "The Mom Test" - Chapter 7: Choosing Your Customers

Ege Pakten — Mon, 09 Mar 2026 10:58:49 +0000

A developer's guide to why talking to "everyone" is the fastest way to learn nothing

There's a saying in the startup world: startups don't starve, they drown. You never have too few options, too few leads, or too few ideas — you have too many. You get overwhelmed. You do a little bit of everything and make progress on nothing.

Chapter 7 is about the antidote: customer segmentation. Choosing who to focus on so you can actually learn something useful instead of drowning in mixed signals.

Outline

In this post, I'll break down Chapter 7 into the following sections:

Segmentation: Why Starting Broad Kills You — How Google, Paypal, and Evernote all started narrow, and why you should too.
Babies or Body Builders? — A real-world example of what happens when you try to serve everyone with one product.
Big Brands or Mom & Pop? — Fitzpatrick's own painful lesson of choosing a customer segment that was way too broad.
But What Does It Mean? — Why "students" or "advertisers" aren't real customer segments, and what happens when you treat them like they are.
Customer Slicing — A practical step-by-step technique for narrowing down your segment until you know exactly who to talk to and where to find them.
Talking to the Wrong People — The three traps that lead you to waste time on the wrong conversations.

Segmentation: Why Starting Broad Kills You

When we look at the big tech successes, they seem to serve the whole world. Google lets anyone find anything. Paypal helps anyone send money anywhere. Evernote backs up everyone's notes.

But here's the thing — they didn't start there.

In its early days, Google helped PhD students find obscure bits of code. Paypal helped collectors buy and sell Pez dispensers and Beanie Babies more efficiently. Evernote helped moms save and share recipes.

Every one of them started with a tiny, specific group. They nailed it for that group, then expanded. If you try to start with "everyone" as your customer, three things go wrong:

You get overwhelmed by options and don't know where to start
You aren't moving forward but can't prove yourself wrong either
You receive mixed feedback and can't make sense of it

The feedback from a Fortune 500 CFO and a freelance designer will be wildly different — even if they're both technically "potential customers." If you're talking to both at once, their conflicting needs cancel each other out and you end up paralysed.

Rule of Thumb: If you aren't finding consistent problems and goals, you don't have a specific enough customer segment.

Babies or Body Builders?

Fitzpatrick shares a brilliant example. A woman had developed a powdered condiment — sweet like cinnamon brown sugar but packed with the nutrition of a multivitamin. An all-natural superfood you could survive on indefinitely.

She said it had countless uses: moms could sprinkle it on breakfast to trick their kids into being healthy, restaurants could leave it on tables as a sugar alternative, bodybuilders could mix it into protein shakes.

Sounds like a huge market, right? Wrong. She was running in circles. The bodybuilders wanted one thing, the restaurants wanted another, and the moms needed a third. Making one group happy always disappointed the others. She didn't know how to start. Even simple decisions — like what colour to use for the label — were impossible to answer because every group had different preferences.

The fix? She had to choose. She focused on moms with young kids who were already shopping at health food stores. Now she knew who to talk to, where to find them, and what they cared about.

Her next move was clever: she went to small, independent health food stores and asked them to place a few bottles of her condiment beside the breakfast foods. This was a great commitment to ask for — it gave her real shelf space and helped distinguish between stores that were just being polite and ones that were genuinely interested. She'd return in a week to check if the product sold and to talk to store owners about their experience.

Choosing a specific segment felt like losing all the other options. But it was the only way to actually make progress. As Fitzpatrick puts it: before we can serve everyone, we have to serve someone.

Big Brands or Mom & Pop?

Fitzpatrick shares his own painful lesson here. In one of his startups, he was thrilled that his customer segment was "advertisers." Everyone advertises somehow, so the market was practically infinite!

He talked to mom-and-pop shops, e-tailers, big brands, creative agencies, SMEs, music labels — anyone who spent money on advertising. And the result? Complete chaos.

Everything they tried sort of worked. Everything was somewhat promising. Some people were talking about paying $10,000/month while others scoffed at $10. Every new feature was moderately popular. But if they tried to cut any feature, someone would scream because it was their favourite part.

The fundamental problem: they couldn't prove themselves right or wrong. They were paying attention to so many customer types that there was pretty much always someone who liked a new idea. But making a so-so product for a bunch of audiences isn't the same as making an incredible product for one.

Eventually they noticed unusually strong signals from creative agencies who wanted to be edgy. They ignored everyone else, cut a bunch of features, and were finally able to get a clear picture of what was working and what wasn't.

But What Does It Mean?

This section is one of the most eye-opening in the entire book. Fitzpatrick describes two founders who were doing everything right — asking good Mom Test questions, pushing for commitments, using every sales meeting as a learning opportunity. And yet they were still completely confused.

After 20 conversations, they had 20 different must-have features and 20 separate must-solve problems. The more people they talked to, the more confused they got. What was going on?

Their customer segment was too broad, but in a sneaky way. They were building something for "students." Sounds specific enough, right? But think about what "students" actually means:

A PhD student at a research university
An ambitious teenager at a prep school
A homeschooling parent who wants to use it with her kid
A child in a rural Indian village self-educating through a shared computer
A student in Africa running the app off a shaky cellphone connection

All are technically "students." But they have completely different needs, workflows, devices, budgets, and goals. These founders weren't having 20 conversations with their customers — they were having one conversation each with 20 different types of customers. That's why the feedback was so inconsistent.

The same thing happens with segments like "small businesses," "developers," or "sales organisations." They sound specific but contain enormous variation underneath.

Customer Slicing

So how do you narrow down a broad segment into something useful? Fitzpatrick introduces a technique called Customer Slicing. It's simple but powerful.

Start with a broad segment and keep slicing it into smaller and smaller sub-sets by asking these questions:

Within this group, which type of person would want it most?
Would everyone in this group buy/use it, or only some?
Why does that sub-set want it? What is their specific problem?
Does everyone in the group have that motivation, or only some?
What additional motivations are there?
Which other types of people have these motivations?

You repeat this process until you end up with a segment that is specific enough to find and reach in the real world.

Here's Fitzpatrick's example: Say you're building a high-end fitness gadget for busy professionals. Your first instinct might be: "finance professionals, age 25-35, living in a major city." That sounds specific, but it's actually useless — it doesn't help you make product decisions and it doesn't help you find them.

Slice further: finance professionals in London who are currently training for a marathon. Better! Now slice again: the sub-sub-subset who go to the gym during their lunch hour. Now you know exactly where to find them — at a gym in London's financial district during lunch time. You can have all the customer conversations you want for the price of a gym membership.

The key test: if there isn't a clear physical or digital location where you can find your customer segment, it's probably still too broad. Go back and slice it into finer pieces.

Once you have a bunch of "who-where" pairs, decide who to start with based on three criteria:

Profitable or big — Is this segment worth pursuing financially?
Easy to reach — Can you actually find and talk to these people?
Personally rewarding — Do you enjoy working with this group?

Don't overthink it. Spend a few minutes to reach a concrete initial segment, find a few of them, and start learning. You can always broaden your segment later once you've nailed it for the first group.

Fitzpatrick adds a personal note that I really appreciate: the third factor — personally rewarding — matters more than people think. This stuff is hard work, and it can become a real grind if you're cynical about the people or the industry you're serving. Choose customers you admire and enjoy being around.

Rule of Thumb: Good customer segments are a who-where pair. If you don't know where to go to find your customers, keep slicing your segment into smaller pieces until you do.

Talking to the Wrong People

Even with good segmentation, you can still end up talking to the wrong people. Fitzpatrick identifies three ways this happens:

1. Your segment is too broad and you're talking to everyone

We've covered this extensively. If your feedback is all over the place, you're probably mixing multiple customer types together. The fix: slice your segment narrower.

2. You have multiple customer segments and missed some of them

Sometimes it's obvious — if you're a two-sided marketplace (like Airbnb), you clearly have hosts and guests as separate segments. But sometimes it's sneakier. If you're building an app for kids, you need to understand both the kids AND their parents. If you're building for public schools, you need the teachers, the students, the administration, and potentially even the parent-teacher association and tax payers.

You'll also need to worry about important partners — whether for manufacturing, distribution, or promotion. If your business relies on them, you need to understand their goals and constraints just as well as your customers'.

3. You're selling to businesses with complicated buying processes and have overlooked some stakeholders

This is the B2B trap. Don't fall into only talking to the most senior or impressive people you can find. You want to talk to people who are representative of your actual customers, not the ones who sound impressive on your status report.

Fitzpatrick admits making this mistake himself: when building interactive advertising products, he spent lots of time talking to executives and none talking to the kids who were supposed to actually love the products.

If you're in a multi-sided marketplace, yes, you need to run customer conversations separately for all the various segments. But hopefully that isn't as scary now that you know how to keep conversations casual and efficient.

Key Takeaways from Chapter 7

Startups drown, they don't starve. Too many options is the real killer. Segmentation is your life raft.
Every big company started small. Google, Paypal, Evernote — they all began by serving a tiny, specific group before expanding to the world.
"Everyone" is not a customer segment. If your feedback is inconsistent, your segment is too broad. Slice it down.
Use Customer Slicing. Keep asking "within this group, who wants it most?" until you have a who-where pair — a specific person you can physically go find and talk to.
Choose segments that are profitable, reachable, and personally rewarding. Don't just pick the biggest market — pick one you can actually serve and enjoy serving.
Watch out for hidden segments. Multi-sided marketplaces, products for kids (parents are the buyers), B2B with complex buying processes — make sure you're talking to all the relevant groups.
Don't over-plan. Spend a few minutes choosing an initial segment, go talk to them, and adjust as you learn. You can always broaden later.

This is part of my series where I break down each chapter of The Mom Test by Rob Fitzpatrick. If you're building a product and talking to customers, this book is essential reading.

Previously: Chapter 6 - Finding Conversations
Next up: Chapter 8 - Running the Process

What I Learned from "The Mom Test" - Chapter 6: Finding Conversations

Ege Pakten — Fri, 06 Mar 2026 10:16:10 +0000

A developer's guide to actually finding people to talk to — and making them want to talk to you

So you know how to ask good questions (Chapter 1-3), keep things casual (Chapter 4), and push for real commitments (Chapter 5). Great. But there's one problem nobody talks about enough: where do you actually find these people to talk to?

Chapter 6 is Fitzpatrick's playbook for finding conversations. And the core insight surprised me: you don't need to be a networking wizard. You just need to be strategic about where you show up and how you ask.

Outline

In this post, I'll break down Chapter 6 into the following sections:

Going to Them: Cold Outreach — Why cold conversations are a necessary evil and how to make the most of them (cold calls, serendipity, finding excuses, immersing yourself, landing pages, and getting clever).
Bringing Them to You — How to flip the dynamic so customers find you instead (organising meetups, speaking & teaching, industry blogging).
Creating Warm Intros — The gold standard for conversations and how to manufacture them (7 degrees of bacon, industry advisors, universities, investors, and cashing in favours).
Asking For and Framing the Meeting — The 5-element framework (Vision/Framing/Weakness/Pedestal/Ask) for getting meetings without sounding salesy.
To Commute or to Call — Why in-person beats phone calls, and when exceptions make sense.
The Advisory Flip — A powerful mindset shift that makes customer conversations feel natural instead of desperate.
How Many Meetings Do You Actually Need? — When to stop talking and start building.

Going to Them: Cold Outreach

Let's be real — cold outreach sucks. Nobody likes cold calls, and nobody likes receiving them. But sometimes, especially at the very beginning, you have no choice. You don't know anyone in the industry yet, and you need to start somewhere.

The key insight Fitzpatrick shares is this: the goal of cold conversations is to stop having them. You hustle together the first one or two from wherever you can, treat people's time respectfully, genuinely try to solve their problem, and those cold conversations start turning into warm intros. The snowball starts rolling.

Cold Calls

If you reach out to 100 people and 98 of them ignore you, what does that mean? It means you now have 2 conversations in play. That's it. Unless your entire business model depends on cold outreach, the rejection rate is irrelevant. You only need a few yeses to get the ball rolling.

One team successfully used cold LinkedIn messages to reach C-level executives at major UK retailers. They were ignored by practically everyone, but they only needed one "yes" to get started. And that one "yes" led to warm intros to others.

Seizing Serendipity

Beyond cold outreach, stay open to unexpected opportunities. Fitzpatrick shares a story about being at an engagement party and overhearing someone mention a speaking engagement. He walked over, started a genuine conversation about her career, and she ended up becoming his first committed alpha user.

The lesson? If you stop thinking of customer conversations as formal "interviews" and start thinking of them as genuine conversations about people's lives and problems, opportunities are everywhere. People love talking about their problems — by showing genuine interest, you become more interesting than 99% of people they've met.

Rule of Thumb: If it's not a formal meeting, you don't need to make excuses about why you're there or even mention that you're starting a business. Just ask about their life.

Find a Good Excuse

Sometimes you need a reason to start a conversation with a stranger. Fitzpatrick tells a great story about an entrepreneur who was building a product for cafe owners. He'd been hitting the pavement for weeks, getting turned away from cafe after cafe. The fix? Walking into a cafe and saying: "This coffee is amazing — I wanted to ask about the story behind the beans." Suddenly, the conversation was natural. The owner wasn't around, but the manager gave them the owner's contact details.

The trade-off with using an excuse is that it's hard to transition into a product or sales conversation later without revealing the initial deception. So think of these as one-time learning opportunities, not the start of an ongoing relationship.

The ultimate excuse? Having a PhD student on your team. "I'm doing research on X for my dissertation" opens almost any door. If you're really desperate, you can always say you're "writing a book" on the topic.

Rule of Thumb: If it's a topic you both care about, find an excuse to talk about it. Your idea never needs to enter the equation and you'll both enjoy the chat.

Immerse Yourself in Where They Are

This is one of the most underrated strategies. Instead of trying to find customers from the outside, go to where they already gather.

Fitzpatrick wanted to build tools for conference organisers and professional speakers. He didn't know any of the big names. So he hit the conference circuit and gave free talks everywhere he could. The speakers' lounge became his personal customer conversation machine. By immersing himself in the community, he met a load of people and had all the connections and conversations he could handle.

Interestingly, he ultimately decided that big speakers and big conferences were a bad customer segment and walked away. Not every conversation has to validate your idea — sometimes the most valuable learning is discovering what NOT to build.

Landing Pages

Joel Gascoigne did a classic landing page test with his startup Buffer. He described the value proposition and collected emails. But here's what most people miss: it wasn't the conversion rate metrics that convinced him to move forward. It was the conversations that resulted from him emailing every single person who signed up and saying hello.

Landing pages are a great way to collect qualified leads that you can then reach out to and have real conversations with. Paul Graham suggests a similar approach: get your product out there, see who seems to like it most, and then reach out to those types of users for deeper learning.

Get Clever

Every business is different, and sometimes you need a creative approach. One guy wanted to sell to top-tier universities like Stanford and Harvard. He needed to understand their problems and be taken seriously by decision-makers. His solution? He organised a semi-monthly "knowledge exchange" call between department heads of top universities to discuss shared challenges. By simply organising the call and playing host, he immediately absorbed all the credibility of the participating universities and got direct phone access to a pile of great leads.

The point is: don't just copy what someone else is doing. Consider your unique situation and get creative about how to manufacture conversations.

Bringing Them to You

When you're the one initiating conversations, you're always on the back foot. The other person is suspicious and trying to figure out if you're wasting their time. The better approach? Find ways to make them come to you. This saves time, reduces friction, and makes people take you more seriously.

Organise Meetups

For marginally more effort than attending an event, you can organise your own and benefit from being the centre of attention. Want to understand HR professionals' problems? Organise an "HR professionals happy hour." People will assume you're credible just because you're the one who sent the invite emails. It's the fastest and most unfair trick for rapid customer learning, and it also bootstraps your industry credibility.

Speaking & Teaching

Teaching is massively under-valued as both a learning and selling tool. If you're building better project management software, you probably have expertise and strong opinions about how things could be better. That's the magic combination for being an effective teacher.

Teach at conferences, workshops, through online videos, blogging, and by doing free consulting or office hours. You'll refine your message, connect with potential customers who take you seriously, and learn which parts of your offering resonate — all before you've even built it. Then simply chat up the attendees who are most keen.

Industry Blogging

Even if you have no audience, blogging about your industry is incredibly helpful. When Fitzpatrick sent cold emails from his blog email address, people would often meet with him because they had checked his domain, seen his industry blog, and figured he was an interesting person to talk to. The traffic and audience were almost irrelevant — the blog served as a credibility signal.

Blogging is also a great exercise for getting your thoughts in a row. It makes you a better customer conversationalist because you've already spent time thinking deeply about the industry's problems.

Creating Warm Intros

Warm intros are the gold standard. Conversations are infinitely easier when you get an introduction through a mutual friend that establishes your credibility and reason for being there.

7 Degrees of Bacon

The world is smaller than you think. Everyone knows someone. You just have to ask.

Fitzpatrick tells a story about a team of recent graduates who needed to reach McKinsey-style consultants. They were at a co-working space, so one of them stood on a chair and yelled: "Does anyone here know anyone who works at McKinsey? Can we talk to you for a second? We'll buy you a beer!" They bought three beers, had three quick chats, and left with a diary full of intros.

For consumer products, it's even easier — everyone knows a recent mom, an amateur athlete, or a theatre enthusiast.

Rule of Thumb: You can find anyone you need if you ask for it a couple of times. Kevin Bacon's 7 degrees of separation applies to customer conversations too.

Industry Advisors

Advisors can be a goldmine for intros. In his first company, Fitzpatrick relied heavily on 5 advisors who each had around half a percent of equity. Their main job was to make credible introductions. He met with each one once per month and got a fresh batch of intros weekly without it being a huge time burden for anyone.

You'd also be surprised by the quality of people willing to join your advisory board. The first conversation with a good advisor looks a lot like the first conversation with a flagship customer — you're both talking passionately about a space you care about. You can sometimes recruit great advisors directly from your early customer conversations.

Universities

If you're still in or recently out of university, professors are a goldmine. They get their grant funding from friendly, high-level industry folks, and since they're investing in research, those industry contacts are self-selected to be excited about new projects. Plus, professors are easy to reach — they post their emails publicly and you can generally just wander into their office.

Investors

Top-tier investors are awesome for B2B intros. Beyond their own rolodex and company portfolio, they can usually pull off cold intros to practically any industry. They can also help you close better advisors and directors than you'd be able to wrangle on your own. This applies to anyone who is a "big deal" and has already bought into your idea — always ask: who can they connect you to?

Cash in Favours

Remember all those people who brushed you off saying "Sounds great, keep me in the loop and let me know how I can help"? Now's the time to call in those favours. Reply to that old email and tell them you're ready for an intro to that person they know. Use the framing format from the next section to make their lives easy and reassure them you won't waste anyone's time.

You'll get ignored a lot, but who cares? You're not trying to minimise your failure rate — you're trying to get a few conversations going. Don't make a habit of it though, since it can burn bridges.

Asking For and Framing the Meeting

Sometimes a proper meeting can't be avoided — you need the full hour with someone senior. In those cases, how you frame the meeting request makes all the difference.

If you don't frame it properly, it becomes a sales meeting by default, which is bad for three reasons: the customer closes up about pricing, attention shifts to you instead of them, and it's going to be the worst sales meeting ever because you aren't ready.

The Five Key Elements

Fitzpatrick outlines a framework for requesting meetings that works incredibly well. The five elements are: Vision / Framing / Weakness / Pedestal / Ask

The mnemonic is: "Very Few Wizards Properly Ask [for help]."

Vision — You're an entrepreneur trying to solve a problem or achieve a vision. Don't mention your specific idea.
Framing — Set expectations about what stage you're at and, if true, that you don't have anything to sell.
Weakness — Show vulnerability by mentioning a specific problem you're struggling with. This also clarifies you're not a time waster.
Pedestal — Put them on a pedestal by showing how much they, in particular, can help.
Ask — Explicitly ask for help.

Here's an example of what this looks like in practice:

As Fitzpatrick suggests, a good meeting request might look like this:

Hey Pete,

I'm trying to make desk & office rental less of a pain for new businesses (vision). We're just starting out and don't have anything to sell, but want to make sure we're building something that actually helps (framing).

I've only ever come at it from the tenant's side and I'm having a hard time understanding how it all works from the landlord's perspective (weakness). You've been renting out desks for a while and could really help me cut through the fog (pedestal).

Do you have time in the next couple weeks to meet up for a chat? (ask)

— Rob Fitzpatrick, The Mom Test

People like to help entrepreneurs, but they also hate wasting their time. This kind of opening tells them you know what you need and that they'll be able to make a real difference.

Once the meeting starts, you need to grab the reins quickly. Repeat what you said in the email and immediately drop into your first question. If someone else made the introduction, use them as a voice of authority. Have a plan for the meeting and be assertive about keeping it on track.

To Commute or to Call

One common shortcut is to move conversations to phone or video calls. Fitzpatrick is not a fan, and for good reason.

When you're in person, you get access to body language, facial expressions, and the natural rapport that comes from sharing a physical space. On the phone, people are trying to squeeze calls between other activities, wondering when they can hang up, and the whole thing ends up feeling more like a scripted interview than a natural conversation.

In-person meetings also have a huge advantage for building ongoing relationships. Nobody becomes friends over the phone. And those friendships are what lead to warm intros and future meetings.

That said, some experienced practitioners in the field do recommend phone calls, and they can work. But Fitzpatrick's advice is to start in person first. It's too easy to use phone calls as an excuse to skip the awkwardness of meeting someone face-to-face, rather than as a considered trade-off.

The Advisory Flip

This is a subtle but powerful mindset shift. Instead of going into conversations thinking "I need to find customers", think "I'm looking for industry advisors."

When you're looking for customers, you feel needy. You're on the back foot. You're basically asking: "Please buy my thing." But when you're looking for advisors, the whole dynamic flips. You're evaluating them. You're the one deciding if they're a good fit. Even if the topics you discuss are the same, both you and the other person will notice the difference.

This isn't about explicitly telling people you're looking for advisors (unless you already like them and it comes up naturally). It's about orienting your state of mind to give you a helpful internal narrative and consistent front.

The sales-advisor switch also puts you firmly in control of the meeting, since you're now evaluating them. You set the agenda, you keep it on topic, and you propose next steps.

How Many Meetings Do You Actually Need?

Every meeting has an opportunity cost. When you're travelling to that meeting, you aren't writing code or building your product. So how many conversations is enough?

The UX community says: keep talking to people until you stop hearing new information.

In practice, if your initial assumptions are mostly correct and you're in a simple industry, it might only take 3-5 conversations to confirm what you already believe. But you usually won't get that lucky. It often takes more until you start hearing a consistent message.

Here's a useful diagnostic: if you've run more than 10 conversations and the results are all over the map, your customer segment is probably too vague. You might be mashing together feedback from multiple different types of customers.

The goal isn't to have a thousand meetings. It's about quickly learning what you need, and then getting back to building. In most cases, you should be able to answer almost any question about your business or customers within a week.

Rule of Thumb: Keep having conversations until you stop hearing new stuff. If you're still getting wildly different answers after 10+ conversations, your customer segment is too broad.

Key Takeaways from Chapter 6

The goal of cold outreach is to stop doing cold outreach. Hustle the first few conversations, then convert them into warm intros.
Go where your customers already are. Conferences, meetups, online communities — immerse yourself in their world instead of trying to pull them into yours.
Make them come to you. Organise events, teach, blog. Being the host or the expert flips the power dynamic in your favour.
Warm intros beat everything. Ask your network, advisors, investors, and even previous contacts for introductions. Everyone knows someone.
Frame your meeting request properly. Use the VFWPA framework (Vision/Framing/Weakness/Pedestal/Ask) to get meetings without sounding salesy.
Start in person. Phone calls are a shortcut that often backfires. In-person conversations build better relationships and give you better data.
Flip your mindset. You're not looking for customers — you're looking for advisors. This one mental switch changes everything about how the conversation feels.
Know when to stop. Keep talking until you stop learning new things, then get back to building.

This is part of my series where I break down each chapter of The Mom Test by Rob Fitzpatrick. If you're building a product and talking to customers, this book is essential reading.

Previously: Chapter 5 - Commitment and Advancement
Next up: Chapter 7 - Choosing Your Customers

The Mom Test - Chapter 5: Commitment and Advancement

Ege Pakten — Mon, 02 Mar 2026 11:03:54 +0000

In the previous chapters, we learned how to have proper customer conversations — avoiding compliments, digging into specifics, and not pitching too early. But here's a question that kept bugging me: How do I know if a meeting actually went well?

Chapter 5 answers exactly that. And the answer is brutally simple: a meeting went well only if it ends with a commitment.

Outline

In this post, I'll break down Chapter 5 into the following sections:

There's No Such Thing as a Meeting That "Went Well" — Why every meeting either succeeds or fails, and how compliments trick you into thinking you're making progress.
Commitment and Advancement: Two Sides of the Same Coin — The two key concepts of the chapter and why they always come together.
The Currencies of Commitment — The three types of commitment (Time, Reputation, Money) and how they escalate in seriousness.
The Spectrum: From Zombie Lead to Committed Customer — How to read the signals and know exactly where you stand with a potential customer.
Why We Don't Ask for Commitments (And Why We Should) — The two traps that prevent us from getting real signals: fishing for compliments and not asking for next steps.
The "Crazy" First Customers: Your Early Evangelists — Why your first customers won't be "normal" buyers, and why that's a feature, not a bug.
How to Push for Commitment Without Being a Used Car Salesman — A practical framework for asking for commitments without feeling pushy.
Don't Ask for Commitment Too Early — Why timing matters and how to match your ask to the stage of the relationship.

There's No Such Thing as a Meeting That "Went Well"

This was a mindset shift for me. I used to walk out of meetings thinking "That went great! They loved the idea!" — and then... nothing happened. No follow-up, no next steps, just silence.

Fitzpatrick puts it bluntly:

Every meeting either succeeds or fails.

A meeting fails when you leave with:

A compliment: "That's a really cool idea!"
A stalling tactic: "Let's circle back after the holidays."

A meeting succeeds when you leave with:

A commitment to the next step
Something concrete that advances the relationship forward

The tricky part? The subtle stalls don't feel like rejection. "We should definitely talk again soon" sounds positive, but it's just a polished version of "Don't call me, I'll call you."

Rule of Thumb: If you leave a meeting feeling good but without a concrete next step, you probably got played by a compliment, not a commitment.

Commitment and Advancement: Two Sides of the Same Coin

Fitzpatrick introduces two key concepts:

Commitment — When someone gives you something they value. This proves they're serious and not just being polite.

Advancement — When the relationship moves to the next concrete step in your sales or learning process.

These two almost always come together. To advance to the next step, someone has to commit something. And if someone commits something, the process naturally advances.

For example: You want to demo your product to a company's decision-maker. To get that meeting (advancement), your current contact needs to introduce you to their boss (reputation commitment). One doesn't happen without the other.

Rule of Thumb: Commitment and advancement are functionally the same thing. If you're getting one, you're usually getting both. If you're getting neither, the meeting failed.

The Currencies of Commitment

Not all commitments are created equal. Fitzpatrick breaks them down into three "currencies" — and they escalate in seriousness:

1. Time Commitment

This is the lightest form. The person is investing their time to engage with you further.

Examples:

Agreeing to a follow-up meeting with clear next steps
Sitting down for a longer, deeper conversation
Trying out your prototype or beta and giving feedback
Coming to your office (or going out of their way) for a meeting

If someone won't even give you another 30 minutes of their time, that's a pretty clear signal.

2. Reputation Commitment

This is heavier. The person is putting their name and credibility on the line for you.

Examples:

Introducing you to their boss or a decision-maker
Introducing you to a peer or potential customer
Giving you a public testimonial or case study
Posting about you on social media or their company Slack

When someone introduces you to their boss, they're essentially saying "I believe in this enough to risk looking stupid if it doesn't work out." That's real skin in the game.

3. Financial Commitment

The ultimate signal. Money talks, everything else walks.

Examples:

A letter of intent (LOI) or pre-order
A deposit or partial payment
Pre-paying for the product before it's built

If someone says "I'd definitely pay for that" — that means nothing. If someone says "Here's $500, let me know when it's ready" — that means everything.

Rule of Thumb: The more someone gives you (time → reputation → money), the more seriously you can take their signal. Compliments cost nothing. Commitments cost something. That's the whole difference.

The Spectrum: From Zombie Lead to Committed Customer

Fitzpatrick describes a spectrum of signals you might get from potential customers, and it's incredibly useful for figuring out where you actually stand:

Cold signals (the meeting failed):

"That's cool, I like it" → compliment, worthless
"Looks interesting, keep me in the loop" → polite brush-off
"Let's grab coffee sometime" → stalling, no specifics
No follow-up after the meeting → they forgot you exist

Warm signals (getting somewhere):

"Can you show this to my team next Tuesday?" → time + reputation commitment
"Send me the beta link, I'll try it this week" → time commitment with a deadline
"Let me introduce you to our Head of Product" → reputation commitment

Hot signals (you're onto something):

"How much would this cost? Can we do a pilot?" → moving toward financial commitment
"We'd like to pre-order 50 licenses" → money on the table
"Here's a deposit, build it" → they're all in

Rule of Thumb: If you can't tell where someone falls on this spectrum, you didn't push hard enough for a commitment at the end of the meeting.

Why We Don't Ask for Commitments (And Why We Should)

So if commitments are so important, why don't we ask for them? Fitzpatrick identifies two main traps:

Trap 1: You're Fishing for Compliments

Instead of asking "Would you be willing to pay for this?" or "Can I show this to your boss?", we ask soft questions like:

"What do you think of the idea?"
"Would you use something like this?"

These questions are begging for a compliment, not a commitment. And guess what? People are happy to give you a compliment because it costs them nothing and gets you out of the room.

Trap 2: You're Not Asking for Next Steps

The meeting is going well. You're vibing. You're having a great conversation. And then... you just let it end. No ask. No push. You walk away with warm feelings and zero concrete progress.

This is fear dressed up as politeness. We don't want to be "pushy" so we don't ask. But here's the thing — if your product is genuinely solving their problem, asking for a next step isn't pushy. It's helpful.

Rule of Thumb: Always know what commitment you want before the meeting starts. Then ask for it before the meeting ends. If you don't ask, you won't get it. Period.

The "Crazy" First Customers: Your Early Evangelists

Fitzpatrick makes an important point about who your first customers will be. They won't be normal, rational, cautious buyers. Your first customers will be a little bit "crazy" — and that's a good thing.

Your early evangelists typically:

Have the problem right now, not "someday"
Know they have the problem — they're not in denial
Have already tried to solve it (maybe with spreadsheets, duct tape, or a competitor)
Have the budget or authority to actually pay for a solution
Are desperate enough to try an unfinished, unpolished product from an unknown startup

Think about it: a normal person wouldn't use a half-built product from two people in a garage. But someone who's in pain RIGHT NOW and has been looking for a solution? They'll tolerate bugs, missing features, and a terrible UI — because you're solving their burning problem.

These people are gold. They give you real feedback, real money, and real validation.

Rule of Thumb: If you can't find anyone who's desperate enough to use your product in its current state, you either haven't found your real customer segment, or you're not solving a painful enough problem.

How to Push for Commitment Without Being a Used Car Salesman

A common fear: "But I don't want to be pushy!"

Fitzpatrick's answer: you're not being pushy if you're genuinely trying to help. Here's his framework:

Know your ask before the meeting. What's the ideal next step? An intro to the boss? A pilot program? A pre-order? Know this going in.
Ask at the end of the meeting. Don't let the meeting fizzle out. Before wrapping up, clearly state what you'd like to happen next.
Accept the answer gracefully. If they say no, that's actually great information. A clear "no" is infinitely more useful than a wishy-washy "maybe." At least now you know where you stand.
Interpret the response honestly. If they dodge, stall, or give you a compliment instead of a commitment — recognize it for what it is. Don't lie to yourself.

Examples of good asks:

"Would you be willing to do a trial run with your team next month?"
"Could you introduce me to [decision-maker] so I can understand their perspective?"
"If we build this by March, would you commit to being a pilot customer?"
"Can I get a letter of intent so we can prioritize building this feature for you?"

Rule of Thumb: If you're afraid to ask for a commitment because you think the person will say no — that's exactly why you need to ask. A "no" now saves you months of chasing a dead lead.

Don't Ask for Commitment Too Early

Here's the balance: pushing for commitment is essential, but timing matters.

If you push for money or a huge commitment during what's supposed to be an early learning conversation, you'll scare people away. The first few conversations should be about learning — understanding their problem, their workflow, their pain.

Once you've validated the problem and have something to show (even a rough prototype), THEN you start pushing for commitments.

The progression looks like this:

Early conversations: Learn about the problem. No pitch, no ask. Just listen.
Problem validated: Start showing your solution concept. Ask for time commitments (follow-up meetings, beta testing).
Solution takes shape: Push for reputation commitments (introductions, referrals).
Product is tangible: Push for financial commitments (pre-orders, deposits, LOIs).

Skipping steps or pushing too hard too early is just as bad as never pushing at all.

Rule of Thumb: Match your ask to the stage of the relationship. Early = learn. Middle = time and reputation. Late = money.

Key Takeaways from Chapter 5

Let me sum up the core lessons:

Meetings don't "go well." They either produce a commitment or they fail. Stop fooling yourself with compliments.
Commitments come in three currencies: Time, Reputation, and Money — in escalating order of seriousness.
Always push for a next step. Know your ask before the meeting and make it before the meeting ends.
Compliments ≠ Commitments. "That's a great idea" is worthless. "Here's my credit card" is priceless.
Your first customers will be "crazy." They have the problem now, they know it, and they're desperate enough to use your unfinished product.
A "no" is better than a "maybe." Rejection gives you clarity. Wishy-washiness wastes your time.
Match your ask to the stage. Don't ask for money when you should be asking questions. Don't ask for opinions when you should be asking for money.

This is part of my series where I break down each chapter of The Mom Test by Rob Fitzpatrick. If you're building a product and talking to customers, this book is essential reading.

Previously: Chapter 4 - Why You Should Keep Customer Conversations Casual
Next up: Chapter 6 - Finding Conversations

What I Learned from "The Mom Test" - Chapter 4: Why You Should Keep Customer Conversations Casual

Ege Pakten — Sat, 24 Jan 2026 12:50:12 +0000

A developer's guide to learning from customers without the meeting overhead

If you've been following my series on "The Mom Test" by Rob Fitzpatrick, you know we've been exploring how to have better conversations with customers. Today, I want to share what I learned from Chapter 4: Keeping It Casual.

Here's the big idea: formal meetings can actually hurt your customer learning.

Sounds counterintuitive, right? Let me explain.

The Problem with Formal Meetings

We developers love structure. When we want to learn something from customers, our first instinct is often to schedule a meeting. But Rob Fitzpatrick argues this is actually a trap.

Think about it. When you schedule a formal meeting:

The customer knows you want something from them
They put on their "meeting behavior"
They try to be polite instead of honest
Everything becomes awkward and formal

The author shares that Steve Blank, in his book "4 Steps to the Epiphany," recommends 3 separate meetings: one about the customer's problem, one about your solution, and one to sell the product. The idea is to avoid what Fitzpatrick calls the "Pathos Problem"—where you jump too quickly into emotional selling mode.

But here's the thing: setting up 3 formal meetings is incredibly time-consuming. Once you factor in scheduling, travel, preparation, and the actual meeting, a single 1-hour meeting can cost you 4+ hours of your time.

And as the author puts it: "The most precious resource in a startup is its founders' time."

The Solution: Keep It Casual

So what's the alternative? Keep your conversations casual and informal.

Instead of sending a calendar invite, just have a chat. Instead of a conference room, talk at a coffee shop. Instead of an interview, have a conversation.

Here's a great example from the book. Imagine you're at a conference and you bump into someone in your target industry. Instead of saying:

"Can I schedule a meeting to interview you about your problems?"

You say:

"Hey, I'm curious—how did you end up getting this gig?"

See the difference? One feels like work. The other feels like genuine human curiosity.

When you strip all the formality from the process, something magical happens:

No meetings to schedule
No "interviews" to conduct
Conversations become fast and lightweight
You can talk to a dozen people at a single industry meetup

The Meeting Anti-Pattern

The author introduces a concept called "The Meeting Anti-Pattern." This is the tendency to relegate every customer conversation into a calendar block.

Beyond being a bad use of time, our over-reliance on formal meetings makes us miss serendipitous learning opportunities.

Here's a funny example from the book: Imagine you're at a café, and your dream customer sits next to you. Instead of just starting a natural conversation, you psych yourself up and then fumble through an awkward pitch asking if maybe they want to get coffee sometime... at a different place.

That's ridiculous, right? You're already having coffee together! Just talk to them like a normal human being.

How Formal Is Too Formal?

Here are some warning signs that your conversation is too formal:

"So, first off, thanks for agreeing to this interview..."
"On a scale of 1 to 5, how much would you say..."

When you start with phrases like these, you immediately put the other person in "interview mode." They feel like they're doing you a favor, which creates an ominous atmosphere where they'll say whatever they think you want to hear.

Learning from customers doesn't mean wearing a suit and sipping boardroom coffee. The right questions are fast, interesting, and touch on topics people genuinely enjoy discussing.

Rule of thumb from the book: If it feels like they're doing you a favor by talking to you, it's probably too formal.

At their best, these conversations are a pleasure for both parties. You're probably the first person in a long time to be truly interested in the petty annoyances of their daily work.

How Long Should These Conversations Be?

This surprised me: early conversations can be incredibly short.

5 minutes is enough to learn whether a problem exists
10-15 minutes gets you into their workflow, time usage, and what they've tried before
30+ minutes happens naturally when you hit a topic they love (people enjoy talking about themselves!)

The longer conversations are easier to facilitate because once someone starts explaining their work, they can go into a monologue. You just need to point them in the right direction.

But here's the catch with formal B2B meetings: the duration is often determined by the arbitrary calendar block (usually 30 minutes or 1 hour), not by what you actually need to learn. You might lose:

5 minutes to miscellaneous tardiness
5 minutes to saying hello and small talk
10 minutes to product demos
5 minutes to figuring out next steps

That's half your meeting gone before you even start learning!

Putting It Together: A Real Example

The author shares a great story about trying to get feedback from busy investors who manage their dealflow with hundreds of meetings per month.

Instead of trying to schedule yet another meeting in their packed calendars, he showed up to an industry meeting and, during casual small talk, mentioned: "Our analysts kill most of them before they ever reach us."

That was it. One sentence during small talk. The investor responded with a bunch more details about how they deal with applications, pointed at some sticky notes on the wall, and shared exactly how their process worked.

It took 5 minutes. No formal meeting. No biases. No compliments. Just concrete facts.

Now compare that to someone who takes a 2-hour commute to attend a formal meeting. They might get the same information (or worse), but at a much higher cost.

The lesson? Sometimes a casual 5-minute chat is worth more than an hour-long formal meeting.

The Visionary Leap

Here's the beautiful part: once you've collected all these casual insights, you can take what the author calls the "visionary leap."

You take everything you've learned—all the problems, all the frustrations, all the workarounds—and you come up with a specific offering that makes your customers' lives better. Then you ask them to commit to it.

But you can only make this leap if you've been listening properly. And proper listening happens in casual, honest conversations—not in formal interviews where people tell you what you want to hear.

Key Takeaways

Let me summarize the main lessons from this chapter:

Formal meetings create bias. People behave differently when they know they're being "interviewed."
Casual conversations are faster and more honest. You can learn in 5 minutes what might take an hour in a formal setting.
The first conversation doesn't need to be a meeting. It works better as a casual chat.
Your time is precious. Don't waste 4 hours on meeting overhead when a 10-minute conversation would give you the same insights.
Serendipity is your friend. Be open to learning opportunities everywhere—conferences, coffee shops, random encounters.
If they feel like they're doing you a favor, it's too formal. The best conversations are enjoyable for both parties.

Rule of Thumb

I'll leave you with the book's main rule for this chapter:

"Learning about a customer and their problems works better as a quick and casual chat than a long, formal meeting."

And one more:

"Give as little information as possible about your idea while still nudging the discussion in a useful direction."

That's it for Chapter 4! The message is clear: stop hiding behind formal meetings. Get out there, talk to people like a normal human being, and you'll learn so much more.

In the next chapter, we'll explore more techniques for having effective customer conversations. Stay tuned!

This post is part of my series on "The Mom Test" by Rob Fitzpatrick. I'm a developer learning product management and customer validation, sharing my learnings with fellow developers who want to build products that people actually want. All examples and stories are credited to the original author.

What do you think? Have you experienced the difference between casual and formal customer conversations? Let me know in the comments!

What I Learned from "The Mom Test" - Chapter 3: Asking Important Questions

Ege Pakten — Sat, 24 Jan 2026 11:31:28 +0000

The Trivial Question Trap
Finding Scary Questions
Learning to Love Bad News
The Lukewarm Response Problem
Look Before You Zoom
Premature Zooming: A Common Mistake
Gaze Upon the Elephant
Does This Problem Actually Matter?
Prepare Your List of 3
Key Takeaways and Rules of Thumb

The Trivial Question Trap

Here's something I realized after reading this chapter: it's possible to ask non-biasing questions that are completely useless.

Once we learn The Mom Test, we might over-compensate. We start asking safe, neutral questions — but they're so trivial they don't move our business forward at all.

Asking someone "How old are you?" isn't biasing, sure. But it also tells you nothing useful about whether they'll buy your product or whether you're solving a real problem.

The Key Insight

You have to apply The Mom Test to questions that actually matter. Otherwise, you're just spinning your wheels — having nice conversations that feel productive but lead nowhere.

⚠️ Watch Out For

Asking demographic questions that don't help you understand the problem
Sticking to "safe" topics because important questions feel uncomfortable
Leaving conversations feeling good but having learned nothing critical

Finding Scary Questions

This section hit me hard. Fitzpatrick argues that beyond avoiding trivialities, you need to actively search for the world-rocking, scary questions you've been unintentionally avoiding.

We all have questions we're afraid to ask because the answers might destroy our business idea. But those are exactly the questions we need to ask.

How to Find Scary Questions

The book suggests a thought experiment:

Imagine your company has failed spectacularly
Ask yourself: what had to be true for that to happen?
Find ways to learn about those critical pieces

How to Identify Important Questions

Here's a practical test: a question is important when its answer could completely change (or disprove) your business.

If you get an unexpected answer and it doesn't affect what you're doing, it wasn't an important question to begin with.

A Real Example from the Book

Fitzpatrick shares a personal story that cost him dearly. One of his companies had legal ambiguities around content ownership. The theory was okay, but they lacked strong precedents.

A key customer's executives were excited, and their creative team was thrilled. But Fitzpatrick never asked the lawyers about the legal concerns — he was afraid of the answer.

The result? Not asking that scary question cost them at least half a million dollars.

The Hard Truth

There's no easy solution here. For unpleasant tasks, the book offers this advice: imagine what you would have someone else do if you were delegating it. Then do that yourself.

You're a startup. You're allowed to ask about money. You're allowed to ask uncomfortable questions. It's okay.

Rule of thumb: You should be terrified of at least one of the questions you're asking in every conversation.

✅ Do This

Identify the questions you've been avoiding
Ask yourself: "What could kill this business?"
Make yourself ask at least one scary question per conversation

❌ Don't Do This

Avoid topics because they make you uncomfortable
Assume things will "work out" without verification
Leave critical assumptions untested

Learning to Love Bad News

This concept was a mindset shift for me. We avoid important questions because the answers are scary. They might reveal that our beloved idea is fundamentally flawed, or that a major client will never buy.

But here's the reframe: bad news is actually good news — if you get it early.

The Economics of Bad News

Think about it this way:

Scenario	What Happens
One shot, bad news	Your bungee cord doesn't work, your café fails, your $50k startup idea flops — that's genuinely bad
Early bad news, resources left	You spend $5k to learn an idea is dead, but you still have $45k and all your new knowledge to find a viable path

If you have $50k and spend $5k to discover you're heading toward a dead end, that's actually a great result. You've saved $45k and gained valuable learning.

Why We Fish for Compliments

We go through the futile process of asking for opinions and fishing for compliments because we crave approval. We want to believe that the support and sign-off of someone we respect means our venture will succeed.

But here's the reality: that person's opinion doesn't matter. They have no idea if the business is going to work. Only the market knows.

The Real Victory

Similarly, if you have an exciting idea and talk to a few potential customers who don't actually care, that's a great result. You just saved yourself months of building and selling something nobody wants.

Bad news early is good news. Bad news late is disaster.

✅ Do This

Actively seek information that could disprove your idea
Celebrate when you learn something won't work (early)
Remember: finding out now saves you time and money

❌ Don't Do This

Avoid conversations because you might hear "no"
Seek validation instead of truth
Interpret silence or politeness as approval

The Lukewarm Response Problem

This was one of the most valuable insights for me. We often think that positive feedback is good and negative feedback is bad. But there's something worse than both: the lukewarm response.

What Lukewarm Looks Like

When you're learning about a problem or testing your product positioning, you might get responses along a spectrum:

Response Type	What They Say	What It Means
Strong Positive	"This is exactly what I need! When can I get it?"	Real problem, real interest
Strong Negative	"That's completely wrong for us because..."	Useful data, clear direction
Lukewarm	"That's pretty neat." / "Yeah, maybe."	Danger zone

Some responses tell you clearly: you're not getting paid, but it's also a bad result. When someone doesn't care at all, at least you know they're not your customer.

Lukewarm responses are the most dangerous because they feel somewhat positive but indicate no real interest.

Why Lukewarm Kills Businesses

As the book puts it: "Meh" responses are more reliable information than "Wow!" responses.

You can't build a business on lukewarm interest. If people aren't excited, they won't pay, they won't change their behavior, and they won't tell their friends.

Rule of thumb: There's more reliable information in a "meh" than a "Wow!" You can't build a business on lukewarm responses.

How to Handle Lukewarm

When you get a lukewarm response, dig deeper:

"You don't seem too excited about this — is it not a big problem for you?"
"On a scale of 1-10, how painful is this issue?"
"What would have to be true for this to be a must-have for you?"

✅ Do This

Recognize lukewarm responses for what they are: a "no"
Push for clarity when responses are ambiguous
Value strong negative feedback over weak positive feedback

❌ Don't Do This

Interpret "that's interesting" as validation
Count lukewarm responses as potential customers
Proceed without genuine enthusiasm from your market

Look Before You Zoom

This section addresses a mistake I've definitely made: getting lost in details before understanding the big picture.

The Problem with Premature Details

Another way to miss important questions is by obsessing over ultimately unimportant nuances. We get stuck in the details before understanding whether we're even solving the right problem.

Here's what happens:

You ask about specific features or implementation details
The person knows about those details, but doesn't actually care enough to fix the problem
You lead them through questions about that semi-problem
They happily answer, drowning you in unimportant details
You zoom in on a super-specific problem before understanding the big picture

Zooming in too quickly on unimportant details can irreparably confuse your learning.

A Really Bad Conversation Example

The book gives a great example of how this goes wrong:

You: "Hi, thanks for taking the time. We're building phone and tablet 
     apps to help people stay in shape. How do you stay fit?"

Them: "Okay." (I never exercise, so this should be quick)

You: "How often do you go to the gym?"

Them: "Not really ever." (Well, looks like we're done here then!)

You: "What would you say is your biggest problem with going to the gym?"

What went wrong here?

The opener mentioned the idea — now everything is biased
Asking "how often do you go to the gym" is demographic data that tells you what kind of person they are, not whether there's a real problem
Asking about "your biggest problem with the gym" prematurely zooms into whether staying fit is a real problem

Any response you get is going to be dangerously misleading. You're asking someone who doesn't care about fitness to tell you about fitness problems.

A Good Conversation Instead

You: "How often do you go to the gym?"

Them: "Um. Not really ever."

You: "Why not?" (Instead of taking it for granted that staying fit is 
     one of their top priorities, let's dig into the motivations)

Them: "I don't know, it's just not something I'm that worried about, 
      you know?"

You: "When's the last time you did try? Have you ever joined a gym or 
     taken up jogging or anything?"

Them: "Oh yeah, I used to be into sports in high school. It just 
      hasn't been a big deal since I settled down. Running around 
      after the kids gives me all the cardio I need!"

You: "Haha, gotcha. Thanks for the time!"

Why this is better:

We learned this person isn't our customer
We didn't bias them with our idea
We can move on and find people who actually care about fitness
The conversation was pleasant and we didn't waste time on details

Rule of thumb: Start broad and don't zoom in until you've found a strong signal, both with your whole business and with every conversation.

✅ Do This

Start with broad questions about their life and priorities
Find out if they even care about the problem space first
Only zoom into details after confirming genuine interest

❌ Don't Do This

Jump straight into specific questions about your solution
Assume everyone has the problem you're solving
Spend 30 minutes on details with someone who doesn't care

Premature Zooming: A Common Mistake

The book expands on this with another example about fitness apps:

Bad Conversation: Zooming Into Nothing

You: "Hi. Thanks for taking the time. We're building phone and tablet 
     apps to help people stay fit."

Them: "I guess the time it takes to get there. I'm always kind of 
      busy, you know?"

You: "Perfect. That's great. And could you rank these 4 in terms of 
     which is most important to you in a fitness program: convenience, 
     personalisation, novelty, or cost?"

Them: "Probably convenience, then cost, then personalisation, then 
      novelty."

You: "Okay. Awesome. Thanks so much. We're working on an app to help 
     you exercise in the convenience of your own home..."

Them: "Cool. I'd love to try it when it launches."

What's wrong here?

The opener biases the conversation — you're now fishing for compliments
Asking them to rank features assumes they actually care about fitness (they might not)
The "convenience" ranking doesn't tell you if this person actually cares enough to pay
"Cool, I'd love to try it" is a non-committal compliment and a stalling tactic
You totally missed the point: You're misinterpreting the conversation as validation when you're prematurely zooming into irrelevant details

Good Conversation: Finding What Matters First

You: "What are your big goals and focuses right now?"

Them: "The big one is that promotion at work. And we just bought our 
      first house, so I've got to find a bit more time for the missus. 
      Things have been pretty busy lately."

You: "You're buying a new house and expect to be less busy?"

Them: "Can't blame a guy for hoping."

You: "Is getting healthier on that list?"

Them: "I'm actually feeling pretty good at the moment."

Why this is better:

We asked about their big goals first — fitness wasn't even mentioned
We learned what actually matters to them (work, house, relationship)
We discovered they're not worried about fitness right now
We know this isn't our customer without wasting either person's time

The Leading Question Trap

The book makes an interesting point: sometimes leading questions are okay, as long as you're careful.

We probably already know the answer when you're about to abort the conversation anyway. If they come back with a positive, just be extra careful in making sure they aren't lying.

You: "Is getting healthier on that list?"
Them: "I'm actually feeling pretty good at the moment." 
      → Not a customer.

✅ Do This

Ask about their overall goals before zooming into your topic
Be willing to end conversations when someone isn't your customer
Check if your problem area even registers as a priority for them

❌ Don't Do This

Assume everyone cares about the problem you're solving
Ask detailed questions before establishing relevance
Interpret polite interest as genuine need

Gaze Upon the Elephant

This section teaches us to look for the big, scary, obvious problems — not just the ones we want to solve.

De-risking the Business

Sometimes we comfort ourselves by asking questions which don't actually de-risk the business. We resolve the easy questions about our tools and features, but ignore the elephant in the room.

The book shares this scenario:

Let's say we suspect that teachers from the poorest schools are completely overloaded, and that yes, they are completely overloaded. We then spend weeks with them, figuring out exactly what their dream tool would do.

But we've missed the elephant: We go talk to them and confirm that yes, they are completely overloaded. Unfortunately, we've missed the elephant: the schools may not have the budgets available to pay us.

What We Tend to Ignore

Startups tend to focus on multiple failure points — problems of the teachers and the ability of the schools to pay. If any of these conditions doesn't exist, we must overhaul our idea.

The book says it's tempting to obsess over the most interesting of several failure points and ignore the others. But we miss important questions when we:

Focus only on problems we find interesting
Ignore risks related to our customers and market
Skip over the "boring" business model questions

Beyond the risks of our customers, we also have challenges with our own product. Overlooking product risks is just as deadly as overlooking the goals and constraints of our customers.

What to Consider

Ask yourself:

Risk Type	Questions to Ask
Product risk	Can I build it? Can I grow it?
Customer/market risk	Do they want it? Will they pay me? Are there lots of them?

Is it full of good data or bad data?

✅ Do This

Identify all the major risks to your business (product AND market)
Address the scariest assumptions first
Ask about budgets, decision-making, and buying processes

❌ Don't Do This

Only focus on the problems you find interesting
Ignore the "elephant in the room" (usually money or market size)
Assume if the problem exists, people will pay to solve it

Does This Problem Actually Matter?

At some point, you need to figure out if the problem you're solving is a must-solve (painkiller) or a nice-to-have (vitamin).

Painkiller vs. Vitamin

The book introduces this framework:

Type	Description	Customer Behavior
Painkiller	Solves an urgent, painful problem	They're actively looking, willing to pay, will switch
Vitamin	Nice improvement, not critical	They're interested but won't prioritize it

Questions to Determine if the Problem Matters

The book calls these "Does-this-problem-matter" questions:

"How seriously do you take your blog?"
"Do you make money from it?"
"Have you tried making more money from it?"
"How much time do you spend on it each week?"
"Do you have any major aspirations for your blog?"
"Which tools and services do you use for it?"
"What are you already doing to improve this?"
"What are the 3 big things you're trying to fix or improve right now?"

These questions help you understand if the problem is top-of-mind or just an occasional annoyance.

A Good Conversation Example

The book shares a conversation about talking to a blogger:

You: "Hey Rob, what are the top problems with your blog?"

Me: "I'm grumpy that Google Reader disappeared — I lost like half my 
    followers. And this book is consuming all of my interest in 
    writing, so I haven't really posted in months. And Wordpress 
    seems so slow these days."

You: "That Google Reader thing is a mess. What are you doing about it?"

Me: "Nothing, really. I don't know what to do. But it sucks."

You: "Have you looked into what your options are?"

Me: "No, I just caught the drama on Hacker News."

You: "Are you spending a lot of time working to build your audience 
     back up?"

Me: "Probably just keep on writing when I have something to say. 
    It's more of a hobby than a business, really."

What we learned:

The Google Reader problem sounds annoying, but they haven't done anything about it
It's not a big deal for them despite being "annoyed"
The blog is a hobby, not a business — so they won't pay much to solve problems
This isn't a customer worth pursuing for an audience-building tool

An Ambiguous Conversation

Sometimes the signal isn't clear:

Them: "...I get paid 2 or 3 grand per talk. Sometimes more if it's 
      corporate work."

You: "Where do you get your gigs? Do you have an agent?"

Them: "Yeah. He kind of sucks though. Most of my work comes through 
      people who just know me from my blog or have seen my other talks."

You: "What's wrong with the agent? And why do you still work with him?"

Them: "I'm one of the lowest-paid people they work with, so I get 
      ignored a lot. But sometimes he brings in deals, so whatever. 
      It's free money."

At this point:

Getting gigs is important to them (they mention income)
They have a workaround (the agent) but it's not perfect
The current solution isn't painful enough to actively change

Next step: Zoom in to introduce the problem and see if they care:

You: "I'm building a marketplace to cut out the agents and connect 
     event organisers directly with speakers. It should help you get 
     more gigs and keep the agent fees. How would that fit into your 
     speaking life?"

Them: "Man, that's awesome. If you could get me more gigs — or better 
      paid ones — I'd happily drop my agent and pay you 20% of the 
      boost. I know a bunch of other people who would love to as well."

Now we have signal:

This is a real problem for them
They're willing to pay (20% of the boost)
They're offering to refer others
This is worth pursuing

Product Risk vs. Market Risk

The book makes an important distinction:

Product risk: Can I build it? Can I grow it?
Customer/market risk: Do they want it? Will they pay me? Are there lots of them?

You can't overlook either one. The book shares a story of a founder who spent 3 months on worthless customer conversations. He was building gadgets to track farm animal fertility. The farmers responded like: "If you can build what you say you can build, I'll equip my whole herd."

The problem: He couldn't build it. The risk was in the product, not the market. He should have talked to technical experts, not just customers.

When Conversations Aren't Enough

For some businesses, you can't fully validate through conversations alone:

Situation	Why Conversations Aren't Enough
Online advertising	Advertisers will pay if you have traffic — you need to get traffic first
Affiliate products	You need traffic and ability to sell — the risk is in execution
Heavy product risk	The market exists but can you build the tech?

In these cases, the conversations give you a starting point, but you'll have to start building product earlier with less certainty.

✅ Do This

Ask questions that reveal how much they care about the problem
Find out if they've tried to solve it before
Understand if this is a top-3 priority for them
Differentiate between product risk and market risk

❌ Don't Do This

Assume complaints equal willingness to pay
Build without understanding if the problem is "must-solve"
Ignore product risk when the market seems interested

Prepare Your List of 3

The final section gives practical advice for preparing for conversations.

Why Pre-plan Your Questions

Pre-planning your big questions has several benefits:

Makes it easier to ask questions that pass The Mom Test — you're not improvising
Reduces biasing — you've decided on questions in a calm environment with your team
Helps you face tough questions — it's easier when you've already committed to asking them
Keeps you focused — you won't drift into trivial topics

How to Create Your List

For each type of person you talk to (customers, investors, industry experts, partners), pre-plan the 3 most important things you want to learn.

The questions will be different for each:

Person Type	Example Questions
Potential Customer	What's your current process? What have you tried? What would make you switch?
Industry Expert	What are the biggest changes in the market? Where do new entrants fail?
Investor	What concerns you about this space? What would make this a big opportunity?

Don't Over-stress About "Right" Questions

The book reassures us: your questions will change as you learn. Just choose whatever seems murkiest or most important right now.

You might get answers 1-3 from customer A
Answer 4 from customer B
Answers 5-7 from customer C

There's overlap and repetition, but you don't need to repeat the full set of questions with every participant. Pick up where you left off and keep filling in the picture.

The Serendipity Advantage

Knowing your list allows you to take advantage of serendipitous encounters.

Instead of running into a dream customer and asking to exchange business cards for a formal meeting later, you can "grab a coffee" (like everyone else) and just pop off your most important question.

This keeps it casual, which has advantages the book discusses later.

Rule of thumb: You always need a list of your 3 big questions.

✅ Do This

Write down your 3 most important questions before conversations
Update the list as you learn new things
Have different questions for different types of people
Be ready to ask your questions in casual encounters

❌ Don't Do This

Wing it and hope you'll remember what to ask
Ask the same trivial questions every time
Miss opportunities because you weren't prepared

Key Takeaways and Rules of Thumb

Let me summarize all the rules from this chapter:

Rules of Thumb

Rule	What It Means
You should be terrified of at least one question in every conversation	If you're not asking scary questions, you're not learning what matters
There's more reliable information in a "meh" than a "Wow!"	Lukewarm responses are actually worse than negative ones
Start broad and don't zoom in until you've found a strong signal	Don't get lost in details before understanding the big picture
You always need a list of your 3 big questions	Pre-planning helps you ask what matters and stay focused

My Personal Checklist

Before every customer conversation, I now ask myself:

Preparation:

[ ] Do I have my 3 big questions written down?
[ ] Is at least one of them scary?
[ ] Am I ready to hear bad news?

During the conversation:

[ ] Am I starting broad or jumping to details?
[ ] Is this person actually in my target market?
[ ] Am I getting lukewarm responses? (If so, dig or move on)

After the conversation:

[ ] Did I learn something that could change my business?
[ ] Did I ask about the elephant in the room (money, priorities)?
[ ] Can I describe their current situation in detail?

Quick Reference: Important vs. Trivial Questions

Trivial (Avoid)	Important (Ask These)
"How old are you?"	"What's your biggest challenge right now?"
"Do you use apps?"	"What have you tried to solve this?"
"Would you like this feature?"	"What would happen if you couldn't solve this?"
"Do you like our idea?"	"How are you dealing with this today?"

Quick Reference: Good Signs vs. Bad Signs

Good Signs ✅	Bad Signs 🚨
Strong emotion (positive OR negative)	Lukewarm "that's interesting"
Detailed description of their problem	Vague agreement with your pitch
They've tried to solve it before	They've never looked for a solution
They ask when they can get it	They say "keep me in the loop"
They want to introduce you to others	They're politely ending the conversation

Wrapping Up

This chapter fundamentally changed how I think about customer conversations. It's not just about avoiding bad questions (compliments, fluff, ideas) — it's about actively seeking the questions that matter most.

The biggest shifts for me:

Embrace scary questions — The questions you're avoiding are probably the most important ones
Bad news is good news (if it's early) — Better to learn now than after building
Lukewarm kills — Strong negative feedback is more valuable than weak positive feedback
Start broad, zoom later — Don't get lost in details before confirming the big picture
Always have your 3 questions ready — Preparation makes everything easier

I'm still working through the book, and I'll continue sharing what I learn. These concepts aren't just for startups — they apply to any developer who wants to build things people actually want.

Have you ever avoided asking a scary question and regretted it later? Or spent time on conversations that went nowhere because you zoomed in too fast? Share your experiences in the comments!

This post covers Chapter 3 of "The Mom Test" by Rob Fitzpatrick. I highly recommend reading the full book if you're serious about building products people actually want.

Sharing what I learn as a developer expanding into product thinking. If you're on a similar journey, feel free to explore my blog for more posts like this.

Currently reading: Chapter 3 ✅ | More insights coming soon...

What I Learned from "The Mom Test" - A Developer's Guide to Customer Conversations - Part 2

Ege Pakten — Thu, 08 Jan 2026 13:31:33 +0000

Chapter 3: Asking Important Questions

The Trivial Question Trap
Finding Scary Questions
Learning to Love Bad News
The Lukewarm Response Problem
Look Before You Zoom
Premature Zooming: A Common Mistake
Gaze Upon the Elephant
Does This Problem Actually Matter?
Prepare Your List of 3
Key Takeaways and Rules of Thumb

The Trivial Question Trap

Here's something I realized after reading this chapter: it's possible to ask non-biasing questions that are completely useless.

Once we learn The Mom Test, we might over-compensate. We start asking safe, neutral questions — but they're so trivial they don't move our business forward at all.

Asking someone "How old are you?" isn't biasing, sure. But it also tells you nothing useful about whether they'll buy your product or whether you're solving a real problem.

The Key Insight

You have to apply The Mom Test to questions that actually matter. Otherwise, you're just spinning your wheels — having nice conversations that feel productive but lead nowhere.

⚠️ Watch Out For

Asking demographic questions that don't help you understand the problem
Sticking to "safe" topics because important questions feel uncomfortable
Leaving conversations feeling good but having learned nothing critical

Finding Scary Questions

This section hit me hard. Fitzpatrick argues that beyond avoiding trivialities, you need to actively search for the world-rocking, scary questions you've been unintentionally avoiding.

We all have questions we're afraid to ask because the answers might destroy our business idea. But those are exactly the questions we need to ask.

How to Find Scary Questions

The book suggests a thought experiment:

Imagine your company has failed spectacularly
Ask yourself: what had to be true for that to happen?
Find ways to learn about those critical pieces

How to Identify Important Questions

Here's a practical test: a question is important when its answer could completely change (or disprove) your business.

If you get an unexpected answer and it doesn't affect what you're doing, it wasn't an important question to begin with.

A Real Example from the Book

Fitzpatrick shares a personal story that cost him dearly. One of his companies had legal ambiguities around content ownership. The theory was okay, but they lacked strong precedents.

A key customer's executives were excited, and their creative team was thrilled. But Fitzpatrick never asked the lawyers about the legal concerns — he was afraid of the answer.

The result? Not asking that scary question cost them at least half a million dollars.

The Hard Truth

There's no easy solution here. For unpleasant tasks, the book offers this advice: imagine what you would have someone else do if you were delegating it. Then do that yourself.

You're a startup. You're allowed to ask about money. You're allowed to ask uncomfortable questions. It's okay.

Rule of thumb: You should be terrified of at least one of the questions you're asking in every conversation.

✅ Do This

Identify the questions you've been avoiding
Ask yourself: "What could kill this business?"
Make yourself ask at least one scary question per conversation

❌ Don't Do This

Avoid topics because they make you uncomfortable
Assume things will "work out" without verification
Leave critical assumptions untested

Learning to Love Bad News

But here's the reframe: bad news is actually good news — if you get it early.

The Economics of Bad News

Think about it this way:

Scenario	What Happens
One shot, bad news	Your bungee cord doesn't work, your café fails, your $50k startup idea flops — that's genuinely bad
Early bad news, resources left	You spend $5k to learn an idea is dead, but you still have $45k and all your new knowledge to find a viable path

If you have $50k and spend $5k to discover you're heading toward a dead end, that's actually a great result. You've saved $45k and gained valuable learning.

Why We Fish for Compliments

But here's the reality: that person's opinion doesn't matter. They have no idea if the business is going to work. Only the market knows.

The Real Victory

Bad news early is good news. Bad news late is disaster.

✅ Do This

Actively seek information that could disprove your idea
Celebrate when you learn something won't work (early)
Remember: finding out now saves you time and money

❌ Don't Do This

Avoid conversations because you might hear "no"
Seek validation instead of truth
Interpret silence or politeness as approval

The Lukewarm Response Problem

This was one of the most valuable insights for me. We often think that positive feedback is good and negative feedback is bad. But there's something worse than both: the lukewarm response.

What Lukewarm Looks Like

When you're learning about a problem or testing your product positioning, you might get responses along a spectrum:

Response Type	What They Say	What It Means
Strong Positive	"This is exactly what I need! When can I get it?"	Real problem, real interest
Strong Negative	"That's completely wrong for us because..."	Useful data, clear direction
Lukewarm	"That's pretty neat." / "Yeah, maybe."	Danger zone

Some responses tell you clearly: you're not getting paid, but it's also a bad result. When someone doesn't care at all, at least you know they're not your customer.

Lukewarm responses are the most dangerous because they feel somewhat positive but indicate no real interest.

Why Lukewarm Kills Businesses

As the book puts it: "Meh" responses are more reliable information than "Wow!" responses.

You can't build a business on lukewarm interest. If people aren't excited, they won't pay, they won't change their behavior, and they won't tell their friends.

Rule of thumb: There's more reliable information in a "meh" than a "Wow!" You can't build a business on lukewarm responses.

How to Handle Lukewarm

When you get a lukewarm response, dig deeper:

"You don't seem too excited about this — is it not a big problem for you?"
"On a scale of 1-10, how painful is this issue?"
"What would have to be true for this to be a must-have for you?"

✅ Do This

Recognize lukewarm responses for what they are: a "no"
Push for clarity when responses are ambiguous
Value strong negative feedback over weak positive feedback

❌ Don't Do This

Interpret "that's interesting" as validation
Count lukewarm responses as potential customers
Proceed without genuine enthusiasm from your market

Look Before You Zoom

This section addresses a mistake I've definitely made: getting lost in details before understanding the big picture.

The Problem with Premature Details

Another way to miss important questions is by obsessing over ultimately unimportant nuances. We get stuck in the details before understanding whether we're even solving the right problem.

Here's what happens:

You ask about specific features or implementation details
The person knows about those details, but doesn't actually care enough to fix the problem
You lead them through questions about that semi-problem
They happily answer, drowning you in unimportant details
You zoom in on a super-specific problem before understanding the big picture

Zooming in too quickly on unimportant details can irreparably confuse your learning.

A Really Bad Conversation Example

The book gives a great example of how this goes wrong:

You: "Hi, thanks for taking the time. We're building phone and tablet 
     apps to help people stay in shape. How do you stay fit?"

Them: "Okay." (I never exercise, so this should be quick)

You: "How often do you go to the gym?"

Them: "Not really ever." (Well, looks like we're done here then!)

You: "What would you say is your biggest problem with going to the gym?"

What went wrong here?

The opener mentioned the idea — now everything is biased
Asking "how often do you go to the gym" is demographic data that tells you what kind of person they are, not whether there's a real problem
Asking about "your biggest problem with the gym" prematurely zooms into whether staying fit is a real problem

Any response you get is going to be dangerously misleading. You're asking someone who doesn't care about fitness to tell you about fitness problems.

A Good Conversation Instead

You: "How often do you go to the gym?"

Them: "Um. Not really ever."

You: "Why not?" (Instead of taking it for granted that staying fit is 
     one of their top priorities, let's dig into the motivations)

Them: "I don't know, it's just not something I'm that worried about, 
      you know?"

You: "When's the last time you did try? Have you ever joined a gym or 
     taken up jogging or anything?"

Them: "Oh yeah, I used to be into sports in high school. It just 
      hasn't been a big deal since I settled down. Running around 
      after the kids gives me all the cardio I need!"

You: "Haha, gotcha. Thanks for the time!"

Why this is better:

We learned this person isn't our customer
We didn't bias them with our idea
We can move on and find people who actually care about fitness
The conversation was pleasant and we didn't waste time on details

Rule of thumb: Start broad and don't zoom in until you've found a strong signal, both with your whole business and with every conversation.

✅ Do This

Start with broad questions about their life and priorities
Find out if they even care about the problem space first
Only zoom into details after confirming genuine interest

❌ Don't Do This

Jump straight into specific questions about your solution
Assume everyone has the problem you're solving
Spend 30 minutes on details with someone who doesn't care

Premature Zooming: A Common Mistake

The book expands on this with another example about fitness apps:

Bad Conversation: Zooming Into Nothing

You: "Hi. Thanks for taking the time. We're building phone and tablet 
     apps to help people stay fit."

Them: "I guess the time it takes to get there. I'm always kind of 
      busy, you know?"

You: "Perfect. That's great. And could you rank these 4 in terms of 
     which is most important to you in a fitness program: convenience, 
     personalisation, novelty, or cost?"

Them: "Probably convenience, then cost, then personalisation, then 
      novelty."

You: "Okay. Awesome. Thanks so much. We're working on an app to help 
     you exercise in the convenience of your own home..."

Them: "Cool. I'd love to try it when it launches."

What's wrong here?

The opener biases the conversation — you're now fishing for compliments
Asking them to rank features assumes they actually care about fitness (they might not)
The "convenience" ranking doesn't tell you if this person actually cares enough to pay
"Cool, I'd love to try it" is a non-committal compliment and a stalling tactic
You totally missed the point: You're misinterpreting the conversation as validation when you're prematurely zooming into irrelevant details

Good Conversation: Finding What Matters First

You: "What are your big goals and focuses right now?"

Them: "The big one is that promotion at work. And we just bought our 
      first house, so I've got to find a bit more time for the missus. 
      Things have been pretty busy lately."

You: "You're buying a new house and expect to be less busy?"

Them: "Can't blame a guy for hoping."

You: "Is getting healthier on that list?"

Them: "I'm actually feeling pretty good at the moment."

Why this is better:

We asked about their big goals first — fitness wasn't even mentioned
We learned what actually matters to them (work, house, relationship)
We discovered they're not worried about fitness right now
We know this isn't our customer without wasting either person's time

The Leading Question Trap

The book makes an interesting point: sometimes leading questions are okay, as long as you're careful.

We probably already know the answer when you're about to abort the conversation anyway. If they come back with a positive, just be extra careful in making sure they aren't lying.

You: "Is getting healthier on that list?"
Them: "I'm actually feeling pretty good at the moment." 
      → Not a customer.

✅ Do This

Ask about their overall goals before zooming into your topic
Be willing to end conversations when someone isn't your customer
Check if your problem area even registers as a priority for them

❌ Don't Do This

Assume everyone cares about the problem you're solving
Ask detailed questions before establishing relevance
Interpret polite interest as genuine need

Gaze Upon the Elephant

This section teaches us to look for the big, scary, obvious problems — not just the ones we want to solve.

De-risking the Business

Sometimes we comfort ourselves by asking questions which don't actually de-risk the business. We resolve the easy questions about our tools and features, but ignore the elephant in the room.

The book shares this scenario:

What We Tend to Ignore

Startups tend to focus on multiple failure points — problems of the teachers and the ability of the schools to pay. If any of these conditions doesn't exist, we must overhaul our idea.

The book says it's tempting to obsess over the most interesting of several failure points and ignore the others. But we miss important questions when we:

Focus only on problems we find interesting
Ignore risks related to our customers and market
Skip over the "boring" business model questions

Beyond the risks of our customers, we also have challenges with our own product. Overlooking product risks is just as deadly as overlooking the goals and constraints of our customers.

What to Consider

Ask yourself:

Risk Type	Questions to Ask
Product risk	Can I build it? Can I grow it?
Customer/market risk	Do they want it? Will they pay me? Are there lots of them?

Is it full of good data or bad data?

✅ Do This

Identify all the major risks to your business (product AND market)
Address the scariest assumptions first
Ask about budgets, decision-making, and buying processes

❌ Don't Do This

Only focus on the problems you find interesting
Ignore the "elephant in the room" (usually money or market size)
Assume if the problem exists, people will pay to solve it

Does This Problem Actually Matter?

At some point, you need to figure out if the problem you're solving is a must-solve (painkiller) or a nice-to-have (vitamin).

Painkiller vs. Vitamin

The book introduces this framework:

Type	Description	Customer Behavior
Painkiller	Solves an urgent, painful problem	They're actively looking, willing to pay, will switch
Vitamin	Nice improvement, not critical	They're interested but won't prioritize it

Questions to Determine if the Problem Matters

The book calls these "Does-this-problem-matter" questions:

"How seriously do you take your blog?"
"Do you make money from it?"
"Have you tried making more money from it?"
"How much time do you spend on it each week?"
"Do you have any major aspirations for your blog?"
"Which tools and services do you use for it?"
"What are you already doing to improve this?"
"What are the 3 big things you're trying to fix or improve right now?"

These questions help you understand if the problem is top-of-mind or just an occasional annoyance.

A Good Conversation Example

The book shares a conversation about talking to a blogger:

You: "Hey Rob, what are the top problems with your blog?"

Me: "I'm grumpy that Google Reader disappeared — I lost like half my 
    followers. And this book is consuming all of my interest in 
    writing, so I haven't really posted in months. And Wordpress 
    seems so slow these days."

You: "That Google Reader thing is a mess. What are you doing about it?"

Me: "Nothing, really. I don't know what to do. But it sucks."

You: "Have you looked into what your options are?"

Me: "No, I just caught the drama on Hacker News."

You: "Are you spending a lot of time working to build your audience 
     back up?"

Me: "Probably just keep on writing when I have something to say. 
    It's more of a hobby than a business, really."

What we learned:

The Google Reader problem sounds annoying, but they haven't done anything about it
It's not a big deal for them despite being "annoyed"
The blog is a hobby, not a business — so they won't pay much to solve problems
This isn't a customer worth pursuing for an audience-building tool

An Ambiguous Conversation

Sometimes the signal isn't clear:

Them: "...I get paid 2 or 3 grand per talk. Sometimes more if it's 
      corporate work."

You: "Where do you get your gigs? Do you have an agent?"

Them: "Yeah. He kind of sucks though. Most of my work comes through 
      people who just know me from my blog or have seen my other talks."

You: "What's wrong with the agent? And why do you still work with him?"

Them: "I'm one of the lowest-paid people they work with, so I get 
      ignored a lot. But sometimes he brings in deals, so whatever. 
      It's free money."

At this point:

Getting gigs is important to them (they mention income)
They have a workaround (the agent) but it's not perfect
The current solution isn't painful enough to actively change

Next step: Zoom in to introduce the problem and see if they care:

You: "I'm building a marketplace to cut out the agents and connect 
     event organisers directly with speakers. It should help you get 
     more gigs and keep the agent fees. How would that fit into your 
     speaking life?"

Them: "Man, that's awesome. If you could get me more gigs — or better 
      paid ones — I'd happily drop my agent and pay you 20% of the 
      boost. I know a bunch of other people who would love to as well."

Now we have signal:

This is a real problem for them
They're willing to pay (20% of the boost)
They're offering to refer others
This is worth pursuing

Product Risk vs. Market Risk

The book makes an important distinction:

Product risk: Can I build it? Can I grow it?
Customer/market risk: Do they want it? Will they pay me? Are there lots of them?

The problem: He couldn't build it. The risk was in the product, not the market. He should have talked to technical experts, not just customers.

When Conversations Aren't Enough

For some businesses, you can't fully validate through conversations alone:

Situation	Why Conversations Aren't Enough
Online advertising	Advertisers will pay if you have traffic — you need to get traffic first
Affiliate products	You need traffic and ability to sell — the risk is in execution
Heavy product risk	The market exists but can you build the tech?

In these cases, the conversations give you a starting point, but you'll have to start building product earlier with less certainty.

✅ Do This

Ask questions that reveal how much they care about the problem
Find out if they've tried to solve it before
Understand if this is a top-3 priority for them
Differentiate between product risk and market risk

❌ Don't Do This

Assume complaints equal willingness to pay
Build without understanding if the problem is "must-solve"
Ignore product risk when the market seems interested

Prepare Your List of 3

The final section gives practical advice for preparing for conversations.

Why Pre-plan Your Questions

Pre-planning your big questions has several benefits:

Makes it easier to ask questions that pass The Mom Test — you're not improvising
Reduces biasing — you've decided on questions in a calm environment with your team
Helps you face tough questions — it's easier when you've already committed to asking them
Keeps you focused — you won't drift into trivial topics

How to Create Your List

For each type of person you talk to (customers, investors, industry experts, partners), pre-plan the 3 most important things you want to learn.

The questions will be different for each:

Person Type	Example Questions
Potential Customer	What's your current process? What have you tried? What would make you switch?
Industry Expert	What are the biggest changes in the market? Where do new entrants fail?
Investor	What concerns you about this space? What would make this a big opportunity?

Don't Over-stress About "Right" Questions

The book reassures us: your questions will change as you learn. Just choose whatever seems murkiest or most important right now.

You might get answers 1-3 from customer A
Answer 4 from customer B
Answers 5-7 from customer C

There's overlap and repetition, but you don't need to repeat the full set of questions with every participant. Pick up where you left off and keep filling in the picture.

The Serendipity Advantage

Knowing your list allows you to take advantage of serendipitous encounters.

Instead of running into a dream customer and asking to exchange business cards for a formal meeting later, you can "grab a coffee" (like everyone else) and just pop off your most important question.

This keeps it casual, which has advantages the book discusses later.

Rule of thumb: You always need a list of your 3 big questions.

✅ Do This

Write down your 3 most important questions before conversations
Update the list as you learn new things
Have different questions for different types of people
Be ready to ask your questions in casual encounters

❌ Don't Do This

Wing it and hope you'll remember what to ask
Ask the same trivial questions every time
Miss opportunities because you weren't prepared

Key Takeaways and Rules of Thumb

Let me summarize all the rules from this chapter:

Rules of Thumb

Rule	What It Means
You should be terrified of at least one question in every conversation	If you're not asking scary questions, you're not learning what matters
There's more reliable information in a "meh" than a "Wow!"	Lukewarm responses are actually worse than negative ones
Start broad and don't zoom in until you've found a strong signal	Don't get lost in details before understanding the big picture
You always need a list of your 3 big questions	Pre-planning helps you ask what matters and stay focused

My Personal Checklist

Before every customer conversation, I now ask myself:

Preparation:

[ ] Do I have my 3 big questions written down?
[ ] Is at least one of them scary?
[ ] Am I ready to hear bad news?

During the conversation:

[ ] Am I starting broad or jumping to details?
[ ] Is this person actually in my target market?
[ ] Am I getting lukewarm responses? (If so, dig or move on)

After the conversation:

[ ] Did I learn something that could change my business?
[ ] Did I ask about the elephant in the room (money, priorities)?
[ ] Can I describe their current situation in detail?

Quick Reference: Important vs. Trivial Questions

Trivial (Avoid)	Important (Ask These)
"How old are you?"	"What's your biggest challenge right now?"
"Do you use apps?"	"What have you tried to solve this?"
"Would you like this feature?"	"What would happen if you couldn't solve this?"
"Do you like our idea?"	"How are you dealing with this today?"

Quick Reference: Good Signs vs. Bad Signs

Good Signs ✅	Bad Signs 🚨
Strong emotion (positive OR negative)	Lukewarm "that's interesting"
Detailed description of their problem	Vague agreement with your pitch
They've tried to solve it before	They've never looked for a solution
They ask when they can get it	They say "keep me in the loop"
They want to introduce you to others	They're politely ending the conversation

Wrapping Up

The biggest shifts for me:

Embrace scary questions — The questions you're avoiding are probably the most important ones
Bad news is good news (if it's early) — Better to learn now than after building
Lukewarm kills — Strong negative feedback is more valuable than weak positive feedback
Start broad, zoom later — Don't get lost in details before confirming the big picture
Always have your 3 questions ready — Preparation makes everything easier

I'm still working through the book, and I'll continue sharing what I learn. These concepts aren't just for startups — they apply to any developer who wants to build things people actually want.

Have you ever avoided asking a scary question and regretted it later? Or spent time on conversations that went nowhere because you zoomed in too fast? Share your experiences in the comments!

This post covers Chapter 3 of "The Mom Test" by Rob Fitzpatrick. I highly recommend reading the full book if you're serious about building products people actually want.

Sharing what I learn as a developer expanding into product thinking. If you're on a similar journey, feel free to explore my blog for more posts like this.

👉 Read the rest of the posts from here...

Currently reading: Chapter 3 ✅ | More insights coming soon...

What I Learned from "The Mom Test" - A Developer's Guide to Customer Conversations - Part 1

Ege Pakten — Wed, 07 Jan 2026 10:43:36 +0000

As developers, we're great at building things. But here's the uncomfortable truth: we often build the wrong things. Not because we lack technical skills, but because we're terrible at gathering honest feedback from potential customers.

I'm currently reading "The Mom Test" by Rob Fitzpatrick, and it's already changing how I think about customer conversations. This post covers the key lessons from the first chapters — I wanted to share them while they're fresh in my mind, both to help fellow developers and to solidify my own understanding.

Why We Collect Garbage Data
The Three Traps That Fool Us
Trap #1: The Compliment Trap
Trap #2: The Fluff Trap
Trap #3: The Idea Trap
Keeping Your Ego Out of the Room
When You Accidentally Become a Salesperson
The Simplest Rule: Shut Up
My Personal Cheat Sheet
Wrapping Up

Why We Collect Garbage Data

Picture this: You've got a brilliant idea. You share it with friends, family, maybe some potential users. Everyone says "Wow, that's cool! I'd totally use that!" Feeling validated, you spend months building it. Launch day comes... crickets. No one buys.

Sound familiar? I've been there.

The problem isn't that people lied to you. The problem is that you asked the wrong questions and interpreted the answers incorrectly.

Fitzpatrick introduces a concept that hit me hard. The data we collect from conversations can mislead us in two dangerous ways.

First, we might abandon a perfectly viable idea because the feedback seemed negative — even though we just talked to the wrong people or asked poorly framed questions. That's a false negative.

Second, and more dangerously, we might convince ourselves our idea is golden because everyone seemed enthusiastic — when in reality, they were just being polite. That's a false positive, and it's the silent killer of startups.

The Three Traps That Fool Us

After reading the first chapters, I've identified three types of responses that feel valuable but are actually worthless:

Compliments — When people say nice things about your idea
Fluff — When people speak in generics, hypotheticals, or future promises
Ideas — When people suggest features without you understanding why

Let me break down each one.

Trap #1: The Compliment Trap

Why Praise Is Poison

Nothing feels better than hearing "That's a great idea!" or "I love it!" after sharing your concept. Your brain releases dopamine. You feel validated.

But here's what I learned: compliments carry zero predictive value.

Think about it. When someone says "That's cool!", what are they actually telling you? Are they saying they'll pay for it? That they'll change their behavior to use it? That it solves a real problem they have?

No. They're just being nice.

Fitzpatrick points out that people hand out compliments for many reasons that have nothing to do with your product's viability:

They want to support you emotionally
They don't want to be the one to crush your dreams
Your excitement is infectious and they're mirroring it
They want to end the conversation gracefully
They find the concept intellectually interesting (which doesn't mean they'd pay for it)

Here's a humbling thought from the book: even venture capitalists — people whose literal job is predicting which ideas will succeed — are wrong more often than they're right. If professional future-predictors can't reliably judge ideas, why would a random person's "I love it!" mean anything?

What Actually Matters

The book argues that the only feedback worth trusting comes from facts about past behavior and concrete commitments. Everything else is noise.

Instead of accepting a compliment and moving on, redirect the conversation:

Before:

Them: "That's a really cool idea!"

You: "Thanks! Glad you like it!"

After:

Them: "That's a really cool idea!"

You: "I appreciate that! Quick question though — how are you handling this problem today?"

See the difference? The second approach acknowledges the compliment but pivots to extracting actual information.

Red Flags That You're Drowning in Compliments

I've started watching for these warning signs in myself:

During conversations:

I keep saying "Thanks!" or "Glad you like it!"
I feel great but can't recall specific facts I learned

After conversations:

I tell my team "That went really well!"
I report that "Everyone loves the idea!"
I can't answer basic questions like "What are they currently using?" or "How much time/money does this problem cost them?"

The book has a memorable line that I keep coming back to: compliments are like fool's gold — shiny and attractive, but ultimately worthless. Real gold is specific information about behavior, problems, and constraints.

Trap #2: The Fluff Trap

The Three Flavors of Empty Promises

Fluff is trickier than compliments because it sounds like real data. Someone gives you a specific-sounding answer, and you write it down thinking you've learned something. But you haven't.

I now categorize fluff into three types:

Generic Claims: Statements about what someone "usually" or "always" or "never" does.

When someone says "I always organize my inbox first thing in the morning," they're not describing reality — they're describing their idealized self. The person they wish they were. Fitzpatrick makes an insightful observation here: when people use generics, they're painting a portrait of who they aspire to be, not who they actually are.

Future Promises: Statements about what someone "would" or "will" do.

"I would definitely buy that!" feels like a commitment. It's not. It's a prediction about future behavior, and humans are terrible at predicting their own future behavior. We're consistently overoptimistic about what we'll do tomorrow.

Hypothetical Maybes: Statements using "might" or "could."

"I could see myself using that" means nothing. "Might" and "could" are escape hatches that let people sound supportive without committing to anything.

The Most Expensive Fluff in History

Fitzpatrick shares a painful story from his own experience that illustrates how costly fluff can be. At his first startup, the team kept hearing "I would definitely buy that!" from potential customers. They interpreted this as validation and pushed forward confidently.

The result? They lost around $10 million building something based on fluffy promises that never materialized into actual purchases.

That story stuck with me. Ten million dollars, gone, because the team couldn't distinguish between "I would buy that" (fluff) and "Here's my credit card" (commitment).

Anchoring: The Antidote to Fluff

The technique Fitzpatrick recommends is what he calls "anchoring." When someone gives you a fluffy answer, you anchor it to a specific moment in the past.

Here's how it works:

You: "Do you ever have trouble managing your tasks?"

Them: "Oh yeah, all the time."

You: "When's the last time that happened?"

Them: "Hmm, actually it was last Tuesday."

You: "Can you walk me through what happened?"

Now you're getting somewhere. Instead of a vague "all the time," you have a specific incident you can explore. You can ask what they tried, how they felt, what it cost them.

The book includes a great example about someone claiming to be an "Inbox Zero zealot." Instead of taking that at face value, the interviewer asked "What's your inbox look like right now?" and "When's the last time it totally fell apart?"

Suddenly the "I always have an empty inbox" claim transformed into "Actually, it blew up three weeks ago when I was traveling and took 10 days to recover." That's real data. That's a pain point you can potentially solve.

Questions That Generate Fluff (Avoid These)

I've started noticing which questions tend to produce useless answers:

"Do you ever...?"
"Would you ever...?"
"What do you usually...?"
"Could you see yourself...?"
"How much would you pay for...?"

These aren't bad questions exactly — sometimes you need to start there. The mistake is treating the answers as meaningful. They're conversation starters, not conclusions.

Trap #3: The Idea Trap

Why Feature Requests Can Destroy Your Product

As developers, we love feature requests. Someone says "You should add Excel export!" and our brains immediately start designing the implementation. We feel productive. We're solving problems!

But Fitzpatrick warns that blindly implementing feature requests is the fast lane to a bloated, unfocused product.

The issue isn't that users' ideas are bad. It's that you don't understand why they want something. Without understanding the underlying motivation, you might:

Build something complex when a simple solution would work
Prioritize a nice-to-have over a must-have
Lose focus on your core value proposition
Create a Frankenstein product that tries to do everything

The MTV Disaster

The book contains a cautionary tale that perfectly illustrates this trap. At Fitzpatrick's startup, they were selling to MTV, which requested "analytics and reports" for their campaigns.

The team did what most of us would do: they took the request at face value and built a sophisticated analytics dashboard. It had tons of options, beautiful visualizations, the works. Technically impressive.

Then something strange happened. MTV kept calling every Friday asking the team to manually export and email them a report. The team added CSV export. MTV still called. They added PDF export. MTV still called. They added branded report templates. MTV still called.

Finally, someone asked the question they should have asked at the beginning: "Why do you need branded reports? What's wrong with the unbranded ones?"

The answer was deflating: MTV's clients expected a nice-looking report emailed to them weekly. That's it. Nobody actually read the reports or used the analytics. They just needed something professional-looking to forward along.

The team had spent months building a complex analytics platform when all MTV needed was a scheduled email with a pretty PDF attachment. An intern could have handled it manually.

All because nobody asked "Why do you want this?"

Digging Beneath the Request

Now when I hear a feature request, I try to understand the motivation before even considering implementation:

"What would that feature allow you to do?"
"How are you solving this problem today?"
"What happens if we don't build this?"
"Is this a dealbreaker, or could we launch without it?"

The book suggests that when someone asks for a specific feature, they've often already jumped to a solution. Your job is to uncover the problem they're trying to solve. There might be a simpler way to address it.

Emotions Are Signals Worth Exploring

One insight I found valuable: strong emotions are goldmines.

If someone seems frustrated, angry, embarrassed, or excited about something, dig into it. Ask:

"Tell me more about that."
"That seems to really bother you — what's the story there?"
"Why hasn't this been solved already?"
"What makes this such a big deal?"

People love talking about their frustrations. You're not being intrusive — you're giving them permission to vent. And in that venting, you'll find real problems worth solving.

The book's rule here: understand feature requests, but don't blindly obey them.

Keeping Your Ego Out of the Room

The Pathos Problem

Here's something uncomfortable I realized about myself: when I share an idea I care about, I'm unconsciously fishing for validation.

Fitzpatrick calls this "The Pathos Problem." When people sense that you're emotionally invested in something, they instinctively want to protect your feelings. Even if you explicitly ask for honest criticism, they'll pull their punches.

It's human nature. If someone says "I quit my job to build this — what do you think?", most people won't respond with brutal honesty. They'll find something nice to say, even if they think the idea is terrible.

The symptoms are subtle:

"I'm thinking of starting a business... do you think it'll work?"
"I had this idea I'm really excited about — do you like it?"
"Be honest, I can take it!"

That last one is particularly insidious. Saying "I can take it" doesn't make people more honest — it just confirms that your ego is on the line, which makes them more likely to be gentle.

The Solution: Make It About Them

The antidote is keeping the focus on the other person's life, problems, and behavior — not on your idea.

Instead of asking "Would you use my product?", ask "How are you dealing with X problem today?"

Instead of pitching your solution, explore their world. What tools do they use? What frustrates them? What have they tried before?

When the conversation is about them rather than you, people have no reason to protect your feelings. They're just describing their reality.

An interesting note from the book: some entrepreneurs like Elon Musk or Gordon Ramsay are famous for demanding harsh feedback. But that works for them precisely because nobody worries about hurting their feelings. For the rest of us, it's better to structure conversations so ego never enters the equation.

When You Accidentally Become a Salesperson

The Pitch Trap

There's another mode that kills learning: getting "pitchy."

You know the feeling. You start explaining your idea, get excited, and suddenly you're five minutes into a monologue while the other person nods politely. You're no longer having a conversation — you're delivering a presentation.

The book points out an irony here. The "won't take no for an answer" attitude that helps founders push through obstacles becomes a liability when you're trying to learn. If you won't let someone express doubt or disinterest, you're just collecting forced compliments.

Signs you've gone pitchy:

"No, no, I don't think you understand..."
"Yes, but it also does THIS!"
The other person has barely spoken for several minutes
You're addressing objections they haven't even raised

Recovering Gracefully

What I appreciate about the book is its acknowledgment that slipping into pitch mode is natural. You're excited about your idea. That's good! Otherwise, you wouldn't be doing this.

The key is catching yourself and course-correcting:

"Sorry — I just realized I've been rambling about my idea. I get excited about this stuff. Can we go back to what you were saying about your workflow?"

If they genuinely want to hear more about your product, offer to explain at the end of the conversation. But protect the learning part first.

The memorable rule: if you're being annoying enough, anyone will eventually say your idea is great just to end the conversation. That's not validation — that's surrender.

The Simplest Rule: Shut Up

Learning Requires Listening

The final lesson from these chapters might be the most important:

You cannot learn while you're talking.

This is hard for me. When someone says something I have a great response to, my instinct is to jump in. If they misunderstand something about my idea, I want to correct them immediately.

But Fitzpatrick argues both impulses are mistakes.

When someone starts explaining their mental model — "So it's kind of like Uber for..." — they're giving you a glimpse into how they think. If you interrupt to "fix" their understanding, you lose that insight. You'll have time to explain later.

Plus, it's just annoying. Nobody likes being cut off, especially when they're trying to help you.

I've started applying a simple test: if I'm talking more than listening, the conversation is failing.

My Personal Cheat Sheet

After processing these chapters, I created a reference sheet for myself:

Questions That Extract Real Data

"How are you dealing with this problem today?"
"When's the last time this happened? Walk me through it."
"What solutions have you tried? Why didn't they work?"
"What does this problem cost you in time/money/frustration?"
"Why do you want that feature? What would it let you do?"

Questions That Produce Garbage

"Would you use something like this?"
"Do you think this is a good idea?"
"How much would you pay?"
"Would you ever...?"

Signs I'm Getting Real Data

✅ I learned something surprising

✅ I can describe their current process in detail

✅ I know what they've tried before and why it failed

✅ I understand their constraints

✅ Even a "no" taught me something useful

Signs I'm Getting Garbage

🚨 I'm doing most of the talking

🚨 I'm hearing lots of compliments

🚨 I feel validated but can't cite specific facts

🚨 I don't know what they're currently using

🚨 They said "I would definitely buy that"

Wrapping Up

These lessons are challenging my instincts as a developer.

When someone describes a problem, I want to immediately architect a solution. When someone compliments my idea, I want to bask in it. When someone suggests a feature, I want to add it to the roadmap.

But the best code in the world is worthless if it solves the wrong problem. And the only way to find the right problem is to have conversations that extract truth rather than validation.

I'm still early in the book, but these principles are already changing how I approach customer conversations:

Compliments are noise — Redirect to behavior and facts
Fluff is dangerous — Anchor everything to specific past events
Ideas need excavation — Understand the "why" before the "what"
Ego invites lies — Keep the focus on their life, not your idea
Talking is failing — Learning happens in the silence

I'll likely write more as I continue through the book. But for now, my main takeaway is this: your customers have the answers. Your job is to ask the right questions and then shut up long enough to hear them.

What about you? Have you fallen into any of these traps when talking to potential customers? I'd love to hear your experiences in the comments.

This post covers lessons from the early chapters of "The Mom Test" by Rob Fitzpatrick. I highly recommend reading the full book if you're serious about building products people actually want.

I've also written a longer, more detailed version of this post on my personal website. If you want to dive deeper into these concepts, feel free to check it out — it's completely free, no sign-up or sign-in required. My goal is simply to learn and share as much as I can.

👉kerempakten.dev

Currently reading: Chapters 1-2 ✅ | More insights coming soon...

Docker for Beginners: Everything I Learned about Images

Ege Pakten — Tue, 30 Dec 2025 19:34:25 +0000

My notes from learning Docker — explained simply for absolute beginners

🐳 This is Part 2 of my Docker series!

In my previous post, I covered the fundamentals:

What is Docker and why use it

Containers vs Virtual Machines

Installing Docker

Images vs Containers

Docker Hub and Registries

Essential commands (pull, run, stop, ps)

Port binding

👉 Read Part 1: Docker for Beginners: A Complete Guide to Containerisation

What You'll Learn in This Post

Now that you understand Docker basics, it's time to build your own images! In this post, I'll cover:

📄 Dockerfile — Writing instructions to create images
🏗️ FROM — Choosing a base image
⚙️ RUN — Installing packages during build
📁 COPY — Adding your files to the image
🌐 Downloading files — Using curl efficiently
🚀 CMD — Setting the startup command
🔧 Overriding commands — Running containers interactively

By the end, you'll be able to create your own custom Docker images from scratch!

📚 Table of Contents

Creating Images with Dockerfile
The FROM Instruction
Building a Dockerfile
Naming Your Image with Tags
The RUN Instruction
COPYing Files into an Image
Downloading Files in Docker
The CMD Instruction
Overriding the Default Start Command
Quick Reference Cheat Sheet

Creating Images with Dockerfile

A Dockerfile is a text file with instructions to build a Docker image.

The Flow

Dockerfile → Build → Docker Image → Run → Container
     📄         🔨        📀          ▶️       📦
   Recipe    Cooking   Frozen Meal   Heat    Hot Meal

The FROM Instruction

Every Dockerfile must start with FROM. It tells Docker what base image to use.

FROM ubuntu
FROM python:3.11
FROM node:18-alpine

With Specific Versions (Recommended)

FROM ubuntu:22.04
FROM python:3.11.4
FROM node:18.17.0-alpine

💡 Always use specific versions in production to avoid unexpected changes!

Why Use a Base Image?

Starting Point	What You Get
`FROM ubuntu`	Empty OS, install everything yourself
`FROM python:3.11`	Python already installed
`FROM node:18`	Node.js already installed
`FROM postgres:15`	Full database ready to use

Building a Dockerfile

The Build Command

docker build .

The . (dot) means "look for Dockerfile in current folder".

What the Dot Means

Command	Where Docker Looks
`docker build .`	Current folder
`docker build ./app`	The `app` subfolder
`docker build ..`	Parent folder

Build Output

$ docker build .

[+] Building 0.1s (5/5) FINISHED
 => [internal] load build definition from Dockerfile
 => => transferring dockerfile: 54B
 => CACHED [1/1] FROM docker.io/library/ubuntu
 => exporting to image
 => => writing image sha256:a67f41b1d127160a7647b6709...

Naming Your Image with Tags

Without a name, your image gets a random ID like sha256:a67f41b1d127... 😅

Use the `-t` Flag

docker build -t my-app .

Add Version Numbers

docker build -t my-app:v1.0 .
docker build -t my-app:v1.1 .
docker build -t my-app:latest .

Real Example

# Build and name it
docker build -t my-python-app:v1 .

# Now you can run it easily
docker run my-python-app:v1

The RUN Instruction

RUN executes commands during the build process.

RUN <shell-command>

Example: Installing Python

FROM ubuntu:22.04
RUN apt-get update
RUN apt-get install -y python3

What Does `apt-get update` Do?

It refreshes the package list (catalog of available software):

Command	What It Does	Analogy
`apt-get update`	Get latest list of packages	Get the restaurant menu
`apt-get install python3`	Install the package	Order from the menu

The `-y` Flag

RUN apt-get install -y python3

-y = "Yes to all prompts"

Without it, Docker would wait for you to type "Y" (which you can't do during build!).

Combine Commands for Smaller Images

# ❌ BAD - Creates 3 layers
RUN apt-get update
RUN apt-get install -y python3
RUN apt-get install -y curl

# ✅ GOOD - Creates 1 layer
RUN apt-get update && apt-get install -y python3 curl

COPYing Files into an Image

COPY takes files from your computer and puts them inside the image.

COPY <source-on-computer> <destination-in-image>

Copy a Single File

COPY app.py /app/app.py

Copy to Folder (Keeps Same Name)

COPY app.py /app/
# Result: /app/app.py

Copy Entire Folder

COPY src/ /app/
# Copies everything in src/ to /app/

⚠️ Important Rule: No Parent Directory Access

# ❌ This will FAIL
COPY ../secret-file.txt /app/

# Docker can't access files ABOVE the Dockerfile location (security!)

Visual Example

Your Computer:              Inside Image:
my-project/                 /app/
├── Dockerfile              ├── main.py
├── main.py      ─COPY→     ├── utils.py
└── utils.py                └── config.py

Downloading Files in Docker

Instead of COPY, you can download files from the internet:

Three Steps

# 1. Download
RUN curl https://example.com/file.zip -o /tmp/file.zip

# 2. Unzip
RUN unzip /tmp/file.zip -d /app/

# 3. Remove zip (cleanup)
RUN rm /tmp/file.zip

⚡ Efficient Way (Single Instruction)

Each RUN creates a layer. Even deleted files add to image size!

# ❌ BAD - 3 layers, zip still counts toward size
RUN curl https://example.com/file.zip -o /tmp/file.zip
RUN unzip /tmp/file.zip -d /app/
RUN rm /tmp/file.zip

# ✅ GOOD - 1 layer, zip deleted before layer saves
RUN curl https://example.com/file.zip -o /tmp/file.zip \
    && unzip /tmp/file.zip -d /app/ \
    && rm /tmp/file.zip

What Does `&&` Mean?

&& = "then do this" (runs next command only if previous succeeded)

What Does `\` Mean?

\ = "continue on next line" (makes long commands readable)

The CMD Instruction

CMD tells Docker what command to run when the container starts.

CMD <shell-command>

RUN vs CMD

Instruction	When It Runs	Purpose
`RUN`	During build	Install software, setup
`CMD`	At startup	Start your application

Examples

# Run a Python script
CMD python3 app.py

# Start a web server
CMD npm start

# Run a shell script
CMD ./start.sh

Key Points About CMD

Only the LAST CMD counts (if you have multiple)
Does NOT increase image size
Does NOT add time to build

Complete Example

FROM python:3.11
COPY app.py /app/
WORKDIR /app
CMD python3 app.py

When you run this:

docker run my-app
# Automatically executes: python3 app.py

Overriding the Default Start Command

You can replace the CMD when running a container:

Default (Uses CMD)

docker run my-image
# Runs whatever CMD is in the Dockerfile

Override with Your Command

docker run my-image echo "Hello!"
# Ignores CMD, runs "echo Hello!" instead

Interactive Mode

docker run -it ubuntu bash

Flag	Meaning
`-i`	Interactive - keeps input open
`-t`	Terminal - shows proper console

This opens a shell inside the container:

$ docker run -it ubuntu bash
root@abc123:/# ls
bin  boot  dev  etc  home  lib  ...

root@abc123:/# echo "I'm inside the container!"
I'm inside the container!

root@abc123:/# exit
$

When to Use Override?

Use Case	Command
Debug inside container	`docker run -it my-image bash`
Run different script	`docker run my-image python3 other.py`
Check files inside	`docker run my-image ls /app`

Quick Reference Cheat Sheet

Dockerfile Instructions

Instruction	Purpose	Example
`FROM`	Base image	`FROM ubuntu:22.04`
`RUN`	Run command during build	`RUN apt-get install -y python3`
`COPY`	Copy files into image	`COPY app.py /app/`
`CMD`	Command to run at startup	`CMD python3 app.py`
`WORKDIR`	Set working directory	`WORKDIR /app`

Docker CLI Commands

Command	What It Does
`docker build -t name .`	Build image from Dockerfile
`docker run image`	Run a container
`docker run -it image bash`	Run with interactive shell
`docker images`	List all images
`docker ps`	List running containers
`docker pull image:tag`	Download an image

Example Dockerfile

# Start from Python base image
FROM python:3.11-slim

# Set working directory
WORKDIR /app

# Copy requirements first (for caching)
COPY requirements.txt .

# Install dependencies
RUN pip install -r requirements.txt

# Copy application code
COPY . .

# Command to run at startup
CMD ["python", "app.py"]

Build and Run

# Build the image
docker build -t my-python-app:v1 .

# Run the container
docker run my-python-app:v1

# Run with interactive shell (for debugging)
docker run -it my-python-app:v1 bash

Summary

Today I learned:

✅ Dockerfile is a recipe for building images

✅ FROM sets the base image (always first!)

✅ RUN executes commands during build

✅ COPY puts files from your computer into the image

✅ CMD runs when the container starts

✅ docker build -t name . builds and names your image

✅ docker run -it image bash lets you explore inside a container

✅ Use && to combine commands for smaller images

📬 Keep Learning With Me!

I'm documenting my learning journey in public. If you found this helpful, check out my blog for more tutorials:

👉 kerempakten.dev

You'll find:

🐳 DevOps & Cloud tutorials
💻 Project breakdowns & real code
🎯 Career tips for new graduates
📝 Honest "building in public" updates

I'm a recent Computer Science graduate from King's College London, learning and sharing everything along the way. No gatekeeping — just practical knowledge for beginners like us!

Let's connect and learn together! 🚀

Found an error or have a suggestion? Drop a comment below!

Claude Code in Terminal: A Beginner's Guide to 10x Faster Development

Ege Pakten — Sun, 28 Dec 2025 17:33:35 +0000

A beginner's guide to supercharging your development workflow with Claude Code

This space is for beginners and new grads who want practical, no-nonsense tutorials. Explore more posts at kerempakten.dev!

📚 Table of Contents

What is Claude Code?
Why Use Claude in Terminal?
Getting Started
Essential Commands You Need to Know
- /help — Your Starting Point
- /add — Add Files to Context
- /ls — Check What Claude Sees
- /clear — Fresh Start
- /code — Write and Edit Code
- /architect — Plan Before Building
- /review — Code Review
- /test — Generate Tests
- /debug — Fix Bugs
- /git — Smart Git Operations
Real Workflow Examples
Command Cheat Sheet
Level Up: Community Resources
Summary

What is Claude Code?

Claude Code is a CLI-based AI coding assistant that lives in your terminal. Instead of switching between your browser and IDE, you can have Claude help you directly where you code.

What's CLI? CLI stands for Command Line Interface — it's the text-based terminal/console where you type commands instead of clicking buttons. On Mac it's called Terminal, on Windows it's Command Prompt or PowerShell. If you've ever typed npm install or git push, you've used a CLI!

Think of it as having a senior developer sitting next to you, ready to help with anything — writing code, debugging, reviewing, planning features, and even committing to Git.

Why Use Claude in Terminal?

Browser Claude	Terminal Claude Code
Copy-paste code back and forth	Works directly with your files
Can't see your project structure	Sees your entire codebase
Manual file management	Creates/edits files automatically
Separate from your workflow	Integrated into your workflow

Bottom line: Terminal Claude Code is 10x faster for actual development work.

Getting Started

Installation

# Install Claude Code globally
npm install -g @anthropic-ai/claude-code

# Navigate to your project
cd your-project

# Start Claude Code
claude

First Command: `/init`

> /init

This creates a CLAUDE.md file in your project root. This file is extremely important!

Why CLAUDE.md Matters

The CLAUDE.md file is like a briefing document for Claude. Every time you start Claude Code, it reads this file first to understand your project. Think of it as onboarding a new developer — you'd tell them about your tech stack, coding conventions, and project structure.

Without CLAUDE.md: Claude guesses how your project works.

With CLAUDE.md: Claude knows exactly how to help you.

What to Include in CLAUDE.md

# Project: My Portfolio Website

## Tech Stack
- React 18 with TypeScript
- Tailwind CSS for styling
- Supabase for backend
- Vite for bundling

## Project Structure
- `/src/components` - React components
- `/src/pages` - Page components
- `/src/lib` - Utility functions
- `/supabase/functions` - Edge functions

## Coding Conventions
- Use functional components with hooks
- Use TypeScript strict mode
- Use Tailwind classes, no CSS files
- Name components in PascalCase
- Name utilities in camelCase

## Commands
- `npm run dev` - Start development server
- `npm run build` - Build for production
- `npm run test` - Run tests

## Important Notes
- Always use environment variables for API keys
- Supabase client is in `/src/lib/supabase.ts`
- Don't modify files in `/src/generated`

Key Benefits

Without CLAUDE.md	With CLAUDE.md
Claude might use wrong styling approach	Claude uses Tailwind as specified
Claude might create files in wrong folders	Claude follows your structure
Claude might use different naming conventions	Claude matches your style
You repeat context every conversation	Claude remembers your preferences

You Can Edit It Anytime!

The CLAUDE.md file is 100% yours to customize. As your project grows, update it.

💡 Pro tip: The more specific your CLAUDE.md, the better Claude understands your project. Spend 10 minutes setting it up properly — it saves hours later!

Essential Commands You Need to Know

1. `/help` — Your Starting Point

> /help

Shows all available commands. Start here!

2. `/add` — Add Files to Context

Claude can only see files you explicitly add:

# Add a single file
> /add src/components/Header.tsx

# Add multiple files
> /add src/App.tsx src/index.tsx

# Add entire directory
> /add src/components

# Add with pattern
> /add src/**/*.tsx

Why This Matters

When you start Claude Code, it can't see any of your project files by default. It's like asking someone to fix your code without showing them the code!

Example — Wrong way:

> Why is my Header component not rendering properly?

# ❌ Claude has no idea what's in your Header component
# It will give generic advice that might not apply to your code

Example — Right way:

> /add src/components/Header.tsx
> /add src/App.tsx
> Why is my Header component not rendering properly?

# ✅ Claude can now SEE your actual code
# It will give specific advice based on YOUR files

Think of it Like This

Scenario	Real Life Equivalent
Asking Claude without `/add`	Asking a mechanic to fix your car over the phone without seeing it
Asking Claude with `/add`	Bringing your car to the mechanic so they can look under the hood

💡 Rule of thumb: Before asking any question about your code, always /add the relevant files first. Use /ls to double-check what Claude can see.

3. `/ls` — Check What Claude Sees

> /ls

This command lists all files currently in Claude's context (memory).

Example output:

> /ls

Files in context:
  src/App.tsx
  src/components/Header.tsx
  src/utils/api.ts

Total: 3 files

Why Use `/ls`?

After adding multiple files, you might forget what Claude can see. Before asking a question, run /ls to verify:

> /add src/components/Header.tsx
> /add src/components/Footer.tsx
> /add src/utils/helpers.ts

# Wait, what did I add again?
> /ls

# Now you can confirm Claude has the right files before asking your question

💡 Quick check: If Claude gives a weird answer, run /ls — you might have forgotten to add the relevant file!

4. `/clear` — Fresh Start

> /clear

This command removes all files from Claude's context and starts fresh.

When to Use `/clear`

Situation	Why Clear?
Finished one task, starting another	Old files might confuse Claude
Context getting too large	Too many files = slower + confused responses
Claude giving irrelevant answers	Might be referencing wrong files
Switching between projects	Don't mix files from different projects

Example workflow:

# Working on Header component
> /add src/components/Header.tsx
> /code Fix the navigation menu
> /code Add mobile responsive styles

# Done with Header! Now working on Footer
> /clear

# Fresh start for new task
> /add src/components/Footer.tsx
> /code Add social media links

What Happens If You Don't Clear?

# Added Header files earlier...
> /add src/components/Header.tsx

# Now asking about Footer without clearing
> /code Fix the Footer styling

# ❌ Claude might accidentally reference Header.tsx
# or get confused about which component you mean

💡 Good habit: When you switch tasks, run /clear first. It takes 1 second and prevents confusion!

5. `/code` — Write and Edit Code

This is the most powerful command — it tells Claude to actually write or modify code.

# Create new component
> /code Create a Button component with TypeScript and Tailwind

# Edit existing file (add it first!)
> /add src/App.tsx
> /code Add a dark mode toggle to the header

# Refactor
> /add src/components/OldComponent.tsx
> /code Refactor this to use React hooks instead of class component

How It Works

Creating new files: Just describe what you want — Claude creates the file automatically

> /code Create a useAuth hook for handling authentication

# Claude creates: src/hooks/useAuth.ts (or similar)
# with full implementation!

Editing existing files: Add the file first, then describe changes

> /add src/components/LoginForm.tsx
> /code Add email validation that checks for @ symbol

# Claude modifies your actual LoginForm.tsx file
# You'll see the changes in your editor immediately

Refactoring: Add the file, describe what you want improved

> /add src/utils/api.ts
> /code Refactor to use async/await instead of .then() chains

# Claude rewrites the code following best practices

Be Specific = Better Results

Vague Request	Specific Request
`/code Make a button`	`/code Create a Button component with TypeScript, Tailwind, loading state, and disabled prop`
`/code Fix this`	`/code Fix the form submission - it's not sending data to the API`
`/code Improve this code`	`/code Add error handling and loading states to this API call`

Example — Vague vs Specific:

# ❌ Vague
> /code Add a form

# ✅ Specific
> /code Create a contact form with:
> - Name field (required)
> - Email field (required, validated)
> - Message textarea (required, min 10 characters)
> - Submit button with loading state
> - Error messages shown below each field
> - Success toast notification on submit

💡 The more detail you give, the better the result. Treat it like explaining to a junior developer exactly what you want built.

6. `/architect` — Plan Before Building

> /architect How should I structure user authentication?

This command asks Claude to think and plan before writing any code. It's like consulting a senior developer about the best approach.

What Claude Provides

When you use /architect, Claude will give you:

File structure — What files to create and where
Design patterns — Best practices for your use case
Implementation steps — Ordered list of what to build first
Trade-offs — Pros and cons of different approaches

Example:

> /architect How should I build a shopping cart feature?

# Claude responds with something like:

# 📁 Suggested Structure:
# src/
#   components/
#     cart/
#       Cart.tsx
#       CartItem.tsx
#       CartSummary.tsx
#   hooks/
#     useCart.ts
#   context/
#     CartContext.tsx
#   types/
#     cart.ts
#
# 🔨 Implementation Order:
# 1. Create cart types (cart.ts)
# 2. Build CartContext for state management
# 3. Create useCart hook for easy access
# 4. Build UI components
#
# ⚖️ Recommendation:
# Use React Context for cart state since it needs to be
# accessed across multiple components...

When to Use `/architect`

✅ Use `/architect` for	❌ Don't need it for
Authentication system	Adding a button
Database schema design	Fixing a typo
API structure	Changing colors
Multi-component features	Simple bug fixes
State management setup	One-file changes

Architect → Then Build

# Step 1: Plan
> /architect How should I implement dark mode?

# Step 2: Review Claude's plan, ask follow-up questions
> What about system preference detection?

# Step 3: Once happy with plan, build it
> /code Implement dark mode following the plan above

💡 Save hours of refactoring: 10 minutes of planning with /architect can save you from rebuilding a feature that was poorly structured from the start.

7. `/review` — Code Review

> /add src/components/PaymentForm.tsx
> /review

This command asks Claude to review your code like a senior developer would in a pull request.

What Claude Checks

Category	What It Looks For
🐛 Bugs	Logic errors, edge cases, null checks
🔒 Security	XSS vulnerabilities, exposed secrets, SQL injection
⚡ Performance	Unnecessary re-renders, memory leaks, slow operations
📖 Readability	Confusing code, missing comments, poor naming
🏗️ Best Practices	React patterns, TypeScript usage, code structure

Example output:

> /add src/components/PaymentForm.tsx
> /review

# Claude responds:

# 🔴 Critical Issues:
# - Line 23: Credit card number is logged to console (security risk!)
# - Line 45: No error handling for API call
#
# 🟡 Warnings:
# - Line 12: useEffect missing dependency array (could cause infinite loop)
# - Line 34: Consider using useMemo for expensive calculation
#
# 🟢 Suggestions:
# - Line 8: Variable name 'x' is unclear, consider 'cardNumber'
# - Consider splitting this into smaller components
#
# Overall: 3 critical issues need fixing before commit

Review Workflow

# Before committing any code:

# 1. Add files you changed
> /add src/components/PaymentForm.tsx
> /add src/hooks/usePayment.ts

# 2. Run review
> /review

# 3. Fix issues Claude found
> /code Fix the security issue on line 23

# 4. Review again to confirm
> /review

# 5. Now safe to commit!
> /git commit

💡 Catch bugs before users do: Always run /review before pushing code. It's like having a free senior developer check your work!

8. `/test` — Generate Tests

> /add src/utils/validators.ts
> /test Write unit tests for validators

This command asks Claude to automatically create test files for your code.

What Claude Creates

> /add src/utils/validators.ts
> /test Write unit tests for validators

# Claude creates: src/utils/validators.test.ts
# with tests like:

# ✅ validates correct email format
# ✅ rejects email without @ symbol
# ✅ rejects empty email
# ✅ validates phone number with country code
# ✅ rejects phone number that's too short
# ... and more

Different Types of Tests

# Unit tests (test one function)
> /add src/utils/formatDate.ts
> /test Write unit tests for formatDate

# Component tests (test React component)
> /add src/components/Button.tsx
> /test Write tests for Button component

# Integration tests (test multiple things together)
> /add src/components/LoginForm.tsx
> /add src/hooks/useAuth.ts
> /test Write integration tests for the login flow

# Specific scenarios
> /add src/utils/cart.ts
> /test Write tests for edge cases: empty cart, max quantity, negative prices

Be Specific About What to Test

# ❌ Vague
> /test Write tests

# ✅ Specific
> /test Write tests covering:
> - Valid inputs
> - Invalid inputs (empty, wrong format)
> - Edge cases (very long strings, special characters)
> - Error handling

💡 No excuses for no tests: Test writing is tedious, but now Claude does it for you. Use /test on every new function or component!

9. `/debug` — Fix Bugs

> /add src/components/LoginForm.tsx
> /debug Form submission isn't working, getting undefined error

This command asks Claude to analyze your code and find the bug — like having a detective investigate the crime scene.

How to Use `/debug` Effectively

Step 1: Add the relevant files

# Add the file with the bug
> /add src/components/LoginForm.tsx

# Add related files if needed
> /add src/hooks/useAuth.ts
> /add src/utils/api.ts

Step 2: Describe the problem clearly

# ❌ Vague
> /debug It's broken

# ✅ Specific
> /debug Form submission fails with "undefined" error.
> - Happens when I click Submit
> - Console shows: "Cannot read property 'email' of undefined"
> - Started happening after I added validation

Step 3: Include error messages

> /debug Getting this error when users try to login:

TypeError: Cannot read property 'user' of undefined
    at LoginForm.tsx:45
    at handleSubmit (LoginForm.tsx:23)

What Claude Does

Step	What Happens
1️⃣	Reads your code files
2️⃣	Analyzes the error message
3️⃣	Traces the problem to its source
4️⃣	Explains WHY it's broken
5️⃣	Shows you exactly how to fix it

Example:

> /debug Getting "undefined" when submitting the form

# Claude responds:

# 🔍 Found the issue!
#
# Problem: On line 23, you're accessing `formData.email`
# but `formData` is undefined because the useState
# initial value is missing.
#
# Line 23 (current):
#   const email = formData.email
#
# The issue: useState() on line 8 has no initial value
#   const [formData, setFormData] = useState()
#
# Fix: Add initial state
#   const [formData, setFormData] = useState({ email: '', password: '' })
#
# Want me to apply this fix?

💡 Save hours of debugging: Instead of console.log everywhere, just tell Claude the symptoms and paste the error. It's like having a debugging superpower!

10. `/git` — Smart Git Operations

# Check status
> /git status

# Commit with AI-generated message
> /git commit

# See changes
> /git diff

This command lets Claude handle Git operations for you — including writing commit messages!

Available Git Commands

Command	What It Does
`/git status`	Shows changed files (like `git status`)
`/git diff`	Shows what you changed in each file
`/git commit`	Commits with AI-written message
`/git branch`	Shows or creates branches
`/git log`	Shows recent commits

The Magic: AI Commit Messages

This is the best part — Claude reads your changes and writes the commit message for you:

> /git commit

# Claude analyzes your changes and suggests:

# "feat: Add email validation to login form
#
# - Add regex validation for email format
# - Show error message below input field
# - Disable submit button for invalid email
# - Add unit tests for validation function"
#
# Commit with this message? (y/n)

Why This Is Amazing

# ❌ Your commit messages
git commit -m "fix stuff"
git commit -m "update"
git commit -m "wip"
git commit -m "asdfasdf"

# ✅ Claude's commit messages
git commit -m "fix: Resolve null pointer exception in user authentication"
git commit -m "feat: Add dark mode toggle with system preference detection"
git commit -m "refactor: Extract validation logic into custom useValidation hook"

Full Git Workflow

# 1. Check what you've changed
> /git status

# 2. See the actual changes
> /git diff

# 3. Review your code before committing
> /add src/components/Header.tsx
> /review

# 4. Fix any issues
> /code Fix the issue found in review

# 5. Commit with smart message
> /git commit

# Done! Professional commit message without thinking about it

💡 Never write "fix stuff" again: Let Claude write your commit messages. Your Git history will look professional, and future you will thank present you when debugging!

Real Workflow Examples

Starting a New Feature

# 1. Plan first
> /architect How should I build a user profile page?

# 2. Create the structure
> /code Create UserProfile component based on the plan

# 3. Add files for further work
> /add src/components/UserProfile.tsx

# 4. Implement details
> /code Add avatar upload functionality

# 5. Write tests
> /test Write tests for UserProfile

# 6. Review before committing
> /review

# 7. Commit with smart message
> /git commit

Fixing a Bug

# 1. Add the buggy file
> /add src/components/LoginForm.tsx

# 2. Describe the issue
> /debug Login button doesn't respond after first click

# 3. Apply the fix
> /code Fix the bug as suggested

# 4. Add regression test
> /test Add test to prevent this bug

# 5. Commit
> /git commit

Command Cheat Sheet

SETUP
/init              Create CLAUDE.md for your project
/help              See all commands

CONTEXT MANAGEMENT
/add <file>        Add files to context
/drop <file>       Remove specific files
/clear             Clear all context
/ls                List current files

CODE OPERATIONS
/code              Write or edit code
/architect         Plan architecture
/review            Review code quality
/debug             Fix bugs
/test              Generate tests
/docs              Generate documentation

GIT
/git status        Check status
/git commit        Smart commit message
/git diff          See changes

SHORTCUTS
Tab                Accept suggestion
Ctrl+C             Cancel operation
Esc                Close modal

Level Up: Community Resources

The Claude Code community is incredibly active. Here are two resources I highly recommend:

1. Awesome Claude Code

📦 github.com/hesreallyhim/awesome-claude-code

A curated collection of:

Slash commands
CLAUDE.md templates
CLI tools
Workflows
Productivity tips

This repo is updated daily by the community. If you can't find a command or workflow you need, check here first. It has 18k+ stars and is the go-to resource for Claude Code users.

What you'll find:

Battle-tested slash commands
CLAUDE.md setups for different project types
Tutorials and guides
CLI tools and integrations

2. Superpowers — My Favourite Plugin 🦸

📦 github.com/obra/superpowers

Superpowers transforms Claude Code from a coding assistant into a complete software development workflow. Created by Jesse Vincent, it's a collection of "skills" that teach Claude professional engineering practices.

What Makes Superpowers Special?

Instead of Claude jumping straight into writing code, Superpowers makes it:

Ask what you're really trying to do — Clarifies requirements first
Create a proper spec — In digestible chunks you can review
Build an implementation plan — Clear enough for any developer to follow
Execute with subagents — Multiple agents work through tasks systematically
Review between tasks — Catches issues before they compound

It emphasizes TDD (Test-Driven Development), YAGNI, and DRY principles.

Installing Superpowers

# In Claude Code terminal:

# 1. Add the marketplace
/plugin marketplace add obra/superpowers-marketplace

# 2. Install Superpowers
/plugin install superpowers@superpowers-marketplace

# 3. Restart Claude Code
# Then check it's working:
/help

# You should see:
# /superpowers:brainstorm - Interactive design refinement
# /superpowers:write-plan - Create implementation plan
# /superpowers:execute-plan - Execute plan in batches

Using Superpowers

# 1. Brainstorm your feature
/superpowers:brainstorm

# Claude will ask clarifying questions, explore alternatives,
# and present the design in sections for you to validate

# 2. Create implementation plan
/superpowers:write-plan

# Creates a detailed plan with tasks clear enough for
# "an enthusiastic junior engineer" to follow

# 3. Execute the plan
/superpowers:execute-plan

# Launches subagent-driven development
# Claude can work autonomously for hours following the plan!

Skills That Activate Automatically

Superpowers includes skills that trigger when relevant:

Skill	When It Activates
`test-driven-development`	When implementing features
`systematic-debugging`	When debugging issues
`requesting-code-review`	Between tasks
`using-git-worktrees`	After design approval
`finishing-a-development-branch`	When tasks complete

You don't need to do anything special — Claude just gains these superpowers! 🦸

Summary

Claude Code in the terminal is a game-changer for development speed:

Command	What It Does
`/add`	Add files to context
`/code`	Write and edit code
`/architect`	Plan features
`/review`	Check code quality
`/test`	Generate tests
`/git commit`	Smart commits
`/clear`	Reset context

Resources to bookmark:

📚 Awesome Claude Code — Commands, workflows, updated daily
🦸 Superpowers — Professional development workflow plugin

Master these commands and you'll be 10x more productive. Start with /help, then practice with /add, /code, and /review — these three alone will transform your workflow!

📬 Join the Journey!

Found this helpful? I'm building this blog for beginners and new grads like us to learn and grow together.

👉 Subscribe at kerempakten.dev for more tutorials!

You'll find:

🛠️ DevOps & Cloud tutorials
💻 Project breakdowns & real code
🎯 Career tips for new graduates
📝 Honest "building in public" updates

Let's learn together!

Last updated: December 2025

Connect with me: kerempakten.dev

Docker for Beginners: A Complete Guide to Containerisation

Ege Pakten — Fri, 26 Dec 2025 18:14:46 +0000

🚀 This space is for **beginners and new grads who want practical, no-nonsense tutorials. Explore more posts, project breakdowns, and my learning journey at kerempakten.dev!

📚 Table of Contents

What is Docker?
What Problems Does Docker Solve?
Virtual Machines vs Docker
Installing Docker
Docker Images vs Containers
Docker Registries
Docker Image Versions (Tags)
Essential Docker Commands
Port Binding
Starting and Stopping Containers
Private Docker Registries
Registry vs Repository
Dockerfile - Dockerizing Your App
Building Your Own Image
Docker in the Software Development Lifecycle
Where to Go From Here

What is Docker?

Docker is a containerization platform that allows you to package your application along with all its dependencies into a standardized unit called a container.

Think of it like this: Imagine you're moving to a new house. Instead of packing each item separately and hoping everything arrives intact, you put everything into a shipping container. That container can be moved anywhere in the world, and when you open it, everything is exactly as you packed it.

Docker does the same thing for software! 📦

Key Concept

A container is a lightweight, standalone, executable package that includes everything needed to run a piece of software: code, runtime, system tools, libraries, and settings.

What Problems Does Docker Solve?

The "It Works on My Machine" Problem 😅

If you've ever worked in a development team, you've probably heard (or said) this phrase. Here's a typical scenario:

Without Docker:

Developer A: "The app works perfectly on my laptop!"
Developer B: "It's crashing on mine..."
Developer A: "What version of Node are you running?"
Developer B: "Node? I thought this was a Python project..."

This happens because different machines have:

Different operating systems
Different versions of programming languages
Different installed libraries
Different environment configurations

How Docker Solves This

With Docker, you define your application's environment once in a configuration file. Everyone who runs your container gets the exact same environment.

Developer A: "Here's the Docker container"
Developer B: "It works perfectly!" ✅
Developer C: "It works perfectly!" ✅
Production Server: "It works perfectly!" ✅

The Deployment Nightmare

Traditional Deployment:

1. Set up server
2. Install correct OS version
3. Install correct Node.js version
4. Install correct MongoDB version
5. Install correct Redis version
6. Configure environment variables
7. Configure networking
8. Cross fingers and pray 🤞
9. Debug for 3 hours when something breaks

Docker Deployment:

1. Install Docker on server
2. Run: docker-compose up
3. Done ✅

Real-World Example

Let's say you're building a web application that needs:

Node.js v18
MongoDB 6.0
Redis 7.0
Specific npm packages

Without Docker:

Each developer must install all these manually
Version conflicts are common
"But I have MongoDB 5.0 installed for another project!"

With Docker:

Run one command, everything spins up
Each project has its own isolated environment
No conflicts between projects

Virtual Machines vs Docker

This is one of the most important concepts to understand!

Virtual Machines (VMs)

A VM is like having a separate computer inside your computer. It includes:

Full operating system (Windows, Linux, etc.)
Virtual hardware (CPU, RAM, disk)
All system files

┌─────────────────────────────────────────┐
│              Your Computer              │
├─────────────────────────────────────────┤
│              Host OS (Windows)          │
├─────────────────────────────────────────┤
│              Hypervisor                 │
├───────────────┬───────────────┬─────────┤
│     VM 1      │     VM 2      │  VM 3   │
├───────────────┼───────────────┼─────────┤
│  Guest OS     │  Guest OS     │ Guest OS│
│  (Ubuntu)     │  (CentOS)     │ (Debian)│
├───────────────┼───────────────┼─────────┤
│  Your App     │  Your App     │ Your App│
└───────────────┴───────────────┴─────────┘

Problem: Each VM needs its own OS, which means:

Takes up GBs of disk space
Uses significant RAM
Slow to start (minutes)
Resource heavy

Docker Containers

Containers share the host OS kernel and only include what's necessary for your app:

┌─────────────────────────────────────────┐
│              Your Computer              │
├─────────────────────────────────────────┤
│              Host OS (Linux)            │
├─────────────────────────────────────────┤
│              Docker Engine              │
├───────────────┬───────────────┬─────────┤
│  Container 1  │  Container 2  │Container│
├───────────────┼───────────────┼─────────┤
│  Your App     │  Your App     │Your App │
│  + Deps only  │  + Deps only  │+ Deps   │
└───────────────┴───────────────┴─────────┘

Comparison Table

Feature	Virtual Machine	Docker Container
Size	GBs	MBs
Startup Time	Minutes	Seconds
Performance	Slower (full OS overhead)	Near-native
Isolation	Complete (separate OS)	Process-level
Resource Usage	High	Low
Portability	Limited	Excellent

When to Use What?

Use VMs when:

You need complete isolation
You need to run different operating systems
Security is critical (separate kernels)

Use Docker when:

You need lightweight, fast deployments
You're deploying microservices
You want consistent environments
You need to scale quickly

Installing Docker

Docker is available for all major operating systems.

For Mac

Download Docker Desktop for Mac
Open the .dmg file
Drag Docker to Applications
Open Docker from Applications
Verify installation:

docker --version
# Output: Docker version 24.x.x, build xxxxx

For Windows

Download Docker Desktop for Windows
Run the installer
Enable WSL 2 (Windows Subsystem for Linux) if prompted
Restart your computer
Verify installation:

docker --version

For Linux (Ubuntu/Debian)

# Update package index
sudo apt-get update

# Install prerequisites
sudo apt-get install ca-certificates curl gnupg

# Add Docker's official GPG key
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Set up the repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Install Docker
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Verify installation
docker --version

Post-Installation (Linux)

To run Docker without sudo:

sudo groupadd docker
sudo usermod -aG docker $USER
# Log out and back in

Docker Images vs Containers

This is crucial to understand! Many beginners confuse these two concepts.

Docker Image 📀

An image is a read-only template containing:

Application code
Runtime environment
Libraries and dependencies
Environment variables
Configuration files

Think of it as a recipe or a blueprint.

Docker Container 📦

A container is a running instance of an image. It's the actual application running in isolation.

Think of it as the actual dish made from the recipe.

Analogy: Class vs Object

If you're familiar with programming:

// Image = Class (the blueprint)
class Car {
  constructor(color) {
    this.color = color;
  }
}

// Container = Object (the instance)
const myCar = new Car('red');    // Container 1
const yourCar = new Car('blue'); // Container 2

Visual Representation

┌─────────────────────────────────────────┐
│            Docker Image                 │
│         (node:18-alpine)                │
│                                         │
│  - Node.js v18                          │
│  - npm                                  │
│  - Alpine Linux base                    │
│                                         │
│         READ-ONLY TEMPLATE              │
└─────────────────────────────────────────┘
                    │
                    │ docker run
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
┌───────────────┐       ┌───────────────┐
│  Container 1  │       │  Container 2  │
│  (Running)    │       │  (Running)    │
│               │       │               │
│  App Instance │       │  App Instance │
│  Port 3000    │       │  Port 3001    │
└───────────────┘       └───────────────┘

Key Points

You can create many containers from one image
Containers are isolated from each other
Changes in a container don't affect the image
When a container is deleted, its data is lost (unless using volumes)

Docker Registries

A Docker Registry is like GitHub but for Docker images. It's a storage and distribution system for Docker images.

Docker Hub

Docker Hub is the default public registry. It contains:

Official Images: Maintained by Docker (nginx, node, postgres, etc.)
Verified Publisher Images: From trusted companies (Microsoft, Oracle, etc.)
Community Images: Created by anyone

How It Works

┌─────────────┐     docker push     ┌─────────────────┐
│  Your       │ ─────────────────►  │  Docker Hub     │
│  Computer   │                     │  (Registry)     │
│             │ ◄─────────────────  │                 │
└─────────────┘     docker pull     └─────────────────┘

Finding Images

# Search for images
docker search nginx

# Or browse Docker Hub website
# https://hub.docker.com/

Popular Official Images

Image	Description	Pull Command
nginx	Web server	`docker pull nginx`
node	Node.js runtime	`docker pull node`
postgres	PostgreSQL database	`docker pull postgres`
redis	In-memory data store	`docker pull redis`
mongo	MongoDB database	`docker pull mongo`
python	Python runtime	`docker pull python`

Docker Image Versions (Tags)

Images come in different versions, managed through tags.

Understanding Tags

image_name:tag

Examples:
node:18          # Node.js version 18
node:18-alpine   # Node.js 18 on Alpine Linux (smaller)
node:latest      # Latest version (default)
node:lts         # Long Term Support version

Why Tags Matter

# This might break your app in the future!
docker pull node:latest

# This is predictable and safe
docker pull node:18.17.0

Best Practices

✅ DO:

# Use specific versions in production
docker pull node:18.17.0-alpine
docker pull postgres:15.3

❌ DON'T:

# Avoid 'latest' in production
docker pull node:latest  # Could be v18 today, v20 tomorrow!

Common Tag Patterns

Tag	Meaning
`18`	Major version only
`18.17`	Major + minor version
`18.17.0`	Exact version (most precise)
`alpine`	Minimal Alpine Linux base (~5MB)
`slim`	Reduced Debian image
`bullseye`	Based on Debian Bullseye

Essential Docker Commands

Let's learn the commands you'll use daily!

Pulling Images

# Pull an image from Docker Hub
docker pull nginx

# Pull specific version
docker pull nginx:1.25

# Pull from different registry
docker pull gcr.io/google-samples/hello-app:1.0

Running Containers

# Basic run (foreground)
docker run nginx

# Run in background not on terminal (-d = detached)
docker run -d nginx

# Run with a custom name
docker run -d --name my-nginx nginx

# Run and remove when stopped
docker run --rm nginx

Listing Containers & Images

# List running containers
docker ps

# List ALL containers (including stopped)
docker ps -a

# List images
docker images

# List images with details
docker images -a

Example Output

$ docker ps
CONTAINER ID   IMAGE   COMMAND                  STATUS          PORTS     NAMES
a1b2c3d4e5f6   nginx   "/docker-entrypoint.…"   Up 2 minutes   80/tcp    my-nginx

$ docker images
REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
nginx        latest    a1b2c3d4e5f6   2 weeks ago    142MB
node         18        b2c3d4e5f6a7   3 weeks ago    991MB

Port Binding

By default, containers are isolated. To access a containerized app from your host machine, you need port binding.

The Problem

┌─────────────────┐      ┌─────────────────┐
│  Your Browser   │  ✗   │   Container     │
│  localhost:80   │ ───► │   nginx:80      │
└─────────────────┘      └─────────────────┘
          Can't connect! Container is isolated.

The Solution: Port Binding

# Syntax: -p HOST_PORT:CONTAINER_PORT
docker run -d -p 8080:80 nginx

┌─────────────────┐      ┌─────────────────┐
│  Your Browser   │  ✓   │   Container     │
│  localhost:8080 │ ───► │   nginx:80      │
└─────────────────┘      └─────────────────┘
          Port 8080 on host maps to port 80 in container

Multiple Port Bindings

# Bind multiple ports
docker run -d -p 8080:80 -p 8443:443 nginx

# Random host port
docker run -d -p 80 nginx  # Docker assigns random host port

Real-World Example

# Run PostgreSQL with port binding
docker run -d \
  --name my-postgres \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=mysecretpassword \
  postgres:15

Now you can connect to PostgreSQL at localhost:5432!

Starting and Stopping Containers

Stop a Running Container

# Stop by name
docker stop my-nginx

# Stop by ID
docker stop a1b2c3d4e5f6

# Stop multiple containers
docker stop container1 container2 container3

Start a Stopped Container

# Start by name
docker start my-nginx

# Start by ID
docker start a1b2c3d4e5f6

Restart a Container

docker restart my-nginx

Remove a Container

# Remove stopped container
docker rm my-nginx

# Force remove running container
docker rm -f my-nginx

# Remove all stopped containers
docker container prune

View Container Logs

# View logs
docker logs my-nginx

# Follow logs (live)
docker logs -f my-nginx

# Last 100 lines
docker logs --tail 100 my-nginx

Execute Commands in Container

# Open interactive shell
docker exec -it my-nginx bash

# Run single command
docker exec my-nginx ls -la

# Check environment variables
docker exec my-nginx env

Private Docker Registries

While Docker Hub is public, companies often need private registries for proprietary code.

Popular Private Registry Options

Provider	Description
Docker Hub Private	Paid private repos on Docker Hub
AWS ECR	Amazon Elastic Container Registry
Google GCR	Google Container Registry
Azure ACR	Azure Container Registry
GitHub GHCR	GitHub Container Registry
Self-hosted	Harbor, Nexus, GitLab Registry

Using AWS ECR (Example)

# Login to ECR
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789.dkr.ecr.us-east-1.amazonaws.com

# Pull from ECR
docker pull 123456789.dkr.ecr.us-east-1.amazonaws.com/my-app:v1.0

# Push to ECR
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/my-app:v1.0

Why Use Private Registries?

Security: Keep proprietary code private
Control: Manage access with IAM/RBAC
Speed: Faster pulls within same cloud network
Compliance: Meet regulatory requirements

Registry vs Repository

This is often confused! Let me clarify:

Registry

A registry is the server that stores Docker images.

Examples:

docker.io (Docker Hub)
gcr.io (Google)
123456789.dkr.ecr.us-east-1.amazonaws.com (AWS ECR)

Repository

A repository is a collection of related images with different tags.

Example:

nginx repository contains:
- nginx:latest
- nginx:1.25
- nginx:1.25-alpine
- nginx:1.24

Full Image Reference

registry/repository:tag

Examples:
docker.io/library/nginx:1.25      # Full reference
nginx:1.25                         # Short (defaults to docker.io/library)
gcr.io/my-project/my-app:v1.0     # Google Container Registry

Visual Representation

┌─────────────────────────────────────────────────┐
│              Docker Hub (Registry)              │
├─────────────────────────────────────────────────┤
│  ┌──────────────┐  ┌──────────────┐            │
│  │    nginx     │  │     node     │            │
│  │ (Repository) │  │ (Repository) │   ...      │
│  ├──────────────┤  ├──────────────┤            │
│  │ :latest      │  │ :18          │            │
│  │ :1.25        │  │ :18-alpine   │            │
│  │ :1.25-alpine │  │ :20          │            │
│  │ :1.24        │  │ :latest      │            │
│  └──────────────┘  └──────────────┘            │
└─────────────────────────────────────────────────┘

Dockerfile - Dockerizing Your App

A Dockerfile is a text file containing instructions to build a Docker image. It's like a recipe for creating your container!

Basic Dockerfile Structure

# Base image
FROM node:18-alpine

# Set working directory
WORKDIR /app

# Copy package files
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy source code
COPY . .

# Expose port
EXPOSE 3000

# Start command
CMD ["npm", "start"]

Dockerfile Instructions Explained

Instruction	Purpose	Example
`FROM`	Base image to build upon	`FROM node:18-alpine`
`WORKDIR`	Set working directory	`WORKDIR /app`
`COPY`	Copy files from host to image	`COPY . .`
`RUN`	Execute command during build	`RUN npm install`
`EXPOSE`	Document which port the app uses	`EXPOSE 3000`
`CMD`	Default command when container starts	`CMD ["npm", "start"]`
`ENV`	Set environment variable	`ENV NODE_ENV=production`

1. Use specific base image versions:

# ✅ Good
FROM node:18.17.0-alpine

# ❌ Bad
FROM node:latest

2. Order instructions by change frequency:

# Things that change rarely (top)
FROM node:18-alpine
WORKDIR /app

# Dependencies (change occasionally)
COPY package*.json ./
RUN npm ci

# Source code (changes often - bottom)
COPY . .

3. Use .dockerignore:

# .dockerignore
node_modules
npm-debug.log
.git
.env
*.md

4. Minimize layers:

# ✅ Good - single RUN command
RUN apt-get update && \
    apt-get install -y curl && \
    rm -rf /var/lib/apt/lists/*

# ❌ Bad - multiple layers
RUN apt-get update
RUN apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*

Building Your Own Image

Now let's build the image from our Dockerfile!

Build Command

# Basic build
docker build -t my-app .

# Build with specific tag
docker build -t my-app:v1.0 .

# Build with different Dockerfile
docker build -f Dockerfile.prod -t my-app:prod .

Build Process Explained

$ docker build -t my-app:v1.0 .

[+] Building 15.2s (10/10) FINISHED
 => [1/6] FROM node:18-alpine                           2.1s
 => [2/6] WORKDIR /app                                  0.1s
 => [3/6] COPY package*.json ./                         0.1s
 => [4/6] RUN npm ci --only=production                 10.2s
 => [5/6] COPY src/ ./src/                              0.1s
 => exporting to image                                  0.3s

Verify Your Image

# List images
docker images

REPOSITORY   TAG     IMAGE ID       CREATED          SIZE
my-app       v1.0    abc123def456   10 seconds ago   175MB

Run Your Custom Image

# Run in detached mode with port binding
docker run -d -p 3000:3000 --name my-app-container my-app:v1.0

# Test it
curl http://localhost:3000
# Output: {"message":"Hello from Docker! 🐳","timestamp":"2024-01-15T10:30:00.000Z"}

Push to Registry

# Tag for Docker Hub
docker tag my-app:v1.0 yourusername/my-app:v1.0

# Login to Docker Hub
docker login

# Push
docker push yourusername/my-app:v1.0

Docker in the Software Development Lifecycle

Let's see how Docker fits into the complete development workflow!

Development Phase

┌─────────────────────────────────────────────────────┐
│                  LOCAL DEVELOPMENT                  │
├─────────────────────────────────────────────────────┤
│                                                     │
│  Developer writes code                              │
│         │                                           │
│         ▼                                           │
│  docker-compose up (starts all services)           │
│         │                                           │
│         ▼                                           │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐              │
│  │ Node.js │ │ MongoDB │ │  Redis  │              │
│  │   App   │ │   DB    │ │  Cache  │              │
│  └─────────┘ └─────────┘ └─────────┘              │
│         │                                           │
│         ▼                                           │
│  Test locally at localhost:3000                     │
│                                                     │
└─────────────────────────────────────────────────────┘

CI/CD Pipeline

┌─────────────────────────────────────────────────────┐
│                   CI/CD PIPELINE                    │
├─────────────────────────────────────────────────────┤
│                                                     │
│  1. Developer pushes code to GitHub                 │
│         │                                           │
│         ▼                                           │
│  2. CI server (GitHub Actions) triggers             │
│         │                                           │
│         ▼                                           │
│  3. Run tests in Docker container                   │
│         │                                           │
│         ▼                                           │
│  4. Build Docker image                              │
│         │                                           │
│         ▼                                           │
│  5. Push to Container Registry (ECR/GCR)            │
│         │                                           │
│         ▼                                           │
│  6. Deploy to Kubernetes/ECS                        │
│                                                     │
└─────────────────────────────────────────────────────┘

Production Environment

┌─────────────────────────────────────────────────────┐
│               PRODUCTION (Kubernetes)               │
├─────────────────────────────────────────────────────┤
│                                                     │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐              │
│  │ Pod 1   │ │ Pod 2   │ │ Pod 3   │   Auto-      │
│  │ my-app  │ │ my-app  │ │ my-app  │   scaling    │
│  └─────────┘ └─────────┘ └─────────┘              │
│       │           │           │                    │
│       └───────────┼───────────┘                    │
│                   │                                 │
│            Load Balancer                            │
│                   │                                 │
│              Users 🌐                               │
│                                                     │
└─────────────────────────────────────────────────────┘

Key Benefits in SDLC

Phase	Docker Benefit
Development	Consistent environment, quick setup
Testing	Isolated test environments
CI/CD	Reproducible builds
Staging	Mirror production exactly
Production	Easy scaling, quick deployments

Where to Go From Here

Congratulations on learning Docker basics! 🎉 Here's your learning roadmap:

Immediate Next Steps

Learn Docker Compose
- Multi-container applications
- Define services in YAML
- Example: App + Database + Cache
Understand Volumes
- Persist data across container restarts
- Share data between containers
Docker Networking
- Bridge networks
- Container communication
- DNS in Docker
Multi-stage Builds
- Smaller production images
- Separate build and runtime
Docker Security
- Non-root users
- Image scanning
- Secrets management
Container Orchestration
- Kubernetes (K8s)
- Docker Swarm
- Amazon ECS
CI/CD with Docker
- GitHub Actions
- GitLab CI
- Jenkins

Recommended Resources

Resource	Type	Link
TechWorld with Nana	YouTube	Channel
Docker Official Docs	Documentation	docs.docker.com
Play with Docker	Interactive Lab	labs.play-with-docker.com
Docker Curriculum	Tutorial	docker-curriculum.com

Quick Reference Card

Most Used Commands

# Images
docker pull <image>           # Download image
docker images                 # List images
docker rmi <image>           # Remove image

# Containers
docker run -d -p 8080:80 nginx    # Run container
docker ps                          # List running
docker ps -a                       # List all
docker stop <container>            # Stop
docker start <container>           # Start
docker rm <container>              # Remove
docker logs <container>            # View logs
docker exec -it <container> bash   # Shell access

# Build
docker build -t myapp:v1 .         # Build image
docker push myapp:v1               # Push to registry

# Cleanup
docker system prune               # Remove unused data
docker container prune            # Remove stopped containers
docker image prune                # Remove dangling images

Summary

Docker is an essential tool for modern software development. Here's what we covered:

✅ What Docker is - A containerization platform
✅ Problems it solves - Consistency across environments
✅ VMs vs Containers - Lightweight alternative to VMs
✅ Images vs Containers - Blueprint vs running instance
✅ Docker Hub - Public registry for images
✅ Essential commands - pull, run, stop, logs, exec
✅ Port binding - Exposing container ports
✅ Dockerfile - Recipe for building images
✅ SDLC integration - Development to production workflow

📬 Join the Journey!

Found this helpful? I'm building this blog for beginners and new grads like us to learn and grow together. No gatekeeping — just honest, practical knowledge from one learner to another.

👉 Subscribe at kerempakten.dev to get notified when I publish new tutorials!

You'll find:

🐳 DevOps & Cloud tutorials
💻 Project breakdowns & real code
🎯 Career tips for new graduates
📝 Honest "building in public" updates

Let's learn together!