02 / Perficient · AI Compliance Platform
Blue Cross Blue Shield of Massachusetts
Perficient / Client work for Blue Cross Blue Shield of Massachusetts
While at Perficient, I worked on the delivery of a consumer-facing insurance marketplace for Blue Cross Blue Shield of Massachusetts, helping define API contracts, integration requirements and a self-service onboarding flow designed to support scale from launch.
- Role
- Product Manager
- Company
- Perficient
- Client
- Blue Cross Blue Shield of Massachusetts
- Product
- Insurance Marketplace Platform
- Focus
- Integrations · Onboarding · Consumer Product
67,000
Users at launch
Context
Health insurance is bought under time pressure, in language most people encounter only once a year. A marketplace has to make plan differences legible without oversimplifying regulated benefit detail.
The platform also had to sit on top of existing insurance systems, so much of the product work happened at the boundary between the consumer experience and the services behind it.
The problem
A self-service marketplace only works if plan discovery, eligibility and enrolment behave consistently across every underlying system it depends on.
Comprehension
Premiums, copays and out-of-pocket maximums have to be comparable at a glance.
Integration surface
Plan, eligibility and enrolment data arrive from separate systems with different contracts.
Self-service
Every step that requires assistance reduces completion and increases support cost.
Launch scale
The experience had to hold up for a large user base from day one.
What I owned
I contributed to the delivery of the marketplace as Product Manager, working across client stakeholders and engineering on API contracts, integration requirements and the self-service onboarding flow.
API contracts
Defined the interfaces between the marketplace and the systems behind it.
Integration requirements
Specified how plan, eligibility and enrolment data had to behave end to end.
Onboarding flow
Shaped a self-service path from plan discovery through to enrolment.
Client collaboration
Translated client and compliance constraints into buildable product scope.
My approach
Plan discovery came first: filtering, pricing and side-by-side comparison had to answer the question a member actually arrives with before any enrolment step is introduced.
Integration contracts were treated as product decisions rather than implementation detail, because the shape of the data determines what the interface can honestly present.
In regulated consumer products, clarity is the feature. The interface has to make a complex decision comparable without editing away the detail that matters.
Product rationale
Product rationale
- Challenge
Plan information could be presented as a dense benefit table or as a progressive comparison flow.
- Product implication
- —Show every benefit field upfront for completeness
- —Progressive disclosure with a focused comparison view
- Approach
Lead with a small set of comparable attributes and let members open full plan detail when they need it.
- Why it mattered
Comparison stays usable at the moment of decision while the regulated detail remains one step away.
Product rationale
- Challenge
Integrations could be defined per screen or as shared contracts across the marketplace.
- Product implication
- —Bespoke integrations shaped by each screen's needs
- —Shared API contracts consumed across discovery, comparison and enrolment
- Approach
Define shared contracts so the same plan data behaves identically wherever it appears.
- Why it mattered
Consistency across the flow, and a smaller surface to validate before a launch at scale.
System / workflow
How a member moves from an initial query to an enrolled plan.
Product considerations
Product consideration
Reducing the comparison to a handful of attributes makes plans legible, but regulated benefit detail cannot be dropped. Detail moved one layer down rather than out.
Product consideration
Bespoke integrations would have shipped individual screens sooner. Shared contracts cost more upfront and made the launch surface predictable.
Execution
- Definition
Mapped the marketplace journey and the systems each step depends on.
- Contracts
Defined API contracts and integration requirements with engineering and the client.
- Onboarding
Specified the self-service flow from plan discovery through to enrolment.
- Launch
Validated the experience against scale expectations ahead of go-live.
Outcome
67,000
Users at launch
The marketplace launched with 67,000 users, supported by shared API contracts and a self-service onboarding flow designed to hold up at that scale.
Reflections
Contracts are product surface
The shape of the data decides what the interface can honestly show.
Comparison is the product
In a marketplace, the decision step matters more than the catalogue.
Client work needs shared framing
Alignment on constraints upfront is what keeps delivery predictable.
Next case study
MedByte
Building an AI-powered wellbeing platform from 0 → $500K ARR