Then I looked at how they’re pricing it, and stopped scrolling.

The CRM Used to Remember. Not Work.

For decades a CRM had one job. Remember things. It stored customer info, tracked deals, logged emails, spit out reports. You updated it after the work was done, not while you were doing it.

Sales reps still had to find their own prospects. Support still answered its own tickets by hand. Marketing built campaigns, ops cleaned up the data nobody else wanted to touch, and none of that actually happened inside the CRM itself, it happened around it. The CRM just watched and kept the receipts.

HubSpot’s newest stuff pokes a hole in that.

Its agents aren’t framed as faster ways to click through the same old workflows (which, let’s be honest, is what half of “AI features” turn out to be once you actually use them). These are supposed to prospect leads on their own, resolve support tickets, keep the data clean, fill in gaps in the knowledge base without someone assigning that as a task.

So the CRM stops being just a record of the work. It starts being one of the things doing it.

The Pricing Is the Real Product Decision

Here’s the part that actually convinced me this isn’t just marketing copy: how HubSpot decided to charge for it.

As of April 2026, two of the flagship agents moved to outcome-based pricing. Customer Agent runs $0.50 per resolved conversation. Prospecting Agent is $1 per recommended lead. Not a seat fee. Not “access to AI features included in your plan.” You pay when it actually does the thing.

That’s a strange bet to make unless you’re fairly confident the thing gets done reliably enough, often enough, that people will pay per result instead of per login.

And apparently they are confident, or at least the numbers say so. On the Q1 2026 earnings call, HubSpot said Customer Agent was autonomously resolving 70% of support conversations. Up from 20% a year before. Across more than 9,000 customers, which is not a beta test anymore, that’s a real chunk of their customer base running production support through it.

Software Is Starting to Be Valued Like Labor

Zoom out for a second and this fits a pattern that’s been building for a while, even if nobody planned it this cleanly. SaaS digitized the paperwork. Automation cut out the busywork underneath it. Copilots started suggesting what to do next. Now the expectation is the software just does it, and you check its work instead of doing the work yourself.

Which quietly changes the question people ask when they’re evaluating a CRM. It used to be “does this have the features my team needs?” Increasingly it’s “which parts of my team’s job can I actually hand to this thing?”

That second question is a lot harder to answer yes to.

Not every vendor has made this jump, to be clear. Plenty are still bolting AI onto a subscription and calling it done. HubSpot’s bet, at least with these two agents, is that the outcome itself is the product. Not the access to a tool that might help you get there.

The Hard Part Isn’t AI. It’s Trust.

I don’t think the trust is fully earned yet, and I don’t think HubSpot would claim it is either. Most of these agents still draft the response and wait for a human to hit send. Full autonomy is more of a stated direction than something happening in every account today.

The failure modes aren’t hypothetical, they’re pretty specific once you think about it for thirty seconds.

A prospecting agent reaches out to a contact based on a deal stage nobody bothered to update in three months.

A customer agent resolves a ticket by citing a return policy that changed last quarter and nobody flagged.

The agent isn’t wrong because the model’s bad, it’s wrong because the CRM’s memory was never as clean as the pitch assumed it was.

Which is sort of the uncomfortable part.

Agentic CRM doesn’t fix a data quality problem, it just makes that problem visible a lot faster than a stale spreadsheet ever did.

The New Job Description of a CRM

For decades the job description of a CRM was simple. Remember every interaction.

HubSpot’s betting the next version of that job description doesn’t stop at remembering, it expects the software to actually do the work too.

I’m not sure most CRMs, HubSpot included, are fully ready to be judged on that basis yet. The gap between drafting a decent email and actually owning a customer relationship is still pretty wide.

But that’s the bar now anyway.

Whether the agents are ready for it or not.

Last week, HubSpot announced Contact Discovery, a feature designed to make CRM data smarter.

On paper, it was exactly what customers had been asking for. Less manual data entry. Richer contact profiles. Better lead discovery. Smarter AI recommendations.

If you’ve ever used a CRM, you’ve felt the pain this product was trying to solve. Customer records decay surprisingly fast. People change jobs. Companies rebrand. Email addresses stop working. Sales teams spend hours fixing information that software should already know.

Contact Discovery promised to solve that. Instead, it triggered a sharp, fast-moving customer backlash.

The feature wasn’t the problem. The rollout was.

The Most Important Product Decision Wasn’t the AI

Most discussions focused on artificial intelligence. But they shouldn’t have. The real product decision was much simpler.

Who owns the data once it enters a platform?

HubSpot’s proposal relied on customer data helping improve a shared contact discovery network. The company maintained that customers retained ownership of their CRM data. But the new terms opted customers in by default, splitting the opt-out across three separate settings — enrichment participation, AI-model training, and tracking-code intent signals. Switching off one left the other two running.

Whether intentional or not, the experience left many customers believing they hadn’t truly opted out.

Because products aren’t judged solely by what they do. They’re judged by what users believe they might do next.

Here’s the deeper pattern. Every successful software company eventually encounters the same temptation. The platform has millions of customers. Millions of customers generate billions of data points. Somewhere inside the company, someone asks the obvious question.

“What if the network itself became the product?” It’s a logical progression.

Google improved Search using search data. Netflix improved recommendations using viewing data. Spotify improved discovery using listening habits. But those are first-party loops — each company used a customer’s own behavior to improve that same customer’s experience.

HubSpot’s plan was a different shape. It meant pooling one customer’s contact data to enrich records across other HubSpot customers. That’s not a company learning from its users. That’s users being asked to fund each other, without necessarily choosing to.

From a product perspective, the pooled-dataset idea is elegant. From a customer perspective, it’s a different kind of ask entirely — and it deserved to be pitched as one.

Why Customers Reacted So Strongly

The backlash wasn’t driven by technical complexity. It was driven by uncertainty.

Customers started asking questions. “Is my CRM helping my competitors?” “Who can access this information?” “What exactly is being shared?” “Can I opt out?”

Notice something interesting. These aren’t engineering questions. They’re trust questions.

When people don’t fully understand how their data moves, they rarely assume the best. They assume the worst. And in this case, the default settings gave them a concrete reason to.

Four Days Changed Everything

HubSpot could have defended the rollout. It could have argued that customers misunderstood the feature. It could have hidden behind legal language.

Instead, it did something surprisingly rare for a company of its size. It admitted it got the rollout wrong. Within four days, HubSpot withdrew the proposed changes and apologized publicly.

From a communications perspective, that’s impressive. From a product perspective, it’s worth being precise about what actually happened.

HubSpot didn’t reject the economics behind Contact Discovery. It paused the rollout while reassessing how the feature should be introduced. Leadership called the move a “reassessment,” not an abandonment — and the underlying case for a shared dataset hasn’t gone away just because the rollout did.

The Cold Incentives

To understand why this happened, ignore the headlines and follow the incentives.

For HubSpot:

• Better shared data creates a better CRM.

• Better CRM recommendations create stickier products.

• Stickier products improve retention.

• Retention compounds revenue.

For customers:

• Better AI is valuable.

• Better prospecting is valuable.

• Losing confidence in how their data is handled is expensive.

Those incentives coexist until they collide. This time, they collided.

The Feature They Never Built

Ironically, the missing feature wasn’t AI. It was permission.

Imagine opening HubSpot and seeing a simple prompt.

“Help improve Contact Discovery by contributing anonymized business contact signals.”

Explain exactly what’s shared. Explain exactly what’s never shared. Show the benefits. Make participation something you turn on, not something you have to notice and turn off.

Would everyone opt in? Probably not.

Would more customers trust the platform? Almost certainly.

Because consent isn’t just a legal requirement. It’s a product experience.

The Platform Paradox

Every AI company is facing the same problem. The best models require more context.

The best products require more trust. Those two goals don’t always move together. The more data a company wants, the more transparent it has to become. The more powerful AI becomes, the less users are willing to accept ambiguity.

HubSpot didn’t discover a flaw in AI. It discovered something far more fundamental.

Trust isn’t something you earn once. It’s a product decision you have to remake every time you ask users for one more piece of their data.

HubSpot wasn’t asking customers to trust an AI model. It was asking them to trust a data relationship. Those are two very different asks.

Building Durable Systems

I love tearing apart software because I love building systems that balance high-scale platform complexity with rock-solid user trust. I specialize in scaling core infrastructures, developer velocity tools, and complex system design.

I’m currently wrapping up a deliberate career sabbatical and am actively looking for my next Product Management challenge. If your team is scaling heavy infrastructure, managing complex platform loops, or building tools that developer ecosystems rely on, let’s talk.

Connect with me on LinkedIn or drop a comment below

If you’ve opened Instagram in the last 72 hours, you’ve likely noticed the shifts. With Instants, you’re no longer greeted by the familiar workflow of Capture -> Review -> Edit -> Filter -> Share. Instead, you are looking at a live trigger.

The core mechanics are deceptively simple:

• No editing: Photos must be taken live within the app. No camera roll, no filters, no second-guessing.

• No review: The moment your finger leaves the shutter, it’s already sending.

• No permanence: The photo lands in the direct message section and vanishes in 24 hours from your screen, at least.

The Most Calculating Decision Isn’t the Speed

The most calculating product decision isn’t the instant delivery. It’s what you don’t see after you post. Unlike traditional Instagram Stories, Instants doesn’t show you who viewed your photo. No names, no counts, no faces.

That wasn’t an oversight. It was a deliberate choice.

When you share an unedited, real-time moment of your life, you instinctively want to know how many people saw it. Not just how many, but who. By removing that, Instagram leaves that question permanently open.

“Did THEY see it?”

“Why haven’t THEY responded?”

“Maybe I shouldn’t have posted this.”

So, the next time you feel that urge to check back ten minutes after posting, notice it. That’s not curiosity. That’s the loop working exactly as designed.

The question is whether anyone designed it that way deliberately, or whether it’s just what happens when a platform optimizes hard enough for engagement.

Why Meta Actually Built This

It sounds dystopian, but inside Meta’s product teams, this probably isn’t malice, it’s math.

The problem they were solving is straightforward. Polished, curated feeds make people anxious about posting. So they stop posting publicly and retreat to Snapchat, or private apps like BeReal, taking their daily habits and their data somewhere else. Instants is Meta’s answer to that migration. Strip away the editing, make sharing feel low-stakes, and pull that high-frequency, casual interaction back into Instagram’s own messaging system.

The no-camera-roll rule isn’t just an infrastructure decision because Meta already processes billions of gallery uploads a day through Stories and Reels. It serves a dual purpose:

• Culturally, it acts as a guardrail against overthinking. Block the gallery and you block the spiral of selecting, editing, and second-guessing before you share.

• Technically, live capture simplifies the media pipeline: standardized assets, lower processing overhead, and faster transmission from capture to delivery. This is why the experience feels instantaneous even across two billion devices.

The 24-hour disappearing window serves the same logic. While the content vanishes from the recipient’s view the moment they open it, the image is quietly routed to a private archive on your account. It is stored for up to a year, available for Meta to surface later as “Story Recaps.”

It feels ephemeral. It isn’t.

The Flaw They Shipped With

The backlash was immediate. Within hours of launch, users on X and Instagram were posting tutorials on how to hide the feature, panicking about accidental captures already sent to the wrong people.

This is a solvable problem, and the solution is simpler than you’d think.

A half-second delay. That’s it. When you lift your finger off the shutter, the photo doesn’t send instantly. It waits 500 milliseconds before transmitting. Half a second is too fast to notice under normal circumstances, but just long enough to hit Undo if your stomach drops the moment after you shoot. No accidental send ever reaches the recipient. No cleanup required on Meta’s end.

They didn’t ship it that way. The question is why.

The Cold Incentives

To truly evaluate the trade-offs of this feature, look at the cold mechanical incentives driving growth engineering teams. Product decisions at this scale are a balancing act between user experience, infrastructure costs, and system security:

The math shows why the current implementation won. Growth engineering is rarely about building a flawless, error-proof experience for the user. It is about finding the maximum possible speed the architecture can handle right up until the moment users stop trusting it enough to keep posting.

The Platform Paradox

The real takeaway here isn’t about a missing half-second button. It is about a fundamental product management paradox: maximizing transaction velocity almost always requires exploiting human impulsivity.

A safety grace period activates your rational brain. It gives you time to think, second-guess, and cancel an interaction. But platforms like Instagram rely on split-second panic to create the volatile, high-frequency social loops that keep metrics spiked. To a growth team, user friction isn’t a bug to be fixed; it is a variable to be tuned.

That is the true architecture of the attention economy. The next time an application forces you to act before you think, look past the clean interface. The system is working exactly as designed.

Building Durable Systems

I love tearing apart software because I love building systems that balance high-scale platform complexity with rock-solid user trust. I specialize in scaling core infrastructures, developer velocity tools, and complex system design.

I’m currently wrapping up a deliberate career sabbatical and am actively looking for my next Product Management challenge. If your team is scaling heavy infrastructure, managing complex platform loops, or building tools that developer ecosystems rely on, let’s talk.

Connect with me on LinkedIn or drop a comment below.

That moment defined the most challenging project of my career: building the QA application at HelloFresh.

When I joined the team, HelloFresh was running quality checks across its global distribution centers largely through manual workflows. Assembly line workers were tracking errors on paper, in spreadsheets, in ways that varied by market. The goal was to change that: to build an internal QA application that would digitize and standardize quality checks across 13 global markets.

The challenge I hadn’t anticipated was this: I knew very little about quality operations. And the users I was building for, workers on assembly lines in warehouses, were not like any users I’d worked with before.

These were people moving fast, working with their hands, deeply sceptical of a new piece of software that someone from the product team had decided they needed and none of them were sitting at a desk.

The job, as I understood it, was to figure out what they actually needed and build something they’d actually use, while also ensuring the solution could scale across every market we operated in, not just solve for one. That second part is where the real tension lived.

Early on, I ran into a conflict with a regional operations stakeholder. They wanted the product rolled out quickly with market-specific customizations. Their market had immediate pain: quality errors were spiking and customer complaints were following. They needed relief now, and they needed something that fit their specific workflow.

I understood that. But I was concerned about what would happen if we built bespoke solutions for every market. We’d end up with 13 different products masquerading as one. Maintenance would become a nightmare. Scaling would become impossible.

Saying yes would have meant hitting the launch date and dealing with the technical debt later. Saying no would have meant holding the line on global architecture and asking them to wait. Neither felt right.

So instead of debating the decision, I tried to understand what was actually driving their urgency. Not the surface ask, but the underlying problem. When I dug in, what I found was simple: they were drowning in quality errors that were hitting customers, and they felt like no one was moving fast enough to help them.

That changed everything about how I approached the conversation.

I stopped framing it as a debate about architecture and started framing it as a problem we were solving together. I walked them through the tradeoffs of heavy customisation versus a configurable global solution, not to convince them I was right, but to make the decision transparent. Then I proposed a middle path: we’d launch with a standardized core workflow, but build in specific configuration points that addressed their immediate needs without fragmenting the platform. We agreed on success metrics upfront. Instead of just “does this work for your market” i focussed on “does this reduce quality errors in a way that holds up across regions.”

In parallel, I had to get much closer to the assembly line workers than I’d originally planned. Warehouse user research looks nothing like office user research. There are no scheduled discovery calls, no conference rooms. You catch someone between shifts, watch them work, and notice what they ignore versus what they actually use. The insight that stuck: the app needed to work with one hand, in a loud environment, for someone who had never once thought about UI design.

That user research was uncomfortable. It was slow. And it was the most valuable thing I did on the project.

The Rollout and The Numbers

The rollout sharply reduced quality errors in that regional market. Because we held the line on a configurable global architecture rather than bowing to market-specific customization, this very foundation is what allowed us to cleanly scale the QA application across all 13 global markets.

By transforming those fragmented, manual workflows into a unified, scalable digital platform, the project ultimately delivered £500,000 in annual savings and eliminated over 600 operational hours annually across our international fulfillment network. Throughout the aggressive multi-region rollout, we leveraged tight monitoring loops via SQL and Grafana to maintain a 99% platform uptime SLA, ensuring the physical assembly lines never stalled.

But the number I’m proudest of is harder to quantify: assembly line workers in markets across the world were actually adopting and using the tool daily. That doesn’t happen by accident.

Stakeholder conflicts are almost never about the thing they appear to be about.

This one looked like a debate about speed versus scalability. But underneath it was something simpler: a stakeholder who felt unheard, and a PM who hadn’t yet done the work to understand their real problem.

When you focus on the underlying concern instead of the stated position, alignment becomes much easier. Not because you always give people what they ask for, but because when you understand what they actually need, you can often find a path that works for everyone.

The other thing I learned is that building for users whose world looks nothing like yours requires genuine discomfort. You have to go where they are, watch before you assume, and resist the urge to design from a distance.

That discomfort is where the best product decisions come from.

1. Why This Feature Is More Interesting Than It Looks

I was at the gym this past Monday, grinding through my last set of bench presses. Headphones on. Till I Collapse blasting.

Ninth rep. And I was done. Or at least I thought I was.

Then something subtle happened in my headphones.

Till I Collapse started to blend into Lose Yourself. No pause. No silence. Just a slow, intentional transition. And suddenly Eminem is in my ears again - “One shot. One opportunity…”

I smiled.

Four seconds ago, I was ready to quit. Now I was hitting the tenth rep.

That moment - that extra push - is what I believe the Apple Music product team envisioned with AutoMix. And honestly, they have nailed it.

At first glance, AutoMix looks like a fun audio trick. It isn’t.

What it actually does is quietly, without calling attention to itself, removes a tiny but critical interruption: the few seconds where your brain asks, “What should I play next?”

Instead of decision-making, Apple replaces that gap with anticipation. A smooth, energetic handoff from one song to the next.

As a Product Manager, I’m confident the goal here was never “better transitions.” That would have been the lowest-hanging fruit (and Apple doesn’t ship those).

What Apple focused on was something deeper: energy continuity.

Even a few seconds of silence can break momentum, kill immersion, and reduce engagement. Shuffle and playlists have plateaued. Manual curation is friction. Context switching is the enemy.

AutoMix is Apple acknowledging that in today’s products, the margins matter, and sometimes removing silence is more powerful than adding features.

2. The Apple Way of Solving It

The obvious approach would have been to make AutoMix a visible feature - a “DJ mode” or a dedicated AutoMix section that users consciously interact with.

But Apple rarely does that.

Instead, they made AutoMix feel like it was always supposed to be there - quietly improving the listening experience without demanding attention. It reminds me of OTP auto-fill on iPhones: simple, almost invisible, but incredibly effective once you notice it.

Apple has long had a bias toward making intelligence feel invisible. The best Apple features don’t ask you to learn them, they just remove friction from experiences you already have.

AutoMix fits perfectly into that philosophy.

It feels less like a growth feature and more like a craft feature. The kind that comes from a team paying attention to experience details most users never explicitly complain about.

3. Why Now?

AutoMix is also a “right-time” feature. It likely couldn’t have existed in this form three to five years ago.

Real-time audio processing and on-device machine learning are now fast and efficient enough to make transitions feel instantaneous. At the same time, streaming UX innovation has plateaued. The good old playlists, shuffle, and recommendations are already mature.

That shifts the frontier from what to play → how listening feels.

Combined with Apple’s hardware-software integration advantage, AutoMix feels less like a new feature and more like a capability that only recently became possible.

4. Not a Feature but A Capability

The more I think about AutoMix, the more it feels less like a feature and more like a capability Apple has developed.

What Apple really built isn’t just smoother song transition, it’s the ability to understand tempo, energy, and structure of music in real time and adapt playback accordingly. Automix is simply one visible expression of that capability.

And once a capability like this exists, it rarely stays confined to a single feature.

The same foundation could power:

• smarter workout playlists

• context-aware music transitions while driving

• adaptive DJ-style listening experiences

• tools for artists and creators

In that sense, AutoMix feels less like a destination and more like an early signal of where Apple Music experiences could go next.

5. Trade-offs Apple Quietly Accepted

AutoMix isn’t perfect, and it doesn’t need to be.

Apple appears to have made a deliberate trade-off: accept occasional imperfect transitions in exchange for maintaining continuity. The alternative, silence between songs, is predictably worse for immersion.

This is a classic product decision: optimize for overall experience quality, not edge-case correctness.

There’s also a deeper trade-off at play: artist intent versus listener experience.

Songs are produced with deliberate beginnings and endings. Silence can be part of artistic expression. AutoMix slightly reshapes that boundary by treating music less like individual tracks and more like a continuous experience.

Push too far, and remixing could feel intrusive. Stay too conservative, and the feature loses its value.

AutoMix today feels like Apple testing that boundary carefully.

6. What I’d Watch If I Were on the Team

If I were on the Apple Music team, I wouldn’t just watch feature adoption - I’d watch behavioral signals of continuity.

First, I’d look at listening session length and songs per session. If AutoMix is working, sessions should naturally become longer because fewer moments of silence interrupt momentum.

Second, I’d track manual interventions during listening:

• song skips

• manual song selection

• search actions mid-session

A reduction in these behaviors would suggest the system is doing a better job maintaining flow.

Third, I’d pay attention to failure perception, not just usage. Even if transitions are technically correct, a few noticeably “wrong” remixes could disproportionately affect user trust.

Finally, I’d watch where AutoMix works best:

• workouts

• driving

• focus listening

• background sessions

These contexts likely benefit most from continuity and could guide future investments.

Apple Music’s latest innovation called AutoMix is a reminder that meaningful product innovation doesn’t always come from new surfaces or bold features. Sometimes it comes from noticing small moments where experiences break, and quietly fixing them.

This isn’t just about remixing songs. It’s about maintaining momentum, reducing friction, and making listening feel uninterrupted.

Strong product teams don’t just ship features - they build capabilities that make experiences feel effortless.

AutoMix may look small on the surface, but it signals something bigger: Apple Music is starting to optimize not just for what you listen to, but how listening feels.