PMI-ACP Seek Early Feedback: Customer Satisfaction, Small Increments and Feature Flags

Seeking early feedback means putting real, working pieces of the product in front of the people who will use or depend on it as soon as possible, measuring how satisfied they are, and feeding what they say and do back into the backlog on a steady rhythm. The PMI-ACP Examination Content Outline makes it Task 1 of the Delivery domain and lists three enablers:

1. Evaluate customer satisfaction. Choose a measure that fits the goal, track it across increments, and read it critically.
2. Deliver work in small increments. Small, releasable pieces are what make early feedback possible at all.
3. Collect and incorporate stakeholders' feedback on a regular basis. Feedback has to arrive often, from the right people, and actually change what is built next.

The Delivery domain description adds two details that matter here: feedback is sought from internal and external customers, and the practitioner is expected to know development practices such as continuous integration, continuous delivery and test-driven development, which are what make frequent small releases safe.

Neighbouring tasks cover related ground. Running the iteration review, slicing stories vertically and measuring the value of each increment belong to Manage increments; MVPs and experiments to Experiment early; design thinking, lean startup and loop length to Shorten feedback loops; choosing and radiating team metrics to Manage agile metrics; and day-to-day collaboration with customers on needs and acceptance criteria to Actively engage customers.

Choose the satisfaction measure whose question matches the goal you are trying to judge, and ask it at a moment and a frequency that lets you judge each increment. The three common survey measures ask different questions:

Behavioural signals complement these. Active usage, retention, task completion and drop-off show what people do, but they only reflect satisfaction when people have a choice. Captive users, such as employees who must use an internal tool, keep using it however tedious it is, so usage would not move when you make it better or worse. Volume measures can also be driven by outside factors: how many orders a warehouse team processes depends on customer demand, not on how pleasant its scanning screen is. Page views or traffic show reach, not whether anyone was helped.

A Kano survey also asks how users feel about features, but it is a prioritization tool that sorts features into categories such as basic (must-be), performance and delighters (Kano also has indifferent and reverse categories); it is not a tracker of satisfaction over time.

Customers' stated satisfaction and their actual behaviour often disagree, and when they do, the behaviour tells you there is a problem while direct observation tells you what it is. People answer surveys and interviews politely, predict their future use optimistically, and often cannot explain their own workarounds.

A gap can run either way. A feature can earn good ratings while the data shows it is rarely used as intended, or people can promise enthusiastic use that never materialises. In a library's booking app, for instance, members might rate the new reservation screen highly while most of them still phone the desk to reserve a room.

The sound response has two parts:

• Treat both sources as evidence. The behaviour is the stronger signal that something is wrong, and the stated views carry context that may later explain it. Neither should be quietly dropped, and a short-lived dip is not yet proof that the product has failed.
• Find the cause before building more. The explanation usually comes from watching a few people use the product in their real setting, or talking to the specific people whose behaviour differs from what they said. Further self-reported data cannot settle a disagreement with behaviour, and a fix chosen before the cause is known may solve the wrong problem.

The same principle explains why focus groups and preference surveys are weak evidence for questions about behaviour: what a few people say they prefer can differ from what many people actually do.

Measure satisfaction little and often, after each release, and keep at least one measure constant so the trend means something. One large survey at the end of a project tells you the result when it is too late to change direction; regular measurement shows whether each increment helped or hurt while there is still time to respond.

• Ask the customers themselves. Anyone reporting on customers' behalf is a proxy, however senior or well informed. Counting stories accepted at a review measures output against acceptance criteria, not how satisfied people are using the product.
• Keep one core question fixed. A trend needs the same question asked the same way each time. Keep one question unchanged and add exploratory questions beside it; scores from different questions cannot be combined into a trend after the fact.
• Attribute changes carefully. Before crediting an increment with a rise or fall, list whatever else changed in the same period: prices, marketing, the season, the mix of people who answered. A measurement that cannot separate those causes cannot attribute the change, however many times it is repeated.
• Use a comparison group. Comparing people who got the increment with similar people who did not, while both experienced the same other changes, isolates the increment's own effect. A randomly chosen pilot group gives you this comparison for free, so a concern raised by pilot users can be checked against everyone else with data before the release is widened.

Before acting on a satisfaction figure, check who it represents: averages, falling response rates and self-selected respondents can all hide dissatisfied customers.

None of these means waiting indefinitely for "more data". When a trend is clear across several increments and nothing suggests the responses are unreliable, act on it. When the data is skewed, go and get the missing voices rather than discarding the measure entirely.

Delivering work in small increments means finishing and showing usable pieces of the product often, so that misunderstandings come to light while they are cheap to fix. Stakeholders react to real working software; a wrong assumption found in a two-week slice costs far less than one discovered after months of work have been built on top of it. Small increments still meet the full definition of done, they do not mean less testing, and agile delivery keeps scope flexible so feedback can change it.

The feedback must come from working product. Approved specifications, sign-offs and mock-ups are not the same as using the thing: a mock-up shows layout but not whether results fit how people really work, and a signed document records agreement, not experience. When the only convincing check is for users to work with the real output, slice the work so that real use begins with the first small piece and grows piece by piece, so problems surface early instead of all at once near the end.

Frequent releases are only sustainable with technical practices that keep the product releasable at any moment:

• Continuous integration: every change is merged and tested straight away, so the product stays working.
• Automated tests, including regression tests, run on each commit. Release frequency is limited by how fast the team can prove nothing broke, so a slow manual check becomes the ceiling on how often you can release. The lasting fix is to automate the check, not to shorten or skip it.
• Continuous delivery and an automated deployment pipeline, which make a release a routine step rather than a special phase.
• Test-driven development, which builds the automated safety net as the code is written.

Quality and feedback are linked. If frequent releases keep breaking things that used to work, users lose trust, stop trying new features and feedback dries up. The remedy addresses the cause, quality checks built into the pipeline, so the team keeps its release pace and regains trust. Other good practices help a team in other ways; the test for this task is whether a practice keeps the product releasable on demand.

A limited-exposure release puts an increment in the hands of a small group of real users first, so the team gets real-world feedback while a flaw affects only a few people. Common forms are a pilot with chosen customers, a beta with volunteers, and a canary release to a small share of traffic. Two things make it valuable: the feedback comes from real use in real conditions, and the exposure is kept small before any problem appears rather than repaired afterwards. (A split test also uses groups, but it is a comparison technique that may show each variant to a large share of users; see the next section.)

The enabling idea is that deploying is not releasing. Deploying puts code into production; releasing makes a feature available to users. Feature flags (toggles checked when the code runs) separate the two:

Because a flag controls availability through configuration, two things follow. Unfinished work can be merged and deployed continuously without anyone seeing it, which keeps integration frequent. And a public launch date limits the general release, not deployment: the code can be in production well before that date and switched on for a selected group, who can give feedback in the real system while everyone else waits.

Pick the feedback technique by the question you need answered: analytics tell you where and how many, watching and talking to users tells you why, and a split test tells you which option performs better.

Good investigations often combine techniques: data for "how many", short interviews or observation with the people concerned for "why". The order matters: understanding the problem comes before comparing designs, because a split test can only choose between the options you bring to it. And the feedback has to come from the people who use the product; a group that does not use it cannot stand in for those who do.

Feedback should arrive as often as increments do, from everyone who uses or depends on what the increment produces. If stakeholders see the product only at long intervals, the team builds months of work on assumptions between reviews. Reviewing each increment with those stakeholders as it is done lets them correct direction early. One-way communication such as status reports informs people but gathers no reaction, and approving requirements up front does not replace reacting to working product.

Make giving feedback easy for the people you need. When key users have little time, bring the increment to them on their terms, for example hands-on access they can use whenever it suits them with a quick way to comment, and save scarce meeting time for going deeper. The team's own cadence should not bend around one person's calendar, and a second-hand account of what users think is not the same as their own reaction to using the product.

Internal customers count. Support agents, operations staff and back-office users work with what the product produces or keep it running, and they often notice problems first: the help desk hears where people get stuck, and the staff who process the data captured find out quickly when it is incomplete. Give their observations a regular route into the team's cycle, tied to each release, so that the cause gets fixed in the product rather than worked around. Groups that neither use nor run the product have legitimate interests, but their feedback rarely prevents product rework.

Internal and external customers sometimes want opposite things: what is quicker for the customer can create work for the staff behind it, and the reverse. Both views are valid. Bring the groups together to solve for the whole flow, for example by establishing what is truly needed and when, rather than letting one side win by default or leaving a known conflict to surface after release.

Feedback is incorporated only when someone regularly reviews it, weighs it against the product goal and the evidence, turns it into ordered backlog items, and tells the people who gave it what happened.

• Review it on a rhythm. A pile of unread comments has been collected, not incorporated. Reviewing new feedback with the product owner as part of backlog refinement lets similar items be grouped, weighed and ordered alongside everything else, at the pace the team works.
• Weigh by representativeness and goal, not volume. Ask how many users a request really represents and how directly it serves the product goal. Volume can come from a few very active people, a single external trigger or one influential voice, so it is a prompt to check, not proof of broad need. A problem raised by a few people can still come first if it blocks the goal directly.
• Every request gets heard; the backlog decides its place. Record it and let it be ordered against the goal and the evidence, openly. Ordering is the product owner's responsibility, informed by stakeholders and the team; it is not settled by who asks most forcefully.
• Act when the evidence is clear. When the data already shows where most users struggle, putting focused effort there in the next increment teaches more than spreading it thinly or waiting for further confirmation.
• Close the loop, including "not now" and "no". People keep giving feedback when they can see what it changed. Announcing only what shipped leaves everyone whose request was deferred or declined in silence, and they conclude their input disappears. Tell each contributor the outcome and the reason, and show where deferred items sit in the backlog. Making feedback easier to give does not help if people believe nobody acts on it.