Offering customers deployment flexibility from managed SaaS to complex on-premise installations often feels like essential table stakes in enterprise software. Vendors list options, sales teams confirm availability, and engineering prepares for varied environments. Operationally, it seems like necessary market responsiveness. Strategically, however, this frequently masks a costly disconnect.

“The single biggest problem in communication is the illusion that it has taken place.” – George Bernard

The illusion here is that offering deployment choice equates to a sound strategy, often without a shared internal understanding of the profound operational and financial consequences across the Deployment Complexity Spectrum, visualized below:

Consider an enterprise security vendor’s platform. Their cloud-native solution delivers threat detection efficiently through centralized intelligence and real-time updates (Managed SaaS). Yet, certain market segments federal contracts, highly regulated industries (often requiring Private Cloud or On-Premise), and organizations with strict data sovereignty requirements legitimately demand deployment options further right on the spectrum. Supporting these models isn’t simply a matter of preference; it’s sometimes a necessity for market access.

However, accommodating these more complex deployment models triggers that cascade of business implications. Engineering faces the friction of packaging for disparate environments; Sales encounters drastically longer cycles navigating security and infrastructure reviews with more stakeholders; Implementation becomes bespoke and resource-intensive; Support grapples with unique, often opaque customer environments typical of Hybrid Cloud or On-Premise setups. The key isn’t avoiding these markets entirely, but rather making conscious strategic decisions about how to serve them while understanding the full business impact.

This isn’t just about technical difficulty; it’s about a fundamental business trade-off between market access and operational efficiency. Let’s examine the quantifiable impact:

Enterprise Security Vendor – Annual Deal Comparison (Illustrative):

• Cloud-Connected Platform (SaaS/Hybrid):
  • Annual Revenue: $500,000 | Sales Cycle: 4 months | Implementation: $20k | Margin: 75% | Support: Low/Standardized
• Isolated On-Premise Platform (Same Core Functionality):
  • Annual Revenue: $700,000 | Sales Cycle: 12 months | Implementation: $150k | Margin: 25% | Support: High/Bespoke

The higher on-prem ARR is dwarfed by the tripled sales velocity drag, the 7.5x implementation cost, the margin collapse, and the ongoing high support burden. Even when necessary, this “complexity tax” must be accounted for. The long-term financial disparity becomes even clearer when visualized over time:

A Framework for Strategic Deployment Evaluation

To move beyond operational reactivity, vendors need a framework that explicitly evaluates the impact of supporting points along the deployment spectrum. This framework should quantify the true business impact, forcing conscious trade-offs:

• Sales & Go-to-Market Impact (Weight: ~25%):
  • Quantify: How does this model affect sales cycle length? (On-prem often 2-3x longer). Example Key Metric: Sales Cycle Length (Days)
  • Identify: Does it require engaging more stakeholders (networking, security, infra, procurement), complicating the sale?
  • Assess: What is the cost of sales and required presales expertise vs. potential deal value? Does it accelerate or impede overall business velocity?

• Implementation & Delivery Cost (Weight: ~30%):
  • Measure: What is the typical implementation time? (Days/weeks for SaaS vs. months/years for complex on-prem). Example Key Metric: Implementation Margin (%)
  • Factor In: Does it require bespoke configuration, custom infrastructure knowledge, and navigating complex customer organizational boundaries and politics?
  • Calculate: What is the true implementation cost and its impact on gross margin? How repeatable and predictable is delivery?

• Operational Scalability & Support Burden (Weight: ~30%):
  • Analyze: How difficult is troubleshooting in varied, often opaque customer environments with limited vendor visibility? Can issues be easily replicated? Example Key Metric: Avg. Support Tickets per Account per Quarter
  • Resource: Does it require broadly skilled support staff or specialized experts per environment? How does this impact support team scalability and cost-per-customer?
  • Compare: Contrast the ease of automated monitoring and centralized support in SaaS vs. the manual, reactive nature of complex deployment support.

• Customer Value Realization & Retention (Weight: ~15%):
  • Evaluate: How easily can customers access new features and improvements? Does this model enable SaaS-like continuous value delivery (think Tesla’s overnight updates) or does it rely on disruptive, infrequent upgrades? Example Key Metric: Net Revenue Retention (%) by Deployment Model
  • Track: How visible are product usage and value realization? Does lack of visibility (common in on-prem) hinder proactive success management and create renewal risks?
  • Engage: Does the model foster ongoing engagement or lead to “out of sight, out of mind,” weakening the customer relationship?

(Note: Weights are illustrative examples, meant to provoke thought on relative importance.)

This framework brings the hidden costs and strategic trade-offs into sharp focus, facilitating data-informed decisions rather than reactive accommodations.

Three Deployment Strategy Archetypes

Applying this framework often leads vendors towards one of three strategic postures:

1. The SaaS-First Operator: Maximizes efficiency by focusing on SaaS and standardized cloud, accepting limitations on addressable market as the key trade-off to preserve operational leverage and innovation speed.
2. The Full Spectrum Provider: Commits to serving all models but requires disciplined execution: distinct architectures, specialized teams, rigorous cost allocation, and pricing reflecting true complexity. High risk if not managed strategically with extreme operational discipline and cost visibility.
3. The Strategic Hybrid Player: Primarily cloud-focused but supports specific, well-defined Hybrid or On-Premise use cases where strategically critical (e.g., for specific regulated industries or control-plane components). Aims for a balance between market reach and operational sustainability, requiring clear architectural boundaries and disciplined focus.

Implementation: Aligning Strategy with Execution

Making the chosen strategy work requires aligning the entire organization, incorporating lessons from both successful and struggling vendors:

• Recognize the fundamental differences between cloud-native (for SaaS efficiency) and traditional architectures. Align product architecture with target deployment models; avoid force-fitting. Consider distinct codebases if necessary.
• Ensure pricing models accurately reflect the total cost-to-serve for each deployment option, including the higher sales, implementation, and support burden for complex models (e.g., conduct quarterly reviews of actual cost-to-serve per deployment model).
• Create dedicated teams or clear processes for the unique demands of selling, implementing, and supporting complex deployments. Don’t overload SaaS-optimized teams.
• Even for on-prem, develop standardized deployment models, tooling, and best practices to reduce variability.
• Invest in secure monitoring/diagnostics for non-SaaS environments where feasible to improve support efficiency.
• Ensure internal alignment on the strategy and its rationale. Clearly communicate capabilities, limitations, and expectations externally (e.g., ensure support SLAs clearly reflect potential differences based on deployment complexity). Avoid the “illusion” of seamless flexibility where significant trade-offs exist.
• Ensure executive alignment across all functions (Product, Engineering, Sales, Support, Finance) on the chosen deployment strategy and its implications. Resource allocation must match strategic intent.

Conclusion

Choosing which deployment models to offer, and how, is a critical strategic decision, not just a technical or sales tactic. It fundamentally shapes your business’s operational efficiency, cost structure, product architecture, innovation capacity, and customer relationships. As the visualized business impact illustrates, ignoring the true costs of complexity driven by technical realities, architectural limitations, and organizational friction can cripple an otherwise successful business.

By using a multi-dimensional framework to evaluate the real impact of each deployment option and aligning the entire organization behind a conscious strategy, vendors can move beyond reactive accommodations. Success lies not in offering every possible option, but in building a sustainable, profitable, and scalable business around the deployment choices that make strategic sense. Avoid the illusion; understand and communicate the true impact.

When a product reaches the end of its lifecycle, companies typically create simple tables mapping products to migration paths, target dates, and release milestones. While operationally necessary, these tables often fail to capture the complex nature of EOL decisions. As George Bernard Shaw aptly said, “The single biggest problem in communication is the illusion that it has taken place.” These simplistic EOL tables create precisely this illusion-providing the comfort of a decision framework without addressing the strategic nuances.

Consider a neighborhood bakery that supplies all baked goods to a large grocery store chain. After a change in ownership, the new bakery manager reviews the product lineup and identifies a specialty pastry that appears to be an underperforming outlier-purchased by only a single customer. With a purely product-centric analysis, discontinuing this item seems logical.

However, this pastry happens to be a signature item for the grocery chain, which purchases substantial volumes across the bakery’s entire range. When informed about the discontinuation, the grocery store explains that their customers specifically request this specialty pastry. The bakery manager refuses to reconsider, emphasizing that the product isn’t profitable enough and the production line is needed for more popular items.

A few weeks later, the bakery learns that the grocery chain has decided to replace them entirely with a new vendor capable of meeting all their needs. The interaction was handled so poorly that the grocery store, despite being a major customer, isn’t even inclined to renegotiate-they’ve moved on completely.

This scenario vividly illustrates a common but critical strategic error: viewing products in isolation rather than considering their value in customer relationships. The quantitative analysis reveals the magnitude of this mistake:

Enterprise Account Analysis:

• Specialty Pastry: $12,000 annual revenue, -8% margin
• All Other Products: $680,000 annual revenue, 22% margin
• Total Account Value: $692,000 annual revenue, 21% blended margin
• Risk Assessment: Discontinuing the specialty pastry put $692,000 at risk, not just $12,000
• Outcome: Complete loss of the account (100% revenue impact vs. the expected 1.7% impact)

The bakery manager made several critical errors that we see repeatedly in product EOL decisions. They treated each pastry as an isolated product rather than part of a larger strategic relationship. They failed to recognize the pastry’s importance to their major client. They made decisions based purely on aggregated sales data without customer segmentation. They approached the conversation without empathy or alternatives. And they prioritized immediate resource allocation while overlooking long-term consequences.

A Framework for Better Decisions

To avoid similar mistakes, organizations need a comprehensive approach that evaluates EOL decisions across dimensions that understand the whole business, here is an example of how this might work in our bakery example:

• Customer relationship impact should be the primary consideration in any EOL decision, weighing approximately 40% in the overall assessment. This includes evaluating the aggregate revenue from all products with shared customers, the customer’s classification and business importance, the probability of triggering a broader portfolio review, and what C-level relationships are tied to the product.
• Product economics matter but must be viewed holistically, accounting for about 25% of the decision weight. Consider the product-specific recurring revenue and growth trajectory, any “door opener” and account protection value, ongoing engineering and operations expenses, volume and complexity of support tickets, and margin trajectory over time.
• Technical considerations evaluate the maintenance burden against potential disruption, weighing approximately 20% in the decision process. Assess technical debt quantification, resources allocated across engineering and support, systems that depend on this product, estimated customer transition effort, and infrastructure and stack viability.
• Market position provides critical competitive context, contributing about 15% to the decision framework. Consider the percentage of customers actively using the product, strength of the unique value proposition, fit with long-term product vision, and segment growth trajectory.

Note: These % figures are really intended as examples rather than strict guidelines.

These four dimensions provide a balanced view of a product’s strategic importance beyond immediate financial metrics. The bubble chart above illustrates their relative weighting in the decision process, emphasizing the outsized importance of customer relationships.

Three Product Archetypes and How to Handle Them

Most EOL candidates fall into one of three categories, each requiring a different approach:

• Strategic anchor products have high customer relationship impact despite potentially challenging economics or technical debt. Like the bakery’s specialty pastry, they may appear unprofitable in isolation but protect significant broader revenue. Organizations should retain these products despite costs, as they protect broader customer relationships and associated revenue streams, though pricing adjustments might be considered if necessary.
• Legacy systems typically have balanced profiles with high technical maintenance burden but moderate customer impact. They often represent technical debt accumulated through growth. The wise approach is to modernize rather than discontinue to maintain customer relationships, creating migration paths that preserve core functionality while reducing technical debt.
• True EOL candidates have low customer attachment and minimal dependency chains. Their strategic value has diminished over time as the market has evolved. These products can be considered for end-of-life treatment with appropriate migration paths and thoughtful customer communication, ensuring smooth transitions to alternatives.

The radar chart above illustrates how these three product archetypes compare across the four dimensions. Strategic anchor products show high customer relationship impact, legacy systems typically have high technical burden but moderate customer impact, and true EOL candidates score low across most dimensions.

Implementation: Making It Work in Practice

Successful EOL decisions require collaboration across the organization through a structured process. Begin with thorough data collection across all dimensions, then integrate perspectives from Sales, Customer Success, Product, Engineering, and Support. Project different transition timelines and potential impacts. Present multidimensional analysis to secure leadership alignment. Develop thoughtful communication that acknowledges the full context.

As the bakery example illustrates, EOL decisions are fundamentally about managing complex trade-offs. The framework shifts the conversation from “Should we discontinue this product?” to “What is the strategic value of this product to our customers and business?”

By moving beyond simplistic spreadsheet analysis to a multidimensional approach, organizations can make EOL decisions that enhance rather than damage customer relationships, technical architecture, and market position.

Remember Shaw’s warning about the illusion of communication. Your EOL tables may give the appearance of strategic planning, but without considering all dimensions, they’re merely operational checklists that risk overlooking critical strategic value. The true measure of EOL success isn’t operational execution but customer retention and long-term business impact.

We cannot do everything; the French have a saying, “To choose something is to renounce something.” This also holds true for Product Managers. How we choose is important, especially in a startup where resources are finite.

The larger the organization, or the more political it is, having a framework that we use for decision-making helps us both increase the chances of good decisions and defend the uncomfortable decisions that must be made.

The highest priority of a product manager is to be a good custodian of the engineering resources. This means we must ensure they have the information they need to make the right engineering investments; otherwise, we are wasting the most valuable asset in the organization.

The next highest priority is to ensure that the sales and support team has what they need to keep the funnel full. This might include marketing materials, product roadmaps, one-on-one customer engagements, or a myriad of other inputs to the sales process that enable the field to support teams to jump-start the revenue engine.

With that said, if all we do is focus on those two things, we fail. Product management is about solving a specific business problem in an elegant and timely manner. This requires research, customer interviews, designs, and roadmapping. Once we unblock engineering, sales, and support, we must shift our priority to optimizing the conversion funnel.

We need to prioritize optimizing how each stage of the sales funnel works while ensuring the existing sales, support, and engineering processes function as needed.

The path to success involves balancing immediate needs with long-term strategic goals and continually refining the process to ensure that the product not only addresses current market needs but is also positioned for future growth and success. This also requires us to continually assess, as independently as we can, how the organization is doing on these metrics so we can make sure how we prioritize evolves with the ever-changing needs of the organization.

As the product manager, you are in many respects the general manager for the business. If you get too focused on a task mindset, simply put, you will miss the forest through the trees, which for a small company can be the difference between death and success.

The Decision Engine

What makes this funnel particularly powerful is that each stage generates critical information that fuels better decision-making. As a product manager, you’re not just moving customers through stages—you’re creating a decision engine that systematically improves how you allocate resources and prioritize efforts.

When focusing on filling the funnel, every piece of messaging that resonates or falls flat gives you data that refines your market understanding. The leads that convert tell you which pain points matter most; those that don’t reveal gaps in your value proposition. This creates a natural feedback loop where better market understanding leads to more effective messaging, which generates higher-quality leads, further enhancing your understanding.

This pattern continues as prospects move toward contracts. Here, you learn precisely where your offering stands relative to alternatives. Which features accelerate decisions in your favor? What competitive gaps slow down contract signing? These insights should directly influence your product prioritization decisions, creating a virtuous cycle where enhanced differentiation speeds contract closure.

Product Design: The True Driver of Sales Velocity

Looking at our funnel, it’s tempting to see words like “quickly,” “successful,” and “renewals” as purely sales-driven metrics. In reality, these outcomes are fundamentally shaped by product decisions. Each “quickly” in our funnel represents not just a sales process optimization but a product design imperative.

Consider the pilot stage. Moving through pilot “quickly” isn’t just about sales execution—it’s about how you’ve designed the product to be deployed, configured, and integrated. A product that requires weeks of professional services to set up creates an inherent velocity constraint that no sales process can overcome. Your architectural decisions directly determine how rapidly customers can reach value.

Similarly, moving to full production quickly depends on how you’ve designed for scalability from the beginning. Does your product require painful reconfiguration when moving from pilot to production? Have you anticipated enterprise requirements for security, compliance, and integration? The deployment friction your customers experience is built into your product decisions long before the sales team encounters it.

Making customers “successful” and securing renewals are likewise outcomes of product strategy more than sales tactics. A product designed with deep customer empathy, clear use cases, and thoughtful success metrics creates its own momentum toward renewal. Conversely, even the most skilled customer success team can’t compensate for a product that doesn’t deliver measurable value aligned with the customer’s definition of success.

As a product manager, recognize that you’re designing not just features but the velocity of your entire business. Every decision that reduces friction in deployment, integration, scalability, and value realization accelerates your funnel more effectively than any sales process optimization could.

Communication: The Force Multiplier of Decision-Making

The greatest decision framework in the world fails if it remains inside your head. The biggest problem with communication is the illusion that it has occurred. As a product manager, you can never communicate too much about decisions and their rationale.

Clear communication turns good decisions into organizational alignment. When engineers understand not just what to build but why it matters to customers and the business, they make better micro-decisions during implementation. When sales understands the strategic reasoning behind a feature prioritization, they can communicate this context to customers, turning potential disappointment into a deeper relationship.

Insufficient communication of decisions and rationale inevitably leads to loss of focus and momentum. Teams begin to drift in different directions, making assumptions about priorities that may conflict with your actual intentions. You’ll find yourself having the same conversations repeatedly, wondering why people “just don’t get it.” The answer is usually that you haven’t communicated nearly as effectively as you thought.

This communication challenge often necessitates difficult conversations and realignment throughout the process. Team members may have become invested in directions that no longer align with your decisions. Having to reset expectations is uncomfortable but essential. These conversations become significantly easier when you’ve consistently communicated the decision framework and the data informing it.

Effective communication of decisions requires multiple formats and repetition. The same message needs reinforcement through documentation, presentations, one-on-ones, and team discussions. Remember that people need to hear information multiple times, in multiple contexts, before it truly sinks in. What feels like redundant overcommunication to you is often just barely sufficient for your stakeholders.

Most importantly, communicate not just the what but the why. Decisions without context are merely directives; decisions with context create learning opportunities that help your team make better autonomous choices aligned with your strategy.

Embracing Constraints

It’s worth acknowledging a fundamental truth of product management: resource constraints are inevitable regardless of your organization’s size. Even companies with seemingly infinite resources must choose where to allocate them. Google, Amazon, and Apple all discontinue products and say “no” to opportunities—size doesn’t eliminate the need for prioritization, it just changes the scale of what’s possible.

Priority conflicts and organizational challenges will always be part of the landscape you navigate. You’ll encounter competing stakeholder needs, passionate advocates for conflicting approaches, and the politics that come with any human enterprise. This isn’t a sign that something is wrong—it’s the natural state of building products in complex environments.

The key difference between effective and ineffective product managers isn’t whether they face these challenges, but how they approach them. By being transparent about the first and second-order effects of your decisions, you create trust even when stakeholders disagree with your choices. When engineering knows why you’ve prioritized feature A over feature B, they may still be disappointed but can align with the reasoning.

Perhaps most importantly, remember that few decisions are truly permanent. The best product managers maintain the humility to monitor outcomes and change course when the data suggests they should. Your decision framework should include not just how to decide, but how to recognize when a decision needs revisiting. This adaptability, coupled with transparency about your reasoning, creates the resilience necessary to navigate the inevitable twists in your product journey.

Building Decision Frameworks That Scale

As product managers, we should strive to make our analysis and decision processes repeatable and measurable. Using consistent rubrics helps ensure that the insights generated at each funnel stage don’t remain isolated events but become part of an institutional learning process.

These rubrics need not be complex—simple scoring systems for evaluating feature requests against strategic goals, or frameworks for assessing customer feedback patterns—but they should be consistent. By standardizing how we evaluate options, we create the ability to look back quarterly and yearly to assess the quality of our decision-making.

Did we ask ourselves the right questions? Did we weigh factors appropriately? Which decision frameworks yielded the best outcomes? This retrospective analysis allows us to internalize lessons and deploy improved decision processes more consistently across the organization. Over time, these rubrics become the scaffolding that supports better and faster decisions as the company grows.

Feeding the Company’s Soul

As a product manager, you are the custodian of more than just resources—you are feeding the very soul of the company. Product is where vision meets reality, where strategy becomes tangible, and where customer needs translate into business value. Each decision you make, each iteration loop you create, fuels the journey toward the company’s next milestone.

These seemingly small decisions—which feature to prioritize, which customer segment to focus on, which technical debt to address—collectively determine the trajectory of the entire organization. The funnel isn’t just a conversion mechanism; it’s the heartbeat of your business, pumping valuable insights that nourish every subsequent decision.

Your most valuable contribution isn’t the individual decisions you make, but how you architect the feedback loops that transform customer interactions into organizational learning. By systematically capturing and applying these insights, you create not just a product but an ever-evolving organism that adapts and thrives in changing conditions.

Remember that in a startup, the line between success and failure is often razor-thin. Your ability to make good decisions, informed by these iteration loops, may be the difference between reaching that next funding milestone or running out of runway. You’re not just building a product—you’re charting the course that determines whether your company reaches its destination or disappears beneath the waves.