The Illusion of Customer-Centric Design
“Built for vets, by vets.”
It’s a phrase plastered across landing pages, pitch decks, and product demos in the animal health space. It signals empathy, legitimacy, and user-centered innovation. But ask almost anyone working in a veterinary clinic what they think of the tools they use every day, and you’ll get a very different story.
I know there’s a better way—because I’ve LIVED it.
The first 18 months of my career were spent almost entirely on the road, inside veterinary clinics. I wasn’t just demonstrating how our PACS software could fit into their workflow, I was observing, listening, asking questions. I wanted to understand what wasn’t working, where the friction was, and what “better” could look like from their perspective.
Then I’d go back to the office and translate those insights into business requirements, which became technical requirements, which turned into working prototypes. And I’d bring those right back to the clinics and ask: “Does this do what you need? Did I capture what you told me? Is anything missing or off?”
That’s what building with your users looks like. It’s iterative, relational, and humble.
There’s a meaningful difference between designing with your end users and merely consulting them once the roadmap is already drawn. One creates trust, adoption, and impact. The other leads to frustration, churn, and tools that collect dust.
In Practice: What Actually Works
Each edition, we bring you insights from industry leaders shaping the future of veterinary innovation, and just as importantly, from the people living it every day: veterinarians, practice managers, and veterinary technicians.
This week, I had the absolute pleasure of reconnecting with someone I genuinely admire, Mark Massaro, DVM. Mark is one of those rare voices who brings both deep clinical experience and sharp product intuition to the table. He does not sugarcoat things (which I love), and his straight-to-the-truth feedback always makes the work better. Our conversation was full of energy, practical insight, and the kind of grounded perspective that only comes from living both sides of the exam table and the dev sprint. Every time we talk, I walk away clearer, sharper, and more motivated to help teams build tools that truly work in the chaos of a real clinic.
“Man, this topic really hits home for me. If I had a nickel for every time I’ve seen or heard the “built by vets, for vets” slogan. Another thing that would make me a rich man…if I got paid every time I heard, “What the heck is this? It feels like there were no vet people in the room when they designed this…”
And guess what — there probably were not.
How do I know this? Because I GOT in the room!
Any Hamilton fans out there? “The room where it happened”?
I certainly was one of those folks, consistently puzzled by why many of the software programs used in veterinary hospitals did not really seem to fit the needs of those working on the floor - or at least weren’t as intuitive as they could be. But I often played devil’s advocate, learned the program, and then became a resource for my coworkers.
“Actually, there is a way to do what you’re trying to do; it just takes a few extra clicks…”
“Ugh… why?! Why would they design it this way? That does not make any sense for how we do things. It feels like they didn’t talk to any vet folks when they made this…”
There it is. That phrase again. And as Fotine points out in this piece, it is often not that they never spoke to anyone…they probably did! But was it a one-hour Zoom call? Or was that person deeply involved in the creation and design of the product? Both are often called “consultants” or “advisors,” but they are two quite different things…and…I have experienced both.
Without naming too many names, I will share a few anecdotes to illustrate my point. The first being that there is an ENORMOUS difference between a consultant and a full-time employee working in the Product division at a software company. Heck, before my first job in software, I did not even know what a “Product” division or a “Product Manager” was—I had to Google the job title I was applying for!
I think the easiest way to quickly describe my point and this is where I will drop the name of the company, at least—is that a few months into my first true software job as a Product Manager, I started to dream in Instinct. And yes, I mean that literally. Instinct is a practice management (PIMS) software for veterinary hospitals. Its action buttons and a core part of its design scheme are the color orange. And my dreams used to have an orange hue. I would often wake up with a potential solution to a problem I had been wrestling with all week… or come up with it in the shower… or while driving… and I know I’m not the only one. In fact, in a recent conversation with a product person at another PIMS company, they said the same thing—that they “dream in [name of PIMS].”
I think that’s the quickest way I can explain the difference between a casual consultant (which is actually some of what I do now—depending on how much a given company wants to involve me; I do a bunch of these quick Zoom feedback calls/demos) and a full-time employee or someone that is truly involved behind the scenes with the Product division/design of the program. The casual consultant is not dreaming in your program…
A couple of other anecdotes.
That whole “Well, then I think you need to get new consultants”—yep, that happened. And I completely understand where the company was coming from! Listen, I do a lot of demos. It is super easy to say, “Yeah, I think it looks great!” It’s what they want to hear and it often does! But that’s hugely different from actually running a program through its paces or using it in clinical practice.
OKAY, last anecdote… actually another Instinct one.
Soon after I was hired, I was tasked with making Instinct more accessible/functional for general practices (GP). Instinct was amazing for ER/specialty clinics with its innovative digital treatment sheets, but really didn’t have anything in the way of vaccines or service reminders. Having come from GP (I joke that I literally—well, figuratively—“grew up” in GP, with both of my parents as general practitioners), I jumped at the chance. I specifically remember one meeting early on with my team of developers, going over requirements for the project. I got that same question so many of us in vet med—or anyone who has owned a puppy—have come across or potentially been confused by:
“How many distemper vaccines do puppies get?”
“Well, it depends… they’re given every 2–4 weeks until they turn 16 weeks, so if you start at 8 weeks it could be 4, but if you start at 10 weeks it might only be 3…”
“Huh??”
And then of course we got into how the SAME vaccine can be good for 2–4 weeks this time, 1 year next time, and then 3 years the time after that…I remember specifically one developer looking at me from the other side of our Zoom meeting like her head was going to explode.
These things that become second nature to us in vet med, when you take a step back—or look at them from an outside perspective, especially a super analytical “if, then” computer science one—seem to make no sense. This is why it is so important to actually have someone in the room who understands these things. We spent weeks together ironing out the details, testing things in beta environments, etc., making sure we got it just right. I ended up leaving Instinct just before our big “Vaccines & Service Reminders” project was released (the project ballooned as we then ventured into things like Rabies and Vaccine Certificates, email and text reminders, etc., and was delayed by other projects we were working on at the same time), but I will always be super proud of the work we put in together and the way we figured out how to make it work—at times in ways I’d never seen any other PIMS do before, that I hoped would be more intuitive for our end user.
Okay, I think that’s enough anecdotes, and hopefully enough to show again that a casual consultant and someone LIVING AND BREATHING the program are NOT THE SAME THING.”
THAVMA INSIGHT: Mark’s stories bring one truth into sharp focus: software built in isolation is destined to be misunderstood. Involving real users is not optional. It is essential.
The Problem with “We Consulted with Vets”: Why That’s Not Enough in Veterinary Software Development
“We consulted with vets”— WHAT DOES THIS MEAN? Practice managers too? Technicians? Or did you do a one-hour Zoom call with a couple of vets who said, 'Looks cool'?
That quote came from a frustrated veterinarian who’s been on the receiving end of too many “vet-friendly” products that completely miss the mark. And they’re not alone. Across the industry, software companies claim to build with clinical insight, but the depth of that consultation rarely holds up under scrutiny.
Too often, “consulted with vets” means one or more of the following:
Token Interviews: Surface-level conversations done late in the product lifecycle. Insights don’t influence direction, they validate it.
Misaligned “Consultants”: Individuals without recent, relevant clinical experience whose input may reflect personal preferences more than operational reality.
No Clinical Expertise on the Dev Team: Without firsthand clinical experience on the development team, assumptions often drive product decisions.
THAVMA INSIGHT: “It feels like there were no vet people in the room when they designed this…” As Mark said, “It feels like no vet people were in the room” and too often, that’s the reality.
When Veterinary Software Creates More Problems Than It Solves
“There’s a reason the vast majority of people who work in animal hospitals find their programs counterintuitive.”
When products are built without deeply understanding the day-to-day reality of veterinary teams, the result is predictable: frustration, workarounds, and wasted time.
I was once on a call with a startup developing a new PIMS. I pointed out a specific feature that didn’t make sense in a clinical context, something that would clearly slow down a busy team. Their response? “Our vet consultant said it was good.” My reply: “Then I think you need new consultants.”
Real usability comes from repeated feedback across roles and settings. Without it, users lose trust, adoption stalls, training becomes burdensome, and support tickets pile up. Poor UX doesn’t just cause inconvenience, it erodes credibility.
THAVMA INSIGHT: When your users say things like, “There’s a way to do it—it just takes a few extra clicks,” you HAVE NOT built a SOLUTION. You’ve BUILT a WORKAROUND.
Why Vet Advisors Aren’t a Substitute for Actual User Co-Creation
One of the most common missteps in veterinary product development is assuming that a few advisor relationships are enough to call your process “customer-led.” It’s not.
Surface Consultation vs. Embedded Co-Creation: True co-creation involves users from day one, not just after decisions are made.
Validation at the End vs. Iteration Throughout: Continuous iteration beats end-stage approval.
Advisory Board Titles vs. Functional Collaboration: It’s not the title that matters, it’s the depth and frequency of engagement.
THAVMA INSIGHT: Mark captured this best: “The casual consultant is not dreaming in your program.” If they are not living it, they can’t shape it.
Veterinary UX Done Right: How to Build Software That Fits the Hospital Floor
The most successful veterinary products embed real users into every stage of the development process. Customers aren’t just testers, they’re collaborators.
Involve the Whole Hospital Team: Techs, PMs, and CSRs are essential to workflow. Design with their input, not just for vets.
Create Ongoing Feedback Loops: Make feedback a habit, not a one-off event. Engage early, often, and throughout the lifecycle.
Design With Clinical Staff in the Room: Co-create in real time with the people who use your tools under pressure.
Hire Clinical Voices into Product Roles: Bring former practitioners into your UX, product, and customer success teams. They don’t just validate, they shape the product with insider insight.
THAVMA INSIGHT: At Instinct, Mark did not just give feedback, he co-led the creation of entirely new workflows. From vaccine scheduling to certificates, he and the development team wrestled through the chaos TOGETHER until it clicked.
The ROI of User-Led Design in Veterinary Tech: Trust, Adoption, Loyalty
If there’s one thing to take away from all of this, it’s that how you build matters just as much as what you build.
You Reduce the Risk of Misfit Features: Continuous collaboration prevents wasted development cycles.
You Build Community and Champions: Users who see their feedback reflected in the product become advocates.
You Create Intuitive, Beloved Tools, Not Just Functional Ones: Seamless integration into clinical workflows leads to sustained adoption and loyalty.
Real product-market fit isn’t built in a vacuum. It’s built in conversation, with the people who will make or break your success.
THAVMA INSIGHT: When your developers say, “Wait, how many vaccines do they get?”, that is your sign you need someone in the room who’s lived both sides. Real users do not just CLARIFY complexity. They build better SOLUTIONS.
Because the future of veterinary technology isn’t just built in code—it’s built in clinics.
The products that stand the test of time are the ones shaped by the people who rely on them when it matters most. When we take the time to listen deeply, to observe without assumption, and to build alongside our users, we don’t just create better tools, we create shared ownership. That’s what makes a product intuitive, trusted, and indispensable.
In a world full of complexity, building with clarity, empathy, and collaboration isn’t just good practice, it’s the difference between being tolerated and being truly valued.
Because truly customer-led software isn’t built on slogans, it’s built by the people dreaming in your product.
Ready to sharpen your strategy? Start here!
Access our free strategy resources and learn more about Thavma Consulting.
Let’s connect: Fotine A Sotiropoulos | LinkedIn
If you are ready for a strategy-first approach, contact me to get started.
