Life sciences company overhauls patient services model for faster treatments

A global life sciences company partnered with Modus Create to redesign the foundation of its patient services operations. Through a deep discovery and strategy phase, they identified the root causes of delays in medication access and built a new service blueprint. The new patient-centric framework reduces time to first fill (TTFF) by up to 20% and creates a more aligned org structure. As a result, the company has a clear blueprint to inform future product and platform engineering decisions.

Our work involved

• Analysis of 10,000+ patient cases
• Unified data pipeline analyzing 10k+ patient journeys end-to-end
• Product operating model creation
• Multi-tenant architecture for a communication hub

Impact

When important metrics start slipping, organizations tend to respond in one of two ways. They either ignore the results and hope the trend corrects itself, or they dive into firefighting mode and start deploying quick fixes.

But sometimes, progress comes from stepping back and questioning the problem itself. A global life sciences organization found itself in a similar situation.

Challenge

High TTFF & patient abandonment rate

The company had a popular patient support program that helped patients navigate insurance, get financial assistance, and access life-saving therapies. On the surface, the system worked, with structured processes and technology in place. However, the metrics revealed some concerning patterns:

• Average TTFF was 22.6 days, meaning patients typically waited more than three weeks after enrollment to receive medication.
• Patient abandonment was 31%, and more than 3,000 people each year enrolled but never received medication.
• Status checks made up 40% of inbound calls, with many patients reaching out just to get an update.
• Profile creation was slow—35 minutes median, with an average of 6.4 days from start to completion.

Modus Create’s product engineering experts partnered with the life sciences company to address these issues. Together, we mapped the patient support process, surfaced the real pain points, and identified where change would create the biggest impact.

Solution

Moving from a process-centric to a patient-centric operating model

Early analysis made one thing very clear. The existing patient support program was optimized for paperwork, not patient outcomes. Technical limitations shaped how teams talked about patient needs, and the strategic intent set at the leadership level wasn’t making its way to daily operations. This prompted a deep dive into all aspects of the patient support program.

1. Reviewing over 10,000 unique patient cases

The product engineering team reviewed 10,268 unique patient cases to understand the root issues and analyzed intake cycles, communication cadence, and bottlenecks. We interviewed teams to understand:

• workarounds
• technical constraints
• decision habits

and mapped actual decision flows against official org structures. We also built a Python-based data pipeline in Snowflake for a comprehensive analysis of user journeys.

The data revealed that straightforward cases moved quickly, but complex cases stalled for days because the system was not designed to handle exceptions. Staff created personal tracking systems in OneNote and Excel because no single tool gave them the full picture. These were all signs of structural misalignment that made the user experience erratic and inconsistent.

2. A change in mindset

One observation became the turning point during the discovery phase. Almost every conversation focused on “missing information.” Work paused until a fax arrived or a form was completed. This mindset meant that progress was treated as a checklist item rather than a continuous journey.

The breakthrough came from a simple question: Why do we focus on what is missing instead of what we are gathering?

Reactive approach

• Deficit-focused: "What's missing?"
• Reactive: Wait for response
• Process-driven: Follow a rigid schedule regardless of effectiveness
• Channel-centric: Send fax, send letter (method before effectiveness)
• Binary model: Complete or incomplete

Proactive approach

• Progress-focused: "What are we gathering?"
• Proactive: Predictive guidance on next best steps
• Patient-driven: Meet patients where they are
• Intent-based: Optimal channel based on effectiveness data
• Continuous model: Every piece of information moves us forward

This shift allowed teams to reposition their role. Hub associates were not clerks fixing incomplete paperwork; they were advocates guiding patients toward medication access. This reframe became the north star for the entire operating model.

3. Designing a layered product operating model

With this new mindset, the product engineering team then moved to design a five-layered product operating model, bringing together people, roles, work structure, and tools into one cohesive system.

• Layers 1 and 2: People, roles, and org structure

We defined roles from the VP of Product Management to individual contributors. This helped develop cross-functional teams (not functional silos) with clear ownership under the principle: who works it, owns it.

• Layer 3: A structured hierarchy of work

We established a strict hierarchy mapping to organizational structure and time horizons: Goal (12-18 months) > Initiative (2-4 quarters) > Epic (1 quarter) > Feature (2-4 sprints) > User Story (1 sprint) > Task (hours/days)

The structure came with a few specific rules, such as no double parenting (each work item has only one assignee), no orphans (every work item connects to a strategy), no shared ownership (one owner per work item), and no proxy ownership (who works it, owns it).

• Layer 4: Backlogs and increments

Next, the team organized work into time-bound increments such as Program Increment, Sprint, Product Backlog, and Innovation Backlog.

• Layer 5: Tools and integration

To keep strategy and delivery aligned, the team recommended a two-tool system:

1. Aha! as a strategic tool for Goals, Initiatives, Epics, and Features
2. Atlassian Jira as a delivery tool for User Stories, Tasks, and Bugs. Features keep strategy and delivery synced.

The team also embedded the OODA Loop (Observe, Orient, Decide, Act) as the decision-making framework to ensure transformation isn't a one-way journey but a continuous process of improvement.

4. Delivering an actionable blueprint

Finally, we delivered an actionable blueprint that can be used immediately or scaled over time. It included aspects such as:

• Strategic vision and principles: A patient-first manifesto to guide every decision, prioritize faster access, and align teams around outcomes.
• Hub navigator: A GPS-style product definition to visualize progress, recommend next actions, and unify the patient journey.
• Communication hub: A multi-tenant architecture for coordinated, channel-smart communication with a single conversation history.
• Data and analytics foundation: Live TTFF/abandonment views at program scale (Snowflake), with actions tied to business impact

The life sciences company received three implementation options to put the plan into action: full transformation, maintaining the status quo, and a quick-wins approach. Each option outlined the effort, investment, and expected outcomes, giving leadership the clarity needed to choose the path that best fits their priorities.

Impact

Faster & more reliable patient services

The life sciences company now has a clear path to transform patient services from process-centric operations to patient-centric outcomes. The analysis revealed specific opportunities to reduce TTFF by up to 20%, cut patient abandonment rates, and set new benchmarks for patient services.

Beyond performance improvements, the life sciences company now operates with a unified view of the patient journey, a modern product operating model that links authority to accountability, and a data foundation capable of supporting predictive and proactive patient support. This reduces friction, improves medication access, and scales patient services with confidence.