Architecture & Product Management

Product management decides which problems to solve, for whom and in what order, based on customer and business value; architecture ensures the chosen solutions can be built, evolved and operated at acceptable cost and risk. They share one goal, delivering valuable outcomes sustainably, from different angles. Product owns the why and the what; architecture shapes the how and the how well, including quality attributes, technical foundations and the long-term consequences of short-term choices. The relationship fails when either side works alone: product commits dates the system cannot meet, or architecture builds foundations nobody needs. In Claims 360 the two work as partners through joint discovery, a shared backlog and one roadmap.

An enabler is a backlog item that creates technical foundations so future features can be delivered faster, more safely or at all, without delivering user-visible functionality itself. Examples are an API gateway that partner FNOL integration depends on, deployment automation, a performance-test harness, observability or a new data platform. In SAFe and similar frameworks enablers are an explicit work type alongside features, technical debt and operational work. The important property is that each enabler is justified by what it unlocks: the gateway was valued by the six weeks partner APIs would otherwise be blocked. Enablers that cannot be linked to future features or reduced risk are usually gold-plating and deserve challenge.

Because without it, every enabler, debt item and operational fix must win a fresh argument against a visible customer feature, and it usually loses until something breaks. A capacity allocation agrees in advance what share of team capacity each work type receives. On Claims 360, product and architecture signed 65 percent features, 20 percent enablers, 10 percent technical debt and 5 percent operations, reviewed every PI. Product still prioritises within the feature share, and items in the other shares are prioritised jointly. Exceptions are planned, such as raising operations to 10 percent before cyclone season, and review triggers, such as more than three blocked features, prompt renegotiation based on evidence.

By joining the discovery trio with the product manager and designer from the start, not after the roadmap is fixed. My contribution is to answer five questions quickly. Is it feasible, with a sketch of options, dependencies and any spikes needed? What quality does it need, written as quality attribute scenarios for latency, availability, scale and security? What will it cost to build and run, as t-shirt effort and a run-cost estimate, such as GPU cost for photo assessment? What does it enable next? And what could go wrong, as the top risks? Answering these lets roadmap dates rest on reality and surfaces one-way-door decisions before commitments are made.

Translate it into product currency, meaning time, money, delay and risk, rather than code-quality metrics. On Claims 360 the team measured hours lost per sprint to manual deploys, flaky tests and database waits, 137 hours, and showed the chart to product leadership every PI; deployment automation was funded and paid back within two sprints. Other measures are cost of delay, such as partner APIs blocked for six weeks without the gateway; incident cost, such as rupees per hour of FNOL downtime; the interest on a hotspot, such as 32 lakh rupees a year; and risk exposure, such as an unpatched runtime that will become an audit finding. Rough numbers with stated assumptions suffice.

Minimum viable architecture is the least architecture that safely supports an MVP and its likely next steps. The rule is to decide now only the one-way doors, the choices that are expensive to reverse, and defer everything reversible until evidence arrives. For Claims 360's partner FNOL pilot, the authentication model, API contract and data ownership were decided upfront because changing them later would break partners, while multi-region deployment, caching and rate tiers were deferred. For the photo assessment beta, the model-hosting boundary and human review path were fixed, while autoscaling tuning and cost optimisation waited. It avoids both extremes: over-engineering a product that may pivot, and an MVP that must be rewritten.

Place items on two axes, business value and architectural significance, and treat each quadrant differently. High value, high significance work, such as a new claims workflow, gets serious architecture effort before any dates are committed. High value, low significance work is simply built now. Low value but high significance items are typically enablers; they are justified by the features they unlock and by their cost of delay, not on their own merit. Low value, low significance work is deferred. This prevents two opposite failures: significant decisions being rushed because a feature was urgent, and enablers being postponed forever because, viewed on their own, they appear to deliver nothing.

By writing each product goal as a quality attribute scenario with a measurable response, attached to the epic during discovery. FNOL in under three minutes becomes FNOL submission at p95 of 400 ms or better under five times normal load. Cyclone-ready becomes document uploads surviving a twentyfold surge with processing within five minutes. Partners self-serve becomes 99.9 percent partner API availability and onboarding in under a day. Trust becomes no PII in logs and an audit trail for every decision. Each scenario names source, stimulus, environment, response and measure, so it can be designed against, tested automatically in the pipeline and monitored in production.

Options with their consequences, so that product can make an informed choice. A veto invites a workaround; options invite a decision. For partner FNOL, instead of refusing to expose the internal API, the architect offered three: expose it directly in two weeks, with high coupling and security risk; build a partner facade with OAuth2 in six weeks, with low risk; or ship a read-only facade in three weeks and the full facade next PI. Each showed time, run cost, risk and future cost, and product chose the third. The levers are scope, time, quality targets, cost and accepted risk, and any debt created is recorded with an owner.

Put enablers, technical debt and platform work on the same roadmap as features, with dependency arrows showing which features they unlock, instead of maintaining a separate technical roadmap that product never reads. The gateway enabler sits directly before the partner FNOL feature it supports, so delaying one visibly delays the other. Use confidence levels, such as now, next and later, rather than precise dates far into the future. Review the roadmap jointly every PI and adjust the capacity split when the evidence demands it. A shared dashboard combining product metrics with DORA metrics reinforces that delivery speed and system health are one conversation, owned together by product and architecture.