İkinci Derece Düşünme Modeli

The Discount Is Never Just a Discount

Your first-order thinking says: "Discount wins the deal." Second-order thinking asks: and then what? The 20% discount doesn't just close one account—it re-prices your entire product in the market's collective mind.

The consequence chain you're missing:

1. Your existing enterprise customers will hear about this within a quarter—sales teams talk, procurement shares benchmarks. Their renewal conversations now start from "we know you gave 20% off."
2. Competitors don't need to match you; they need to undercut your new reference price. Your discount becomes the new ceiling for every future negotiation.
3. Your sales team learns that discounts close deals. Next quarter, they'll ask for the same tool. You've trained your own organization to lead with price, not value.

The deeper trap: In a zero-sum market, first-order thinkers all reach the same conclusion—"discount to win." By definition, that's already priced into your competitive landscape. The differentiator is asking what the discount triggers in others.

Actionable alternative: Instead of 20% off, offer 10% off plus a value-added service or extended contract term. This protects your price anchor while still closing the deal—and it's harder for competitors to replicate than a simple price cut.

Ask yourself: "If I were my customer's procurement head, how would I use this discount against my own sales team next year?"

The Cheaper Material Isn't Cheaper—It's a Different Product

Your immediate savings are first-order. The second-order question is: what changes in the entire system when you swap inputs?

Map the downstream chain before you commit:

1. Quality drift — Cheaper materials often have wider tolerance bands. Your product may still pass specs, but with less margin. Six months out, that's more field failures at the edges of your operating envelope.

1. Warranty claims lag — Here's the trap: the cost savings show up this month, but warranty expenses show up next quarter. Your P&L will look great for two quarters, then get hit with a spike you can't easily attribute to the material change.

1. Customer trust is asymmetric — You lose trust in one incident, but it takes years to rebuild. A single high-profile failure at a key account doesn't just cost that account—it becomes a case study your competitors use in every pitch.

The "and then what?" test:

• If warranty claims rise 10%, what's the cost? (Not just replacement—but support hours, engineering time, and reputation.)
• If a competitor keeps the old material, what story do they tell your customers?

Actionable approach: Run a 90-day pilot on a non-critical product line. Measure not just cost savings, but scrap rate, rework time, and customer complaint trends. If the pilot shows quality holds, scale it. If not, you've learned cheaply.

Chesterton's Fence applies here: the old material may have been chosen for reasons the cost spreadsheet doesn't show. Find out why before you remove it.

The 5% Feature Is Probably a Fence—Here's How to Test Before Removing It

Your instinct is correct. Chesterton's Fence says: don't remove a fence until you know why it was put there. A feature used by only 5% of users isn't necessarily dead weight—it might be load-bearing for that 5%.

The second-order consequences of removal:

1. Power users are your revenue — In most SaaS, the top 5-10% of users generate disproportionate value: they're your champions, your renewal advocates, and your referral sources. Alienating them over a UI simplification is a bad trade.

1. Unmeasured reliance — You said "we haven't measured" how they use it. That's the key gap. The feature might be a workaround for a deeper workflow need. Remove it, and those users either churn or build shadow workarounds that create support tickets.

1. The "and then what?" chain — You remove the feature → 5% of users complain → you add it back as an "advanced mode" → now you have two UIs to maintain, which is more work than before.

Actionable approach before you remove anything:

• Interview 10 users who actively use the feature. Ask: "What would you do if this disappeared?" Their answer tells you if it's a fence or a decorative post.
• Check support tickets and feature requests mentioning it. If it's referenced in workarounds, it's load-bearing.
• Offer it as an opt-in "legacy mode" for 60 days. If no one opts in, remove it with confidence.

The engineering team's happiness is a first-order benefit. The 5% users' silent churn is the second-order cost. Measure the latter before you act on the former.