What I learned working in a complex medtech project | Part II
Building an efficient, intuitive, and evidence-based pharmaceutical decision support tool
This is a follow up to part I , where I shared an introduction to product management at AMBOSS.
I outlined the complex medtech product we’re working on, that empowers physicians to provide the best possible care by providing them with a catalog knowledge tool to look up information about different drugs.
Well, in part II, it gets practical.
5 tools I use to handle complexity
Simply put, my approach is, and will always be, to make things as explicit as possible.
Visualize it. Make it explicit. Tell stories!
It helps to develop and deepen a shared understanding of complex dynamics and develop a product vision.
For this particular project, I used five different tools to do that.
1. User Journey Mapping
In order to understand clinical reality, I facilitated a workshop with internal and external physicians where we mapped a typical decision making situation on call. We were able to derive great learnings for our product from it.
We outlined a concrete story from the moment of a patient’s examination, to the patient treatment and eventually discharge. The workshop team consisted of two external physicians, two internal physicians (medical content editors/ domain experts), one engineer and one product manager.
The outcomes we created were two different user journey maps filled with rich information to turn into product work (inspiration, user stories, communication, design vision creation).
2. Project Scope Mapping
Based on those everyday examples from the workshop, I created a project scope map which outlined the different use cases of the project. It helped a lot to connect boxes with arrows on a board. We defined artifacts and outcomes. This facilitated a good conversation within the discovery team first and helped place ideas in context for the delivery team and stakeholders.
When new project aspects arose, the visualization was complemented with a project timeline that outlined value streams over time. Those value streams helped to separate different sub-projects from one another. Each was assigned an objective, a driver and a milestone. Dependencies were evident and a conversation about those is fostered. This is simply visual project planning— yet it’s a powerful communication tool.
We put a timeline in the form of an arrow on a blank Miro board and pinned the things that we needed to do next to solve our foundational challenges as post-its along the line. In a conversation between two product managers, we defined different value streams based on the value we think we add for the user.
Coming back to the construction work example from part I: If you build an electronic network in one value stream as your first phase of the project, you need to continue maintaining it at the same time as setting up the heating system. You might check out another opportunity where you can implement the same wiring concept from your electronic network in another building faster, because of what you learned on the first project.
3. Define Terms
Given the complexity of the nature of substances and their sometimes varying applications, we faced a lot of communication challenges due to the use of ambiguous terms.
My learning: Give it an unambiguous name and define it! Defining terms failed in our project because domain experts inherently knew what a medical term meant, but it was hard for non-medical experts to grasp. This failure showed up as a symptom every time we touched the logic for data processing and display. We came up with a solution in a collaborative effort, led by our driven engineering managers who noticed the ambiguity in conversations and code. We have now defined a proper domain model.
I highly urge you to make sure that domain experts, engineers, you and people not as close to the project, understand what you’re talking about. Define and visualize your domain model, make relations explicit with examples, give entities unambiguous names.
Documentation and visualizations do not solve everything though.
4. Talk to your users
We’re continuously in touch with our users. We released our products in beta to several test groups, ran experiments and conducted rounds of user interviews to better understand their behavior and usage context.
Interviewing users is the best method to stay in touch with our purpose and understand their needs. Quotes and stories convey so much more than a solution spec. Documenting, sharing and connecting insights to the product roadmap is key.
5. Organize and act on retrospectives
Checking in with the team, the wider team and your stakeholders is my final recommendation to handle complexity. Ask everyone you work with for their thoughts and perceptions. It helps to take the time once every quarter or half year to check in and get their view on how the collaboration and progress is going.
Retrospectives are a very operational tool in agile teams, but can also be used at a higher level. We hold the operational retrospectives at the end of each sprint and the more high-level retrospectives with stakeholders every quarter. It’s important to make time for both of these.
Of course we hit some bumps on the road. Knowing what I know now, here are four things that I’d do differently.
1 | Have an information architecture expert from the start
Our project started with a team that was newly built for the purpose of making drug information from the database usable in AMBOSS. The immediate goal sounded clear: Given a database, make it searchable and display it.
In the beginning, the team consisted of two backend engineers and several frontenders. In hindsight, we lacked a database expert and information architect. Our setup let us move quickly in the beginning, but led to a major refactoring later in the year. We failed to understand inherent expectations and interpretations from both engineering and product perspectives due to a lack of architectural guidance. Our domain model was not explicit enough. We lacked this key competency guiding us when starting our journey.
2 | Nuance stakeholder meetings
We used to meet in a big round of domain experts, business and marketing representatives, who have differing needs in terms of depth of information and discussion of solution design. Separating checkins with those different business functions made a big difference to the progress and depth of conversations.
3 | Explicitly appoint an expert to consult about deep knowledge questions
I’ve never been to medical school. I can pick up new things fast, but I’ll always have questions for “real physicians” in my daily work.
AMBOSS offers an amazing setup. We have experts in our company. They write our high quality content. I can reach out to them anytime. But progress on our project, especially for the hard questions, has been boosted since we created the new role of a medical advisor.
They bring expert level medical domain knowledge to the project. They mitigate medical risks at every step of the product development process and ensure feasibility from a medical point of view. The medical advisor is an integral part of the team — just like engineers, designers, analysts, and researchers.
4 | Invest in figuring out solutions collaboratively
Given the large number of project contributors, meeting invite lists tend to become long. Having experienced the drawbacks of short-cutting solution design, I’ve recently become more confident to ask key stakeholders, including C-level managers with busy schedules, to participate in ideation and planning meetings where needed. So far, the investment has been proven to be worth it.
Different problems require different expertise. Recently I composed the following task forces:
Feature A: Domain Expert, Researcher, Engineer
Feature B: Domain Expert, Designer, Researcher
Feature C: Marketing Expert, Engineer, Designer
Making information explicit makes complexity easier to handle
Visualizing and telling stories are two great ways I successfully made information explicit and engaging.
Here are a few things that I’ve implemented with my team and stakeholders that I hope you’ll be able to do too:
- Be sure to first invest in deeply understanding the problem and making it tangible through visualization.
- Define terms as clearly as possible.
- Check in with your users, as well as your team members regularly.
- Make sure to check if your staffing fits the needs of your project intent and question this every now and then (and bring in new roles to fill gaps, in my case an information architect or medical contributor).
- Embrace the unknown and try out different forms of collaboration where necessary. Dare to invest time in true cross-functional alignment.
Thanks for reading my thoughts and learnings. I hope it inspires you to take action on your very own projects.