Far fewer learn how to make an executive decision easier.

That distinction sounds semantic until you watch a senior PM walk into an executive review with 38 beautifully formatted slides, spend eight minutes explaining the research methodology, get interrupted on slide four by the CFO asking, “So how much money are we talking about?”, and discover that the rest of the meeting has abruptly become an oral examination for which PowerPoint provides remarkably little emotional support.

The PM was presenting.

A VP of Product would have been architecting the decision.

That is the real skill behind “executive communication.” It is not speaking more slowly, deleting adjectives, wearing darker clothing, or sprinkling sentences with the word strategic. Senior executives are not a separate species requiring their own dialect. They simply operate under a different information constraint: they must make consequential decisions across domains in which they usually know less detail than the people presenting to them.

Your job, therefore, is not to demonstrate how much you know.

Your job is to compress what you know into the smallest amount of information required to make a good decision—without hiding the uncertainty, trade-offs, assumptions, or unpleasant bits.

That last clause matters.

Executive communication is not simplification. It is compression without distortion.

And the difference between the two is where a great many product presentations go to die.

The C-Suite Has an Information Problem, Not an Attention-Span Problem

There is a popular caricature of executives as people capable of absorbing information only in 30-second bursts between airport lounges.

The reality is more interesting.

Executives will spend hours on a problem when the decision warrants it. What they resist is spending an hour discovering what the problem actually is.

McKinsey surveyed more than 1,200 managers and executives about organizational decision-making and found that only 20% believed their organizations excelled at it. Even more striking, 61% said at least half of their decision-making time was ineffective. McKinsey estimated that inefficient decision-making at a typical Fortune 500 company could consume about 530,000 manager-days annually, representing roughly $250 million in wages. McKinsey’s research on decision-making

There is another counterintuitive finding: speed and quality are not necessarily enemies. Respondents who described their companies as fast decision-makers were almost twice as likely to say their decisions were high quality. McKinsey’s “Three Keys to Faster, Better Decisions”

So the executive communication problem is not:

“How do I squeeze my 45-minute presentation into 15 minutes?”

It is:

“How do I structure this conversation so the organization reaches the right decision with the least unnecessary cognitive and political friction?”

That is a much more senior question.

And it changes almost everything about how you write memos and build decks.

Lesson One: Amazon Didn’t Replace PowerPoint With Memos. It Replaced Presentation With Thinking.

No discussion of executive memos can escape Amazon, so we might as well invite Jeff Bezos into the room early.

Amazon famously abandoned conventional slide presentations for important internal meetings. In his 2017 shareholder letter, Bezos explained:

“We don’t do PowerPoint… Instead, we write narratively structured six-page memos.”

Participants then silently read the memo at the beginning of the meeting. Jeff Bezos’s 2017 shareholder letter

This practice is frequently summarized as “memos are better than PowerPoint.”

That is too shallow.

The important part is what happens before the meeting.

Bezos noted that high-quality six-page memos might take a week or more to produce. They are drafted, rewritten, circulated to colleagues, revised again and then edited after time away from the document.

Why?

Because prose exposes bad thinking.

A slide can say:

Strategic Growth Opportunity

• Expand ecosystem

• Unlock synergies

• Increase engagement

• Create differentiated value

• Leverage AI

Congratulations. You have written five phrases that could describe approximately 81% of Silicon Valley strategy decks since 2017.

Now try turning them into prose:

We recommend investing $4.2 million over 18 months to launch an AI-assisted workflow for mid-market customers because customer interviews indicate that setup complexity is the largest remaining barrier to activation. We estimate the initiative can improve 30-day activation from 42% to 50–54%, which would add approximately $7–10 million in annualized gross profit if retention remains unchanged.

Suddenly the writer must explain the causal chain.

What customer?

What problem?

What investment?

What metric?

What outcome?

What assumption?

That is why narrative writing is powerful. It turns intellectual fog into sentences, and sentences are irritatingly resistant to hand-waving.

Amazon’s current explanation of its product-management model shows the same discipline in its famous Working Backwards mechanism. Before funding a product or writing code, teams create a hypothetical press release and FAQ. The internal FAQ explicitly tackles questions such as:

• Will this product be profitable?

• Could it cannibalize another product?

• Do we have the resources?

• What happens if it breaks?

• Why would a customer choose it?

AWS on product management and Working Backwards

That is not merely product discovery.

It is pre-emptive executive communication.

The team is answering objections before asking executives to invest scarce capital.

What a Product Leader Should Steal From Amazon

Do not copy the six-page limit religiously.

Copy the intellectual mechanism.

Before an executive review, force your argument into prose:

Context → Problem → Evidence → Alternatives → Recommendation → Economics → Risks → Decision

If you cannot write that coherently, your deck will not rescue you.

PowerPoint is many things, but a licensed therapist for confused strategy is not one of them.

Lesson Two: The Memo and the Deck Solve Different Problems

The fashionable conclusion from Amazon is that “slides are bad.”

That is nonsense.

Slides are excellent at showing:

• trends,

• comparisons,

• financial models,

• funnels,

• cohorts,

• customer journeys,

• competitive maps,

• architectures,

• scenarios.

Memos are better at showing reasoning.

The mistake is asking one medium to perform the other medium’s job.

Sequoia Capital’s guidance for company boards makes this point explicitly. Its board-meeting advice notes that some companies use decks while companies including Qualtrics, Domino and Thumbtack have used Amazon-style memos. Sequoia’s conclusion is refreshingly un-dogmatic: use whatever medium communicates most effectively. Sequoia Capital’s guide to preparing a board deck

More importantly, Sequoia defines the purpose of the board material as calibration.

Board members do not live inside the company every day. Management does.

The communication artifact has to bring those two information states close enough together that board members can contribute useful judgment.

That same principle applies when a Director of Product presents to the CEO or CFO.

You have spent four months debating whether to move upstream from SMB to enterprise.

The CFO has spent four minutes thinking about it.

Your responsibility is not to replay those four months chronologically.

It is to reconstruct the minimum context necessary for the CFO to reason at your level.

That is calibration.

Use the Memo for Logic

A decision memo should answer:

1. What changed?

2. Why does it matter?

3. What decision are we making?

4. What are the realistic options?

5. What do we recommend?

6. Why?

7. What must be true for us to be right?

8. What could make us wrong?

Use the Deck for Evidence

Then show:

• revenue scenario,

• adoption curve,

• retention cohorts,

• capacity requirements,

• customer evidence,

• competitive position,

• timeline,

• sensitivity analysis.

The memo tells executives what to think about.

The slides give them the evidence to challenge the thinking.

That combination is far more powerful than either medium becoming a corporate religion.

Lesson Three: Put the Punchline First

Most product presentations are structured like detective novels.

First, some background.

Then research.

Then findings.

Then perhaps a persona.

Then the market.

Then some screenshots.

Then competitive analysis.

Then, around slide 27:

Recommendation

This structure makes sense psychologically to the presenter because it recreates how the team discovered the answer.

It makes almost no sense to an executive.

Your CEO did not attend the meeting to experience your personal journey toward enlightenment.

Start with the answer.

Bessemer Venture Partners’ board guidance recommends opening a board deck with the company’s three to five major priorities, their associated metrics, and a simple status indicator. Then show the priorities for the coming period. Bessemer’s CFO playbook for board communication

Former Oracle CFO Jeff Epstein puts the principle memorably:

“When you present to a board, tell the punchline at the beginning.”

There is a reason Barbara Minto’s famous Pyramid Principle, developed from work at McKinsey, starts with the governing idea and organizes supporting arguments underneath it. The Minto Pyramid Principle

For product leaders, that means replacing this:

“Today I’m going to walk you through our research into checkout conversion.”

With:

“We recommend delaying international expansion one quarter and moving two squads to checkout. Mobile payment failures are costing an estimated $5.8 million in annualized GMV, and our experiments indicate we can recover roughly one-third of that within six months.”

Now you have a meeting.

Everything after that sentence exists to interrogate the recommendation.

The VP-Level Executive Memo

Here is a structure I recommend for consequential product decisions.

Not every topic requires all eight sections, and that is the point. The format serves the decision; the decision does not serve the template.

1. Decision Required

One sentence.

Approve a $3.5 million FY27 investment to replace our legacy onboarding platform and migrate all new enterprise customers by Q3.

Not:

Discuss onboarding modernization strategy.

“Discuss” is where accountability goes for a little vacation.

2. Executive Recommendation

Two or three sentences.

State:

• what you recommend,

• why,

• expected business impact.

For example:

We recommend rebuilding rather than extending the current onboarding platform. The existing architecture now adds approximately 11 engineering weeks to each major enterprise integration and contributes to a median implementation time of 84 days. We expect the replacement to reduce implementation time to roughly 50–60 days and recover its cost within 24–30 months.

Your reader now understands the argument before reading page two.

3. What Changed?

Executives need the delta.

Do not provide the history of civilization.

Explain why the issue deserves attention now.

Perhaps:

• enterprise demand doubled,

• churn increased,

• a regulation changed,

• a competitor changed pricing,

• inference costs collapsed,

• a key assumption failed,

• engineering capacity changed,

• your previous strategy worked so well that it created a new bottleneck.

Strategy is usually triggered by changed conditions.

Show the change.

4. Evidence

Use only evidence capable of changing the decision.

For example:

• 14 of the last 20 enterprise losses cited integration speed.

• Median implementation time rose from 61 to 84 days.

• Accounts activated within 45 days retain at 93%; those exceeding 90 days retain at 78%.

• Engineering spends 31% of platform capacity supporting custom integrations.

Notice what is missing.

There is no slide titled “What Is Onboarding?”

Your CEO is probably familiar with the concept.

5. Alternatives

This section is where seniority becomes visible.

Weak PM:

Here is my solution.

Senior PM:

Here are three options.

VP:

Here are three options, the constraints that make each rational, the second-order effects, and why I am recommending Option B despite its disadvantages.

Try this:

Option

Investment

Upside

Downside

When It Wins

A: Patch legacy system

$900K

Fast

Technical debt increases

Demand plateaus

B: Rebuild platform

$3.5M

Structural improvement

12–15 month investment

Enterprise continues growing

C: Buy vendor

$2.2M + fees

Faster deployment

Vendor dependency

Requirements remain standard

Executives need choice architecture.

Without alternatives, you are asking for approval.

With alternatives, you are enabling judgment.

Put the Trade-Off in the Room

One of the biggest differences between mid-level and executive communication is comfort with trade-offs.

Junior communication often tries to make the recommendation look obviously correct.

Executive communication explains why reasonable people might disagree.

Suppose you want to launch an AI copilot.

Do not say:

“AI will increase customer productivity and drive engagement.”

Say:

“We expect the copilot to improve task completion by 15–25%, but inference costs could reduce gross margin by 1.8–3.1 points at high adoption. We therefore recommend launching first to the Pro tier with usage caps while we validate willingness to pay.”

Now the real question is visible:

Growth versus margin.

Other common product trade-offs include:

• speed versus reliability,

• growth versus profitability,

• customization versus scalability,

• enterprise features versus product simplicity,

• platform investment versus near-term roadmap delivery,

• acquisition versus retention,

• automation versus control,

• global consistency versus localization,

• customer value versus implementation complexity.

Senior leaders expect uncertainty.

What frightens them is uncertainty that the presenter has apparently failed to notice.

Use the “What Must Be True?” Test

One of the best ways to make strategy intellectually honest is to expose its assumptions.

Bessemer describes a similar concept as a financial hypothesis: reduce an economic model to the small number of inputs that must work for the company to achieve its objectives.

Instead of presenting 47 metrics, ask:

What must be true for this investment to succeed?

For example:

1. At least 30% of eligible customers adopt the feature.

2. Adoption increases retention by at least two percentage points.

3. Serving cost remains below $4.50 per active customer.

4. Enterprise customers accept usage-based overages.

5. The feature does not materially increase support demand.

Suddenly the roadmap becomes testable.

You can now tell executives:

“The largest uncertainty isn’t engineering feasibility. It is willingness to pay. We propose spending $400,000 to resolve that uncertainty before committing the remaining $4 million.”

That is how capital allocators think.

And at the executive level, product strategy is capital allocation.

Managing Across: Separate Dissent From Decision Rights

Executive communication is not only upward.

The harder version is often sideways.

Engineering wants reliability.

Sales wants the enterprise deal.

Finance wants margin.

Marketing wants a launch date.

Legal would like everyone to stop having ideas.

How do you create alignment when rational people have conflicting incentives?

Netflix offers an unusually useful model.

Its published culture memo says significant decisions have an “informed captain”: one person responsible for the judgment call. Before deciding, that person is expected to seek opposing views—a practice Netflix calls “farming for dissent.” Once a decision is made, everyone commits to execution. Netflix’s culture memo

This separates three things companies constantly confuse:

Input

Many people should provide it.

Decision

Someone has to own it.

Commitment

Everyone needs to support execution afterward.

Amazon operates with a related principle: “disagree and commit.”

In his 2016 shareholder letter, Bezos argued that organizations should not wait for universal consensus and suggested that many decisions can be made with roughly 70% of the information one would ideally like. Bezos on high-velocity decision-making

His warning about unresolved conflict is particularly useful:

“‘You’ve worn me down’ is an awful decision-making process.”

Every product leader has experienced the alternative:

Meeting one.

Meeting two.

Slack thread.

Working session.

Steering committee.

Pre-steering-committee alignment meeting.

Meeting to prepare for the executive meeting.

At which point nobody remembers whether the original disagreement was about pricing or where to order lunch.

If teams fundamentally disagree, write the disagreement down.

For example:

Unresolved disagreement

Product recommendation: Launch to 100% of SMB customers in September.

Engineering position: Limit rollout to 25% until error rate falls below 0.5%.

Underlying disagreement: Product believes the cost of delayed learning exceeds reliability risk; Engineering believes current observability is insufficient to contain failures.

Decision owner: CTO.

Decision required by: August 15.

That paragraph can save three weeks of organizational interpretive dance.

Three Executive Communications Worth Studying

1. Brian Chesky’s 2020 Airbnb Memo: Strategy Before Actions

When COVID-19 devastated travel, Airbnb cut approximately 1,900 of its 7,500 employees—about 25% of the company.

Brian Chesky’s employee memo remains an unusually clear example of communicating a painful strategic decision. Read Brian Chesky’s Airbnb memo

Notice the structure.

First, reality:

Airbnb expected 2020 revenue to be less than half its 2019 level.

Then uncertainty:

The company did not know when travel would return, and it believed travel would return differently.

Then strategy:

Airbnb would refocus on its core hosting business.

Then portfolio consequences:

Transportation and Airbnb Studios would pause, while investment in Hotels and Lux would be reduced.

Then operating principles.

Then implementation.

In other words:

Reality → interpretation → strategy → choices → execution.

That sequence matters.

Without the strategy, the cuts look arbitrary.

With the strategy, people can understand the logic even if they hate the outcome.

Product leaders should use the same structure when killing products, removing features or reallocating teams.

Never say:

“We deprioritized Project Falcon because of capacity constraints.”

Say:

“We are concentrating FY27 investment on enterprise retention. Falcon primarily drives new SMB acquisition, so continuing it would consume two squads while contributing little to our highest-priority objective. We therefore recommend stopping development after the current release.”

Now the roadmap reflects strategy rather than appearing to have been attacked by a random-number generator.

2. Satya Nadella: Strategic Compression

When Satya Nadella became Microsoft CEO in 2014, he wrote:

“Our industry does not respect tradition — it only respects innovation.”

More importantly, his early communications repeatedly compressed Microsoft’s strategic direction around becoming a productivity and platform company for a “mobile-first and cloud-first world.” Nadella’s first-day Microsoft memo

You can debate the language—“mobile-first and cloud-first” contains the mathematical curiosity of having two firsts—but strategically it did something important.

It became a filter.

Good strategy communication allows thousands of people to independently answer:

Does this fit?

A product strategy nobody can repeat is barely a strategy.

3. Sequoia’s Board Structure: Highlights, Lowlights and Help

Sequoia recommends that board updates include:

• highlights,

• lowlights or challenges,

• where management needs help,

• financial performance,

• sales performance,

• product engagement,

• product delivery,

• customer experience,

• roadmap and organizational issues.

The underrated item is lowlights.

Executives do not build trust by making every metric green.

They build trust by demonstrating that they detect bad news before senior management does.

A VP-level product update might say:

Yellow: Enterprise activation reached 61% versus a 70% target. The primary gap is implementation time, not product adoption after launch. We are moving one infrastructure squad to provisioning automation and expect the first measurable improvement by October.

That sentence communicates:

• the problem,

• magnitude,

• diagnosis,

• intervention,

• timing.

No melodrama.

No metric cosmetics.

No “great progress with some exciting opportunities to optimize.”

Sometimes the metric is bad.

It will survive being called bad.

How to Build an Executive Deck That Doesn’t Become a Hostage Situation

A strong executive deck is usually much smaller than the appendix behind it.

Try this sequence.

Slide 1: Recommendation

A sentence, not a topic.

Bad:

Enterprise Strategy

Better:

Move 40% of FY27 product capacity to enterprise onboarding; expected payback is 18–24 months.

Slide 2: Why Now?

Three facts maximum.

What changed?

Slide 3: Economics

Show:

• investment,

• expected return,

• range,

• major assumptions,

• payback period.

Do not use financial precision you do not possess.

“$13,742,219 of incremental ARR” on a three-year innovation forecast does not make you look rigorous.

It makes Excel look overconfident.

Ranges are your friend.

Slide 4: Options

Show the real alternatives.

Include “do nothing” when it is credible.

Slide 5: Customer Evidence

Not 17 quotes.

Show the two or three observations that materially change the decision.

Slide 6: Risks

Include:

• probability,

• impact,

• mitigation,

• leading indicator.

Slide 7: Decision and Next Steps

Exactly what are you asking the room to decide?

By when?

Who owns execution?

Everything else goes in the appendix.

And your appendix should be enormous if the decision is important.

This is another paradox of executive communication:

The visible presentation gets shorter as the invisible preparation gets deeper.

Prepare for Questions, Not Your Speech

When presenting to executives, your slides are not the meeting.

The questions are the meeting.

If you have 30 minutes, assume you may get five uninterrupted minutes.

Then prepare for interrogation.

For a product investment, I would expect questions such as:

CFO

• What happens to gross margin?

• What is the payback period?

• What would we stop funding?

• What assumptions drive the model?

• What happens in the downside case?

CTO

• What technical debt does this create?

• What architectural dependency are we accepting?

• What breaks at 10× scale?

• Why build rather than buy?

CRO

• Which segment buys this?

• Has Sales validated willingness to pay?

• Will it shorten or lengthen the sales cycle?

• Which deals have we actually lost because we lack it?

CEO

Usually some unpleasantly simple version of:

• Why now?

• Why us?

• Why this?

• Why not the other thing?

• How will we know you’re right?

If those questions frighten you, that is useful information.

It means the memo is not finished.

What Changes When AI Can Write the First Draft?

There is a 2026 wrinkle to all of this.

Writing is becoming cheaper.

Reasoning is not.

Anyone can now turn messy meeting notes into something resembling a polished strategy memo in minutes.

That makes surface professionalism less valuable, not more.

The executive advantage shifts toward:

• asking the right question,

• knowing which evidence matters,

• identifying hidden assumptions,

• understanding economics,

• distinguishing reversible from irreversible decisions,

• exposing disagreement,

• anticipating second-order effects.

AI can make a bad strategy memo beautifully grammatical.

This is progress of a sort.

Amazon’s lesson therefore becomes even more relevant: the value of the memo is not the prose. It is the thinking required to make the prose withstand attack.

The PM of the AI era should use AI aggressively for summarizing research, testing counterarguments, finding gaps, restructuring drafts and generating scenarios.

But before presenting anything consequential, ask:

“If the CEO challenges my core assumption in the first two minutes, do I actually understand the answer?”

If not, another round of font adjustments will probably not save you.

The Executive Communication Test

Before sending your next memo or walking into an executive review, check whether an intelligent person who knows little about the project could answer these questions after five minutes:

1. What exactly is happening?

Not the project description.

The business situation.

2. Why does it matter?

Revenue?

Margin?

Retention?

Risk?

Strategic position?

Customer value?

3. Why now?

What changed?

4. What are the choices?

Real choices, not one recommendation accompanied by two straw men wearing fake moustaches.

5. What do you recommend?

Say it.

6. What must be true for you to be right?

Expose assumptions.

7. What might make you wrong?

Expose risk.

8. What do you need from the executive?

Money?

Headcount?

A decision?

Escalation?

Air cover?

Nothing is more awkward than reaching the end of an executive presentation and discovering nobody knows why they were invited.

The Real Promotion From PM to Product Executive

The transition from product manager to product executive is often described in terms of scope.

You manage more products.

More teams.

More managers.

Larger budgets.

That is true, but incomplete.

A deeper transition occurs in how you process complexity.

A PM is often rewarded for discovering information.

A senior PM is rewarded for synthesizing it.

A Director is rewarded for aligning organizations around it.

A VP is rewarded for turning ambiguity into decisions.

That is why great executive communication feels different.

It does not sound more impressive.

It sounds clearer.

The writer has already wrestled with the contradictions.

The ugly assumptions are visible.

The alternatives are legitimate.

The economics are attached.

The disagreement has an owner.

The recommendation appears at the beginning rather than emerging triumphantly after 47 slides like the winner of a corporate talent show.

Executives rarely need you to make the situation look simple.

They need you to make the complexity manageable.

That is the real purpose of a memo.

That is the real purpose of an executive deck.

And that is what “managing up” looks like when you stop thinking of it as stakeholder theatre and start treating it as one of the core jobs of product leadership:

Create the conditions in which good decisions can happen faster.

Everything else is presentation.

An AI product can have terrific engagement while giving people incorrect answers. It can achieve a wonderful conversion rate while taking 18 seconds to respond. It can delight users with beautifully written nonsense. It can even improve its benchmark score while becoming less useful in production.

That is what makes AI product management fundamentally different from shipping another CRUD app with a chatbot-shaped hat.

Traditional product metrics still matter. Revenue is still revenue. Retention is still retention. Nobody gets to tell the CFO, “Our ARR fell 30%, but coherence improved 7.2 points.”

But those metrics are now lagging indicators of something deeper. Before users retain, convert, recommend, or pay, an AI product must consistently answer three questions:

1. Can I trust what it tells me?

2. Did it actually help me?

3. Did it help me fast enough?

That gives us what I think of as the new PM Trinity:

Hallucination. Helpfulness. Latency.

Or, in less ML-flavored language: truth, utility, and speed.

The challenge is that these metrics are not independent. Improving one can damage another. More reasoning may improve accuracy but increase latency. Aggressive refusal policies may reduce hallucinations while destroying usefulness. Shorter answers may arrive faster but omit critical context. Longer answers may seem more impressive while creating more opportunities to invent things.

Welcome to AI product management, where every optimization comes with a small complimentary trade-off hiding behind it.

Why DAU Is No Longer Enough

Suppose you launch an AI research assistant.

Within six months:

• weekly active users grow 40%;

• session length increases 25%;

• paid conversion rises from 4% to 6%;

• users submit more prompts per session.

Celebrations occur. Slack fills with rocket emojis. Someone suggests ordering cupcakes.

But imagine that users are submitting more prompts because the first answers are unreliable. Session length is rising because people must repeatedly correct the assistant. And conversion is improving because power users desperately need the product despite its flaws.

Your dashboard says engagement.

Your users may be experiencing friction.

Generative AI introduces a peculiar measurement problem because the product behavior itself is probabilistic. Traditional software generally behaves deterministically: press the Save button and, bugs notwithstanding, you expect Save to do the same thing tomorrow.

Ask an LLM the same question twice and you may get two different answers.

That means PMs must measure not merely whether people use the product, but the quality distribution of what the product produces.

And averages are particularly dangerous.

If 99% of responses are correct but the remaining 1% includes fabricated legal citations, incorrect medical instructions, or imaginary financial regulations, an executive dashboard showing “99% quality” may be technically accurate and operationally insane.

The right AI dashboard therefore starts one level below engagement.

Metric 1: Hallucination — Measure Wrongness, Not Just Accuracy

The term “hallucination” is slightly unfortunate because it makes the behavior sound mysterious. NIST prefers the word confabulation, defining it in its Generative AI Risk Management Profile as systems generating and confidently presenting “erroneous or false content.” (NIST Publications)

That distinction matters.

A hallucination is not simply “the model failed a benchmark question.”

Consider these three answers:

A: “The answer is 47.”

B: “I’m not certain, but I believe the answer may be 47.”

C: “I don’t have enough reliable information to answer that.”

If the correct answer is 83, treating A, B and C as equivalent failures produces terrible incentives.

OpenAI made this point explicitly in its research on why language models hallucinate: many benchmarks reward guessing rather than uncertainty. Its SimpleQA example is striking. One model achieved 24% accuracy versus another model’s 22%—apparently better. Yet its error rate was 75%, compared with 26% for the more cautious model, largely because the latter abstained much more often. (OpenAI)

As the researchers put it:

“Errors are worse than abstentions.”

That should probably be taped above every AI PM’s monitor.

Stop asking, “What is our hallucination rate?”

There is rarely one meaningful hallucination rate.

Instead, break factual quality into several dimensions.

1. Claim-level factual error rate

Break responses into atomic verifiable claims:

False claims / total verifiable claims

This prevents one enormous response containing six factual mistakes from being treated exactly the same as a short response containing one.

Arena’s July 2026 Factuality in the Arena study does exactly this at enormous scale. Arena says it evaluated more than 2 million claims across roughly 170,000 battles. The marginal true-claim rate was 87% in its Text Arena and 89% in Search Arena. (Arena AI)

The important insight is not the exact percentages—they represent Arena’s particular traffic and methodology.

It is the unit of measurement.

The response is not the atomic unit of truth.

The claim is.

2. Response-level hallucination incidence

Users experience responses, not spreadsheets full of claims.

So also measure:

Responses containing ≥1 material factual error / factual responses

This catches an uncomfortable product reality: a response that is 95% correct may still be unusable if the incorrect 5% is important.

3. Severity-weighted hallucination rate

Now introduce risk.

A hallucinated restaurant opening hour and a hallucinated drug dosage are both factual errors. They are not remotely equivalent product failures.

Create severity classes, for example:

Severity

Example

Product response

S0

Cosmetic wording issue

Log

S1

Minor incorrect fact

Monitor

S2

Material error affecting task

Investigate

S3

High-stakes financial/legal/medical error

Immediate review

S4

Error capable of causing serious harm

Stop-ship / incident

Your headline metric should heavily weight S3 and S4 failures.

Otherwise your organization will eventually congratulate itself because the model became better at remembering movie release dates while occasionally inventing tax law.

4. Groundedness

For RAG systems, ask a slightly different question:

Does the answer actually follow from the retrieved sources?

This is not identical to factual accuracy.

A claim may happen to be true while still being unsupported by the documents the model was supposed to use.

Microsoft’s current AI evaluation framework therefore separates groundedness, relevance, task adherence, tool accuracy and other dimensions rather than pretending “quality” is a single number. (Microsoft Learn)

That is the right instinct.

5. Calibration and appropriate abstention

Sometimes the best AI answer is:

“I don’t know.”

Or:

“I need more information.”

Or:

“I can answer generally, but you should verify this detail.”

OpenAI’s hallucination research argues that evaluations should penalize confident errors more severely than uncertainty. (OpenAI)

So measure whether confidence matches correctness.

An AI that knows what it doesn’t know is often more valuable than one that knows slightly more but believes it knows everything.

There is a human equivalent. He is usually sitting beside you at a dinner party.

Metric 2: Helpfulness — The Danger of Beautiful Nonsense

Now we hit the harder metric.

What exactly is “helpful”?

Correctness alone certainly isn’t enough.

Imagine asking:

“Help me write a polite email declining this meeting.”

Model A produces:

“Decline meeting.”

Perfectly factual.

Spectacularly useless.

Model B writes a thoughtful two-paragraph response matching your tone and context.

No factual benchmark can distinguish those products properly.

Helpfulness therefore measures something closer to:

Did the AI successfully move the user toward the outcome they wanted?

The industry increasingly uses human preference as one proxy. Arena, for example, reported in June 2026 that its platform had accumulated more than 82 million human votes across hundreds of millions of conversations. Its evaluation model is built around people comparing AI outputs and choosing which response they prefer. (Arena AI)

That is enormously useful.

It is also insufficient.

Preferred does not necessarily mean correct

Arena itself recently demonstrated the problem.

When it compared factuality scores with human-preference scores, it found only a weak positive correlation. Its researchers observed that long, comprehensive answers may win preference votes while simultaneously introducing more factual errors. (Arena AI)

That should make every PM suspicious of a generic “AI quality score.”

Users reward:

• confident language;

• polished formatting;

• comprehensiveness;

• empathy;

• decisiveness;

• the appearance of expertise.

Unfortunately, confidence and expertise are merely casual acquaintances.

OpenAI discovered a related evaluation problem in HealthBench. Longer responses could earn better rubric scores simply because they had more opportunities to satisfy scoring criteria. Its August 2026 GPT-5.6 evaluation report therefore includes length-adjusted HealthBench scores. (OpenAI Deployment Safety Hub)

In other words:

Verbosity can game helpfulness metrics.

Who knew artificial intelligence would eventually discover the management-consulting business model?

Measure helpfulness in layers

A serious AI product should combine at least four signals.

Layer 1: Task completion

Did the user achieve the desired result?

Microsoft’s agent evaluation framework now explicitly measures task completion, task adherence, intent resolution and navigation efficiency. (Microsoft Learn)

For an AI coding tool:

• Did the code compile?

• Did tests pass?

• Did the bug disappear?

For customer support:

• Was the issue resolved?

• Did the user reopen the ticket?

• Was escalation required?

For an AI scheduling agent:

• Was the correct meeting actually scheduled?

The closer your metric gets to the real-world outcome, the better.

Layer 2: Human preference

Run blind pairwise evaluations:

Candidate vs. current production model

Ask evaluators:

Which response better accomplishes the user’s goal?

Pairwise comparison is usually easier and more reliable than asking humans whether a response deserves 7.3 out of 10.

Anthropic has long used this style of evaluation and has also warned that there is an “inherent tension between helpfulness and harmlessness”. (Anthropic)

That tension generalizes.

More helpful may mean less cautious.

More concise may mean less complete.

More creative may mean less grounded.

Welcome back to the trade-off factory.

Layer 3: Rubric-based quality

Define product-specific dimensions.

A generic assistant might use:

• relevance;

• correctness;

• completeness;

• instruction following;

• clarity;

• tone;

• conciseness.

A legal assistant might add citation validity.

A coding assistant might add executability.

A medical information product might add clinical appropriateness and uncertainty communication.

Do not copy someone else’s eval rubric simply because it looks scientific.

Your evaluation schema is effectively a coded definition of what your company believes “good” means.

Layer 4: Production behavior

Finally, observe what users actually do.

Useful signals include:

• thumbs-up/down;

• copy rate;

• answer acceptance;

• regeneration rate;

• immediate reformulation rate;

• undo rate;

• escalation rate;

• abandonment after answer;

• successful downstream action.

But interpret them carefully.

A user copying an incorrect answer is not success.

It may actually be your scariest failure.

The LLM-as-Judge Trap

At production scale, humans cannot manually evaluate every response.

So teams increasingly use one model to grade another.

This is powerful, cheap and slightly circular.

Google’s Vertex AI evaluation guidance makes an important recommendation: compare model-generated judgments against human ratings and calculate whether the judge actually agrees with people. (Google Cloud Documentation)

That is the correct workflow.

Do not simply announce:

“GPT-Whatever rated our feature 4.8/5.”

Congratulations. A robot has given another robot Employee of the Month.

Instead:

1. Build a high-quality human-labeled dataset.

2. Define an explicit rubric.

3. Run the automated judge.

4. Measure agreement against humans.

5. Inspect disagreement cases.

6. Recalibrate the evaluator.

7. Continue human audits in production.

LLM judges are scaling infrastructure, not ground truth.

Metric 3: Latency — Faster Is Better, Except When It Isn’t

Latency seems simpler.

Surely lower = better.

Not quite.

OpenAI’s latency guidance notes that response time is strongly influenced by model choice and the amount of generated output. Its service guidance recommends examining metrics such as time to first token (TTFT), total request time and token generation velocity, and looking at percentile distributions rather than averages. (OpenAI Help Center)

That gives PMs at least four latency metrics:

Time to first token

How long before the product visibly starts responding?

This often dominates perceived responsiveness in streaming interfaces.

Time to useful information

More interesting.

Maybe token one is:

“Certainly!”

Tokens 2–64 are an enthusiastic recap of the question.

The useful answer arrives at second 8.

Congratulations on your 700-millisecond TTFT.

Time to completion

Critical when the output must finish before anything useful can happen—for example structured extraction, an agent action or executable code.

P95 and P99 latency

Never manage AI latency using averages alone.

If nine users receive an answer in 2 seconds and one waits 30 seconds, your average is 4.8 seconds.

Nobody met Mr. Average.

The tenth user met rage.

But faster can actually feel worse

Here is where AI latency becomes fascinating.

A 2026 CHI study, The Impact of Response Latency and Task Type on Human-LLM Interaction and Perception, experimentally varied time-to-first-token latency between 2, 9 and 20 seconds.

Counterintuitively, participants experiencing the 2-second response sometimes rated outputs as less thoughtful and less useful than those experiencing longer delays. Participants apparently interpreted some delay as evidence that the AI was “thinking.” (DOI)

That does not mean your roadmap should include:

Q4 Initiative: Make Product Slower.

Other research points the opposite direction. A 2025/26 chatbot study found that longer delays could lower satisfaction, although typing indicators reduced the damage. The research suggests perceived social presence changes how users interpret waiting. (Taylor & Francis Online)

And research on LLM-powered conversational agents found that latency above roughly four seconds significantly degraded experience in its particular experimental setting. (DOI)

The conclusion is not “four seconds good, five seconds bad.”

The conclusion is more useful:

Latency is contextual and psychological.

A user expects autocomplete to feel instantaneous.

They will tolerate longer waits for:

• deep research;

• complex code generation;

• financial analysis;

• image/video generation;

• multi-step agents.

The correct latency SLO therefore depends on user intent, not merely infrastructure.

The Real Metric: Trusted Task Success

Now we can bring the Trinity together.

Most teams will be tempted to create something like:

AI Quality Score = 40% helpfulness + 40% factuality + 20% latency.

Please don’t.

Weighted averages allow absurd compensation.

Imagine:

• 99/100 helpfulness;

• 30/100 factuality;

• 100/100 latency.

A sufficiently enthusiastic spreadsheet can still produce a respectable composite number.

But a spectacularly fast wrong answer does not become good because the spinner disappeared quickly.

For consequential AI products, some dimensions should behave as constraints, not interchangeable points.

I prefer a north-star concept I call:

Trusted Task Success Rate

The percentage of eligible AI interactions in which the user’s task is successfully completed, without a material factuality failure, within an acceptable experience window.

Conceptually:

Trusted Task Success = Task Success × Trust Gate × Experience Gate

Not because the arithmetic must literally be multiplication, but because failure of a critical gate should invalidate the interaction.

For example:

An AI mortgage assistant that gives a gorgeous answer in 1.4 seconds but fabricates the interest rate has not achieved 85% success.

It has achieved zero success with excellent typography.

What an AI Product Scorecard Should Actually Look Like

Here is an illustrative production dashboard. The thresholds are examples—not universal industry standards.

Dimension

Metric

Why it matters

North Star

Trusted Task Success Rate

Captures useful, trustworthy outcomes

Hallucination

Claim factual-error rate

Measures atomic truthfulness

Hallucination

Responses with material error

Reflects user exposure

Hallucination

S3/S4 critical error rate

Protects high-stakes use

Hallucination

Appropriate abstention rate

Rewards calibrated uncertainty

Helpfulness

Task completion rate

Measures actual outcome

Helpfulness

Pairwise win rate vs. production

Detects quality improvement

Helpfulness

User acceptance/copy/action rate

Observes real behavior

Helpfulness

Reformulation/regeneration rate

Detects hidden dissatisfaction

Latency

P50 TTFT

Typical perceived responsiveness

Latency

P95 TTFT

Tail experience

Latency

P95 completion time

Full workflow performance

Latency

Abandonment during generation

Measures latency pain directly

Economics

Cost per trusted successful task

Connects AI quality to P&L

Business

Retention / conversion / revenue

Confirms quality creates value

Notice what happened.

DAU did not disappear.

Neither did conversion.

They moved downstream.

That is where they belong.

Build an Evaluation Flywheel, Not a Quarterly Benchmark

The bigger organizational mistake is treating evaluation as QA performed shortly before launch.

AI evaluation should operate continuously.

Step 1: Build the golden dataset

Collect representative prompts covering your major jobs-to-be-done.

Include:

• common tasks;

• difficult edge cases;

• multilingual queries;

• ambiguous requests;

• historical failures;

• adversarial prompts;

• high-value customer workflows.

And keep refreshing it.

A static benchmark eventually becomes a school exam whose answers everyone has memorized.

Step 2: Slice everything

Never report only an aggregate quality score.

Segment by:

• task;

• customer cohort;

• language;

• model;

• prompt length;

• retrieval/no retrieval;

• tool use;

• risk class;

• device;

• geography;

• conversation depth.

OpenAI’s August 2026 GPT-5.6 documentation makes a particularly important measurement warning: its challenging hallucination sets are intentionally designed around difficult and historically failure-prone cases, so the reported values should not be interpreted as production prevalence. (OpenAI Deployment Safety Hub)

That principle applies to your product too.

Your adversarial eval rate and your real-world incidence rate answer different questions.

Track both.

Step 3: Mine production failures

Your best eval set is tomorrow’s collection of yesterday’s embarrassing incidents.

Take:

• thumbs-down responses;

• regenerated answers;

• support tickets;

• escalations;

• factuality complaints;

• abandoned agent workflows;

• human overrides.

Turn them into regression tests.

Every serious production failure should leave behind an eval.

That is how the product gradually develops institutional memory.

Step 4: Compare releases pairwise

Before shipping a prompt, model or retrieval change, compare the candidate against production.

Do not merely ask:

“Did candidate score 84?”

Ask:

“Does candidate beat production on the tasks our users actually perform—and where does it regress?”

Pairwise comparison makes changes legible.

Step 5: Validate offline with online behavior

Offline evals tell you whether the system should be better.

Experiments tell you whether users agree.

A new model may score higher offline but:

• respond more slowly;

• sound more robotic;

• refuse too often;

• generate unnecessarily long answers;

• increase costs;

• reduce successful workflow completion.

AI PMs must bridge both worlds.

Benchmark optimization without product telemetry is just competitive Pokémon for machine-learning teams.

Fun, perhaps. Not a strategy.

The Trinity Has Two Important Exceptions: Safety and Cost

At this point you may reasonably object:

“What about safety?”

Or:

“What about cost?”

Correct.

The Trinity is not intended to represent every metric in an AI business.

It represents the three central dimensions of user-perceived AI performance.

Safety is better treated as a non-negotiable guardrail.

Cost belongs in the economic layer.

For safety-critical categories, you should establish hard release thresholds independently of helpfulness. Anthropic’s observation about the tension between helpfulness and harmlessness matters here: a system that refuses everything may be extremely safe and completely worthless. (Anthropic)

Meanwhile cost should evolve from:

cost per request

toward:

Cost per trusted successful task

Suppose Model A costs $0.02 per interaction and completes 40% of tasks correctly.

Model B costs $0.05 and completes 90%.

Model A looks cheaper on the infrastructure dashboard.

Model B may be dramatically cheaper per successful outcome.

This is where AI product management finally reconnects with economics.

Tokens are not value.

Completed work is value.

Trust Is the Compounding Metric

There is one final reason to care about this framework.

AI quality failures compound.

A conventional UI bug often produces an obvious failure. The button does not work. The user knows it does not work.

Hallucinations are more dangerous because the interface may continue behaving beautifully.

The sentence is grammatical.

The formatting is pristine.

The citations look plausible.

The error may be invisible.

That creates a peculiar form of product debt: trust debt.

A large 2025 University of Melbourne/KPMG survey covering more than 48,000 people in 47 countries found that 66% regularly used AI, yet only 46% were willing to trust AI systems. Even more concerning, 66% reported relying on AI output without evaluating its accuracy, while 56% reported mistakes in their work associated with AI use. The global trust study puts numbers around the contradiction at the heart of the market: adoption can rise faster than trust. (KPMG)

Professor Nicole Gillespie, who led the research, put it succinctly:

“The public’s trust of AI technologies… is central to sustained acceptance and adoption.”

That is why trust should not be treated as branding.

It is product infrastructure.

The PM’s Job Has Changed

The old product-management question was often:

“Will users use this?”

The AI-era question is harder:

“Will users successfully use this, receive a reliable result, understand when the system is uncertain, and get that result quickly enough to come back?”

That changes roadmap conversations.

Instead of:

“Should we upgrade to Model X?”

ask:

“Which model maximizes trusted task success for this workload at acceptable latency and cost?”

Instead of:

“Prompt V7 scored 4% higher.”

ask:

“Which user segments improved, which failure modes regressed, and did production behavior confirm the eval?”

Instead of:

“Hallucinations dropped.”

ask:

“Which hallucinations dropped? In what tasks? At what severity? And did the model simply learn to refuse more often?”

Instead of:

“Latency is down 20%.”

ask:

“Did users notice, and did the faster configuration compromise answer quality?”

That is the conceptual shift.

AI product management is not about choosing the smartest model.

It is about engineering the best system-level trade-off among truth, usefulness and speed.

The New PM Trinity

If I were running an AI product review tomorrow, I would want three charts before looking at DAU.

1. Hallucination

How often are we confidently wrong—and how serious are those errors?

Track claims, material failures, severity, groundedness and appropriate abstention.

2. Helpfulness

Did the user actually accomplish what they came to do?

Track task success, pairwise preference, rubric performance and behavioral evidence.

3. Latency

How long does useful value take to appear?

Track TTFT, time-to-useful-information, completion time, tail latency and abandonment.

Then connect all three with:

Trusted Task Success

Because the ideal AI interaction is not merely accurate.

It is not merely helpful.

It is not merely fast.

It is helpful enough to matter, truthful enough to trust, and fast enough that the user doesn’t open another tab while waiting.

That is the new product-quality bar.

DAU can come afterward.

And yes, Finance may still ask about gross margin.

Some traditions survive every technological revolution.

1. Take an impressive foundation model.

2. Put a pleasant interface around it.

3. Add a system prompt.

4. Charge $29 a month.

5. Put “AI-powered” on the homepage in a gradient font.

This worked surprisingly well.

It is also becoming a terrible strategy.

The problem is not that foundation models have stopped improving. Quite the opposite. They are improving so quickly that access to raw intelligence is becoming less scarce. According to Stanford’s [2026 AI Index] 2026 AI Index technical-performance data, four leading model providers were clustered within only 25 Elo points of one another on the Arena leaderboard by March 2026. Anthropic, xAI, Google, and OpenAI were all operating in roughly the same elite performance neighborhood.

Meanwhile, price-performance has collapsed. Stanford previously calculated that the cost of querying a model performing at roughly GPT-3.5 level fell from $20 per million tokens in November 2022 to $0.07 by October 2024—a more than 280-fold decrease. Stanford AI Index research on inference costs (Stanford HAI)

This does not mean models are literally commodities. Frontier differences still matter. Stanford found that the best closed model was 3.3% ahead of the best open model in March 2026, after the gap had narrowed dramatically in 2024. Certain models remain noticeably better at coding, reasoning, multimodal work, latency, or cost.

But the strategic question is not whether Model A beats Model B this Tuesday.

It is whether that advantage still belongs to you next Tuesday.

If your AI application’s primary advantage is “we use the smartest model,” your competitive advantage has the approximate shelf life of a ripe avocado.

The companies building genuinely defensible AI products are moving elsewhere. Their moats are emerging from proprietary learning loops, deeply accumulated context, workflow position, permissions, trust, distribution, and the ability to convert millions of interactions into a product that improves faster than competitors can copy it.

The foundation model matters.

It just increasingly isn’t the moat.

The first test: What happens if everyone gets your model tomorrow?

Product leaders should perform a brutally simple thought experiment.

Imagine that tomorrow morning every competitor receives access to the exact same model you use, at the exact same price, with roughly the same latency.

What remains?

If the answer is your prompt, you are in trouble.

If the answer is your UI, you may also be in trouble.

If the answer is “our prompt and our UI,” congratulations: you may have invented a slightly more attractive commodity.

The real question is what gets better specifically because customers use your product.

That distinction separates an AI feature from an AI moat.

A normal software product creates value when people use it.

A great AI product should create value and create information that makes future value easier to produce.

Think of the difference this way:

Weak loop:

User request → model response → user leaves.

Strong loop:

User request → proprietary context → model/agent action → observed outcome → feedback signal → improved retrieval, routing, workflow, memory, evaluation or automation → better next outcome.

The second system compounds.

That is where defensibility begins.

Moat #1: Proprietary data is overrated. Proprietary feedback loops are not.

“Proprietary data” has become the AI equivalent of “network effects” in startup pitch decks: everyone claims to have it, and remarkably few can explain exactly why it matters.

Having a database does not create a moat.

Having exclusive PDFs does not necessarily create a moat.

Dumping ten years of customer-support tickets into a vector database certainly does not guarantee a moat. Sometimes it guarantees an expensive way to retrieve obsolete refund policies.

The strategically valuable asset is high-signal data generated through usage that tells you whether the AI performed the task correctly.

Consider customer service.

Intercom says its Fin agent resolves an average of 76% of customer queries. Intercom’s description of Fin AI Agent But the more interesting part of the product is not merely the model answering questions. Intercom’s optimization system analyzes conversations Fin could not successfully answer and turns those failures into recommendations about missing content, missing customer data, or missing actions. Intercom’s Fin optimization system (Intercom)

That is much closer to a moat.

The failed interaction becomes training material for the product organization.

If thousands of customers encounter obscure support problems, Intercom can learn which knowledge structures, procedures and integrations improve resolution. The feedback is grounded in real work rather than benchmark theatre.

Salesforce is chasing a similar idea at much larger scale. As of its May 2026 fiscal Q1 report, Salesforce said Agentforce had delivered 3.8 billion “Agentic Work Units”—tasks completed by agents across its platform—and that Agentforce annual recurring revenue had reached $1.2 billion, up 205% year over year. Salesforce Q1 FY2027 results (Salesforce Investor Relations)

Tokens themselves are not particularly defensible.

The resulting graph of:

• which task was attempted,

• with which customer context,

• under which constraints,

• using which tools,

• whether the action worked,

• whether a human corrected it,

• and what happened afterward

can be extraordinarily valuable.

That is proprietary outcome data.

The four-question proprietary-data test

Before declaring something a “data moat,” ask:

1. Is the data exclusive?

Could competitors acquire approximately the same information from public sources?

2. Is it generated naturally through product usage?

A dataset that becomes richer every day is much more defensible than something you purchased once.

3. Does it contain outcome signals?

“User asked question X” is useful.

“User asked X, agent recommended Y, user rejected it, human changed Y to Z, and Z resolved the problem” is vastly more useful.

4. Does more data measurably improve the product?

If doubling your dataset barely changes accuracy, the dataset may be an asset, but it is probably not much of a moat.

The ideal AI flywheel therefore isn’t:

More users → more data.

It is:

More usage → more high-quality outcome signals → better decisions → better outcomes → more trusted usage.

The feedback loop is the moat.

The database is just where you keep it.

Moat #2: Personalization matters—but “fine-tune a model for every user” is usually the wrong mental model

One popular theory of AI defensibility goes something like this:

Every user trains their own personalized AI. Eventually their AI knows them so well that switching becomes painful.

The underlying idea is strong.

The implementation is often wrong.

Persistent personalization absolutely can create switching costs. But continuously training a separate foundation-model variant for every individual is usually slower, harder to govern, and less flexible than maintaining a rich user context layer.

For rapidly changing knowledge, retrieval and memory are often better tools.

OpenAI itself distinguishes between techniques such as retrieval-augmented generation, which can add relevant knowledge at inference time, and fine-tuning, which can shape behavior or improve performance on a specialized task. In May 2026, OpenAI even announced that it was winding down its existing self-service fine-tuning platform for new users while continuing other customization approaches. OpenAI’s model-customization and fine-tuning update (OpenAI)

Meanwhile, personalization in products increasingly looks like persistent memory.

OpenAI describes ChatGPT Memory as a way to remember relevant user information across conversations so people do not have to keep explaining the same context. OpenAI’s guide to ChatGPT personalization and memory (OpenAI)

That is strategically interesting because every additional interaction can increase the product’s contextual advantage.

Imagine two executive assistants.

Assistant A knows nothing about you.

Assistant B knows:

• your company,

• your team,

• your preferred writing style,

• your calendar patterns,

• which projects matter,

• which customers are sensitive,

• what “the Q3 issue” means,

• which meetings you dislike,

• how you normally communicate with your CEO,

• and that when you say “make this concise,” you mean four sentences rather than fourteen bullets and an inspirational quote from Steve Jobs.

Even if both assistants use the identical underlying model, their usefulness is no longer identical.

Switching away from Assistant B means rebuilding context.

That creates switching cost without deliberately imprisoning the customer.

The best personalization architecture may therefore combine:

Persistent memory + retrieval + preference learning + user feedback + selective model customization.

Fine-tuning still has legitimate uses, especially where companies possess substantial proprietary examples of a specialized task. OpenAI previously described a custom legal model developed with Harvey using the equivalent of roughly 10 billion tokens of domain material; according to OpenAI, the resulting system produced 83% more factual responses in its evaluation and was preferred by attorneys 97% of the time versus GPT-4. (OpenAI)

But that is very different from automatically fine-tuning “BobGPT” because Bob clicked thumbs-up six times last week.

Personalization is a moat.

Fine-tuning is merely one possible implementation detail.

Moat #3: Own the workflow, not merely the chatbot

One of the clearest lessons of 2026 is that the AI assistant itself is migrating into the existing software where work happens.

Microsoft is perhaps the strongest demonstration.

Microsoft 365 Copilot exceeded 30 million paid seats by June 30, 2026. Microsoft FY2026 fourth-quarter results

Why would enterprises pay Microsoft for AI when exceptionally capable general-purpose AI products already exist?

Because Microsoft owns context and workflow.

In an April 2026 earnings call, Satya Nadella said:

“Nearly every task depends on organizational context.”

Microsoft said the Work IQ layer grounding Copilot already spanned more than 17 exabytes of organizational data, including email, documents, meetings, SharePoint sites, roles and communications—and that Copilot-generated conversations and artifacts make that context richer over time. Microsoft FY2026 Q3 earnings discussion of Work IQ(Source)

That is considerably harder to clone than a chat window.

The same pattern explains GitHub Copilot.

By mid-2026 GitHub Copilot had evolved well beyond code completion into agents operating through repositories, pull requests, reviews, issues and actions. Microsoft reported 50 million GitHub Copilot users by FY2026 year-end. (Source)

The interesting moat isn’t that Copilot has access to a specific LLM.

In fact, Microsoft has deliberately moved toward multiple models. Earlier in 2026 it said the majority of GitHub Copilot users were leveraging more than one model. (Microsoft)

That is the point.

The application survives model substitution because the workflow remains.

GitHub owns:

repository history → permissions → branches → pull requests → CI/CD → code review → developer identity → deployment workflow.

The model becomes an interchangeable cognitive engine operating inside a far less interchangeable system.

This suggests an important product strategy rule:

Your AI layer should ideally become more valuable when better third-party models arrive.

If a competitor releases a breakthrough model next month and you can plug it into your system while preserving your customers’ data, context, workflows and feedback loops, excellent.

Their R&D just improved your product.

That is a much more pleasant situation than waking up to discover their new model is your product.

Moat #4: Integrations alone are becoming less defensible

At first glance, integrations look like a perfect AI moat.

Connect your assistant to Jira, Slack, Salesforce, GitHub, Gmail, Google Drive, Dropbox, SAP, Confluence, Workday and whichever enterprise system was apparently designed in 1998 and has been threatening to migrate to the cloud since 2014.

Eventually, surely, nobody can copy you.

Unfortunately, standards are attacking this moat too.

Anthropic introduced the Model Context Protocol in 2024 specifically to standardize how AI applications connect to tools and data. By December 2025 MCP had been contributed to the Linux Foundation’s Agentic AI Foundation and was being supported across major AI ecosystems. Linux Foundation announcement on MCP and the Agentic AI Foundation

Anthropic’s Mike Krieger described MCP as having become:

“the industry standard for connecting AI systems to data and tools.”

The Linux Foundation reported adoption across ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, VS Code and others. (Linux Foundation)

That is great for interoperability.

It is less great if your competitive strategy was “we built the Slack connector.”

So the integration moat is moving upward.

What matters is not simply whether you can access Salesforce.

What matters is whether you understand:

• what a particular Salesforce object means,

• which records matter to this employee,

• which customer is strategically important,

• what permissions apply,

• which actions are allowed,

• what approval chain must run,

• which historical actions succeeded,

• and whether an agent should update the record automatically or request human review.

The connector becomes infrastructure.

The semantic, permission and workflow layer above the connector becomes the differentiator.

Moat #5: Build a context graph competitors cannot reconstruct overnight

Glean provides one of the clearest examples of this strategy.

Its Enterprise Graph maps relationships among employees, projects, products, customers, processes and content. Glean also maintains personal graphs intended to understand an individual employee’s projects, collaborators, work patterns and preferences. Glean’s Enterprise Graph architecture (Glean)

Notice how different this is from traditional RAG.

Traditional retrieval asks:

Which documents resemble this query?

A richer context system asks:

Who is asking? What are they working on? Which project does this probably refer to? Which source is authoritative? Who has access? Which related customer, team and deadline matter? What actions normally follow?

That difference becomes more important as base-model intelligence rises.

Paradoxically, better models can increase the value of proprietary context.

A mediocre model may fail regardless of the data you feed it.

A brilliant model can exploit subtle contextual relationships.

So as models improve, companies with the richest context layers may gain disproportionately.

The model providers supply reasoning.

The application supplies reality.

That division of labor may define much of the next generation of enterprise AI.

Moat #6: Trust, permissions and evaluation are boring—and therefore valuable

AI founders understandably prefer discussing autonomous agents to discussing audit logs.

Nobody has ever raised a Series A by walking onto the stage and screaming:

“ROLE-BASED ACCESS CONTROL!”

But enterprise AI eventually encounters an inconvenient institution known as the real world.

Models still make mistakes.

Stanford’s 2026 AI Index found that agents on OSWorld, a benchmark involving computer tasks, had improved from roughly 12% accuracy to 66.3%—remarkable progress, but still approximately one failed attempt in three. Stanford 2026 AI agent benchmark data (Stanford HAI)

That makes governance part of the product.

For a sales email, an error may be embarrassing.

For an agent moving money, modifying production infrastructure, approving insurance claims or changing medical records, “the AI got creative” is not an acceptable postmortem.

Defensible systems therefore accumulate infrastructure around:

• authorization,

• identity,

• auditability,

• human approval,

• confidence thresholds,

• rollback,

• policy enforcement,

• evaluation suites,

• domain-specific safety checks,

• provenance,

• and monitoring.

These capabilities rarely generate viral demo videos.

They do generate procurement approvals.

And once an AI system becomes trusted enough to execute meaningful actions, replacing it becomes significantly harder.

Trust is a switching cost.

Moat #7: Distribution is still a moat, even if VCs find it less exciting than transformers

There is another uncomfortable truth in AI strategy:

Sometimes the best AI company does not win.

The company already sitting in front of the customer does.

Salesforce offers a useful illustration. In Q1 FY2027, more than half of Agentforce and Data 360 bookings came from existing customers. Salesforce’s May 2026 Agentforce results (Salesforce Investor Relations)

This is distribution leverage.

A startup may have a marginally superior agent. Salesforce already has:

• customer records,

• enterprise contracts,

• administrators,

• security configuration,

• workflows,

• sales teams,

• procurement approval,

• APIs,

• partner ecosystems,

• and executives who would rather upgrade a contract than conduct another nine-month vendor review.

Microsoft enjoys the same advantage.

This does not mean startups cannot win. It means a startup competing with an incumbent must usually build a much larger product advantage than “our answers are 8% better.”

Startups need asymmetry.

Perhaps they own a previously ignored workflow.

Perhaps they acquire data incumbents cannot.

Perhaps they radically outperform on outcome economics.

Perhaps they create a new distribution channel.

Perhaps they specialize so deeply that the horizontal platform cannot match them.

But ignoring distribution because “AI changes everything” is dangerous.

AI changes a lot.

Procurement departments remain surprisingly resilient.

Moat #8: Move from selling intelligence to selling outcomes

Perhaps the most important commercial shift is from pricing AI according to access toward pricing it according to work accomplished.

Intercom charges for Fin based on successful outcomes, starting at $0.99 for certain resolutions and completed procedures rather than simply charging for raw model tokens. Intercom’s outcome-based Fin pricing (Intercom)

Salesforce has created its “Agentic Work Unit” metric to describe tasks executed by agents.

And when Microsoft reported its FY2026 results, Nadella described the goal as helping customers:

“turn tokens into business results.”

(Source)

That phrase captures where product strategy is going.

Nobody actually wants tokens.

Nobody wakes up thinking, You know what would improve my Thursday? Four million additional tokens.

Customers want:

• a support ticket resolved,

• a pull request completed,

• an invoice reconciled,

• a qualified lead,

• a report created,

• an insurance claim processed,

• a meeting prepared,

• or a software bug fixed.

The closer your economics are tied to those outcomes, the more proprietary outcome data you collect.

And that creates another loop:

Outcome-based pricing → incentive to improve outcomes → better instrumentation → richer outcome data → better automation → improved economics.

Now we are building a moat.

The AI moats that are probably fake

Product teams should be particularly suspicious of five commonly claimed advantages.

“Our prompt engineering”

Prompts matter enormously to product quality.

They are not generally durable competitive barriers.

Prompt engineering is seasoning, not a castle wall.

“We use Model X”

Unless you have genuinely exclusive access, so does everyone else.

And increasingly, serious products deliberately support multiple models.

“We have RAG”

Congratulations on joining 2024.

Retrieval is architecture, not differentiation.

The differentiation is the proprietary knowledge architecture, ranking signals, permissions, feedback loops and context that make your retrieval better.

“We have lots of integrations”

Useful, yes.

But open standards such as MCP are steadily reducing the cost of reproducing basic connectivity.

“We have proprietary data”

Which data?

How exclusive is it?

Does it improve outcomes?

Does it become more valuable through use?

Can competitors purchase something similar?

If nobody can answer those questions, you may have proprietary storage bills.

A defensibility scorecard for AI product managers

When evaluating an AI roadmap, I would score every major feature on five dimensions.

Question

Weak

Strong

Does usage generate proprietary information?

No

Every interaction produces useful outcome signals

Does the product improve from accumulated context?

Session-only

Persistent user/company context compounds

Does it become embedded in a workflow?

Separate chatbot

Executes inside a system of record/action

Would switching destroy accumulated value?

Easy export and restart

Significant context/workflow rebuilding required

Can competitors reproduce it with the same model?

Weekend prototype

Requires years of data, trust, distribution or workflow history

The objective is not to maximize switching pain.

The objective is to maximize accumulated customer value.

Those are different things.

Artificial lock-in makes customers angry.

Accumulated intelligence makes customers reluctant to leave because the product genuinely understands their work better.

The most defensible architecture may be surprisingly model-agnostic

There is a final implication that AI product leaders should take seriously.

Your architecture should assume that the best model will keep changing.

Stanford reports that frontier model leadership has moved repeatedly among companies and countries. Microsoft now exposes multiple models inside its own products. GitHub users increasingly move among models depending on the task. Glean advertises access to dozens of frontier and open models through its AI gateway. Glean’s multi-model AI Gateway(Stanford HAI)

That implies a modern AI product stack might look something like:

Model layer: replaceable.

Routing layer: proprietary.

Evaluation layer: proprietary.

Context and memory layer: proprietary.

Customer data graph: proprietary.

Workflow and action layer: deeply integrated.

Permissions and governance: accumulated.

Feedback and outcome data: compounding.

Distribution: difficult to reproduce.

Now an OpenAI release, Anthropic release, Gemini breakthrough or open-source leap is not an existential crisis.

It is an upgrade opportunity.

That is exactly where you want to be.

The real moat is the rate at which your product learns

AI has revived an old Silicon Valley temptation: confusing technical novelty with strategic defensibility.

The spectacular capability of foundation models makes that mistake particularly easy.

A brilliant model demo feels like magic.

But competitors can buy magic too.

The more durable question is whether your product develops advantages that competitors cannot obtain simply by increasing their API budget.

The strongest AI products will accumulate four things:

Context: They understand the customer, organization and task better over time.

Feedback: They know what actually worked.

Workflow position: They can act where economically valuable work occurs.

Trust: They have earned permission to perform increasingly consequential actions.

Everything else—including the model itself—should increasingly be treated as replaceable infrastructure.

Stanford reports that AI adoption reached 88% of surveyed organizations in 2025, while generative AI was already in use across at least one business function at a large majority of companies. Stanford’s 2026 AI economy research (Stanford HAI)

So the easy phase is ending.

Putting AI inside software is rapidly becoming table stakes.

The next competition is about whose AI learns fastest from proprietary reality.

That is the moat product teams should be designing.

Not a clever prompt.

Not a shiny chatbot.

Not a dependency on whichever model is winning the benchmark leaderboard this month.

Build the context nobody else has.

Capture the feedback nobody else sees.

Own the workflow where the value is created.

Make your product smarter every time someone uses it.

And if the foundation models become 10 times better and 10 times cheaper next year?

Even better.

Your moat should get wider.

Reality has been less Zen.

Slack added a direct sales force. Atlassian built enterprise sales capabilities around its famously self-service model. Figma hired its first salesperson only a few years after launching and eventually created Organization and Enterprise plans. Zoom grew a giant online business and a separate enterprise motion. The great product-led companies did not eliminate sales. They changed when sales enters the picture, what information sellers have when they arrive, and what job sales is expected to perform.

That distinction matters enormously for product managers.

Product-Led Sales, or PLS, is often presented as a GTM tactic: identify Product-Qualified Leads, throw them into Salesforce, and have an AE call them before lunch. But the better way to think about PLS is as a product system. The product must detect when individual experimentation has become organizational adoption, recognize when that organization is running into problems that self-service cannot elegantly solve, and hand the resulting context to a human who can help.

The product is no longer merely the thing being sold.

It becomes part of the sales infrastructure.

And that puts PMs squarely in the middle of the enterprise funnel.

The strange new B2B buyer: “Please leave me alone. Also, I need your help.”

The case for PLS begins with an apparent contradiction in modern B2B buying.

According to Gartner’s 2025 survey of 632 B2B buyers, 61% preferred an overall buying experience without a sales representative. Even more strikingly, 73% said they actively avoid suppliers that send irrelevant outreach. Gartner analyst Robert Blaisdell summarized the danger rather nicely:

“Bad prospecting actively damages relationships with potential customers.”

That should probably be printed above the door of every SDR bullpen.

Yet eliminating humans is not the answer either. (Gartner)

By 2026, another Gartner survey found that 69% of B2B buyers preferred using sales reps to validate AI-generated insights. Buyers used an average of seven information sources during a recent purchase, while 45% had used generative AI during the buying process. In other words, customers increasingly want to research independently—but they still want knowledgeable humans when risk, ambiguity or organizational complexity enters the deal. (Gartner)

McKinsey found a similar pattern in its 2024 B2B Pulse research across nearly 4,000 decision makers. Roughly one-third of customers preferred in-person interactions, one-third remote interactions and one-third digital self-service at any given stage. Even high-dollar purchases are increasingly comfortable online: some buyers reported willingness to conduct transactions worth $500,000 or more remotely. (McKinsey & Company)

The implication is not “sales is dead.”

It is that forced sales is dying.

The winning model increasingly looks like this:

Let the product handle discovery, education and proof of value. Introduce humans when humans can genuinely reduce friction.

That is Product-Led Sales.

PLS is not PLG with an SDR duct-taped to it

Pocus, one of the companies that helped popularize the term, defines Product-Led Sales as:

“A go-to-market approach that relies on existing users of the product to drive revenue.”

That revenue can come from initial conversion, expansion, cross-sell or upsell.

Early benchmark research showed how quickly hybrid models were becoming normal. In Pocus’s 2022 survey of more than 200 PLG companies, 49% already had a Product-Led Sales motion, 52% of sales teams were reaching out to Product-Qualified Leads, and 52% had signals that triggered human involvement for enterprise opportunities. Only 7% allowed customers to self-serve all the way onto enterprise licenses. A later 2023 benchmark covering more than 170 PLG companies found that more than half were using PLS and that blended self-service, sales-assist and enterprise motions had become the dominant pattern. (Pocus)

But there is an important trap here.

A mediocre PLS program simply replaces one kind of spam with another.

Traditional demand generation says:

“Someone downloaded our AI transformation ebook. CALL THEM.”

Bad PLS says:

“Someone clicked the export button six times. CALL THEM.”

Neither is particularly intelligent.

A good PLS system asks a different question:

What evidence suggests that this organization has experienced meaningful value, has a problem worth solving at greater scale, and would benefit from human assistance right now?

That is a much harder problem—and a much more interesting one for product management.

Figma shows what the model looks like when it works

Figma is almost a textbook illustration of the evolution.

Its product spread bottoms-up because collaboration was inherently viral: someone shared a Figma URL, another person opened it, another team joined, and adoption expanded before procurement necessarily knew what was happening.

But Figma did not conclude that salespeople were obsolete.

Its IPO filing explains that it hired its first salesperson in 2018, the same year it introduced an Organization plan. In 2022 it launched Enterprise, adding things such as advanced security, team workspaces and administrative capabilities.

More importantly, Figma disclosed that during 2024 and early 2025, roughly 70% of new Organization and Enterprise customers included at least one user who had previously belonged to a Professional-plan account. Approximately 70% of revenue during those periods came from Organization and Enterprise customers.

That is the PLS flywheel in unusually clear numbers:

individual adoption → team value → organizational spread → enterprise requirements → assisted expansion.

And the engine kept scaling. Figma’s 2025 Form 10-K reported 1,405 customers generating more than $100,000 in ARR at the end of 2025, up from 963 a year earlier—a 46% increase. Its net dollar retention rate reached 136%, while revenue grew 41% year over year. (SEC)

Figma explicitly describes two parallel purchasing paths: an “automated and highly efficient” self-service option and a direct sales process for setting up, upgrading and expanding accounts. (SEC)

That is the critical idea.

PLS is not a funnel that eventually replaces self-service. It is a routing system that decides which journey each customer needs.

Atlassian learned the same lesson from the opposite direction

Atlassian is especially interesting because its historical identity was almost aggressively anti-enterprise-sales.

Its early model revolved around transparent pricing, free trials and online purchasing. No armies of quota-carrying reps performing ceremonial PowerPoint demonstrations of Jira.

By 2025, however, Atlassian’s model had evolved.

Its 2025 Form 10-K describes a deliberately hybrid approach. New customers still land primarily through an automated self-service flywheel. But Atlassian says it increasingly relies on direct sales once a customer reaches sufficient scale, with sales focused on expanding into more teams, selling additional apps and moving accounts into higher-value editions. (SEC)

This is an important economic principle for PMs designing PLS systems:

Sales attention is a scarce resource.

A $150,000-a-year account can support things a $49-a-month account cannot: discovery calls, solution engineers, procurement negotiations, security reviews, custom rollout plans and executive engagement.

The product therefore needs to do more than detect “interest.”

It needs to detect economic justification for human involvement.

Zoom offers an unusually concrete example. In 2024, the company moved approximately 26,800 lower-MRR customers away from direct sales, reseller or partner coverage and back into its Online category. Zoom said the change did not have a material impact on the percentage of revenue coming from Enterprise versus Online customers, net expansion or online churn. Zoom disclosed the change in its SEC filings. (SEC)

Think about what that implies.

Having a salesperson attached to an account is not automatically better.

Sometimes the sophisticated GTM decision is to remove the salesperson.

Stop obsessing over PQLs. Enterprise software is bought by accounts.

One of the first mistakes companies make when implementing PLS is building everything around the individual user.

That makes sense in consumer products. It often makes much less sense in B2B.

Suppose one engineer from a Fortune 100 company signs up, logs in every morning and uses your product obsessively.

Interesting? Absolutely.

Enterprise opportunity? Maybe.

Now suppose 43 people from the same company have appeared within two weeks. They span engineering, product, security and operations. Five separate teams exist. Three admins have visited your SSO documentation. Usage has doubled week over week. The account is approaching a free-tier limit.

That is a rather different animal.

Enterprise purchasing happens at the organizational level, which is why the more useful abstraction is often a Product-Qualified Account, or PQA.

Even in the 2022 Pocus data, only 17% of respondents were tracking PQAs, reflecting how immature account-level PLS measurement still was at the time. (Pocus)

Modern B2B analytics tooling increasingly reflects this shift. Mixpanel’s Account Analytics model, for example, aggregates individual behavior into account profiles so companies can measure adoption, active-user counts, feature usage, retention and revenue at the company level rather than treating every user as an isolated organism floating through cyberspace. (Mixpanel)

For a PM, this means your PLS architecture starts with identity.

You need to know which users belong together.

Build the enterprise signal graph

The basic PLS data model should combine four kinds of evidence: fit, value, momentum and intent.

Fit tells you whether the organization resembles the customers you can serve economically: employee count, industry, geography, technology environment, regulatory requirements and potential contract size.

Value tells you whether users are actually accomplishing something meaningful. Ignore vanity activity such as logins whenever possible. Instead track behaviors associated with customer outcomes: publishing a project, running a production workload, collaborating with teammates, creating a dashboard that gets reused, processing transactions, deploying an integration—whatever “value received” means for your product.

Momentum measures organizational spread. Are active seats climbing? Are invitations accelerating? Are new departments appearing? Is usage becoming more frequent? A 50-person account with rapidly accelerating adoption can be much more interesting than a 5,000-person corporation containing one lonely enthusiast.

Intent captures behaviour suggesting that self-service may soon become insufficient: repeated pricing-page visits, approaching usage limits, viewing enterprise documentation, attempting to configure SSO, exploring permissions, requesting invoices, examining audit logs, asking about data residency or clicking “contact sales.”

This is where product telemetry gets genuinely useful.

A simple starting score might look like this:

Signal family

Example evidence

Illustrative weight

Product value

Core workflow completed repeatedly

30%

Organizational breadth

Multiple active users, teams or departments

25%

Adoption momentum

Rapid seat or usage growth

15%

Enterprise intent

Pricing, SSO, security, admin or limit signals

20%

ICP fit

Size, industry, geography, expected ACV

10%

Those weights are deliberately illustrative. Copying somebody else’s PQA formula is roughly as sensible as copying somebody else’s eyeglass prescription.

Your job is to discover which signals predict your outcomes.

Mixpanel recently published a particularly useful real-world account of how it built its own product-led data infrastructure. The company connected product behavior with Salesforce account IDs, identified product milestones correlated with value, detected usage caps and signup surges, and pushed qualified accounts back to its sales systems. Its later analysis joined sales, marketing and product data in BigQuery and compared conversion across ICP and non-ICP accounts. (Mixpanel)

That is far closer to the architecture PMs should be thinking about than “add a field called PQL Score to Salesforce.”

The most valuable PLS signals are often product problems

Here is where the PM role gets especially interesting.

The strongest enterprise buying signals frequently appear when bottoms-up adoption collides with organizational complexity.

Twenty employees have independently created accounts using the same corporate domain.

Suddenly IT wants centralized control.

Five teams are sharing sensitive information.

Suddenly security wants auditability.

Employees keep joining and leaving.

Suddenly administrators want SCIM provisioning.

Data is crossing borders.

Suddenly legal wants residency controls.

Teams are buying seats on individual corporate cards.

Suddenly finance wants consolidated billing.

These are not merely “sales signals.” They are product requirements.

Look at Figma’s Enterprise plan: SAML SSO, SCIM provisioning, workspaces, administrative controls and security capabilities sit alongside the core creative product. Its organization administrators can control domains, login methods, provisioning, seats, billing and access. (Figma Help Center)

Slack followed a similar pattern. Its original S-1 said:

“We complement our self-service strategy with a focused direct sales effort targeted at organizations with existing organic adoption of Slack.”

Slack then invested in Enterprise Grid capabilities such as administration, security and compliance. Its current enterprise offerings include controls around audit logs, data loss prevention, information barriers, domain claiming, retention and other enterprise requirements. Slack’s plan comparison shows how those capabilities increase with organizational complexity.

That suggests a useful PM principle:

Your enterprise roadmap should solve the problems created by successful bottoms-up adoption.

That is much more strategic than compiling a list of features requested by whichever enterprise prospect shouted loudest last quarter.

Build the “seller cockpit,” not just the alert

Once you identify a strong PQA, resist the temptation to send sales a notification reading:

HOT PQL — SCORE 87

That conveys roughly the same strategic insight as a smoke alarm.

The seller needs context.

A good PLS handoff should explain what is happening inside the account: how many active users exist, which teams are growing, who appears to be the internal champion, which workflows have reached value, which enterprise features have been explored, whether the account is approaching a limit, whether usage is accelerating or declining, and why the system believes human intervention might help.

Imagine an AE opening an account and seeing:

Acme Corp: 47 weekly active users, up 81% in 14 days. Five teams active. Three users visited SSO setup. Workspace at 92% of plan limit. Sarah Chen invited 19 users and appears to be the internal champion.

Now the opening conversation can be:

“Would it help if we showed you how other companies centralize provisioning before adoption spreads further?”

Instead of:

“Hi Sarah! I noticed you use our product. Do you have 30 minutes for a quick chat?”

Nobody has ever believed that call will be quick.

The difference is not cosmetic. The first approach is sales-assist. The second is surveillance with Calendly attached.

Give customers a hand-raiser everywhere friction appears

The best PLS systems do not depend entirely on sellers deciding when to intervene.

Let customers summon help.

A PM can add contextual human escalation at exactly the moments where complexity increases: upgrading a large workspace, configuring SSO, reaching a usage limit, inviting dozens of users, requesting security documentation, setting up multiple departments, evaluating migration tools or trying to understand enterprise pricing.

The CTA should match the problem.

“Talk to sales” is generic.

“Plan a company-wide rollout” is useful.

“Discuss security requirements” is useful.

“Get help consolidating 14 workspaces” is extremely useful.

The product knows what the customer is trying to accomplish. Use that context.

This also reconciles the apparently contradictory buyer research. Customers can remain happily self-directed when self-service works and request expertise when they encounter a problem where expertise creates value.

Sales becomes an optional product capability.

That is a much healthier relationship.

The dangerous metric nobody talks about: assisted revenue that would have happened anyway

Suppose your PQA model identifies 1,000 highly engaged accounts.

Sales contacts them.

Thirty percent purchase.

Champagne! Gong! LinkedIn post!

Except perhaps 28% would have purchased anyway.

This distinction is enormously important.

A PQA model can be excellent at predicting who will buy while being useless at determining who needs sales assistance to buy.

Those are different questions.

From a product experimentation perspective, the second is the more interesting one.

Where operationally feasible, hold out a percentage of qualified accounts from proactive outreach and compare outcomes. Test different score thresholds. Test timing. Compare product-only conversion against sales-assisted conversion. Examine contract value, sales-cycle duration, retention and expansion—not merely meeting-booked rates.

You are trying to measure incremental lift:

Sales-assist value = outcome with assistance − expected outcome without assistance.

If extremely high-intent customers convert equally well without help, leave them alone.

If medium-intent enterprise accounts convert dramatically better when a solution engineer appears after a security signal, invest there.

This is where a mature PLS team moves beyond lead scoring into resource allocation.

The goal is not to create the maximum number of PQLs.

The goal is to deploy scarce human attention where it changes the outcome.

Metrics: measure the system, not the vanity funnel

A PM running PLS should refuse to accept “number of PQLs” as the primary success metric.

You can increase PQL volume tomorrow. Lower the score threshold. Congratulations—you have invented MQLs again.

The more meaningful scorecard connects product behaviour to economics.

At the top of the funnel, measure the share of qualified accounts that reach genuine product value, the precision of your PQA model and how frequently sellers accept versus reject the opportunities generated.

Through the sales funnel, measure PQA-to-meeting conversion, PQA-to-opportunity conversion, assisted win rate, average contract value and sales-cycle length.

Then follow customers after purchase: expansion, net dollar retention, adoption breadth and churn.

Finally, measure the cost side. How many seller hours did the motion consume? What proportion of customers would probably have converted without human involvement?

A powerful north-star candidate is therefore something like:

Incremental gross profit generated per hour of sales-assist capacity.

It is not as Instagram-friendly as “10,000 PQLs this quarter,” but CFOs tend to recover remarkably quickly from the disappointment.

PM and Sales need a feedback loop, not a weekly argument

The final component is organizational.

Sales must be able to tell Product why a PQA was wrong.

Product must be able to see why qualified accounts were lost.

Customer Success must report what happened after the contract.

Marketing must know which accounts arrived with meaningful intent.

RevOps must ensure the data survives the journey across systems without becoming an archaeological expedition.

And PM should regularly examine patterns in lost enterprise deals.

If 40% of promising accounts hit a security requirement you cannot satisfy, that is roadmap data.

If customers repeatedly require a sales call merely to understand pricing, that may be a pricing UX problem.

If sellers repeatedly rescue users who cannot complete onboarding, that may be an activation problem masquerading as a sales opportunity.

If enterprise prospects consistently need an expensive solution engineer to configure something that could be automated, congratulations: you may have discovered a product feature worth millions.

Sales conversations are not noise surrounding the product.

They are product research occurring unusually close to money.

A practical 90-day PLS roadmap for PMs

A PM starting from scratch does not need a machine-learning propensity model, a 14-tool RevOps stack and a newly hired Vice President of Acronyms.

A sensible first 90 days can be surprisingly pragmatic:

1. Define value first. Identify the behaviours most associated with activation, conversion and retention. Interview Sales and Customer Success, but verify their beliefs against actual product data.

2. Create an account identity layer. Group users by workspace, company, verified domain, CRM account or another reliable organizational identifier. Preserve the ability to drill from account behaviour down to individual champions.

3. Instrument enterprise signals. Add events for invitations, workspace growth, usage limits, pricing exploration, administrative settings, security documentation, SSO, integrations, billing and other high-intent behaviours.

4. Build a first PQA model. Combine product value, organizational breadth, momentum, enterprise intent and ICP fit. Start rules-based; sophistication can come later.

5. Create a contextual handoff. Push not only the account and score into your CRM but also the reason the account qualified and the specific customer problem worth discussing.

6. Add contextual hand-raisers. Give users obvious ways to request human help at high-friction moments without forcing everyone through sales.

7. Run controlled experiments. Compare different trigger thresholds, messages and timing. Where possible, maintain a holdout group so you can measure incremental lift rather than flattering correlation.

8. Feed revenue outcomes back into Product. Won, lost, churned and expanded accounts should continuously reshape your qualification model and enterprise roadmap.

By the end of that period, you will not have “finished PLS.”

You will have something more valuable: a learning system.

The PM’s real job in Product-Led Sales

The temptation is to see Product-Led Sales as a clever mechanism for converting free users into enterprise leads.

That undersells it.

The deeper opportunity is to connect three things that traditional software companies often keep embarrassingly separate:

what customers do, what customers need and what customers will pay for.

Product sees behaviour.

Sales sees organizational intent and procurement complexity.

Customer Success sees whether the promised value actually survived implementation.

PLS works when those signals become one system.

The best product-led companies are already moving in this direction. Figma lets the product spread organically and then uses direct sales to scale larger deployments. Atlassian automates as much of the customer journey as economics permit and introduces direct sales as accounts become sufficiently valuable and complex. Slack built enterprise sales on top of bottoms-up adoption. Zoom has even demonstrated the reverse move—removing lower-value customers from direct coverage when human attention no longer made economic sense.

None of those companies abandoned product-led growth.

They completed it.

Because enterprise customers do not wake up one morning, throw away their credit cards and suddenly become “sales-led.” Their needs evolve. One user becomes a team. A team becomes five teams. Five teams become a security concern, an identity-management problem, a procurement event and—eventually—a very large contract.

The PM’s job is to design the product so the company can recognize that transition.

Not too early, when a salesperson merely becomes friction.

Not too late, when an internal champion is drowning in security questionnaires.

At exactly the moment when the product has proven its value—and the next obstacle requires something more than another tooltip.

That is Product-Led Sales at its best.

The product earns the customer.

The data identifies the opportunity.

And the human helps close the gap.

In June 2023, Apple did something it had not done in nearly a decade: it unveiled an entirely new computing platform.

Tim Cook stood onstage and declared that Apple Vision Pro would usher in “the era of spatial computing.” Apple called it the company’s most advanced consumer electronics device ever created. The demonstration was appropriately Apple-esque: enormous floating screens, FaceTime calls suspended in your living room, 3D photographs, movies projected at cinema scale, and a user interface controlled with nothing more exotic than your eyes and fingers. Read Apple’s original Vision Pro launch announcement (Apple)

For a few minutes, it looked as if Minority Report had been acquired by Cupertino.

Then Apple revealed the price: $3,499.

And somewhere, several million people quietly decided that perhaps regular old reality wasn’t so terrible after all.

Three years later, the evidence is increasingly difficult to spin. Vision Pro has not become the next iPhone, iPad, Apple Watch or even AirPods. IDC data cited by the Financial Times indicates Apple shipped roughly 390,000 Vision Pro units in 2024. Production was reportedly halted in early 2025 after inventory accumulated, U.S. and U.K. digital advertising spending for the product fell more than 95% during 2025, and IDC expected only about 45,000 units to ship during the crucial fourth quarter of that year. Read the Financial Times investigation into Vision Pro’s weak sales (Financial Times)

And on August 21, 2026, the story became harder still to dismiss. Apple cut roughly 100 positions from its Vision Pro organization, largely shut down a team focused on gaming, and reduced the group producing its expensive Apple Immersive Video content. The company says Vision Pro and visionOS are continuing, but resources are increasingly moving toward AI and lighter smart-glasses-style devices. Read Bloomberg’s reporting on Apple’s August 2026 Vision Pro cuts (Yahoo Finance)

So yes: if Vision Pro was supposed to become Apple’s next mass-market computing platform, the first generation failed.

But “it cost too much” is an unsatisfying explanation.

Apple’s bigger mistake was more interesting.

It built perhaps the finest headset anybody had ever made at precisely the moment the market was beginning to discover that people didn’t really want headsets.

First, let’s define what “failed” means

There is a danger in judging every new Apple product against the iPhone.

The original iPhone sold its millionth unit just 74 days after launch. Apple was so pleased that Steve Jobs publicly bragged about the milestone. Apple’s announcement of its millionth iPhone sale (Apple)

Vision Pro never had a realistic chance of matching that trajectory.

Cook eventually acknowledged as much:

“At $3,500, it’s not a mass-market product.”

He described Vision Pro instead as an “early-adopter product” for customers who wanted tomorrow’s technology today. (MacRumors)

That’s fair.

In fact, Apple’s original production expectations had already been dramatically reduced before launch. The Financial Times reported in 2023 that Apple initially hoped to sell around one million units during Vision Pro’s first year but reduced production expectations to fewer than 400,000 because manufacturing the micro-OLED displays and other components was extraordinarily difficult. Read the FT’s pre-launch report on Vision Pro manufacturing difficulties(Financial Times)

So 390,000 shipments in 2024 were not catastrophic relative to Apple’s already-constrained supply.

The real problem came afterward.

Successful platform products normally produce a flywheel:

users → developers → better apps → more users → more developers.

Vision Pro produced something closer to a ceiling fan with one blade missing.

Initial curiosity was enormous. Long-term momentum was not.

That is where the failure becomes strategically interesting.

1. Apple confused technological breakthrough with customer value

Vision Pro contains some astonishing engineering.

The displays are superb. Eye tracking feels almost telepathic. You look at something and pinch your fingers together. It responds.

No controllers.

No mouse.

No instructions involving “press trigger B while holding grip button A.”

Reviewers who were skeptical of the concept routinely praised the interface. Ars Technica, after attempting to work almost entirely inside Vision Pro for a week, described the eye-tracking and finger-gesture system as brilliantly conceived and said the device genuinely demonstrated compelling possibilities for spatial computing. Read Ars Technica’s week-long Vision Pro productivity test (Ars Technica)

That’s precisely why Vision Pro makes such a useful product-management case study.

A product can be technologically extraordinary and commercially unnecessary.

Apple showed consumers dozens of things Vision Pro could do:

• replace multiple monitors;

• watch giant movies;

• view spatial photos;

• conduct FaceTime meetings;

• play games;

• meditate;

• manipulate 3D models;

• work on airplanes;

• explore immersive environments.

What it struggled to answer was much simpler:

What problem in my life is painful enough that I will pay $3,499 and strap nearly a kilogram of electronics to my head to solve it?

That question never received an obvious answer.

The iPhone did.

It replaced or improved devices people already carried every day: phone, iPod, camera, browser, email device, eventually GPS and much more.

Vision Pro often replaced something customers already liked.

Want to watch Netflix? You probably own a television.

Want three monitors? Monitors are inexpensive.

Want to write email? Your MacBook does not require facial cushioning.

Want to attend a Zoom meeting? Your coworkers may prefer that your face look like your actual face.

Vision Pro therefore suffered from a deadly innovation problem: spectacular demos without sufficiently frequent jobs-to-be-done.

The demo made people say, “Wow.”

The product needed to make them say, “I need this every Tuesday.”

Those are very different sentences.

2. The physical form factor fought against the product’s own ambitions

Apple marketed Vision Pro as a general-purpose “spatial computer.”

General-purpose computers are used for hours.

Unfortunately, human faces have opinions about that.

The original Vision Pro weighed roughly 600–650 grams depending on configuration, excluding its separate 353-gram battery. See Apple’s Vision Pro technical specifications (Apple Support)

That’s a lot of hardware sitting on your cheekbones and forehead.

The newest M5 version improved the headband and counterbalancing, but the current configuration is still substantial: Apple lists the device at roughly 750–800 grams including the Light Seal and Dual Knit Band, plus the separate battery. Battery life reaches around 2.5 hours of general use and three hours of video. See Apple’s current M5 Vision Pro specifications (Apple Support)

None of this is disastrous for a 30-minute experience.

It becomes extremely important if Apple’s ambition is to replace your laptop monitor for eight hours.

One Guardian reviewer reported that after a month of daily use he could manage approximately two-hour sessions, but still experienced neck, shoulder and back discomfort after extended wear. (The Guardian)

This exposes a fundamental product contradiction.

Vision Pro’s hardware was optimized for fidelity.

Its use cases required comfort.

Apple chose displays, sensors, glass, aluminum, cameras, compute power and visual quality because it wanted the experience to feel magical.

Every one of those decisions carried weight, power and cost.

The engineering team succeeded.

The human neck lost.

3. $3,499 wasn’t merely expensive. It destroyed the ecosystem economics.

Price does matter, just not in the simplistic “people don’t like expensive things” sense.

Apple sells plenty of expensive things.

A well-equipped MacBook Pro can cost thousands of dollars. People buy it because they can calculate its value.

Vision Pro’s price created a more subtle platform problem.

Few users meant limited developer revenue.

Limited developer revenue meant fewer ambitious native applications.

Fewer applications meant fewer reasons for consumers to buy Vision Pro.

Congratulations: you have invented the world’s most expensive chicken-and-egg problem.

Apple tried to jump-start the ecosystem cleverly. At launch, more than one million iPad and iPhone applications could technically run on Vision Pro, while more than 600 experiences had been designed specifically for the device. Apple’s launch-day Vision Pro app announcement (Apple)

By June 2024, Apple said the number of native spatial apps had exceeded 2,000.

That sounds impressive until you examine the trajectory.

By October 2025 — more than a year later — Apple reported only “more than 3,000” apps built for visionOS. Apple’s October 2025 update on the Vision Pro app ecosystem (Apple)

So the ecosystem grew rapidly during the launch excitement and then dramatically more slowly.

Independent Appfigures data spotted the warning almost immediately. After an early surge of Vision-specific releases, new launches fell sharply following the headset’s debut, at one point reaching just one new Vision-only application during the final week of March 2024. See Appfigures’ analysis of slowing Vision Pro development (Appfigures)

Developers are rational.

Suppose you run a 20-person SaaS company.

Should you spend six months creating an extraordinary spatial application for perhaps hundreds of thousands of users?

Or improve your iPhone app for hundreds of millions?

The spreadsheet is not particularly conflicted about this.

4. Apple launched a platform before it had a killer app

There is a subtle but important distinction between having apps and having a killer app.

Vision Pro had Disney+. Microsoft 365. Zoom. Slack. Safari. Apple TV. Games. Productivity utilities.

What it lacked was the application that made people forgive everything else.

Nintendo had Mario.

The iPod had 1,000 songs in your pocket.

BlackBerry had mobile email.

Instagram helped sell smartphone cameras.

ChatGPT gave generative AI its consumer “aha!” moment.

Vision Pro had… extremely large Safari windows.

They are beautiful Safari windows, granted.

Apple Immersive Video came closest to providing something genuinely impossible on conventional devices. Apple’s 180-degree, stereoscopic, high-resolution films can create an extraordinary sense of presence.

But immersive video faced the same economic trap as native apps.

It is expensive to create.

The audience was tiny.

And Apple is now reducing the team producing it. Bloomberg reported in August 2026 that individual immersive productions could cost millions of dollars while the limited number of active Vision Pro users made that expenditure increasingly difficult to justify. (MacRumors)

This is particularly revealing.

When your killer content is too expensive to produce because too few people own the hardware, while too few people buy the hardware because there isn’t enough killer content, your flywheel is rotating in the wrong direction.

5. Vision Pro was surprisingly antisocial

Apple understood one uncomfortable fact about VR headsets: humans tend to dislike talking to somebody whose face has been replaced by ski goggles.

Its solution was EyeSight.

The front of Vision Pro displays a representation of the wearer’s eyes, supposedly allowing people nearby to maintain a sense of connection.

It was an admirable attempt.

It was also a sign that Apple was solving a problem created by the product itself.

Then came Personas — digital representations of Vision Pro owners used during calls.

Early versions landed somewhere between Pixar and a witness-protection reconstruction.

Ars Technica’s week-long productivity experiment concluded that Vision Pro’s weakest professional use case was meetings, describing the Personas issue rather memorably as “social suicide.” (Ars Technica)

This matters because computing is becoming more collaborative.

Slack, Teams, Zoom, Meet, multiplayer games, social video and hybrid work all depend on effortless interaction with other people.

Vision Pro often inserted hardware between you and them.

Apple’s marketing repeatedly emphasized that Vision Pro allowed users to remain present in their surroundings.

But presence isn’t merely seeing the person beside you.

It is also them being able to see you.

6. Apple underestimated how badly gaming mattered

Apple was careful not to call Vision Pro a VR headset.

It was a “spatial computer.”

This was understandable branding. VR had accumulated years of baggage: gamers, motion sickness, Meta’s metaverse spending spree and assorted virtual meeting rooms populated by torsos without legs.

But refusing the category doesn’t eliminate its strongest existing customer segment.

Gaming had been one of the few proven reasons consumers were willing to wear a headset.

Meta understood that.

Apple entered with gorgeous displays, excellent spatial tracking and tremendous processing power — and without standard VR motion controllers.

Instead, it prioritized eye and hand tracking.

Elegant? Absolutely.

Ideal for manipulating menus? Yes.

Ideal for swinging a sword, firing a virtual bow or handling fast physical interaction?

Not always.

The platform eventually added richer controller support, and the M5 release supported accessories including PlayStation VR2 Sense controllers. (Apple)

But ecosystems have path dependence.

Gamers were already on Quest, PlayStation VR and PC VR platforms. Developers were already there with them.

Apple needed either to embrace gaming aggressively enough to migrate that audience or produce a new use case dramatically larger than gaming.

It did neither.

The August 2026 decision to largely shut down Vision Pro’s dedicated gaming team feels less like the cause of the problem than the final admission that the strategy never achieved escape velocity. (The Verge)

7. The competitor that mattered wasn’t Quest. It was Ray-Ban.

This is where the story becomes genuinely interesting.

Apple appeared to believe the evolution of spatial computing would look roughly like:

VR headset → exceptional mixed-reality headset → smaller mixed-reality headset → AR glasses.

Meta accidentally discovered a different path:

ordinary glasses → camera + speakers → AI assistant → display → richer AR.

The distinction is enormous.

Vision Pro asks you to adopt a new behaviour.

Ray-Ban Meta glasses piggyback on one humanity has been practicing for centuries: putting on glasses.

EssilorLuxottica said more than two million Ray-Ban Meta glasses had been sold by early 2025 and announced plans to expand production capacity to 10 million units annually by the end of 2026. Read Reuters on Ray-Ban Meta sales and production expansion (Reuters)

Sales accelerated further. EssilorLuxottica subsequently reported Ray-Ban Meta sales growing more than 200% during the first half of 2025. (EssilorLuxottica)

By 2026, the broader market had moved decisively in the same direction.

IDC reports that display-less smart-glasses shipments increased 167% year over year in Q1 2026, reaching roughly 2.25 million units in a single quarter. Meta held about 69.2% of the category. IDC now expects 13.6 million display-less smart glasses to ship in 2026. See IDC’s 2026 smart-glasses market data (IDC)

Traditional VR and mixed-reality headsets, meanwhile, continued struggling.

IDC’s broader 2025 analysis put it nicely: XR was moving away from bulky headsets and toward devices that consumers might actually wear to the grocery store. Read IDC’s 2025 XR market analysis (IDC)

There is the brutal strategic insight.

Apple may have perfected the wrong intermediate form factor.

8. Apple’s premium strategy worked against platform strategy

Apple usually loves premium positioning.

It enters a category, makes something beautifully integrated, charges more and harvests attractive margins.

That works when the value of the product mostly comes from Apple itself.

Spatial computing is different.

Its value depends heavily on network effects.

You need developers.

Content producers.

Games.

Media companies.

Enterprise software.

Peripheral makers.

Users.

Creators.

Maybe social interactions.

Maybe shared spatial experiences.

Platform businesses often benefit from subsidizing early adoption because every additional customer makes the ecosystem more attractive to developers.

Meta understood this to an almost comical degree, spending tens of billions of dollars through Reality Labs.

Apple instead launched its new ecosystem with a $3,499 velvet rope.

In 2026, even after U.S. Quest prices increased because of component costs, the entry-level Meta Quest 3S costs around $349.99 — roughly one-tenth Vision Pro’s price. See Reuters on current Meta Quest pricing (Reuters)

Of course the products aren’t technically equivalent.

That’s not the point.

Developers care about installed bases.

A magnificent $3,499 platform with hundreds of thousands of customers can be less commercially attractive than an imperfect $350 platform with millions.

Apple optimized gross-margin logic before it had established ecosystem liquidity.

For a platform launch, that may have been backwards.

9. Yet Vision Pro found one place where $3,499 isn’t particularly expensive: enterprise

This is why declaring Vision Pro completely dead would be premature.

In enterprise environments, $3,499 can be pocket change.

An aircraft engine costs considerably more than an Apple headset.

So does shutting down an aircraft for training.

Apple has highlighted Vision Pro applications at companies including KLM, Porsche, SAP and Lowe’s. KLM developed an Engine Shop application allowing technicians to train against detailed 3D engine models rather than requiring equivalent access to physical equipment. Explore Apple’s Vision Pro enterprise case studies (Apple)

Those applications make much more economic sense.

Consider a manufacturer where an error costs $50,000.

A $3,499 headset is no longer expensive.

It is a rounding error.

Training, design visualization, healthcare, engineering, remote assistance, architecture and high-end simulation may therefore represent Vision Pro’s strongest near-term market.

The irony is wonderful.

Apple built what it called a consumer spatial computer and accidentally produced something resembling a workstation.

That isn’t necessarily a bad business.

It just isn’t the next iPhone.

10. The M5 Vision Pro shows Apple could improve almost everything except the fundamental problem

Apple refreshed Vision Pro in October 2025 with its M5 chip.

Performance improved.

Display rendering improved.

Battery life improved.

The Dual Knit Band improved comfort.

Apple Intelligence arrived.

The ecosystem surpassed 3,000 visionOS-native apps. Read Apple’s M5 Vision Pro announcement (Apple)

What did not change?

The starting price remained $3,499.

The physical form factor remained a headset.

And the central value proposition remained difficult to explain without a 30-minute Apple Store demonstration.

This is an important product lesson.

When adoption disappoints, product teams often respond by making the product better.

Faster.

Sharper.

More features.

Better battery.

Better AI.

More comfortable straps.

Sometimes the problem isn’t that the product isn’t good enough.

Sometimes the product is solving the wrong layer of the problem.

Vision Pro did not primarily need a faster processor.

It needed to become something people wanted to wear.

So did Vision Pro really fail?

As of August 2026, I would give three different answers.

As a mass-market consumer product: yes.

Hundreds of thousands of annual units are tiny by Apple standards. Production and marketing were reduced. Developer momentum never developed into an iPhone-style flywheel. Dedicated Vision Pro staffing is being reduced. The price and ergonomics remain formidable barriers. (Financial Times)

As a platform experiment: not necessarily.

Apple now has years of real-world experience with eye tracking, hand tracking, passthrough video, spatial interfaces, 3D content, Personas, spatial photography, developer APIs and human-computer interaction.

That technology does not disappear because Vision Pro itself remains niche.

Apple is still developing visionOS 27 in 2026, including deeper AI and visual-intelligence capabilities. See Apple’s visionOS 27 roadmap (Apple)

As preparation for glasses: Vision Pro may eventually look brilliant.

Imagine an Apple product five years from now that weighs roughly as much as ordinary eyewear.

It recognizes what you are looking at.

Siri understands your environment.

Notifications appear subtly in your field of vision.

Directions float ahead of you.

AirPods provide audio.

Your iPhone supplies compute.

Your Apple Watch provides identity and health context.

And fifteen years of Vision-team engineering quietly sit underneath the whole thing.

Suddenly Vision Pro looks less like Apple’s Newton and more like a $3,499 public prototype.

An extremely polished public prototype, admittedly.

The real product lesson: don’t confuse “magic” with product-market fit

Vision Pro demonstrates one of the most dangerous traps in product development.

Teams can fall in love with capability.

A prototype does something that was previously impossible.

Executives try it.

Their eyes widen.

People start saying things like “paradigm shift.”

PowerPoint decks mysteriously acquire pictures of rocket ships.

Then somebody forgets to ask whether the customer wants to do the thing frequently enough to build a business around it.

Vision Pro had extraordinary experience-market fit.

People tried it and said “wow.”

What it lacked was habit-market fit.

People didn’t reliably wake up the next morning thinking, Where is my Vision Pro?

That distinction should terrify product managers.

A compelling demo measures emotional intensity.

A successful product measures repeated behaviour.

The two correlate less than Silicon Valley would like to admit.

Five lessons product leaders should steal from Vision Pro

First, start with frequency, not novelty. A mediocre solution to something customers do 20 times per day can create more value than a breathtaking solution to something they do twice per month.

Second, hardware friction multiplies behavioural friction. Every extra step — charging, fitting, wearing, adjusting, carrying — must be overcome by proportionally greater value. “Put something on your face” is not equivalent to “open an app.”

Third, platform pricing is ecosystem strategy. If developers need millions of users before investing, maximizing first-generation hardware margins may minimize long-term platform value.

Fourth, killer apps cannot be replaced with feature inventories. Customers don’t buy platforms because PowerPoint slides contain 37 possible use cases. They buy because one use case becomes indispensable.

And fifth, form factor is strategy. Apple spent enormous engineering effort making a headset extraordinary. Meta discovered that being slightly useful in normal-looking glasses could produce better adoption than being astonishing inside a computer strapped to your face.

That’s uncomfortable.

It is also probably the most important lesson of the entire Vision Pro story.

Apple may have lost the headset battle and still win spatial computing

There is a lovely historical precedent here.

Apple did not invent the MP3 player.

It did not invent the smartphone.

It did not invent the tablet.

It did not invent the smartwatch.

Its traditional strength has been recognizing when technology is finally ready to cross the gap between possible and normal.

Vision Pro reversed the formula.

Apple crossed “possible” spectacularly.

It never reached “normal.”

The industry now appears to be converging on the missing piece: glasses.

And that’s why Vision Pro’s failure may ultimately prove useful rather than embarrassing.

Apple has learned what millions of dollars of laboratory testing could never teach it:

People love spatial computing.

They love enormous virtual displays.

They love immersive memories.

They love interfaces controlled by eyes and hands.

They just don’t particularly love wearing a 600-plus-gram computer to get them.

Perhaps the future really is spatial.

Perhaps Tim Cook was right about that part.

But the first rule of building the computer of the future turns out to be surprisingly old-fashioned:

Make sure people actually want to put it on.

It is the awkward first date between your product and the user. You have five minutes to prove you are useful, trustworthy, and not secretly a spreadsheet wearing a SaaS hoodie. Get it right, and users experience the magic: “Oh, I see why I need this.” Get it wrong, and they disappear forever, leaving behind only a sad analytics event called signup_started.

For Product Managers, onboarding is not a tour. It is not a checklist. It is not seven tooltip balloons screaming “Click here!” like an overexcited museum guide.

Onboarding is the designed path from user intent to customer value.

That means the PM’s job is to understand activation, identify the aha moment, design strong first-run UX, make empty states useful, trigger lifecycle emails at the right time, and measure time-to-value like it actually matters. Because it does.

According to Wyzowl’s customer onboarding research, 86% of people say they are more likely to stay loyal to a business that invests in onboarding content that welcomes and educates them after purchase. The same research found that 8 in 10 users have deleted an app because they did not know how to use it.

That is a brutal reminder: customers do not churn only because your competitors are better. Sometimes they churn because your product made them feel like they accidentally opened the cockpit of a Boeing 737.

Onboarding Is Not Education. It Is Acceleration.

A common mistake is treating onboarding as a classroom.

“Welcome to our product. Here is a 14-step tutorial. Please memorize the sidebar.”

No. Absolutely not. Your user did not wake up excited to complete your product SAT. They came with a job to do. The onboarding experience should help them complete that job faster than they expected.

Intercom describes the aha moment as the interaction that “reveals the true value of the product” to users in its guide to understanding aha moments. That phrase matters because onboarding is not about showing everything your product can do. It is about helping the user experience one meaningful thing your product does for them.

For a project management tool, that might be creating the first shared project and assigning a task. For a banking app, it might be checking a balance, paying a bill, or freezing a card. For a developer API, it might be making the first successful request. For an AI writing tool, it might be generating a usable first draft.

The customer does not care that your product has “advanced configuration.” They care whether it solves the painful thing that brought them there in the first place.

Advanced configuration can wait. Nobody ever said, “I fell in love with this product because the settings page appeared before I understood the value.” Except maybe an enterprise admin. And even then, only after coffee.

Activation: Define the Moment That Predicts Retention

Activation is the point at which a user has completed enough meaningful actions that they are significantly more likely to retain.

This is not the same as signup. Signup is paperwork. Activation is evidence.

A user who creates an account but never experiences value is not activated. They are just a lead with a password.

The classic examples are famous because they are specific. Facebook’s widely discussed “7 friends in 10 days” metric is covered in Mode’s article on Facebook’s aha moment. Slack’s often-cited activation threshold was tied to a team sending enough messages to experience the product’s collaborative value. Dropbox’s early value was not “account created”; it was a file synced and available where the user needed it.

The lesson is not that every product needs a magic number. The lesson is that activation must be measurable.

Bad activation metrics:

• Completed signup

• Watched intro video

• Clicked “next” five times

• Landed on dashboard

• Received welcome email

Better activation metrics:

• Created first project and invited a collaborator

• Connected bank account and categorized first transaction

• Published first form and received first response

• Imported customer data and sent first campaign

• Generated first report using real data

• Completed first payment or transfer

• Received first useful AI-generated output

The best activation event connects directly to the product’s core promise.

For PMs, the question is simple: “What action, completed early, predicts that this user will come back?”

Then comes the harder question: “How do we remove everything that prevents them from reaching it?”

That second question is where roadmaps go to become adults.

The Aha Moment: Stop Guessing, Start Proving

Every team thinks it knows the aha moment.

Sales thinks it is the demo feature. Marketing thinks it is the tagline. Design thinks it is the beautiful new dashboard. Engineering thinks it is the technically elegant workflow nobody else understands. The CEO thinks it is whatever was in the investor deck.

The user, annoyingly, has their own opinion.

Your job as PM is to find the real aha moment using evidence. Start by comparing retained users against churned users. What did retained users do in their first session, first day, or first week that churned users did not? Which actions correlate with repeat usage, expansion, or successful outcomes?

Then combine quantitative analysis with qualitative research. Watch session recordings. Run first-use usability tests. Interview new users within 24 to 48 hours of signup. Ask: “When did this product first make sense to you?” Also ask: “Where did you almost give up?”

That second question is gold. It reveals the cliff edge.

Aha moments often hide behind friction. The user almost reached value, but then the product asked them to upload a CSV, configure permissions, invite a team, verify an email, choose a template, name a workspace, accept cookies, solve a CAPTCHA, and emotionally recover from the word “implementation.”

This is how products lose people: not with one giant failure, but with 12 tiny papercuts.

First-Run UX: Let Users Do the Thing, Not Learn About the Thing

The best first-run experience is not a lecture. It is a guided first success.

This is why interactive onboarding usually beats passive product tours. Users rarely remember a tooltip tour shown before they have context. They are clicking “Next” with the dead-eyed determination of someone accepting software terms and conditions.

Instead of saying, “Here is how to create your first campaign,” help them create the first campaign.

Instead of saying, “Here is where reports live,” generate their first useful report.

Instead of saying, “Invite teammates later,” explain why inviting one teammate now unlocks the value.

Good first-run UX follows a simple pattern:

1. Ask only what you need to personalize the path.

2. Give the user a realistic default or template.

3. Guide them toward one valuable action.

4. Celebrate completion without turning the interface into a birthday clown.

5. Reveal deeper features progressively.

This is especially important for complex products. In B2B, onboarding can become painfully slow. McKinsey notes that the average onboarding process for a new corporate banking client can take up to 100 days. That is not onboarding. That is a season of prestige television.

Complexity may be unavoidable, especially in regulated environments, enterprise workflows, banking, healthcare, or security products. But complexity should be sequenced. The user should not have to complete every administrative task before seeing any value.

Give them a first win. Then earn the right to ask for more.

Empty States Are Not Empty. They Are Onboarding Real Estate.

Empty states are the screens users see before they have created data: no projects, no reports, no transactions, no campaigns, no messages, no teammates.

Many products treat these states as blank walls.

“No data yet.”

That is not helpful. That is the product equivalent of a waiter dropping you in a restaurant kitchen and saying, “No food yet.”

UserOnboard puts it beautifully in its guide to empty states: “If empty states aren’t adding to your onboarding, they’re taking away.”

A strong empty state should answer three questions:

• What is this area for?

• Why should I care?

• What should I do next?

Weak empty state:

“You have no reports.”

Strong empty state:

“Reports help you see which campaigns are driving qualified leads. Create your first report from a template or import sample data to preview how it works.”

Even better, give users a shortcut:

• Use sample data

• Start with a template

• Import from an existing tool

• Watch a 60-second example

• Invite a teammate

• Connect an account

• Book setup help

Empty states are powerful because they appear exactly when the user needs direction. They are not interruptive. They are contextual.

A modal is a salesperson jumping into the room. A good empty state is a helpful signpost.

Lifecycle Emails: The Product Experience Continues Outside the Product

Onboarding does not stop when the user closes the app.

Lifecycle emails, push notifications, and in-app messages can rescue users who stalled, reinforce value, and guide the next best action. But only if they are based on behavior.

Generic lifecycle email:

“Welcome to Productly! We’re excited to have you.”

Behavioral lifecycle email:

“You created your first workspace but haven’t invited your team yet. Teams that invite at least one collaborator are more likely to complete their first project. Invite someone now.”

The second email is better because it responds to what the user actually did.

A strong onboarding email system should include:

• A welcome email that restates the promised outcome

• A “next best action” email if the user stalls

• A first-win email when the user completes activation

• A social proof email showing how similar customers succeed

• A help email triggered by friction signals

• A reactivation email if the user disappears before value

• A milestone email when the user reaches meaningful progress

HubSpot’s guide to customer lifecycle management highlights onboarding metrics such as time to first value, activation rate, feature adoption, and onboarding completion rate. That is the right mental model: lifecycle communication should move users through measurable stages, not blast them with “Did you know?” trivia.

Nobody wants seven emails about features they have not needed yet. That is not onboarding. That is a product newsletter with boundary issues.

Time-to-Value: The Metric That Keeps You Honest

Time-to-value measures how long it takes for a new user or customer to experience the first meaningful benefit.

It is one of the most important onboarding metrics because it forces the team to think from the customer’s perspective.

Your internal milestone may be “customer completed setup.” The customer’s milestone is “I got the thing I came for.”

Those are not always the same.

Visa’s digital onboarding research found that customers abandon digital applications after an average of 14 minutes and 20 seconds, and that abandonment rises sharply when processes reach 20 minutes. Different industries have different thresholds, but the principle is universal: users have limited patience for processes that delay value.

Forrester has made a similar point in customer service research, noting that customers want companies to value their time. Its article on self-service customer expectations argues that self-service should be easy, effective, contextual, and delivered in the flow of customer action.

That applies perfectly to onboarding.

Measure time-to-value by segment:

• New self-serve users

• Enterprise admins

• Invited collaborators

• Mobile users

• Desktop users

• Users by acquisition source

• Users by use case

• Users by plan type

Averages can hide disasters. Your overall time-to-value might look fine while mobile users are trapped in permission prompts, enterprise users are waiting for SSO setup, and invited teammates have no idea why they were invited.

Segment the funnel. Find the pain. Remove the nonsense.

The PM Onboarding Scorecard

A Product Manager should track onboarding across four layers: conversion, behavior, value, and sentiment.

Conversion metrics:

• Signup completion rate

• First-login rate

• Onboarding step completion

• Trial-to-paid conversion

• Invite acceptance rate

Behavior metrics:

• Activation rate

• Key feature adoption

• Template usage

• Integration completion

• Number of meaningful actions in first session

Value metrics:

• Time-to-first-value

• Time-to-activation

• First successful outcome

• Usage frequency after activation

• Retention by activation cohort

Sentiment metrics:

• First-session satisfaction

• Customer effort score

• Support tickets during onboarding

• “I understand how to use this” survey responses

• Qualitative feedback from churned users

The magic happens when you connect these metrics.

For example:

• Users who import sample data activate faster.

• Users who invite teammates retain better.

• Users who skip onboarding generate more support tickets.

• Users who complete setup but never reach first value churn anyway.

• Users from a specific ad campaign sign up but fail to activate because the promise does not match the product.

That last one is spicy. It means onboarding is not only a product problem. It can expose positioning problems, pricing problems, sales problems, and occasionally “we built a thing nobody understands” problems. Product management: come for the roadmap, stay for the existential dread.

Common Onboarding Anti-Patterns

Here are the traps PMs should hunt down.

The everything tour

A 12-step product tour tries to explain the entire product before the user has done anything. It feels thorough to the team and useless to the user.

The dashboard cliff

The user finishes signup and lands on an empty dashboard with no context, no data, and no next step. It says “Welcome” but feels like “Good luck.”

The premature form

The product asks for company size, job title, phone number, team name, industry, use case, budget, favourite sandwich, and childhood nickname before showing any value.

The fake checklist

The checklist measures tasks completed, not value reached. Users finish onboarding but still do not understand why the product matters.

The email cannon

The user receives daily onboarding emails unrelated to their behaviour. The unsubscribe button becomes the most loved feature.

The enterprise swamp

The customer cannot get value until legal, security, IT, procurement, admin configuration, SSO, data import, and three steering committee meetings align under a full moon.

Some complexity is real. But PMs should constantly ask: “Can we deliver a smaller version of value earlier?”

Practical Framework: Design Onboarding Backwards From Value

Here is a simple PM framework.

Step 1: Define the promised outcome

What did the customer come here to achieve?

Example: “Understand where my money is going,” “publish my first landing page,” “reduce support tickets,” “track project progress,” “generate qualified leads.”

Step 2: Identify the first value moment

What is the smallest meaningful version of that outcome?

Example: “First categorized transaction,” “first published page,” “first resolved ticket,” “first completed task,” “first lead found.”

Step 3: Map the required path

List every action required to reach that moment.

Then mark each step as:

• Essential now

• Can be defaulted

• Can be delayed

• Can be automated

• Can be removed

Step 4: Design the first-run experience

Guide the user through the minimum path to value. Use templates, defaults, sample data, and progressive disclosure.

Step 5: Instrument the journey

Track every step from signup to first value. Measure drop-off, time spent, errors, support requests, and return behaviour.

Step 6: Trigger lifecycle nudges

Use behaviour-based messages to help users who stall.

Step 7: Review activation cohorts

Compare users who reached first value against those who did not. Look at retention, conversion, expansion, and support load.

This is not a one-time project. Onboarding is a living system. Every new feature, segment, pricing change, integration, or acquisition channel can change the path to value.

Final Thought: Onboarding Is Product Strategy in Disguise

Customer onboarding is not the decorative lobby of your product. It is the bridge between promise and proof.

Your marketing makes a promise. Your sales team reinforces it. Your product has to prove it quickly. Onboarding is where that proof either happens or collapses into a confusing dashboard and a support ticket.

Great onboarding does not mean users understand every feature. It means users understand why your product matters to them.

The best onboarding experiences are fast, contextual, measurable, and slightly invisible. They help users succeed without making them feel like they are being trained by a compliance video from 2007.

So the next time your team debates adding another tooltip, ask a better question:

“Does this help the customer reach value faster?”

If yes, ship it.

If no, delete it, simplify it, or move it later.

Because in the end, users do not remember your onboarding flow.

They remember whether your product helped them win.

Evernote did not fail because people stopped taking notes.

That would be like saying gyms fail because humans stopped feeling guilty in January.

Evernote failed because it slowly broke the emotional contract it had with users. The product promised to be an external brain: fast, reliable, searchable, cross-platform, private, and always there. Over time, many users felt it became slower, more expensive, more complicated, less trustworthy, and less essential.

The tragedy is that Evernote was not a bad product. Quite the opposite. It was one of the most important productivity apps of the smartphone era. Before Notion became a Lego set for overachievers, before Apple Notes became “good enough,” before Obsidian turned note-taking into a spiritual retreat for Markdown monks, Evernote was the default place where your thoughts went to become organized.

For many people, Evernote was not an app.

It was a memory prosthetic with an elephant logo.

And then the elephant started forgetting why people loved it.

The original magic: capture everything, find it later

Evernote’s early genius was beautifully simple: capture anything, then find it later.

Web pages. Meeting notes. Receipts. Business cards. PDFs. Voice memos. Photos. Half-baked startup ideas written at 12:41 a.m. after too much coffee and one YouTube video about “passive income.”

Evernote handled all of it.

In 2011, Wired profiled Evernote as a freemium success story and quoted founder Phil Libin’s philosophy: “It’s more important that you stay than you pay.” That line captured the original magic of Evernote’s business model. The company did not need to squeeze users immediately. The longer users stayed, the more valuable Evernote became.

Notes accumulated.

Memories accumulated.

Switching costs accumulated.

Eventually, some users paid because leaving Evernote felt like moving houses, except every box contained your brain.

By 2013, Wired reported that Evernote had more than 65 million users and described Libin’s ambition to make Evernote an “extension of the brain.” That was a huge vision. Evernote did not merely want to be a note-taking app. It wanted to become the Nike of your mind.

Which sounds inspiring.

Also slightly like something a barefoot CEO would say on a conference stage next to a fern.

But the ambition mattered. Evernote was not trying to build a utility. It was trying to build trust, habit, and identity.

That is why its decline hurt so much.

TL;DR: Evernote did not die. It became less inevitable.

Evernote still exists. It still has paying users. Under Bending Spoons, it has been rebuilt, redesigned, and pushed toward a more aggressive business model.

But Evernote failed against its original promise.

It promised permanence, simplicity, speed, privacy, and trust. Over time, too many users experienced the opposite: friction, complexity, pricing anxiety, missing workflows, and uncertainty.

The core lesson is simple:

A productivity product does not fail when competitors add more features. It fails when users stop trusting it with their future.

Mistake 1: Evernote expanded before fully protecting the core

Evernote’s core value proposition was almost perfect:

Write it down. Store it. Find it.

That was the product.

But successful products attract temptation. Once a company has traction, the roadmap starts whispering dangerous things:

“Let’s become a platform.”

“Let’s add collaboration.”

“Let’s launch a marketplace.”

“Let’s make socks.”

And yes, Evernote really did experiment with physical products and lifestyle extensions, including notebooks, scanners, bags, and other accessories. The company wanted to become more than software. It wanted to become a productivity brand.

The problem was not ambition. Ambition is good. Without ambition, every product roadmap becomes “fix bugs, add dark mode, schedule another alignment meeting.”

The problem was sequencing.

Users depended on Evernote for speed, sync, search, offline access, editing, and reliability. Those were not just features. They were the foundation. When those parts felt weak, everything else felt like decoration on a cracked wall.

For a notes app, reliability is not a backend metric. It is the product.

If users cannot quickly capture a thought, the moment is gone.

If sync fails, trust is gone.

If search disappoints, the whole “remember everything” promise collapses into “misplace everything, but digitally.”

The product lesson: when your product becomes part of someone’s personal infrastructure, the boring features become sacred.

Mistake 2: The free model became emotionally complicated

Evernote was once one of the best examples of freemium done right. The free plan was generous, useful, and habit-forming. People could use Evernote casually, then gradually become deeply invested.

That worked brilliantly until the economics became harder.

In 2016, Evernote changed the free plan by limiting Basic users to syncing across two devices and raising paid plan prices. MacRumors covered the change, while Ars Technica described it as a major shift in Evernote’s freemium strategy.

From a business perspective, the move was understandable. Cloud infrastructure costs money. Product development costs money. Customer support costs money. A large free user base does not magically become profitable because someone in finance adds “viral loop” to a spreadsheet.

But from a user perspective, the change felt personal.

This is the danger with productivity tools. Users do not see their stored notes as your monetization surface. They see them as their life.

A pricing change in a normal SaaS product may feel annoying.

A pricing change in a personal knowledge product can feel like the app is charging rent on your memories.

That tension became even sharper in 2023, when Evernote announced that Free accounts would be limited to 50 notes and one notebook. Evernote said existing free users above the limit could still view, edit, export, share, and delete existing notes. But for many users, the free plan became less of a product and more of a lobby with a velvet rope.

It may have helped monetization.

But it changed the emotional meaning of the product.

Evernote went from:

“Your external brain.”

To:

“Your external brain, now with a storage quota and mild existential dread.”

Mistake 3: Privacy trust took a serious hit

Evernote’s brand depended on trust. People stored personal notes, business plans, journals, legal thoughts, medical notes, receipts, passwords they absolutely should not have stored there, and resignation letters they wisely never sent.

That is why the 2016 privacy controversy hurt so much.

Evernote announced privacy policy changes related to machine learning that could allow some employees to review user notes to make sure the technology worked properly. TechCrunch reported on the backlash, and then reported that Evernote reversed the policy shortly afterward.

To Evernote’s credit, the company listened and walked back the change. But trust is not restored like a password reset.

For a notes app, privacy is part of the user experience. It is not just a policy buried below 4,000 words of legal oatmeal. Users need to feel safe putting their thoughts into the product.

The privacy issue was especially damaging because Evernote’s original promise was intimate. This was not a weather app asking for location permission for the 48th time. This was a product that wanted to be your second brain.

When a second brain creates privacy anxiety, people start shopping for a third brain.

Mistake 4: The rebuild broke too many old habits

In 2020, Evernote launched a rebuilt generation of apps across platforms. The strategic logic made sense. Maintaining multiple legacy apps is expensive. Technical debt grows quietly until one day your codebase looks like an archaeological dig with login buttons.

Evernote needed modernization.

But modernization is dangerous when users have years of workflows built into the old product.

Evernote’s own State of the Product update acknowledged that its releases had not gone as smoothly as hoped. Users complained about missing features, performance issues, offline limitations, export friction, and broken power-user workflows.

This is one of the hardest product management lessons:

A technically correct rewrite can still be a customer experience failure.

Engineers may see a cleaner architecture.

Users see a missing keyboard shortcut.

Product leaders may see a unified platform.

Users see the workflow they used every day suddenly gone.

For casual users, a missing feature may be mildly annoying. For power users, it can be catastrophic. A search operator, export format, local notebook, tagging behavior, or bulk-editing flow may represent years of muscle memory.

Changing that without enough continuity is not just a redesign.

It is eviction.

Mistake 5: Competitors became “good enough” or better

Evernote also suffered because the market got dramatically better.

Apple Notes became surprisingly capable. Microsoft OneNote remained powerful and deeply integrated into Microsoft’s ecosystem. Google Keep handled lightweight capture. Notion became the flexible workspace for teams and creators. Obsidian won over local-first, Markdown-loving power users. Bear, Craft, Joplin, Notesnook, UpNote, and others each found their niche.

The note-taking market stopped being “Evernote or chaos.”

It became a menu.

The Verge’s guide to the best note-taking apps shows how broad the category has become. Users can now choose based on privacy, simplicity, collaboration, local storage, Markdown support, AI features, price, or ecosystem fit.

That matters because Evernote’s switching costs used to be its moat. Once your archive lived there, leaving felt painful.

But when enough frustration accumulates, pain flips direction. Staying becomes more painful than leaving.

That is the moment a moat becomes a trap.

And users start building bridges out.

Mistake 6: The business became a turnaround story

Evernote’s decline was not only about product decisions. It was also about business pressure.

In 2022, Evernote announced that Bending Spoons would acquire the company. TechCrunch described the acquisition as the end of a long, uneven chapter for one of the most famous productivity apps.

Then in 2023, TechCrunch reported that Bending Spoons laid off 129 Evernote employees. The most revealing line came from an Evernote spokesperson, who said the company had been “unprofitable for years.”

That quote matters.

It reframes the story.

Evernote was not merely a beloved product that made some unpopular choices. It was also a business that struggled to convert love into sustainable economics.

This is the uncomfortable truth for many consumer productivity apps:

Being useful is not the same as being profitable.

Having millions of users is not the same as having a healthy business.

Being iconic is not the same as being inevitable.

Evernote had a huge brand, a loyal user base, and a clear use case. But the business model still became difficult enough that the product had to be reshaped around survival.

And survival rarely feels delightful to users.

The deeper failure: Evernote lost confidence

The common explanation is that Evernote failed because it became bloated.

That is partly true.

But the deeper failure was confidence.

Users lost confidence that Evernote would stay fast.

They lost confidence that pricing would remain reasonable.

They lost confidence that workflows would not break.

They lost confidence that privacy decisions would be handled carefully.

They lost confidence that Evernote was the safest place to put the next ten years of their notes.

That last point is crucial.

A note-taking app is not just competing for today’s note. It is competing for tomorrow’s trust.

Every time a user captures something important, they are making a small bet that the product will still serve them later. Evernote became a riskier bet.

Once that happened, competitors did not need to be perfect.

They just needed to feel safer, simpler, cheaper, or more aligned with the user’s needs.

Product lessons from Evernote

1. Protect the core promise

Evernote’s core promise was “remember everything.” That meant capture, sync, search, speed, and reliability had to be sacred.

Before expanding into new categories, product leaders need to ask:

Are we making the core stronger, or are we decorating around unresolved pain?

A product can survive missing nice-to-have features.

It cannot survive breaking the reason people hired it.

2. Do not monetize in a way that feels like a hostage situation

Charging for premium features is fair.

Charging users in a way that makes them anxious about years of accumulated data is dangerous.

The more personal the product, the more careful pricing changes must be. Notes, photos, files, and memories are emotionally different from analytics dashboards or CRM seats.

Nobody wants to feel like their grocery list and life plans are being held behind a velvet SaaS rope.

3. Rewrites must protect existing workflows

Technical debt matters. But so does workflow debt.

If users have spent years building habits around your product, a rewrite should not make them feel like strangers in their own house.

Modernization must come with migration paths, feature parity planning, communication, and empathy for power users.

Otherwise, “new and improved” becomes “new and where did everything go?”

4. Trust is a feature

Privacy, data portability, export options, offline access, and transparent communication are not legal or operational side quests.

They are product features.

Especially for software that stores personal knowledge.

Trust is not what users read in the privacy policy. Trust is what they feel when they decide where to write something important.

5. Competition does not need to beat you everywhere

Notion did not need to beat Evernote at classic note capture.

Apple Notes did not need to beat Evernote at advanced organization.

Obsidian did not need to beat Evernote at mainstream simplicity.

Each competitor only needed to win a specific user need better than Evernote did.

That is how category leaders lose: not all at once, but segment by segment.

Final thought: the elephant forgot the job

Evernote’s story is not just about a note-taking app. It is about what happens when a beloved product becomes too ambitious, too complex, too commercially pressured, and too inconsistent to preserve the thing users originally loved.

Evernote wanted to be a 100-year company. That was a beautiful ambition.

But lasting 100 years requires more than vision.

It requires protecting the core promise every single day.

For Evernote, that promise was simple:

Remember everything.

The irony is that Evernote’s biggest mistake may be that it forgot.

I embedded 10 external links directly in the post. The key factual points are supported by sources on Evernote’s early freemium model, user growth, pricing changes, privacy backlash, acquisition, layoffs, free-plan limits, and competitive landscape. (WIRED)

This guide gives you a practical, step‑by‑step plan. It blends an overview of the craft with specific actions you can take this week-plus quotes, research, and data to help you calibrate your approach.

Phase 1: Foundational Knowledge and Skill Development

Step 1: Deep Dive into the Fundamentals

Start by clarifying the role. A common misconception is that PMs are “mini‑CEOs.” As Julia Austin writes in Harvard Business Review, “PMs are not the CEO of product” because they have little direct authority over most functions needed to make products successful. (Harvard Business Review)

Marty Cagan (SVPG) offers a concise north star for PM responsibility: “As product manager, you’re responsible for ensuring that what gets built is both valuable and viable.” (Silicon Valley Product Group)

Read voraciously. Core books like Inspired (Marty Cagan) and Cracking the PM Interview (McDowell & Bavaro) build vocabulary and mental models. Supplement with blogs and newsletters (SVPG, Lenny’s Newsletter) and HBR articles on PM careers. For context on how the role has evolved (and why “output vs. outcomes” matters), browse SVPG’s pieces on empowered teams and the PM’s contribution. (Silicon Valley Product Group)

Follow industry leaders. The best PM content is living, not static. Keeping up with CPOs, growth leaders, and design leaders helps you absorb patterns, trade‑offs, and language quickly.

Listen and watch. Podcasts and recorded conference talks give you “apprenticeship at scale.” You’ll hear how practitioners reason-gold for interview prep and day‑to‑day decision‑making.

Step 2: Master Key Product Management Skills

Hard skills.

• Product strategy & roadmapping. Learn to define an outcome, choose a direction, and sequence bets. Frameworks like North Star help teams align around one value‑centric metric: “a single metric…that best captures the value customers derive from your product.” (info.amplitude.com)

• User research & analysis. Understand qualitative and quantitative methods. For lean usability testing, NN/g’s classic guidance is still useful: “The best results come from testing no more than 5 users and running as many small tests as you can afford.” (Use judgment: exploratory interviews often need more than five.) (Nielsen Norman Group)

• Prioritization. Master RICE (reach, impact, confidence, effort). “RICE is an acronym for the four factors we use to evaluate each project idea.” (Intercom)

• Discovery techniques. Practice Opportunity Solution Trees to connect outcomes → opportunities → solutions → experiments. (Teresa Torres’ guides are a great start.) (Product Talk)

• Metrics & analytics. Internalize AARRR (Pirate Metrics) and retention/activation relationships; as Brian Balfour puts it, “Retention is king.” Pair that mindset with a North Star and supporting input metrics. (Amplitude)

• Agile literacy. Learn Scrum and Kanban-not as religion, but as shared languages for delivery and flow. The 2020 Scrum Guide is the canonical definition of Scrum; Kanban University provides the official Kanban method overview. (Scrum Guides)

• Data skills (including basic SQL). Hiring signals have shifted: in 2024 data from Lenny’s newsletter found SQL, Jira, and LLM experience among the most requested hard skills for PMs. You don’t need to be a data scientist, but you should be able to independently pull, sanity‑check, and interpret basic data. (Lenny’s Newsletter)

Soft skills.

• Communication. You’ll translate customer needs and business constraints into clear, testable product decisions.

• Leadership through influence. You’ll rarely have direct authority, so you’ll build trust with design, engineering, and go‑to‑market partners (and stay in the room when trade‑offs get tough).

• Structured problem‑solving. Define the problem crisply, explore the opportunity space, converge on a plan, and measure.

• Empathy. Whatever you ship is for someone-develop an instinct for their context, constraints, and jobs to be done.

Step 3: Formalize Your Learning (Optional but Helpful)

Short courses and certificates can speed up your ramp, especially if they include portfolio projects and community. Pragmatic Institute’s 2024 State of Product Management & Marketing Report pegs the average reported salary of product professionals at $141,392 (pre‑bonus)-useful context for ROI thinking as you choose programs. (Pragmatic Institute - Corporate)

Phase 2: Gaining Practical and Auxiliary Experience

Step 4: Create Your Own Product (or Feature)

Nothing beats doing. Identify a real problem (yours, your team’s, a hobby community’s). Run a scrappy discovery loop. Then create a Minimum Viable Product. Eric Ries defines an MVP as the version that “allows a team to collect the maximum amount of validated learning…with the least effort.” (Emphasis on learning over features.) (Lean Startup Co.)

A lightweight build–measure–learn flow

1. Define the outcome (e.g., “reduce onboarding time by 30%”).

2. Map the opportunity space with an Opportunity Solution Tree. (Product Talk)

3. Prioritize with RICE; design a small, testable slice. (Intercom)

4. Prototype in Figma/Balsamiq and run 5 quick usability tests to surface obvious issues (iterate as needed). (Nielsen Norman Group)

5. Ship an MVP-even if it’s a concierge service, no‑code workflow, or “painted door” test.

6. Instrument your North Star + input metrics (activation, retention, time-to-value) and run weekly reviews. (Amplitude)

Document everything. Your case study should show the problem, constraints, options considered, the hypothesis you tested, your instrumentation, the result, and what you’d do next.

Step 5: “Productize” Your Current Role

You don’t need “Product Manager” in your title to behave like one. Treat internal processes, dashboards, or team rituals as mini‑products:

• Identify customers (your “users” might be sales reps, analysts, editors, or your support team).

• Interview and instrument. Quantify pain (e.g., SLA misses, rework rates).

• Co‑design solutions with your cross‑functional partners.

• Prioritize using RICE (or a simple cost/benefit + confidence model). (Intercom)

• Quantify your impact (e.g., reduced cycle time by 22%, cut errors by 35%). Recruiters and hiring managers respond to outcomes.

Tip: Anchor improvements to a North Star appropriate to the internal workflow (e.g., “time to first correct answer” for an insights team). (Amplitude)

Step 6: Freelance or Volunteer to Build Reps

Offer structured help to early‑stage startups or nonprofits: run discovery interviews, draft a lightweight roadmap, or instrument basic product analytics. Even a 4–8 week engagement can yield a strong, measurable case study-and references.

Phase 3: Networking and Launching Your PM Career

Step 7: Build Your Professional Network

Networking isn’t a hack; it’s how product work actually happens-through people, context, and trust. And it materially improves hiring outcomes. LinkedIn’s former CEO Jeff Weiner noted that candidates who asked for a referral on LinkedIn were “eight times more likely to get the job.” Independent recruiting data also shows referred candidates can be ~7× more likely to be hired than those from job boards. (WIRED)

Three high‑yield ways to network

• Informational interviews. Ten thoughtful 20‑minute conversations often beat 100 cold applications.

• Communities. Join product Slack groups, Mind the Product forums, local meetups, and virtual events.

• Give before you ask. Share a teardown, offer a small analysis, or connect two people-you’ll be remembered.

Step 8: Craft a Compelling Resume and Portfolio

Treat your resume like a one‑page product: every bullet should express a customer problem, your intervention, and the quantified outcome. (Yes, numbers matter; major job sites and career resources consistently recommend quantification because it communicates scale and impact at a glance.) (Indeed)

What to show:

• Transferable skills (prioritization, experimentation, stakeholder management) in product language.

• Case studies for your MVP and any “productized” internal initiatives: problem → options → decision rationale → metrics → learnings.

• Thought leadership: a short blog post, a 5‑slide teardown, or a public framework you used.

Calibration tip: When you reference compensation bands in negotiation prep, use multiple sources (e.g., Glassdoor, Levels.fyi) and match for level and location. At the high end, company‑specific disclosures and comp aggregators show wide ranges (e.g., total comp at large tech firms can exceed $500K at senior levels), while broader medians sit much lower. (Glassdoor)

Step 9: Prepare for-and Ace-Your Interviews

PM interviews generally probe four areas:

1. Product sense / design (understanding users, diagnosing problems, ideating and scoping)

2. Strategy (market sizing, competitive positioning, trade‑off thinking)

3. Analytics / metrics (defining success, instrumentation, interpreting ambiguous data)

4. Behavioral (stakeholder management, conflict, ownership)

Guides from Exponent and others outline this structure explicitly. Expect company‑specific flavors, too: for example, Google emphasizes product sense, strategy, analytics, and behavioral rounds; Amazon leans heavily on its Leadership Principles and “Bar Raiser” behavioral interviews. (Exponent)

A simple prep plan:

• Drills (daily): Do one product design and one metrics prompt; write structured answers (problem → user → goals → constraints → options → trade‑offs → metric).

• Frameworks (weekly): Practice RICE, AARRR, and North Star alignment until they’re second nature in whiteboard scenarios. (Intercom)

• Mocks (weekly): 45‑minute peer mocks or coaching sessions; record and critique your clarity, structure, and pacing.

• Company research (per interview): Know the product, business model, key metrics, and recent moves (launches, pricing changes, partnerships). Prepare insightful questions that signal you understand their users and constraints.

A 90‑Day Break‑In Plan (Simple, Aggressive, Realistic)

Days 1–30: Learn the language & ship your first case study

• Read Inspired and one PM interview guide (notes and flash cards).

• Complete an MVP project (even if no‑code). Ship a version, run 5 usability tests, iterate once, and publish a 1–2 page write‑up. (Lean Startup Co.)

• Start 10 informational interviews; ask for “one other person you recommend I meet.”

Days 31–60: Show product chops where you are

• “Productize” one process in your current role; instrument baseline metrics, launch a change, measure impact, and publish a brief internal report.

• Join one PM community; contribute one teardown or resource weekly.

• Begin mock interviews (1–2/week). Use prompts from reputable guides to practice product sense and metrics. (Exponent)

Days 61–90: Convert momentum into offers

• Polish your resume (outcomes first) and portfolio (2 case studies minimum).

• Target referral‑driven applications at 10–15 companies where your background is relevant; ask your network for warm intros. (Referrals consistently outperform cold applications.) (WIRED)

• Keep shipping small improvements to your MVP; demonstrate retention/activation movement with charts in your portfolio. (Amplitude)

Frequently Asked Real‑World Questions

Do I need a CS degree or to code?
No. Many PMs come from non‑technical backgrounds. That said, data fluency and the ability to partner deeply with engineers are increasingly non‑negotiable; SQL shows up frequently in job postings. (Lenny’s Newsletter)

Scrum or Kanban-what should I learn first?
Both. Scrum gives you the ceremony/vocabulary of iterative delivery; Kanban builds your intuition for flow and WIP. Knowing both makes you versatile across teams. (Scrum Guides)

What metrics should I care about?
Pick a North Star metric tied to customer value, then track input metrics like activation and retention. AARRR (acquisition, activation, retention, referral, revenue) is a good mental model to structure instrumentation. (Amplitude)

How do I prioritize when everything seems important?
Start with outcome clarity and constraints. Use RICE to stack‑rank bet sized ideas and run time‑boxed experiments. (Intercom)

Final Thoughts

If you take only three ideas with you, let them be these:

1. Own value and viability. Product managers aren’t mini‑CEOs; they’re accountable for value and viability, working in lockstep with design (usability) and engineering (feasibility). (Harvard Business Review)

2. Bias to small, fast learning loops. Use MVPs to validate the riskiest assumptions quickly; test early and often with small samples; measure what matters. (Lean Startup Co.)

3. Win through people. Build uncommon signal in your portfolio and use referrals to reach the room where decisions happen. The conversion lift is substantial. (WIRED)

With a strategic plan and consistent reps, you can absolutely transition into product management-without prior formal experience. The work starts today.

How to read this: Tuition figures are program-listed or program-calculated estimates (excluding living costs unless noted). Always confirm with the university, as fees change annually.

Quick-Compare (at a glance)

University

Degree

Duration & Format

Tuition (estimate)

Notable outcomes

Carnegie Mellon University (CMU)

MS in Product Management (MSPM)

~12 months, full-time, includes internship & capstone

$39,636 per semester (Spring & Fall) + $2,202summer internship credit → ≈ $81,474 tuition

Class of 2024: $152,500 median starting salary; 84% accepted offers within 6 months.

University of Maryland (UMD), A. James Clark School of Engineering

Master of Professional Studies (MPS) in Product Management

5 terms; designed so many complete in ~15 months; fully online with live sessions

$26,500 total, paid in five installments

Program materials cite strong PM market indicators (e.g., Glassdoor total pay and LinkedIn growth) and career support. (UMD Product Management)

Northwestern University (Segal Design Institute, McCormick)

MS in Product Design & Development Management (mpd²)

9 months(full‑time) or ~2 years (part‑time); Fri/Sat cohort schedule

$22,973 per quarter(2025‑26 full‑time master’s tuition); 3 quarters ≈ $68,919 (tuition only)

Alumni populate leadership roles across tech/consumer products; hands‑on, industry‑embedded curriculum. (Segal Design Institute)

Queen’s University (Smith School of Business), Canada

Master of Digital Product Management (MDPM)

12 months(hybrid: mostly online evenings + 2 short in‑person sessions)

CAD $44,580 (domestic); CAD $67,080 (international); includes on‑site accommodations & some meals during residencies

Program shares post‑grad salary data and employer list; designed for working professionals. (Smith School of Business)

University of Southern California (USC) – Viterbi School of Engineering

MS in Product Development Engineering (PDE)

Typically 1.5–2 years; on‑campus or online (DEN@Viterbi)

Per‑unit tuition $2,665 (2025–26); program requires 28 units → ≈ $74,620 tuition (plus fees)

Strong pathway to hardware/manufacturing/complex-systems PM roles across industries. (USC Viterbi | Prospective Students)

1) Carnegie Mellon University - MS in Product Management (MSPM)

Why it stands out: Co‑run by CMU’s Tepper School of Business and School of Computer Science, the MSPM is among the best known “pure PM” master’s degrees and packs strategy, UX/HCI, business, and tech into one year. The curriculum includes an internship (for credit) and a corporate‑sponsored capstone. The program’s own positioning is unambiguous: “MSPM is the best investment many aspiring product managers can make.”

Requirements to enter (high level): Application with resume, transcripts, one essay, one recommendation; English proficiency (TOEFL/IELTS/Duolingo) unless waived; the site also supports GMAT/GRE submissions with a test‑score waiver option.

Duration: ~12 months (January cohort: spring–summer–fall) with internship for credit in summer.

Cost: $39,636 per semester for Spring and Fall; $2,202 for the summer internship course → ≈ $81,474 tuition for the one‑year track (fees/living additional).

Career impact: Class of 2024 reporting shows a $152,500 median starting salary with 84% of graduates accepting offers within six months-reported under MBA CSEA standards.

Student & third‑party voices:

• CMU’s own overview emphasizes ROI and Pittsburgh’s affordability.

• “I really recommend this program… loved the capabilities [MSPM candidates] bring to the table.” - a Tepper MBA alum on GMAT Club (shortened). (GMAT Club)

• Poets&Quants features on the MSPM (video interviews with program staff/alumni) offer external context on curriculum and outcomes. (YouTube)

Best for: Candidates targeting software/tech PM roles who want an accelerated, cross‑disciplinary PM credential with strong brand and employer access.

2) University of Maryland - MPS in Product Management

Why it stands out: A fully online master’s built by the Clark School of Engineering with a five‑term structure that working professionals can finish in ~15 months (or stretch longer). The site underscores affordability and flexible financing.

Requirements to enter: Simple checklist-statement of purpose, resume, transcript. No GRE/GMAT or recommendations required. English‑language testing may be required for some international applicants.

Duration: Designed across five terms; many finish in ~15 months.

Cost: $26,500 total tuition, payable in five installments at the start of each term. (UMD Product Management)

Career impact: Maryland presents current market data-high PM compensation and demand (e.g., Glassdoor total pay; LinkedIn job growth)-and integrates career‑advancement messaging into the program design. (As always, verify current labor data for your geography.)

Student & third‑party voices:

• “[A] meticulously designed curriculum tailored to equip you with the essential skills to navigate every aspect of [the] product lifecycle.” - student highlight (shortened).

• Background on how the program grew from Maryland’s product‑management initiatives (and edX partnership) provides additional outside context. (edX Press)

Best for: Cost‑sensitive, full‑time working professionals seeking a credible, structured PM degree without relocating; also a fit if you value live online instruction.

3) Northwestern University - MS in Product Design & Development Management (mpd²)

Why it stands out: Housed in the Segal Design Institute (McCormick School of Engineering), mpd² blends business, design, engineering, and product leadership. Students meet on Fridays/Saturdays (FT) or one day per week PT, which keeps learning close to work.

Requirements to enter: The cohort typically includes mid‑ and senior‑level professionals with at least two years of experience in product design/development. (Formal application items are standard graduate materials.)

Duration & format: 9‑month full‑time option (or ~2 years part‑time), with a cohort schedule designed for immersion while maintaining professional momentum. (Segal Design Institute)

Cost: Northwestern lists $22,973 per quarter (2025–26) for full‑time master’s (3–4 units); three quarters of full‑time study is about $68,919 in tuition (exclude fees/living). (Northwestern University)

Career impact: Alumni land in product, design, and innovation leadership across top companies; the program is explicitly designed to “assure our graduates a pathway to senior management.”

Student & third‑party voices:

• “I bring everything from my time in the program to my day job.” - Amber Hall, Director of Product Management (shortened).

• Community discussions and profiles on outside sites (e.g., educations.com) frame the program’s blend of innovation, market research, and project/product management for leadership roles. (

https://www.educations.com

• )

Best for: Builders who want a design‑ and development‑intensive product leadership master’s with a compact (9‑month) on‑campus cadence.

4) Queen’s University (Smith School of Business, Canada) - Master of Digital Product Management (MDPM)

Why it stands out: A 12‑month hybrid program aimed at working professionals: evening virtual classes plus two short, in‑person sessions (Kingston/Toronto). The School explicitly ties curriculum to digital transformation and enterprise product leadership.

Requirements to enter: Bachelor’s degree (minimum B+), typically 2+ years of relevant experience; English proficiency where applicable. GMAT not required (may be recommended). WES evaluation for non‑North American degrees.

Duration & format: 12 months (May–May), virtual evenings (Tues/Wed) and select Saturdays, plus two on‑site residencies.

Cost: CAD $44,580 (domestic) and CAD $67,080 (international); on‑site accommodations & some meals during residencies are included. (Airfare/local transport not included.) (Smith School of Business)

Career impact: Smith shares an employer roster and salary outcomes for the program; the MDPM is embedded in one of Canada’s best‑known business schools. Program leadership captures the ethos well: “As we move deeper into the digital era, we have to think about the world through the lens of how things are connected.” (shortened). (Smith School of Business)

Best for: Professionals in Canada/US who want a work‑compatible, hybrid master’s with a strong business‑school home and enterprise‑scale digital product focus.

5) University of Southern California (USC), Viterbi - MS in Product Development Engineering (PDE)

Why it stands out: A systems and engineering‑heavy graduate program for those building physical and complex, software‑enabled products (aerospace, automotive, hardware, logistics, robotics, etc.). Available on‑campus or online via DEN@Viterbi with the same academic standards. (USC Viterbi | Prospective Students)

Requirements to enter: Bachelor’s in engineering or science, minimum 3.0 GPA, and completion of 28 units(thesis/directed research options available). Recent admissions pages indicate GRE not required for 2026 master’s intakes (confirm for your term). (USC Catalogue)

Duration: Typically 1.5–2 years depending on pace and unit load. (USC Viterbi | Prospective Students)

Cost: USC Viterbi’s 2025–26 per‑unit rate is $2,665; 28 units → ≈ $74,620 tuition (plus university fees and health insurance). (USC publishes separate PDFs showing per‑unit rates and sample totals by program unit count.) (USC Viterbi | Prospective Students)

Career impact: Graduates span industries from aerospace to medical devices and advanced manufacturing-ideal if you expect to own hardware + software product lifecycles in regulated or safety‑critical contexts. (USC Online)

Third‑party note: International admissions sites and rankings (e.g., QS) provide additional independent snapshots of USC’s graduate reputation and typical master’s program costs. (Top Universities)

What students and the broader community say (brief picks)

• CMU MSPM (external): GMAT Club: “Recommend this program… loved the capabilities [candidates] bring.”(alum comment, shortened). Poets&Quants spotlights curriculum/employment in video features. (GMAT Club)

• UMD MPS PM (external): edX’s announcement explains how the degree leverages online delivery and stackable learning (useful color for prospective online students). (edX Press)

• Northwestern mpd² (external): Program profiles on educations.com and public alumni stories describe its innovation + leadership focus; prospective‑student forums often compare mpd² with MBAs depending on career goals and geography. (

https://www.educations.com

• )

Program-site testimonials (shortened):

• “MSPM is the best investment many aspiring product managers can make.” - CMU MSPM.

• “I bring everything from my time in the program to my day job.” - Northwestern mpd² alum.

• “A meticulously designed curriculum [for] every aspect of the product lifecycle.” - UMD MPS student.

• “Think about the world… through the lens of how things are connected.” - Queen’s MDPM co‑director. (Smith School of Business)

Which degree fits you?

• Choose CMU MSPM if you want a brand‑name, one‑year PM degree with robust tech + design + businessintegration and strong placement momentum into software/tech PM. The tuition is higher-but so are documented early‑career outcomes.

• Choose UMD’s online MPS if you’re optimizing for price + flexibility while still getting a structured PM master’s from an R1 public research university. The five‑term cadence is particularly friendly to working professionals.

• Choose Northwestern mpd² if your target roles straddle product leadership + design/development and you value cohort‑based, on‑campus learning with a compact 9‑month FT path. (Segal Design Institute)

• Choose Queen’s MDPM if you want a work‑compatible, hybrid master’s with a North American business school brand and digital product emphasis-especially if you’re based in or near Canada.

• Choose USC PDE if your products are multi‑disciplinary, engineered systems (e.g., aerospace/medical/robotics) and you need deeper coverage of the engineering and operations side of product development. (USC Online)

A few practical notes on ROI

• Map total cost to realistic time‑to‑role. For CMU’s MSPM, tuition of ~$81.5k targets a 12‑month pivot with strong outcomes; for UMD’s MPS, $26.5k over ~15 months is one of the lowest‑cost credible PM master’s paths. (Both exclude living costs.)

• Check reporting standards and sample sizes for outcomes (CMU notes MBA CSEA standards for transparency). Also ask for most recent employment reports during info sessions.

• Consider industry fit. USC’s PDE is exceptional if you’ll manage physical plus software products; Northwestern mpd² often resonates with design‑forward PMs headed to consumer and industrial companies; CMU MSPM is laser‑focused on software tech PM. (USC Online)

Final checklist before you apply

1. Validate the latest tuition and fees (and health insurance) for your entry term; many schools adjust rates annually. (Northwestern University)

2. Ask about waivers (e.g., test scores) and scholarships-MSPM and mpd² both reference scholarship or aid guidance. (Segal Design Institute)

3. Talk to current students/alumni. Programs frequently host info sessions; independent forums (GMAT Club, Reddit) offer candid perspectives. (GMAT Club)

4. Align the format to your life. CMU (on‑campus, 12 months); UMD (online, 5 terms); Northwestern (on‑campus cohort days); Queen’s (hybrid evenings + two residencies); USC (on‑campus or online). (Segal Design Institute)

Below is a practical, funny‑but‑serious guide to frameworks (SWOT, Five Forces, strategy canvas, perceptual maps), feature benchmarking that doesn’t devolve into parity theater, and a grab‑bag of tools-from Semrush to Wappalyzer-to turn raw intel into strategic advantage.

Why do competitive analysis at all?

Because it gives you context-industry structure, buyer power, substitutes, and where you can credibly zag while others zig. Porter’s Five Forces remains a sturdy lens for understanding the “extended rivalry” that shapes profits. Use it to diagnose where pressure comes from before deciding how to respond. (Harvard Business Review)

But don’t mistake competitor watching for a strategy. Porter warned decades ago that strategy isn’t the same as operational effectiveness. Uniqueness beats “best practices” every time. (Harvard Business Review)

“Don’t worry about competition. It means you picked a good market.” - an HN oldie that still slaps. (Hacker News)

Step 1: Define your arena (and your real competitors)

Map three circles:

1. Direct: Same job, same buyer (you vs. “the usual suspects”).

2. Indirect: Different solution for the same job (your product vs. spreadsheets, agencies, or outsourcing).

3. The Status Quo: In many markets, your biggest rival is nothing (inertia).

Jobs‑to‑Be‑Done (JTBD) keeps this honest: customers “hire” products to make progress in specific circumstances. Start there, not with feature catalogs. (Harvard Business Review)

HN wisdom: “Launch something that works… then learn from users. That’s priceless.” (Hacker News)

Step 2: Use frameworks that force clarity (not busywork)

A) SWOT (Strengths, Weaknesses, Opportunities, Threats)

SWOT is simple and widely used-but treat it as a snapshot, not scripture. Its origins are debated (Albert Humphrey at SRI vs. earlier Harvard strands), which is a polite way of saying: the tool isn’t the point; how you think is. Use it to converge on a few decisive moves, not to generate a 12‑page parking lot. (Emerald, Marketing Teacher)

Redditors put it plainly:

“Do a SWOT on new competition… give yourself an educated view, not an emotional one.” (Reddit)

B) Porter’s Five Forces

For each force-rivalry, new entrants, substitutes, supplier power, buyer power-write a one‑line threat, a one‑line opportunity, and the metric you’ll watch (e.g., CAC trend, switching cost proxy, retailer margin asks). This converts theory to a scoreboard. (Harvard Business Review)

C) Blue Ocean’s Strategy Canvas (+ ERRC)

Plot the factors your industry competes on (horizontal axis) vs. your and competitors’ offering levels (vertical). Then run the Eliminate–Reduce–Raise–Create (ERRC) Grid to articulate a divergent value curve. (If this sounds artsy, remember: [yellow tail] outsold rivals by eliminating wine‑snob complexity and raising fun.) (Blue Ocean Strategy)

D) Perceptual Maps

These visualize customer perception (e.g., easy ↔ powerful, price ↔ breadth). Use them to track whether your positioning is landing, not just announced. Harvard’s online explainer is a handy primer. (Harvard Business School Online)

Reddit PM tip: “PoP vs. PoD matters-Points of Parity you must match; Points of Difference you must defend.” (Reddit)

Step 3: Feature benchmarking-without becoming a parody

A giant matrix is inevitable. Here’s how to keep it sane:

• Scope it to the top 5–7 jobs customers pay for.

• For each job, score competitor approaches on outcome quality, effort, and risk, not just existence.

• Annotate Parity / Win / Lose and Compete / Not Compete-because it’s often rational to not fight every battle. (A PM on Reddit shared exactly this pattern and it works.) (Reddit)

Two reality checks:

• Feature bloat is real. Pendo found ~80% of software features are rarely or never used. Parity‑chasing is the road to product obesity. (Pendo.io)

• “Better product” ≠ moat. HN: “Simply having a better product isn’t a moat.” Distribution, switching costs, and network effects are. Keep your eyes on those. (Hacker News)

On moats, NFX’s study argues ~70% of tech value creation since 1994 came from network effects-which should make you benchmark network density and retention, not just features. (NFX)

HN quip: “A startup worrying about competitors is like a fat guy worrying about West Nile.” Translation: build value first. (Then do the analysis right.) (Hacker News)

Step 4: Tooling-your competitive intelligence stack

Think channels, content, tech stack, and change‑detection.

Traffic & keyword intel

• Semrush: domain/traffic comparisons, organic & paid keywords, ad copies, and trendlines. Great for benchmarking your SEO/paid share. (Semrush)

• Similarweb: traffic sources, referral flows, geography, engagement-fast directional reads on competitor growth. (Similarweb)

• Ahrefs Site Explorer: backlink graph + keyword footprints to reverse‑engineer what drives rivals’ organic visibility. (Ahrefs)

Tech stack & pricing

• BuiltWith or Wappalyzer: fingerprint web tech (payments, analytics, A/B testing, CDNs) and monitor changes; Wappalyzer even offers alerts. (BuiltWith, Wappalyzer)

• Wayback Machine + its Changes view: compare snapshots of competitor pages, see pricing/messaging edits over time. (Yes, it now highlights differences.) (wayback.archive.org, TNW | The heart of tech)

Category & review signals

• G2 and Gartner Peer Insights: watch your category grid, top alternatives, and qualitative “why we switched” comments. Useful for validation-not gospel. (G2 Documentation, Gartner)

• Capterra: broad category coverage; handy to verify who buyers are shortlisting. (Capterra)

Caveat emptor: all third‑party traffic/keyword estimates have error bars. Use trends and relative comparisons, not absolute numbers.

Step 5: Distribution shifts are competitors too (hello, “zero‑click”)

You’re not just competing with companies-you’re competing with platform changes. For example, Similarweb reported that since Google’s AI Overviews launch (May 2024), the share of news‑related searches ending in zero‑clicks rose from 56% → ~69% year‑over‑year to May 2025; ChatGPT referrals to news sites grew ~25×, but didn’t offset the loss. Competitive analysis that ignores distribution is missing the plot. (Similarweb, TechCrunch)

So what? If SEO is a major channel, your benchmarking must include SERP features (AIO, snippets), content atomization for chat answers, and brand demand creation beyond search. Track “click‑through per impression” by query class, not just rank.

Step 6: Turn insights into strategy, not slideware

Here’s a six‑move playbook to convert analysis into advantage:

1. Positioning that bites
   Use the strategy canvas to craft a sharp tagline that communicates your divergence (“simple wine for everyday fun”‑style clarity). Pair with a perceptual map to verify customers actually perceive it. (Blue Ocean Strategy, Harvard Business School Online)

2. Selective parity, aggressive differentiation
   Close minimum viable parity gaps (security, compliance, critical integrations), then over‑invest where you can be undeniably best. Reddit PMs warn: “Feature parity… is a lost cause” if it’s not tied to strategy. (Reddit)

3. Exploit rival blind spots
   Look for segments incumbents ignore due to channel conflicts or cost structure. (Reddit’s entrepreneurs: “Find aspects of the market bigger players aren’t interested in.”) (Reddit)

4. Build moats deliberately

   • Network effects: instrument invitations, liquidity, and same‑side/cross‑side growth.

   • Switching costs: honest ones like data migration, API ecosystems, workflows.

   • Distribution: partnerships and PLG loops; HN notes “distribution moat” is real. (Hacker News, NFX)

5. Price to win your position
   Price for your strategy, not your competitor’s spreadsheet. (Undercutting is easy; sustaining margins isn’t.) Use win/loss interviews to calibrate value/price trade‑offs by segment. Industry surveys report 63% of companies see win‑rate lifts from formal win/loss, rising to 84% for mature programs. (Clozd)

6. Close the loop: win/loss + sales enablement
   Feed insights into competitive battlecards, objection handling, and product bets. As one Klue roundup summarized, a majority of senior leaders report win/loss makes sales cycles more effective-because you align on what buyers actually care about. (Klue)

A one‑week competitive analysis sprint (template)

Day 1 - Define scope & hypotheses

• Pick top 3–5 jobs and segments.

• Write your hypothesis: “We win when…; we lose when…”

• Choose metrics: win rate vs. X, CAC vs. Y, payback, NPS by segment.

Day 2 - Industry structure & rivals

• Five Forces brief (one slide each).

• Competitor map: direct / indirect / status quo + buyer personas. (Harvard Business Review)

Day 3 - Strategy canvas + ERRC

• Plot you vs. 3 core rivals across factors; propose eliminate/reduce/raise/create. (Blue Ocean Strategy)

Day 4 - Feature benchmarking

• Outcome‑based matrix with Parity/Win/Lose & Compete/Not Compete columns.

• Call out “we choose not to compete” areas explicitly (and why). (Reddit)

Day 5 - Channels & content

• Semrush/Ahrefs/Similarweb pulls for traffic, keywords, and ads;

• Pricing page diffs via Wayback “Changes”; tech stack via Wappalyzer. (Semrush, Ahrefs, Similarweb, TNW | The heart of tech, Wappalyzer)

Day 6 - Win/Loss interviews

• 8–12 short calls across won and lost deals; code reasons and decision criteria. Summarize 5 “why we win” and 5 “why we lose” patterns. (Even light programs measurably lift win rates.) (Clozd)

Day 7 - Decisions

• Keep / Kill / Invest on features.

• Messaging & pricing updates.

• Next‑quarter experiments (one acquisition, one activation, one retention).