What I learned working on a complex medtech product | Part I

Building an efficient, intuitive, and evidence-based pharmaceutical decision support tool.

Hi!

I’m Lina. On my LinkedIn profile I introduce myself as a passionate design thinker with a background in data analytics and strategic consulting. Now, I’m a Product Manager at AMBOSS where I work on a complex med-tech product.

I’d like to share my experience of working as a Product Manager (PM) on a complex project in the field of medical knowledge distillery at AMBOSS.

It takes two posts to share what’s on my mind. This one discusses product management, the PM role at AMBOSS and an overview of the product I’m working on. The other one shares practical approaches and learnings for working on complex projects.

I hope to inspire, motivate, and in the best case even guide you through tough times with my story. Feel free to reach out to me if anything resonates with you.

What does a Product Manager do?

This is where the conversation among us Product Managers and outside of our bubble starts, right? What does this role even mean? We acknowledge a bunch of diverse backgrounds in product, such as design, business, tech, and even more exotic fields. My background, for example, is in economics, business informatics and design thinking.

In our chat about the role, we might end up agreeing that Marty Cagan and Dan Olsen are great thought leaders and Think Fast, Talk Smart is a great podcast (go check those out if you haven’t heard about them and are interested in product).

Outside of the tech bubble, I often find myself explaining my role from very different angles.

At work, I tailor my speech about ‘product’ to the audience. I emphasize different details of my understanding of the role depending on if I’m communicating with engineers or medical domain experts.

In private life, I keep improving by trying out different analogies. I’ve described my role as similar to a construction manager, agent, or mediator before. The construction manager usually works best as it’s the most descriptive and relatable. Construction Managers and Product Managers share the connective aspect; the large amount of communication as part of their responsibilities, and the many conversations with different professions — such as a tiler, electrician, bricklayer, glazier, and architect.

When people think about product, they probably have colorful post-it note covered walls in mind. One might imagine that ‘the idea’ plays a key role in the job. Yet, most of the time we don’t come up with solutions. We understand the problem we’re trying to solve and then facilitate our way from the problem space to the solution space.

Yet, another reality check is in order. As a PM you think you’re working on formulating and solving problems most of the time, but at the end of the day your role is actually a connector. You’re not always the expert, so oftentimes the best you can do is ask the right questions.

PMs are experts on their respective products — how users behave when interacting with the product, the user’s needs and problems to solve and the opportunities to do so.

I like that problems come in different shapes and sizes. It means one can approach them from different angles. Some problems have an easy fix, while others aren’t even the problem themselves — you end up searching for the core of the problem causing the symptoms that look like problems.

The connecting character of the role comes into play when facilitating collaboration and communication within the core project team, as well as with all the collaborators. Bits and pieces are usually there, it’s rather a matter of understanding, detangling and reconnecting them to create a meaningful product solution.

I didn’t follow the Product Management career path because I have great ideas and want to release them into the universe. I followed it because it became a job where I could learn and embrace inspiration from my surroundings. It’s fun to work collaboratively and create product visions.

Where I truly get excited is in understanding, formulating, visualizing, documenting and mapping the problem space, and deeply engaging in discovery work, exploring solutions collaboratively with domain experts, engineers, and designers.

I love the process of structuring the complexity which product discovery naturally induces. This includes structuring a mess of ideas, beliefs, and working with criteria to evaluate them against user needs and business goals.

I love developing a plan and a story in conversation with the team, business stakeholders, and our users. I’m glad that I quickly learned that Product Managers do not ‘own’ ideas or roadmaps— rather they facilitate and structure the path.

Being a Product Manager at AMBOSS

I joined AMBOSS in a state of excitement as I’d just found out about the great value we provide to medical students and physicians. My friends who went to medical school and never really got my “job in tech” shouted, “AMBOSS! OMG that’s so cool!” when I first told them where I was going to be working.

Of course I’d read the mission and vision statements. I knew I was going to work on empowering medical students and physicians with a knowledge tool. I was delighted by a smooth HR process, short reply time, and quick invitation to interview onsite.

I was greeted warmly, and interviewed in an authentic and friendly manner. I could sense a great passion, creativity and true drive to act and make change happen within the company. Despite the usual interview nerves of hoping to convey my personal traits and values right, every interview ended with a lightweight feeling.

When I met my fellow Product Managers Hannes and Tobi, I was impressed by their humbleness, asking me to share my knowledge with them. They are Product Managers by experience, with backgrounds in medical education and tech. Therefore ‘technically’ I am a Product Manager by training. They provided me with an empowering feeling of adding a lot of expertise, especially in product discovery work. What a warm welcome and what a humble and cool place to work!

I met my wonderful team and embraced our mission in great awe. We were taking the first bet towards elevating AMBOSS as a tool for clinical decision making and not just a tool for medical students — building an efficient, trusted, intuitive, and evidence-based pharmaceutical decision support tool.

The team

Our cross-functional team consists of engineers, a designer, product manager, medical contributor, product analyst and user researcher. We work with Jira and Notion for planning and documenting.

I really enjoy our pragmatic and value driven working style. We’re generous team players. And the best part is working with physicians on a physician product, while having the expertise in-house — our staff of medical editors are trained physicians with experience and stories to learn from.

I don’t hesitate to reach out to experts regarding medical questions or when I can draw upon insights from the reality of the clinical day-to-day. This is a great shortcut.

Yet, I haven’t ever worked in a company that embraces customer research so much. Product discovery is taken seriously and devoted a healthy amount of time and space. Our customer insights department is a team of real rockstars.

The product

All cool… tell me more about the product!

Okay.

AMBOSS makes studying a breeze, and life on the wards easier.

I’m working on the physician side of the product. Our physician users administer and prescribe drugs in their daily practice. These are among the most important types of therapy applied. Applicable therapy advice is only useful when specific pharmacological information is included.

• When, where and in what dosage shall I apply in my specific patient case?
• Do I need to make adjustments given insufficiencies?

When physicians need to look this up in their clinical practice, they use a wide range of sources — google search, hospital software, physical books (yes, really!) and asking colleagues.

Our current knowledge base includes basic information and general knowledge for key substances. Yet, reaching completeness and depth is our goal.

Together with a great truly cross-functional team, I lead us towards these goals:

A. Providing a pharma catalogue of knowledge in AMBOSS

B. Integrating the pharma database into the AMBOSS knowledge universe so that it can be curated, connected and interlinked.

The complexity

If you still think “that doesn’t sound too difficult,” let me outline the complexity we’re taking on with this project:

What’s so complex about it?

Let me start with our users’ reality.

Imagine you’re a young physician, you’ve recently finished your studies and work as an intern or resident in a hospital. You’re under a lot of pressure, working crazy hours, yet, you want to make the best decisions for your patients.

While on call and reviewing your patients files, questions might arise that you want to double check — this could be any medical term for example.

You might turn to your colleagues, but you don’t always want to do that because you all work very hard, treat a lot of patients and interruptions cost time. You might google some info, but how reliable is that?

You might want to double check a specific substance, for example Ramipril, an ACE inhibitor with antihypertensive effects. You might want to check which trade name it’s available under, or enter the trade name you know and read more about its active ingredients.

For many drugs you might have general questions:

• What is the right dosage?
• Do I need to adjust the dosage due to my patient’s renal insufficiency?

Knowing everything is impossible.

Especially in the field of medicine, there are substances out there which have been developed for one purpose, but cause side effects that are beneficial in other cases. These drugs ultimately end up becoming the number one go-to for an indication that it was never intended for. Dosage obviously makes a big difference in indication as does the application form.

So how can I quickly find the right dosage and application form?

Another level of complexity arises from working within a big organization.

The nature of a large, cross-functional team in a project with a lot of room for idea generation and research, yet differing expectations, requires a lot of communication and alignment.

Given different professional perspectives, a lot of expectations lay upon this endeavor of integrating a new product into our existing product:

Business
“A “new” product which will drive user acquisition and retention. When will we see the first effects in our usage data? Which market segments will we acquire first? Will it help solve our rather weak business performance with user group X?”

Domain Experts (our internal physicians and medical editors who write our high-quality medical content)
“With a list of all drugs we can reach completeness much faster. Yet, we need to make some adjustments so it lives up to our quality standards. ”

Engineering
“Ok great, let’s digest this and display it. Domain Experts, we just need you to specify how it can match to your knowledge structure, what entities do we need to create?”

All those perspectives depend on the Product Manager’s ability to understand, create, prioritize, scope and plan, so some of those expectations will come true. It’s managing expectations, saying no, asking for commitment, facilitating decisions, and making hard tradeoffs.

When I was facing this challenge, the concept of the four risks from Marty Cagan’s product theory helped me organize my thoughts:

“Successful products are valuable, usable, business viable and technically feasible.”

All those risks need to be accounted for. It always helps to check in on these once a solution has been formulated.

Looking ahead, the risks we’re most challenged by are understanding, communicating and managing the technical feasibility and value risks — mapping the complexity on the user perspective with organizational solutions (the collaboration of engineering, domain experts and design).

This is the end of part one.

You now have an understanding of product work at AMBOSS, the onboarding process and an idea of my complex project.

I already hinted at some strategies to structure complexity: Structure it with the help of frameworks, sometimes as simple as listing user perspectives formulated in quotes, sometimes applying wise product theory.

Read part II if you’d like to find out about strategies and learnings about handling a complex project as a Product Manager.