03 · Product · One thing in the next version
The points mall can wait. Double posting cannot
The product owner owns the next version of a system already live. After go-live, the loudest request is often not the one that hurts most. He does not sign first-phase scope. Use facts come from product operations. Ticket classes come from technical support.
This version does: A paid order accrues points once. A refund reverses against the original order. Acceptance looks at orders, not mall skins.
Leave it: A nicer points mall, auto birthday coupons. While the books still double-post, those would hide the hole.
After release, watch: Duplicate accruals from a dozen a day to zero. Reversals trace to the original order. Then birthday coupons may be ranked.
Product owner and product manager are not the same decision
The product manager owns the first go-live's scope. The product owner takes a system people already use every day. The job is to classify feedback, not to drop a sentence from a group chat straight into development. He asks four questions first: does it hit the books, fulfillment, or only looks; how many times a day; is there a bypass around the system; would the fix change a rule already shown to customers. Ideas with no count go on a watch list. During the watch, data or support records fill the evidence. They do not take a version slot.
If a version mixes defects, rules, and wishes, after release no one can tell whether to celebrate or roll back. The product owner requires a version to answer one question. That question is a countable result: duplicate accrual orders go to zero — not "points experience improved". Experience cannot be falsified the next morning, so the team stays forever in the next version still needing to improve.
Feedback comes from classified records, not forwarded chats
A WeChat a salesperson forwards usually keeps only the angriest line. The product owner requires the source to be the three classes Technical support already split: defect, miss, and wish. Defects enter the fix queue and reproduce by order number. A miss first changes help or privilege, not the rule. Wishes enter candidates and are compared with harm already happening. Unclassified feedback he returns to support, not to development. Development given an unclassified sentence will ship a compromise button nobody likes.
His boundary with product operations and campaign operations is equally clear. Operations may propose a birthday coupon. They may not hand the coupon's rules straight to development. The rules pass the product owner: which order state the coupon stacks on, whether a refund returns the coupon, how many times one member may claim in a day. If those are unwritten, an accident on campaign day will be called an unstable system. It was a rule that never entered the version notes.
Kandiantong points: the payment callback arrived twice
Two weeks after the membership system went live, a store manager found the same payment sometimes produced two point lines. A mall redesign was also in the queue, because HQ thought the page looked old. The product owner pulled fourteen days of point ledger, grouped by order number. The thirteen duplicates all mapped to two payment-success callbacks, same amount, a few seconds apart. Some refunds reversed; some did not, because reverse logic recognized only the latest line, not the order.
The next version therefore does two things, and they are two faces of one rule: payment success on the same order accrues once, with the order number as the idempotency key; a refund must find the original accrual and write a reverse, and must not subtract a nearby-looking number from the member balance. Mall skin and birthday coupons go on the watch list. After release he watches not time on page, but duplicate order count and reversals that cannot join the original order. Both stay at zero for seven days before birthday coupons may be ranked. If coupons go first, duplicate points become money customers already spent, harder to chase.
Failure for this role looks like a long roadmap where every version does a little. Success looks like the business owner being able to name which hole the last version closed.