I inherited a backlog with no methodology — every client claiming P0, engineering with 6 release slots, and the math not adding up. The real problem wasn't execution capacity. It was that nobody had made the tradeoffs explicit. A backlog without prioritization logic isn't a strategy. It's a queue.
Sapiens CoreSuite is an enterprise insurance platform used by tier-1 insurance carriers globally. Handles policy servicing, fund management, digital customer portals, and compliance workflows. Serves 500K+ end customers through Sapiens' insurance carrier clients.
A backlog of 50+ features with no consistent prioritization methodology. Multiple clients each believing their request was P0. Engineering with 6 release slots for the year. No framework for how decisions had been made. A queue masquerading as a roadmap.
My mandate: define and drive the product roadmap for CoreSuite's policy servicing and fund management modules, with a specific focus on enabling digital portal integration for enterprise clients. The real work, it turned out, was building the decision-making infrastructure before touching any feature.
In enterprise B2B SaaS, every client believes their request is the most urgent. That belief is often legitimate — from their perspective. The PM's job is not to validate every belief. It's to build a framework that makes the tradeoffs legible and defensible to everyone.
The three questions the backlog couldn't answer when I arrived:
Which features create the most value for the most clients? (Client breadth vs. single-client requests)
Which features are table-stakes for contract retention vs. which are growth enablers? (Survival vs. expansion)
Which features carry technical risk high enough that sequencing matters? (What unlocks what)
Without answers, the roadmap defaulted to whoever had the loudest client relationship. That's not prioritization — that's noise allocation.
Clients ask for features. What they actually need is confidence that the platform is moving in the right direction. Prioritization transparency — knowing what's coming and trusting it will ship — improved client satisfaction without shipping a single line of code. I invested as deliberately in communication cadence as in feature delivery.
Structured sessions to understand each client's 12-month digital roadmap and where CoreSuite fit in their plans. Key question: what does "success" look like in their planning horizon? The answer varied by client — which itself was a prioritization input.
Finding: Different clients needed different things in different timeframesSat with the lead architect to map technical dependencies between features. Some features were gating others — building them in the wrong order would create rework. This is a prioritization input that no amount of client interviews can surface.
Finding: 8 features had hidden dependencies that changed their viable release slotCompared what clients were requesting (feature requests) vs. what they were complaining about (support tickets). These were meaningfully different. Support tickets surfaced real pain; feature requests surfaced desired solutions. The pain is often more reliable than the solution.
Finding: Top 3 support categories weren't in the top 10 requested featuresEvery backlog item scored on four dimensions. Composite score determines release slot assignment.
How many of our active clients benefit from this feature? Score 1–5. A feature serving 3 clients scores higher than one serving 1 — even if the 1-client request is louder.
Weight: 30%Is this feature tied to a specific contract commitment or renewal? Features with explicit revenue consequences score highest — regardless of how "exciting" or "strategic" they are.
Weight: 35%Does this advance platform differentiation, or does it maintain feature parity with competitors? Differentiating features score higher. Table-stakes features still get built but score lower.
Weight: 20%Does this depend on a complex architectural change that might slip? High-risk features are scored down — not eliminated, but moved adjacent to releases where engineering has capacity for a spike.
Weight: 15% (inverse)The resulting logic: features scoring high on Client Breadth + Revenue Linkage → Release 1–2. Features high on Strategic Value but low on Client Breadth → Release 4–6. Features with high Technical Risk → adjacent to engineering capacity windows.
More importantly: the framework made the tradeoffs visible. Clients could see why their feature was in Release 4 instead of Release 2. Disagreement became a data conversation, not a relationship conversation.
Release 3 had a conflict that the framework couldn't resolve automatically — it required a judgment call:
Feature A: A digital self-service portal for policyholders. Requested by 2 clients, visible to end customers, modernizes the product story. Internal metric: higher score on client breadth and strategic value.
Feature B: An internal batch processing optimization. Requested by 1 client, invisible to customers, high engineering complexity. But it was tied directly to that client's renewal decision.
The framework said Feature A. The revenue signal said Feature B. I took both to the product steering committee with explicit trade-off framing: "If we do A, we have a better product story but risk this client renewal. If we do B, we protect revenue but delay the portal work two other clients are waiting for."
I personally communicated the delay to the two clients waiting for Feature A — committing to Release 4 with dedicated capacity and explaining the reason. Required de-prioritizing two smaller Release 4 features. Those were re-scoped into Release 5. The client retained. No surprises, no burned relationships.
Insurance carrier clients have near-zero tolerance for production defects. A policy processing error on a Sunday night is not a minor bug — it's a compliance incident. I introduced a 95% pre-production quality gate: every release went through API-level testing in Postman, with me personally validating integration scenarios before UAT opened to clients.
Slightly longer delivery cycles. Each release cycle added approximately 3–5 days for personal validation before client UAT. Some sprints felt slow.
Zero P1 defects shipped to clients in 6 months. Client confidence in release reliability. Carriers started planning their own integrations around our release dates — a sign of trust, not just satisfaction.
Clients who trust the platform's reliability take on more integration risk and expand their usage. Every clean release is a trust deposit. I track pre-production quality rate as deliberately as any feature metric — because it compounds.
| Decision | What I Chose | Why | Tradeoff Accepted |
|---|---|---|---|
| First 30 days | Understand before executing — no sprints started | Executing a bad backlog fast just creates faster wrong outcomes; needed the framework first | Delayed first release cycle by ~3 weeks; justified by framework quality that followed |
| Release 3 conflict | Feature B (invisible, revenue-protecting) | Revenue certainty > roadmap aesthetics; a better product story with a lost renewal is not a success | Two clients waited an extra release cycle; required direct communication to manage expectations |
| Pre-production quality gate | 95% quality before UAT opens | Insurance clients cannot absorb production defects; reliability is a growth lever, not just a cost | Slightly longer delivery cycles per release |
| API design ownership | PO owns API documentation, not just engineering | Prevents spec drift between what I specify and what clients receive; technical fluency is a product responsibility | More technical work for me as PO; appropriate given the integration complexity |
The most significant non-metric result: clients started referencing the release communication cadence in their own planning documents. Predictability had become a product. They trusted what was coming — which is the precondition for everything else.
They ask for features. What they actually need is confidence that the platform is moving in the right direction. My job is often to provide that confidence — through communication, prioritization transparency, and consistent delivery — as much as it is to ship a specific feature.
For enterprise clients, knowing what's coming and trusting it will actually ship matters as much as the feature itself. I've invested as deliberately in consistent release communication as in feature quality. This has improved client satisfaction without shipping a single line of code.
The 4-factor matrix is useful for making the right call. But its bigger value is making the call defensible to clients who disagree. When a client asks why their feature is in Release 4, the answer isn't "because I decided so." It's "here's how it scored on the four factors, and here's what would need to change for it to move up."
Every clean release is a trust deposit. Clients who trust reliability take on more integration risk and expand faster. The 95% quality gate looked like a cost in the first sprint and looked like a growth strategy by month 4.