When a Client Asks for 'Just One More Feature' Mid-Project

The Problem: A 'Small' Feature – Should You Take It?

You're halfway through a project. The client or your boss says, "It's simple – just add an Excel export. Two days, right?"

Sounds small. But anyone who's managed projects knows these "small" features are often the beginning of scope creep. Worst case: you accept, the team works overtime, testing reveals format issues, permission problems, and ongoing maintenance costs. Delivery slips, quality suffers, and the client is still unhappy.

Rejecting it risks offending the client or looking incapable.

This is the classic dilemma for a small-team PM. We don't have the process or commercial teams to shield us, nor the resources for a detailed impact analysis. But because we're small, we must decide fast and focus energy on what matters.

My Rule: Ask Four Questions First

When I led projects at Wangri Shiguang and Shanhe Network, I faced this repeatedly. I eventually developed a simple framework – no complex tools, just a notebook. Whenever a midsprint request came in, I asked four questions:

1. Is this feature necessary for the current project goal? If it's part of the contract or requirements doc, it's not a change – it's a gap to fill. If it's purely outside the original scope, move to the next question.
2. What is the impact on the current schedule? Not just "how many dev days?" but "will this delay any critical milestone?" If yes, what will be pushed?
3. What is the testing and regression cost? Small teams often count only development. An export feature may involve multiple fields, permissions, edge cases – testing can take longer than coding.
4. What is the cost of rejection? Will the client be angry? Threaten future work? Or is this a "nice-to-have" that doesn't affect core usage?

These four questions don't need perfect answers, but they quickly reveal the risk level.

A Hypothetical Example

Suppose we're building a CRM for a client. Core features are customer management and follow-up logs. Week three, the client says, "Can you add an export-to-Excel feature for the customer list?"

Sounds simple. But the real impact:

• Export fields need confirmation (the UI shows only some fields; should export include all?)
• Permissions: not all roles can export – need role checks
• Data volume: if thousands of records, export may need pagination or async processing
• Testing: empty data, huge data, permission interception – at least 3-4 days of testing

If we accept, the original plan's reporting optimization and user training get squeezed. Unless we negotiate: either delay delivery or drop a feature of equal effort.

Decision Framework: Accept, Negotiate, or Reject

Based on the four questions, I map to three options:

1. Accept

Condition: feature is small, necessary (without it the project can't deliver), and you have clear schedule slack with low testing cost. Action: immediately adjust the timeline, inform the team, and record the change.

2. Negotiate

Condition: feature is valuable but will clearly impact schedule or quality. Action: explain the impact to the client and offer choices:

• Option A: accept the feature with a delay of X days
• Option B: keep the original date but drop or replace an existing feature to keep total effort constant
• Option C: defer this feature to phase two, complete the current scope first

Key: don't just say "no." Say "if we add this, here's what we'll have to sacrifice." Let the client understand the trade-off.

3. Reject

Condition: feature is unrelated to core goals and carries high risk (e.g., introduces technical debt or security issues), or the client is just casually asking and won't be unhappy without it. Action: politely explain why not, and offer a workaround (e.g., use existing features, manual export).

A Practical Checklist

To avoid ad-hoc decisions, I later created a short checklist I shared with the team before the project started:

• Is this request outside the original scope?
• If accepted, which existing tasks need to be rescheduled?
• What is the minimum testing and regression time?
• Is there a workaround (e.g., using existing features + manual steps)?
• How reversible is this feature? Can we easily remove it later if needed?
• Is the client willing to pay extra for this feature?

That last question is crucial. If they're willing to pay, the feature is genuinely important to them, and it gives the team buffer. If not, it's likely a throwaway request.

Final Thoughts

For small teams, the real enemy isn't a lot of requests – it's the accumulation of individually small ones that become uncontrollable. Instead of deciding by gut every time, build a simple decision habit early.

This framework isn't perfect, but it gives you a clear stance with the client, your boss, and your team. Next time someone asks for "just one more little feature," pause, ask yourself four questions, and confidently choose to accept, negotiate, or reject.

PaxLee