Engineering with Insight

A Field Guide to Customer Conversations for Product-Minded Engineers

The distance between what to build and how to build it continues to collapse. The wall between product and engineering is disappearing…and that’s a good thing.

This post is for the product engineer: builders who care deeply about what their code unlocks for users. Think PostHog’s definition in practice: full-stack bias, customer empathy, design taste, roadmap opinions, and a habit of shipping small and learning quickly. They pair user feedback with usage data and competitive context to decide what’s next. They have the drive and curiosity to own outcomes, not just tickets.

Because “Product” is not simply a title (“Product Manager”); it’s the work. The best engineers are building not only the product — they’re building an understanding directly with customers.

Recently, Igor and I worked together on extracting better insights from customers during prep for a big launch, and he shared his reflections on LinkedIn.

Discovery isn’t about validating your solution. It’s about understanding their problem first.

Let’s call it customer listening (hat tip to Agata).

This is a guide for the engineers and teams who want to build that customer gut. Over time, that intuition compounds, and you start to feel what to build next.

What to Use and When

There are two kinds of conversations (listening sessions) worth mastering:

Generative conversations help you find problems, patterns, and workarounds worth solving. You’re problem hunting, not validating a solution or approach. These happen early, when you’re chasing problems and shaping ideas.

Evaluative conversations test whether your solution actually solves the right problem effectively. These happen as you near launch or post-release.

We’ll focus largely on evaluative conversations here (but the best engineers keep their curiosity alive by weaving generative questions into those evaluative conversations).

Run a Call That Teaches You Something

Close your laptop for a second and remember the mantra: You’re here to become fluent in your customer’s world.

Now: Use this like a one-pager before your next Zoom.

1. Write three bullets before you meet

• The assumption you’re testing

• The behavior that would change your mind

• The outcome that gives you confidence to ship

Without this, you’ll collect anecdotes and miss insight. Once you define your goals, the right questions write themselves.

2. Recruit for fit, not convenience

Once you know what you need to learn, recruit people who can actually teach you that. Talk to people who live the problem you’re exploring. If you realize mid-call it’s a mismatch, pivot — explore their actual workflow for generative learning, then wrap.

• If your learning goal is “understand existing workflows,” talk to active users who are deep in the process today.

• If it’s “see if new users understand the value,” recruit fresh eyes who’ve never touched the product.

• If it’s “explore expansion or adjacent use cases,” talk to power users or customers who’ve hacked the product to do more than you expected.

Avoid convenience sampling. Your loudest customer or the one who answers Slack fastest isn’t necessarily your best teacher.

Diversity matters — a few contrasting perspectives often reveal the boundaries of your insight faster than another round of similar users.

3. Establish a truth-seeking tone (30 seconds)

“Thanks for doing this—please be frank. If something feels confusing or useless, say it. That helps me fix the right things.” That sentence buys you truth.

4. Map their baseline first (5–10 min)

Seek stories, not opinions. You must understand the current reality you’re competing against — their existing workflow is your baseline. Again, your goal is to learn about the customer and their world. Questions like:

• “Walk me through the last time this came up.”

• “Could you show me how you do this today?”

• “What is the most annoying part of that process?”

If they can’t recall a real moment, the problem probably isn’t real.

5. Let your product speak first (10 min)

Share the build or prototype. Don’t narrate. Watch where they hesitate, what they ignore, what they try to make it do. Then probe with questions like:

• “Where would this live in your day?”

• “What does this replace?”

• “What would stop you from trying this this week?”

• “If you could add one thing to this…”

• “If this disappeared tomorrow, what breaks?”

Anchor in behavior, not opinion.

6. Close the loop crisply (2–3 min)

• Reflect back: “Sounds like the value is X, but trust hinges on Y. Did I get that right?”

• Ask for a real-world trial: “Any upcoming use case where this could ride along?”

• Get permission to follow up in a week.

• Bonus: “What’s the one question I should have asked you?”

Better Questions, Better Signal

The quality of your learning depends on the quality of your questions. Replace hypotheticals with real stories, and polite prompts with provocations.

If your question starts with would or do you think, reframe it until it starts with when, how, or why.

Instead of… → Ask…

• “Would you use this?” → “When was the last time you needed to do this? What did you do?”

• “Do you like this?” → “What’s confusing or unnecessary here?”

• “Would you pay for this?” → “What do you already pay for that solves part of this?”

• “Would this save you time?” → “What’s costing you time right now?”

• “Would you switch?” → “What would make you leave your current tool — and what would keep you there?”

When you want to leave them thinking:

• “What’s the question we should’ve asked you today, but didn’t?”

• “If this product disappeared, what would you actually miss?”

• “What’s the one outcome you care about that no tool ever measures right?”

When you’re testing whether the problem is real:

• “Appreciate you testing this! Now, if I turned this back off tomorrow, what would break?”

• “What’s the ugly but reliable hack you fall back on?”

• “How do you know when this process is ‘good enough’ to ignore?”

When you’re exploring willingness to pay or switch:

• “If this could replace [tool], how would you expect pricing to compare?”

• “What’s the moment you’d say, ‘This just paid for itself!’”

• “What have you already paid for to solve this — even halfway?”

• “If your budget got cut tomorrow, what would you fight to keep?”

• “Who else would need to love this for it to stick?”

👉 A note on willingness to pay: WTP is tricky, and ultimately, the credit card is the test. These questions help you sniff signal, but there are loads of scientific ways to do this as you lead up to a launch — think Van Westendorp, Gabor–Granger, conjoint testing, etc. You could go nuts here. But the main rule of thumb in this realm is to lead with value before cost. Users don’t pay for features; they pay to make something disappear.

The Engineer’s Advantage

Great engineers don’t wait for insight to be handed to them. They go get it — by asking sharp questions, grounding in real moments, and closing the loop with code.

• You already isolate variables and run tight loops. Treat interviews like debugging: reproduce a real moment, inspect inputs and outputs, validate hypotheses against behavior.

• You already ship iteratively. Use flags, small cohorts, and session replay to pair what people say with what they do.

• You already manage complexity. Ask one question at a time; change one thing at a time.

Do this for a few weeks and your judgment changes. You’ll feel which problems are alive, where friction really is, and what good enough to learn looks like.

Try: list one thing you don’t know about your user. Then schedule a 20-minute call to find out using the guidelines above.

Build fast. Listen better.

---

Bottom Line

The engineers who engage with users — especially outside of pure validation — change the company. It builds product sense and customer empathy.

Don’t wait for product direction. Go find it — then build what you learned.