Writing code is easy. Building products is hard. We’ve all seen this pattern: a brilliant PM writes a massive spec, engineers build it at lightning speed, and then… crickets.

I call this silence the “validation gap” – the void between deployment and knowing if the feature really works for your users. At monday.com CRM, we bridged that gap by getting quality feedback early in the release process. We then used this feedback to get our engineers “out of the IDE” and into the minds of our users.

In this post, I’ll share how we built a process that allowed us to identify, recruit, and engage with a group of “alpha testers”, eager to provide us with quality feedback. This process didn’t just improve the feature – it redefined how our engineers think.

Why ‘code complete’ is never enough

The worst thing an engineering organization can suffer from is having its best engineers working on the wrong features, prioritizing the wrong things.

How do we monitor new product releases? Usually, we turn to our best-in-class observability tools. They are great at telling us what is happening – latency, error rates, throughput… but they are silent on the why. To debug a user’s frustration, you can’t just look at a trace – you must hear their story. The best way to hear their story? Face to face (or Zoom to Zoom, that is).

Enabling this “product mindset” means engineers no longer focus on “delivering”. They focus on outcomes. We want them to ask “How does this change affect our users?” and “What will be the impact of not delivering this change?” Let’s make it easy for them to ask these questions.

Here’s the step-by-step framework we used with the latest Quotes & Invoices product release.

Building the Feedback-Driven Pipeline

The first step in creating this group of users is identifying who they are. Who has the highest intent to use our product? At what point in their session would they be most likely to convert and join our alpha?

For us in Quotes & Invoices, we were targeting the Admins – the power users who were setting up the system. The most intentful time in their session is when they experience the most pain – using the legacy Quotes & Invoices experience.

Our initially-proposed opt-in banner

<marquee>PIVOT TIME</marquee> (or, optimize for speed)

A product team needs to move fast. When a platform team builds great infra for us to use, we use it. So instead of our original “high-intent” plans (which would take 1-2 days to implement), we introduced a system-wide banner that every Admin user would see (which took 1-2 hours to implement).

Eventually, this turned out to be a great decision. We were reaching out to a bigger audience, including those who tried Quotes & Invoices in the past, but churned from this feature because it did not fit their needs.

Why our users actually wanted to help

In this banner, we tried to give them an “exclusive” feeling. “Want to be the first to experience our updated…” This created a psychological effect of exclusiveness and belonging, which later led to a higher engagement and a desire to participate and leave valuable feedback.

The Implementation: Low Effort, High Impact

It was as simple as it could get: when the user clicked the button, we saved their details so we could:

• Actually open the feature flag for them
• Personally reach out to them via email
• Choose who we wanted to engage with

We started by releasing the banner to 3% of the monday.com CRM accounts. We were thirsty to get users on board, so we added a Slack integration that would send us a message on any new request. The conversion was incredible. After 1 day, we had >200 accounts that opted in. We had to stop the Slack integration.

Closing the Feedback Loop: From Email to Slack

Luckily, monday.com CRM has an amazing email sequencing product (but worry not, the following can be achieved with any such solution. Your company’s marketing team will be happy to assist).

We created an email sequence that would fire once we opened the feature flag for an account. The first email was a “congratulations on joining!” After 3 days (and hopefully some usage), we sent another email asking for feedback.

Our initial email

Our followup email asking for feedback

Every response to the form and every reply to an email was sent directly to a dedicated #quotes-and-invoices-feedback Slack channel, so every member of the team can see how our users are using the product, what does and doesn’t work for them. It allowed us to converse on these specific topics, with everyone participating – devs, PM, designer, and team lead.

This Slack channel acted as the “heartbeat” of the product, and we were thirsty for every new piece of feedback we got, whether it was bug reports, feature requests, praises, or anything else.

Our slack hearbeat

The last and most crucial step in connecting our engineers with the users is putting them together in the same room. Well, a virtual room, that is. Except for 1 David, who came to meet us in our office with his business-partner-wife and their 2 kids. Shoutout to David!

Why empathy is an engineering skill

We got dozens of pieces of quality feedback in less than a month. This was a goldmine.

All of this feedback is building user empathy in our engineers. They’ve started relating to them. They’ve started to understand their needs. They’ve started to develop the “product mindset” that makes the difference between a great builder and a great coder.

Now, this wasn’t just a “feel-good” exercise. It helped us nudge our roadmap in the right direction. We actually pivoted away from planned features and doubled down on ideas we thought were low-priority.

This is also my key takeaway for you: if you don’t want your team spending time building the wrong things, you must have your team spend time speaking with users. If you want your team to spend time speaking with users, incorporate quality user feedback into every step of the release process.

Grow your business by growing your engineers

For my team, this experiment was a game-changer. We started looking at every new feature we plan to deliver, and asked ourselves not only “what is the MVP we can release?”, but more importantly, “if this MVP fails, how do we know WHY it failed?” and “if this MVP succeeds, how do we know what the next features should be?”

You don’t need a fancy forms product or a state-of-the-art email sequencer – you can start with a simple Google form and some manual emails. If you want to grow your business and if you want to grow your engineers, in an age where coding skills are no longer enough, get your engineers closer to your customers. Both will thank you.