Who owns the user?
Clarifying roles: how government teams share responsibility for user needs.
In many government teams, both product management and design practices care deeply about the people they serve—but unclear lines of responsibility can create confusion, duplicated effort, and unnecessary tension.
Recent client work has shown just how common this challenge is: designers feeling stretched thin, product managers unsure where to lead, and both groups wanting to center users but lacking shared definitions and rituals to support that work.
User-centered outcomes improve when teams deliberately clarify who leads on what—and when they treat user needs as a shared responsibility rather than the domain of any single discipline.
When roles are clarified and responsibility is shared, teams can hold work—and the people it serves—with greater care. Effective collaboration isn’t about ownership; it’s about stewardship.
A quick note on language: Terms like “user” and “product” are used inconsistently across government. In many contexts, “user” isn’t the right term—teams are serving residents, communities, beneficiaries, or public servants themselves. Likewise, some government teams use “product” to describe any deliverable, while others practice formal product management.
For clarity, this piece uses “user” and “product” within the context of product-oriented government teams, while recognizing the limitations of both terms. The underlying principles—shared responsibility, thoughtful stewardship, and centering the people affected by our work—apply across many kinds of public-sector teams.
What we’re seeing in practice
Across engagements, including our recent workshop with HCD and product management teams, we’ve observed a consistent pattern:
Common pain points:
Blurred roles: Product, design, and research responsibilities overlap without intentional structure.
Design overextension: Designers often advocate for users, process, and outcomes simultaneously—leaving them depleted and limiting impact.
Unclear ownership: Teams aren’t sure who “owns” decisions related to user needs, feasibility, scope, or prioritization.
Vendor amplification: When roles aren’t clear internally, vendors often (unintentionally) fill the void, shaping priorities in ways misaligned with mission.
These are not failures of individuals—they are symptoms of teams evolving faster than their operating models.
We’ve seen similar role blurring surface across teams we’ve worked with, including in our earlier reflections on how product management and HCD practitioners collaborate in government.
Why this matters
Role ambiguity doesn’t just slow teams down. It impacts public outcomes by:
Dilutes accountability, making it unclear who should steward user needs or how those insights influence decisions.
Undermines trust, both within teams and with stakeholders.
Compromises user experience, especially when research and insights aren’t integrated early and consistently.
Reinforces inequitable systems, as unclear ownership leads to reactive decisions rather than intentional design.
Government teams don’t need perfect structures—they need shared language and clear lanes so they can collaborate with purpose.
A model that helps: lanes of responsibility
Based on workshops and government client work, we’re seeing success when teams adopt a simple lane model that clarifies leadership while honoring collaboration:
Engineering or technical SMEs lead on…
Feasibility
Architecture constraints
Implementation pathways
Collectively, the team owns user outcomes. No single lane or discipline can get there alone.
Design leads on…
User needs
Usability
Sensemaking and insight integration
Product leads on…
Viability
Prioritization
Balancing constraints across the ecosystem
How teams can apply this
Reinforce roles early and often: Teams benefit from hearing this more than once—especially during growth or organizational change.
Use shared vocabulary: Normalize saying “product,” “design,” “research,” and “user” consistently and intentionally.
Document the lanes: A simple one-page working agreement can prevent months of ambiguity.
Establish sprint rituals that reinforce clarity:
Set sprint goals at the outset
Embed evaluative research earlier
Use definitions of ready/done tied to outcomes, not just outputs
Pause for alignment: Intentional pauses prevent unintentional drift—a theme directly named by participants in our recent client workshop.
Closing
When product management and design treat user-centeredness as shared work—not competing territory—teams gain clarity, resilience, and collective purpose.
The question isn’t “Who owns the user?”
The question is “How do we design our lanes and practices so the user never gets lost?”
If your team is navigating similar questions around roles, collaboration, or user-centered practice, Public Servants offers support ranging from light-touch advisory conversations to facilitated workshops that help teams clarify lanes and design sustainable ways of working. We’d be glad to explore what might serve your team best. Contact us.
Related reading: Bridging the gap between product management and design in government to improve collaboration and outcomes.
