I wrote this yesterday.
We suck at looking at issues in isolation. But we're surprisingly good at looking at two issues side by side and saying which one feels worse.
And it's true. But someone pointed out that my entire argument was flawed, because I was still looking at one single class of issues: accessibility issues.
The argument went that it's simple to prioritise when all you have are accessibility issues. But in the real world, for any product, you have to prioritse issues from every category. As a product owner, you need to look at security, performance, new features, old bugs, your backlog, the roadmap, technical debt, what customers want now, what leadership wanted yesterday.
Accessibility is just one more thing competing for your attention.
And yes, that makes it harder!
But that's the job!
Your main job is prioritising. It's time allocation. It's people allocation. Resources. Preventing scope creep.
Your job is to deliver value. And to do that, you need to decide what gets built, in what order and why.
Delivering value doesn't always mean ship more. It could very well mean:
- Reducing risk
- Improving conversion
- Increasing user retention
- Avoiding wasted effort
- Reducing rework
- Protecting brand reputation
- Increasing customer lifetime value
- Reducing support costs
- Improving overall usability
- Making future development cheaper and faster
Accessibility touches almost all of these.
So then, how do you prioritise accessibility when everything is on fire?
You stop treating it as a separate category and start treating it as a quality dimension. It's not a feature. It’s not a "nice to have." It’s not a backlog epic.
Try to see it as a lens. Look through this lens when you decide on every other item.
- Does this introduce risk?
- Does this exclude users?
- Does this increase future cost?
- Does this create rework later?
The most effective prioritisation move you can do is to remove accessibility from prioritisation and make it a part of your acceptance criteria so it stops competing with features.