Transparency in Coverage

Predicting personalized service costs

COMPANY
Amino
DATE
2023
TEAM
Full-stack Engineers (6), Data Science (1), Product Managers (2), Actuary (1), Lawyer (1)
SERVICES
PORTFOLIO STRATEGY PRODUCT DEINVESTMENT MVP PRODUCT REQ TRIMMING DEPLOYMENT

As the healthcare industry grappled with the complexities of the Transparency in Coverage (TIC) mandate, Amino embarked on developing "Explore Cost"—a tool designed to empower patients with comparative healthcare service pricing. Midway through its development, I assumed the role of Principal Product Manager, inheriting a product that had already consumed 1.5 years of R&D investment but lacked clear strategic direction and scalability.

TIC UI Cost Report TIC UI Explore options TIC UI Explore Cost Home
TIC Process 1 TIC Process 2

Product

TIC was built to help self-insured employers comply with the federal mandate requiring health plans to disclose pricing information. The product provided:

  • Machine-readable files (MRFs) for all covered items and services
  • Consumer-facing price comparison tools
  • Integration with existing health plan systems
  • Compliance monitoring and reporting

Strategic Assessment

Upon evaluation, it became evident that:

  • Market Misalignment: Initial customer expectations were narrowly defined and not scalable across the broader market.
  • Technical Constraints: The product's architecture was ill-equipped to handle the vast and complex data required for compliance.
  • Regulatory Ambiguity: The evolving nature of TIC regulations introduced uncertainties that the current product roadmap did not adequately address.

Recognizing these challenges, I initiated a comprehensive review to determine the product's viability within our strategic portfolio.

Decision Framework

To guide our course of action, I developed a Go/No-Go framework focusing on:

  • Big Enough Market Opportunity? Assessing the product's potential for widespread adoption.
  • Why us, why now? Strategic Fit: Evaluating alignment with Amino's core competencies and long-term objectives.
  • Resource Allocation: Determining the feasibility of scaling the product without compromising other initiatives.

This framework facilitated transparent discussions with stakeholders, leading to the decision to halt further investment in "Explore Cost."

Decision to Divest

Several factors contributed to the decision to divest:

  • Market saturation with established players
  • High implementation costs for employers
  • Limited differentiation in the market
  • Strategic focus shift towards core competencies

Divestment Process

Despite the decision to divest, it was imperative to honor commitments to existing customers and maintain trust. Actions taken included:

  • Beta Launch: Released "Explore Cost" as a beta product, covering 95% of mandated features, ensuring compliance with minimal maintenance overhead.
  • Customer Communication: Engaged in proactive dialogues with clients, providing clarity on product status and future support plans.
  • Internal Alignment: Conducted company-wide presentations to elucidate the rationale behind the strategic pivot, fostering organizational cohesion.
  • Technical migration support

Outcomes

  • Customer Retention: Successfully retained all existing customers, demonstrating effective change management and communication.
  • Resource Reallocation: Freed up critical resources, allowing the team to focus on initiatives with higher strategic value.
  • Organizational Learning: Enhanced the company's approach to product evaluation, emphasizing the importance of early-stage strategic alignment.

Key Learnings

  • Early market validation and strategical aligmment is crucial: Ensuring that product development initiatives are closely tied to overarching business goals from inception.
  • Clear communication with stakeholders is essential
  • Having a structured divestment process helps
  • Focus on customer impact during transition
  • Document lessons learned for future reference

Impact

The divestment allowed Amino to:

  • Focus resources on core product offerings
  • Reduce operational complexity
  • Improve financial performance
  • Strengthen market positioning

Other Tid Bits

User experience & compliance
To be compliant, we had to display certain data that made no sense to an end user, so we layered the data with simple explanations.
Explainability vs. performance
We had to display how complex calculations were made, which hindered rendering performance often. We used the opportunity to educate the user before seeing the results.
Embedding duplicative feature in existing product
When I joined the product was half way built, separate from our core product although it did have overlapping capabilities with our existing features. I learned it was simply due to moving to fast. If we had gone back and reset customer expectations and leveraged this product in our existing product, it would have actually improved our cost data accuracy.
Scalability
Our architecture struggled to aggregate, normalize, and process all the ~1TB of MRF data. We made minor improvements via technical clean up, but still had very long writing times. We had to phase the roll out of searchable services, which led to being incompliant.
Built with foundational model
In total it took 1.5yrs to build the product. I'm sure using a foundational model could have accelerated the build and maintenance cost. We could have leveraged GPT to help with our data scalability by pre-processing MRF files.
Augmentation and Automation
On a monthly basis it took 1 dev, 2 weeks to maintain both customer's instances. So we built a roadmap over time to bring that down to 1 dev, 1 day / month to maintain.
×