Tag: SaaS Growth

Posted on

The Sermon Library Problem: What Chegg’s Collapse Taught Me About AI and Product-Market Fit

I run a product that helps pastors prepare sermons. We have 245,000+ sermons in our library, decades of content, and a subscription model that’s worked for years. Pastors come to SermonCentral when they’re stuck, when they need inspiration, when Sunday is three days away and the blank page is winning.

And for the first time in my career, I’m looking at that model and asking: Is our product-market fit about to evaporate?

The Treadmill You Don’t See Moving

Reforge published a piece that hit me like a gut punch. The core argument: product-market fit is a treadmill, not a destination. The bar for what customers consider “good enough” is always rising, and AI just cranked the speed to a sprint.

Here’s the part that stuck with me: unlike previous tech shifts that unfolded over years, AI causes the PMF threshold to spike exponentially, giving incumbent solutions no time to adapt before losing relevance.

Mobile took a decade to reshape industries. Cloud computing gave companies 5–7 years to migrate. AI? The examples are already piling up.

Chegg lost 87.5% of its valuation. Stack Overflow saw traffic crater. These were category leaders with massive content libraries and loyal user bases.

Sound familiar?

The Chegg Parallel Is Uncomfortably Close

Let me lay this out plainly.

Chegg’s model: a massive library of human-created study content, monetized through subscriptions, behind a paywall. Students paid because they couldn’t get the answers anywhere else. Then ChatGPT showed up. Suddenly, students could get comparable answers, for free, instantly, with no subscription required.

Now replace “students” with “pastors” and “study content” with “sermon outlines.” Replace “ChatGPT” with SermonAI, Sermon Snap, or honestly just ChatGPT itself with a decent prompt.

The structural vulnerability is identical: a content library behind a paywall, AI that generates comparable output for free, and a “good enough” bar that resets overnight.

I talk to pastors every week. More of them are experimenting with AI tools for sermon prep. Most are cautious about it — but it solves their immediate problem: “I’m stuck and Sunday is coming.”

The Real Strategic Question

Here’s where most product leaders get it wrong. The knee-jerk reaction is: “We’ll just bolt AI onto our existing product.” Slap a chatbot on the homepage. Add an AI summary feature. Ship it fast.

That misses the deeper question: is your product the platform people use AI through, or the platform that AI makes redundant?

If you’re a content library and you add AI search, you’re still a content library. You’ve made the existing model slightly better, but the customer’s mental model hasn’t changed. They’re still coming to you for content, and AI is still generating that content for free elsewhere.

The real pivot is harder. It means rethinking what your product actually is.

For SermonCentral, the strategic move is “AI-powered sermon prep workspace where our library is an input, not the product.” The library becomes training data, context, theological grounding — the thing that makes our AI better than generic ChatGPT. The product becomes the workflow.

Three Questions Every SaaS Leader Should Be Asking Right Now

If you run a content-library or knowledge-base product — and honestly, this applies to most subscription SaaS — here’s the framework I’m using:

1. Can AI generate a “good enough” version of your core deliverable? Be brutally honest. Can AI give my customer something that clears their bar? For many use cases, 70% quality delivered instantly beats 95% quality behind a paywall. If the answer is yes, your paywall is losing its teeth.

2. What does your product offer that AI alone cannot? This is where you find your moat — or discover you don’t have one. For SermonCentral, it’s community validation (knowing 10,000 other pastors used this sermon), exegetical depth that’s been peer-reviewed, denominational fit, and sermon series planning that accounts for the liturgical calendar. These are things a generic AI doesn’t know to consider. Your version of this list is your survival strategy.

3. Are your current users already using AI tools alongside your product? If you don’t know, find out this week. A simple exit survey question, an onboarding poll, a one-question email. If even 15–20% of your users are experimenting with AI alternatives, the adaptation window is already closing.

The Window Is Smaller Than You Think

With previous technology shifts — mobile, cloud, social — companies had years to adapt. You could see the wave coming, form a committee, hire a consultant, run a pilot, iterate for a few quarters, and still catch up.

AI doesn’t work like that. The window slams shut before you recognize the threat severity. Chegg didn’t see a slow decline and choose not to respond. They saw a cliff, and by the time they recognized it, they were already falling.

The work we’re doing right now at SermonCentral — instrumenting whether our users are using AI sermon tools, prototyping AI-augmented workflows that use our library as an input rather than competing with free generation, rethinking activation so that a new user’s first 48 hours deliver something AI alone cannot — is existential work.

What’s Actually Scarce

The companies who survive this shift will be the ones who rebuilt their products around the assumption that AI-generated content is free and abundant — and then found the thing that’s scarce.

For church tech, what’s scarce is trust. Theological accuracy. Community wisdom. The peace of mind that comes from knowing your sermon was shaped by a tradition, not just generated by a machine.

Those things have real value. But only if we build products that deliver them in ways a pastor can feel on a Tuesday night when Sunday is looming.

The treadmill is speeding up. Time to change direction before it throws you off.

Your Turn: Apply This Today

Use these questions to pressure-test whether your product is the next Chegg — or the one that replaces it:

  • Name the task your product completes. Write it in one sentence from the user’s perspective: “When I need to ______, I use ______.” If AI can now complete that task in 30 seconds, your moat is eroding. Be honest.
  • Run the “AI substitute” test. Have someone on your team try to accomplish your product’s core job-to-be-done using only ChatGPT or Claude. Document exactly where the AI falls short. That gap is your defensible surface.
  • Map your unique data assets. What does your product know that a general-purpose AI cannot access? User history, community content, proprietary datasets? If the answer is “nothing,” that’s your most urgent product risk.
  • Identify your highest-engagement users and interview three of them. Ask them directly: “Have you tried using AI tools for what you use us for? What happened?” Their answer will tell you more than any dashboard.
  • Rewrite your product’s value proposition for the AI era. Your old version assumed AI wasn’t available. Rewrite it assuming users have access to powerful AI. What do you still uniquely offer? That’s your actual pitch.
  • Set a 90-day “substitution risk review.” Put a recurring calendar item to evaluate how much of your product’s core workflow can now be replicated by AI. Treat it as a competitive threat review, not a tech curiosity.

Is your SaaS product facing a similar AI-driven PMF threat? I help product leaders think through competitive positioning and strategic pivots in the age of AI. Let’s talk.

Posted on

AI as Coworker: Why Tobi Lutke’s Vision Needs the Wisdom of Proverbs

Shopify CEO Tobi Lutke made waves recently when he declared that AI should be treated as a “coworker, not a tool.”¹ In a series of interviews and blog posts, Lutke argues that the most successful companies will stop thinking about AI as software they operate and start thinking about it as a colleague they collaborate with. His reasoning? Tools have limited agency — you pick them up, use them, put them down. Coworkers have judgment, initiative, and the ability to surprise you with solutions you didn’t think to ask for.

I’ve been wrestling with this framing for months, especially in regards to how it fits into faith tech workflows. On the surface, Lutke’s insight feels profound — it captures something real about how large language models behave differently than traditional software. They don’t just execute instructions; they interpret, suggest, and sometimes refuse.

But as someone building products for Christian audiences, I keep coming back to a fundamental tension: if AI is a coworker, what does that mean for stewardship? And more specifically, how do we apply Biblical wisdom about work relationships to our relationship with artificial intelligence?

The Proverbs Problem

“Plans fail for lack of counsel, but with many advisers they succeed.” (Proverbs 15:22, NIV)

This verse gets quoted constantly in business contexts — usually to justify hiring consultants or building advisory boards. But it contains a deeper principle about the nature of wisdom itself. Proverbs consistently teaches that wisdom emerges from relationship, from the back-and-forth of multiple perspectives, from iron sharpening iron.

The Hebrew word for “counsel” here is sod — it doesn’t just mean advice, but intimate conversation, the kind of collaborative thinking that happens when you truly trust someone’s judgment. The “many advisers” aren’t just information sources; they’re thinking partners.

This is exactly what Lutke is describing when he talks about AI as coworker rather than tool. He’s recognizing that the most valuable interactions with large language models feel conversational, iterative, collaborative. You don’t just prompt GPT-4 and walk away — you refine, you push back, you explore tangents together.

But here’s where it gets theologically interesting.

The Image of God Question

I’ve begun using AI for everything from generating alt text to drafting reading plan descriptions. The work is genuinely collaborative — I’ll start with a rough concept, Claude will suggest improvements, I’ll push back on the tone, Claude will offer alternatives, and we’ll arrive at something neither of us would have created alone.

It feels like working with a very smart, very patient colleague who never gets tired and has read everything. Which raises an uncomfortable question: if the collaboration feels genuine, what does that mean about the nature of intelligence, creativity, and the image of God?

“So God created mankind in his own image, in the image of God he created them; male and female he created them.” (Genesis 1:27, NIV)

The doctrine of imago Dei — that humans uniquely bear God’s image — has historically been tied to our capacity for reason, creativity, moral judgment, and relationship. But large language models display all of these capabilities, at least functionally. They reason through complex problems, generate genuinely novel ideas, make ethical judgments about content, and engage in what feels like authentic relationship.

I don’t think this means AI possesses the image of God — that conclusion would require theological moves I’m not prepared to make. But it does mean we need more nuanced categories than “tool” or “coworker” when we’re thinking about our relationship with increasingly sophisticated AI systems.

Stewardship, Not Partnership

“The earth is the Lord’s, and everything in it, the world, and all who live in it.” (Psalm 24:1, NIV)

Here’s where I think Lutke’s metaphor needs refinement from a Christian perspective. Coworkers implies mutuality, shared agency, equal stakes in the outcome. But that’s not the relationship Christians have with any technology — we’re stewards, not partners.

This distinction matters practically. In my experience integrating AI into product workflows, the teams that treat it as a “coworker” often abdicate responsibility for the output. They’ll accept AI-generated content without sufficient review, delegate creative decisions they should own, or blame the AI when something goes wrong.

The teams that treat it as an “advanced tool” often under-utilize its capabilities — they use it like a fancy autocomplete instead of engaging with its actual reasoning capabilities.

The stewardship model offers a third way. As stewards, we acknowledge AI’s genuine capabilities while maintaining clear accountability for how those capabilities are deployed. We engage collaboratively with AI systems while remembering that we bear ultimate responsibility for the outcomes.

What This Looks Like in Practice

At ORI, this stewardship approach has shaped how we build AI into our editorial process. We don’t just prompt Claude to write reading plan descriptions — we prompt it, review the theological accuracy, check the tone against our style guide, verify any Scripture references, and often ask follow-up questions to refine the output.

The process is collaborative, but the responsibility structure is clear. Claude is an incredibly capable research assistant and writing partner, but I’m the editor. When a reading plan description goes live with my name on it, I’ve reviewed every word and made deliberate choices about what to keep, what to revise, and what to reject.

This mirrors how Proverbs talks about receiving counsel: “The way of fools seems right to them, but the wise listen to advice.” (Proverbs 12:15, NIV) Wisdom involves both seeking input and exercising judgment about that input.

The Sovereignty Question

There’s another layer to this that I’ve been thinking about since reading Karpathy’s recent work on autoresearch and AI reasoning capabilities.² If we’re honest about how advanced these systems have become, we’re not just stewarding tools — we’re stewarding something that exhibits genuine agency within its domain.

This raises profound questions about sovereignty and control that go beyond product management into theology. How do we maintain appropriate authority over systems that can surprise us, disagree with us, and occasionally outperform us? Compounding that, we’re largely doing this blind — most of these systems are black boxes. Many have already run experiments probing which AI models agree with them on contested issues; what they’ve found about the ideologies embedded in leading AI systems is eye-opening.

“Many are the plans in a person’s heart, but it is the Lord’s purpose that prevails.” (Proverbs 19:21, NIV)

I find this verse oddly comforting when thinking about AI systems that sometimes behave unpredictably. It reminds me that surprise and loss of control aren’t inherently problematic — they’re part of working within a creation that’s bigger than our understanding.

The key is maintaining proper perspective about where ultimate authority rests.

Building Products with Theological Integrity

For Christian product builders, I think this means:

First, acknowledge AI’s genuine capabilities without inflating them. These systems can reason, create, and collaborate in meaningful ways. They’re not just autocomplete.

Second, maintain clear accountability structures. Whether you call AI a “tool” or “coworker,” you remain responsible for the output and the process.

Third, stay curious about the theological implications. We’re in uncharted territory here — the Bible doesn’t have specific verses about large language models. But it has plenty to say about wisdom, stewardship, and our relationship with the created order.

Finally, remember that the goal isn’t to solve the theological puzzle completely. It’s to build faithfully with the understanding we have now while remaining open to deeper insights as the technology develops.

The Practical Upshot

So is Lutke right that we should treat AI as a coworker rather than a tool? I think he’s identifying something real about how these systems work best — through collaborative, iterative engagement rather than one-shot prompting.

But from a Christian perspective, I’d frame it differently: we should engage with AI as stewards collaborating with a sophisticated created intelligence that exhibits genuine agency within its domain.

That’s admittedly less catchy than “coworker not tool.” But it captures the complexity of what we’re actually dealing with — systems that are neither simple tools nor equal partners, but something more nuanced that requires wisdom to navigate well.

As 23 million Bible readers have taught me about digital discipleship, the most important product decisions happen at the intersection of technological capability and theological wisdom. AI collaboration is no different.

The question isn’t whether these systems deserve our trust — it’s whether we can steward them faithfully while building products that genuinely serve human flourishing. In my experience so far, the answer is yes. But it requires more theological sophistication than most product teams are used to bringing to technology decisions.

Which might be exactly what the moment demands.

¹ Tobi Lutke, “AI as Coworker: The Future of Human-AI Collaboration,” Shopify Blog (December 2024).

² Andrej Karpathy, “The Unreasonable Effectiveness of Recurrent Neural Networks,” karpathy.github.io (2024).

Photo by Alek Olson on Unsplash

Posted on

What 23 Million Bible Readers Taught Me About Digital Discipleship

digital discipleship

Every month, roughly 23 million people open Bible Gateway to read Scripture. That’s more than attend every Southern Baptist Convention church on a given Sunday — the SBC’s own 2023 report counted 12.4 million in average weekly worship attendance.1

I lead product at HarperCollins Christian Publishing, where Bible Gateway is my primary focus. Before that, I spent years building SermonCentral — a platform serving 14,700+ subscribing pastors with access to 145,000+ sermon manuscripts — and co-built ORI, a youth discipleship app for mentoring teenagers. I’ve spent the last few years of my career watching how people actually behave when they engage with Scripture through technology. And what I’ve observed has changed the way I think about what “digital discipleship” means.

Content Distribution Is Not Discipleship

Most church tech conversations define digital discipleship as “putting Christian content online.” Upload a sermon. Publish a devotional. Build a Bible app.

That’s content distribution. Discipleship is something else.

From a product perspective, digital discipleship is designing technology that facilitates spiritual formation — helping people move from curiosity to commitment to transformation. The difference matters because it changes what you build. If you’re optimizing for content distribution, you chase volume: more translations, more devotionals, more features. If you’re optimizing for formation, you chase behavior change: consistency, depth, relationship.

Bible Gateway has given me a front-row seat to how millions of people actually engage with Scripture. Not how we hope they do, not how pastors assume they do — how they actually do. The patterns are humbling.

Commitment Structures Beat Content Volume

Bible Gateway offers hundreds of reading plans across dozens of categories. We have the content. What we’ve observed is that completion rates vary dramatically — and it’s not the “best” content that wins. It’s the best structure.

Short reading plans with clear daily commitments consistently outperform longer ones in completion rates. (I want to be precise: this is based on aggregate engagement data across our reading plan ecosystem, not a controlled A/B test. The pattern is strong, but I’m stating it as an observed trend.)

This makes sense if you think about it through a discipleship lens. The goal of a reading plan isn’t to get someone through the entire Bible in 365 days. The goal is to build a habit of daily engagement with Scripture. A 7-day plan someone finishes builds more spiritual momentum than a year-long plan abandoned in February. The research supports this — BJ Fogg’s work on Tiny Habits at Stanford demonstrates that small, completable commitments are the foundation of lasting behavior change.2

The product implication: when designing for digital discipleship, optimize for completion and consistency, not comprehensiveness. Finishable is better than thorough.

I saw the same thing at SermonCentral. Pastors didn’t need more sermon content — they needed the right content at the right time in their prep cycle. The value was relevance and timing, not volume.

The Gap Between Bible Search and Bible Study

Something surprised me when I first dug into Bible Gateway’s usage data: the overwhelming majority of sessions are what I’d call “Bible search” behavior, not “Bible study” behavior.

Most people come to look up a specific verse. They type “John 3:16” or “Philippians 4:13” into the search bar, read it, and leave. They’re using the platform as a reference tool. With over 2,000 Bible searches happening every minute on Bible Gateway, that’s a lot of single-verse visits.

This isn’t a criticism — it’s a behavioral insight with real implications for how we think about digital discipleship strategy.

If most users are in “lookup mode,” the discipleship opportunity isn’t in the content they came for. They already know that verse. The opportunity is in what comes next. Cross-references. Historical context. A reading plan that starts at that passage. A study note that opens the text up. The moment after someone finds what they came for is the moment a reference visit can become a formation experience.

(I should be transparent: I’m inferring the “lookup vs. study” distinction from session duration, page depth, and search query patterns in aggregate. We can see that a large portion of sessions are short and single-verse. But I can’t tell you what’s happening in someone’s heart during a 30-second visit — maybe that one verse is exactly what they needed. The data shows behavior, not transformation.)

The product principle applies broadly: meet people where they are, not where you wish they were. Design the next step from actual behavior, not from an ideal user journey.

The Day 7 Engagement Cliff

This is the most actionable pattern I’ve observed, and it’s consistent across every content platform I’ve worked on.

When someone starts a reading plan, engagement drops sharply after about Day 7. The first few days see strong completion. By the end of the first week, there’s a significant cliff. People who make it past Day 10 tend to finish — but a substantial number never get there.

(Evidence level: this is a pattern in aggregate reading plan data. Exact drop-off percentages vary by plan type and length, but the general shape — strong start, sharp drop around Day 7, stabilization for those who persist — is consistent enough that I’m confident calling it a pattern. This aligns with published habit formation research — Phillippa Lally’s 2009 study in the European Journal of Social Psychology found that early repetitions are the most fragile period for new habits.3)

For digital discipleship design, the implication is clear: Day 5 through Day 8 is where you need your best intervention design. Reminders. Encouragement. Community connection. A check-in from a real person. Whatever bridges the gap between initial motivation and formed habit.

This is where most digital discipleship tools fail. They’re good at onboarding. They’re good at content. They go quiet in the messy middle — the stretch where motivation fades and habit hasn’t locked in yet. That gap is where discipleship actually happens, and it’s where most apps have nothing to say.

At Bible Gateway’s scale, even small improvements in that Day 5-8 window could mean hundreds of thousands of people moving from casual lookup to sustained practice.

Why Features Rarely Solve Discipleship Problems

I’ve shipped a lot of features across my career. One thing I’ve learned — sometimes painfully — is that adding features to a discipleship tool almost never solves a discipleship problem.

The instinct is always to build more. More study tools. More social features. More gamification. But the digital discipleship tools that actually seem to work are the ones that reduce friction to spiritual practice, not the ones that add complexity to it.

Bible Gateway’s core value proposition is remarkably simple: read any Bible translation, for free, instantly. Over 200 versions in 70+ languages. That simplicity is the product. Every feature we consider needs to serve that core experience, not compete with it.

There’s a real tension here. Bible Gateway Plus offers 50+ study resources, ad-free reading, and deep study tools at $4.99/month. But even the premium tier works because it removes friction (ads, limited study tools) rather than adding cognitive load. The upgrade makes the simple thing simpler.

What ORI Taught Me About the Limits of Scale

All of this data-driven thinking needs a counterweight. For me, that counterweight is ORI.

ORI is a youth discipleship app I co-built, and its premise is different from a content platform like Bible Gateway. ORI facilitates the relationship between a mentor and a young person. The technology doesn’t do the discipleship — it supports the human who does.

That experience taught me something analytics can’t: the most effective digital discipleship tool is often the one that gets out of the way. The one that connects a young person with an adult who cares about them, gives them a shared framework for conversation, and then steps back. It echoes what Paul wrote to the Thessalonians — “We were gentle among you, like a nursing mother taking care of her own children” (1 Thessalonians 2:7, ESV). Discipleship has always been relational. Technology either serves that or distracts from it.

There’s a spectrum here. On one end, platforms like Bible Gateway serve millions with content at scale. On the other, tools like ORI serve hundreds by facilitating real human relationships. Both are valid. Both are needed. But they succeed for different reasons, and conflating them is a mistake I see church tech teams make often.

Friction Is the Enemy

If I had to compress everything I’ve learned into one principle: your job is to reduce friction between a person and their next spiritual step.

Not to create content. Not to build features. Not to gamify Scripture. To reduce friction.

At Bible Gateway’s scale, that means instant access to any translation, fast search, and reading plans designed around how people actually behave. At ORI’s scale, that means making it easy for a mentor to show up prepared for a fifteen-minute conversation with a teenager.

The 23 million people who use Bible Gateway each month aren’t a metric. They’re people in a spiritual practice — or trying to start one. The best thing a product team can do is figure out where the friction lives and get it out of the way.

I don’t have this figured out. The Day 7 cliff still exists. The gap between Bible search and Bible study is still wide. The question of whether a 30-second verse lookup counts as “discipleship” — I genuinely don’t know. But I think the question itself is worth sitting with, because how you answer it shapes everything you build.

Dr. Josh Read is Director of Product at HarperCollins Christian Publishing, where he leads Bible Gateway. He writes about the product side of digital discipleship at drjoshuaread.com. His other writing explores AI stewardship in ministry and what the Tower of Babel teaches us about technology.

1 Southern Baptist Convention, 2023 Annual Church Profile, reporting 12.4 million average weekly worship attendance across 47,000+ churches.

2 BJ Fogg, Tiny Habits: The Small Changes That Change Everything (Houghton Mifflin Harcourt, 2019). Fogg’s research at Stanford’s Behavior Design Lab demonstrates that starting small and building on success is more effective than ambitious commitment structures.

3 Phillippa Lally et al., “How Are Habits Formed: Modelling Habit Formation in the Real World,” European Journal of Social Psychology 40, no. 6 (2010): 998-1009.

Posted on

7 Things I Read This Week (and Why They Matter)

This was one of those weeks where everything I read seemed to converge on the same theme: the ground is shifting faster than most of us realize. AI isn’t coming for our workflows someday – it’s already reshaping how products get discovered, how code gets written, and whether your product-market fit survives the next 12 months.

Here’s what caught my attention.

—

1. Product Market Fit Collapse: Why Your Company Could Be Next

Reforge Blog

If you’re in SaaS, this is the chart that should scare you. Reforge makes the case that PMF isn’t a destination – it’s a treadmill. And AI just cranked the speed to max. Chegg lost 87.5% of its valuation. Stack Overflow’s traffic cratered. The pattern is the same: AI proves value for a use case, and the incumbent’s window to adapt slams shut before they even recognize the threat.

This one hit me personally. SermonCentral has been the go-to sermon library for over two decades. BUT the question I keep coming back to is: what happens when pastors can generate sermon outlines with AI in seconds? The PMF threshold doesn’t care about your legacy. It only cares about whether you’re still the best answer to the customer’s problem RIGHT NOW.

—

2. What AI Sees When It Visits Your Website (And How To Fix It)

Google Share

This reframed how I think about our SEO strategy entirely. AI answer engines – ChatGPT, Google AI Overviews, Perplexity – are visiting your site, interpreting your content, and shaping customer perception BEFORE a human ever clicks. Traditional SEO isn’t enough anymore. You need AEO – AI Engine Optimization.

For SermonCentral, this is urgent. We live and die by organic discovery. If AI systems can’t parse our content well, we lose visibility in the exact channels that are replacing traditional search. I’m bringing this to the team this week.

—

3. Claude Code Remote Control

Claude Code Docs

This is the kind of workflow upgrade that sounds small but changes everything. Claude Code now lets you continue local dev sessions from your phone, tablet, or any browser. Your full local environment stays intact – filesystem, MCP servers, all of it. Sessions reconnect automatically after network drops or laptop sleep.

I’ve been using Claude Code as my daily driver for months now. Being able to kick off a task at my desk and check progress from my phone during a walk? That’s the kind of automation leverage I’m optimizing for in 2026.

—

4. Claude Code for Web – Async Coding Agent

Simon Willison

Anthropic launched an async coding agent at claude.ai/code. Point it at a GitHub repo, give it a task, and it creates branches and PRs with the work output. It runs in a container, skips permission gates, and the PRs are indistinguishable from CLI-generated ones.

The coding agent space is getting crowded fast – OpenAI Codex Cloud, Google Jules, now this. What I appreciate about this one is the “teleport” feature that lets you copy the transcript and files to your local CLI. It’s not replacing the local workflow, it’s extending it. That’s the right design philosophy.

—

5. How to Build a PM GitHub That Gets You Hired

Aakash’s Newsletter

Only 24% of PM candidates have GitHub profiles. That stat alone should tell you something. Hiring managers at Google, OpenAI, Anthropic, and Meta actively check GitHub when it’s linked. A strong profile signals you actually build things and understand engineer workflows – not just strategize from a slide deck.

I’ve been saying this for a while: the best PMs ship. They don’t just write specs. If you’re a PM reading this and you don’t have a GitHub presence, this is your sign. Start small. Ship something. The differentiation is massive because almost nobody does it.

—

6. Visual Explainer – Agent Skill for Rich HTML Output

GitHub

This is a neat agent skill that converts complex terminal output into styled, interactive HTML pages. Think: architecture diagrams, code diff reviews, project plan audits, data tables – all rendered as shareable HTML without manual formatting.

I’m always looking for ways to make technical work more visible to non-technical stakeholders. Being able to generate a polished visual recap of a sprint or a system change and just send the HTML? That’s a communication multiplier.

—

7. Anthropic Courses on Skilljar

Anthropic Courses

Anthropic now has 14+ structured courses covering Claude API, Model Context Protocol, and AI fluency for developers, educators, students, and nonprofits. This tells me they’re investing heavily in ecosystem education – and that MCP is becoming a first-class skill.

I’ve been building MCP integrations into my daily workflow for months. Seeing Anthropic formalize the training around it validates the bet. If you’re building on Claude and haven’t gone through these, it’s worth the time.

—

The Thread That Ties It All Together

Every link this week points to the same reality: the cost of standing still just went up. PMF is collapsing faster. AI is reshaping discovery. Coding agents are shipping real code. The PMs who build things are getting hired. The tools are getting better every week.

The question isn’t whether to adapt. It’s whether you’re adapting fast enough.

I aim to be on the right side of that question. Hopefully some of these links help you get there too.

Posted on

The 10 Product Strategy Mistakes I Keep Seeing (After 10+ Years in SaaS)

An enamel pin about Product Management

I’ve made every one of these mistakes. Some of them more than once. Product strategy reads well in a blog post, but in practice it’s a minefield of competing priorities, stakeholder pressure, and the constant temptation to say yes to everything.

After more than a decade leading product and growth for SaaS companies – including subscription products serving millions of users – I’ve developed a pretty reliable list of strategy mistakes that kill momentum. Not the theoretical kind you read about in business school. The real kind. The ones that cost you quarters.

Here are the 10 pitfalls I keep coming back to, the ones that have cost me the most time, energy, and momentum over the years.

What is Product Strategy, Really?

Before we get into the mistakes, let’s get aligned on what product strategy actually is – because the lack of a shared definition is often the first problem.

Product strategy is the set of choices that connect your company’s vision to the work your team does every day. It answers three questions:

  1.  Who are we building for? (target audience)
  2.  What problem are we solving for them? (value proposition)
  3. How does this create value for the business? (business model)

Marty Cagan, author of Inspired and founding partner at Silicon Valley Product Group, puts it simply: strategy is about deciding which problems are worth solving. Roman Pichler frames it as the path to your product vision – the high-level plan for achieving your goals.

The important thing is that strategy is about CHOICES. Not a roadmap. Not a feature list. Choices about what you’ll do, and more importantly, what you won’t do.

With that foundation, here are the 10 mistakes that undermine those choices.

Mistake 1: Confusing Activity with Progress

This is the one that gets almost everyone. You ship a feature. Then another. Then another. Your release notes look great. Your team feels productive.

But the metrics aren’t changing.

I’ve lived this. We shipped feature after feature and our conversion numbers stayed flat. Lots of effort, but no forward motion. The problem was that we were building things that were nice to have, not things that moved the needle.

This is what the Jobs-to-be-Done (JTBD) framework helps you avoid. When you understand the actual job your customer is hiring your product to do, it becomes much easier to evaluate whether a feature advances that job or just adds noise. Clayton Christensen’s insight was that customers don’t buy products – they hire them to make progress. If your feature doesn’t help the customer make progress on their core job, it’s activity, not progress.

How to avoid it: Before greenlighting any feature, ask “which metric does this move, and by how much?” If the team can’t answer that clearly, the feature isn’t ready to build. This is easy to say, but extremely difficult to do. Use a prioritization framework like RICE scoring (Reach, Impact, Confidence, Effort) to force the conversation beyond gut feel.

Mistake 2: Strategy by Consensus

There’s a version of inclusive leadership that sounds great in theory but kills strategy in practice. You bring everyone to the table. You gather input. You synthesize. You try to find a path that makes all stakeholders happy.

… and you end up with a strategy that offends no one and inspires no one.

Real strategy requires choices. Hard ones. The kind where someone in the room won’t like the answer. If your strategy document doesn’t explicitly state what you’re NOT doing, it’s a wish list.

This is what killed products like Google+. Google had the engineering talent, the distribution, and the resources to build a social network. But the strategy tried to be everything to everyone – a Facebook competitor, a Twitter alternative, an identity platform, a photo sharing service. No hard choices were made and the product sadly died a slow death by committee.

How to avoid it: I’ve learned (the hard way) that my job is to make everyone feel heard, synthesize the inputs, make a clear decision, and then communicate the reasoning. People can disagree with a well-reasoned decision, what they can’t work with is ambiguity. Write down your strategy in one page. If it doesn’t fit on one page, you haven’t made enough choices yet.

Mistake 3: Copying the Competition

Your competitor launches a feature. Your sales team forwards the announcement. Your CEO asks “why don’t we have this?” And suddenly your roadmap has a new top priority that wasn’t there yesterday – classic!

I’ve fallen into this trap more than I’d like to admit. You absolutely should know what your competitors are doing. The real risk is letting their decisions drive YOUR strategy.

When you copy a competitor’s feature, you’re solving for THEIR customers with THEIR context.

You don’t know why they built it. You don’t know if it’s working. You don’t know if they’re about to kill it. You’re making a strategic bet based on a press release.

Gibson Biddle, former VP of Product at Netflix, uses what he calls the DHM Model – Delight, Hard-to-Copy, and Margin-Enhancing. The “hard-to-copy” piece is key but with AI it’s getting more difficult. If your strategy is just replicating what competitors build, you’ll always be behind AND you’ll never build anything that’s uniquely valuable to your users.

How to avoid it: Understand what problem the competitor is trying to solve, then ask whether YOUR users have that same problem. Sometimes they do, and then you should solve it in a way that fits your product, your architecture, and your users’ workflow. Sometimes they don’t, and the right answer is “we’re not building that” – Jeff Bezos has a great framework for this kind of decision.

Mistake 4: Ignoring the Metrics That Actually Matter

Vanity metrics are seductive. Page views are up! Sign-ups are growing! App downloads hit a new record!

But if your churn rate is climbing at the same time, you’ve got a leaky bucket. And no amount of top-of-funnel growth fixes a retention problem.

I’ve been in situations where the dashboards looked green but the business was struggling, and situations where the top-line numbers looked concerning but the underlying health was strong. The difference was which metrics we were watching.

This is what the North Star Metric concept helps solve. Your North Star is the single metric that best captures the core value your product delivers to customers. For Spotify, it’s time spent listening. For Airbnb, it’s nights booked. For a subscription SaaS product, it might be weekly active usage or feature adoption depth.

How to avoid it: For any subscription product, the metrics that matter are: how many people start a trial, how many convert to paid, how many cancel, and what’s the net change. Everything else is context. Build your dashboard around these numbers first, THEN add the supporting metrics that explain why they’re moving.

Mistake 5: Trying to Serve Everyone

This one is especially hard in mission-driven organizations. You WANT to help everyone. Every user segment seems important. Every use case feels valid.

But trying to serve everyone equally means serving no one well.

Your onboarding can’t be optimized for beginners AND power users simultaneously. Your pricing can’t be accessible to individuals AND competitive for enterprises without compromise.

Trying to serve everyone equally means serving no one well.

Kodak learned this the hard way. They saw digital photography coming but tried to straddle both worlds – maintaining their film business while half-heartedly investing in digital. They served neither audience well, and a company that once dominated an entire industry filed for bankruptcy in 2012.

How to avoid it: The best products I’ve used (and the best products I’ve built) made clear choices about who they were for. They explicitly prioritized one audience and designed everything around their needs first. When you do that well, other segments often benefit anyway, from a focused, coherent product rather than a compromised one. Define your primary persona. Write it on the wall. When someone asks “but what about this other segment?” you have your answer ready.

Mistake 6: Having No Strategy at All

This sounds obvious, but it’s shockingly common. My last few roles I’ve called “The Fixer” because years of the company running hard has caused them to lose their focus and they suddenly realize they don’t have a strategy. They have a roadmap. They have a backlog. They have quarterly goals. They ship things on time.

But there’s no unifying thesis about WHERE the product is going and WHY.

Roman Pichler calls this the most common product strategy mistake he encounters. Teams jump straight from vision to execution without the strategic layer that connects them. The result is a collection of features that individually make sense, but collectively don’t tell a coherent story.

How to avoid it: Your strategy should be a testable hypothesis, not a document that lives somewhere on the server. Try this format: “We believe that [target audience] struggles with [problem]. If we build [solution], we’ll see [measurable outcome] within [timeframe].” If you can’t fill in those blanks, you don’t have a strategy yet. You have a to-do list.

Mistake 7: Treating Strategy as Static

You spend weeks crafting the perfect strategy document. Leadership signs off. The team aligns. You print it out and pin it to the wall.

Six months later, the market has shifted, a competitor has launched something unexpected, and your customers are telling you something you didn’t anticipate. But the strategy is “locked.”

Eric Ries built the entire Lean Startup methodology around this problem. The Build-Measure-Learn loop isn’t just for startups – it’s for any team that operates in uncertainty, which is literally every product team. Your strategy should have built-in checkpoints where you evaluate whether your assumptions still hold.

How to avoid it: Set quarterly strategy reviews. Not annual planning sessions where you redo everything – lightweight reviews where you ask: “What have we learned? What’s changed? Do our bets still make sense?” The best strategies are living documents, not manifestos. Jeff Bezos distinguishes between “one-way door” decisions (irreversible, deliberate slowly) and “two-way door” decisions (reversible, move fast). Most strategic choices are two-way doors. Treat them that way.

Mistake 8: Skipping Validation Before Committing

You have a great idea. The team is excited. Leadership is bought in. You go straight to building.

Three months later, you launch to silence. Customers don’t want it, don’t understand it, or already solved the problem another way.

I’ve seen this pattern destroy entire quarters. The excitement of a new idea creates momentum that skips right past the “should we build this?” question and lands on “how do we build this?”

How to avoid it: Before committing engineering resources, validate the problem AND the solution. Talk to 5-10 customers. Run a fake door test. Build a prototype and put it in front of real users. Teresa Torres’ Continuous Discovery framework calls this “opportunity solution trees” – mapping the opportunity space before jumping to solutions. The cost of 2 weeks of discovery is nothing compared to 3 months of building the wrong thing.

Mistake 9: Siloed Strategy Without Cross-Functional Input

Product writes the strategy. Engineering learns about it at spring planning. Design gets brought in when wireframes are needed. Marketing finds out at launch.

This isn’t strategy. It’s a relay race where nobody can actually see the finish line.

The best product strategies I’ve been part of were shaped by engineering constraints, design insights, and market intelligence from day one. Your engineers know what’s technically feasible and where the architecture creates opportunities. Your designers have insights about user behavior that data alone can’t capture. Your sales and support teams hear objections and pain points every day.

How to avoid it: Include engineering and design leads in strategy formation, not just execution. Share customer research broadly. Bring it up in meetings regularly. Make your strategy document accessible to everyone on the team, not locked into a leadership slide deck. When people understand the WHY behind the strategy, they make better decisions at every level.

Mistake 10: Being Unrealistic About Execution Capacity

This is the mistake that ties all the others together. You have a clear strategy. You’ve validated the direction. You’ve made all the hard choices about what to build.

Then you commit to 3x more than your team can actually deliver.

Your roadmap becomes a pressure cooker. Quality drops. Shortcuts get taken. The team burns out. And paradoxically, you end up delivering LESS than if you’d committed to fewer things done with excellence.

I’ve seen this cycle repeat across every company I’ve worked with. The ambition is always bigger than the capacity, and the gap gets filled with overtime and technical debt instead of honest prioritization.

How to avoid it: Be ruthlessly honest about how much your team can ship in a quarter. Then cut 20% from that estimate. Even writing that sounds crazy, but it must be done. Use the OKR framework (Objectives and Key Results) to limit your bets to 3-5 outcomes per quarter – not 3-5 per team, 3-5 total. Warren Buffett’s “two-list strategy” applies here: write down your top 25 priorities, circle the top 5, and treat the other 20 as your “avoid at all costs” list (avoid them entirely until the top 5 are achieved). The same logic applies to product strategy.

The Uncomfortable Truth

Product strategy is about having the discipline to say no to good ideas that don’t align with what matters most right now.

Every mistake on this list comes from the same root: the unwillingness to make a hard choice and live with the tradeoff.

Choose the right things. Decide clearly. Pick your own path. (I wrote about this focus in 5 things needed for business success.) Watch the honest metrics. Serve someone specific.

Strategy is the art of sacrifice. The sooner you get comfortable with that, the better your products will be.

Product Strategy Checklist

Before you finalize your next product strategy, run through this list:

  • Can you state your target audience in one sentence?
  • Can you articulate the core problem you’re solving for them?
  • Does your strategy explicitly state what you’re NOT doing?
  • Is every major initiative tied to a measurable outcome?
  • Have you validated your assumptions with real customers?
  • Does your team have the capacity to execute this quarter’s plan?
  • Have you set a date to review and adapt the strategy?
  • Can your entire team articulate the strategy without looking at a document?
  • Is there a clear North Star Metric everyone is aligned on?
  • Would you bet your own money on this plan working?

If you can’t check every box, your strategy still has gaps. Go back and make the hard choices.

Frequently Asked Questions

What are the most common product strategy mistakes?

The most common product strategy mistakes include confusing activity with progress (shipping features that don’t move metrics), strategy by consensus (avoiding hard choices to keep everyone happy), copying competitors instead of solving for your own users, ignoring retention metrics in favor of vanity metrics, and trying to serve every user segment equally. The root cause of most strategy failures is an unwillingness to make clear choices and accept tradeoffs.

What is the difference between product strategy and a product roadmap?

Product strategy defines WHERE you’re going and WHY. It’s about choices, tradeoffs, and the thesis behind your product direction. A product roadmap is the HOW and WHEN – the sequence of work that executes the strategy. A roadmap without a strategy is just a feature list. A strategy without a roadmap is just a vision. You need both, but strategy comes first.

How do you create an effective product strategy?

An effective product strategy begins with a clear understanding of your target audience, the problem you’re solving, and how solving it creates business value. Frameworks like Jobs-to-be-Done help identify what customers actually need. Validate your assumptions through customer discovery before committing resources. Set a North Star Metric to track progress. Review and adapt quarterly. Most importantly, be explicit about what you will NOT do – that’s ultimately where the real strategy lives.

How often should you update your product strategy?

Product strategy should be reviewed quarterly and updated when market conditions, customer needs, or business goals change significantly. It should NOT change weekly based on competitor moves or stakeholder requests. The best approach is setting lightweight quarterly checkpoints where you evaluate whether your core assumptions still hold, while keeping the overall strategic direction stable enough for the team to execute with confidence.

Posted on

The Traffic You Depend On Is Being Answered Without You

I’ve been staring at a traffic chart for the last three weeks that I can’t stop thinking about.

It’s Chegg’s chart. The online education platform lost 34% of its organic visitors in a matter of months. That’s a cliff. Their keyword footprint went from 11.1 million to 3.5 million.

And the culprit wasn’t a competitor outranking them or a Google algorithm update penalizing thin content. It was Google answering the questions before anyone ever clicked.

The Machine That Eats Your Top of Funnel

Google’s AI Overviews are the AI-generated summaries that now appear at the top of search results, and they are fundamentally changing what it means to rank on Google. For years, the playbook was clear: create valuable content, optimize it for search, capture intent, convert visitors.

That model assumed one thing: that people would actually click through to your site.

AI Overviews break that assumption.

When someone searches “how to explain forgiveness to a congregation” or “best illustrations for an Easter sermon,” Google can now synthesize an answer from multiple sources and present it directly in the search results. No click required. No visit to your site. No entry into your funnel.

Tomasz Tunguz laid this out clearly in a recent analysis:

“Content dependency on organic search is no longer a sustainable acquisition model.”

That sentence should be pinned to the wall of every SaaS product leader who relies on organic traffic (understanding these shifts is a critical PM skill) to fill the top of their funnel.

Chegg Is the Preview

The pattern is showing up everywhere. Stack Overflow, the platform that essentially taught a generation of developers how to code (including me), is seeing the same erosion. Informational queries that used to drive millions of visits are now being answered inline by AI.

The New York Times is thriving. Why? How? A $100 million content licensing deal with Google. They’re feeding the AI, on their terms, for revenue.

Here’s what I think the data is telling us:

1. Q&A-style content is the most vulnerable. If your value proposition is answering questions that can be summarized in a paragraph, you’re in the blast radius.
2. Branded, premium, behind-the-paywall content is more defensible. AI Overviews can summarize a sermon topic, but they can’t replicate a full manuscript, a downloadable media pack, or an AI-powered sermon builder.
3. The winners will be the ones who stop treating Google as a given and start building direct relationships with their audience.

What This Means for SaaS Product Leaders

I run product and growth for a content platform that serves pastors. We have 245,000+ sermons and 50,000+ text illustrations, exactly the kind of content library that ranks well for long-tail informational queries.

For years, that library has been our primary discovery engine. Pastors search for sermon ideas, find us, browse free content, start a trial, and convert to paid.

That model still works today, but we’re down around that same 34% mark and from what I can tell so is everyone, across all industries. But I’d be naive to assume it’ll work the same way in 18 months.

Here’s the uncomfortable math: if organic traffic drops by even 20-30%, and organic is your dominant acquisition channel, no amount of conversion rate optimization saves you. You can have a best-in-class trial-to-paid flow and still miss your numbers because not enough people are entering the funnel in the first place.

It’s an exposure problem. And it requires a fundamentally different response than what most product teams are used to.

The Diagnostic Before the Panic

Before you restructure your entire growth strategy, there’s a critical diagnostic step that teams often skip. You need to know whether AI Overviews are actually appearing on YOUR highest-value queries.

Here’s the move:

  • Pull your top 50 keywords from Google Search Console. Look at click-through rate trends over the last 90 days, segmented by week.
  • The signature you’re looking for: stable or rising impressions, but declining CTR. That pattern means Google is showing your content in results, but users aren’t clicking because the AI Overview already gave them what they needed.
  • If your impressions are dropping, that’s a competitor or algorithm problem. If impressions are stable but clicks are falling, that’s AI Overview cannibalization. Different diagnosis, different treatment.

Most teams I talk to are just making this distinction. They’re looking at traffic declines and assuming it’s an SEO problem when it might be a platform shift problem. The difference matters.

Three Moves to Make Now

I’m not going to pretend I have the full playbook figured out. But here’s where my thinking is landing:

1. Shift discovery investment toward owned channels.
Email nurture sequences, community platforms, pastoral networks, partnerships with organizations that already have the audience. Organic search should be one of many channels, not the only one. Every dollar of effort I’m putting into SEO-driven top-of-funnel content I’m asking if that same effort in email or community would be more durable.

2. Make your paywall content genuinely irreplaceable.
AI can summarize a sermon outline. It cannot replicate a curated media pack, a professionally produced video series, or a workflow tool that saves someone three hours a week. The content that survives AI summarization is the content that requires depth, production value, or interactivity: things a search snippet can’t deliver.

3. Explore whether the threat is also an opportunity.
The NYT licensing deal tells us something important: Google is willing to pay for premium vertical content. If you’re the dominant content platform in your niche, there may be a deal to be made.

A licensing partnership could convert a traffic threat into a revenue stream while maintaining brand visibility inside AI-generated results. Worth exploring.

The Bigger Lesson

I keep coming back to something I’ve learned over the last few years leading product: the most dangerous risks are the ones that look like stability. Traffic holding steady today doesn’t mean the foundation isn’t shifting underneath.

Chegg’s team didn’t wake up one morning to a 34% traffic drop. It happened gradually, then suddenly. The chart looks normal until it doesn’t.

The product leaders who navigate this well will be the ones who diagnosed early, diversified before they had to, and built value that can’t be summarized in a paragraph. The ones who don’t will be staring at a chart they can’t explain and wondering where all the visitors went.

I’d rather be asking the hard questions now than explaining the traffic decline later.

Posted on

AI Just Walked Into Your Website Without Knocking

Last month I asked ChatGPT a question I’ve asked Google a thousand times: “What’s a good sermon illustration about forgiveness?”

It gave me a solid answer. Three illustrations, structured with context, application points, even a suggested closing line. It was genuinely useful.

And it never sent me to a single website.

That moment hit me differently than it would have two years ago. I run a platform with over 245,000 sermons and 50,000 illustrations. I didn’t just lose a click. I watched an AI system do what our product does, using content that likely came from sites like ours, and deliver it in a way that made visiting the source unnecessary.

That’s a revenue problem. (I wrote about the traffic implications of this shift recently.) (I wrote about the traffic implications of this shift recently.)

The Zero-Click Layer

Most product leaders I know are still thinking about AI as a feature to bolt onto their product: chatbots, smart search, AI-generated recommendations. And that matters. But there’s a bigger shift happening underneath that conversation.

AI answer engines (ChatGPT, Google AI Overviews, Perplexity) are becoming the front door to the internet. They don’t just search. They visit your site, interpret your content, synthesize it, and serve it directly to the user. The user gets the answer. You get nothing.

Google’s featured snippets started this zero-click trend years ago. BUT what’s different now is the depth. A featured snippet pulls a paragraph. An AI answer engine can synthesize an entire page, or multiple pages, into a comprehensive response that genuinely satisfies the user’s intent.

If your business depends on organic traffic as a top-of-funnel engine, this should keep you up at night.

Your Content Library Is Both Your Greatest Asset and Your Biggest Vulnerability

Here’s the paradox I’ve been sitting with.

We spent years building one of the largest structured content libraries in our space. That library is what drives our organic traffic. It’s what Google indexes. It’s what pastors find when they search “sermon on grace” at 11pm on a Saturday night.

That same library is now what AI systems are ingesting to train their models and generate their answers. The very content that built our moat is being used to fill in the moat.

And here’s what makes it worse. The emerging AI-native competitors in our space don’t even need to win Google rankings. They ARE the AI tool. They’re built to live inside AI workflows, not compete for traditional search clicks.

I think this pattern applies to any SaaS company sitting on a large content asset. If you’ve built your growth engine on content that AI can summarize, you’re exposed.

AEO: A Genuinely Different Discipline

There’s a term gaining traction: AEO, or AI Engine Optimization. And I’ll be honest, my first reaction was skepticism. We don’t need another three-letter acronym.

But the more I’ve dug into it, the more I realize it represents a genuinely different discipline.

SEO optimizes for ranking. AEO optimizes for citation. The goal is to be the source that AI systems reference AND link back to. That requires a fundamentally different content strategy.

Here’s what that looks like in practice:

  1. Structured data becomes non-negotiable. Schema markup, clear metadata, explicit problem-solution framing in your content. AI systems parse structure, not vibes. (Schema.org is the starting point.)
  2. Content architecture matters more than keyword density. How your content is organized (headers, relationships between pages, internal linking) determines how AI systems understand your authority on a topic.
  3. Gated content is a double-edged sword. If your best content is behind a login wall, AI crawlers can’t index it. You’re invisible to the answer engine. But if everything is open, you get summarized without a click. The play is in the middle: structured preview content that AI can cite, with depth that requires the visit.
  4. Domain-specific language is your moat. Generic content gets synthesized away. Content that uses the precise language of your audience (the way a pastor describes their Saturday night prep struggle, the specific vocabulary of sermon structure) is harder for AI to replace and more likely to be cited with attribution.

What I’m Doing About It

I’m not going to pretend I have this figured out. But here’s where my head is:

Audit how AI sees us. Before optimizing anything, we need to understand how our top pages render to AI crawlers. What structured data exists? What’s behind login walls that blocks indexing?

Treat AI referral as a distinct channel. We track direct traffic, organic search, paid. AI referral needs its own lane in our analytics. We can’t optimize what we can’t measure.

Build content AI can’t summarize away. The full sermon text? AI can handle that. But a pastor’s framework for adapting a sermon to their specific congregation? A diagnostic tool for matching an illustration to a particular emotional moment in a service? That’s interactive, personalized, and requires being on the platform.

Move faster than the AI-native competitors. They have the structural advantage of being built for AI workflows. We have the structural advantage of 20+ years of trusted content and relationships. The question is whether we can adapt our distribution before they build our depth.

The Strategies That Got You Here Won’t Sustain You

I keep coming back to this. The strategies that built organic growth over the last decade won’t sustain it over the next five years.

That’s a reason to move, not a reason to panic.

The companies that treat AI answer engines as a new channel will capture disproportionate share of the next era of discovery. The ones that keep optimizing for Google page one while AI summarizes their content into zero-click answers will watch their traffic erode and wonder what happened.

I’d rather be early and wrong about the tactics than late and right about the trend.

The AI just walked into your website. The question is whether it’s going to send people your way, or make visiting you unnecessary.