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.

Product design fundamentals every product manager should know

I’ve been building products for nearly three decades and one of the things I wish someone had told me early on is this: you don’t need to be a designer, but you need to understand design well enough to have an opinion.

A “this flow is going to confuse people and here’s why” opinion. That’s a fundamentally different skill, and it’s one that separates good PMs from great ones.

Design Literacy Is a Product Superpower

Most PMs I’ve worked with fall into one of two camps. Either they defer entirely to the designer (“you’re the expert, I trust you”) or they micromanage pixels without understanding why.

Neither works great.

The best PMs I know can open a Figma file, look at a proposed flow, and say: “This solves the problem, but I think we’re going to lose people at step 3 because there’s too much cognitive load.” That’s product judgment informed by design principles.

Here are the fundamentals that have made the biggest difference in how I work.

Visual Hierarchy Drives Behavior

Every screen has a job. The user lands on it and their eyes need to go somewhere. If everything is bold, nothing is bold. If there are six calls to action, there are zero calls to action.

This sounds obvious, but I can’t tell you how many product reviews I’ve sat in where the page is trying to do five things at once. The conversion data always tells the same story: users don’t know what to do, so they do nothing.

The principle is simple: every page should have ONE primary action. Everything else is secondary.

When I look at a design now, the first question I ask is “what’s the one thing we want the user to do here?” If the designer can’t answer that in one sentence, we have a problem.

Consistency Reduces Cognitive Load

This one took me a while to internalize. Consistency is about reducing the mental effort required to use your product. (If you haven’t read it, Schneiderman’s Eight Golden Rules is a great foundation for this.)

When a button is blue in one place and green in another, when the save action is top-right on one page and bottom-left on another, when confirmation messages look different everywhere, each inconsistency is a tiny tax on the user’s brain. Individually they’re nothing. Collectively they’re the reason people say “this product feels clunky” without being able to explain why.

As a PM, I’ve learned to flag consistency issues early. They compound. And they’re 10x easier to fix in design than in code.

Feedback Loops Build Trust

Users need to know their action worked. Every single time. No exceptions.

Click a button? Something should visually change. Submit a form? Show a confirmation. Trigger a process that takes time? Show a loading state.

I still see products that leave users wondering “did that work?” And every time that happens, trust erodes a little. I’ve started treating feedback loops as a product requirement, not a design nice-to-have.

Whitespace Is Not Wasted Space

My instinct as a PM was always “we have this space, let’s use it.” More features visible, more value communicated, more reasons to convert.

That instinct was backwards. Whitespace is what makes the important things important. It’s what gives the user’s eye a place to rest.

Some of the most effective design changes I’ve seen were about removing things. Taking away a sidebar. Eliminating a secondary nav. Letting the content breathe. The metrics almost always improved.

Accessibility Is Just Good Design

I’ll be honest, I used to think of accessibility as a checkbox. Something we needed to do for compliance. I was wrong and it wasn’t until I reached mid-forties that I started to recognize why they are necessary.

High contrast text is easier for everyone to read. Clear labels help everyone navigate.

Keyboard support benefits power users as much as it benefits users with motor disabilities. When we improved accessibility on our platform, our overall usability scores went up across the board. For everyone.

The PM’s Role in Design

My job is to define the problem clearly enough that the designer can solve it well. I challenge designs that optimize for aesthetics over usability. I push back when a beautiful mockup doesn’t account for edge cases, error states, or the reality of what happens when a user has 500 items instead of 5.

I don’t draw wireframes or pick colors or argue about border radius.

The best design partnerships I’ve had were two people with different expertise looking at the same problem and making it better together. That only works when the PM speaks enough design language to have the conversation.

I wish I’d started learning design fundamentals earlier. You don’t need a course. You don’t need to learn Figma (though it helps).

Just start asking “why” when you see a design decision, and pay attention to the answer. That habit alone will make you measurably better at your job.

How do you avoid burnout in product management?

Quick answer: Avoid product management burnout by protecting non-negotiable time blocks, automating repetitive work, delegating through your team instead of controlling every detail, making fast reversible decisions instead of chasing perfection, and anchoring yourself to something outside work. Boundaries plus leverage plus recovery — not more hours — is what actually prevents burnout.

There was a season a few years back where I was checking Slack before my feet hit the floor in the morning. Responding to emails during dinner. Thinking about roadmap priorities during my daughter’s volleyball game.

I wasn’t working more hours than anyone else on my team. I was just never NOT working.

Product management does this to people. (HBR’s research on burnout confirms it’s systemic, not individual.) You own the outcome but you don’t own the resources. You’re the one the CEO asks when numbers are off, the one engineering pings when priorities conflict, the one the customer success team escalates to when a big account is unhappy. The role is designed to pull you in every direction at once.

I was hired to replace the previous PM who burned out. He had replaced a PM who had burned out. Now, I was burning out. Not dramatically. I didn’t quit or have a breakdown. It was the slow kind, where you stop being excited about the work and start just surviving it. Where your family gets the leftover version of you and even that feels like it’s running on fumes.

Here’s what I’ve changed since then. I’m not going to pretend I’ve got it all figured out, but I’m in a fundamentally better place than I was, and most of it came from a few non-negotiable decisions.

Protect Your Time Like It’s a Product Requirement

I have a hard rule: home by 5:30 for dinner. No exceptions. Not for a board prep. Not for a product review. Not for a “quick sync” that will definitely run long.

I also block a 90-minute gym window in the middle of my day and an hour for reading first thing in the morning. These aren’t nice-to-haves. They’re on my calendar as immovable blocks, the same way a meeting with the CEO would be.

When I first started doing this, I felt guilty. Like I was being less committed than my peers. What I actually found is that the constraints made me sharper.

When you know you have to be done by 5:30, you stop saying yes to the third “alignment meeting” of the day. You get ruthless about prioritization because you have to be. The artificial scarcity forced better decisions about where my time went.

Automate Everything You Touch Twice

My theme for this year is automate as much as possible. Every hour I spend on repetitive work is an hour I’m not spending on the high-leverage thinking that actually moves the business forward.

Status reports, data pulls, recurring communications, task routing, inbox triage: if I do it more than twice, I build a system for it.

Some of these are sophisticated (automated morning briefings that synthesize email, calendar, and tasks into a single digest). Some are dead simple (a Slack reminder template so I don’t have to think about weekly check-ins).

The compounding effect is real. Each small automation frees up 15-30 minutes. Stack enough of them and you’ve recovered entire blocks of deep work time that used to disappear into operational overhead.

Your Team Is Your Leverage

The biggest burnout trap for PMs is thinking you need to be involved in everything. You don’t. You need to be clear about what matters, set the direction, and then trust your team to execute.

I used to review every analytics pull. Now my analytics lead knows what I care about and surfaces the insights, not the data.

I used to write every A/B test hypothesis. Now my growth marketer proposes them and I weigh in on priorities.

I used to attend every customer call. Now my PM partner handles the S4K side entirely and we sync weekly.

Delegation is about building capability on your team so that your time is spent on the decisions only you can make. If you’re the bottleneck for everything, that’s a sign of a system that’s one illness away from breaking.

Make Peace with “Good Enough”

Perfectionism will eat you alive in product management. There’s always one more edge case to account for, one more stakeholder to consult, one more data point to gather before making a decision.

I’ve learned to ask: “Is this decision reversible?” If yes, make it fast and move on. You can adjust later. If no, take the time you need.

But most decisions in product are reversible, and treating every one like it’s permanent is a fast track to analysis paralysis and the chronic stress that comes with it.

Shipping at 80% with the ability to iterate beats shipping at 100% three months late. And honestly, your users can’t tell the difference most of the time.

Faith and Purpose as Anchors

This one’s personal, so take it for what it’s worth. For me, faith is the thing that keeps work in perspective. I care deeply about what I do (I’m building products that help the church grow, and that mission matters to me). BUT it’s not the entirety of who I am.

When I remember that, it’s easier to close the laptop. It’s easier to be present at dinner. It’s easier to let go of the meeting that didn’t go well, the metric that’s off target, the feature that shipped with a bug.

Whatever your version of that anchor is (faith, family, community, a creative pursuit), guard it. Don’t let the urgency of product work crowd out the things that actually sustain you.

The Bottom Line

Burnout in product management comes from working without boundaries, without leverage, and without recovery.

Set the boundaries. Build the leverage through automation and delegation. Protect the time that restores you.

Your value is measured by the clarity of your decisions and the impact of what you ship. The version of me that protects his time, trusts his team, and goes to the gym at 11am is a better PM, a better leader, and a better husband and father than the one who was grinding 14 hours a day and calling it dedication.

Frequently Asked Questions

What causes burnout in product management?

PM burnout is systemic, not individual — the role gives you full accountability for outcomes without full control over resources, so you’re pulled in every direction at once by leadership, engineering, and customers simultaneously.

What’s the fastest way to reduce burnout as a PM?

Protect a hard boundary on your calendar, like a fixed end-of-day time, the same way you’d protect a meeting with the CEO. Constraints force better prioritization and stop you from saying yes to everything.

Does delegating more actually help with burnout?

Yes. The biggest burnout trap is believing you need to be involved in everything. Building your team’s capability to own decisions frees you to focus on the choices only you can make.