You’ve run the diagnostic. You’ve cleaned house on dead features. Leadership is at least willing to try something different. Now comes the hard part: actually launching a pilot team that can prove craft works in your org.

This is where most transformations fail. Not because the idea is wrong, but because the pilot team gets crushed by organizational pressure within a few weeks. Here’s how to keep them alive long enough to show results.

The Minimum Viable Change

You cannot change everything at once. You’ll lose. Pick one team. The smallest unit that can own a complete customer problem. Three to eight people. Product manager, engineers, designer.

Give them one problem to solve. Not a feature to build. A problem. “Customers churn within 90 days because they can’t figure out how to integrate our product into their workflow” is a problem. “Build an onboarding wizard” is a feature.

Change their metrics.

All of them. Collectively accountable for:

• Adoption rate of whatever they ship (percentage of target customers actively using it)

• Time to value (how long until customers get meaningful results)

• Single Ease Question (SEQ) scores (ask “How easy was it to complete this task?” on a 7-point scale immediately after they use the feature)

• Retention improvement for customers who use it versus those who don’t

Remove their individual metrics. No story points. No velocity. Just shared accountability for customer outcomes.

Give them authority to make tradeoffs. They can simplify the solution to increase adoption. They can say no to requirements that won’t drive outcomes. They can build less but better. They can kill features from the plan that dilute the core value. They decide what will actually get customers to adopt and get value, not what checks every stakeholder’s box.

Protect them.

When sales wants a custom feature for a deal, the answer is no unless it serves the problem this team owns. When an executive has an idea, it goes in the backlog like everything else. When someone complains they’re moving too slow, you point to the outcomes.

This team becomes your proof of concept. If they can’t show better outcomes within two quarters, craft won’t work in your org. If they do, you have evidence to expand.

How to Actually Align Incentives

You can’t just “add” customer outcome metrics to existing metrics. That’s how you get 15 OKRs and nobody knows what actually matters.

You have to replace metrics. Not supplement. Replace.

For product managers

Old metric: Features launched, deals closed, revenue influenced
New metric: Adoption rate of shipped features, time to value for customers, SEQ scores, retention improvement tied to product quality

How to calculate each new metric

Adoption rate: Users who completed feature’s core action ≥2x in 30 days / Total users with access. Example: 450 users integrated ÷ 1,200 users with access = 37.5% adoption.

Time to value: Median days from feature availability to first meaningful action. Track in product analytics. Example: Median 11 days from invitation sent to first successful integration.

SEQ scores: Average response to “How easy was it to complete this task?” (1–7 scale) triggered immediately after core action. Example: 1,240 responses, average 5.9 out of 7.

Retention lift: 90-day retention rate for users who adopted feature minus baseline retention. Example: Feature adopters: 78% retained. Baseline: 65% retained. Lift: +13 points.

Engineers and designers get measured on:

Same metrics. Shared accountability for adoption, time to value, SEQ scores, retention.

No code coverage targets. No lines of code. No “designs approved” or “design system contributions.” The only question: did customers adopt what we built and did it improve their outcomes?

How comp structure changes

Bonuses

70% based on team outcomes (adoption, time to value, SEQ, retention), 30% based on company outcomes (revenue, overall retention). No individual metrics.

Promotions

“Shipped features customers loved and used” becomes the criterion. Not “shipped on time” or “led three projects.”

Performance reviews

Template changes to:

• What customer problem did you help solve?

• What were the outcome metrics? (Include adoption %, time to value, SEQ, retention lift)

• What did you learn that will make the next thing better?

The transition plan (because you can’t flip overnight)

Quarter 1

Announce new metrics for pilot team only. Rest of org stays on old metrics. Pilot team comp is 50% old metrics, 50% new metrics (hedge during transition).

Quarter 2

Pilot team comp is 100% new metrics. Start measuring new metrics for three expansion teams, but don’t tie comp yet (tracking period).

Quarter 3

Expansion teams move to 50% old, 50% new metrics. Pilot team shows results to broader org.

Quarter 4

Expansion teams move to 100% new metrics. Half the org is now tracking new metrics.

Quarter 5–6

Scale new metrics to entire product org.

You can’t skip the transition. Moving everyone overnight triggers panic and resistance. Gradual rollout with visible results gives doubters time to see it works.

Navigating the Political Landmines

The VPs will resist. They’ll say you need revenue metrics. They’ll say engineering needs delivery metrics. They’ll say this is too risky.

Before you push back, find an executive sponsor. Ideally the CEO, but at minimum someone with real authority who believes craft matters. Without air cover, the next part can get you fired.

How to identify your executive sponsor

Look for someone who:

• Has asked “why don’t customers use our features?” in the last 90 days

• Has direct P&L or product authority (not a staff role)

• Has fired or threatened to fire someone over product quality

• Has mentioned a competitor and said “their product feels better than ours”

• Has at least four years tenure (they’ve seen enough cycles to value durability)

The conversation to have with them

“I pulled the data on our last 10 shipped features. Average adoption: 14%. Three features have under 5% adoption. That’s $2.3 million in engineering time building things customers don’t use. Our retention trails [competitor] by 18 points.

The current metrics got us here: launches, velocity, features shipped. If we keep measuring the same things, we’ll keep getting the same results.

I want to run a pilot. One small team, one customer problem, new metrics: adoption, time to value, satisfaction, retention. Two quarters. If outcomes improve, we expand. If not, we kill it and I’ll own the failure.

I need you to protect them from sales escalations and exec requests for two quarters. Can you do that?”

If they say yes, you have a sponsor. If they hedge: ”sounds interesting, let me think about it”, they’re not your sponsor. Keep looking.

How to build a coalition among peers

Don’t present to all VPs at once. You’ll get crossfire and they’ll protect their turf.

Instead: One-on-one conversations with each VP. Customize the pitch:

VP Engineering

“Our velocity looks high, but we’re rebuilding the same things every six months because we didn’t build them well the first time. Technical debt is compounding. This pilot will slow initial velocity but reduce rework long-term.”

VP Sales

“We keep building custom features to close deals, then 80% of customers don’t use them. That’s not a moat. This pilot will build features customers actually adopt, which improves retention and gives you referenceable customers.”

VP Customer Success

“We’re drowning in tickets because features are confusing. SEQ scores will force us to ship things customers can actually use, which reduces support load.”

Get each VP to yes individually before the group meeting. By the time you present to everyone, you have allies in the room.

What to do if CEO says yes but VPs undermine it

Month 1

VP asks pilot team to “quickly add” a feature for a deal. You email CEO: “Pilot team received request from [VP] to work on [feature] for sales deal. This dilutes focus on [problem]. Confirming pilot team priority: [problem] through [date], correct?”

Month 2

VP complains pilot team is moving too slow. You email CEO: “Pilot team shipped first iteration. Early metrics: 35% adoption, SEQ 5.8. [VP] is concerned about velocity. Want to confirm we’re optimizing for outcomes, not speed. Align?”

Month 3

VP tries to add metrics to pilot team. You email CEO: “Pilot team metrics: adoption, time to value, SEQ, retention. [VP] wants to add velocity tracking. This muddies accountability. Can you reconfirm pilot metrics with [VP]?”

You’re not tattling. You’re giving your sponsor clear decision points. Every time a VP undermines the pilot, your sponsor reinforces the boundary or admits they can’t protect you. Either way, you know where you stand.

How to use board members or advisors as leverage

If you have no internal executive sponsor, look external.

Board member who’s built product companies

“I’m trying to transform how we build product. Current approach: 12% feature adoption, retention trails competitors by 15 points. Can I walk you through a pilot plan and get your feedback?”

If they like it: “Would you be willing to mention this to [CEO] as something worth trying?” Board signal often unlocks CEO attention.

Advisor who scaled craft-focused companies

Same approach. “Can you share what worked at [their company]?” Then: “Would you talk to our CEO about this?”

External validation from someone the CEO respects can substitute for internal sponsorship, but only temporarily. You still need to convert an internal exec within two quarters or the pilot dies when the advisor’s attention shifts.

Protection Playbook: Rituals and Responses

Once you have executive sponsorship, protection becomes a set of repeatable moves you execute weekly.

Weekly rituals that create boundaries:

Monday: Review escalation requests. Any sales custom feature request? Engineering lead emails: “Thanks for flagging. This doesn’t align with [team’s problem statement]. Parking in the general backlog for future consideration.”

Tuesday: Check exec calendar invites. Did someone invite the team to a strategy session, roadmap review, or planning meeting outside their scope? Product lead declines: “Team is focused exclusively on [problem] through [date]. Can sync after we measure outcomes.”

Thursday: Review what the team said yes to this week. Did they commit to anything that dilutes focus? Kill it in standup: “That’s not our problem to solve. Who owns that? Let’s hand it off.”

The four fights you’ll have (and what to say)

Sales: “This feature blocks a $500k deal.”

You: “What’s the evidence customers will adopt it after we close the deal? Last three sales-driven features had 8% adoption. That’s $1.2 million in engineering time for features customers don’t use. Show me adoption evidence, or it goes in the backlog.”

Exec: “Why can’t they also work on [strategic initiative]?”

You: “They’re accountable for improving retention for [customer segment] by 10 points. We measure that in six months. Splitting focus means we measure nothing. Which outcome matters more?”

Engineering: “Pilot team shipped one thing this quarter. We used to ship four features per quarter. This is killing our velocity.”

You: “We used to ship four features with 12% average adoption. Pilot team shipped one feature with 58% adoption. Customers care about the second number. Velocity means improving customer outcomes, not deploying code nobody uses.”

Team reverts to specs:

When product starts writing a detailed spec: “What’s the evidence customers will adopt this? Don’t write a spec until you’ve talked to 8–10 customers, prototyped three approaches, tested the simplest one, and confirmed customers will actually use it. Then write the spec for what you validated, not what you guessed.”

Monthly check-ins to maintain air cover

Month 1: Meet with executive sponsor. Show pilot team focus: “One problem. Four metrics. No distractions. Will have data in 60 days.”

Month 2: Meet with executive sponsor. Show early signals: “Shipped first iteration. 35% adoption in two weeks versus 12% historical. SEQ scores 5.8 out of 7. Still early, but directionally good.”

Month 3: Meet with executive sponsor + VPs who’ve been pushing back. Show results: “Adoption: 58%. Time to value: down from 18 days to 6. SEQ scores: 6.2. Retention: +12 points for customers who adopted. This is what craft looks like.”

If you can’t execute these moves weekly, don’t start the pilot. The team will drown in organizational pressure within six weeks.

What End-to-End Ownership Actually Looks Like

Stop writing specs. Seriously. If product is writing detailed specs that get handed to design that get handed to engineering, you’re still running a feature factory.

Instead

Product brings a customer problem with evidence (not a solution). Template:

• Problem statement: [Customer segment] can’t [achieve outcome] because [obstacle].

• Evidence: Talked to [number] customers. [X]% confirmed this is their top-3 problem. Current behavior: [what they do instead]. Cost of current approach: [time/money wasted].

• Success metrics: Adoption target [%], time to value target [days], SEQ target [score out of 7], retention lift target [points].

The team (product, design, engineering together) explores solutions:

• Monday: Product shares problem and evidence. Team brainstorms 5–8 solution directions. No filtering yet.

• Tuesday: Designer sketches three approaches. Engineer does quick feasibility check on each (1–2 hours, not detailed design). Product identifies 3–5 customers to test with.

• Wednesday: Team picks simplest approach that could work. Engineer builds quick prototype (clickable, not production code).

• Thursday: Product tests prototype with 3 customers. Records sessions. Team watches together.

• Friday: Team decides: ship it, iterate it, or kill it. If ship: engineer scopes production build. If iterate: designer revises based on feedback. If kill: back to Tuesday with different approach.

They decide together what to build based on what will drive outcomes. No handoffs. No “design is done, now engineering starts.” Overlapping work, continuous collaboration.

They build it together

Designer in daily standups. Not just “here’s the status,” but “here’s what I’m seeing in build and here’s how we could adjust.”

Product reviewing builds in staging every two days, not just at the end. Catches misalignments early.

Engineer flagging technical constraints that affect UX. “This approach requires 8-second load time. That’ll kill adoption. Can we simplify?”

They measure together whether it worked

Week 1 post-launch: Review adoption curve. 15% adoption in first week—on track for 50%+ by week 4, or lagging?

Week 4 post-launch: Review full metrics. Adoption: target hit? Time to value: target hit? SEQ: target hit?

Week 8 post-launch: Review retention lift. Are customers who adopted this sticking around at higher rates?

Retrospective: What worked? What didn’t? What will we do differently next time?

Hiring and Training for Craft

Most people don’t have the skills for end-to-end ownership. You’ll need to hire differently or train differently or both.

For hiring

Designers: Give take-home projects that require understanding technical constraints.

• Project: “Design a feature that needs to work on web, iOS, and Android. Explain which elements can be shared across platforms and which need platform-specific approaches. Show your design system thinking.”

• Red flag answer: Designs three completely different approaches without acknowledging platform constraints.

• Good answer: Identifies shared components, explains platform-specific adaptations, shows awareness of engineering effort.

Engineers: Give take-home projects that require thinking about user experience.

• Project: “Build a feature that lets users upload and preview files. Optimize for ease of use, not just for technical correctness. Explain your UX decisions.”

• Red flag answer: Builds feature with no upload progress, no error states, no empty states. Pure happy path.

• Good answer: Considers edge cases from user perspective. Progress indicators. Clear error messages. Graceful failures.

Product managers: Look for facilitators, not deciders.

• Interview question: “Tell me about a time your team disagreed about what to build. How did you resolve it?”

• Red flag answer: “I made the call based on my experience.”

• Good answer: “I brought everyone together. We listed our assumptions. We ran a quick test to validate the key assumption. The data showed which approach would work. We aligned around that.”

For training

Designers: Pair with engineers for one week. Sit with them during implementation. See what’s easy and what’s hard to build. Watch trade-offs in real time.

Engineers: Attend five customer interviews. Watch users struggle with the product. See what confuses them. Take notes on friction points. Report back to team.

Product managers: Use the product daily for two weeks. Document every friction point. Time how long tasks take. Record every moment of confusion. Share with team.

The goal is to make everyone care about the whole problem, not just their piece.

The Person Who Can Say No

Someone needs authority to kill things that won’t drive customer outcomes. Not veto power over everything. Authority specifically to say “this won’t get adopted” or “this won’t improve retention” or “customers won’t get value from this.”

This is usually a product leader, but it could be anyone with:

• Direct access to customer outcome data

• Understanding of the full product, not just one area

• Political cover to piss people off

Their job is to look at every proposed feature and ask

What’s the evidence customers need this?

• Acceptable: “Talked to 12 customers. 9 said this is top-3 problem. Showed them rough prototype, 8 said they’d use it weekly.”

• Not acceptable: “Sales says customers are asking for it.” (Sales hears what closes deals, not what drives adoption.)

What’s the adoption hypothesis? (How many customers will use it?)

• Acceptable: “Feature targets customers in [segment]. That’s 2,400 customers. Based on problem severity and prototype feedback, expect 55–65% adoption.”

• Not acceptable: “Everyone will love this.”

What’s the value hypothesis? (What outcome improves if they use it?)

• Acceptable: “Customers who adopt this will complete [workflow] in 4 minutes instead of 18 minutes. Expect retention to improve by 8–12 points based on correlation between time-to-value and retention in similar features.”

• Not acceptable: “It’ll make the product better.”

Can we test this more cheaply than building it?

• Acceptable: “Yes. We can prototype in Figma, test with 8 customers, validate adoption hypothesis before engineering starts.”

• Not acceptable: “We need to build it to see if it works.”

If those questions don’t have good answers, the feature doesn’t get built. Even if sales needs it. Even if a competitor has it. Even if an executive wants it.

This person will be hated

Sales will complain they’re blocking deals. Executives will complain they’re not responsive to strategy. Other product managers will complain they’re too rigid.

Protect them. Publicly.

When someone complains in a meeting: “What’s the evidence customers will adopt this and it will drive retention or growth?” If they don’t have evidence, case closed.

When someone escalates to you: “We’re optimizing for features customers actually use. Last quarter, pilot team: 58% adoption. Rest of org: 14% adoption. [This person] is making sure we build things that work. That’s the job.”

If you can’t protect this person, don’t hire them. They’ll burn out or leave within six months.

When to Start Small vs When to Burn It Down

Most orgs should start with one pilot team. But some are so broken that a pilot can’t work. Here’s how to tell:

Start with a pilot if

You can get budget for one autonomous team (typically $800k–$1.2M annually: 5–7 people fully loaded)

You have at least one executive who believes craft matters (will protect the team for two quarters)

Your product has discrete areas that one team could own (you’re not so entangled that everything touches everything)

You can protect that team from organizational pressure for two quarters (sales escalations, exec requests, resource-sharing demands)

Burn it down and start over if

Every decision requires five stakeholders to approve (one team can’t move without triggering coordination overhead)

Your product is so entangled that no team could own a complete problem (changing login flow requires touching 14 services owned by 8 teams)

Your best people are already leaving because they’re frustrated (lost 3+ high performers in last 6 months)

Leadership explicitly values speed over quality and won’t reconsider (”ship fast, fix later” is official strategy)

If you’re in the second category, you have two options: convince the CEO this is existential (good luck) or leave. There’s no middle ground.

What This Looks Like in Practice

Real example from a company that did this:

They had a team of 6 people. Product manager, three engineers, designer, data scientist. Their problem: customers who didn’t integrate within 30 days churned at 80%.

The feature factory approach

Product writes spec for integration mapping wizard based on sales feedback. Design makes mocks. Engineering builds it over 8 weeks. They ship. 7% of customers use it. Churn doesn’t improve. Feature gets abandoned.

Cost: 8 weeks × 6 people × $3,000 per week = $144,000 for something that didn’t work.

The craft approach

Week 1

Whole team talks to 10 customers who churned. Learns integration is confusing but wizard isn’t the problem. The problem is customers don’t know what data to map. The wizard won’t fix that.

Week 2

Designer sketches three different approaches:

1. wizard with better guidance

2. pre-configured templates for common use cases

3. AI that suggests mappings.

Engineer does quick feasibility check. Templates are simplest. AI is 6-month project, they’re in a regulated industry so extra compliance work is required. Wizard still doesn’t solve core problem. Team picks templates.

Week 3

Engineer prototypes templates in two days. Not production code, just enough to test. They test with 5 customers. Customers love it but want one change: ability to customize template after selecting it.

Week 4

Engineer adds customization to prototype. They ship to 10% of customers as beta.

Weeks 5–7: Monitor metrics:

• 60% of beta users select a template (adoption is working)

• Time to integration drops from 12 days to 4 days (time to value is working)

• SEQ scores average 6.2 out of 7 (ease is working)

Week 8

Ship to 100% of customers.

Week 12

Retention data comes in. Customers who integrated with new flow: 75% retention. Customers who integrated with old flow: 20% retention. Retention lift: +55 points.

Why this worked

They owned the problem. They could make tradeoffs (picked templates over wizard when they learned what actually worked). They tested fast (prototype in days, not months). They measured outcomes (adoption, time to value, SEQ, retention). No handoffs. No 6-month project. No feature nobody uses.

Cost: 3 weeks × 6 people × $3,000 per week = $54,000 for something that drove massive retention improvement.

That’s craft.

Next: Part 3 covers your detailed week-by-week execution playbook, the quarter-by-quarter transformation timeline, how to sustain craft through leadership changes, and when to give up.

You read the diagnostic. You checked boxes. You’re convinced your org is hostile to craft. Now what?

Here’s the cost of staying put: you’re burning $2–4 million annually shipping features less than 10% of customers use. Your retention trails craft-focused competitors by 15–20 points. Your best engineers leave every nine months because they can’t do their best work. Meanwhile, someone who values craft is taking share. Sometimes it’s a startup building something that works better. Sometimes it’s the incumbent in your space who never stopped caring. Either way, you’re losing ground.

The window closes. Every quarter you wait, technical debt compounds, good people leave, and the gap widens.

Now the bad news: you can’t incrementally improve your way to craft. You can’t “align incentives a little bit” or “try shared ownership on one project.” The changes required are structural and political. They threaten people’s positions. They force uncomfortable conversations about who owns what.

If you’re looking for permission to not change, here it is:

building for craft is hard, most orgs can’t do it, and you’re probably better off finding a company that already values it than trying to transform yours.

Still here? Good. Here’s how you actually do it.

Start With the Diagnostic That Matters

Before you change anything, you need to know exactly where you are. Not vibes. Numbers.

Pull the data on your last 10 shipped features

What percentage of customers actually use them? (Active users, not just “has access”)

• Tool: Product analytics dashboard (Amplitude, Mixpanel, Posthog, or your own)

• Query: Customers who performed feature’s core action ≥1x in 30 days / Total customers with access

• Benchmark: <20% adoption = crisis territory; 20–40% = mediocre; >60% = you might already value craft

How long did it take customers to get value? (Time to first meaningful action)

• Tool: Event tracking from activation to first core action

• Calculation: Median days from first login to completing feature’s primary job

• Benchmark: <7 days = good; 7–21 days = friction; >21 days = broken

What’s the satisfaction score for each feature?
(Single Ease Question on a 7-point scale right after they use it, task completion or something similar, not overall NPS or CSAT)

• Tool: In-app microsurvey triggered after feature completion

• Question: “How easy was it to complete this task?” (1 = Very Difficult, 7 = Very Easy)

• Benchmark: <5.0 = frustrating; 5.0–6.0 = acceptable; >6.0 = delightful

Did retention improve for customers who used it versus customers who didn’t?

• Tool: Cohort analysis in retention dashboard

• Calculation: 90-day retention rate for users who adopted feature vs. baseline

• Benchmark: No lift = wasted effort; +5–10 points = marginal; >10 points = meaningful

If you can’t answer these questions, that’s your first problem. You’re not measuring customer outcomes. Start there.

Understand the Motivations

Then map those features back to why they were built. How many were built because:

• Sales needed it to close a deal

• A competitor launched it

• An executive thought it was a good idea

• You had actual evidence customers needed it and would use it

Be honest. The ratio will be brutal.

Now look at your team’s current metrics. What is product actually measured on? What does engineering get rewarded for? What gets design promoted?

Write it down. All of it.

Create a document titled “Current State - [Date]”:

• Last 10 features: adoption %, time to value, SEQ scores, retention lift

• Build rationale: sales-driven vs. competitor-driven vs. exec-driven vs. evidence-driven (count each)

• Current metrics: what actually drives comp, promotions, performance reviews

This is your before state. You’ll need it when people claim nothing needs to change.

You’ll also need it six months from now when your pilot team shows 58% adoption versus the historical 12%, and someone says “we’ve always had good adoption.”

Archive it. Bookmark it. When the organizational antibodies attack, this is your immune response.

What to Do With All the Dead Features

You just documented 10 features with 8–15% adoption. They’re taking up space in your product, confusing customers, and burning engineering time on maintenance. Now comes the uncomfortable part: what do you do with them?

You have two choices for each feature. Only two.

Choice 1: Unship it

The feature has low adoption because it doesn’t solve a real problem. Maybe it was built to check a box on an RFP. Maybe it was a competitor response. Maybe an executive thought it sounded good. Either way, customers don’t use it, which means it’s providing zero value.

Unship it. Remove it from the product. Yes, this will cause fights. Sales will say “but we sold it to three customers.” Those three customers aren’t using it. Check the data.

The cost of keeping dead features:

• Engineering maintains code nobody uses

• QA tests flows nobody runs

• Docs and support cover features nobody adopts

• New customers get confused by clutter

• Your best people work on maintenance instead of impact

Calculate it: low-adoption feature × maintenance cost × number of features. That’s millions of dollars maintaining things customers don’t want.

Choice 2: Commit to solving the actual problem

Maybe there’s a real customer problem buried under the failed feature. The integration wizard has 12% adoption not because customers don’t need integrations, but because the wizard doesn’t actually solve their problem.

If you choose this path, you’re committing to:

• Talk to customers who tried the feature and stopped using it

• Talk to customers who never tried it

• Understand the actual problem (not the feature request)

• Reconsider unshipping it, now that you understand more about it

• Build a solution that drives 50%+ adoption

• Measure whether it improves retention

This isn’t “make some tweaks.” This is “treat it like a new problem and build the right solution.” Same process as the pilot team: problem statement, customer research, prototyping, measuring outcomes.

If you’re not willing to commit to that level of work, unship it. Half-measures waste more time. And if you do unship feature, make sure you celebrate it internally as much as you do releasing a feature, arguably more.

What you can’t do: leave them as-is

The worst option is keeping low-adoption features in the product while claiming you’ll “get to them later.” You won’t. They’ll sit there for years, accumulating technical debt, confusing customers, and burning maintenance time.

This is your forcing function. Leadership either commits to craft (unship the junk, rebuild what matters) or reveals they’re not serious (”we can’t unship anything, customers might need it someday”).

The decision framework

For each low-adoption feature, ask:

1. Is there a real customer problem here?
   Talk to 5–10 customers. If 7+ say “yes, this is a top-3 problem,” there’s something real. If they shrug or struggle to articulate the problem, there isn’t.

2. Did the feature fail because of execution or because the problem doesn’t exist? Execution failure: customers tried it and couldn’t figure it out. Problem failure: customers never tried it because they don’t have this problem.

3. If we rebuild this properly, will it drive retention?
   Look at customers who have this problem versus those who don’t. Is there a retention difference? If no retention signal, the problem isn’t important enough to solve.

4. Do we have capacity to rebuild it in the next two quarters?
   If your pilot team is focused on a different problem, you don’t. Be honest about capacity. Saying “we’ll get to it” is the same as saying “we won’t do it.”

If the answer to all four is yes, commit to rebuilding it properly. Assign it to the pilot team or an expansion team. Measure outcomes.

If the answer to any is no, unship it.

The RFP checkbox reality

You’re right to suspect most low-adoption features were built to check boxes on RFPs. Sales needed them to close deals. You built them. The deals closed. Then customers never used them because they really didn’t need them. They just thought they did.

Those customers would have closed anyway, or they would have churned after six months when they realized the product doesn’t actually work well.

RFP checkboxes are not a moat. Retention is a moat.

Features customers love and use daily are a moat. The checkbox features are costing you retention because they clutter the product and steal time from building things that matter.

When sales pushes back on unshipping, ask them: “What’s the renewal rate for customers who use this feature?” If it’s not higher than baseline, the feature isn’t helping sales. It’s hurting the company.

How to actually unship something

Week 1: Announce deprecation. Email affected customers (the ones with access, not the ones actually using it—there probably aren’t many). “We’re removing [feature] on [date]. Based on usage data, this doesn’t appear to be core to your workflow. If you are using it, please contact us.”

Week 2–3: Talk to anyone who responds. Find out what they’re actually doing. Often they’ll say “oh, we never used that” or “we found a better way.”

Week 4: Remove the feature. Update docs. Ship the change.

Week 5+: Watch for complaints. If usage really was 8%, you’ll hear from 8% of customers. Most will accept an explanation. Some will need a workaround. Almost none will churn over it.

If a customer threatens to churn over a feature with 8% adoption, they were looking for a reason to leave anyway. The product probably has bigger problems.

This is your clean-slate moment

Before you start the pilot, clean house. Unship the junk. Commit to rebuilding what matters. Don’t carry three years of failed features into your craft transformation.

If leadership won’t let you unship anything, you’ve learned something important: they’re not actually committed to change. They want the appearance of craft without the hard decisions.

That’s your signal to either escalate to the CEO or start looking for a company that’s serious.

Next: Part 2 covers how to set up your pilot team, protect them from organizational pressure, align incentives, and navigate the politics to

Run this diagnostic on your B2B company:

□ Product, engineering, and design have separate metrics instead of shared accountability for customer outcomes
□ Product disrupts the roadmap to land deals, regardless of whether customers will actually use the features
□ Engineering is rewarded for hitting dates and velocity, not whether what they shipped works well
□ Design has been beaten into submission to propose “achievable” mediocrity to avoid 18-month estimates
□ Decisions get made in rooms, by committees, where no one understands how all the pieces fit together
□ Teams hand off specs between functions instead of owning problems end-to-end

The more boxes you check, the more your system selects against craftspeople.

What You’re Actually Optimizing For

Product is measured on revenue growth

New customers, expansion revenue, retention numbers. To hit those numbers, they need features that unlock new markets, win competitive deals, and check boxes in sales decks.

This creates pressure to say yes to everything sales needs to close deals. The roadmap becomes a negotiation with the loudest enterprise customer. Product managers optimize for shipping features that make sales decks more competitive, not features that make the product better.

Engineering is measured on hitting dates

Story points completed. Velocity. This creates inflated estimates as self-defense and corners cut to make deadlines. Technical debt compounds while everyone pretends it doesn’t exist.

Design has been beaten down

They propose something thoughtful and get back an 18-month estimate. They learn to self-censor. They start designing mediocre shit that’s “achievable” instead of good.

Nobody is collectively accountable for customer outcomes. Not feature adoption rates. Not time to value. Not customer satisfaction with specific workflows. Not retention tied to product quality.

Product hit their revenue target. Engineering hit their deadline. Design shipped their mocks. The fact that only 8% of customers actually use the feature is nobody’s problem specifically, so it’s nobody’s problem at all.

See if you recognize this cycle: Sales needs feature X to close a big deal. VP of Product needs to hit their revenue target. Sales essentially demands that Feature X goes on the roadmap with a tight deadline. Engineering estimates 6 months. Product says we need something in 6 weeks. Engineering cuts corners to make it happen. The feature ships barely functional. The deal closes. No one uses Feature X. Existing customers complain you still have fixed the last 20 broken features.

That’s because no one is accountable for the fact that the feature doesn’t actually solve the customer’s problem well. Six months later that customer isn’t expanding because the product is frustrating to use. But that’s a retention problem, not a product problem. Different metric. Different quarter. Nobody connects the dots.

This is the machinery. Three groups with misaligned incentives, each optimizing for their own metrics, wondering why the output feels soulless.

The craftspeople you hire see this immediately. They push back. They argue for doing things right. They get labeled “not a team player” or “too perfectionist” or “doesn’t understand the business.” They leave or learn to stop caring.

Your system selected against them. Working as designed.

What This Actually Costs You

You ship features customers asked for that they don’t actually use. Product celebrated closing the deal. Engineering hit the deadline. The feature sits at 8% adoption because it’s too complicated or doesn’t fit the workflow or solves the wrong problem.

Your best people leave. The ones who could build something great go to companies where they’re allowed to. You’re left with people who’ve accepted that mediocrity is the job. They’re not bad people. They’re rational actors responding to your incentive structure.

Your product becomes a commodity. When the software barely works and everyone knows it, you compete on price, complexity, and integrations. Your differentiation is a checkbox on a comparison chart. Your customers stay because switching costs are high, not because they like using your product.

Your technical debt makes everything slower. That 18-month estimate wasn’t crazy. It accounts for the three years of shortcuts that made shipping fast possible. Now simple changes require architectural rewrites. Your velocity drops every quarter while your backlog grows.

What Actually Needs to Change

Align incentives around shared customer outcomes

Product, engineering, and design need collective accountability for metrics like feature adoption rates, time to value, customer satisfaction with specific workflows, and retention tied to product quality.

If product can close deals with features customers don’t use and still hit their OKR, you haven’t fixed anything. If engineering can ship on time with features that don’t work well and still get rewarded, nothing changes. If design can ship pixels that customers hate and still meet expectations, craft is impossible.

Own problems end-to-end

Give teams a customer problem and let them figure out the solution. Not a spec to implement. Not a backlog of tickets. A problem to solve, with authority to make tradeoffs about scope, timeline, and approach.

This requires trust that most orgs don’t have. If you can’t trust a team to make good tradeoffs, you either hired wrong or broke them with your process.

Make someone accountable for customer outcomes

Someone whose job is to look at whether customers actually use what you built, whether they get value quickly, whether they’re satisfied with the experience. Someone who can say no when the feature will close a deal but won’t actually work well.

This person will be extremely unpopular. Protect them or they’ll leave.

Kill the handoffs

If design creates specs that engineering estimates at 18 months, your process is broken. Either designers don’t understand what’s technically feasible or engineers are padding estimates because they don’t trust the requirements.

Get them in the same room earlier. Prototype together. Kill bad ideas in hours instead of months. This requires designers who understand technical constraints and engineers who care about user experience.

Stop measuring velocity

If you’re measuring story points completed, you’re measuring output. Output is not outcomes. You can ship a thousand story points of features nobody uses.

Measure whether customers actually adopted what you built. Measure how quickly they got value from it. Measure whether they’re less frustrated than before. Measure whether retention improved because the product got better, not just because switching is hard.

Why Most Won’t Do This

Changing incentive structures is political

Product VPs need to hit revenue targets. Engineering VPs need to deliver predictably. Design leaders fought for a seat at the table by proving they could keep engineering fed with easily implementable designs.

Telling them their metrics create perverse incentives threatens their positions. They’ll resist. They’ll argue that craft doesn’t scale or customers don’t care about quality or the market moves too fast to sweat details.

They’re protecting the system that rewards them.

Quarterly pressure makes long-term thinking hard

Fixing technical debt doesn’t show up in this quarter’s metrics. Rebuilding a feature properly takes longer than shipping a mediocre version. Your board wants growth now.

The companies that commit to craft accept slower growth upfront for compounding returns later. Most boards won’t tolerate this. Most CEOs can’t sell it.

Hiring for craft is harder than hiring for credentials.

You need people who care deeply about customer outcomes and have the judgment to make good tradeoffs. Interviews don’t reveal this. Trial projects do, but they’re expensive and slow.

Most companies hire for résumés and interview performance. Then wonder why their senior engineers don’t care about whether customers actually use what they built.

The Actual Choice

You can build an organization where craft thrives. It requires structural changes to incentives, hiring, and accountability. It requires collective ownership of customer outcomes across product, engineering, and design. It requires protecting craftspeople from the pressure to ship garbage to close deals. It requires accepting that quality takes longer upfront.

Or you can keep running a feature factory while performing craft. Citing Linear in all-hands meetings. Adopting frameworks that require shared accountability you don’t give people. Hiring talented people into a system designed to frustrate them.

Most companies choose the second option. Not explicitly, but through inaction. The political cost of reorganizing is too high. The quarterly targets are too aggressive. The existing incentive structures are too entrenched.

If you checked multiple boxes on that diagnostic, you probably can’t get there from here. The machinery is working as designed. It just can’t produce software people love.

The companies that actually commit become the products people talk about. They have fans, not just users. They charge more because the difference is obvious. They keep their best people because those people can do their best work.

Everyone else competes on price and prays their switching costs stay high.

You know your incentive structure better than I do. You know whether your system rewards customer outcomes or just output. You know whether you’re willing to change it.

Act accordingly.

Ten years ago, a CPO asked me in an interview: “Are you a zero-to-one person or do you love optimizing and growing existing products?” I told them the truth: I was zero-to-one, I’d never worked on anything that wasn’t a new product at that point. I got the offer, but not for the role I wanted. I was adamant he’d made a mistake. He hadn’t. I would’ve been bored within weeks.

That question saved both of us from an expensive mismatch.

That CPO understood something most leaders miss: product talent isn’t fungible. A brilliant PM in the wrong habitat will struggle, get frustrated, and leave. The problem isn’t capability. It’s fit.

If your VP of Product isn’t working out despite being talented and credible, you’re probably facing the same mismatch. Three months ago they seemed perfect. Now you’re wondering if you made a hiring mistake.

You probably didn’t. You hired someone excellent for a different stage than the one you’re actually in.

Here’s the pattern nobody tells you: Product leadership comes in three distinct types, and each one thrives in a specific growth phase. Shreyas Doshi nailed this taxonomy in 2021, showing that most PM hiring and performance failures come from type mismatch, not capability. Hire the wrong type for your stage, and even brilliant people will struggle. Hire the right type, and suddenly product execution clicks.

The three PM archetypes (and where they thrive)

Kent Beck figured this out at Facebook in 2016. Successful teams weren’t following one methodology; they were shapeshifting by stage. He called it 3X:

• Explore (finding product-market fit)

• Expand (scaling what works)

• Extract (optimizing mature business).

Each PM archetype maps to one of these stages.

The Visionary

Lives for zero-to-one. They’re pattern-spotters who see connections others miss. They thrive in ambiguity and get bored with process. In the Explore phase (when you’re still hunting for product-market fit), they’re gold. In Extract phase, when you need predictable execution across 20 product lines, they’re already mentally checked out.

The Craftsperson

Obsesses over taste, UX systems, and product integrity. They’re perfect for the Expand phase, when you’ve found something real and need to turn a rough prototype into something customers love at scale. They’ll fight for quality when everyone else wants to ship faster. Bad fit for early-stage chaos or big-company politics.

The Operator

Sales through people and systems. They excel at portfolio trade-offs and dependable execution. Essential for Extract phase, when you’re running a mature business with predictable playbooks. Lethal to Explore if they arrive too early. I’ve watched one turn a five-person startup into a thirty-meeting-per-week process nightmare within a month.

How to diagnose your actual stage

Most companies lie to themselves about which stage they’re in. The pitch deck says “scale” but the metrics say “still exploring.” Here’s how to tell:

You’re in Explore if:

- Cohort retention curves look like cliffs after month three

- You’re still debating who your real customer is

- Net Revenue Retention (NRR) is below 100% or you haven’t monetized yet

- Most growth is paid, not organic

You’re in Expand if:

- Retention curves flatten by month 3-4

- NRR is above 110% in your target segment

- The product works but support load is crushing you

- You’re bottlenecked by execution, not customer interest

You’re in Extract if:

- The business is predictable enough to hold you accountable to annual plans

- Gross margins are climbing steadily

- Revenue per employee exceeds $200k

- You’re optimizing more than you’re inventing

The costly transition most teams miss

Half your PMs won’t survive stage transitions. That’s not failure. That’s evolution.

The Visionary who found product-market fit becomes the bottleneck preventing scale. The Operator who brought discipline to chaos will stifle the next 0→1 bet. Plan for this.

Real example: Stripe in 2025 runs core payments in Extract mode (reliability, margins, enterprise features) while exploring agentic commerce with OpenAI in pure Explore mode. Different teams. Different scorecards. Different PM types. Same company. Most organizations can’t hold both ideas at once.

What to do when you have the wrong PM for your stage

If you’re in Explore and your PM wants process:

You need to make a change or carve out a parallel track. Every week in the wrong configuration burns cash and morale.

If you’re in Expand and your PM can’t scale through others:

Coach them hard on delegation and systems-building. If they don’t evolve in 90 days, help them find a role that fits.

If you’re in Extract and your PM is bored:

Create a separate Explore track for new bets, or accept they’ll leave. Forcing a Visionary to optimize spreadsheets ends badly for everyone.

The one question that cuts through confusion

Ask yourself: “What failure mode keeps me up at night?”

- “We’ll never find something people desperately want.” You need a Visionary

- “We’ll collapse under our own growth.” You need a Craftsperson

- “We’ll lose discipline and margin.” You need an Operator

Match the PM type to the fear that’s real. Everything else is noise and will end in tears, yours and theirs.

This Ain’t Easy

Most B2B companies never navigate these transitions cleanly. They burn cash in Explore on a product twelve customers kind-of want. They hit Expand and hire their way to chaos. They reach Extract and “innovate” themselves into margin erosion.

The ones that survive change the people and the philosophy on purpose. Know which stage you’re in, not the one you’re pitching to investors. Hire for where you actually are, not where you wish you were.

When great product people fail, it’s almost never about talent. It’s about habitat. Fix the match, and suddenly everyone looks brilliant again.

“We got it,” she texted.

After weeks of our champion modeling business cases, late-night texts dissecting objections, and that demo that went so well, their CFO almost smiled, we finally received budget approval from one of the largest banks in North America.

I grabbed the champagne we’d been saving, made my way to our VP of Sales’ desk, bottle in hand, grinning like an idiot.

She looked me up and down. “I hope you didn’t open that.”

“But... we got it?” I stammered.

“We got budget approval. Now we have to go through procurement.”

“How long does that…”

“Months. And don’t say shit to the board yet. It ain’t over ‘til the wire hits.”

Deflated, I deleted my draft message to investors and slunk back to my desk.

That “done deal” took eight more months to close, even though we timed it perfectly: a new EVP hire who wanted to drive change, the right budget cycle, and a champion with real power. After demos, due diligence, and internal board approval, we still had:

• Eight months in procurement

• Two rounds of legal reviews (both sides)

• A security audit that restarted everything

• Walking away from the deal twice

• Two bank reorgs

• A new EVP replacing our champion

• A bajillion contract redlines

• One lawyer’s call that lasted four hours

This, my friends, is real enterprise B2B software.

The Unicorn Porn Industrial Complex

Meanwhile, on Twitter/X:

“$2MM in three months used to be impressive. Now we expect it in ten days. Right now, momentum is the only moat.” - Bryan Kim

I can’t get lawyers to review an MSA in ten days.

Sigh, where do I start? This messaging isn’t just annoying, it’s dangerous. Because founders building real enterprise businesses are looking at this shit and thinking they’re failing. It’s like we briefly learned about growth at all costs during the heady ZIRP days, and now we've completely forgotten.

Let’s break down the numbers with the math everyone seems to forget exists.

$54,794.52 MRR × 36.5 = $2,000,000 ARR

Cool. Cool. Cool. Now show me:

• The actual signed contracts

• What happens when those subsidized LLM credits run out

• Month 2 retention

• Month 6 retention

• CAC payback that isn’t fictional

• Whether a single dollar is from a company with a procurement department

I could slap together an AI wrapper, charge $20/month, dump $50/month in free credits into each account, and watch people sign up. It would take me about ten days to hit those numbers, too.

You know what I couldn’t do in ten days? Get legal approval from a single Fortune 500 company.

What Actually Happens in Enterprise

Here’s the timeline nobody tweets about:

Month 1-2: The Honeymoon

• Your champion loves you

• Demos go great

• “This is exactly what we need”

• You start sizing your Series A and worrying about how you’ll manage your overflowing pipeline

Month 3-4: Reality Arrives

• “We need to bring in IT”

• “Security wants to do a review”

• “Can you fill out this 47-page vendor questionnaire?”

• We’ve onboarded you to NetSuite; now you get to re-enter that vendor questionnaire.

• Your champion stops responding as fast

Month 5-6: Procurement Hell

• “We’re mandated to get three quotes”

• RFP goes out (to your competitors)

• Bake-off begins

• The deal you thought was done is now competitive

Month 7-8: Legal Thunderdome

• Your lawyer meets their lawyer

• Liability caps

• Indemnification clauses

• You need to double your insurance, which triples your premiums somehow

• Data processing agreements

• That one sentence that takes four calls to resolve

Month 9-10: The Near-Death Experience

• “The deal is falling apart”

• War room convened

• Your champion’s boss has concerns

• New stakeholder appears who hates everything except your competitor that they once implemented and are connected to on LinkedIn

Month 11-12: False Finishes

• “We’re all set, just needs final signatures”

• Org reorg happens

• “It’s been more than 6 months; we need to redo the pen tests.”

• New stakeholder wants to review everything

• Your champion gets promoted/leaves/reassigned

Month 13-18: Actual Close

• Wire hits

• Now you can open the champagne

• Now you can tell the board, but they’re already focused on the next deals.

This isn’t broken. This is the business model.

The Data Nobody Wants to Hear

Kyle Poyar’s research on growth benchmarks:

• 7.5% of startups hit $1MM ARR in under 2 years

• 3.3% hit it before year one

• The median time to $1MM ARR? 2-3 years. You read that right, two to three years.

But wait, what about all those “overnight successes”? Kyle has the receipts.

Lovable: Eighteen months of development before their breakthrough, following previous unsuccessful attempts (GPT Engineer) that fizzled after launch. The “sudden” success had a year and a half of groundwork.

Clay: Six years of grinding before revenue traction. Six. Years. Most teams and investors would’ve called it quits, but then growth exploded. But nobody tweets about years 1-5. Side note: There are so many Clays, I think I may have used an earlier version, but I’m not sure.

StackBlitz: Seven years clawing to $700K ARR. Then Bolt.new hit $4MM in four weeks. Everyone talks about the four weeks. Nobody mentions the seven years.

And then my favorite, Cursor: the one everyone forgets. Eleven months of private development before their March 2023 launch. Then nine more months to hit $1M ARR. Now everyone screams about their explosive growth from $4M to $50M ARR in 2024. But that’s 20+ months after they started building. With zero marketing spend. And with a product developers literally couldn’t live without once they tried it.

So despite what you’re hearing, the pattern isn’t “build fast, win big.” It’s “build for years in obscurity, then maybe something hits.”

Why “Momentum as Moat” Is Specifically Wrong for Enterprise

Consumer/PLG businesses can move fast because:

• Individual buyers making individual decisions

• Credit card transactions

• No procurement departments

• No legal review

• Can pivot weekly based on usage data

Enterprise businesses cannot move fast because:

• Committee decisions with 8-12 stakeholders

• Six-figure+ contracts requiring CFO approval

• Mandatory procurement processes (seriously, it’s in their policies)

• Legal reviews on both sides

• Security audits

• Integration with systems they literally cannot break

• Reference calls from customers you don’t have yet

You know what the actual moat is in enterprise?

The fact that it takes 8-18 months to close a deal.

Your competitors have to climb the same mountain. Every logo you land is a castle they have to siege. Each implementation becomes integration debt for their competitive displacement.

Fast-follow doesn’t work when the “follow” takes a year and a half.

What This Means If You’re Building Enterprise

If you’re six months in and don’t have $1MM ARR, you’re not behind. You’re on time.

If your deals take 6-18 months to close, that’s not a bug. That’s enterprise.

If you have three pilots and zero revenue, you’re further along than the “10 days to millions” crowd with their phantom churn.

If procurement is killing you: Everyone. Every single company. This is the game, try to see it as a challenge, and remember it’s business, not personal. Well, most of the time.

Could you pivot to SMB? Price at $99/month? Let people swipe cards? Sure. Some companies should. But if you’re building for enterprise buyers, you’re playing a different sport entirely.

The Real Metrics That Matter

Stop comparing yourself to consumer SaaS:

Bad metric: Time to $1MM ARR
Good metric: Contract value + renewal rate

Bad metric: signup velocity
Good metric: Pipeline coverage at 3x quota

Bad metric: Daily active users
Good metric: Successful implementations/champion retention

Bad metric: Viral coefficient
Good metric: Reference customers willing to take calls. Customers who take you with them when they switch jobs.

Your $500K annual contract, which took 14 months to close, is worth more than $2MM in MRR that churns at 15% per month. Because in 12 months, you’ll still have $450K. They’ll have $350K.

Durability beats velocity in enterprise.

What Actually Kills Enterprise Startups

It’s not slow sales cycles.

It’s running out of money before the pipeline converts.

The math is brutal:

• 9-month sales cycle

• Need 3 months to onboard/implement

• First renewal at month 21

• Need 18 months of runway when you start selling

Most enterprise startups die in “the valley of death”, that 12-18 month period where:

• Demos are going great

• Pipeline looks incredible

• The board is asking about revenue

• Your bank account is bleeding out

• Nothing has closed yet

This is why enterprise founders need to:

1. Raise more than feels comfortable (you need longer runway)

2. Start selling earlier than feels ready (add 6 months to your timeline)

3. Have fewer, bigger targets (ten $500K deals > fifty $100K deals)

4. Get comfortable with awkward board meetings (where you explain why nothing closed yet)

5. Find the right investors who get B2B Enterprise, founder-investor fit is a real thing.

The Truth About Enterprise That Nobody Tweets

Real enterprise deals require:

• Vendor insurance certificates

• SOC 2 compliance (Type II, they don’t care about Type I)

• Redlined vendor agreements (every single one)

• Multiple reference calls

• Security questionnaires that take 40 hours to complete

• Proof of financial stability

• Proof of D&O insurance

• Integration with systems deployed in 2008 that nobody understands anymore

Your buyer isn’t being difficult. They’re betting their job on you.

They’re rolling you out to 5,000 users. If your shit breaks, they’re in a conference room explaining why they bought from a startup instead of the incumbent. Their boss is asking why they didn’t go with the “safe choice.” Their career is on the line.

They should move slowly. It’s the rational decision.

So What Do You Do?

If you’re building consumer/PLG, great. Move fast. Tweet your revenue. Optimize for momentum. None of this applies to you.

If you’re building enterprise:

“Don’t believe the hype” - Public Enemy, 1988

Stop reading Twitter unicorn porn threads. They’re not for you.

Stop feeling behind because someone’s MRR × 36.5 math went viral.

Stop apologizing for deals taking “too long.”

Your job isn’t to speedrun it. Your job is to survive it.

Start measuring:

• Contract value

• Pipeline quality

• Champion conviction

• Renewal rates (even from pilots)

• Reference customer strength

Keep the champagne in the office. You’ll need it when the wire hits.

Just don’t open it when you get budget approval, like me, when I was a naïve idiot.

In the mid-90s, I got a rare glimpse inside Apple's Industrial Design Center. I noticed a neat grid of eyeglass cases among the sketches, prototypes, and a few modded RC cars.

Jony Ive, then a young, quiet designer, saw my curiosity and shared his thinking. He was searching for the perfect PowerBook latch, and those cases were his inspiration.

He explained that he sought an analog that felt personal and secure. Critical for doing away with the klunky latch, which was the norm in those days.

Ten minutes later, I left physically unchanged and mentally rewired. I'm sure this was just another conversation with a random visitor for Jony, but it changed everything for me. It opened my eyes to what craft truly means: not surface polish, but the quiet engineering of trust.

That single magnetic click could transform doubt into delight, and users would feel it long before they could articulate why.

Speed is Up, Taste is Down - The Soul to Slop Loop

Fast‑forward to Figma’s Config 2025. Linear CEO and co‑founder Karri Saarinen made an observation that haunted me:

"Technology speeds up creation—but makes it harder to care."

His words transported me back to that encounter with Jony. Throughout my career, I've had the chance to work for teams that care at this level, though perhaps not as eloquently. I've also worked with teams that believe we should ship at all costs, which is wildly depressing for everyone involved.

Saarinen mapped a cycle most of us recognize:

1. Hand‑crafted dawn: small teams sign their work with pride.

2. Mass‑production mindset: dashboards replace judgment; metrics eclipse meaning.

3. Process worship: shipping velocity becomes the north star. "Does this feel right?" gets replaced with "Did we hit the sprint goal?"

4. Reckoning & return: A stubborn minority drags craft back to center stage, or the product slowly fades.

We can see this pattern playing out everywhere. Figma and Notion still operate with founding-team levels of obsession. Meanwhile, products that once delighted us (think Evernote or early Dropbox) fell into the mass-production trap.

Technology accelerates steps 2-3, but can't rescue us from them. Escaping the Soul to Slop loop is a choice, not a feature flag.

The lonely decision of "good enough"

I used to think it was about perfectionism. That old line, “Perfect is the enemy of good," gets tossed around like wisdom, but it’s always rubbed me the wrong way.

Because good, the kind most people settle for, is rarely shared. And someone else’s good usually isn’t good enough.

I found a better answer in an unlikely place (unless you’ve seen my slide decks): music producer Rick Rubin’s philosophy. He puts it perfectly:

“Success occurs in the privacy of the soul… in the moment you decide to release the work, before exposure to a single opinion.”

It’s in that moment, before feedback, before compromise, that craft becomes not just a choice, but an act of conviction. Rubin’s perspective illuminates why quality is profoundly personal and why it's so rare:

Success is self-referenced.

• Your release bar lives inside you; no OKR or A/B test can validate it.

• Holding that bar feels risky in metric-obsessed cultures.

It's a private moment.

• You ship without applause. If the work flops, there's nowhere to hide.

• Vulnerability is the ticket price.

You release only after exhausting the work's potential.

• That "extra five percent" polish rarely fits a sprint plan.

• Teams call it scope creep, unless leadership defends it.

Variables outside yourself are irrelevant.

• Most orgs optimize what they can count.

• Soul‑level satisfaction doesn't fit neatly on a dashboard, so it gets cut first.

Rubin reminds us that craft is emotional labor. You're wagering your reputation on taste, no split test to save you. This is why it feels so risky in today's data-driven culture, yet necessary for enduring products.

Linear's playbook: proving care can scale

Saarinen's company provides a rare blueprint that proves craft can thrive beyond the startup phase. While others talk about quality, Linear builds organizational structures that actively protect it:

• Company-wide quality north‑star. Every touch‑point, from sales email to bug fix, must "feel right," not merely "meet SLA."

• Small, cross‑functional squads. Designers, engineers, and PMs iterate together until the product feels right.

• Scope bends; soul doesn't. They ship internal MVPs, repair every bug inside a week, then unveil work that meets their bar.

• Quality metrics alongside growth metrics. Bug count and time-to-resolution are reported with the same visibility as MRR.

This approach generates concrete business outcomes that should make even the most metrics-obsessed executive take notice:

• Profitability by month 24 (compared to competitors who took 5+ years)

• 10,000+ paying organizations by year 4 with near-zero marketing spend

• Word-of-mouth as primary growth channel (54% of new customers come from referrals)

There's also a powerful halo effect: Linear attracts companies that themselves care deeply about craft. Using Linear signals to both customers and potential employees that your organization values quality. This creates a virtuous cycle where quality-focused talent wants to work with you, further reinforcing your craft-centered culture.

Quality, done deliberately, isn't a luxury tax; it's the cheapest growth lever that sustainably pays dividends.

Three habits that elevate quality

For those ready to bring more intentional craft into their work, here are practices that have served me well across decades of product development:

1. Design for confidence.

Every toggle, loading shimmer, or confirmation copy either earns trust or leaks it. If users hesitate, even subconsciously, you've shipped a bug.

Example: Watch how Stripe handles payment processing. Their success animation doesn't just tell you it worked, it makes you feel it was completed successfully. This isn't decorative; it's functional design that reduces support tickets and increases conversion.

2. Scale taste through culture, not checklists.

• Craft pairing – Have junior team members spend 2 hours weekly watching seniors make micro-decisions

• Create a "taste library" – Identify 5-10 products your team admires and articulate exactly what makes them exceptional

• Ask a standing question – "Would we show this to Jony?" Metrics confirm; they don't substitute for judgment or pride

Example: I’ve introduced a polish phase in a few companies as part of our release cycle. In addition to internal feedback and alpha testing, everyone can make improvements before we ship to users and erode trust.

3. Cut breadth before cutting craft.

Deadlines will squeeze you. Let scope bend, never soul. A small, soulful release beats a sprawling compromise nine sprints out of ten.

Positive example: When GitHub tackled dark mode, they tested hundreds of color combinations over a year rather than rushing out a half-baked implementation. The result delighted users and strengthened their reputation for thoughtful design.

Negative example: Contrast this with Sonos, whose app redesigns have repeatedly prioritized visual refresh over functional excellence. Despite making premium hardware, their buggy, unintuitive software experience has frustrated loyal customers for years, spawning Reddit threads, angry tweets, and even third-party alternatives. The lesson? Hardware excellence can't compensate for software that feels like an afterthought.

A challenge for the next sprint

Jony's attention to eyeglass cases, Rubin's private measure of "enough," and Saarinen's zero bug mandate all point to the same conclusion: craft is personal. It starts when one individual refuses to surrender judgment to the dashboard.

So here's the dare. First, watch Karri’s talk: Crafting creative tools that endure.

Before this week is out, add one thoughtful detail to something you own: a micro‑animation, a reassuring sound, or a line of copy that smiles back. Something specific to your role:

• For designers: Add a micro-animation that confirms user success, perhaps the most extreme example would be the most satisfying checkbox

• For engineers: Reduce the loading time by 500ms in your most frequent user flow

• For product managers: Rewrite confirmation copy to sound human instead of technical

• For founders and C-Level people: Spend 30 minutes using your product with no goal except to feel where it creates doubt, like that password field above

Ship it, watch teammates raise their bar, and see whether you don't feel a little prouder signing the release notes. Caring enough not to cut corners is the rarest moat you can build.

In my last post, "Mastering the Art of Ruthless Focus in Product Strategy”, I wrote about the power of ruthless focus, committing to fewer things and doing them exceptionally well. But here's the catch: focus only helps if you're focused on the right thing.

If your strategic context is outdated or wrong, no amount of sharp execution will save you. You’ll just get to failure faster.

This post is about the other half of product strategy: building and continuously updating your view of the market, your customers, and the shifting ground you’re competing on. That view is your strategic context. And it's what separates companies that adapt from those that stall.

Strategic Context vs. Product Sense

It’s worth clearing up a common confusion: Strategic Context isn’t the same thing as Product Sense. They’re tightly connected and reinforce one another, but operate at different levels.

Product sense is personal. It’s the intuition great product leaders develop through direct experience, an internal compass for what customers want and what feels right.

Strategic context is shared. It’s the external map: a collective understanding of your market, competitors, customer segments, and broader trends. It’s documented, deliberate, and distributed across the leadership team.

Strategic context enhances product sense: When product managers understand the broader market, customer segments, and competitive landscape, they make sharper, more relevant product decisions.

Product sense informs strategic context: Insightful product managers often surface patterns, shifts, or customer truths that hadn’t yet been codified into the company’s broader strategic view.

Product sense helps you notice what others miss. Strategic context helps you align those insights with where the business is headed. The best teams build a feedback loop between the two, turning instinct into strategy, and strategy into sharper instinct.

Why Strategic Context Is Your Real Moat

Strategy isn't a one-time plan. It's an ongoing interpretation of reality. When companies stop actively revisiting that reality, they don't just fall behind—they start optimizing a map that no longer matches the terrain.

Your strategic context is how you stay oriented. It tells you:

• Who you're really building for, and who you're not

• What problems are actually urgent to your customers right now

• Where your differentiation is growing, or eroding

• What bets competitors are placing, and which ones are working

And crucially, it helps you catch signals early enough to shift before the market forces your hand. If you're not already doing this systematically, don’t worry. This post gives you the framework and cadence to build that muscle.

Ask Yourself These 3 Questions First

1. Could everyone in the company consistently and confidently name the top three customer problems you solve?

2. Have you made explicit decisions about which segments you do not serve well?

3. Do you update your market understanding on a regular cadence, and share those insights beyond the product team?

If the answer to any of these is "no," your strategy is likely grounded more in old assumptions than current truth.

From Gut Feel to Ground Truth: Systems That Keep Your Strategy Honest

These practices help high-performing teams build and maintain a living view of their market.

1. Market Mapping

Tracks

Competitive landscape and customer value perception

Why

Most teams do a competitive analysis once and never touch it again. The best teams build a living market map that evolves as conditions change.

How

• Hold quarterly market mapping sessions with product, sales, and exec leaders

• Map competitors on the dimensions customers actually care about (speed, support, integrations, etc.)

• Track shifts in perception and performance over time

2. Customer Insight Infrastructure

Tracks

Customer priorities, decision drivers, and pain point hierarchy

Why

Strategic context without fresh customer input is just confident guessing.

How

• Run ongoing Jobs-to-be-Done switch interviews to understand why customers change tools

• Use Customer Problem Stack Ranking (CPSR) to see where your product sits in the hierarchy of customer pain

• Capture and centralize signals from support, sales, churn interviews, and usage data

3. Market Sensing

Tracks

Emerging trends, weak signals, and early market shifts

Why

The best teams notice weak signals before they become loud ones.

How

• Assign internal "market sensors": people who track competitors, customers, or tech trends

• Run monthly pattern recognition sessions where teams share what they’re seeing

• Build a lightweight leading indicators dashboard (new competitors, trend inflections, etc.)

4. Red Teaming Your Strategy

Tracks

Strategic blind spots and unchallenged assumptions

Why

Every strategy has blind spots. The longer you look at your own, the less you see them.

How

• Run regular pre-mortems: "If this strategy failed, what happened?”

• Assign a rotating team to challenge your assumptions with outside-in perspectives

• Invite non-obvious voices (sales reps, customer success, analysts) to poke holes

5. Cadence: Make It a Habit

Strategic context isn't something you do once a year. Here's how to make it part of your operating rhythm:

• Monthly: market sensing session

• Quarterly: Deep-dive strategy reviews, assumption updates, context dissemination

• Annually: Reset foundational beliefs based on structural shifts

Making Strategic Context Actionable

A great market map doesn't help if nobody looks at it when making roadmap decisions. Here's how to embed strategic context into your workflows:

1. Connect It to Decisions

• Require strategic context checks in product reviews

• Include context alignment in roadmap prioritization docs

2. Communicate It Well

• Share aha moments and resonating clips from interviews as they happen.

• Send a monthly "What's Changing" digest to the whole company

• Share market shifts and key learnings in the company, All Hands

• Use “"context card" to summarize key insights during planning

3. Build a Shared Repository

• Create a simple, timestamped wiki for customer, market, and tech context

• Note confidence levels “High conviction” vs “Emerging signal”)

• Track how insights evolve over time

Your Strategic Context Starter Plan

One of the most powerful uses of strategic context is to surface and derisk your highest-risk assumptions early, before they become expensive missteps. Inspired by the work of David J. Bland and others in the lean experimentation community, this means mapping your assumptions and testing them deliberately, not treating them as facts.

Start by identifying which beliefs underpin your current strategy. Then ask: what would need to be true for this to work? What are we least sure about? What could kill the strategy if we're wrong? Prioritize your riskiest assumptions and find fast, lightweight ways to test them.

Now, here's how to get started in the next 30 days:

Week 1

• Run a 1-hour workshop: “What do we believe about our market today?"

• Inventory existing insights (research, interviews, sales intel, churn data)

• Identify the biggest gaps and most questionable assumptions

Week 2–4

• Run 5–10 customer switch interviews (for reference: watch Bob Moesta and Chris Spiek teach you the theory behind switch interviews, skip ahead to 18:40 to see an example if you don't want the theory)

• Assign market sensing owners for competition and customer segments

• Stand up a simple market wiki and start logging changes

End of Month

• Share the top 5 updated assumptions with the exec team

• Add a strategic context section to the next roadmap review

• Schedule your first quarterly strategy deep dive

Final Thought: Strategy Is a Living System

The companies that thrive regardless of the market's twists and turns aren't just focused. They're focused on the right thing and stress-test their assumptions constantly.

They don't treat beliefs about customers or markets as facts. They map them, rank their risk, and deliberately try to break them before reality does.

That discipline of derisking your riskiest assumptions early keeps strategy grounded in truth, not optimism.

Strategic context isn’t a one-and-done document. It's a system for learning, adjusting, and staying aligned with a reality that doesn't sit still.

In my next post, I'll dive into Finding Big Bets, including practical exercises to identify which objectives matter most and how to test them before you commit. It's where strategy meets execution, and where risk becomes insight.

Until then, check your assumptions and make sure your strategy is still pointed at reality.

If you're a product leader at a Series A B2B SaaS company, you might already be juggling pre-acquisition tasks. The 2023 Challenges in Product Management Survey found that 32.4% of product leaders are diving into these activities, especially at companies in hot vertical markets. That’s a lot of you! So, how do you craft a product strategy that nails your current goals and makes your company a shiny target for acquisition? Spoiler: You don’t have to choose. The same strategy that fuels sustainable growth also makes you attractive to buyers.

The 2025 SaaS M&A report from SEG shows that companies commanding premium valuation multiples excel in metrics like Net Revenue Retention (NRR), Annual Recurring Revenue (ARR) growth, and solid unit economics. Now the bad news: exceptional performance across key metrics isn’t something you can achieve with some last-minute polish, but it’s definitely something an effective product strategy can drive. This guide is your playbook for building an acquisition-ready strategy that adds value now, whether you exit tomorrow or years from now.

A great product strategy holds immense value, but considering tech and talent hurdles, post-acquisition integration can hinder progress. High M&A failure rates indicate a gap between identifying product synergies and effectively realizing them.

Why SaaS Acquisitions Succeed (or Crash)

Acquisitions can go south fast. Here’s why they fail:

• Integration headaches: Merging cultures and tech stacks, especially with cloud architectures and remote teams, is complex at best.

• Customer churn: Churn can spike if customers perceive the acquisition as negative or experience service disruptions.

• Product overlap: Duplicate features lead to internal battles and wasted effort.

• Overhyped ‘synergies’: Buyers often overestimate cross-sell potential or underestimate integration costs or feasibility.

Key Success Factors for SaaS Acquisitions

But when acquisitions work, it’s because of:

• A clear reason, like entering new markets, acquiring tech/talent, or boosting market share.

• Strong product-market fit and customer loyalty.

• Effective integration planning and execution.

• Retention of key talent and leadership from the acquired company.

Knowing these factors helps you prep like a pro, reducing risks and highlighting what makes your company a winner.

Understanding the Acquirer's Perspective

What Acquirers Look For in Product Strategy Due Diligence

M&A due diligence isn't just about spreadsheets anymore. Buyers dig deep into your product strategy. Here's what they're really checking out:

1. Is Your Revenue Actually Good? And Growing?

   • ARR growth (30%+ gets them excited).

   • NRR above 100% (120 %+ is a valuation booster).

   • Low churn and sticky products.

   • Customer concentration (too much reliance on a few big clients raises red flags).

2. Are You Actually Making Money?

   • Gross margins (80 %+ is the SaaS sweet spot).

   • Rule of 40 (growth + profit margin > 40%).

   • LTV ratio (3:1 or higher indicates profitable customer acquisition).

   • CAC payback (less than 12 months is a win, but less is more).

   • SaaS Magic Number (how efficiently you spend to grow).

3. What Makes Your Product Special?

   • Unique tech or IP that stands out.

   • Leadership in your niche.

   • A big, growing total addressable market (TAM).

   • Competitive positioning and barriers to entry.

4. Is Your Tech Any Good?

   • Scalability of cloud infrastructure.

   • Security posture and compliance.

   • Tech debt assessment.

   • Robust API and integration capabilities.

A messy tech stack or heavy technical debt can tank synergies, jack up integration costs, and scare buyers off. A modern, scalable, well-documented tech stack significantly facilitates integration and contributes positively to valuation

Common Red Flags That Devalue Companies

You should be aware of issues that consistently raise concerns during acquisition due diligence:

1. Technical Debt Accumulation

   • Unmaintained legacy code

   • Poor documentation

   • Security vulnerabilities

   • Scaling limitations

2. Product-Market Fit Concerns

   • High customer churn indicating product or market issues

   • Low NRR, below 100%, suggests limited expansion potential

   • Uneven customer satisfaction scores across segments

3. Integration Challenges

   • Monolithic architecture resistant to modular integration

   • Custom technology stacks with limited compatibility

   • Data models that resist migration or normalization

   • Limited API capabilities

4. Team Dependencies

   • Knowledge concentration in a few key employees

   • Undocumented product decision processes

   • Lack of systematic product development methodology

Deal-Enhancing Elements in Product Strategy

Research identifies several product strategy elements that consistently drive premium valuations:

1. Vertical Market Leadership

   • Specialized solutions for specific industries command higher multiples due to deeper customer relationships and typically lower churn

   • Domain expertise embedded in the product creates defensible advantages

2. Platform and Ecosystem Strategies

   • Products with platform characteristics benefit from network effects

   • Strong API strategies and third-party integrations increase stickiness

   • Established developer ecosystems create additional value barriers

3. Scalable, Cloud-Native Architecture

   • Modern cloud infrastructure signals easier scaling and integration

   • Microservices architectures offer more flexible integration options

   • Containerization and infrastructure-as-code approaches streamline operations

4. Data and AI Capabilities

   • Unique data assets with demonstrable value

   • AI/ML capabilities embedded in core product functions

   • Analytics capabilities that drive customer value

Optimizing Your Product Strategy for Maximum Value

Strategic Technical Debt Management

Technical debt is inevitable in fast-moving startups, but successful acquisition targets manage it strategically:

1. Debt Inventory and Classification

   • Document and categorize technical debt by impact and resolution effort

   • Distinguish between "drag" debt (slowing development) and "risk" debt (creating vulnerabilities)

   • Quantify carrying costs in engineering time and opportunity cost

2. Prioritization Framework for Technical Debt

   • High Priority: Security vulnerabilities, scaling limitations, integration blockers

   • Medium Priority: Performance issues, reliability concerns, developer experience frictions

   • Lower Priority: Code cleanliness, minor architectural inefficiencies

3. Transparent Debt Management Process

   • Allocate consistent sprint capacity to debt reduction (15-20% is standard)

   • Document debt reduction in engineering and product artifacts

   • Create visible metrics tracking debt reduction over time

4. Acquirer-Ready Technical Documentation

   • Maintain architecture diagrams that illustrate system components and interactions

   • Document the API surface area thoroughly with usage examples

   • Create integration guides that demonstrate extensibility

Showcasing Product Differentiation

Product differentiation directly impacts valuation multiples. Research shows that differentiators should be:

1. Quantifiable in Business Impact

   • Document specific customer outcomes with metrics

   • Demonstrate ROI through case studies and success stories

   • Connect features to concrete business value

2. Defensible Against Competition

   • Identify capabilities not easily replicated by competitors

   • Document intellectual property and proprietary approaches

   • Show sustainable advantages in customer acquisition or retention

3. Aligned with Acquirer's Strategic Interests

   • Map differentiation to potential acquirer needs

   • Identify capabilities that align with the acquirer’s existing product portfolio

   • Demonstrate synergy potential through complementary strengths

4. Validated Through SaaS Metrics

   • Connect differentiation to observable metrics like NRR, conversion rates

   • Highlight pricing power through the sustainability of gross margins

   • Illustrate scaling efficiency through improving unit economics

Demonstrating Scalable Architecture

Acquirers pay premiums for products built to scale efficiently:

1. Performance Scalability

   • Document performance testing methodologies and results

   • Showcase linear cost scaling with customer/user growth

   • Highlight architectural decisions that enable scaling

2. Operational Scalability

   • Demonstrate automated deployment and testing procedures

   • Document incident response and reliability engineering practices

   • Show efficient use of cloud resources and optimization strategies

3. Team Scalability

   • Highlight your modular codebase that supports parallel teamwork

   • Showcase engineering onboarding processes and documentation

   • Demonstrate knowledge distribution across the team

4. Geographic and Compliance Scalability

   • Highlight multi-region capabilities

   • Document compliance frameworks and certifications

   • Show internationalization and localization readiness

Communication Frameworks for Pre-Acquisition Phases

Stakeholder Communication Within NDA Constraints

At some point, you’ll be under a strict NDA that will prevent you from speaking as candidly as you normally will outside of the board and a small internal group. If your default is transparency, this puts you in a difficult position. It can feel a little dirty, but navigating pre-acquisition discussions requires balancing transparency with confidentiality:

1. Investor Communications

   • Focus on strategic rationale rather than specific acquirers

   • Emphasize value creation potential rather than exit timing

   • Frame discussions around market consolidation trends

   Example: "Our Q3 roadmap prioritizes integration capabilities and vertical market expansion, positioning us advantageously in our space as the industry consolidation trend continues."
   

2. Customer Communications

   • Maintain continuity messaging around the product roadmap

   • Emphasize long-term vision and commitment

   • Address concerns proactively if rumors emerge

   Example: "We remain committed to our product vision and roadmap. The investments we're making in our platform architecture ensure we can continue to serve your needs regardless of how our company evolves."
   

3. Team Communications

   • Maintain consistent focus on the company's mission and goals

   • Connect organizational changes to business strategy rather than exit preparation

   • Emphasize professional growth opportunities in all scenarios

   "Our increased focus on documentation and knowledge sharing strengthens our engineering practices and creates growth opportunities for everyone, while ensuring we build a resilient organization."

Roadmap Communication Template

At some point, you’ll need to introduce roadmap changes related to the acquisition process. This template maintains confidentiality when communicating those changes.:

ROADMAP UPDATE: [Initiative Name]

BUSINESS DRIVER: [Customer problem/opportunity being addressed]

VALUE DELIVERED:
- For customers: [Specific customer outcomes]
- For our business: [How this advances strategic goals]

KEY TIMELINE CHANGES:
- [Feature/initiative] moved forward to [date]
- [Feature/initiative] rescheduled to [date]

RATIONALE:
[Business-focused explanation connecting to stated company objectives]

IMPACT ON COMMITMENTS:
[How this affects (or doesn't affect) existing customer commitments]

Planning for Joint Roadmap Scenarios

Preparing for Acquisition Discussions

In advanced acquisition stages, joint roadmap planning becomes critical. This is your opportunity to get ahead and actively influence the post-acquisition roadmap, as well as your chance to demonstrate value to the acquirer:

1. Current Roadmap Documentation

   • Organize roadmap into strategic themes rather than outcomes (and never feature lists)

   • Document clear business rationale for major initiatives

   • Classify initiatives by strategic impact vs. implementation complexity

2. Synergy Preparation Materials

   • Identify obvious integration points with likely acquirers

   • Document API capabilities and integration frameworks

   • Prepare "what-if" scenarios for different combination possibilities

3. Value Capture Modeling

   • Create templates for modeling cross-sell/up-sell opportunities

   • Identify cost synergies in infrastructure and operations

   • Quantify potential market expansion through combined capabilities

4. Sequencing Recommendations

   • Develop recommendations for integration sequencing

   • Identify quick wins vs. longer-term integration projects

   • Document dependencies and critical path considerations

Your Last Independent Roadmap: Making it Count

As acquisition discussions intensify, product leaders confront the harsh reality of crafting their last independent roadmap. Post-acquisition, focus shifts to integration, CapEx reduction, and aligning with the acquirer's KPIs. This makes your pre-acquisition roadmap critically important, and it's your last chance to set direction on your terms.

Deep-Dive: Roadmap Triage Mechanics & Rationale

Earlier, we talked about strategic roadmap considerations. Now, let’s dive into a more detailed scoring model that you can use on your board. This model can be implemented in a Jira/Linear field or spreadsheet to prioritize your final independent roadmap easily.

How to use this framework:

1. Calculate Total Score = Σ(Weight × Dimension Score) for each initiative

2. Rank epics by score and draw a cut-line at available capacity

3. Publish the sortable list internally with dollar values abstracted if the sale process is stealthy

4. Re-score monthly as diligence questions and buyer feedback change weights fast

Adapting This Framework for Confidential Acquisition Scenarios

When acquisition discussions are confidential but you need to use this framework with your broader team, create a "public version" with these adaptations:

When presenting the prioritized roadmap internally, you can:

1. Use only the "public version" terminology in all communications

2. Omit any acquisition-specific rationales from documentation

3. Frame all prioritization discussions around building a stronger, more valuable independent company

4. Keep the detailed scoring spreadsheet confidential to the executive team

This approach allows you to apply the same prioritization framework while maintaining confidentiality around potential acquisition discussions.

"Kill List" Decision Framework

Not all initiatives deserve to survive in an acquisition context. Use these criteria to identify initiatives that should be stopped:

• Total Score < 60% of cut-line this initiative is of low value in your new reality

• Synergy Score ≤ 2, there’s minimal acquirer benefit

• Launch date beyond likely close date, this initiative won't impact the deal

When publishing the Kill List internally, frame each decision through customer-value reasons rather than financial jargon to maintain team morale and focus.

Semi-Reasonable Implementation Timeline

Implementing your acquisition-ready roadmap prioritization requires a structured approach with clear ownership and timelines. Execution excellence signals potential acquirers that your team can deliver consistently, impacting valuation discussions.

This 12-week timeline balances immediate action with sustainable rhythm, maintaining business momentum while reorienting your roadmap to high-value initiatives that strengthen standalone operations and potential acquisition outcomes.

This cadence ensures effective governance while accommodating evolving acquisition discussions and market shifts. Consistent execution is key. Show potential acquirers that your team can systematically implement strategic priorities, as this is a valuable asset post-acquisition.

Addressing Team Anxiety When the Sale Is Still a Secret

Teams can sense acquisition prep. Ideally you can read-in your team but the risk of leaks go up with every person that is aware of conversations. If you can’t be transparent, here’s how to respond to common team concerns:

Sudden project kills → "Are we being prepped for sale?"
Announce project cuts as part of a refinement of your product strategy and tighter focus. Every cancelled feature frees capacity for reliability, scalability, or a top customer pain. Publish a 2-sentence rationale the day the cut lands.

Stability & cost focus → "Vision is dying"
Brand CapEx-friendly work as a Reliability Sprint, framed as prepping for 10× workload and up-market growth.

Documentation Sprints → "Audit prep?"
Bundle under an Engineering Excellence OKR (test coverage, performance budgets, SOC2). It reads as résumé builders, not exit chores.

Leadership Absence
Explain time blocks as strategic partnership or fundraising meetings, which are both NDA-safe.

Fear of losing innovation
Hard-allocate 15–20 % of every sprint to an Innovation Sandbox chosen by squads. Creativity gets an explicit runway even as priorities tighten.

Maintaining team motivation during this period is critical. The talent the acquirer is paying for must remain engaged through closing and beyond.

Contingency Planning for Different Acquisition Scenarios

Scenario Planning Matrix

Not all acquisitions end with you being assimilated by the acquirer. Different scenarios require different product strategy adaptations:

For each scenario, consider these specific roadmap adaptations:

1. Full Integration Scenario

   • Prioritize standardizing on the acquirer's technology patterns where feasible. A common one here is you’re using something like Amazon’s Cognito, and your acquirer hosts everything on GCP.

   • Explore customer data migration capabilities and tools

   • Identify and document product capabilities for potential preservation

2. Stand-alone Subsidiary Scenario

   • Develop integration points for cross-selling between product lines

   • Create shared authentication and user management capabilities

   • Maintain independent innovation capacity in core areas

3. Partial Technology Acquisition Scenario

   • Increase modularity of desired components

   • Develop clean APIs between components likely to be separated

   • Create transition documentation and knowledge transfer materials

Demonstrating Value Through SaaS Metrics

Valuation multiples are increasingly tied to KPIs rather than solely to growth potential. A strategic presentation of key metrics can significantly enhance acquisition premiums and overall company valuation. Well-documented and clearly presented metrics serve as compelling evidence of sustainable business value, allowing you to communicate your value effectively during due diligence and maximize your company’s perceived worth to potential acquirers and investors.

Key Metrics That Drive Acquisition Premiums

These metrics most directly impact valuation multiples:

1. Net Revenue Retention (NRR)

   • Target: >100% essential, >120% for premium multiples

   • Documentation: Cohort analysis showing consistent expansion

   • What it shows: Product delivers ongoing value driving expansion

2. Rule of 40 Performance

   • Target: Growth Rate + Profit Margin > 40%

   • Documentation: Trending improvement over time

   • What it shows: Business balances growth with operational efficiency

3. LTV Ratio

   • Target: >3:1 for healthy acquisition economics

   • Documentation: Calculation methodology and cohort analysis

   • What it shows: Customer acquisition approach is sustainable and profitable

4. Gross Margin

   • Target: >80% for SaaS businesses

   • Documentation: Componentized margin analysis

   • What it shows: Product can scale efficiently without proportional cost growth

Packaging SaaS Metrics for Acquisition Discussions

Effective metrics presentation significantly impacts perceived value:

1. Metrics Dashboard Structure

   • Organize metrics hierarchically (top-line business health to component metrics)

   • Show trending over 4-8 quarters to demonstrate momentum

   • Include a comparison to relevant benchmarks for context

2. Segmentation and Granularity

   • Break metrics down by customer segment/size

   • Show performance by acquisition channel

   • Demonstrate performance across product modules/capabilities

3. Narrative Connection to Product Strategy

   • Connect metric improvements to specific product initiatives

   • Document cause-and-effect relationships in product changes

   • Create forward-looking projections based on roadmap execution

Additional Frameworks for Acquisition-Ready Product Leaders

The Pre-Diligence Readiness Framework

Before formal diligence begins, use this framework to assess and improve your readiness:

Assign an internal owner to each area and rate your readiness from 1-5. Focus remediation efforts on your weakest areas first.

The Integration Assumptions Matrix

This framework helps identify assumptions about post-acquisition integration that should be validated before they become problems:

Document these assumptions early and seek to validate them through informal conversations before they become binding commitments.

The Data Room Preparation Matrix

Ugh, maintaining a data room is a real grind. You can set yourself up from the start by organizing your product documentation for the data room using this framework:

Prepare executive summaries (2-3 pages) and comprehensive documentation for each category, arranged in a consistent structure.

The Value Acceleration Framework

Use this framework to identify how an acquisition could accelerate value creation for both parties:

Quantify the potential value creation in each area and prioritize integration activities that unlock the greatest combined value.

The Reverse Due Diligence Framework

While acquirers perform due diligence on you, this framework helps you evaluate whether they're the right fit:

Use this framework for early private assessment and structured conversations when appropriate.

Conclusion: Building Lasting Value

The most successful acquisition-ready product strategies create value regardless of exit timing. By following the frameworks outlined in this guide, Series A product leaders can build organizations that thrive independently while positioning favorably for potential acquisition.

Remember these critical principles:

1. Value creation starts with customer outcomes - Metrics that drive premium valuations all trace back to delivering exceptional customer value.

2. Technical excellence pays dividends - Clean architecture, manageable technical debt, and scalable infrastructure create value in all scenarios.

3. Transparency builds trust - Honest communication within appropriate constraints builds the foundation for successful transitions.

4. Differentiation drives premiums - Clear, defensible product differentiation remains the core driver of acquisition interest and valuation.

5. Metrics tell your story - Rigorous tracking and presentation of SaaS metrics translate product strategy success into valuation discussions.

By building your product strategy with these principles in mind, you create a win-win scenario: a stronger standalone business that simultaneously commands premium acquisition interest when the time is right.

Acquisition Readiness Checklist

☐ Document technical debt inventory with remediation roadmap
☐ Create architecture diagrams showing system components and interactions
☐ Develop API documentation and integration guides
☐ Establish metric tracking for NRR, Rule of 40, LTV, and other key indicators
☐ Document product differentiation with customer evidence
☐ Create roadmap themes showing strategic direction beyond features
☐ Implement a weighted scoring model for roadmap prioritization
☐ Establish an innovation program with dedicated capacity
☐ Create contingency plans for different acquisition scenarios
☐ Prepare synergy models showing cross-sell/integration potential
☐ Complete Pre-Diligence Readiness assessment
☐ Document Integration Assumptions Matrix
☐ Organize documentation using Data Room Preparation Matrix
☐ Analyze potential value acceleration opportunities
☐ Develop criteria for reverse due diligence on potential acquirers

Why is Strategy So Damn Hard (and Misunderstood)

Product strategy exists in a paradoxical space: everyone agrees it’s essential, yet few organizations do it well. Why? Because genuine strategy demands conviction and the (often political) willingness to say “no” to many appealing ideas. This goes against a very human impulse: we want to keep our options open. We assume more optionality means less risk, but ironically, it can prevent us from committing to the few high-impact bets that produce true strategic differentiation.

As Steve Jobs famously noted:

“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundreds of other good ideas that exist. You have to pick carefully.”

In B2B SaaS, this “pick carefully” mindset can be tough to maintain. Power users demand expansions into adjacent product areas; large enterprise customers threaten to churn if you don’t build certain features. The temptation to say “yes” to everyone is strong. Yet failing to say “no” often dilutes your product offering into a weird state where the total is less than the sum of the disjointed parts, which serves no one especially well.

Strategy Ain’t a Buzzword Bingo Card

Let’s be clear about what product strategy is not:

• A jargon-packed PowerPoint that lulls everyone to sleep

• An endless laundry list of features or pet projects

• Some magic quadrant or fill-in-the-blank template

• A shortcut that skips the hard work of knowing your customers and market cold

A good Strategy, as Richard Rumelt defines it:

“Good strategy works by focusing energy and resources on one, or a very few, pivotal objectives whose accomplishment will lead to a cascade of favorable outcomes.”

That’s the secret: find the 2-3 bets to win your chosen market.

The Strategic Hierarchy

Think of product strategy as the connective tissue in this lineup:

Company Vision → Product Vision → Product Strategy → Roadmap

Company Vision defines the overarching destination for the business, and the Product Vision paints how your offering will support that bigger mission. Product Strategy is the bridge that translates vision into concrete strategic decisions, turning lofty goals into near-term priorities and a decision framework that shapes the Roadmap and ongoing execution.

Product Strategy is where ideas converge with the gritty reality of execution.

Humans Love Options, But Strategy Means Saying “No”

Product teams often shy away from hard strategic choices because of the deep-seated fear that rejecting any opportunity might mean losing future revenue or alienating a potential big customer or key internal stakeholder. We’re wired to keep as many doors open as possible. This plays out in three ways:

1. Fear of Missing Out on Revenue

   • B2B teams especially worry about leaving money on the table. Shouldn't we jump on that expansion if a power user wants an adjacent feature?

   • However, a good strategy recognizes that near-term revenue isn’t worth derailing your long-term product vision or maxing out the engineering team on whack-a-mole, one-off requests.

2. Aversion to Conflict

   • Telling any stakeholder “no” can feel risky. You might fear losing a champion inside a key account or rankling your internal teams who love new ideas. Or worse, it’s an idea based on a HIPPO, and they’re very much in love with it.

   • Without internal conviction, “yes” becomes the default. A swirl of half-priorities accumulates, draining time and clarity and almost certainly removing any hope of long-term success.

3. Lack of Conviction in the Core Bet

   • Often, we cling to optionality because we’re not 100% sure our chosen direction will succeed. The more directions we hedge in, the safer we feel.

   • Ironically, this hedging often means we never gain the momentum needed for the core product strategy to prove itself truly.

Real product strategy accepts that you can’t please everyone, and in doing so, you end up creating more value for the customers you choose to serve best.

A Real B2B Example: When Power Users Want It All

Picture this: your most vocal customers, your power users, are obsessed with your product. They’re solving their core problems as they had hoped when they bought your solution, but now they see new ones they want you to fix. In a previous life, I lived this where our most engaged customers begged us to build a new feature set to replace their clunky Excel workflows. They wanted us to be their one-stop shop, which made a lot of sense. These power users were doing a lot of duplicative data entry, and the system would have been stronger if we had expanded the feature set.

Tempting, right? But our strategy was laser-focused on moving upmarket to land bigger enterprise fish. That meant prioritizing seemingly mundane table stakes like granular permissions, two-factor authentication, and compliance features that’d make economic buyers, not the end users, sign on the dotted line.

Because we’d nailed our strategy down, the choice was clear. We doubled down on enterprise readiness over chasing quicker wins with our power users. That discipline opened doors to a massive market segment previously out of reach, proving that saying “no” can unlock bigger “yeses.”

The Seven Pillars of a Strategy That Doesn’t Suck

1. Start with Clarity
   Before you scribble a single strategic note, get crystal clear on:

   • Company Vision: Where is your organization heading?

   • Corporate Goals: What are the broader business goals?

   • Product Vision: What’s the dream state for your product, and how does it fit into the bigger picture?

   
   Without clarity on these foundational elements, you can’t commit to a path with conviction. And if your strategy doesn’t ladder up to these, it’s just noise. Can your team explain how their daily grind ties to the big picture? That’s the gut check.
   

2. Analyze Your Context Thoroughly
   Strategy isn’t born in a boardroom brainstorm. Effective product strategy requires an ongoing feedback loop:

   • Quantitative Insights: Usage spikes, feature adoption, churn risks, engagement trends

   • Qualitative Insights: Pain points, wishes, unfiltered feedback

   • Pipeline Reality: What’s already on your plate

   • Market Pulse: Competitor moves, buyer behavior, regulatory shifts

   • Big Trends: Technolgy leaps, macro trends, emerging markets

   
   In B2B, don’t forget users (who love your product) and economic decision-makers (who hold the purse strings) rarely want the same thing. Balancing these perspectives is crucial so you don’t chase the wrong signals.
   

3. Pick Your 2-3 Big Bets
   Strategy boils down to picking just a few big bets that can reshape your company's trajectory. The natural human tendency is to pick more and keep flexible. But if everything is important, nothing truly is.

   • What wins would reshape our market position or business model?

   • What moves unlock multiple downstream benefits or expand our SAM or TAM?

   • What blind spots could sink us if we ignore them?

   
   This will feel hard because it is hard. Pro tip: If you’ve got more than three “priorities,” you’re doing it wrong. Proper focus means betting big and owning the risk.
   

4. Own Your Trade-offs
   Humans crave optionality, but strategy’s power comes from what you don’t do. Spell it out:

   • Which segments are you not serving? Note: this may be temporary and can be reassessed along your Product Vision journey.

   • Which features will you not build right now—even if some customers request them?

   • Which “good ideas” are you parking for later?

   
   In my story, we passed on power-user features to chase enterprise credibility. Making that call explicit kept everyone aligned and (mostly) drama-free.
   

5. Manage your Assumptions (AKA Risks) as a Roadmap
   Every strategy rides on assumptions—market trends, user behavior, tech feasibility. Don’t let them fester. If you don’t track these assumptions, you may cling to them to justify “keeping more options alive.”
   
   Instead:

   • List and prioritize every assumption behind your plan. Which are the highest risk? Prove or disprove them first.

   • Test them relentlessly with discovery. Talk to customers, run quick experiments, or do pre-mortems.

   • Rank them by risk and tackle the scariest first. If getting an assumption wrong could kill you, you must validate that first. Right now, why are you still reading?

   • Failure is an option and should be celebrated. If your test proves an assumption incorrect, this is a huge win. You just avoided wasting a ton of time and money chasing the wrong thing.

   • With new data, refine and continuously reevaluate your strategic bets.
     

   Think of assumptions as a backlog you’re constantly pruning. That discipline turns guesswork into progress. Grounding your plan in validated assumptions builds enough confidence to say “no” to secondary opportunities that distract from achieving your Product Vision.
   

6. Differentiate or Die
   If your so-called differentiators are generic enough that competitors could (honestly) claim the same, it’s not a differentiator. Many B2B companies fill pitch decks with useless terms like “seamless, real-time, AI-driven.”
   
   In B2B, differentiation means one thing: making or saving your customers serious money. Ask:

   • Can a competitor say the same thing? If yes, it’s not unique.

   • Does your edge matter to the person signing the check? Tie every alleged differentiator to a measurable value driver: Does it help your customers make more money or save more money?

   • Differentiation is hard, and it will likely take several iterations to articulate true differentiation that resonates with your customers.

   
   There are a lot of commodity B2B products out there. Brutal honesty here separates the winners from the also-rans.
   

7. Embrace Continuous Discovery
   Product strategy isn’t a static document; it’s an ongoing conversation fueled by new data, usage patterns, and market signals. A willingness to adapt means you might pivot earlier and more gracefully if a bet doesn’t pan out or new opportunities arise. But continuous discovery shouldn’t devolve into a frantic chase for new features; it’s about routinely validating or challenging your 2–3 central bets.

   
   B2B’s long sales cycles can hide warning signs. A discovery mindset keeps you ahead of the curve, not stuck building yesterday’s dream.

Strategy Traps to Avoid

Even the sharpest teams stumble. Watch out for:

• The Kitchen Sink Strategy: Trying to do it all to keep every door open while trying to please everyone (spoiler: you won’t).

• Features-First Approach: Listing out features without explaining why they matter. Or worse, they don’t.

• Competitive Copycat: Defining product direction solely in reaction to your competitors.

• Quarterly Pivot: Swinging your priorities too frequently, driven by fear or short-term revenue hunts.

• Disconnected Goals: Strategy that doesn’t tie back to company vision or near-term execution.

• Ivory Tower Plans: Strategies that sound sexy but don’t connect to your reality.

Getting Started: Three Questions

If you’re just beginning your product strategy or suspect your team is spreading itself too thin, start here:

1. What are the 2–3 bets that create disproportionate value for your customers and business?

2. What are we explicitly choosing not to do, and why? Which customers or requests will we deny despite potential near-term revenue?

3. How will we measure progress, and which assumptions must we validate first?

These aren’t easy questions, but wrestling with them strengthens your conviction so you can confidently let go of lesser opportunities.

The Bottom Line

Product strategy isn’t about limitless options; it’s about making bold, calculated choices and focusing your finite resources on the few endeavors with the highest potential. Saying “no” can be uncomfortable, especially when customers present possible revenue or your team’s fear of missing out kicks in. However, this discomfort is where true strategy is crafted.

You create a robust foundation to endure market fluctuations by clearly outlining trade-offs, testing your assumptions, and being honest about your unique differentiators. In the fast-moving B2B landscape, the ability to remain steady or to pivot confidently as new information arises sets apart the best products from those who pursue every opportunity, ultimately finding themselves in the same place they were a year ago, just more burnt out.

What’s Next

This is just the foundation and the all-too-human challenges of sticking to a focused product strategy. Coming up, we’ll dig into:

• Strategic Context: How to analyze and continually update your view of the market, customers, and trends.

• Finding Big Bets: Practical exercises to identify which objectives matter most and how to test them.

• Saying No with Confidence: Frameworks for communicating (and defending) why you say “no” to good ideas.

• Strategy to Roadmap: Translating strategic objectives into actionable roadmaps for B2B teams.

• Real-World Lessons: Case studies of strategies that soared—or crashed.

For now, start mapping your assumptions and zeroing in on your 2–3 big bets. Your strategy’s already getting sharper. And remember, optionality feels safe, but it can quietly undermine your product’s chance to stand out. True strategic conviction means giving up perfectly good ideas to chase the few great ones.

You’ve crafted a product vision that’s sharp, inspiring, and ready to guide your B2B SaaS company into the future. Congratulations, you’ve cleared the first hurdle. But here’s the challenge: most visions, even the brilliant ones, fizzle out before they take hold. They get lost in the grind of daily priorities or diluted by competing agendas. Let’s change that.

In this follow-up to "Build a Product Vision That Doesn’t Suck", we’re tackling why visions fail to stick, how to set your product vision apart from the strategic clutter, and how to communicate it so powerfully that your team, investors, and customers can’t help but rally behind it.

Why B2B SaaS Companies Struggle with Vision Implementation

A great vision is only as good as its execution. Too often, B2B SaaS companies trip over the same obstacles, turning their bold ideas into forgotten slides. Here’s what’s standing in your way:

The Revenue Obsession

Many B2B companies operate with "generate more revenue" as their only real strategy, creating:

• Short-term decision bias: Teams consistently prioritize immediate revenue opportunities over strategic positioning.

• Feature bloat: Products accumulate any capability that might generate revenue, regardless of coherence.

• Value dilution: The product gradually loses focus, becoming mediocre at many things rather than exceptional at a few.

When revenue becomes the sole compass, product teams lose sight of the transformative future they initially aimed to create. The vision? It’s sidelined for the next all-hands slide deck.

The Sales-Led Hijack

In B2B organizations, especially those with founder-led sales or enterprise focus, visions frequently get derailed by sales priorities:

• Deal-driven development: Roadmaps shift based on requirements for the next big deal.

• Custom feature promises: Sales teams commit to customer-specific capabilities that fragment direction and delay making progress on the product vision.

• Disjointed evolution: The product becomes a collection of sales-driven commitments rather than an expression of a coherent vision.

This approach is great for early wins but boxes you into a niche so tight you can’t grow.

The Vague Vision Trap

Many product leaders will be pressured into maintaining flexibility, which requires keeping their vision intentionally vague. Making bets can be scary, but these nebulous visions create:

• Execution confusion: Teams lack clear guidance for prioritization decisions.

• Misaligned interpretation: Different departments develop contradictory understandings.

• Strategic drift: Without specificity, nothing prevents gradual departure from market opportunity.

It’s like handing your team a map with no roads, only a big X for treasure. Everyone nods in agreement, but no one knows where to step next. Priorities clash, teams drift, and your product loses its edge.

The Technical Indulgence

Another common pitfall is creating visions centered on technical capabilities rather than customer outcomes:

• Solution-first thinking: Teams focus on the technology they want to build rather than problems worth solving.

• Developer-centric priorities: Features evaluated based on technical interest rather than market value.

• Innovation without purpose: Pursuing technological advancement disconnected from customer needs.

Tech can be seductive, tempting you to build something because it’s cool, not because it’s needed. It’s like a startup chasing cutting-edge AI while ignoring basic user needs. When your vision fixates on shiny capabilities over customer outcomes, you’re innovating for applause, not impact.

The Stakeholder Alignment Challenge

Even with a well-crafted vision, achieving organizational alignment presents significant hurdles:

• Executive disagreement: Leadership teams often harbor competing priorities.

• Middle management resistance: Those responsible for execution may resist changes to established patterns.

• Incentive misalignment: Compensation structures frequently reward behaviors contradicting the stated vision.

You get what you incent. Nothing undermines a Product Leader’s vision like a CEO’s bonus structure tied exclusively to quarterly profits. Without aligning incentives to the long-term vision, you’ll remain trapped in short-term optimization.

Product Vision vs. The Strategic Soup

Your product vision isn’t your corporate vision, mission statement, strategy, or roadmap. It’s its own beast. Mixing them up breeds confusion. Here’s how they break down:

A product vision isn’t about listing features; it’s about painting a vivid future. Your mission might be “empower businesses with innovative software,” but your product vision should sing: “A world where mid-market manufacturers outpace giants with AI-driven production tools, no data science PhDs required.”

Vision Communication: Tailoring the Message

Different stakeholders require different vision articulations. Beyond traditional vision statements, more tangible formats often create stronger alignment and excitement.

For Investors

Focus on market opportunity size, differentiation approach, and evidence of validation. Connect vision to financial outcomes and competitive positioning.

Example: "Our vision positions us to capture the $4.2B opportunity in mid-market manufacturing analytics with a differentiated approach requiring 60% less technical expertise than current solutions, as validated by our 140% NDR among current customers."

For Customers

Customers don’t care about your tech; they care about their wins. Emphasize the impact of transformation through concrete before/after scenarios.

Example: "Imagine your production supervisors identifying potential quality issues before they occur, without waiting for weekly reports or requesting data science support. That's the future we're creating."

For Employees

Connect daily work to meaningful impact and provide context for prioritization decisions. Emphasize how the vision creates professional growth opportunities.

Example: "Every feature you build brings manufacturers closer to eliminating unplanned downtime. Your work directly impacts thousands of frontline workers and helps factories become more competitive against overseas alternatives."

Powerful Vision Communication Formats

Words alone won’t cut it. Make your vision stick with formats that grab attention and spark imagination.

Vision Types (Prototypes)

"Vision Types" or vision prototypes transform abstract concepts into tangible experiences:

• Interactive prototypes: Functioning demonstrations of the most important user journeys in the future experience.

• Experience videos: Short videos showing future user interactions with your product.

• Simulated dashboards: Mockups of insights users will access in your envisioned future.

Vision Types are particularly effective because they:

• Make abstract concepts concrete and testable.

• Allow stakeholders to experience the vision rather than just hear about it.

• Provide reference points for ongoing development decisions.

Modern AI-powered design tools like Figma's "Add Interactions" feature significantly reduce the effort required to create these vision prototypes. Foundational Models, like Claude, ChatGPT, and Gemini, or design-specific tools like Tempo, Lovable, and v01 can help get your vision out of your head if you lack designers. Do not misunderstand me; I highly recommend you find a way to get designers involved in this process. The earlier the better.

Visual Narratives

Visual storytelling formats dramatically improve vision retention and emotional connection:

• Comic strips/storyboards: Illustrate a user's journey from problem to solution, highlighting emotional impact.

• Day-in-the-life scenarios: Show how users' workdays transform through your solution.

• Customer journey maps: Visualize the complete experience transformation across touchpoints and help communicate the scope.

An insuretech SaaS company created a simple comic strip showing a homeowner’s frustration with their current tools and the relief and efficiency gained through their envisioned solution. This visual narrative became more memorable, digestible, and shareable than their formal vision document, with teams referring to specific panels when making product decisions.

Contrast Frameworks

Explicitly contrasting current reality with the envisioned future fosters clarity and urgency:

• Before/After comparisons: Juxtapose the current state with the future state to emphasize transformation.

• From/To statements: Develop parallel statements illustrating the shift in capabilities or experience.

• Problem/Solution pairs: Link specific challenges directly to their resolutions within the envisioned future.

A liquor brand effectively conveyed its vision by creating a "From/To" framework with its sales team. Previously, salespeople visited restaurants and bars during off-hours to discuss menus and encourage tastings to secure product placements. In the envisioned future, they introduced an app that analyzes customers' existing liquor lists, organizes options by tasting notes, identifies duplicates and gaps in flavor profiles, and recommends their products to enhance the menu. Additionally, it generates revised menus for servers, helping them better articulate options to patrons, enhancing customer knowledge, and ultimately boosting establishment profitability.

Laying the Groundwork for Product Success

Does the world have too many posts about Product Vision? Yes. Did I feel compelled to write another article after watching too many companies needlessly struggle without a compelling vision? Also yes.

Here’s the deal: you need a vision. I’m not concerned about the framework or format—whether it’s a polished document, a whiteboard scribble, or something you shout across a room. What matters is that it is ambitious, credible, and real. A product vision isn’t just a nice-to-have; it must carry inherent value and resonate with everyone involved in the product’s journey: your team, customers, and stakeholders. It’s not about buzzwords or fluff; it’s about authenticity. If it doesn’t feel authentic and resonate deeply, it’s not worth writing down.

A great product vision tells a story with a clear arc: here’s where we stand today, here’s the transformation we need to make happen, and here’s the vivid, compelling future we aim to build. It’s a narrative that doesn’t just describe a goal but paints a picture. It should be specific enough to grab attention and bold enough to inspire. The current situation might be messy or stagnant; the transformation might be challenging or radical; the future state should feel like a place worth reaching. That clarity is what turns a vague idea into a rallying cry.

However, a vision alone doesn’t get the job done. Product vision and strategy together form the foundation of successful product development. They bring direction and coherence to the messy, complex work of creating solutions that matter. A well-articulated vision lights the way, energizing your team and aligning stakeholders around a shared goal. Then, the strategy steps in, practical, deliberate, and grounded, charting the course with the steps, principles, and decisions needed to make that vision a reality. One inspires. The other executes.

What follows is a deeper exploration of how this plays out in practice. Because a vision without action is merely delusional, and a strategy without purpose is just busywork. Let’s dig in.

Why Most B2B Product Strategies Fail

Let’s be honest: most product visions in B2B SaaS are absolute trash: fluffy aspirational statements if they exist. It’s not because the thinking is wrong, but because they're too abstract, too vague, or disconnected from the daily reality of product development. They sound nice in a pitch deck but gather dust while your team’s arguing over the latest feature request. This guide focuses on creating effective product visions that have actually worked at successful B2B companies. not theoretical statements that sound good but provide no real direction. Your vision’s gotta be a weapon, not wall art.

Let's fix that.

What’s a Product Vision, Really?

Your product vision isn’t your strategy. Strategy is the playbook for this quarter, maybe this year. Vision is why you’re even in the game: why your product exists, who it’s for. It’s that point on the horizon you’re aiming at while the market shifts and your strategy pivots. No vision? You’re just reacting to market trends, competitors, internal politics, or that loudmouth in the boardroom. Without a clear vision, your product efforts will ricochet between opportunities like a pinball machine on tilt—lots of noise and flashing lights but no actual progress toward a goal. And in B2B SaaS, where consistency builds the trust that customers stake their careers on, that's a direct path to irrelevance. That’s how you die.

What Makes a Vision Actually Useful?

Forget vague frameworks and Madlib forms; useful product visions have these practical qualities:

• Memorable as hell.
  At Slack, their early vision of "making work life simpler, more pleasant, and more productive" was simple enough that teams would literally ask, "Does this make work life simpler?" when evaluating features. If it takes a script to recite, it’s junk.

• They help you say no to good ideas that don't fit.
  Notion’s “all-in-one workspace for notes, tasks, wikis, and databases” keeps them from chasing CRM or accounting gigs even when customers beg. Focus matters.

• They’re clear enough to call the shots without a babysitter
  Compare "become the leading platform" is fluff. Figma’s “making design accessible to all” tells you what to build and what to skip.

• Fires people up
  It’s gotta hit your team and customers in the gut. Not some save-the-world fluff, but a reason to care beyond a paycheck or features and functions.

• Big but not delusional
  The best visions stretch what seems possible without crossing into fantasy. Stripe’s “increase the GDP of the internet” is ambitious but tied to what they do. It’s not “fix world hunger.”
  

Visions That Actually Did their Job

Here’s some that worked, straight from the source:

Early-Stage Example: Superhuman

"The fastest email experience ever made. Superhuman helps you get through your inbox twice as fast as before."

Why it worked: This vision put speed at the center of everything. It guided Superhuman to focus fanatically on performance and keyboard shortcuts, even when users begged for extras that’d slow it down. One goal, nailed hard.

Growth-Stage Example: Airtable

"Enable anyone to create software applications without writing code."

Why it worked: This vision clearly identified both the value (creating software without coding) and the target user (anyone, not just technical users). It guided Airtable to continuously simplify their interface while stacking on power, knowing exactly who they’re serving. Clear who, clear what that kept them simple while scaling.

Enterprise Example: Snowflake

"Mobilize the world's data with the Data Cloud."

Why it worked: They didn’t just say “we store data.” This vision established a category (Data Cloud) while emphasizing accessibility of data. It guided Snowflake's product decisions around interoperability, data sharing, and marketplace development.

Platform Example: Shopify

"Make commerce better for everyone, so businesses can focus on what they do best: building and selling their products."

Why it worked: This vision clarified the ultimate beneficiary (businesses that sell products) and the core value (making commerce better). It helped Shopify expand beyond just being an online store platform while maintaining focus. It’s why they’re more than an e-commerce widget.

An effective product vision isn’t a slogan. It’s a filter.

How to Build a Vision That Doesn’t Suck

No templates. Start with questions that matter:

• What change are we chasing? Not cash but impact. The purpose beyond profit.

• Who’s it for? “Everyone” is a lame cop-out. Be specific, who are the primary beneficiaries,

• What’s their world like when we win? Paint a compelling future state.

• What do we believe? Your non-negotiable foundational values

• What’s our edge? Why you? What unique insight and/or capabilities form your differentiated viewpoint?

Then do this:

Dig for input. Ask founders, customers, and the team about their dreams, not just gripes. Find the patterns.

• Interview founding team members about the original inspiration

• Conduct customer interviews focused on aspirations, not just pain points

• Analyze customer success stories for patterns of transformational value

• Review industry trends and future projections

Spot the Core Themes. What keeps popping up? What hits you emotionally? Set a timeline: 3 years? No more than 5.

• Look for recurring patterns in customer transformations

• Identify emotional outcomes, not just functional benefits

• Pinpoint what makes your approach fundamentally different

• Determine what timeline makes sense for your vision (3 years? 5 years? 10 years?)

Craft Vision Candidates. Take 3-5 stabs at it. You want a start, not perfection (to quote Jake Knapp). Test them: can they steer a tough call? Stick in your head?

• Develop 3-5 potential vision statements with slightly different emphasis

• For each candidate, outline how it would guide specific product decisions

• Test each vision's memorability and inspirational quality

Test and Refine. Show customers, the team. Can they repeat it? Does it click? Keep grinding till it does.

• Share vision candidates with select customers, not just the ones that love you, for feedback

• Test internal clarity by asking team members to explain the vision in their own words

• Evaluate whether the vision creates clear decision-making guidance

• Refine based on feedback, prioritizing clarity and memorability

GitLab didn’t just stumble into “everyone can contribute.” They beat it into shape through an iterative process, testing how different vision statements guided actual product decisions before finalizing their vision.

Make it Real

A vision’s nothing if it doesn’t hit the ground. Here’s how:

Decision Filters and Product Principles teams can use to connect vision to daily choices.

Twilio's Vision-Based Decision Matrix: They created a simple scoring system where proposed features are evaluated on how strongly they support each element of their vision, creating a concrete way to prioritize based on vision alignment.

Atlassian's Vision Principles: They translated their vision into specific principles that teams can reference when making decisions, like "Make it obvious" and "Don't make me think."

Bake it in

Integrate your vision into the tools teams use daily:

• Include vision alignment fields in whatever you use to propose features (i.e., briefs)

• Add vision criteria to product review checklists. No connection? No go.

• Incorporate vision references in your stories and prototypes

• Create vision-based OKR evaluation criteria if OKRs are your thing.

Real-world example: Shopify includes a "Vision Alignment" section in all feature briefs, where teams must explicitly connect proposed work to their vision of making commerce better for everyone.

Regularly Reinforce Through Storytelling (not propaganda)

Like it or not, you have to merchandise your success. No one else will. Keep your vision alive through consistent storytelling:

• Share customer stories that exemplify vision fulfillment

• Celebrate decisions that prioritized vision alignment over short-term gains

• Use vision language consistently in communications

• Connect quarterly objectives explicitly to vision elements

Real-world example: Stripe regularly shares stories of how their products are helping increase "the GDP of the internet" (their vision), making the abstract concrete through specific examples.

When to Revisit Your Vision: Real Warning Signs

Don't revise your vision on a whim, but watch for these red flags:

• Teams consistently misalign on priorities despite agreeing on strategy: This indicates your vision isn't providing sufficient guidance.

• Customer conversations increasingly focus on problems you're not addressing: MongoDB stretched past the “database for giant ideas” when users demanded more.

• New hires struggle to understand why certain decisions were made: If it’s not obvious, it’s not working.

• You keep saying no to the same stuff: Maybe your lens is too tight for where your market is headed.

• No one is pumped: If your vision doesn't inspire, it may have become outdated or too familiar.
  

Where You’ll Screw Up

Here’s what often kills a vision:

Making it Too Broad

The problem: Visions like "transform the enterprise" are so generic they provide no guidance.

The solution: Include specific value and beneficiaries. Compare "transform the enterprise" with "enable marketing teams to create enterprise-quality video content without specialized skills."

Confusing Vision With Features - Vision is the change, not the how

The problem: Vision statements that list capabilities rather than outcomes.

The solution: Focus on the lasting change you'll create, not how you'll create it. Capabilities evolve, but the core transformation should remain stable.

Fantasyland - Don’t get too far over your skis (working in Colorado left an impact)

The problem: Vision statements that list capabilities rather than outcomes.

The solution: Focus on the lasting change you'll create, not how you'll create it. Capabilities evolve, but the core transformation should remain stable.

One and done. Check it yearly, it’s not scripture.

The problem: Creating a vision statement once, then never revisiting it as the company evolves.

The solution: Schedule annual vision reviews to assess continued relevance, while respecting that vision should change less frequently than strategy.

No follow-through. If teams can’t use it, it’s pointless.

The problem: Having a vision statement that teams can't connect to their daily work.

The solution: Create explicit connections between vision and decision criteria, ensuring teams understand how the vision applies to their specific context.

Is it Working?

You’ll know your product vision is doing its job when:

Decision Match

Track whether similar decisions are made consistently across teams without escalation. If your vision is clear, different teams should reach similar conclusions when facing similar choices.

Everyone Gets It

Randomly ask team members to explain why specific product decisions were made. In companies with effective visions, explanations consistently reference vision elements, even across departments.

Customers See It

When customers describe your product to others, they should articulate value aligned with your vision. If customer perceptions consistently differ from your vision, there's a disconnect to address.

Strategic Stability

Track how often strategic priorities change. With a clear vision, strategy may adapt in approach but should maintain consistent themes aligned with the vision.

People join and stick around

Measure how often candidates and employees cite your vision as a reason for joining or staying. Powerful visions attract and retain talent who share your purpose.

Real-world example: Figma measures vision effectiveness by tracking how consistently employees across departments can articulate what makes Figma different and what future they're building toward.

Conclusion: Vision as Foundation, Not Decoration

Your vision isn’t a tagline. It’s the bedrock. Not about looking good. It’s about being good. Not inspiration. It’s direction. Not tomorrow. It’s today. Strategy tells you how you'll win the game this season. Vision reminds you why you're playing the game at all.

A compelling product vision won't guarantee success, but it provides the clarity, consistency, and inspiration that make success possible. In the fast-changing world of B2B software, your vision is the one thing that should change the least, providing stability amid constant evolution.

The best product visions aren't theoretical—they're practical tools that help teams stay focused on what truly matters, making better decisions every day because they know where they're ultimately headed and why. Get it right, and you’ve got a shot at something real. So do it. Now.

The rise of AI and automation is driving this seismic shift, reducing the need for software engineers while redefining how innovation happens. Tech giants like Salesforce, Microsoft, Meta, and Google are leading the charge, betting on AI to do more with less. Meanwhile, venture capitalist Tom Tunguz's thought experiment, "What If You Cut R&D by 50%?" offers a lens to understand this trend, suggesting that drastic cost-cutting could boost profitability if paired with the right tools. In 2025, AI is proving to be that tool, turning Tunguz's hypothetical into reality.

AI is Eating Software Engineering Jobs

The employment landscape in tech is undergoing a structural overhaul, and the numbers tell a stark story. Job openings for software engineers in the US have plummeted to a five-year low, down over a third from pre-AI highs, according to Indeed. Why? Because AI is supercharging productivity, reducing the need for human coders across the board. Here's how the big players are adapting:

• Salesforce: CEO Marc Benioff hinted they might not hire any software engineers in 2025. AI agents are working alongside current staff, delivering "incredible productivity gains," as Benioff put it. Why hire more when machines can pick up the slack?

• Microsoft: Layoffs are looming in 2025, with engineering roles likely on the chopping block.

• Meta: Mark Zuckerberg envisions AI replacing mid-level engineers by 2025, offloading chunks of the coding workload to algorithms.

• Google: Sundar Pichai revealed that as of October 2024, AI writes over 25% of Google's new code. That's a massive shift, and it's only accelerating.

These aren't isolated moves. They're part of a broader trend. Companies are shedding their old skin and embracing automation to stay lean and competitive. Those that can't adapt? They're getting left behind. Over the weekend, there were a few LinkedIn posts about companies that can’t find their Series A. They’re structured based on yesterday’s playbook, and the effort to flip to the AI script must be too hard and/or too long for them to adapt.

From Job Losses to Strategic Efficiency

This isn't just about fewer jobs, it's about a fundamental rethink of how tech operates. Enter Tom Tunguz's thought experiment, where he asked: could SaaS companies cut R&D budgets by 50% and still thrive? His analysis suggested that for cash-burning firms, such a cut could flip them into profitability overnight. The trade-off? Innovation might stall, threatening long-term growth. In a pre-AI world, that risk loomed large. But today, AI is rewriting the equation.

Take Google's 25% AI-written code or Salesforce's productivity-boosting agents. These aren't cuts for the sake of cuts. They're strategic pivots. AI tools like Cursor, Windsurf, and Claude Code are letting lean teams punch above their weight, handling the grunt work (boilerplate code, optimization, prototyping) so humans can focus on big-picture innovation. Tunguz noted that redirecting R&D savings into growth could multiply enterprise value fivefold. In 2025, that means doubling down on AI to stay ahead, not just to survive.

AI: The New R&D Engine

Here's the kicker: AI isn't just a cost-cutter, it's an innovation enabler. Cutting R&D by 50% might have crippled companies a decade ago, but now it's a viable strategy. Why? Because AI handles the heavy lifting. A small, elite team paired with an army of AI assistants can iterate faster, experiment bolder, and ship smarter than a sprawling pre-AI R&D department ever could. It's not about doing less, it's about doing more with less. Companies aren't sacrificing their future; they're outsourcing the tedious stuff to machines and freeing up human creativity for what matters.

The Catch and the Opportunity

Of course, there's a flip side. Over-relying on AI risks homogenizing the tech landscape, everyone using the same tools could end up building the same products. Quality might slip if human oversight fades too far. But for now, the winners are clear: companies that pair AI efficiency with strategic human ingenuity are thriving.

While traditional software engineering roles are being rapidly redefined—and yes, some are vanishing. AI is unlocking a new frontier of tech careers. Think AI strategists shaping the future of automation, ethical overseers ensuring algorithms play fair, and innovators in roles so cutting-edge we haven’t even named them yet. It's a rough transition for many engineers, but the market's shifting, not collapsing. Look at the roles at companies like Anthropic, OpenAI, and Mistral.

The Bottom Line: Lean is the New Black

We're at peak employment in the old-school sense, and the future belongs to leaner, AI-powered teams. Tunguz's thought experiment asked if companies could survive a 50% R&D cut. In 2025, AI answers with a resounding "yes”, not by slashing innovation but by reimagining it.

Tom Tunguz, a heavyweight in the venture capital world, argues that software companies don’t get their valuation from profitability alone and he’s got a point. But the ground is shifting beneath our feet. These days, the chatter in the tech scene isn’t just about sky-high growth rates anymore; it’s buzzing with terms like EBITDA and the Rule of 40. Investors (institutional, PE, and VC) aren’t chasing the next rocket-ship startup with flashy chart. They’re demanding sustainable hustle (with rocketship growth). Growth only still turns heads if it’s not drowning in a sea of red ink.

Salesforce, Microsoft, Meta, and Google are living proof, cutting back on software engineers while pushing the envelope with AI. The Indeed data, job openings down over a third, confirms this isn't a blip; it's a new reality. AI's rewriting the rules: play smart, or get played

Picture this: You’re a product manager stuck in the crosshairs of a battlefield. Feature requests are raining down like gunfire. Sales are yelling for a shiny new toy to land a deal, power users are hammering you for custom tweaks to make their lives easier, and you’re trying to keep your product from turning into a mangled pile of junk. The pressure’s on, the chaos is real, and the temptation is to just say yes to everyone and call it a day. But that’s how you end up with a bloated, directionless mess that nobody loves and everyone abandons. I’ve been there. I’ve seen the wreckage. And I’m telling you straight: there’s a smarter way to fight this war.

Your Battle Plan: Product Strategy

Forget the fluffy metaphors. Your product strategy isn’t some feel-good poster on the wall, it’s your battle plan. It’s the thing that tells you who you are, where you’re headed, and how you’re getting there without losing your soul. It’s not about features; it’s about vision, goals, and the bets you’re willing to stake your reputation on. Without it, you’re just flailing, reacting to every loudmouth with an idea. With it, you’ve got the guts to say no and the reasoning to make it stick.

This isn’t optional. In a world where every stakeholder thinks they’ve got the golden ticket, your strategy is the filter that keeps you from drowning in their noise. It’s the line in the sand that says, “This is our fight, and we’re not budging.”

Power Users: The Loyal Rebels

Power users are your die-hards. They love your product, they know it inside out, and they’ll scream from the rooftops about how great it is until they want something you can’t give them. These folks are deep in your world, and they’ll push for changes that make their day smoother, even if it screws over everyone else. I’ve seen it up close: a mid-market SaaS client begging for a custom integration that’d take months, while the small businesses we were built for just wanted speed and simplicity.

Here’s the trap: you either bend over backwards for them and alienate your core audience, or you ignore them entirely and miss out on real opportunities. Both roads lead to a shrinking user base. Saying no is brutal. They’re vocal, valuable, and will escalate to your boss’s boss or flood your support team with tickets. But when you’ve got to shut it down, own it. Don’t hide behind “the team” or “the roadmap.” Say, “I don’t think we should do this because it doesn’t fit our strategy, and here’s why.” Be clear, tie it to your vision, thank them for their input, and don’t dangle false hope. That’s how you keep their respect, even when they’re pissed.

Sales Requests: The “Just One Feature” Fallacy

Sales folks can be mercenaries looking out for the customer, the company, and their own commission checks, and you can't blame them. It's their job to hit numbers, and you as a Product Manager play a key part in that equation. But there will come a day when you hear those five dangerous words: "Just one feature to close BigCorp!" It's always "just one feature" to land the big fish, and the urgency pitch makes it tempting to cave.

Here's the brutal truth: when Sales says they need "just one feature," only two scenarios are playing out. Either they've uncovered a genuine market insight that your product strategy should embrace, or they're selling to a customer that isn't your Ideal Customer Profile. There's no middle ground. That "must-have" feature request is telling you something critical about your product-market alignment.

But that one feature? It's a gateway drug. Say yes without strategic consideration, and suddenly you're sucked into a market segment you don't yet understand, with more demands piling up faster than your LLM token usage until you're so far off course you might as well be navigating with a blindfold. I've watched promising products spiral into custom development hell because someone chased a shiny deal without a strategic map. The sunk cost fallacy takes hold: "Well, we've already built half of what they need," and before you know it, you're maintaining a custom branch of your product for a segment you never intended to serve.

The fix starts with ruthless communication of your product strategy. If Sales doesn't intimately know your roadmap vision (where you're going, who you're built to serve, and just as importantly, who you're not built for), they'll keep throwing strategic curveballs that waste everyone's time.

When that feature request lands, don't just shoot it down with a dismissive "not on the roadmap." Dig in like a detective: Why is this specific capability a dealbreaker? What's the real underlying need they're trying to address? What market segment does this prospect represent?

Sometimes, you'll uncover a legitimate market signal worth pivoting toward, a genuine eureka moment that should reshape your strategy. Other times, the conversation will reveal that you're simply dealing with a poor-fit customer who should be pursuing a different solution. Either way, you've transformed a potential fight into a strategic conversation that sharpens your market position and makes everyone smarter. The best product leaders don't just say no, they turn every "just one feature" request into an opportunity to pressure-test their strategy against market realities.

Prioritization: Think, Don’t Just Score

Prioritization frameworks? I’m skeptical. They’re too easy to game; people fudge numbers to push their pet projects, and you’re left with a stack of nonsense. But you need something to show your work, or you’re just the jerk saying no for no reason. Keep it simple: urgency, impact, cost. Rate it, rank it, but don’t let the numbers run the show. The real juice is in the debates, those messy talks that reveal dependencies, risks, and insights no spreadsheet can catch. Use the framework to force people to justify their asks, then trust your gut to make the call.

Outcomes, Not Features: Digging for the Why

Customers love to play designer. They’ll say “dashboard” or “integration with X” like it’s the holy grail. Stop. Put down the Figma. Take a breath. Ask why. Nine times out of ten, they don't need the thing they're asking for, they need the problem solved, which is rarely the same thing. I've seen entire quarters wasted building requested features that barely got used because they addressed the symptom, not the disease. Your strategy lives or dies on outcomes and real value, not a barely related set of features that were thrown on the proverbial pile. Dig for the why, and you’ll find the actual pain.

When a customer says, "we need X," the conversation isn't over; it's just beginning. "What would that help you accomplish? What pain does that solve? What happens if you don't get this?" These questions are your pickaxe, digging beneath the surface request to the gold underneath.

The most dangerous feature requests come wrapped in solution language from smart people, they've thought about their problem and jumped to a solution that makes sense in their world. But they don't see your entire product ecosystem, your technical debt, or your strategic vision. It's your job to translate their solution-speak back into problem-speak, then evaluate whether their proposed solution is actually the optimal path forward.

In practice, this looks like: "So you're asking for a dashboard to track customer engagement across channels. Tell me more about what decisions that would help you make." Then listen. Really listen. The gold is often buried in throwaway comments: "Well, our renewal meetings are next week, and I have no idea which customers are at risk," or "I spent three hours yesterday pulling reports for my boss, and I'm doing it again tomorrow."

There's your real problem: not lack of a dashboard, but inefficient risk identification or manual data aggregation. Your product strategy should establish clear, customer-focused outcomes that you're driving toward, reduced time-to-insight, increased decision velocity, and better allocation of resources. Those outcomes become your evaluation criteria for every feature request. Does this dashboard actually move the needle on those outcomes? Or is there a completely different approach that would deliver more value with less effort?

Pick Your Fight

You can’t win every battle. Trying to please everyone gets you nowhere. Know your market: who you serve now, who you’ll own later, and stick to it. If you’re built for startups, don’t chase enterprise whales. Saying no to the wrong crowd isn’t failure; it’s focus.

Stay True

Your strategy’s got a backbone, principles that don’t bend. If simplicity is your game, a complex request is dead on arrival. Those guardrails keep your product tight and your team honest.

One Team, One Fight

Get everyone on board: Sales, Marketing, Support, and yes even Eng. When they’re part of the strategy, the whining stops. It’s not you against them; it’s all of you against the chaos.

Numbers Don’t Lie

Anchor your calls in data: adoption, revenue, or whatever matters. No impact? No go. It’s your shield when the pushback hits.

Less Is More

Focus is king. Chasing every idea dilutes you into mediocrity. Pick your shots and hit them hard.

Shout It Loud

If your team doesn’t know the plan, you’re screwed. Make it clear, make it loud, and make it stick. When everyone’s on the same page, saying no is just common sense.

The Power of No

Saying no isn’t weak, it’s your edge. It clears the deck for the big wins, keeps your product sharp, and your sanity intact. A tight roadmap beats a cluttered disaster every time.

In a B2B game where the rules are shifting and the stakes are high, you don’t win by being nice. You win by thinking straight, swinging bold, and sticking to a strategy that cuts through the crap. Life’s too short for mediocre products. Grab your plan, make the hard calls, and build something worth your time.

Subscribe now

Let’s cut to the chase. If you’re not knee-deep in the AI debate, wondering if it’s going to eat your job or turn you into some kind of superhero, you’re probably not paying attention. We’re in the thick of it, folks. AI isn’t just some shiny new gadget; it’s rewriting the rules of the game. And in this game, there are winners and losers. Guess which one you want to be.

Everyone is a Product Manager (That’s a Good and Bad Thing)

Here’s the deal: the ivory tower of product management is crumbling. Everyone thinks they’re a Product Manager now. Engineers are making calls on the fly, guided by vibes instead of dusty requirements and Jira tickets. Designers aren’t just sketching pretty screens and building design systems; they plot entire strategies. Even the marketer who previously only haunted you in #General to share their LinkedIn post is tossing out feature ideas like they’ve been shipping products since the dawn of time. It’s chaos out there.

This isn't necessarily a bad thing. The best products have always emerged from a shared sensibility about what constitutes quality—a collective taste. AI has smashed the gates wide open, handing everyone the tools and speeding up the feedback loops to the point where taste and critical thought have become the primary differentiators.

This free-for-all is a double-edged blade. On one side, it’s a rush—everyone’s got a shot at brilliance. On the other, it’s a screaming mess, like a room full of lunatics with no one at the helm. As Product Managers, we’re not extinct; we’re just shifting gears. The flood of ideas is faster and rawer than ever. You can try to push back, but good luck with that. Better to lean in—give your team the tools to sharpen their thoughts, then step up as the one who sifts through the noise. The art isn’t in owning the vision anymore. Now, your job is to curate the vibes.

Smaller Teams, Bigger Headaches

AI is trimming teams down to the bone, and yeah, the efficiency is a siren song. We’re cranking out plans, mockups, and data breakdowns at warp speed—fewer hands, more results. It’s seductive until you realize it’s a grind with no end. Smaller crews mean the pressure’s all on us. Burnout’s waiting in the shadows, and when the AI churns out a dud, who’s left to take the hit? Not the model. Us. The humans. Because when the users scream, “What the hell is this?” no one’s pointing fingers at the LLM. We’ve got to juggle the promise of speed with the reality of keeping a team, and ourselves, from cracking.

The Productivity Trap: Faster, But Hollow

Here’s a kicker for you: an MIT study finds highly skilled workers using AI are more productive but less happy. They feel like they’re working for the AI, not the other way around. In Product Management, that’s a five-alarm fire. This job thrives on intuition, creativity, and that hair standing up on the back of your neck the moment when you know you’ve nailed the user’s pain point and can make the company a boatload of cash. If AI starts calling the shots, we’re reduced to button pushers in a machine-driven dystopia.

I've felt that creeping sensation that I'm becoming a mere prompt engineer, a servant to the machine rather than its master. The work gets done faster, but sometimes it feels hollow, as if the soul has been extracted from the process. The tools promise liberation but can sometimes deliver a subtle form of subjugation.

I’m not here to romanticize the old days; spreadsheets and sticky notes had their own hell, but there’s a soul to Product Management that AI can’t replicate. It can crunch numbers, spit out trends, and mock up a dozen feature ideas before breakfast, but it can’t feel the market’s pulse or hear the unspoken needs behind a user’s complaint. The risk is real: we get so damn good at output that we forget why we signed up for this ride. We are in danger of becoming our own feature factory.

Superagency: Teaming Up Without Selling Out

But hold up—there’s a lifeline. Call it “superagency.” It’s the sweet spot where AI and humans tag-team to hit heights neither could alone. AI takes the grunt work—digging through data, sniffing out trends, sketching first drafts—while we zero in on the big moves, the stuff that makes this job an art. It’s not about handing over control; it’s about juicing up what we already bring to the table.

The Product Managers who’ll own this new world aren’t the ones outsourcing their brains to AI. They’re the ones who get that it’s a force multiplier, not a replacement. I’ve seen it in action: PMs firing off a dozen wild ideas with AI, then using that human edge to pick the winners. It’s a partnership that can crank out stuff we couldn’t dream of a few years back.

The future of product management isn't about surrendering to AI or fighting against it. It's about finding that perfect symbiosis, where human imagination and artificial capability combine to create something greater than the sum of their parts.

The Bottom Line: Keep the Machines in Check

Here’s where we land: the fate of Product Management isn’t locked in yet. We can let AI turn us into hollow shells, feeding the beast, or we can wield it to sharpen our best instincts. I’m throwing my chips on the second option, and you’d be wise to follow.

This job’s always been a split between cold logic and wild art. AI pumps up the logic, but it can’t touch the art. The sharpest PMs will ride both waves, knowing the tools can speed us up, but only our human grit makes it count. AI hands us the raw material; our passion, our skepticism, our intuition shape it into something users crave and businesses bank on. Embrace the tech, sure, but don’t forget who’s steering this ship. It’s not about the gadgets—it’s about the craft. Let’s not blow it.

Subscribe now

AI isn't just changing the game; it's flipping the board. Everyone's suddenly a "product manager" now that they can prompt their way to wireframes, specs, and maybe even production code. In the meantime, a cataclysmic explosion of templates and frameworks has become a crutch that bypasses critical thinking and creativity.

If you’re fed up with the buzzwords, the frameworks, and the AI-generated roadmaps that promise salvation but deliver jack squat, you’ve landed in the right place. Welcome to Jeff On Product, a Substack for those who crave depth in a sea of templates.

The Road to Here: Scars, Stories, and a Few Wins

I’ve worn every hat in the game: founder sweating over whether to keep building or sell, CEO making the tough calls and managing a board, CTO building and breaking things in equal measure, Data Scientist wrestling truth out of chaos, and Product Leader playing translator between the suits and the coders. I’ve sat in boardrooms so tense you could hear the desperation behind every “strategic vision,” knowing full well it was just a plea for more time before the money ran dry.

My road’s been a long one with tours at VC-backed startups, private equity pressure cookers, and public companies, crisscrossing the US, Canada, Europe, and beyond. I’ve done time on corporate boards and tech associations, worked the B2B grind with some marketplace adventures thrown in for good measure. I’ve run with the champs and the chumps, and the chumps showed me more about how shit really works.

I've consulted on product strategy for the tech giants you know, back when they were FAANG, not whatever alphabet soup they’re calling themselves now. I’ve helped global brands crack open new markets, and mentored hundreds of startups as an Entrepreneur in Residence across multiple accelerators. For good measure, I even had a hand in architecting a global financial standard. Oh, and I once took down AWS SQS with a deployment so innocent yet devious that it deserves its own cautionary tale. I only write code for fun these days—the world is safer that way. 

Through all the chaos, one thing never blinked: my obsession with building products that don’t suck.

The Ugly Truth About Product Management

I’ve spent twenty years watching Product management evolve from "that thing engineers tolerate" to whatever the hell it is now, where frameworks and templates are choking the life out of Product Management, turning craft into equal parts paint-by-numbers exercise and soul-crushing assembly line.

Why this Substack? Because I’m done with the bullshit. And you should be, too. The world of Product has never been more critical—or more flooded with noise. AI can crank out a roadmap before you’ve finished your coffee, but it’s got no clue why you’re even bothering. And while we’re all busy worshipping at the altar of the latest framework, the real juice—critical thinking, guts, imagination—is leaking out the cracks.

There’s a library’s worth of books, podcasts, and Medium posts on product strategy, yet it remains woefully misunderstood. Or perhaps worse: understood in theory but abandoned in practice. We get the theory, sure, but when the quarterly crunch hits or the next big deal hinges on a feature we don’t have, we’re still pumping out features like drones on autopilot. It’s time to reclaim the soul of this gig, and I’m starting right here.

What to Expect: The Good, the Raw, and the Real

Don’t expect another “7 frameworks to prioritize your backlog” snoozefest. I’m not pumping templates or promoting certifications. What you’ll get is:

• Raw, unfiltered takes on product strategy in this AI-drenched age

• Trench tales from the front lines of product leadership—the wins, the flops, and the ugly in-between

• A cold, hard look at industry trends, stripping away the hype and buzzwords

• Real advice for navigating the shitstorm of building products that matter

I’ll aim to drop something weekly, but full disclosure: if the mountains are calling or the trails are prime, I might ghost you for a bit. I’m a human, not a content-spewing robot.

Subscribe now

Why You Should Subscribe

Because you’re sick of the crap, too, you’ve sat through enough PowerPoint sermons that sound brilliant until they hit the real world and shatter like cheap glass. You know there’s more to this game than filling out a canvas or marching to someone else’s playbook. You want the voice of someone who’s been in the muck, screwed up royally (and not just once), and still came out swinging.

Or maybe you’re just here for a skeptic who’s taken too many hits to buy the hype, but still gives a damn enough to cut through the noise. Either way, I won’t waste your time or clog your inbox with fluff. No jargon, no fluff, just the kind of jagged, hard-won truth I’ve scraped from the wreckage.

Hit subscribe to get new posts dropped straight to your inbox. Pass this along to your crew, your rivals, or that coworker who needs a wake-up call. And if something I say lights a fire, or pisses you off, drop a comment. I’m here for it.

Until next time, keep your eyes open, your bullshit detector on, and never let a template run your life.