Allstacks’s Embedding Discovery Method: Why Customer Interviews Weren’t Enough to Find Product-Market Fit

Allstacks’s Embedding Discovery Method: Why Customer Interviews Weren’t Enough to Find Product-Market Fit

You schedule fifteen customer discovery calls. You ask about pain points and workflows. Everyone gives thoughtful answers. You build a product roadmap. Six months later, you realize you built something nobody urgently needs.

The problem isn’t that people lied. Structured interviews surface what people think they need, not what actually breaks their day. The real insights live in the moments between calls—the frustrated Slack messages, the emergency meetings, the problems people solve with duct tape.

In a recent episode of Category Visionaries, Hersh Tapadia, CEO and Co-Founder of Allstacks, a value stream intelligence platform that’s raised nearly $16 million, shared how he discovered their product idea not through interviews, but through full immersion in the environment where the problem lived.

The Decision to Embed, Not Interview

After leaving his previous company, Hersh knew he wanted to build a software company focused on developers. But he didn’t want to assume the problem.

So he and his Co-Founder Jeremy Freeman made an unusual choice. Instead of conducting customer discovery interviews, they embedded themselves directly inside engineering teams.

“We said, well, we’ll just embed ourselves into different teams. And as we do that, we’ll figure out what people are complaining about, and we’ll solve that problem.”

This wasn’t a week-long observation. This was full immersion—working alongside teams, participating in standups, seeing what broke in real-time, hearing the conversations that never make it into formal feedback sessions.

The bet was that the real problem would reveal itself through what people consistently complained about when they weren’t being asked.

What Interviews Would Have Missed

If Hersh had run traditional customer interviews, he probably would have heard about velocity, sprint planning, or developer productivity. These are legible, measurable complaints.

But embedding revealed something different. “What everyone was complaining about was ultimately this problem of managing expectations between different stakeholders, because it’s really hard to get a read on what was going on.”

This showed up everywhere. Product managers frustrated because engineering couldn’t give straight answers on delivery dates. Engineering leaders blindsided in exec meetings when projects went sideways. Developers confused about why their work wasn’t valued by the business.

But here’s the critical insight—the thing impossible to discover through interviews. The problem wasn’t actually about delays or misses.

“When you think about what are you actually upset about? You’re actually upset about the surprise more so than you’re upset about what happened. It’s the way you found out.”

This reframing changes everything. If you asked someone “what’s your biggest problem with engineering delivery?” they’d say “projects are late.” They wouldn’t say “I’m upset about being surprised.”

But the surprise is the actual wound. Projects being late is manageable if everyone sees it coming. What destroys trust is finding out too late—discovering in a board meeting that a critical feature won’t ship, or learning from a customer escalation that a bug has plagued users for weeks.

The Pattern Beneath the Pattern

Embedding didn’t just reveal what people complained about. It revealed why they complained.

Engineering teams weren’t struggling because they lacked dashboards or metrics. Most teams had some way of tracking work—Jira boards, custom Tableau dashboards, spreadsheets.

What didn’t exist was a way to surface when things were going off track before it became a crisis. Teams had lagging indicators but no leading indicators. They could tell you what happened last week, but not what was about to go wrong next week.

This is why the surprise problem kept recurring. Engineering leaders were flying blind between check-in points. By the time data showed something was wrong, it was too late to course-correct without disrupting commitments.

The insight wasn’t “engineering needs better data.” It was “engineering needs to eliminate surprises by surfacing problems while there’s still time to fix them.”

That insight only emerged from watching the pattern play out repeatedly in real environments.

Why Embedding Works Where Interviews Fail

Customer interviews are optimized for explicit knowledge—things people know they know. But the most valuable product insights often live in implicit knowledge—things people experience but can’t easily verbalize.

When you ask “what’s your biggest pain point?” they give you their best guess. But pain points aren’t always legible to the people experiencing them. They’ve adapted their workflows around the problem. They’ve accepted the friction as “just how things are.”

Embedding lets you see what people have normalized. You watch them spend twenty minutes manually pulling data from five tools. You see them hedge commitments because they don’t trust their estimates. You observe them having the same conversation in three Slack channels because information doesn’t flow cleanly.

These patterns are invisible to the people living them. They’re only visible to an outsider present long enough to notice the repetition.

The Tactical Implementation

How do you actually embed with potential customers? The key is positioning it as mutual value exchange. Hersh and Jeremy weren’t just observing—they were contributing. They participated in standups and helped solve problems.

This ensures teams actually want you around long-term. And it gives you permission to ask questions in the moment. When you’re embedded, you can ask “why did that meeting go sideways?” right when it happens.

The time commitment is significant—weeks or months. But that investment pays off because you’re developing intuition about the problem space, not just collecting feedback.

From Insight to Product

The embedding discovery led directly to Allstacks’s core positioning. They weren’t building an engineering analytics platform. They were building a system to eliminate surprises in engineering delivery.

This positioning came from embedding, not interviews. And it resonates because it names the emotional wound, not just the tactical problem.

The Broader Lesson

Most founders can’t embed for months before building. But the principle scales: the best insights come from being present in the environment where the problem lives, not from extracting information through structured interviews.

That might mean joining your target customer’s Slack workspace. It might mean taking a part-time role in the industry you’re building for. It might mean spending a week shadowing people as they work.

The common thread is presence over extraction. You’re not trying to get people to tell you what they need. You’re trying to observe the gap between what they think they need and what actually breaks their day.

Allstacks found their $16 million insight not by asking better questions, but by being in the room when the problems happened organically.