Building a HealthTech product—and the organization behind it.

Turning an idea into a product

I joined Adoreal when the product existed only as an idea.

The initial team was the founder, a software architect, and me. There was no product, engineering team, documentation, or established process—only a healthcare problem worth solving and a conviction that we could make the work around it easier.

My role was to translate the founder's ideas into a product a team could build. I defined and prioritized the roadmap, wrote user stories, documented the emerging product, and helped create the ceremonies and release process that gave the growing engineering team a shared rhythm.

The work taught me that early momentum needs discipline. We moved too quickly at times and accumulated bugs; the MVP grew beyond its intended scope; and we waited too long to validate some assumptions with clinics. Those moments changed how I approached discovery, scope, and customer feedback.

What changedWe launched a working first version of the healthcare platform with repeatable product processes, clearer documentation standards, a growing engineering team, and a stronger approach to discovery and validation.

Growing a connected platform

Once the foundation existed, my work shifted from defining the product to continuously improving an ecosystem used by clinics and patients.

I initially focused on the Electronic Medical Record and later moved to the Patient App. That shift gave me a fuller view of the healthcare ecosystem: the operational realities inside a clinic and the expectations of the people receiving care.

The product challenge was rarely a single feature. We had to balance usability with privacy, healthcare requirements, and the reliability people need from the tools that organize appointments, information, and care.

What changedThe result was two connected products serving clinics and patients, used by more than 1,000 people across multiple countries. I learned that dependable products are not defined by one launch—they are built through many thoughtful decisions over time.

Scaling how teams build

As the company and product teams grew, my focus shifted from improving individual features to improving how the organization built products.

As Product Operations Lead, I worked closely with four Product Managers and one Product Owner to support consistency across multiple development teams. The challenge was not to introduce more process; it was to create enough shared structure for teams to move faster without sacrificing quality.

I focused on the places where small, repeatable improvements could reduce friction between product and engineering while making the work easier to understand, review, and release.

What changedProduct Managers spent less time recreating documentation, developers received clearer requirements, and releases became more predictable. The shared operating model grew alongside the company as it expanded from 2 to 30+ employees.