Built With Intention: Why Product Philosophy and UX Matter More Than Ever in MedTech

In MedTech, software is rarely just a standalone tool.

It lives inside regulated processes. It supports decisions that matter. And it is used by people who already carry a heavy cognitive load, every single day.

That’s why at Flinn, we don’t see product philosophy and user experience (UX) as an “extra bonus”. They are core to how we create value and to how we build long-term partnerships with our customers.

Fasten your seatbelts: This post explains how a clear product philosophy, problem-first thinking, and continuous UX work shape how we build regulatory intelligence software at Flinn.

Because we start from a very simple, but very strong belief: we are deeply customer-obsessed. And we are building for the long run.

We don’t aim to win with shortcuts or quick feature lists. We aim to win with the best product, even if that means higher upfront investment, slower beginnings, and hard decisions along the way.

A strong product focus and a serious investment in UX don’t work in isolation. They require a close, ongoing connection to our customers and a shared willingness to grow the product together over time. When that commitment exists, the investment pays off in the form of software with real impact for both sides.

Product Philosophy Is a Long-Term Commitment

At Flinn, our ambition isn’t just to deliver MedTech software that “works".

We want to be an innovation leader in regulatory intelligence and create value not only for our customers, but ultimately for their customers as well: patients, clinicians, and healthcare systems.

That requires a product philosophy that is:

• grounded in real-world workflows

• resilient to regulatory complexity

• and designed to scale without losing clarity.

This philosophy shapes how we build, what we build, and just as importantly, what we deliberately don’t build (yet!).

Core Principle #1: Problem First, Solution Second

A lot of products start with an idea: “How would I use this?” “What would I want to click?” “What sounds impressive?”

Aaand we take a different path.

At Flinn, every product decision starts with deeply understanding the problem and acknowledging how incomplete that understanding often is at the beginning.

A good example is our latest complaint automation module, a discovery-heavy project. Much of the last year was spent taking small, deliberate steps forward, validating hypotheses around what complaint handling actually is. We started with perhaps 99% assumptions and even now, there are still plenty of known unknowns and unknown unknowns that could shift our understanding of the problem space dramatically.

One reason for this is structural. We are often approached by QA, RA, or managerial roles who are facing very real pain: poor intake data quality, inefficient processing, and a lot of time spent chasing information. While these roles are often the ones initiating the collaboration, they are usually not the originators of the problem. They sit in the second or third row, relying on assumptions about what happens at the very first point of data intake.

That means our work often starts with reframing. We need to bring together second-row and first-row roles (service teams, sales reps, technicians) and do discovery together. Only then can we uncover whether the root cause of insufficient complaint data is what everyone initially assumed, or something entirely different that requires a very different solution.

One early example illustrates this well:

With one customer, our initial hunch was to solve complaint intake challenges by building an app for sales representatives, enabling them to report issues on the go. It sounded reasonable, until we spent time with the actual end users. We learned that sales reps are far less involved in reporting than expected. Their primary goal is to fix issues immediately, not document them. And if something does need to be reported, it often gets pushed back to hospital technicians or manufacturer service teams. As a result, this shifted our perception of how to bring true value to this reporter type and put a spotlight on another reporter type that had previously operated in the background.

These insights don’t emerge from planning sessions.

They emerge through testing, observation, and conversations, often with users we don’t even have access to at the beginning.

Almost every customer interaction starts with assumptions. And some will be proven wrong. But with each customer, we learn more about variations, patterns, and customer archetypes, moving us closer to solutions that work out of the box for many, without losing nuance.

And that’s what “problem first” really means to us.

Core Principle #2: Small, Iterative Releases (Without Compromising Quality)

Nope, we don’t believe in massive first versions followed by yearly overhauls. What do we do instead? Glad you asked!

We work in small, deliberate increments. And for a simple reason: real learning happens in use, not in planning decks.

And yes, even with this approach, we sometimes build things that look promising, are discussed thoroughly, and still turn out to be less useful once they hit real-world workflows.

When that happens, we don’t defend the feature. We go back to the underlying problem and simply reshape the solution.

Sometimes, that also means letting go.

A good example for this is the “screening evaluation assistant” we once explored for our literature module, an AI-based feature designed to suggest whether an article should be included or excluded, backed by keyword highlighting in abstracts and full texts. It took us a moment to admit it, but the feature simply didn’t work. We underestimated the complexity of contextual judgment involved in screening and how much trust users would need to place in such a decision.

Instead of forcing the idea forward, we just shifted direction. Rather than replacing human judgment, we focused on building multiple features that assist it: extracting relevant data, optimizing the user interface (UI), and supporting efficient, transparent decision-making. Maybe a feature like this will come back one day, once we better understand how to earn user trust in that context.

New functionality is typically rolled out first to a small group of customers who actively want to test and challenge it. Only after that phase do we release it more broadly.

One thing, however, is non-negotiable: small releases never mean lower quality.

Validation, robustness, and regulatory soundness are always part of the equation, no matter the size of the release.

UX Is Not a Layer. It’s Part of the Foundation.

In regulated environments, usability is often underestimated. But every extra click, every unclear label, every confusing interaction costs time, attention, and confidence.

That’s exactly why continuous UX improvement is part of Flinn’s DNA.

Our complaint automation module, for example, is highly conversational, built around chat-based agent tools.

A single poorly chosen term can lead to misinterpretation, confusion, or even incorrect intake data. To make things even more complex, terminology varies across regions, SOPs, and real-world usage. What exactly is a complaint? Where does feedback end and risk-relevant data begin? These are not semantic questions, they shape outcomes.

Working on our literature module, interviews revealed that our original query builder didn’t reflect how users actually work. It couldn’t handle multiple queries across different sources, forcing users into workarounds. Once we redesigned it to match real search behavior, M2 shifted from being perceived as “nice support” to something teams could use productively right away.

Another example is the statistics tool in our safety database monitoring solution. Previously, it was barely understandable. Today, it’s still complex, but at a level where improvement requests are rare. That’s not because it’s “perfect”, but because it aligns much better with users’ mental models.

The result is something our customers tell us again and again: Flinn feels approachable. It feels self-explanatory. It feels friendly (even when the underlying tasks are complex).

As the product and the company grow, we actively protect this experience.

In regulated MedTech environments, good UX is often not a given.

Switching systems comes with high regulatory, operational, and organizational overhead, which means many teams continue working with complex or outdated tools unless there is a clear and tangible improvement.

That’s why good user experience doesn’t automatically scale in this space. It has to be deliberately defended and continuously justified through real value.

Product Culture: What Feels “Very Flinn”

What sets our product culture apart is not a single process or methodology, but a combination of principles:

• a deep respect for the complexity of the problem space

• very close integration with our customers (sometimes to the point where it feels like we are part of the same team)

• an evidence-based mindset, shaped by highly educated, critically thinking users with mature decision processes

• lean structures, low hierarchies, and inclusive (but efficient!) collaboration.

In an environment where accuracy, reasoning, and trust matter deeply, this culture is the foundation that allows us to build products with intention and to keep improving them, together with our customers, over the long run.

For us at Flinn, this is not a finished state, but an ongoing commitment shaped by continuous learning and close collaboration!

If this way of building products resonates with you, we’d love to exchange perspectives and learn from your challenges.