Giving and Receiving Feedback Questions

Direct answer

I would send a short, specific message that points to the exact screens, says why each issue matters to users, offers the fix as a small list, and invites the developer to say if the design was unclear. Then I would change the process so the checks happen before merge, not after.

Draft message

Hi Sam, thanks for getting the settings page into staging so fast. I went through it against the design and found two groups of things to fix before release:

1. Accessibility: the grey helper text on the card is lighter than the design (it measures about 2.85:1 against its white card, and the 4.5:1 contrast ratio that WCAG, the Web Content Accessibility Guidelines, ask for on normal text is the minimum), the icon-only delete button has no label for screen readers, and the focus ring disappears on the toggle. Low-vision users cannot read the helper text, screen-reader users cannot tell what the delete button does, and keyboard users cannot see where they are.
2. Spacing: the card padding is 12px where the design uses the 16px step, and the gap between the two sections is 20px instead of 24px.

Screenshots with the redlines are attached. If any of it was unclear in my spec, tell me and I will fix the spec. I can pair for 20 minutes tomorrow if that is quicker.

Terms in the message

• Staging: a test copy of the product where changes can be checked before real users see them.
• Contrast ratio: a number from 1:1 (text identical to its background) to 21:1 (black on white) that measures how easy text is to read. Light grey #999999 on white is about 2.85:1, which many people cannot read comfortably; #767676 on white is about 4.5:1, which meets the bar.
• Focus ring: the outline that shows which control the keyboard is currently on. Without it, a keyboard user cannot see where they are.
• Redlines: screenshots of the build marked up with the measured differences from the design, such as "12px, should be 16px".

Why this works

• It names what is wrong and where, so the developer does not guess.
• It explains the user impact for accessibility, so it reads as a requirement, not taste.
• It separates must-fix (accessibility) from polish (spacing) in how it is ordered.
• It opens by acknowledging the work and closes by owning my part, since a vague spec causes some of these misses.

Process changes so it happens less

1. Design tokens (named values like space-4 = 16px) shared between design file and code, so spacing is picked from a list, not typed in.
2. Accessibility in the ticket's acceptance criteria (the checklist a ticket must satisfy to count as done): contrast, keyboard path, labels and focus states are listed per screen.
3. Automated checks in continuous integration (CI), such as an accessibility linter (a tool that scans the page for common accessibility errors like missing labels or low contrast) on the component tests, so basic misses fail the build.
4. A 15-minute design review on the preview build before merge, owned by me, in place of finding issues after release.
5. A short handoff walkthrough for complex components, so questions come out before the build.

Trade-off

The design review adds a step for every UI change, so I would reserve it for new components and screens, and rely on tokens and automated checks for the rest.

Direct answer

I'll tell an illustrative story skeleton. A salesperson was telling customers a feature would ship by a date engineering had never agreed to, and my job as product manager gave me no authority over sales (no line authority: I could not assign his work, set his goals or affect his performance review). I framed it around a goal we shared (keeping customers' trust), gave the feedback privately and soon after the call, and agreed small follow-ups instead of a lecture.

Situation

In two customer calls the account executive (the salesperson who owns the customer relationship and closes the deal) said "that will be ready next month." The roadmap (the team's plan of what ships when) said the end of next quarter, which is months later than "next month". Engineering was being blamed for a promise it never made. I had no line authority over him, so the only tool was influence: getting someone to change by offering a shared goal, a concrete example, a way to make it easy and an offer of help, because I could not instruct him.

Framing and timing

• Shared goal first: "We both want this customer to renew and trust us."
• Timing: within a day of the call so the example was fresh, but not in the hallway or in front of the customer or his boss.
• Private, then involve others only if needed: I did not copy his manager. I invited him to bring the sales lead if he wanted, which kept him in control. If it had repeated after our agreement, I'd have raised it with both managers, telling him first.

What I said

"On Thursday's call you told them the export feature would land next month. The current plan is the end of next quarter. I think the customer will remember the date. If it slips, they blame both of us. I'm not saying you were careless; the roadmap changes and it's hard to track. What would make it easier to give dates you can stand behind?"

He asked for a one-page "safe to promise" list. That was the follow-up: I'd update it every Monday, and he'd check it before calls.

Following up on how he presents roadmap dates to customers

Later, on his customer deck, I offered a quick pre-read: "Want me to look at the roadmap slide before Wednesday?" Coaching by offer, not correction, kept the relationship warm. When I did read the slide, I said: "The date on this slide is the engineering target, not a commitment. If you label it 'target, confirmed on the 1st of each month', customers will not hear it as a promise, and you keep your credibility if it moves."

Outcome

Date promises matched the plan on the next calls, and he started asking me before quoting dates.

Pitfalls

Escalating first, giving feedback in public, and giving the feedback without an agreed way to help.