Why Developers Must Be Part of the Customer Validation Process

Agile has made it faster to design, build, and ship features. Teams track sprints, display burndown charts to show progress, and conduct sprint retros. With the inclusion of AI in almost every phase of software development, teams are equipped to accelerate feature delivery even more. 

But all these improvements in delivery time haven’t really increased customer satisfaction or led to a greater rate of adoption among customers. Perhaps it’s because, at its core, being agile alone does not help software development teams develop features iteratively. We’re still in waterfall when it comes to requirements — they are created by product managers and handed over to the software developers, who create and ship these features without any real feedback from customers.

Customer validation and feedback must be intentionally included in agile sprints, and software developers must be a part of this process. Understanding what problems a feature can solve and watching how customers may use a feature can empower developers to think outside the box and deliver features that are easy for customers to learn, adopt, and use.

But how can teams realistically achieve this? Talking to and observing how customers behave is time-consuming and can take away time from actual development, leading to reduced velocity and longer delivery times — none of which are acceptable outcomes. These activities are also very much in the product management wheelhouse. Hence, developers must work with the product management team to ensure they are getting the maximum learning in the most efficient way. This is where the concept of build-measure-learn cycles can be folded into the software development process.

What Is a Build-Measure-Learn (BML) Cycle?

A BML cycle is a continuous feedback loop that provides a disciplined way to reduce waste, validate assumptions quickly, and ensure we’re delivering features customers will use.

• Build a set of features that allow you to test full functionality or a meaningful portion of it
• Measure how customers behave and use the feature
• Learn whether to continue, pivot, or in some cases abandon the feature in question

Set Up of a BML Cycle

Duration

A build, measure, and learn cycle is generally a fixed number of sprints. If you’re unsure of how many sprints/weeks should make up a build, measure, and learn cycle, start with 2 sprints or 4 weeks. 4 weeks is generally sufficient time to ensure there is meaningful progress to demo to customers.

Goals

Every BML cycle must have a defined goal. For example, if you’re building a new application, a goal can be to demonstrate the menu bar and placement of all elements of the menu bar. If a feature is very big, instead of waiting till the end to demo the entire feature, BML cycles can be set up to demo parts of the feature to ensure feedback is incorporated early.

Participants

Choose a set of customers who will be your BML partners; this step is owned and executed by the product manager. Choosing too many customers can lead to feedback fatigue mid-sprint, and choosing too few can cause feedback to be skewed towards a certain segment of customers. Choosing 5–6 customers who represent 80% of your user segments is a great way to ensure that BML cycles produce meaningful feedback.

BML customers are generally a subset of your larger alpha and beta customer cohort. These are customers who are engaged and will give you feedback on a regular basis.

Role of Engineers in a BML Cycle 

The role of engineers in a build-measure-learn (BML) cycle is not just to build the feature; they are active partners in customer demos during the measure phase and important stakeholders making decisions during the learn phase.

Build — Engineers Shape the Demo, Not Just the Code

Engineers are the stars of the show during the build stage. They understand the requirements, write the code, peer review code, run research spikes for future sprints, and locally test their code before it is handed over to QA. Engineers decide and direct how much of the feature/product is being built and what can be shown in a demo to customers. They can also quickly wire a feature just for the demo to get early insights from customers without having to build the entire feature if the team is undecided on certain elements of the feature.

Measure — Engineers Observe, Instrument, and Interpret Signals

In a BML demo, engineers are not silent observers — they are data collectors and pattern recognizers. They learn and start to think about making the feature better by:

• Watching how users interact with the prototype and understanding how to make the feature more usable
• Identifying edge cases that Product Managers may miss
• Inspecting system behavior and identifying latency, misfires, and false positives
• Asking clarifying questions on workflow to deduce technical constraints that need to be resolved

Engineers often notice user behavior and draw conclusions such as:

• The user paused before clicking — the UI needs to be more intuitive
• The model misclassified because the lighting in the user’s environment is different

These observations are essential to ensure that the final product delivered meets customer expectations.

Learn — Engineers Help Decide Whether to Persevere or Pivot on Key Architecture Constraints

After the demo, engineers help translate observations into technical insights and challenges. They contribute by:

• Explaining to the larger team why certain behaviors such as model limitations, workflow mismatches, or timeouts occurred
• Identifying what’s easy vs. hard to change and thereby influencing what is feasible for MVP timelines
• Helping refine the goals and objectives for the next BML cycle
• Help prioritize fixes or feature changes based on impact and effort

Having engineers as part of the BML cycle builds trust with customers by showing credibility and assuring customers that the product is being built by experts. Engineers encourage an atmosphere of transparency on what is achievable quickly versus what needs time to be built. They also create a collaborative atmosphere where customers are motivated to be more forthcoming because they feel heard by the people who build the system.