Turning repeated admin friction into a release the team could ship.

Support was carrying the cost of repeated workflow friction.

Charity administrators were encountering recurring friction in everyday workflows, and support was repeatedly compensating with explanation. The release already had a committed date, so the work needed a clear boundary rather than an open-ended admin redesign.

The first product task was to turn repeated signals into a shape the team could act on: identify what was product behavior, what was UX friction, what needed technical ownership, and what could still be validated within the release.

Five pain points were not five identical problems.

• Repeated support friction. The same workflow questions were appearing often enough to indicate product friction rather than isolated confusion.
• Different issue types. The five recurring pain points grouped into four UX issues and one technical issue, with different owners and validation paths.
• A fixed release boundary. The committed date meant scope had to stay focused while still addressing the highest-value admin friction.

Make support evidence usable for product, engineering, and QA.

I reviewed support and production signals, synthesized the recurring feedback, separated product behavior from the technical issue, and framed workshops around severity and ownership. I stayed close to engineering, QA, and UAT so the scope remained specific through release validation.

That structure avoided two failure modes: treating every complaint as a redesign request, or dismissing repeated admin friction because the release was already in motion.

Scope became something the team could release and verify.

The work produced pain-point grouping, severity framing, ownership paths, workshop notes, release-scope recommendations, user stories, acceptance criteria, and QA/UAT follow-through expectations.

The release shipped on time with the scoped admin fixes included. Support signals could be discussed as product behavior, UX friction, technical work, or escalation rather than as one undifferentiated queue.

The public result is clearer scope and a more reliable operating path.

The directly supported outcome is that five recurring charity-admin pain points were addressed within a release that shipped on time. The broader triage model connected product, support, engineering, QA, and ownership paths around severity and resolution.

Repeated support friction is product evidence when users keep paying the explanation cost.

The durable lesson was to treat operational friction as a product system: make the signal visible, define the decision categories, protect the boundary, and give every issue a path through validation.