How to Budget for Product Changes After Your First Customer Feedback

Treat feedback as evidence, not an order

Do not commission every feature a customer suggests, or budget only for the effort to build it. First establish the problem the customer is trying to solve, then decide whether it is urgent, supported by evidence and a fit for the product before choosing what to fund.

When feedback arrives, record the customer’s task, what stopped them and the outcome they needed. Keep their suggested solution separate from that account: a request for a new dashboard, for example, may point to a difficulty finding information rather than a need for another screen. That distinction helps you assess the problem before committing to a particular change.

Next, check the likely consequence of leaving the problem unresolved, whether other customers or product evidence point to the same issue, and whether addressing it supports the product’s intended users and direction. A single request can still merit attention, especially if it exposes a defect or blocks an important task, but it is not by itself proof that a new capability should be built.

Use those checks to choose a proportionate next step: investigate an uncertain problem, fix a defect, try a low-cost workaround, commission a scoped change, defer the decision to a review point or decline the request. If work proceeds, budget for the whole change: discovery, design, implementation, testing, release and follow-up. Also note whether it creates continuing needs, such as support, maintenance or hosting, so the decision reflects more than the initial build.

Rather than treating an early allowance as permission to spend it all, manage change funding as a rolling budget. Decide what can be committed now, what needs more evidence and when deferred items will be reviewed. At each review, compare new feedback and the work already under way with available funds and the product’s priorities. This gives you a repeatable way to respond to customers without allowing every request to become a commitment.

Find the problem behind the request

Before assigning budget to a request, write down what the customer was trying to do and what got in the way. Keep the reported problem separate from the solution they suggested: a request for a dashboard, for example, may really be about not being able to find the status of a task.

Capture the customer or account, the task, the context in which it happened, the obstacle and the effect on their work. Note whether they were using a particular workflow, data set or device, and what they expected to happen. If the report came through a support message or sales call, preserve the wording and ask the person who received it to record any missing context. This gives the product owner something concrete to compare with later reports, rather than a list of feature ideas detached from the circumstances.

Follow up with open, neutral questions. Ask the customer to describe what they did immediately before the problem, what they saw, what they expected instead and how they handled it afterwards. Where appropriate, ask them to show the workflow or share a redacted example of the information involved. Avoid questions that put a proposed solution in their mouth, such as asking whether a particular button or report would help. Instead, ask them to describe the obstacle and the outcome they need.

Then classify the report. A defect is a case where an existing, intended task does not work as expected; a new capability is something the product does not currently offer. A usability problem may mean the task is possible but difficult to find or understand. A one-off preference may suit one person without helping the customers the product is designed for. A request outside the intended scope may be valid for that customer but pull the product away from its purpose. These categories can overlap, so record the uncertainty rather than forcing an early answer.

Look for repetition across customers and situations. Two reports about the same obstacle may point to a shared problem, while similar requests can have different causes. A single report should not automatically be dismissed: consider the consequence if the issue remains, and whether it blocks an important task or creates a serious operational risk. Assess whether the underlying need is shared beyond the person making the request. Check whether the person is a customer the product is intended to serve, and whether their need supports or challenges the product’s direction.

When the cause, scale or product fit is unclear, turn the assumption into a research question before commissioning a solution. For instance: “Can users complete this task unaided?” is more useful than “Should we build a new screen?” Choose a proportionate way to answer it. You might review support conversations, observe a customer attempting the task, or ask a small number of relevant users to explain their workflow; use the least burdensome approach that can give useful evidence. GOV.UK guidance recommends turning assumptions and opinions into research questions and choosing research activities that provide strong evidence and reliable answers for the least time, effort and cost.^{1, 2}

Record what evidence would change your decision. If the issue appears to be an existing product failure, verify the expected behaviour and pass the reproduction details to whoever investigates defects. If it is a new capability, establish who needs it and what task it would enable. If more evidence is needed, state the question and the next check. This makes it easier to judge later whether the feedback supports a fix, further investigation or no change, without treating the customer’s first proposed feature as the only answer.

Choose a next step with a feedback-to-budget decision tree

Start with the customer’s reported problem and the task they were trying to complete. Treat the proposed feature as one possible response, not the decision itself. Then follow the branches below, recording the reason for the route you choose and what evidence could change it.

Is an intended task broken, or is there a material immediate risk? Check what happened, who is affected and whether the customer can complete the task another way. If a core workflow fails, information is being handled incorrectly or the issue could cause significant harm to the business or its users, assess promptly whether a defect fix or another protective action is needed. Confirm the scope before committing: reproduce the problem where possible, identify the affected workflow and agree what a successful fix would look like. Return to the decision if investigation shows the issue is isolated, cannot be reproduced or has a different cause than first reported.

If the task still works but the customer is asking for a new capability, continue to the evidence check rather than treating the request as urgent by default.

Do you know how often the problem occurs and what it costs the customer? Look for examples from actual use: which step is difficult, whether it blocks completion, how often it happens and whether other customers encounter it. If the impact, frequency or cause is unclear, investigate before commissioning a larger change. Set a bounded question for that work, such as whether users abandon the task at a particular step or whether an existing setting would solve the obstacle. Decide who will gather the evidence and what finding would justify moving to a change. If the investigation finds little impact, close the item or defer it; if it confirms a repeated obstacle, reassess the case for action.

Could a lower-commitment option test the need? If the problem is credible but a custom change is not yet justified, trial a manual workaround or an existing configuration. For example, the team might carry out a step manually while the customer completes the rest of the workflow, provided this is manageable and does not create unacceptable operational risk. Agree who will do the work, what to observe and when to review it. Continue only if the workaround shows meaningful value and remains workable; stop or investigate further if it creates errors, delays or extra effort that outweighs its benefit.

Does the evidence support a change that fits the product’s direction? If the problem is sufficiently understood and the proposed outcome supports the product’s intended users and workflows, commission a scoped change. Define the outcome in terms of what the customer needs to do, rather than prescribing a feature before the solution is assessed. Consider a smaller first step or staged release where it can test the assumption before more work is committed. Move back to investigation if the scope depends on unresolved assumptions; reconsider or stop if the proposed solution cannot deliver the agreed outcome.

If the request is weakly evidenced, a poor fit or disproportionate to its likely value, defer it or decline it. Record the reason and, for a deferral, a named review point or trigger, such as further customers reporting the same obstacle or a change in the product’s priorities. Reopen the decision if that evidence or circumstance changes. Otherwise, leave it unfunded rather than allowing an unreviewed request to become a standing commitment.

Estimate the whole change, including what continues

Compare proposed changes by the full work they involve, not just the time needed to build them. A small interface change can still require investigation, content decisions, testing and release work; a more substantial change may also affect integrations, existing data or ongoing product operations.

Start by asking whether the problem is clear enough to scope. If the feedback does not show where a customer gets stuck, what they are trying to do or how the issue affects them, budget for discovery before committing to a solution. That work might involve reviewing the customer’s account or workflow, speaking with the person who reported the issue, or checking how the product currently behaves. The aim is to confirm the problem and identify the smallest useful change, not to commission a broad feature based on an assumption.

Then account for the work around the change. If it alters a customer journey, interface or the information customers need, include design and content work as well as implementation. If it connects to another service or changes how existing information is handled, ask the supplier to include the relevant integration or migration effort. Make clear which parts are understood and which depend on investigation, so an estimate does not make uncertain work look settled.

Ask for testing and release activities to be visible in the estimate. These may include checking the change against the agreed behaviour, correcting issues found, preparing the release, deploying it and confirming that it works as intended afterwards. Also decide who will tell the affected customer what has changed and who will gather follow-up feedback. Without an owner, a change can be released without anyone checking whether it addressed the original problem.

Separate one-off delivery work from what may continue after release. Depending on the change, ongoing implications could include customer support, maintenance, monitoring, hosting, storage or charges for a third-party service. Ask which of these apply, what might cause them to change and who will review them. For example, a new integration may need someone to respond if information stops syncing, while a change that stores more customer information may affect storage needs. These are operational questions to clarify, not costs to assume away.

Include software upkeep in the operating plan as well as the initial change budget. The NCSC advises organisations to apply software updates as soon as possible, ideally automatically. ³ Ask who is responsible for applying updates to the product and any connected services, and how that work will be checked alongside the change.

For each estimate, record the scope, assumptions, exclusions and any unresolved questions. Show discovery, design, implementation, testing, release and follow-up as distinct parts where useful, and separate one-off effort from recurring operational implications. Name the person responsible for ongoing support and review, whether that is someone in the startup or a supplier. This gives you a more useful basis for comparing a proposed change with other priorities, and makes clear what you are committing to now versus what still needs investigation.

Prioritise changes against value, risk and runway

Once the next step for each feedback item is clear, compare the candidates against the same practical questions. A change may solve a painful problem but still be a poor use of funds now if the evidence is thin, the work is uncertain or it creates obligations the business cannot support.

For each candidate, record the expected effect on the customer’s task: what becomes easier, safer or possible, and for whom? Note how strong the evidence is, such as whether the problem has been observed directly or is based on a single request. Then assess whether the change supports the product’s intended direction, rather than adding a capability that pulls it towards a different market.

Make uncertainty and risk visible instead of hiding them inside a confident estimate. For example, a proposed integration may depend on access to another system or on a workflow that has not yet been confirmed. Record what needs checking, what could change the scope and what ongoing support or operating work the change may create. Include the consequence of waiting: a workaround may be acceptable for now, or delay may leave an important customer task blocked.

A short written rationale is more useful than a single score that makes unlike considerations look comparable. For each item, capture the problem, evidence, expected value, product fit, key unknowns, estimated effort, continuing obligations and the reason to act or wait. This gives the founder or product owner a basis for discussion with whoever will fund, design, build or support the change.

Use that rationale to divide the rolling list into four decisions: fund now, investigate before deciding, defer to a named review point, or decline. Fund now only when the expected benefit and evidence justify the full commitment alongside other priorities. If the evidence is weak, budget for a proportionate investigation rather than commissioning the whole change. A deferral should have a trigger, such as new customer evidence, a change in business priorities or available delivery capacity; otherwise it can become an unexamined promise.

Protect runway by looking at the combined commitment, not just the next build task. A change that appears manageable in isolation may compete with essential maintenance, other planned work or the capacity needed to respond after release. If an ongoing cost or support responsibility has no clear owner, resolve that before approving the work.

Set a decision point before authorising further scope. After an investigation, workaround trial or first release, review what was learned, whether the customer problem remains, and whether the expected impact justifies the next commitment. Revisit the list when evidence, priorities, capacity or ongoing costs change. That keeps the budget responsive without treating every new request as an automatic addition to the product.

Request a useful estimate and stage the commitment

Give a supplier enough context to estimate the outcome, not just the requested feature. Share who encountered the problem, what they were trying to do, where the task broke down, what impact it had and what evidence you have gathered. Include relevant constraints, such as a deadline, a limited budget, existing systems the change must work with or work that your own team can take on.

Describe the intended result in observable terms. For example, state what a customer should be able to complete, or what information your team should be able to see, after the change. Avoid acceptance criteria such as “make it easier”; instead, define the task or outcome that would show the change is usable. If the evidence is still uncertain, say so rather than presenting an assumption as a requirement.

Ask the supplier to set out what the estimate includes and excludes, the assumptions it depends on, any dependencies and the parts they consider uncertain. The estimate should cover the relevant stages of work, not only implementation: discovery, design, testing, release and follow-up may all need to be accounted for. Ask what could alter the effort and whether a short discovery stage would clarify the scope before you commit to delivery.

Compare proposals by their scope and assumptions, not by the headline effort alone. One estimate may include testing or release support that another excludes. Check who will make decisions, provide access or supply content, and whether any work is expected from your team. Ask how proposed stages can be approved separately, and what you will have to decide at each review point.

Before commissioning custom development, consider whether an existing configuration, a manual step or an existing product could address the problem adequately. A workaround may be proportionate while you gather evidence; it may also introduce extra handling or operational work, so make its owner and review point clear. If important uncertainty remains, fund a focused investigation or small trial first, then decide whether to expand, change direction or stop.

Record the chosen scope, assumptions, exclusions, continuing support or operational responsibilities, and the point at which you will review the decision. This framework works with an in-house team or another supplier as well as DevAgency. If you have a prioritised change or roadmap to scope, you can Discuss your SaaS project as a next step.