How Boddle’s product-driven approach built educational games that kids ask their parents to buy

What if the way you’re building your product is the very thing keeping it from working?

That’s the conversation I had with Clarence Tan, co-founder and CEO of the Kansas City-built edtech startup Boddle Learning — a company that turned educational games into something kids beg their parents to buy.

This wasn’t an overnight success. Clarence and his team started out in what he calls their “mom’s basement phase,” piecing together grant money to build their first prototype.

They didn’t have a dev team.

They didn’t have users.

They barely had a product.

But they had one big question: Can we build learning games that are actually fun to play?

Not “educational” games wrapped in a thin layer of gameplay.

Not worksheets disguised as entertainment.

Real games. That kids want to come back to.

That required something most teams skip: A ruthless focus on understanding the user.

Here’s the trap: Your engineers execute the ticket. Your PM owns the roadmap. Your designers polish the flow.

But no one is actually listening to the user.

You start building based on secondhand data, internal assumptions, and what the last customer said in a sales call. Slowly, your team loses touch with the people they’re building for.

And when that happens, even the smartest teams ship things no one wants.

Clarence saw that early.

When he and his co-founder were building contract games for clients, they kept noticing a pattern: kids hated most educational games. They could smell the “learning” from a mile away.

The game mechanics were weak.

The fun was missing.

The outcomes were predictable.

So they flipped the script.

Fun first. Then learning.

It was a gamble. But it worked because they were obsessively close to the user.

Want to go deeper? Watch this Product Driven podcast episode, then keep reading.

Proximity beats assumptions every time

The most important shift Clarence made wasn’t tactical. It was cultural.

He and his team weren’t just trying to build “what made sense.”

They were building what made kids light up.

That meant watching kids play.

Sitting in classrooms.

Running playtests.

Studying reactions.

Asking teachers what broke or worked.

You don’t get that kind of feedback from a Google Form. You get it from being in the room.

Too many teams wait until scale to build a feedback loop. By then, it’s too late. You’ve scaled assumptions. You’ve hardened the wrong patterns.

At Boddle, proximity wasn’t an afterthought. It was the product strategy.

COVID wasn’t the break — It was the mirror

When COVID hit, Clarence saw an opening. Everyone was scrambling for free resources. So his team sent out messages like: “We’re offering Boddle free during the pandemic.” (They were free anyway. But the positioning mattered.)

Suddenly, they were on lists of “Top 10 Free Tools for Remote Learning.” Then they were on the White House resource list. Then they hit 50,000 users.

That kind of growth exposes cracks fast.

Their servers crashed constantly.

Their onboarding couldn’t keep up.

Their support inbox exploded.

But they survived because the product actually worked. Not technically. Emotionally.

Kids liked it. Teachers used it. Parents recommended it.

Because the team had built with empathy from Day 1.

If they don’t use it, it doesn’t matter

Here’s what I see too often: Founders get excited about an idea. They build fast. They launch big. And they get silence.

No adoption. No stickiness. No traction.

Why?

Because they never got close enough to the people they were building for.

It doesn’t matter how good your tech is if no one wants to use it.

Clarence didn’t just ship features.

He built around motivation. Around characters kids could identify with. Around learning loops that felt like leveling up, not logging in.

That takes more than wireframes and Jira tickets.

It takes watching your users. Caring about their reactions. And being willing to kill ideas that don’t land.

Are you close enough to feel the friction?

Every team says they care about the user.

But if your engineers can’t describe your user without reading a persona doc …

If your designers haven’t sat with real feedback in weeks …

If your roadmap is shaped more by internal goals than real pain …

Then you’re too far.

Clarence reminded me of something I learned the hard way at Stackify: The faster you build, the more dangerous your assumptions become.

Speed without understanding isn’t innovation. It’s waste.