The cutting edge

3 minutes read

Lots of product teams want to live on the cutting edge.

They want to use the latest framework, even when they just finished writing their product in another. No matter they didn't launch to market yet. No matter they have no users and no real feedback so far. No. It's got to be rewritten in the latest and greatest.

No one asked for it and they most probably don't need it, but they throw in AI into their product as well. Why? Because that's where the market is going. Because they fear the competition will do it first. Because it's a buzzword right now. Again, no user feedback, no real need. It just needs to happen.

They obsess over microservices when a monolith would get them to market in half the time. Suddenly their three-person team is managing 12 different services, each with its own deployment pipeline, its own monitoring, its own shit that can break at any time. They're not Netflix and don't handle a billion requests. They're handling zero, because they're still building and somehow they figure kubernetes is the thing they absolutely must have.

All this because it's cutting edge.

It's called the cutting edge because it's painful. You're among the first to hit every rough edge. Every bug that hasn't been documented yet. Every breaking change between versions because the API is still "experimental." The tooling is immature. The docs are incomplete. And when something breaks, and it will break, you're on your own to figure it out.

That's cutting edge. And by definition, it cuts and it's painful.

You know what's not painful?

Listening to some users talk about what they need and where they struggle. Sitting down with someone who uses assistive technology and watching them try to get their job done with your product. Realising that all your latest and greatest framework and AI and microservices mean nothing if someone can't fill in your form or understand what a button does.

Okay, maybe that's painful to watch. But it's also illuminating. That's the stuff that makes your product work for people who need it.

HTML isn't painful. Testing with a keyboard, I'd argue, isn't painful. Writing clear error messages isn't painful. Making sure your colour contrast passes basic standards isn't painful. Putting actual words on your buttons instead of just icons isn't painful.

None of this stuff requires cutting edge tech or a complete rewrite. It just requires you giving a shit about the people who'll use what you're building.

Sent on

Did you enjoy this bite-sized message?

I send out short emails like this every day to help you gain a fresh perspective on accessibility and understand it without the jargon, so you can build more robust products that everyone can use, including people with disabilities.

You can unsubscribe in one click and I will never share your email address.