Engineering Driven Customer Discovery

What you actually need to know

• Engineers should talk to customers directly, at least monthly.
• The engineer listens. The engineer does not demo.
• Open ended questions surface real signal.
• A shared document captures notes per conversation.
• Quarterly synthesis surfaces themes and informs the roadmap.

The core argument

Customer discovery is one of those activities that founders delegate to product or sales. The engineers stay out of customer conversations because the team has decided that is product's job. The pattern is consistent and produces engineers who build features that miss the mark because they never heard the customer say what they actually wanted.

The fix is engineering driven customer discovery. The engineer participates in customer conversations directly. The engineer hears the words. The engineer hears the context. The engineer understands the customer's actual workflow. The understanding shapes the engineer's design decisions in ways that secondhand notes cannot.

The investment is small. One customer conversation per month per engineer is enough to keep the team grounded. The engineer prepares with a short script. The engineer listens for forty five minutes. The engineer writes a note for the team. The total time per month is a couple of hours.

The discipline is in not demoing. The temptation to show the product is real. The conversation that turns into a demo loses the discovery signal. The engineer has to listen. The conversation that stays focused on the customer's experience produces the insights that change the roadmap.

The teams that adopt this build products that match customer needs. The teams that keep engineering away from customers build products that the customer team has to translate. The translation loses signal. The product drifts.

The conversation structure

How much does this cost

The cost is engineer time. One hour per month per engineer for the conversation. A few hours per quarter for synthesis. The total is roughly two hours per engineer per month. The return is product decisions made with customer signal rather than guesses.

Features the discovery practice must have

• A regular cadence of customer conversations.
• A short script for engineers new to discovery.
• A shared document for raw notes.
• Quarterly synthesis sessions.
• A way to surface insights to the product roadmap.
• A way for engineers to revisit specific themes.
• An owner of the practice.
• A way to recruit willing customers.

Expert opinion

The teams that put engineers in customer conversations build products that fit customer reality. The teams that keep engineers away build products that need translation layers between customer feedback and engineering decisions. The translation loses signal at every step. The investment to put engineers in the room is small. The product impact is large.

>

Yashveer Singh, founder of Yashveer Labs

How this played out on a real project

A client SaaS engineering team had been building features based on product specs without talking to customers. The product manager translated customer feedback into requirements. The engineers built to the requirements. The customer adoption was disappointing.

We instituted engineering driven customer discovery. Each engineer had one customer conversation per month. The engineers came back with insights the product manager had not captured. The customer's actual workflow was different from what the product spec described. The pain points were not what the spec emphasized.

The next quarter's features were shaped by the engineer insights as well as the product manager's. The adoption on the new features was significantly better. The engineering team's connection to customer value strengthened. The product manager appreciated the additional signal.

For more on the related work, see the customer feedback pipeline every SaaS should have and the engineer customer conversation patterns that yield insight.

Common mistakes teams make

1. Engineers never talk to customers.
2. Engineers demo the product instead of listening.
3. No structured discovery cadence.
4. No synthesis across conversations.
5. No way to recruit willing customers.
6. Treating discovery as product's job alone.
7. Conversations that become sales pitches.
8. No reporting back to the team on what was learned.

A 30 day plan to start

1. Week one. Build the conversation script. Pick the first willing customers.
2. Week two. First round of conversations. Each engineer has one.
3. Week three. Synthesis across the conversations. Tag themes.
4. Week four. Establish the monthly cadence. Communicate the themes to product.

For more on the related work, read the customer feedback pipeline every SaaS should have and customer health scoring a founder engineers build. On the broader strategy side, customer success engineering a quiet revenue driver is the natural next read.