11 min

read

Navigating IT Dependency in Product Management: Strategies

Written by

Marcin Nowak

Published on

05 Jan 2024

Last update

28 Aug 2026

Why IT Dependency Is the VP Product’s Biggest Time-to-Market Problem in 2026

A few months ago I was in a working session with the VP Product of a $1.6B mid-market US P&C carrier. She had just come from a board meeting where the CEO had asked the question every Chief Product Officer dreads:

"Hannah, a competitor launched a parametric flood product in Florida in four weeks. We took eighteen months on a similar product. Why?"

Her honest answer was not actuarial. It was not regulatory. It was IT. Every product change at her carrier - a new endorsement, an eligibility rule update, a discount tier refresh, a state-specific filing amendment - routed through a four-month IT release cycle and required engineering sprint capacity that was already booked. Her business analyst, Linda, had forty-seven product change requests sitting in the IT queue at any given moment. By the time the rules shipped, the market window that motivated them was closed.

This is the operational shape of IT dependency in product management. Not a metaphor. Not a buzzword. The literal, quantifiable gap between when the product team decides what to ship and when the customer can buy it. McKinsey’s Global Insurance Report 2025 frames it bluntly: the carriers winning share in 2025-2026 are the ones who closed this gap; the carriers losing share are the ones who did not. Gartner’s research finds that only 55 percent of products make it to market on time due to these dependencies. The structural cost compounds quarter over quarter for carriers running on legacy product platforms.

This article walks through the operational shape of IT dependency in mid-market US P&C carriers ($500M–$5B GWP), the strategies VP Products and business analysts are actually using to reduce it, and the role of BRMS-based product configurators in changing the operating model. Most of the strategy framework below was in our original 2024 version of this article and held up well; what this refresh adds is the insurance-specific operational detail and the Higson-specific configurator capability that makes the abstract strategies concrete.

Challenges of IT Dependency in Product Management

Business agility, often hampered by IT-related disruptions in features, components, or teams, faces challenges in time-to-market and innovation due to IT dependencies. A profound understanding of these complexities enables businesses to plan effectively, ensuring efficient resource allocation for product development while maintaining market competitiveness.

Deloitte’s Mainframe Market Pulse Survey involving 261 business and IT decision-makers emphasized the critical role of mainframe-based technologies and the need for updating rules engines, with over half leveraging these engines to manage mainframe applications. Eighty-eight percent considered modernizing their rules engines, and 38 percent of those initiating application modernization regard upgrading the rules engine as a priority.

Hard-coded rules, often scattered across applications, necessitate manual identification of all instances and dependencies - a time-consuming process that increases time to market, costs, and risks. For insurance carriers specifically, this hard-coded rule problem also creates regulatory exposure: rules drift from filed rate plans, market conduct exams discover the drift, and compliance pain follows. Updating rules engines and adopting business rules management systems (BRMS) has become a critical priority for mid-market US insurance carriers facing both T2M pressure and 51-state regulatory variation.

Time-to-market delays

The product roadmap is essential for successful product management as it can help mitigate risks associated with IT dependency that could disrupt the development process. Gartner research shows that only 55 percent of products make it to market on time due to these dependencies. Customer experience suffers and revenue diminishes when launches stall. To maintain a competitive edge in the marketplace and keep customers happy, swift launching without disruptions is key - and this requires careful planning via an effective product roadmap.

For US P&C insurance specifically, the T2M penalty compounds. Each variant launch requires not only the IT release cycle but also state-by-state filing coordination through SERFF (System for Electronic Rate and Form Filing). A carrier with strong IT dependency typically takes 12-18 months end-to-end from product strategy approval to first policy bound; a carrier with reduced IT dependency through BRMS-based configurator capability typically takes 4-8 weeks plus the unavoidable state filing review duration. The math compounds across the variant pipeline.

Limited innovation

IT dependencies can significantly hinder innovation in product development. The limited access to resources and complex systems not only slow down the response to customer feedback and market trends but also constrain creativity and financial resources. This creates challenges in delivering diverse and innovative products, emphasizing the importance of effective resource management for fostering innovation.

Research indicates that the way product architecture and its components interact can affect innovation performance. Technological dependencies between components can undermine innovation efforts, especially when product development is centered around existing architectures.

The integration of product development with IT operations (DevOps) and a focus on continuous delivery are identified as key methods to enhance innovation. These approaches emphasize automation and continuous monitoring, which can significantly increase the speed to market and reduce the cost of delivering new products and services. However, the full potential of these methods is often not realized due to legacy IT systems, outdated technologies, and complex management processes - a McKinsey finding that mid-market US carriers I work with consistently reproduce in their own postmortems.

Inefficient resource allocation

Effective resource management in product management is crucial. Misallocation leads to resource shortages, inefficient processes, and communication gaps, causing project delays and inefficiencies. This can result in overuse of assets, lack of expertise, and inaccurate forecasting. Poor resource management impacts financial health, project success, and organizational stability.

In US mid-market P&C carriers specifically, the most consistent resource misallocation I see is treating Linda - the senior business analyst on the product team - as a specification writer who hands work off to IT, rather than as an operational owner of the rule logic. The carrier hires a CPCU-credentialed BA with eight years of insurance domain knowledge, then puts her in a role where she primarily writes documents that engineering will later code. The BA capability is underutilized; the engineering capacity is overconsumed; the product team’s overall throughput is constrained by both.

Linda’s Week: What IT Dependency Actually Looks Like at the BA Desk

Let me make this concrete with a specific scenario, because IT dependency in product management is often discussed in abstract terms when its operational reality is very specific.

Linda is the senior business analyst on Hannah’s product team. Eight years of insurance domain knowledge, CPCU designation, deep understanding of product structures, rate plans, and state regulatory variation. Zero formal coding background. In a typical mid-market carrier in 2024, Linda’s week with high IT dependency looked like this: receive a product change request from Hannah on Monday (e.g., "the new young-driver discount needs to apply in California, only for drivers under 25 with telematics enrollment, only for the next four quarters"). Translate it into a written rule specification by Wednesday. Hand the spec to IT on Thursday. Wait six to twelve weeks for the rule to ship. Validate that what shipped matches the spec (it often did not). Open defect tickets. Wait. The change went live two months after the original spec, and by then the segment opportunity had moved on.

Linda’s week with reduced IT dependency through a BRMS-based product configurator looks different. Same Monday request. By Tuesday morning, Linda has opened the decision table in her configurator (Higson Studio in our deployments, but the pattern is what matters), defined the new discount tier with eligibility predicates (under 25 AND California AND telematics enrollment AND four-quarter expiration), tested the discount stacking interaction against existing rules. By Tuesday afternoon, after Chief Actuary review of the pricing implication and Hannah’s walk-through of strategy alignment, the change publishes to staging with version control and rollback armed. By Wednesday, after compliance review for California filing implications, the change is in production. Three days instead of two months.

I watched the equivalent transformation at a mid-market commercial carrier last year. The CPO told me, going in:

"My BA Linda has 47 tickets backlogged with IT. Two-month average wait. I can’t launch products on time."

After a four-hour configurator enablement with Linda and the senior BA team, the ticket queue dropped to 3 in eight weeks. The other 44 they handled themselves. The CPO’s framing afterward:

"Linda is now my product strategy partner, not my ticket coordinator. Her career path opened up."

That last sentence is the part I want VP Products to hear. Reducing IT dependency is not just a T2M win or an operational efficiency win. It is a talent retention win. The Linda-equivalent BAs at mid-market carriers are some of the most domain-knowledgeable people in the organization, and the ones threatening to quit over IT bottleneck pain are exactly the ones the carrier cannot afford to lose. Configurator capability that puts the BA in a position to ship rules is what keeps them.

I will name an honest limit. Configurator-driven rule authoring is built for business analysts at Linda’s skill level. For genuinely complex rules - multi-variable ML risk models with custom mathematical operators, deep integrations with third-party data services, rules requiring custom Java extensions - Linda benefits from collaboration with Daniel, the enterprise architect persona. The 85/15 split holds across the deployments I have observed: Linda owns 85 percent of rule authoring solo; the remaining 15 percent is engineering-grade work where Daniel adds architectural value. Vendors who promise "100 percent no-code, no engineers, ever" set Linda up to fail on the 15 percent that requires architectural care.

Strategies for Reducing IT Dependency

To mitigate IT dependency, strategies like agile methodologies, cross-functional collaboration, and continuous improvement are vital. Agile methods enable flexibility and quick response to changes. Collaborating across diverse teams breaks down barriers, aligning goals and priorities. Emphasizing process improvement leads to more efficient systems, enhancing product development productivity. These approaches collectively reduce IT reliance and boost efficiency.

Agile methodologies

Agile methodologies concentrate on empowered individuals and their interactions, ensuring the early and constant delivery of value. They allow for early testing and rejection of decisions, with feedback loops providing benefits not evident in traditional methods.

The benefits of agile include increased employee input, responsiveness to customer feedback, higher job satisfaction, faster fixes, and more cross-functional collaboration. For US P&C insurance specifically, agile delivers most of its value when the configurator capability supports the iteration cadence agile requires. Agile sprints on top of a legacy product platform that requires four-month IT releases produces excellent sprint planning theater with no shipped product. Agile on top of a configurator that ships rule changes in days produces actual iteration cadence.

Cross-functional collaboration

Cross-functional collaboration in IT and product development enhances adaptability, customer connection, and creativity. This approach, supported by research, shows its effectiveness in driving innovation, especially during disruptions, by enabling quick environmental response and resource access, including diverse perspectives and skills.

Companies like CarMax demonstrate the success of this model in rapidly changing technological and customer landscapes. These teams often enjoy considerable autonomy and are more likely in supportive environments, contributing to their effectiveness.

In US P&C insurance specifically, the cross-functional pattern that works is a recurring product steering committee with explicit ownership lines: VP Product (portfolio strategy), Chief Actuary (rate adequacy and pricing logic), Head of Underwriting (eligibility and risk appetite), Head of Distribution (channel-specific behavior), CMO (segmentation and marketing alignment), Head of Claims (downstream impact monitoring), and General Counsel (regulatory implications). Bi-weekly cadence on a structured agenda. Decisions get made in the room. When this committee functions, IT dependency reduces materially because product decisions are not waiting for cross-functional consensus that happens via email over weeks.

Continuous improvement

Continuous improvement in product management involves regular analysis and updates based on feedback and market trends. It utilizes tools like PDCA (Plan-Do-Check-Act) and root cause analysis (5 Whys) to enhance innovation and user experience. Continuous improvement is an ongoing process focused on incremental changes to processes, products, and personnel, aligning with methodologies like lean and agile.

Successful companies embed this concept into every aspect, continuously seeking innovations and performance improvements, and understanding its importance across all business areas. Examples of companies that successfully adapted this concept include Toyota (Toyota Production System with Just-in-Time, Kaizen, Kanban, Andon), Amazon (deeply ingrained culture of continuous innovation, experimentation, risk-taking, customer-centricity), Apple (simplicity, aesthetics, user experience), General Electric (excellence and efficiency through ongoing improvement initiatives), Intel (product quality and customer satisfaction), and IBM (continuous improvement integral to operational philosophy).

For US P&C insurance carriers, the continuous improvement application looks like quarterly portfolio review with structured 90-day post-launch decision points: scale the variant, iterate, or kill. The discipline of structured 90-day decisions is what separates well-run product portfolios from carriers carrying decade-old variants nobody is paying attention to.

Business Rules Engines: A Solution for IT Dependency

Business Rules Engines (BREs) are crucial for navigating complex IT-dependent environments, streamlining decision-making, increasing compliance, and reducing IT dependency. BREs automate decision-making in varied business processes, handling complex data volumes and rules, such as government regulations and organizational policies.

BREs offer several key advantages:

Streamlined decision-making. BREs automate decisions, speeding up the process and enforcing compliance with business rules. They provide a support system for rules-based decision management, making organizations more efficient and responsive. Higson’s typical production execution runs sub-millisecond - 0.23ms per rule decision at sustained throughput of 9 000 requests per second per node - fast enough to power real-time pricing, eligibility, and configuration decisions at quote time rather than batch overnight.

Enhanced compliance and auditing. BREs ensure internal processes comply with regulations and laws, preventing severe penalties and reducing the risk associated with manual processes. For US P&C carriers specifically, this matters under the NAIC Model Bulletin on AI/ML in Insurance (now adopted by 23+ states plus DC as of late 2025), which requires per-decision explainability, bias testing, and governance documentation for AI-influenced rate and eligibility decisions. BREs produce per-decision audit trail stored alongside the policy, retrievable for market conduct exam.

Increased efficiency and adaptability. By removing manual decision-making, BREs save organizations time and cost incurred due to manual errors. They make the system more agile and responsive to changes, aiding in updating and managing rules more effectively. For mid-market US P&C carriers running products across multiple states, BREs that support rule isolation per state - one base ruleset plus state-specific override layers that compose at runtime - reduce the IT-dependency cost of 51-state filings substantially.

Overall, the use of BREs is akin to a compass in navigation, providing precision and direction in decision-making and policy adherence, making them indispensable in today’s fast-paced and complex business environment.

Real-World Examples of Business Rules Engines in Action

Using business rules engines has helped companies from numerous industries reduce their dependence on IT and become more efficient. We will look at two sectors that have employed these tools - financial institutions and insurance carriers - because both face high regulatory complexity and high rate-of-change requirements.

Financial institutions

A consistent example of BREs in action in the finance industry comes from interest rate adjustment cycles. Normally, when central banks adjust interest rates, financial institutions need weeks to implement the implications because of the numerous dependencies in their pricing and product logic. With BREs, the same adjustments can ship in minutes rather than weeks.

Operating on a production financial product is risky. An environment where rule changes can be safely tested before they go live is essential. Higson has a built-in sandbox testing module where business rule changes can be tested in isolation against historical data before they reach production. Mid-market financial services deployments I have worked with consistently report that the sandbox capability is what allows the BA team to ship rule changes confidently without the fear of breaking the production book.

Insurance carriers

In the insurance industry, Business Rules Engines are essential for managing complex decisions and regulations. These systems automate decision-making processes like underwriting policies, calculating premiums, and processing claims, improving accuracy and consistency.

They enhance efficiency and speed in decision-making, reducing operational costs and improving customer satisfaction by processing claims and underwriting policies more quickly. BREs also enable effective risk management, identifying potential risks to mitigate losses and improve financial performance.

BREs help reduce IT dependency in the insurance industry by automating repetitive tasks - form processing, rate calculations, eligibility decisions - and removing human error from these automated tasks. This automation leads to quicker policy creation and faster claim payments, enhancing customer satisfaction. BREs also offer flexibility by integrating with existing applications through APIs, eliminating the need for retraining on new platforms or UIs.

Higson reference deployments

Three deployments illustrate IT dependency reduction at mid-market scale specifically:

Allianz Poland - twenty-year partnership. Allianz Poland consolidated product configuration across 12+ product lines onto a single Higson-based product configurator over a multi-year program. The BA retention impact was the unexpected outcome - BAs who had been threatening to quit over IT bottleneck pain stayed because the configurator gave them ownership of rule authoring. Model deployment from research to production dropped from 6-8 weeks per rate plan iteration to under one week.

InterRisk (VIG Group) - Digital Sales Platform Transformation. InterRisk’s product team needed to launch three new auto endorsements across two regulatory regions in a six-week sprint window - historically a six-month effort. The IT dependency reduction enabled the sprint window to succeed. Regional filing prep time dropped approximately 70 percent.

BNP Paribas Cardif - Centralized Claims (public case study). Detailed in the BNP Paribas Cardif case study on Higson (/case-study/bnp-paribas-cardif-centralizing-claims-with-higson). Cross-vertical configurator unifying banking-distributed insurance products with consistent IT-dependency-reduced rule authoring across geographies.

I want to be honest about Higson’s positioning. Higson does not replace Sapiens IDIT, Duck Creek Product, Guidewire ProductManager, or Insurity PAS suites - we integrate as the specialized rules engine and product configurator layer underneath when carriers need (1) sub-millisecond rule execution PAS pricing modules typically cannot match, (2) decision-table-native rule authoring for the BA team, (3) 51-state rule isolation built natively, or (4) microservices-native architecture. For carriers running AI pricing models on Akur8 or Earnix, Higson deploys those models at production latency inline with rule execution - complementary, not replacement.

FAQ

Q. What is IT dependency in product management?

A. IT dependency in product management refers to the operational gap between when a product team decides what to ship and when the customer can actually buy it - a gap typically created by hardcoded business logic, sprint-based release cycles, and engineering capacity constraints. Gartner research shows only 55 percent of products make it to market on time due to these dependencies. For mid-market US P&C carriers, IT dependency typically extends product variant launches from 4-8 weeks (with modern configurator capability) to 12-18 months (with legacy infrastructure).

Q. How does IT dependency affect insurance product time-to-market?

A. For US P&C carriers, the T2M penalty from IT dependency compounds across the variant pipeline. Each launch requires not only the IT release cycle (typically 4-month sprint queue for rule changes) but also state-by-state filing coordination through SERFF. A carrier with high IT dependency typically takes 12-18 months end-to-end from product strategy approval to first policy bound; a carrier with reduced IT dependency through BRMS-based configurator capability typically takes 4-8 weeks plus the unavoidable state filing review duration.

Q. What strategies actually reduce IT dependency in product management?

A. Three strategies work in practice: (1) agile methodologies that enable iteration, but only when the configurator capability supports the cadence agile requires - agile on top of a legacy platform produces sprint planning theater without shipped product; (2) cross-functional collaboration through structured product steering committees with explicit ownership lines (VP Product, Chief Actuary, Underwriting, Distribution, CMO, Claims, General Counsel); (3) continuous improvement with structured 90-day post-launch decision points to scale, iterate, or kill variants. The strategies underneath all three is a BRMS-based product configurator that lets the BA team author and ship rule changes without engineering escalation.

Q. How does a business rules engine reduce IT dependency?

A. A BRMS externalizes business logic - eligibility, pricing, coverage, discounts, channel adjustments - out of application code into structured decision tables that business analysts can author, version, and deploy without engineering involvement. This compresses rule change cycle time from sprint-based IT releases (weeks to months) to BA-led publish-to-production (hours to days). Higson’s production execution runs at 0.23ms per rule decision with sustained throughput of 9 000 requests per second per node, enabling real-time decisioning at quote time.

Q. What role does the business analyst play in reducing IT dependency?

A. The business analyst (the Linda persona in our internal language) is the operational user who determines whether the BRMS investment actually produces IT dependency reduction. When the BA owns the rule authoring in the configurator with decision-table-native authoring, the IT escalation queue drops dramatically (47 tickets to 3 in eight weeks in one carrier I worked with). When the BA remains a specification writer who hands off to engineering, the IT dependency persists regardless of what BRMS the carrier purchased. The 85/15 split holds: BAs own 85 percent of rule authoring solo; the remaining 15 percent benefits from architect involvement on genuinely complex multi-variable logic or custom data integrations.

Q. How long does it take to reduce IT dependency at a mid-market US P&C carrier?

A. For BRMS-based product configurators at $500M-$5B GWP scale, typical end-to-end deployment runs 3-6 months from contract to first measurable IT dependency reduction. That includes rule migration from existing systems, state filing coordination, integration with existing PAS, and BA team enablement on decision-table authoring. Carriers being quoted 12-18 months are typically buying enterprise PAS replacement, which is a different category of project. Carriers being quoted 4 weeks are buying a demo rather than a production deployment.

Q. How does NAIC Model AI Bulletin compliance affect IT-dependent product changes?

A. For carriers using AI/ML in rating, eligibility, or risk segmentation, the NAIC Model Bulletin (now in 23+ states plus DC as of late 2025) requires per-decision explainability, bias testing, written AIS Program governance documentation, and third-party model oversight. A BRMS that supports these requirements natively - ONNX runtime ML inference with SHAP-derived explanations stored per rate decision - reduces the IT-dependency cost of compliance because the audit trail is automated. Carriers relying on application-code-based decisioning typically must retrofit compliance infrastructure, adding 6-12 months of unplanned engineering work.

Q. Does Higson replace existing PAS systems or product platforms?

A. No. Higson does not replace PAS suites like Sapiens IDIT, Duck Creek Product, Guidewire ProductManager, or Insurity - we integrate as the specialized rules engine and product configurator layer underneath when carriers need sub-millisecond rule execution, no-code rule authoring for BAs, 51-state rule isolation, or microservices-native architecture for embedded distribution. For AI pricing models built on Akur8 or Earnix, Higson deploys those models at production latency inline with rule execution - complementary, not replacement.

Take Full Control of Your Product Logic

If your product team has rule changes that have been sitting in the IT queue for two months, IT dependency is what is slowing your time-to-market. I would rather have a thirty-minute conversation about your specific operating model gap than send a generic vendor brochure.

Book a 30-minute product configurator demo - we walk through Linda’s day on Higson Studio, the 51-state rule isolation pattern, the sandbox testing module, and a sample rule change from BA authoring to production. No procurement cycle required.

Or, for a self-serve technical evaluation: Try Higson on AWS Marketplace at $0.63/hour for the PoC tier - same configurator your production deployment will use.