← Priyanka Das
CASE STUDY · UNEMPLOYMENT PLATFORM
Case study · Public sector · 2021–2023

Cutting a week-long benefits journey to 2 hours — across 26 funds.

ROLE: PM · BUSINESS ARCHITECT DOMAIN: PUBLIC SECTOR GEOGRAPHY: SE / DE SCALE: 500K+ USERS/YEAR
96%
journey-time reduction
500K+
users served/year
26
A-Kassa funds aligned
1
unified REST schema

The problem

Swedish & German unemployment benefits weren't broken because the technology was bad. They were broken because 26 different A-Kassa funds — each with its own data contracts, eligibility rules, internal politics and operational pace — were trying to serve one citizen through 26 different paper-heavy processes. Caseworkers had to re-key the same information into incompatible systems. A typical first assessment took five working days end-to-end. People who had just lost their jobs were waiting a week to know if they qualified for support.

What I owned

I was embedded as the Product Manager / Business Architect across the platform programme: discovery through phased rollout. That meant requirements discovery with caseworkers across multiple funds, defining the PRD and roadmap, prioritising backlog with the engineering org, and running the alignment workshops that turned 26 different stakeholder positions into one schema everyone could ship against.

Approach

The instinct most people had was to build 26 integrations. I argued the opposite: one canonical REST schema, with a per-fund migration runway. Each fund kept its existing internal system; the schema was the contract between them and the unified assessment platform. Funds with simpler workflows went first and proved the model; the more complex ones came later with confidence baked in.

The hard work wasn't technical. It was running two rounds of discovery workshops with caseworkers across multiple funds, then mapping each fund's actual day-to-day workflow against the proposed schema and surfacing every edge case before we shipped. Decisions were documented as auditable trade-offs — what we explicitly chose to support, what we explicitly de-scoped, and what was reversible in v2.

The unlock wasn't a better system. It was getting twenty-six stakeholder funds to agree on one customer schema. The tech was the easy part.

Outcome

What I'd carry forward

Two lessons. First — in regulated, multi-stakeholder environments, the value of a documented trade-off compounds. Every reversible decision needed an explicit rationale, and that rationale paid for itself the third time a steering committee challenged it. Second — discovery is not a phase, it's a posture. We kept caseworker interviews running through rollout, and most of the post-launch fixes came from the same workshops we'd used at discovery.

PRODUCT MANAGEMENT BUSINESS ARCHITECTURE PUBLIC SECTOR PEGA STAKEHOLDER ALIGNMENT REST API DESIGN SAFe AGILE DISCOVERY → ROLLOUT