Teams without a design owner often pile up artifacts.
Interview notes.
Competitor boards.
Roadmap docs.
Nice Figma files.
What they still don't have is one person accountable for turning learning into shipped decisions, and for killing work that no longer deserves engineering time.
Founders feel that gap as a bottleneck. They often call it “we need more UX.”
Why this keeps happening
When product design has no owner, every stage becomes a handoff:
- Someone talks to users
- Someone writes tickets
- Someone ships UI
- Someone looks at analytics later
Each step can look productive.
Nothing connects them.
So the team rebuilds the same surface three times, debates screens in meetings, and ships features that get trimmed two months later.
Shipping more won't help if no one owns the decisions from discovery through ship.
Each stage can produce deliverables. That is not the same as owning the chain.
How it worked on SePoso
SePoso is a mobile-first Athens bus and trolley app that puts a daily commuter's arrival on the home screen without repeating the official line-first search.
Research did not live in a folder and die there.
One owner carried decisions through:
- Interview and survey design
- Competitor teardowns
- Jobs-to-be-done work and positioning
- What to build first when time was tight
- Soft-launch triage
- Analytics setup and reading the funnel
- Fixing arrival data when upstream feeds broke
- Iteration from session recordings and paid traffic
Someone had to keep answering the same question: what do we believe now, and what should we ship or cut?
A competitor teardown only matters if it changes the MVP.
A soft-launch note only matters if it changes a flow.
A funnel drop only matters if it leads to a product call, not a screenshot in Slack.
The calls we had to make
On SePoso, we focused on keeping decisions connected, not on collecting methods.
Frameworks were tools.
The hard part was knowing when to:
- Change the positioning
- Match competitors just to stay in the game
- Give new users a different path than returning users
- Treat a broken backend as a product problem
- Kill half-built features instead of polishing them
That is what teams mean when they say they need product design ownership, even if the brief still says hire a designer.
What to try next time
If you want to know whether design is owned on your team, ignore how many docs and decks you have.
Ask:
- Who can kill a roadmap item without a three-week debate?
- Who can tie research, a decision, a ship, and what happened after?
- Who is accountable when the wrong thing gets built?
If the answer to all three is “everyone” or “the founder by default,” the backlog keeps moving, but no one owns the chain from research through ship.
If this sounds familiar
If your team has plenty of process and still rebuilds the wrong things, another workshop template rarely helps.
Someone still has to own the decisions from research through ship.
If this kind of product judgment is what you're trying to install on your team, we're happy to talk. And if you know someone else who should be in that conversation, we'd love an intro.
