Merchant requests can conflict because merchants operate different businesses. A small owner-led store may value a quick recommendation, while an operations team needs permissions, traceability, and coordination across roles. Averaging those requests can produce a product that serves neither group well.
Prioritization should begin with the customer job and operating context, not a vote count across incompatible segments. The goal is to choose which problems the product will solve coherently and which it will deliberately leave outside its present scope.
Segment by the work that changes the requirement
Company size can be a useful clue, but it is often too broad. Consider order complexity, number of operators, channel count, frequency of exceptions, decision authority, and the systems involved. Two businesses with similar revenue can have very different workflows.
Use segmentation dimensions only when they explain a meaningful difference in the problem or solution. An elaborate classification that does not change product decisions adds administrative work without improving focus.
Keep each request attached to its context. “Needs approval” means something different when a single owner wants a reminder than when several staff members require restricted authority over transactions.
Compare problems within segments first
Estimate frequency, consequence, current workaround, and evidence quality for each problem. A frequently requested convenience should not automatically outrank a less frequently reported task blocker. Users may not report a barrier if they have already stopped using the product.
Do not convert every dimension into an arbitrary precise score. A small number of well-supported comparisons can be more useful than a ranking built from guessed numbers. Mark uncertainty explicitly.
Then examine which problems genuinely overlap across segments. Shared vocabulary is not sufficient; the trigger, input, decision, and required outcome should be similar enough for one product capability to serve them.
Identify where one solution creates opposite effects
An automatic action may save an owner time while violating a larger team’s review process. A detailed audit trail may be essential for one group but overwhelming as the primary interface for another. These are design tensions, not evidence that one group is wrong.
Possible responses include a shared core with different interaction depth, an optional control, or a deliberate focus on one segment. Avoid adding configuration for every disagreement before understanding whether the underlying jobs are compatible.
Each option carries maintenance and explanation costs. A setting is not free merely because it occupies little screen space; it can multiply testing states and support questions.
Choose an explicit product boundary
Write which segment and job the next release is intended to serve. Name the important use cases it does not support. This helps sales and support avoid turning interest from another segment into an accidental commitment.
The boundary can change with evidence, but it should not change silently whenever a persuasive prospect appears. Record the opportunity cost of serving a new segment: which existing work, reliability effort, or learning would be delayed?
A custom request may still be worthwhile if it fits a broader direction and has manageable dependency costs. The decision should explain that fit instead of treating one customer’s willingness to pay as universal product validation.
Validate the proposed overlap
Use representative tasks from the segments thought to share a capability. Test both ordinary and exception states. If each group needs a different definition of success, the shared feature may need a narrower boundary.
Review actual use rather than only preference. A merchant can appreciate a demonstration without incorporating the capability into regular work. Look for task completion, repeat use when the need recurs, and the amount of assistance required.
Keep small pilot findings proportional to their scope. They can support the next bounded decision without proving broad market demand.
Maintain a decision record
The record should include the target segment, problem, evidence, chosen boundary, excluded cases, and reconsideration trigger. This reduces repeated debates when an old request returns with a new name.
For a practical problem-to-decision workflow, see the MerchNivo evaluation plan. For shared capabilities that should remain local to a project, read Oryvelon platform boundaries.