Building Customer Feedback in Early: Testing Delivery in Small Steps

You build customer feedback in early by cutting every delivery so that real users can try it within a few weeks, and by settling beforehand which decision the feedback may change. The shorter the gap between idea and response, the less work goes into assumptions that later prove wrong. This article shows five forms of feedback, a calculation of the learning rate and a checklist for delivery steps.

Many initiatives follow a familiar pattern: requirements are collected, teams build for months, and only at the end do customers or users see the result. Only then does it become clear what everyone involved had estimated but never tested. A change at that point is expensive because it builds on finished work and often invalidates part of it.

Why is it worth gathering customer feedback early?

Customer feedback gathered early reduces the risk of building in the wrong direction and shortens the path to a solution that is used. The reason lies in the number of learning cycles. The principles of the Agile Manifesto of 2001 call for early and continuous delivery of valuable software. In 2011 Eric Ries described in “The Lean Startup” the loop of build, measure and learn, and argued that learning from real customer reactions is the actual progress of a new offering, more than the volume of what has been built.

The principle applies beyond software development. A new order-handling process, a new service offering or an AI application for sales can also be introduced in small steps, each with a group of real users. With AI applications the value often shows only in the real process with real data, which is why an early user test belongs in every initiative of this kind.

How many responses do you need?

A few users are enough to uncover usability problems; to test benefit and willingness to pay you need more. In 1993 Jakob Nielsen and Thomas Landauer showed that a single test user uncovers on average across the projects studied about 31 per cent of the usability problems of an application. With n users, the share of problems found is 1 minus 0.69 to the power of n. With five users that is about 85 per cent, with ten about 98 per cent. Nielsen concluded that several small tests with five users each are better than one large test.

The figure holds for usability problems in a manageable task. Questions such as “Do customers need this?” or “Who pays for it?” can be opened with five conversations and substantiated with figures from real use. For that reason every delivery step includes a decision on which question it should answer and which form of feedback fits it.

Which forms of customer feedback exist?

Five forms cover most cases, and they differ in effort, timing and evidential value.

The order follows the open question. Before building, the task is to clarify whether the problem exists, then whether the solution is understood, then whether it holds up in daily work, and finally whether it moves a metric. The demonstration in a review is the cheapest form and on its own the weakest, because participants often judge more mildly in a demonstration than when they work with the product themselves. How a review produces decisions is described in the article on the sprint review.

How do you calculate the value of small delivery steps?

Small delivery steps raise the number of learning cycles per year, and every cycle reduces the risk that work flows in a wrong direction. The calculation is short: the number of cycles per year is 52 divided by the cycle length in weeks, and the budget spent until the first response shows how much work can hang on a wrong assumption.

The following example is illustrative. An initiative runs for twelve months with a budget of 1.2 million euros. One core assumption on which the solution rests proves wrong.

The calculation simplifies, since part of the work can be reused after a correction, and small steps cause their own costs for coordination and deployment. It does show the order of magnitude: the work that depends on a wrong assumption grows with the time to the first response. For that reason investment in shorter delivery cycles pays off above all where assumptions are uncertain, for example with new products and AI applications. Clarification before building is covered in the article on product discovery.

How do you cut deliveries so that feedback becomes possible?

You cut deliveries vertically, through all layers of the process, so that every step can be experienced by a user. A horizontal cut, for example the data foundation for all functions first, delivers nothing after months that a customer can try. A vertical cut delivers within two to four weeks a small, complete function: one order type, one customer group, one location.

The last point deserves attention. Feedback on a half-finished state distorts judgement because users confuse defects with the idea. The article on the definition of done describes how teams set when a step is usable.

Which mistakes do teams make when building in feedback?

Four mistakes recur. First, teams ask for opinions, and what users say often differs from what they do. Second, they collect responses without decision rights, so nobody determines what follows. Third, they ask only friendly customers who are satisfied anyway. Fourth, approval loops stretch the cycle until four weeks become four months again.

The remedies are simple but binding: observe users at the task, name someone responsible for decisions, choose test participants deliberately from among critical customers as well, and measure cycle length as a metric of its own. How dates and commitments stay reliable despite short cycles is described in the article on release planning.

How do you introduce early customer feedback in four steps?

You introduce early feedback by starting with one initiative that fixes cycle length, pilot group and decision rights, and then transferring the approach to further initiatives.

1. Choose an initiative: take one with uncertain assumptions and a reachable customer or user group.
2. Name the pilot group: fix five to ten real users who are willing to give regular responses.
3. Set the cycle: agree one delivery every two to four weeks, with a question, a metric and a decision per step.
4. Evaluate and adjust: after three cycles, assess which assumptions have been confirmed, how the metric is developing and whether the cycle was short enough.

Customer feedback in delivery with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisational design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. In the delivery management service area he works as delivery manager, project manager or product owner and steers deliveries so that responses arrive early.

The approach follows the Niehues Delivery Model with three phases. Three of its test questions matter most for early feedback: which business outcome should change measurably? Does the prototype prove the benefit in the real process with real data? Which metric shows after 90 days that the solution is landing? Scope and terms of an engagement are discussed in the free initial consultation, which you can arrange in 30 minutes through the contact form.