Music Platform with DEI: Steve Nixon’s Vision for Inclusive Music Innovation

When’s the last time a founder dropped everything, not for a funding round, not for a viral moment, but because one user said, “I can’t access what you made”?  That’s what happened to Steve Nixon, a world-touring jazz and blues pianist turned founder of FreeJazzLessons.

His mission was clear: help musicians develop their skills from anywhere in the world. But when a blind pianist in Argentina couldn’t use the platform, Nixon’s team hit pause. Fully. Rebuilt the product. Rewrote the files. Changed how they worked forever.  

This interview isn’t about performative DEI. It’s about how a small team got real about access, and how that’s made their product better, their brand stronger, and their culture more honest.  

Building a music platform with DEI: Why accessibility isn’t optional

When accessibility is treated as a bolt-on, someone always gets left behind. Steve Nixon learned that the hard way, but he responded in a way most leaders don’t.

The jazz and blues pianist turned ed-tech entrepreneur founded FreeJazzLessons.com to share decades of performance and teaching experience with students worldwide. But a single email changed how he built, taught, and led.  

In this candid conversation, Nixon explains how his team made accessibility non-negotiable, how inclusion now shapes hiring and workflows, and why fixing things before they break isn’t just better business, it’s better humanity.  

For marketers, creators, and community builders, Nixon’s story is a powerful reminder that accessibility isn’t just compliance, it’s strategy.

It’s UX. It’s culture. It’s reach. Let’s hear from Steve how a music platform with DEI became a case study in making accessibility part of culture, not just compliance.

Steve, let’s start with the moment that forced a change. This wasn’t a strategic rollout or a compliance push—you’ve said it began with one email. What happened?  

Steve: The shift didn’t start with a strategy meeting. It started with one email I couldn’t ignore.  

A blind pianist in Argentina wrote to us. He wanted to join one of our courses but couldn’t. The player didn’t work with his keyboard. The captions were broken. His screen reader couldn’t read the PDFs properly. He was respectful, direct, and just wanted access. That message hit me hard.  

We stopped everything. We called the team together. I said we weren’t moving forward until we fixed it. And we did. We rebuilt the player. We restructured every file. We updated every lesson that had problems.

And from that point on, we made accessibility part of the build process, not something to figure out later. 

That’s a powerful moment and a big decision. Once you made that call, how did the process actually change on the ground? What does inclusion look like now? 

Steve: Now we test everything before it ships. We send lessons to a group of users who use assistive tech or have different learning styles.

They tell us what’s clear and what’s not. They catch issues we miss. They’ve helped us rewrite captions, change pacing, rework visuals, and fix layout. One user told us our piano diagrams flipped when played on a small phone screen. It was a small visual bug, but it made the lesson impossible to follow.

We stopped the release and fixed it. No debate. No delay. That kind of input is gold. We use it every week.  

And you didn’t create a flashy DEI report or hire a consultant. You just… made it part of the work. How do you keep the standard alive every day?  

Steve: We have a checklist that’s part of every production sprint. It covers captions, mobile layout, screen reader flow, contrast, audio balance, and keyboard control. If anything fails, the lesson does not go live.

We all treat it as non-negotiable. No one has to bring it up in a meeting. No one has to ask if it’s important. It’s baked into the process. I sign off when things need more time.

That way, no one feels pressure to ship something half-ready.  

About hiring, you’ve built this thoughtful approach into how you evaluate candidates too, right? Tell me how that works. 

Steve: Hiring looks different, too. We don’t ask for resumes right away. We give people a real-world task and see how they solve it.

Then we ask them to write a short note explaining what went well, what didn’t, and what confused them. That note tells us a lot.  One of our best editors came through that process. He lived outside the city, had no formal training, and submitted a task that was sharp, clear, and well-paced.

His write-up included a fix we hadn’t thought of. We brought him on. He now runs edits for our flagship courses.  

Making changes like this doesn’t always go over smoothly with everyone. Did you run into resistance? It’s one thing to build new systems. It’s another thing to bring people with you. What happened when the team pushed back? 

Steve: Not everyone loved the changes. A few freelancers said the accessibility checks slowed them down. I listened.

They pointed out clunky caption tools and extra exports. So we brought in someone to rebuild the workflow. We kept the standards. We just made the tools smoother.  Some folks stuck with us. Others moved on.

No bad blood. The work has to reach the people who need it. That’s the deal.  

And now it sounds like this mindset is just part of the team DNA? 

Steve: People started speaking up without being asked. A junior editor flagged a left-handed issue in a keyboard diagram.

He caught it during review and suggested an alternate version. He’d only been on the team a few weeks. He saw something, fixed it, and brought it to the table. That’s the shift. The expectation is shared. Now, when something isn’t clear, it gets caught before the audience sees it.

That saves us time and makes the product stronger.  

I love the ending on this note. If you could go back to the early days of FreeJazzLessons.com, before the email, what would you do differently?  

Steve: Start by asking who’s being left out. Talk to them. Build with them in mind from the beginning.

Don’t wait until they email you. The version you ship with them in mind will work better for everyone. It really will. We’ve an internal checklist or the project trial template we use when hiring.

None of this is theory. We’re doing it right now, every week.