Turn customer requests into product rules teams can use

Why messy requests become custom work

A messy request rarely arrives as a clear rule. Sales talks about what might close a deal. Support talks about the complaint they need to stop today. Founders talk about urgency, risk, or a promise already made. Often they are pointing at the same need, but the wording changes, so the team treats each request as a separate problem.

That is how custom work starts. One customer asks for "manager approval before large refunds." Another wants "finance review on credits above a limit." A third asks for "sign-off for unusual returns." Those requests might all point to the same thing: approval thresholds. If nobody pauses to compare them, the team builds for the loudest request and calls it done.

That feels fast. It also creates debt quickly. When teams skip the pattern check, engineers still have to ship something, so they fill the gaps with flags, hardcoded exceptions, extra fields, and side logic. Each shortcut solves today's problem and makes the next request harder to judge.

The damage is quiet at first. Similar requests get buried in sales notes, chat threads, and tickets. Engineers invent rules on the fly because nobody wrote them down. Product decisions lose context after a few weeks, so the same debate keeps coming back.

Soon every new ask has to be compared against a pile of old exceptions with different names and half-remembered reasons. At that point, the team cannot tell whether a request fits an existing rule or needs new work.

A short pause between hearing the request and building the fix changes a lot. Ask three simple questions: what is the real constraint, who needs to approve it, and have we seen this before? That small habit cuts custom logic and gives engineering something stable to build.

What a product rule looks like

A customer request is a story. A product rule is the repeatable part behind the story.

If a customer says, "We need manager approval for refunds over $500," the rule is not about that one refund. The rule is that a certain action needs approval when it crosses a set limit.

Teams usually slip here. They write the request exactly as it came in, then engineering builds a special case around one customer, one deal, or one support ticket. To get to a real rule, strip out the names and the urgency. Keep the pattern.

A good rule answers four things: who it applies to, what triggers it, what limit or condition matters, and what happens next if the rule blocks the action.

That last part gets missed all the time. "Block this" is not enough. The product still needs to decide what the user sees. Does it show an error? Save a draft? Send the item for approval? Ask the user to change something first?

Plain language works best. Avoid vague notes like "enterprise exception logic" or "custom finance flow." Write the rule so anyone on the team can read it once and understand it. For example: "Sales reps can give up to 10% discount on standard plans. Finance must approve discounts above 10%. If approval is missing, the quote stays in draft and the rep sees 'waiting for finance approval.'"

That is a real rule. It names the user, the trigger, the limit, and the result. Design, engineering, support, and sales can all work from the same sentence.

If you cannot say who the rule affects or what happens when it blocks an action, you do not have a rule yet. You still have a request. That sounds like a small difference, but it is often the line between a clean product and a product full of special cases.

Find repeated constraints in customer asks

Most customer requests sound unique at first. After a few calls, many of them shrink into the same small set of constraints: who can do something, when they can do it, where it applies, and what limits matter.

A simple sorting pass helps. "Managers need to edit invoices after approval" mixes role and timing. "Orders over $5,000 need sign-off" is a limit plus approval. "German customer data must stay in the EU" is a location rule.

When you review notes, look for phrases that keep coming back even when customers describe them differently. One account says "only supervisors can reopen a case." Another says "agents should not undo a closed ticket." The wording changes, but the underlying rule is almost the same: a restricted role controls that action.

Most repeated requests fall into a few plain buckets: limits such as price caps, seat counts, file sizes, or usage ceilings; timing rules such as before approval, after shipment, or within 30 days; role rules that control who can act; and location rules tied to country, tax zone, warehouse, or region.

A useful test is simple. If three different customers described the same problem in three different ways, would your rule still hold? If yes, you found a pattern. If no, you probably captured a preference, not a product rule.

Custom requests still matter, but they do not deserve product changes on day one. Put them in a separate note, track whether they repeat, and wait for a real pattern. That pause saves teams from shipping exceptions that only one customer wanted and everyone else has to live with later.

This is where founders and product leads often get pulled off course. They listen to the loudest request, not the repeated one. Frequency beats volume. A quiet constraint that appears in six accounts usually matters more than one urgent custom ask from a single deal.

Map approvals before work starts

Most messy requests do not fail because the idea is bad. They fail because nobody knows where the decision begins, who can stop it, or what proof they need before they say yes.

A simple approval map fixes that. Start with the first request and follow every handoff until the team either turns it into a product rule or rejects it. Write down each step, even if it feels obvious. The steps people skip on paper are usually where extra exceptions sneak in.

You do not need a big system. One small table is enough if it shows the step in the flow, the role that approves or rejects it, the trigger that starts the review, and the evidence needed to decide.

The trigger matters as much as the approver. "Finance approves" is too vague. "Finance approves when the request changes billing, pricing, or contract terms" is usable. Now the team knows when to involve finance and when not to.

The evidence needs the same level of detail. Do they need a signed contract, three customer examples, a support ticket pattern, or a security note? If you skip that part, people approve based on memory or pressure.

A short example makes it clear. A customer asks for two managers to approve any account deletion. Sales logs the request. Support checks whether similar requests have appeared before. Product reviews whether the rule fits more than one customer. Security weighs in if the change affects access control. Engineering starts only after those notes are attached.

This kind of map does two useful things. It makes ownership clear, and it kills weak requests early. Some asks should end before a meeting ever happens because they lack evidence or repeatability. That saves time and keeps engineering out of debates that other teams should settle first.

Keep a change log so context does not vanish

Teams forget fast. If a rule changes and nobody records it, the same debate returns in the next sprint, the next support ticket, or the next sales call.

A simple change log fixes that. One shared page or table is enough if everyone can find it. Each entry should include the date, the decision, and the person who owns the rule now. That owner matters because engineers, support, and sales need one person to ask when edge cases show up.

Do not stop at the rule itself. Add one or two plain sentences explaining why it changed. "Three enterprise deals asked for manual approval above 500 seats" is much better than "updated approval logic." That short reason keeps future readers from guessing whether the change came from a legal need, a pricing issue, or a pattern in customer requests.

Keep the old rule next to the new one. That view saves time. People can see what changed without digging through chat, tickets, or old specs. It also helps when someone asks, "Was this always the rule?" In many teams, that question burns more hours than the change itself.

Add one small impact note under each decision so other teams know what needs updating. That might include product docs, support macros, onboarding notes, sales material, code, tests, or admin tools.

This is a common failure point. Engineering updates the code, but support still uses the old answer and sales still promises the old behavior. The log should stop that split before it spreads.

A good entry can stay short:

2026-04-10
Owner: Product manager
Old rule: sales could approve custom onboarding discounts up to 20%
New rule: finance must approve discounts above 10%
Why: margin dropped on five recent deals with long onboarding time
Update: pricing doc, support refund script, checkout logic, test cases

If the team checks this log before work starts, fewer "special exceptions" slip into the product.

Use a simple rule format

Start with one request that keeps showing up. If the same limit, exception, or review step appears in several customer conversations, stop treating it like a custom favor.

A useful rule has four parts: actor, action, condition, and result.

That format keeps the rule short and testable. It also strips out the clutter that fills meeting notes, such as background stories, sales pressure, and one customer's preferred wording.

Take a messy note like this: "Big refunds should get checked first because finance wants control and one customer had a problem last month." Cleaned up, it becomes: "A support agent can submit a refund. If the refund amount is over $500, a finance manager must approve it. If it is $500 or less, the system sends it without approval."

Add a human approval step only when someone truly needs to make a judgment call. If the rule depends on a clear number, status, or date, the product should handle it automatically. People should review fraud risk, policy exceptions, and unusual cases, not routine actions.

Then test the wording against a real request from your notes. If product, sales, and engineering read the rule and give different answers, it is still too loose.

Three quick checks work well. One person should be able to tell exactly when the rule starts. Engineering should be able to build it without hidden context. QA should be able to test the outcome with a yes or no result.

When that is true, hand engineering the rule by itself. Do not bury it inside a long story with side comments like "the customer is important" or "sales promised this fast." Keep those details in the change log. Engineering needs a rule they can build, test, and maintain.

A quick example from sales call to product rule

A sales rep hears a familiar request: any refund over $500 needs manager approval before the payment goes out. If the team treats that as a custom ask for one account, engineering will probably add a quick exception and move on.

Then support brings in two more cases. Another account wants approval over $300. A third wants it over $1,000. The numbers are different, but the pattern is the same. Refunds above a certain amount need an approval step.

Now the work changes. Instead of building "Account A needs extra approval over $500," engineering builds one approval flow that checks a threshold, sends the request to the right person, and records the decision.

The shared rule can stay simple: the action is a refund, the condition is that the amount is above an account threshold, the approver is a manager or finance lead, and the result is that the refund waits for approval.

This saves time in quiet ways that add up. QA tests one path instead of three slightly different versions. Support can answer the next customer without asking engineering. Sales stops promising exceptions that later turn into permanent baggage.

The team should also add one short note to the change log: "Added refund approval rule after repeated requests from three accounts. Threshold and approver are configurable by account."

That note matters later. If someone asks why the refund flow feels stricter than before, the team has the reason, the date, and the pattern that triggered the change. More important, engineering owns one clean workflow instead of logic for one account that nobody wants to touch three months from now.

Mistakes that create special cases

Most custom work does not start with bad code. It starts when a team treats a loud request as proof that the product needs a separate path.

One common mistake is treating every big customer like a new branch of the product. Sales promises a custom approval step, support asks for a hidden setting, and engineering adds a flag just for that account. After a few rounds, nobody knows which behavior is standard and which behavior exists only because one deal felt urgent.

Another problem is where the rule lives. If the decision stays buried in a chat thread, meeting note, or someone's memory, the team will replay the same argument later. People leave. Priorities shift. The original reason disappears. Then a simple request turns into guesswork.

The most expensive mistakes usually look small at first. A temporary workaround stays in production for six months. Two managers approve exceptions, but no one owns the final call. Engineering builds custom logic before anyone checks whether the request repeats. The team changes behavior and never records why.

Temporary fixes and permanent product logic should not blur together. A workaround for one customer might be fine for a week, but it should not quietly become part of the product. Label it, give it an expiry date, and decide who removes it. If nobody owns that cleanup, the workaround becomes policy by accident.

Ownership gaps create another mess. When no one owns exceptions, teams argue later about who approved them, who pays for them, and whether they apply to future customers. That argument usually starts after engineering has already shipped something, which is the worst time to have it.

A better move is boring but effective. Write down the condition, the approver, and the reason. Then ask one plain question: does this happen often enough to become a product rule? That question blocks a surprising amount of waste.

Checks before engineering starts

A rule is not ready if it still depends on memory, habit, or a quick chat. When that happens, engineering fills the gaps on the fly, and a customer request turns into custom behavior nobody meant to keep.

Use a short review before anyone writes code. It takes a few minutes and saves a lot of cleanup.

Ask two people to read the rule on their own and answer the same example. If one says "approve" and the other says "escalate," the wording is still loose.

Check that the rule names the trigger, the condition, and the outcome. A team can build "When a contract value is over $10,000 and the buyer asks for custom terms, send it to legal review." They cannot build "large deals may need extra review."

Write down who can change the rule. Name the role, not "the team." If sales, product, and finance all think they can edit it, the rule will drift.

Then hand the rule to support and ask them to explain it without private caveats or a second document. If support cannot explain it cleanly, customers will get mixed answers.

A good test is boring in the best way. Different people read the rule and reach the same result. Support can explain it in one pass. Engineering can point to the exact trigger and outcome in the ticket.

If any part fails, stop and rewrite the rule before development starts. Ten minutes here can save a sprint of cleanup later.

What to do next

Pick one messy workflow and use real requests, not a blank template. Five recent examples are enough to spot repeated constraints, missing approvals, and fuzzy ownership.

Rewrite those requests as simple rules. Each one should say what the customer wants, what condition must be true, who approves it, and what the product should do. Review them with one person from product, one from support, and one from engineering. Give the group 30 minutes. If they argue about the same sentence, you found a rule that was never clear.

Store the rules in one place. Add an owner, the date, and a short note every time something changes. Then watch exceptions for the next two weeks. If the same exception shows up again, turn it into a rule or reject it on purpose. Do not leave it in someone's memory.

This does not need heavy process. A shared doc, a small table, or a ticket view can work if the team actually uses it. What matters is that everyone can answer three questions quickly: what is the rule, who owns it, and when did it change?

If your team keeps hitting the same wall, outside help can speed things up. Oleg Sotnikov works as a Fractional CTO and startup advisor, and oleg.is is where he shares his work with startups and small businesses on product architecture, technical decision-making, and AI supported development.

If you do only one thing this week, rewrite five recent requests and review them together. You will probably find at least one rule your team thought was obvious but never wrote down.