Building for “Simon from Canada”

Building for “Simon from Canada” #

This site is a work in progress, made public for review and feedback. Learn more.

Bridget Harris’ approach to prioritising features for her online scheduling tool has evolved over the years as she aims to serve her ideal customer, embodied in one real-life person: “Simon from Canada”.

Don’t get too attached to the way you choose the features to build next. As your product matures and your team grows, expect to modify it again, again and again.

That’s what we learnt from our interview with Bridget Harris, who co-founded online scheduling tool YouCanBookMe alongside her husband, Keith.

But do make sure to prioritise to meet the needs of your ideal customer. Or, your “Simon from Canada”, as Bridget calls him.

Simon (whose name we’ve anonymised) is a massage therapist from—you guessed it—Canada and one of their early customers. He fit YouCanBookMe’s ideal customer profile (ICP) perfectly, so the team began developing it with him in mind.

In fact, they’ve changed the way they prioritised features multiple times to ensure they serve Simon—and other customers just like him—well.

Bridget is definitely doing something right, because some customers have been using YouCanBookMe for 10+ years since its founding in 2012. That said, she’s encountered setbacks that taught her to take a more measured approach to product development.

As a whole, Bridget’s journey with YouCanBookMe shows that using and sticking to a systematic, methodical prioritisation framework is hard. But to understand this, we have to start from the beginning.

Building out the minimum viable product #

YouCanBookMe was spun off from one of Bridget and Keith’s earlier apps. At that time, it was little more than a feature and needed to be built into a standalone minimum viable product—a product with just the essential features it needed to work so that the co-founders could evaluate the demand for a more polished solution.

This meant adding features like accounts for users to access the product. A user interface, so people could navigate it. And transactional emails to notify users of new bookings.

Their minimum viable product gained traction, which led to users enthusiastically emailing in feature requests.

Simon was one of them. He needed a tool for accepting new bookings while he focused on serving existing ones. Well, this was exactly the tool the team wanted to build.

Cue the start of a years-long customer relationship, where feedback from Simon (and other customers) shaped YouCanBookMe’s early feature set.

Simon was more than happy to field regular interview emails and calls with Keith to discuss his needs, and feature ideas. During these calls, Keith would ask questions like “What would that feature be about?” and “Why would you want to use it?”

Simon’s answers to these questions were crucial, as they could make the difference between building a feature or scrapping it.

Over time, though, Keith’s inbox overflowed with feature requests. This led to the team building a feedback tool to organise them and let customers vote for their favourites.

“That created a list for Keith to just keep building whatever was the most popular request,” says Bridget.

But they built too many features! #

As the team dutifully heeded their customers’ feature requests, YouCanBookMe’s feature set grew and grew—until the team realised they had built too many features.

“If you just build everything that everybody’s ever told you they want, you end up with a massive and very complicated product,” shares Bridget.

YouCanBookMe’s user interface had only four tabs in the beginning, but this soon expanded to a whole row of tabs—and tabs within tabs—to accommodate all its features. Customers found the interface confusing and sent in countless support tickets. Half the team had to help attend to them.

Bridget hired a head of user experience to revamp the interface. But that wasn’t the only issue that cropped up.

“Furiously building lots of features in the early days caused us a lot of technical debt,” she says.

Getting bogged down by technical debt #

This technical debt caused deep frustration. Building everything their customers asked for, combined with some initial technology choices, had limited the team’s ability to develop other features.

One innovative feature the team wanted to build, but couldn’t due to technical debt, was a feature to overlay anyone’s calendar availability over YouCanBookMe’s scheduling interface even if they didn’t have a YouCanBookMe account. Customers hadn’t asked for it. But Bridget, with a founder’s intimate knowledge of the problem domain, felt certain it would increase the product’s value.

This feature was eventually released eight years later after the team had, among other things, tackled much of YouCanBookMe’s technical debt. By then, competitors had already launched their own versions of the feature, so it was no longer novel.

YouCanBookMe calendar overlay

“We should have built overlay availability in 2016 or 2017 because YouCanBookMe would have continued to be at the forefront of all of the innovation that has happened since then,” says Bridget. “But we were bogged down with technical debt and stability and security issues with the tool.”

Hiring people to improve the product was also difficult because it had been partly built with older technology that had largely fallen out of favour.

The team spent two whole years refactoring their code, rewriting YouCanBookMe using a more modern and flexible web application framework. Bridget describes the work as “the worst, boring-est job that none of us wanted to do”, and their product manager had to put his foot down repeatedly to get it done.1

Starting afresh #

As the team rebuilt YouCanBookMe, they took the opportunity to get rid of some complex features only a handful of customers used.

“These features don’t make you any money, so we’re kind of like, ‘Oh my God, what if we just didn’t have them,’” says Bridget.

The team also now “gets to do all the fun stuff, which is to build all of the exciting features that were always part of the plan”.

The overlay availability feature has been rolled out, among others. The team also spent some time evaluating and improving YouCanBookMe’s positioning. This led to them pivoting from serving teams to returning to their roots and serving small businesses.

“Our homepage said we had an effortless tool for teams. But it just wasn’t effortless,” says Bridget.

“It made us feel awful because we were constantly thinking our tool isn’t good enough. Whereas now, we say we have a booking experience your clients will love. And they do—they love it.”

YouCanBookMe homepage comparison

Focusing on serving “Simon from Canada” #

The team’s current strategy for deciding what to build next mirrors what Keith did over a decade ago: talking to as many customers as possible to learn how they use YouCanBookMe, why they use it and the features they want to see.

No bringing of preconceived notions to the table. Just listening, listening, listening.

So far, they’ve gathered at least 70 interviews and 450 survey responses’ worth of customer insights. Based on these, they’ve drawn up a long list of feature requests and have been building and releasing constantly since.

Being fully aware that it’s possible to build too much, though, Bridget is honing in on the features their ideal customers will love. In fact, the team has made T-shirts saying “YouCanBookMe = our ICP is our BFF (best friends forever)”.

YouCanBookMe team photo

Bridget also purposefully puts a pause on building to assess their progress and next steps.

The hard work, tough decisions and ongoing customer conversations are working. These days, Bridget’s customers are delighted.

“When I interview customers now, they’re like ‘Oh man, I just can’t keep up with your new features! I get your newsletters and there’s more new stuff!’” recounts Bridget.


This case study is based on our interview with Bridget Harris in September 2024.


  1. As Bridget shared her experiences of accumulating and dealing with technical debt, I found myself relating to it all too well. I had faced the exact same situation while building my own product, Feature Upvote.

    I suspect many software products inadvertently build too many features too quickly on their way to maturity. They then spend months or even years paying off the resulting technical debt.

    I listened to Bridget in suspense, waiting to hear the easy solution to years of hodge-podge feature accumulation and technical debt. But what I came to realise is that there is no easy solution.

    When you find your product in this situation, you need to make hard decisions that almost nobody else is willing to make. If you don’t, future product development can be like walking through a muddy swamp. ↩︎