In the last week HubSpot acquired Warmly and Zoom acquired Common Room. These are serious acquisitions. It’s real money spent on tools that surface who’s in-market, who’s visiting your site, who your reps should call next.

I get it. The front door is where new revenue lives. You want to know who’s knocking before they leave.

But once you’ve spent all that time, money, and energy getting someone through the front door -- who’s watchin’ the room?

Watching the room is what converts the front door.

An inside story that got my attention

We had a sizable customer in a 30-day trial. The account wasn’t hitting activation thresholds. Our generic onboarding emails went out. Opened, but zero response.

A playbook flagged the account. I sent a personal note -- co-founder to economic buyer. Nothing automated, just a simple “From what I can see, you’re probably 80% of the way there -- if you do these other 20% of your setup, you’re going to get value out of this.”

One email that get a response, got us on two live calls, and helped close a $10k-plus deal.

That flag only worked because we had account-level visibility and user-by-user granularity inside that account. I could see which users had engaged, which hadn’t, and where the setup had stalled.

Our attention has been split between the front door and the room from the start -- we wanted new logos just like everyone company does, but we also run daily meetings on trial activation and trial health. This deal is why we keep doing it.

The stack gap the big platforms ain’t talking about

Enrichment tools -- like Warmly, Common Room, Freckle, 6sense -- are excellent at telling you who someone is and what they should want based on firmographic profile and intent signals.

Behavioral data tells you what they’re actually doing.

This is behavioral data that nobody else can tell you. It’s pure 1st-party data you own. Only you can see what your customers are doing in your product, and that’s an awesome advantage to have if you’re leveraging that and your competitors aren’t.

The delta between expected behavior and actual behavior becomes your message. With good product data you can say: “I know what you’re trying to do. I can see exactly where you’re missing it. And I can tell you how to get there.”

Generic outreach doesn’t cut it anymore. “You still have three things left on your onboarding checklist” is noise in an otherwise noisy inbox. Operators who can connect observed behavior to a specific intervention -- that’s signal.

Why most post-sales teams aren’t watching

There are four reasons I see over and over:

1. The data’s a mess

2. The data’s inaccessible by the right teams

3. It’s not even the data -- it’s ownership of the tools

4. A tracking plan wasn’t implemented

Post-sales teams haven’t built this muscle. It wasn’t part of the job description five years ago. And it’s not a lack of will or interest, it’s been a lack of availability.

Then there’s the dashboard graveyard. Every team gets excited about new product analytics. Big launch with big promises. Within three to six months everyone’s tired of it telling them what happened without any real explanation attached.

“Trial activation is down 18% month-over-month.”

“Neat. Now what?”

“…”

Two problems stack up:

1. Knowing what good looks like (and documenting it) is step one.

2. Being alerted at the right time, without having to go look, is what makes proactive outreach possible.

Most teams have one. Too few have both. But if you don’t have it today, you can get it setup pretty quickly.

A quick audit worth doing

Set aside a few minutes. Look at your current tooling and ask:

• Do I have account-level visibility or just individual user activity?

• Do I know our activation criteria -- the in-product actions that actually predicts retention?

• Are the people who can act on that data the ones getting alerted?

This is the problem we work on at Accoil, so yes, we’re biased -- but the audit is worth doing whatever tool you use.

It’s worth an honest look: You can probably see who’s coming to the front door, but can you see what’s happening in the room?

The party happens in the room anyway, so it’s definitely the funner place to be ;)

Peter

Selling to startups is a bad idea.

I’ve been circling this thought for a while. A call this morning made it clear.

I was on with a founder in sales tech, with high growth potential, building in a blood-red ocean. Wicked smart and moving fast. He said exactly this:

I wish I had a problem my spreadsheet couldn’t handle.

I wasn’t pitching to him, but he genuinely wishes he had that problem. He wants more customers, more complexity, more revenue, more reason to spend money on tools. But right now his noggin and his spreadsheet handles it. So he doesn’t need us and he may not need you.

I had the same conversation with a homebuilder in our area. He’ll have 10 to 20 projects running at any time. “I have it all in my head,” he says.

It also happened with a founder I met at a conference who showed me the most carefully maintained spreadsheet I’ve ever seen. It was beautiful — I wish I could show you because you would agree. Even though it’s “just a spreadsheet.” He and his team know they’ve outgrown the beautiful spreadsheet. But they’re not done with it yet.

The trap I’ve fallen into is thinking the spreadsheet is the problem to solve. It isn’t.

The spreadsheet is a signal telling you the company is too small to buy from you. You can do a great demo. You can show them everything. If they’re still operating comfortably at that scale, they’re right to stay where they are. Spreadsheets are light and don’t cost much to maintain.

When a team moves off a spreadsheet they’re comfortable with, they may have to spend more time wrangling a new tool than facing the market. So they stay put.

The software founders and the homebuilder are absolutely right to run their businesses this way. As tools and tool counts grow, the surface area you need to manage at that stage changes from market surface area to software surface area.

The more time we spend facing the market — and the less time we spend managing our tools — the better.

When selling to smaller companies, there is a crossing point when they graduate from spreadsheet to tools like yours. But you have to know what to look for.

When we’ve seen it happen — when someone actually makes the move — it usually comes down to prioritization. The book of business has outgrown the staff. There are more accounts than one person can hold in their head, more decisions than gut feel can handle. Someone says: I only have so many hours in a day, and I need to spend them on the right accounts, the right activities, the things that keep as much revenue as possible.

That’s the signal. Not “I have a spreadsheet.” Not “I’m not sure about the ROI.” The signal is: I can’t prioritize my work anymore. Or something like that — you’ll know what that moment is for your customers.

There is a leap of faith customers have to take when moving off the spreadsheet. They know the spreadsheet is working well enough right now because their business is healthy.

And changing things up creates this fear of making the wrong choice and maybe going backwards. That fear almost always outweighs the potential to grow. It’s hard to argue someone out of that. You can only be ready when their own scale forces them to make a decision.

Interestingly, AI is holding this off longer than it used to. AI + Spreadsheets can do a lot right now at the early stage. But AI is probabilistic and it often doesn’t give you the same output every time. When you can catch the inconsistencies yourself, that’s fine. When you need consistent, repeatable action at scale, you need something deterministic like software. That reckoning is coming, just not today for most customers.

So what do you do with the spreadsheeters?

We have a Keep Warm column in the CRM. We watch for growth signals like funding, new hires, product launches, leadership changes, etc. We reach out when something changes. After all, the relationship is worth keeping and these signals can be automated. You can even put them in a spreadsheet ha.

Bottom line: if the companies you’re selling to are comfortable in a spreadsheet, you’re selling to the wrong people. I’ve learned this more times than I care to admit.

Think about what signs and signals tell you when your customers are too big for a spreadsheet. Find that point and you can go in and start selling to them.

TTFN,

Peter

PS: Happy Birthday Weekend, America 🇺🇸 and Go the Socceroos 🇦🇺!

I’m a software founder. so yeah, I want to believe software wins even in a world where everyone wants to build their own tools.

So when Markie Wagner published “Return on Tokens“ -- AI is a compiler, not a runtime, it has no goals, work decays into slop without human direction -- I felt that old familiar pull of agreeing with things that confirm what I want to believe.

And when Elena Verna dropped her “Mom-and-Pop SaaS“ frame -- build costs collapsing, domain experts spinning up their own tools, Jevons paradox meaning more software gets built not less -- I nodded along to that one too. Not quite happy about it, but also kind of encouraged...?

Both ideas are probably right. And both ideas are quietly threatening SaaS products.

If build costs drop far enough that a VP of Sales with no engineering team can just build their own sales intelligence tool -- why buy ours?

If domain experts can make something that fits their domain exactly, the generalist product starts to look like a giant spaghetti mess.

So I’ve been trying to be honest with myself about where SaaS products provide value today and tomorrow.

Where software still wins

I keep landing in the same two places.

1. Where reliably repeatable outcomes are needed.

2. As close as possible to decision points.

Let’s look at Accoil as an example.

The signal layer is becoming free. Or close to it. Messy data can be made clean with agents or agent-built software. It’s cheap to do this.

By signals, I mean things like a company just hired a VP of Sales, a competitor got acquired, a prospect visited your pricing page. These are legible and getting cheaper to access by the week.

First-party data, specifically product usage like Accoil ingests, is different. Higher fidelity. Harder to fake. The problem is, the data doesn’t tell you what it means.

Behavior is visible. Intent is not.

To get reliable behavior patterns, you need reliably repeatable interpretation of the messy data.

The what is visible. The why is the unsolved part. The why is where the money is moving because that’s where decisions are being made.

Yesterday I wrote that the signal is solved -- the action is the open frontier. That was one step. This is the step behind it, the one that makes the action problem hard: signals don’t interpret themselves.

Knowing a customer’s usage dropped 40% tells you something happened. It doesn’t tell you whether they’re about to churn, or whether they had a vacation (common and kind of predictable), or whether they’re quietly evaluating a competitor. The signal is legible. The situation is not.

The defensible layer isn’t the signal. It’s what the signal means for THIS customer, in their specific situation, right now. Not in aggregate. Not in general. For a specific “them.”

That’s where interpretation becomes the product. Action becomes the value.

(Accoil -- sigh, this is what we do -- lives in the signal layer. That’s exactly why I’m hunting the edge of it. If I’m sitting on a layer that’s becoming commodity, the useful thing is to see it clearly, not defend it.)

Ben Williams put the right frame on this: own the verb, become the default, expand from there. The verb is the action. Not the data, not the signal. The thing that actually changes what happens next for a customer.

It’s going to be ok

I’m optimistic for us software builders.

Markie’s right that AI has no goals. Elena’s right that build costs are collapsing. But what Jevons paradox tells us is that lower costs don’t shrink the market -- they expand it. More software gets built, not less. More signals exist, not fewer. More interpretation is needed, not less.

Everybody wins. But the people who win big will be optimistic enough to keep looking for problems to solve. As new tools emerge -- what problems get solved, and what new problems does that force us to find?

There’s more to build. It’s just not where we’ve been building.

Peter

PS: What do you think? Where do you see opportunity? Or do you feel like it’s all converging into agentic soup?

The signal is the reason to reach out. Max Mitcham proved it at Trigify: he says he got 48 meetings from a list of 120 leads using his own tool + Claude Code. In Max’s framing, timing and relevancy beat personalization every time.

He’s right. And there’s something else underneath that idea.

If you’re in the business of surfacing data or signals, that part is getting easy.

One sec: I should define what I mean by “signal” in this context.

These are signals:

• Product analytics data (sigh, this is what we do)

• Task lists and kanban boards

• CRMs and pipeline flows

• OKRs and KPIs

• Etc.

Intent data, hiring moves, funding rounds, competitor announcements. Vendors package this and point AI at it. The signal layer is becoming table stakes. It’s not worthless and it still has some life in it, but it is getting cheaper by the quarter.

Legible signals vs. valuable signals that explain nothing

External signals are legible. A company hired a VP of Sales. A competitor got acquired. AI reads these, scores them, triggers a sequence. That part is becoming a commodity, not a moat.

First-party data -- product usage, for example -- is different. It’s higher fidelity, but the data doesn’t tell you what it means.

Someone logs in every day. Are they winning or stuck? A feature sits unused. Did they not need it or did they just not find it? Behavior is visible. Intent is not.

“I can see what is happening, but not always why”

I asked the onboarding lead at one of our vendors whether she could see how I actually use their platform. She was honest about it. She can see what I built, but only when she logs in as an admin.

What she can’t see is how I move through the product moment to moment. Where I got stuck. Why I stopped doing something I used to do.

Her words: “I can see what is happening in the account, but not always why.”

A signal-rich tool, built to surface behavior, and the person responsible for my success still can’t answer why.

The what is visible.

The why is the unsolved part.

The why is where the money is moving.

The open frontier

A RevOps lead I know has built real confidence in product signals. He’s not surprised by churn anymore. He can see it building weeks out. He and his team have made real progress and it’s awesome to see such clarity.

What he hasn’t cracked, though, is what to actually do about it. The action that reliably lifts net revenue retention. The signal is solved. The action is the open frontier.

That gap, between seeing it and knowing what to do, is where the real work sits now.

I picture it like I would a real frontier: imagine standing on the edge of the great forests of what is now the USA, staring out at an endless sea of grass and prairie. The value isn’t in the mapped forest behind you, it’s out in the unmapped prairie. That’s where you go to build new stuff and grab land.

What your product is actually becoming

Wes Bush at ProductLed and Ben Williams of PLGeek are both circling this. They’re asking their newsletter readers to think deeply about the problems they’re building to solve.

A lot of the problems we’ve all built for are now solved by Claude and Codex.

What a product even is anymore feels up for grabs. AI can do a lot of what software did for years. If your value proposition was “we surface the data,” that part is getting cheaper fast.

The defensible layer is interpretation and action. What this signal means for this specific customer, in their situation. What to do next. Not in general, but for a specific “them”.

This is a threat to a lot of existing tools, for sure. But it’s also an opportunity. It’s where the moats are forming.

If AI is making a core part of any product nothing more than table stakes, what do we build next?

A lot of what we’ve all built for the last while is tooling to say to a human reader: This is what you need to know so you can decide what to do next.

As Claude Tag moves into Slack and gives us all an army of Claude agents embedded in every channel, the work of surfacing these signals is abstracted away.

And it leaves us to build for the problems and opportunities that come next.

When the signal is damn near free, where do our products provide value?

Peter

PS: This is actually an optimistic note. There’s more to build. It’s just not where we have been building.

Dashboards don’t drive anything. Alerts that fire when the good or bad signals happen are what kick off the work.

This morning I pulled up the new dashboards the team’s been building in beta. They look good. They surface the right data. Then I sat there for a minute and realized that the dashboards aren’t the point. The alerts, the actions, the outcomes are the point.

I’ve known that for a while, but it landed when I started building the dashboards myself.

We built Accoil to move product analytics from a system of record to a system of action. The distinction sounds clean in a pitch. Living inside your own product makes it concrete. A dashboard can give the appearance of understanding. You open it, you see numbers, you feel informed. But feeling informed and acting on a signal are two different things.

What dashboards vs signals actually looks like

One of our top-three accounts quietly disengaged over about a month. Usage dropped and a power user who’d been active three days a week went quiet. Nothing dramatic – no cancellation, no support ticket, no angry reply to a check-in email. Just a slow cooling.

If all I had was a dashboard, I’d have to remember to look closely, compare week over week, notice the trend. That sort of stuff is easy to miss. What’s cool is that the alert caught it. It got the data to us in a way that we could act on it – reach out, understand what changed, get ahead of churn instead of chasing it.

The flip side matters just as much.

Another account came roaring back, doubling its active users over two weeks. That’s a signal to pounce on now, not discover late. An expansion conversation, a case study ask, a referral introduction – all of those land better when you catch the momentum live, not in a quarterly review that most customers don’t really want to do anyway.

The work isn’t in the dashboard. It’s in the signal, the alert, the action.

A number you have to remember to go look at is a number that’s already too late

Dashboards are necessary. You need them to orient, to understand your business, to know what normal looks like so you can recognize abnormal. But they’re not enough.

A dashboard you check on a good Monday morning doesn’t find the account that cooled last Wednesday. Tools should work for you, not demand you work in them.

What if the signal came to you?

Putting it into practice

Pick one customer segment – your top accounts, your recently onboarded cohort, your highest-growth users. Pick two or three signals: cooling (feature drop-off, login frequency down, power user goes quiet) and heating (usage spike, new users added, breadth of feature adoption up). Wire them to Slack. Bing bong.

Or if you want to go further, run them through Claude via MCP with a cron job and bring the summary into your daily standup.

The point isn’t the tool. The point is that the signal reaches you where you already work, so it becomes impossible to miss.

A system of record tells you what happened. A system of action finds the signal in the noise and puts it in front of you before it’s too late to do anything about it.

Build more systems of action.

Peter

We give people 30 days to try Accoil. For a long time I let that number run my thinking: 30-day trial, so we’ve got 30 days to win them over. Check in around day 30, see how it’s looking, try to rescue it or send a thank-you note.

That’s backwards. And I think a lot of us have been doing it.

Amplitude released a report saying that the first seven days of a new customer’s life has an outsized impact on their retention and lifetime value. The better activated someone is in those first seven days, the higher their retention rate at the 90-day mark. I’m now hearing versions of this on call after call. Teams everywhere are shrinking the window they actually pay attention to.

The 30-day trial trap

Turns out the 30-day window is a trap. If you offer a 30-day trial and you don’t look at the health and activity of an account until day 30, you’ve waited too long. There’s no time left to respond, react, nudge, or adjust. A 30-day window is really a decision made up front: we’ll let be what will be, and at day 30 we’ll either scramble to save it or pat them on the back and say thanks.

A seven-day window is a completely different posture. It says: let’s put as much of our attention, and ideally theirs, on getting activated, understanding the value, and making the rest of the trial genuinely useful. So that when the moment comes to put the credit card in, it isn’t even a question.

Why is the window shrinking?

Two reasons, I think.

First, it’s finally getting the attention it always deserved. I know a $30M ARR SaaS company that shifted focus away from retention work and toward onboarding work, because they realised the better their onboarding and activation, the higher their retention downstream. It’s a renewed focus on the highest-leverage moment you have with a customer: the very beginning.

Second, switching costs have collapsed. When I shop for tools now, I’ll run two or three at once. The one that’s easy to use and helps me get going wins. The one where I have to wait on a CSM to schedule a call, who then sends me docs I couldn’t find myself, loses. Momentum gets built or destroyed fast.

I can see it in our own numbers. The single biggest early predictor of conversion is how quickly a team connects a data source. Connect on day one versus the last week of the trial, and you are remarkably more likely to convert. We’ve even extended trials so teams could have a proper crack once data was flowing, and it still doesn’t work late. If the momentum’s gone, it’s gone. Get them activated early or it’s very hard to claw back.

This is the reframe: offering someone 30 days and needing 30 days are not the same thing. You offer 30 in the hope they find value. The window you actually manage might be seven days. It might be one day.

Think of Facebook’s famous activation metric of connecting with seven friends in ten days. Every product has its own version of that. Ours is connecting data, early. While we give people 30 days, what we really want to see between day one and day seven is an absolute frenzy of activation activity.

The shrinking activation window

The Monday-morning move, and this was literally my Monday this week: map your ideal onboarding day by day. Two dimensions, time and activity. On what day do you want a customer to complete what action? For us, if you can point your data source at Accoil in the first 15 minutes, we’re off and running.

So, what’s your product’s first step? Once you have that written down, move on to the next step on the ladder. Not all activation is linear, but for the first critical steps customers shouldn’t skip rungs.

Like copywriting, the point of the first step is to get them to the next step, and so on.

Day zero matters more than I gave it credit for. Map it. Then start asking the question our customers are now asking us: how do I measure time to activation, and what can I test to shrink it?

Peace out,

Peter

The hype in GTM right now is all about going from signal to action as fast as possible. A customer does something, a sequence fires. A prospect trips a trigger, an email lands. Signal straight to customer, automated to the hilt before anyone’s checked whether it works.

Fire. Ready. Aim.

It’s seductive, because the promise is that it runs on minimal effort and minimal input. You flip it on and it hums, that’s the promise I see a lot.

But the hype leaves a lot of the story buried.

Edison famously took 10,000 or more tries at developing a lightbulb that worked and lasted. A lot of the results we’re shown on LinkedIn and AI-hype-y Product Hunt launches are the 10,001st attempts -- the workflows and automations that survived the trials and testing.

Automation is not the first step

The hype isn’t an empty promise. It just whitewashes the work behind automation that’s actually any good.

There are teams doing amazing work. Workflows.io has some killer materials and their clients are benefiting from their work.

But what we see publicly are the workflows and automations that the team fought hard to build. And even then they’re always refining things. Any GTM builder will tell you the same -- it’s a constant evolution to find what works today and hopefully tomorrow.

How do you do that?

It isn’t by automating the heck out of everything first.

Point your signals at yourself first

So before you wire a signal straight to the customer, point it at a human you know first. Build for signal to sales rep. Signal to success manager. Signal to the teammate who owns the account.

Send the signals to the human who owns the judgment and has the ability to look at something and know whether it’s the right move. Automation without this misses a lot of important nuance.

Even if you feed it every call and support ticket you own, your AI won’t have the same level of context and awareness of even junior teammates. Some things just don’t translate into robot.

A Head of Growth I know put it like this:

if the signal went straight to their customer, it felt like a missed opportunity, a relationship moment handed to a machine instead of a human. Most business is still human to human. That’s what makes or breaks deals.

I’ve felt the cost of skipping that. I gave an outreach tool what I thought were tight parameters, and it reached out to people we should never have been selling to. A symptom of moving through the build loop too fast.

Maybe it doesn’t feel like it cost much, but there’s reputational damage at risk. When there is a relationship worth having, getting it wrong costs a lot more.

It’s noisy out there

There’s noise underneath every signal-based GTM motion. AI is powerful, but everything was already noisy, and AI has made it really easy to turn up the volume.

So many tools promise to be the single pane of glass that filters the signals, yet I’ve never seen one team actually run from one.

That’s why we, the humans, still need to be in the loop for any automations or agentic flows we’re building. To help discern signal (value) from the noise.

When to skip the HITL

Is signal straight to customer ever right? Sure. If you’ve got a PLG, self-serve motion, it’s probably expected by customers.

For PLG + Sales-led companies like Atlassian, there are clear customer segments that warrant different approaches. For the PLG, self-serve customers, it’s fine to skip the human-in-the-loop because there are too many people to communicate with and the value from that work isn’t there in the form of high ACV. Self-serve customers can get shorter signal-to-action loops because there’s less at stake.

That’s not to say they should be treated like garbage. Put some effort into the automation, but don’t have a teammate sitting there reading every signal-based in-app message before it’s sent.

Higher ACV customers can and should benefit from the discernment and taste of a human. If your key customers have a seasonal business or have shared some context with you no AI would ever know, that’s leverage you can use to make the signal-to-action logic even better.

Start simple

If you’re not running data-backed signal-to-action campaigns, why not? If you’re building SaaS or online at all, you have data you can use.

Pick one outcome and one workflow for one role. Find a signal that supports the outcome. Run experiments, and route the signal to the human on your team so the judgment stays in.

Once you’ve run the workflow enough and are up to 80-90% sure automating it would bake that judgment in, expand from there.

Start simple. Keep the human in the loop until the loop earns its automation.

Peter

A customer pinged us last week, a little confused. A handful of their users had gone vertical -- big, sustained spikes in product activity. The kind of engagement curve you’d frame and put on the wall.

Turns out it was AI agents doing all the work, making it look like the individuals deployed them were super busy. These are bots those users had deliberately let loose inside the product -- not malicious, in fact very intentionally put there, part of a platform shifting from “do automations” to “be proactive.”

So despite the human users looking like they were on fire, the agents were doing the work.

Then I went and looked at our own website. PostHog reckons about 38% of our pageviews over the last 90 days are bots -- and that’s a conservative floor, sitting on top of the bots PostHog already drops before we ever see them.

An army of 267 “visitors” crawling the whole site, frozen on one Firefox version, running out of AWS datacenters. Strangely around the same time, I’d been getting Intercom messages and emails from new SaaS clearinghouses asking to list us. The traffic spike and the scraper outreach were probably the same story. I just hadn’t put them next to each other until now.

We already know bots and/or agents have overtaken humans on the internet. Expected. The question that actually matters isn’t whether it’s happening. It’s what it means for us, as builders and product owners reading data to decide what to build next.

My first instinct was wrong

My first reaction was to filter it all out and move on. Strip the noise. Get back to the humans. Maybe that was how you felt too.

But first we have to ask what value is attached to that traffic. And to answer that, we have to know what job the bot was sent to do.

If we’re talking agents, well they’re just a human abstracted away one more step. The agent does a pile of work, and at some point a human acts on it. Your product might be at arm’s length from that person now, but the activity isn’t valueless just because no person clicked the touchpad.

There are going to be entirely new jobs to be done that agents unlock -- work a human would never have done by hand. So “bot activity is just human activity, amplified” is a bad assumption. I’m betting much of it will take a different shape entirely.

Valuable job vs. vanity job

So how do you tell a valuable bot job from a vanity one? I don’t have a clean answer. But here’s where I’m landing for now:

Watch for volume swamping value. An agent that fires the same action a thousand times isn’t a thousand times more engaged. That’s the noisy bit -- the part you weight down, segment out, and look at on its own rather than letting it flood the signal.

Then do the unscalable thing: ask. Talk to the customer. What agents do you have running? What are they doing? Why? What are you hoping to get out of them? You’ll learn more in one call than in a month of staring at event counts.

Not all bots are pointed at you

There’s at least two flavors here, probably more. Worth noting, I’m using the term “bots” when it could be the traditional idea of a web scraper bot or an AI agent:

1. Bots working for your customer, inside your product. Think of Atlassian’s AI, Rovo. Rovo’s agents could be using your SaaS to get a job done. These can be real value -- a customer getting more out of you, just one layer removed.

2. Bots working for someone else, hitting your surface. AI crawlers reading your site, scrapers, eventually browser-based computer-use agents doing real work in your product on someone’s behalf.

The value splits hard inside that second group. A crawler that reads your site so ChatGPT can surface you in the right query? That might be really valuable traffic.

A scraping bot lifting your pricing and describing what you do (poorly, I might add)? That’s someone taking, not a customer arriving. It all takes the same shape in the logs, but has real opposite value. You can’t tell them apart without asking what job they’re on.

Why this isn’t academic

If you can’t separate human from agent in your engagement data:

• Health scores that mean nothing

• Activity rankings are built on ghosts

• Usage-and-revenue forecasts ride on work no person did

We can start optimizing for the wrong user -- building toward the wrong customer because we can’t (or don’t) see who’s actually getting value.

A funny irony? I’m using AI tooling to sort the AI noise from the signal. No idea how accurate it is. Feels like the whole problem in miniature. Anyway.

So, I don’t have a neat bow to put on this one.

If you’re reading any data that touches customer or public engagement, this only gets more important: learn to split it -- human, agent, bot -- and trace where the value actually lands.

We can only keep building for the right entity on the other end if we can still tell who or what they are and what they need to get done.

Ai ai ai,
Peter

Saturday morning I opened Claude on my phone to use Fable for something, and it was gone.

My first thought certainly wasn’t a big one. It was “did I accidentally unsubscribe?” or do something wrong?

So I checked my Anthropic account. Nothing wrong. Then I did what you do -- went to X to see if it was just me. And there was the notice: the US government had asked Anthropic to press pause on Fable.

My very next thought was: damn, I hadn’t finished the work I’d lined up with Fable. Our website. A free tools site build. A pile of things it had been quietly unlocking for me all week.

It’s Monday now, and I’m honestly not sure I’ll get through that work as fast, or with as much confidence, as I would have on Friday.

That’s part of the fun of all this, I suppose.

Locked in?

We got lucky, mostly. We’re not 100% locked into any one model, and none of our workflows are tied to a specific one -- we can swap an Anthropic model for an OpenAI one pretty painlessly. So in one sense, nothing broke.

But it rattled something loose. Are we actually planning for this?

Short answer: nope. The risk I’d been managing turned out to be oply one of the things to consider.

I’d been thinking only about cost. Token crunch, prices creep up, how do we absorb it, how much margin do we hand back. That’s a commercial risk, and commercial risk is the comfortable kind -- how you respond to growing costs is in your control. You’ve got levers. Pricing. Margin. You can model it on a spreadsheet.

What I hadn’t been thinking about is availability and continuity. What happens when a model just goes away, and not over a price you can negotiate, but because of a decision you had no part in?

That risk is out of your hands. The only thing in your hands is whether you did any insurance thinking ahead of time. I hadn’t. The question I couldn’t answer Saturday: if we entirely lost access to frontier models, do we know what we’d do? Again, short answer: nope.

It’s nothing new

Tools going away is nothing new -- they get acquired and shut down, sunset, quietly killed. Usually there’s an alternative and it means a migration headache, not a funeral.

A model feels different because it’s baked into how you work. Except, like I said, for us the model itself isn’t. Swapping vendors is easy.

So the lock-in wasn’t the vendor, but the category. It’s the assumption that frontier AI will simply always be there in the same way we assume the internet is always there.

Picture going all-in on the internet to run your business, and then having it taken away. That’s the dependency I’d stopped seeing. And it gets deeper every time you wire up another agent to do real work, important work on a schedule.

I don’t have a tidy answer yet, and we’ll keep using frontier models -- you have to, that isn’t the lesson. The lesson is smaller and more annoying: I’d stopped looking.

So here’s the one thing I’m doing this week. Taking 30 minutes to look at important workflows from across the copmany (product, engineering, go-to-market, sales ops, etc.) and drawing a quick exposure map.

Where are the dependencies we hadn’t thought about? What happens if it doubles in price, or disappears? I don’t think everything will need an immediate fix, but it’s important to see the dependencies and possible gaps.

From there, we can plan for insurance or fallbacks.

The worst dependencies aren’t the ones we choose. If there’s a clear decision to go “all-in” on a tool, it’s usually with eyes wide open.

The dependencies that sting are the ones we just walk into, assuming that everything will just keep working.

Time to take stock of how dependent we are on LLMs and those big frontier companies.

Peter

PS: This isn’t the first time (or the last) platform dependence matters. It’s just the latest. And maybe because it’s AI it feels bigger?

Two customers asked me some version of “what does good look like?” in the last two weeks. Different companies, same question.

If you’re building anything data-shaped, you get this constantly. What am I looking at? What does it mean? Is this number good or bad – and how would I even know?

The first instinct is to reach for a benchmark report. Makes sense. Those reports exist for a reason. But looking at industry benchmarks for a lot of data types is a waste of time.

The definition of good can be very flexible. It changes depending on things like your ACV, your product type, your market segment, whether your economic buyer is also your end user, whether you sell through partners or direct.

You have to build the benchmark yourself, from inside your own customer base.

The real question we ask of our data

When a head of CS asks of a health score “is 72 good?”, they’re actually asking: what am I going to do on the back of this? How do I react? That’s what’s underneath the question.

There are two sides to every data point. One is which direction it points you. The other is its inverse.

If you’re defining good, you’re also defining bad.

Once I have a definition of good, I spend most of my time looking at and looking for the inverse. It’s Charlie Munger’s “invert, always invert.” Understanding what makes a bad number happen is equally as important as understanding what makes a good number happen. That’s the half many of us skip.

How it looks in practice

Take account health. You’ve got an account in the bottom quartile of its customer segment, underperforming against the measures you’ve decided signal healthy or unhealthy. You’ve also got a peak performer in the same segment. The question worth asking: what’s the delta? Not “what’s the score” – what’s actually different between these two accounts?

The delta between the poor performer and the peak performer turns into a task list. Automated or human, doesn’t matter. That list is aimed at changing behavior on those accounts. That is the work.

That’s what all data intel points to.

We’re a data company and we’re still working on this

We built Accoil on a relative number, not an absolute one. That means “Good” can change.

Customers tell us they trust the signals Accoil gives them. But then it’s a matter of learning what to do with those signals.

That’s the gap pretty much all data hands us. Got a signal… what does it mean and then what?

With any data set we use to improve our business, new tools can help us all lean in:

• here’s the signal

• here’s what it means

• here’s what you can do about it

• here’s what happened after you did the thing

AI will help with a lot of this. But it still needs us to define what good looks like. That can come from our discernment. If we’re talking customer data, it can and should come from the customers themselves. Your best accounts are writing the definition every day – with how they use your product, when they pay, how they engage with support, and so on.

Draw the line

For any of this to work, you have to commit. Draw a line somewhere and say: above this is good, below this is not.

Then the job is doing the day-to-day work of moving more things above the line and understanding what’s holding the rest below it.

We’re all swimming in data. To make sense of yours, define what good looks like, define what not-good looks like, and spend your time closing that gap.

Peter

Went and made coffee. Had some lunch. Walked past the computer a few minutes later.

Done.

The prompt was deliberately thin: “Help us improve the performance of this website.” No goals. No conversions, load times, bounce rates, time-on-page. No scope. I handed it a problem with no edges and pointed it to the tools it has access to like Posthog, Google, Github, etc.

It built its own edges and just ran.

---

That was yesterday. I’ve had Fable for all of a day.

With earlier Opus and Codex models it felt like I could reach the limits. I knew where the tool ended and I had to step in. With Fable, it feels like it’s ready for more, and I’m not sure how to give it more.

That gap re-triggered something I thought I’d processed: the fear that the top 1% of people using AI tools are going to start pulling away from me if I don’t figure this out. The anxiety has been there since circa ChatGPT 3.5. I’d gotten over it. Fable brought it back.

I’m not going to give into that feeling, but I think it’s pointing at something worth naming.

The bottleneck is me

The Every team published their Fable reactions this week, and two lines landed close to where I landed.

Austin Tedesco: “The model is so good that, especially for knowledge work in growth and go to market, I feel like my own limitations are the only thing ever holding it back.”

Katie Parrott: “I haven’t found the right project to hand it yet, but that’s probably a failure of imagination on my part rather than the model’s.”

The bottleneck moved. It’s not the model anymore. It’s me. Ugh.

Missions > projects

My first instinct was to reach for the tool-selection frame: stop treating Claude Code as a hammer, think of the models as tools, match the knife to the screw. That’s useful. But model choice will be abstracted away eventually. OpenRouter-style routing will handle most of it. That’s not the real shift.

What caught me was something that happened inside the website deliverable.

Fable didn’t just return a list of recommendations. It proposed benchmarks, metrics to track, and a timeline for re-assessment. It built its own feedback mechanism into the output.

A project has a defined scope and a finish line. A mission has a direction, a method for measuring progress, and permission to keep iterating. I gave Fable a direction – improve the website – and it filled in everything else, including the loop.

Give it a mission instead of a project. That’s what I think the shift actually is.

Mission-framing doesn’t replace judgment. It requires it.

The performance recommendations were sharp. There’s an animated transition between the blog index and individual posts – a nice UI touch that’s apparently slowing the pages down. That call was right.

The design recommendations felt cold and lacking polish. Not that I’m a designer and have great taste.

But there’s still judgment, discernment, feel that has to be overlaid on top of this stuff. Because of that, there’s a risk in giving any setup full autonomous permissions. The mission still needs a human in the loop. Not to rubber-stamp the answers – to bring the taste.

Squashing the anxiety or FOMO

What I’m actually doing with the anxiety? Aside from living with it? Ha.

Not arm-wrestling Fable to see what it can do. Instead, I’m trying to focus on the business needs.

This reframe is calming me down:

Stop chasing model capability and start looking at the areas of opportunity. As in the problems that matter, the gaps where we’ve been leaving value on the table.

The question I’m bringing to it now is this: what are the projects we’ve dreamed about doing for customers – genuinely useful things – that we’ve never had the time, skills, capacity, or resources to get done? Is Fable capable of doing those now?

That’s a different question than “what can this model do.”

That’s a mission, not a project.

Onward,

Peter

I wasn’t the difficult customer, nor the churned customer. I was the aspirational fit. The one who had every intention of using the tool, but was too small, too early, and too unready for it.

I’d convinced myself that we were ready. A good seller would have told me “not yet” and pointed me in a different direction. But I came in on the last day of the quarter, signed for a discount, and helped someone hit quota.

That’s the story from one side of the desk.

I’ve been on the other side too. And when I read this line from a Winning by Design paper on revenue governance – “customer success is absorbing onboarding load that was never priced in” – I didn’t need to think hard about what it was pointing at. I’ve watched an onboarding that should’ve taken two weeks stretch to six months. I’ve sat in those Monday morning meetings where the same customer comes up before anyone’s had coffee, and you can hear the room collectively exhale before anyone says anything.

The cost nobody itemizes

The obvious stuff is obvious: support hours, churn, CAC payback that never comes. If you’re honest about the fully loaded cost of onboarding and servicing a poor-fit customer over the life of a contract, you’re often losing money. The number gets big fast. Most people stop the math before they get there because getting to that number is uncomfortable.

What gets ignored is the stuff that’s harder to put a dollar sign on.

Morale. This one’s quiet. When your team starts every Monday feeling down about the same customer <sigh>again</sigh> before the week has started… you feel it. It’s one of those indicators that a good product analytics tool will never catch. It’s in the group chat or sideline convos.

Opportunity cost. The more time you spend on one customer who shouldn’t be in the business, the less time you have to find and serve the ones who should. It’s math. Every hour fighting to make a bad fit work out is an hour not spent on a customer where you actually win. It’s a wet blanket on your best revenue motions.

Attention distortion field. This one’s less talked about. You’re not just losing time, you’re losing signal. When your team’s energy and conversation is soaked up by an outlier, it skews what you think the real problems are. You can start solving for the edge case. You can start to think the product needs to go a direction it doesn’t. It’s dangerous.

Why doesn’t this get discussed?

It does get discussed – sort of. The sales-to-CS handoff problem is well-known. The MQL quality fight between marketing and sales is a rite of passage in almost every B2B company. It’s almost fun. Everyone knows the tension exists at the handoff points.

But it doesn’t get discussed very openly. I think there are two real reasons:

The first is structural. The WbD paper makes this point well: without governance to hold the whole system together, you end up with siloed teams each optimizing for their own metrics. Sales closes. CS onboards. Nobody owns the full cost. When a problem is spread across enough people’s lane boundaries, nobody has the full picture, and nobody wants to be the one who calls it out. It becomes institutionalized. Naming it feels like putting your neck out.

The second is that it’s just plain hard to measure. What is the fully loaded cost of a six-month onboarding versus a two-week one? To answer that, you’re deep into activity-based costing models – which are expensive, time-consuming, and even more opportunity cost in their own right. So we skip it. We do the easy math and hope the incomplete version tells us enough.

It often doesn’t.

Your ICP isn’t a fixed artefact

Every company has an ideal customer profile. But that profile changes as you grow.

What looks like a poor-fit customer today may have been exactly the right customer two years ago. Early stage, growth stage, scale stage: these aren’t just different phases of the same business. They often need different customer profiles to feed them.

The transition between stages can be messy. You carry forward the ICP from an earlier era. They live in your pipeline, in your prospecting muscle memory, in the type of buyer your brand still attracts Often even after you’ve grown past that segment.

You end up with poor-fit customers not because anyone made a bad call, but because the company changed and the motion didn’t keep up. That’s not bad acting. That’s just what happens when you’re building. It’s a good problem to have and solve.

Understanding which kind of poor fit you’re dealing with changes what you do about it.

When it’s worth it anyway

Poor-fit customers aren’t always a mistake.

Early on, when you’re still learning what an ideal customer even looks like – when cash matters, when a logo on the website has real strategic value – taking a deal that doesn’t fit perfectly is often a good call. You’re not failing to govern. You’re gathering evidence. Edison’s “ten thousand ways that won’t work” and all that.

The risk is the zero-sum thinking that comes after: if I go too narrow, I’ll run out of market. I’ve felt that pull.

The more useful frame is abundance. If we can get honest about why the poor-fit deals cost what they cost, even just back-of-napkin, the math usually pushes you back toward selectivity pretty fast.

If you’re running a business, you’ve had customers that weren’t a good fit. Things can end mutually and without drama. But sitting with why it wasn’t a fit – even in a 30-minute debrief – is how we avoid repeating it.

The question I’m sitting with

I don’t have a clean framework to work from.

I keep coming back to this: if every team in a recurring revenue business is absorbing a piece of the cost of a poor-fit customer but nobody ever adds it up, the cost stays invisible. And invisible costs don’t change behavior.

You don’t need a full-on governance system to fix this (but it would help). You do need one honest conversation with your team about one customer – the one everyone sighs about on Monday – and an attempt, even rough, to put a real number on what they’ve actually cost you.

Consider what that number looks like at your company. I’ll be here writing it out on this napkin…

Peter

When she moved from founder to advisory, she made herself a promise. To only work with companies she believed could actually deliver value to their customers. Even if that meant a slimmer pipeline for her.

There’s an enthusiasm in how she works. It’s nice to be around.

There’s a risk in getting too wrapped up in that enthusiasm, but honestly, I just appreciate it. Because if you want to take others to a higher level, you have to have that kind of enthusiasm for the work you do with them. You can’t lift anyone you’re not excited to be standing next to.

The narrative I keep having to put down

Building in tech, there’s always a story running in the background: build to go as big as possible. Unicorn status. Generational impact. People saying your name in 100 years.

We’ve all met people building with that intent. They’ve had real success and they want the astronomical version of it. It’s admirable. I love it for them.

It’s not for me. But it’s easy to get swept up in. Build fast, burn fast, rocket ship to Mars, exit with squillions in the bank, plant your flag at the top of the mountain and call that the pinnacle of life.

And then every day I work too much, every week I’m away from my family and the things that actually matter to me, doing what I feel I have to do instead of what I want to do, the top of the mountain doesn’t feel like something worth shooting for.

“Slimmer pipeline” is a story about scarcity

The slim pipeline thinking is finite game thinking. Only so many resources, only so many people, everyone fighting over the same slice.

I don’t buy it.

With most things, if you can find your tribe, you can make a good living doing the work, and have fun doing it. There are far more of those people out there than you’d think. Jordan Peterson said something like this once (agree with him or not, it’s beside the point here): until he started putting his thinking out into the world, he assumed he was basically alone in it. He wasn’t.

So there’s something to sticking to your guns. Putting yourself out there. Letting people know how you think and how you feel. More of them open up, make themselves known, or get pulled in by your enthusiasm and your willingness to lift them up than the scarcity story ever lets you believe.

It’s true for people and for product.

The little thing: help first

We’re building a business and doing founder-led sales. Some days it feels like a grind. The framing that’s saved me is looking for ways to help people first. Yes, there’s constant pressure to be selling, to be closing deals, but those come on the back of being genuinely helpful.

It’s nothing new. It’s Gary Vee’s jab, jab, jab, right hook. At some point you do have to ask for the money. But the thing I come back to every single day, every time I send an email, is one question: is this actually helpful? Is there an insight in here that someone can take, learn from, implement, and benefit from, whether or not they ever buy from me?

Do I get it right every time? Heck no. But the ratio of helpful:selling is getting better.

All the way down

Does this run into what we’re actually building? I think it does. That’s the whole idea. How do we make our users the heroes of their day? The heroes of their team? How do we make them feel like they pulled off something good?

It doesn’t have to be world-changing, just good. How do we give them back more time for the work they actually want to be doing, the work they know they need to be doing so they feel valuable and worthwhile?

I know how sappy that sounds, and that’s probably leaning too far into it. But yes, it goes all the way into the product. Can we lift people up with the tools we build? Can we lift them out of the day-to-day grind of whatever they’re stuck in right now?

One honest thing, and the ask

At Accoil, we’ve held strong opinions, very tightly, and I think that hasn’t always served us well. Sometimes we heard our customers, but we didn’t listen to them. They’d tell us what they needed and we’d say, “nah, you don’t need that.” We had a very firm view of what was useful and what wasn’t. Maybe it was a bit arrogant.

I believe that we all buy tools that have strong opinions. But those strong opinions can be loosely held to flex and form to real customer needs. Anyway…

There’s been a shift lately. Now when we look at the product, the question is different: are we making this useful in a way that helps people do good, meaningful work?

So, before doing the next thing, the email, the feature, the support ticket:

Is this helping? Will this lift someone up today?

TTFN,

Peter

That question just got a lot easier to answer. Point a decent AI model at a pile of signals, and it will spot the pattern and hand you the next best step: reach out to this account, nudge this user, prioritize that one. It’s fast, confident, and a lot of the time it’s actually useful.

But the “so what?” part was the hard part for a reason.

It’s the part where judgment lives, and if we’re not careful, we’re about to hand it to something that doesn’t know what’s actually behind the number.

Think about one of your accounts that’s super active. They’re busy. They’re logging in all the time. You see usage spikes constantly. Feed that into an AI model, and it’ll see it and say, “This one’s hot. Reach out right now.” Reality might be different. Maybe it is, or maybe someone set up an automation last week, and it’s a quiet cron job cranking through tasks and making a dead quiet account look busy. You get the same signal, but a completely different ”now what?”

In this example, it could either be a buying moment or a red herring.

Now add proactive agents to the mix, which is where a lot of tools and a lot of people, including me, are heading. More and more of the data that we see could be misleading. We can’t tell the difference between signals and false signals and noise. There’s a problem.

If the answer is to put AI on top of those before we understand the context and the meaning, we risk exacerbating the problem.

Ask AI a question, and it will give you an answer. Whether or not it’s the right answer is still hard to tell.

It’s getting very easy to collect data, interpret it, build on it, make decisions faster and faster. But the understanding that should go into all of this is getting abstracted away. If you did not build the dashboard, the metric, or the report, and you do not know what is feeding it or what it is really measuring, it is hard to know how to sense-check the recommendation you are handed. AI will give you an answer, and that answer arrives quickly. It can even arrive at scale.

For years, the skills we trained were signal versus noise, wheat from chaff. That still matters, but there’s a newer muscle we need to build. I think it’s one that will separate teams, products, and businesses.

Understanding what a signal is, what it means, what’s behind it, and what it implies for the decision in front of you is not a dashboard skill. It’s a decision-making skill, and AI doesn’t have your context.

I am certainly not anti-AI. Quite the opposite. It’s still important to hold onto some things. Closing the gap between getting a signal and taking action is the whole game, and AI is the best tool we’ve ever had for it. Still, speed toward the wrong action isn’t progress. A shorter signal-to-action loop aimed at a misread signal just gets you to the wrong place a lot faster.

If you’re leaning on AI to tell you what to do next, good. You should be. Don’t forget to understand what’s behind the signal: what’s in it and what’s not. Be very clear about what decision the data is actually supporting. The teams that win won’t be the ones that act on signals the fastest. They’ll be the ones who understand what the signals mean when they decide to act.

AI will give you the next best action if you ask, but whether it’s actually the best one is still on you to decide.

🚀,

Peter

That’s Dan Rosenthal, writing in Kyle Poyar’s Growth Unhinged. In Growth Unhinged’s 2025 State of B2B Go-to-Market report, intent-based outbound ranked as the #2 channel teams are investing more in for 2026.

So everyone’s racing to capture signals. Almost nobody has worked out what to do once they have them.

We see it every week. A team gets set up. The signals start firing with data flying into the CRM, notifications landing in Slack. It’s exciting. The excitement lasts probably about six months. And then it goes quiet.

Kate (one of my co-founders) put it better than I can:

“Everybody says ‘this is great, you’ve given us these signals’… and now what do we do with them?”

Almost every team using Accoil has said this.

This isn’t an Accoil pitch, though. It’s GTM in general. There’s this whiplash that happens after you set up any signals. That’s the fun part, because you get to see things maybe you’ve not seen before AND you get to dream up ways to use it all.

So the real work starts when you have to decide how to use it. What do you do with what you’re seeing? Turns out that’s not as easy to answer as you’d think.

• An ICP-fit company creates an account. Great, and then what?

• A target account raised a Series A six months ago. Now what?

• A power user jumps to a new ICP company. Now what?

There are endless signals out there, some more valuable than others (think 1st-party vs 3rd-party signals). More valuable than any signal is the judgment about what to do with it.

That last 10% Dan’s talking about? That’s the whole game.

We’ve got a customer who completely trusts their signals now. They run trials, and the one they watch is dead simple: did a brand-new account do the core thing in the first seven days? If not, someone reaches out before the trial goes cold. That’s it. One signal, one play.

The data part is done. What’s left is the human part, including the message, the timing, the relationship. The “so what?” And honestly, that’s the fun part: it’s creative, it’s energetic, it’s full of possibilities.

But on any team there’s variation on the “so what? now what?” decisions. Everyone sees the same signal, but comes up with totally different ideas about what comes next.

That’s not a problem unless you let it be one. It’s the point of getting the signals set up in the first place.

What happens after you get a signal? It’s all hypothesis. Build it, test it, run the feedback loop, make it better. Once you trust the signals, you get to refine what comes after them.

If you’re doing product-led growth or product-led sales, pay attention here: you are sitting on some of the most valuable signals that exist, coming straight out of your own product. You don’t need to buy more signals or more sources. You almost certainly don’t have a capture problem. You have a now what problem.

So make it small. Pick one signal → your single highest-intent moment after sign-up. Something a new customer can do in your product that makes them go “Hey, this is great!”

Then decide the one action it should trigger: a message, a call, maybe even a handwritten letter. Decide who owns it and when it fires. Pair one signal with one play, end to end. Run it and see what happens.

As you work out and find successful Signal-to-Action pairings, start stacking more of them. Find another signal, start a new play, run the feedback loop, improve it. Then do the next one.

Most teams have never built even one real solid Signal-to-Action play. I’m convinced it’s because it feels overwhelming. I felt overwhelmed reading Dan’s piece on Kyle’s newsletter.

But we’re all sitting on valuable data and signals. It’s what we do with those signals that will determine the trajectory our companies are on.

Like seemingly everything else right now: Signals are abundant. Judgment is scarce. That’s the part worth getting good at.

Peter

Got tired just writing that.

I see it in customer conversations all the time. A team goes from having almost no automation to wanting to automate everything. They make that leap before understanding what it is they’re automating.

The teams I see handling this well aren’t the ones moving fastest.

They’re the ones taking a careful, measured look at their processes. The workflows they run today and the ones they want to run tomorrow. They work through them methodically. Especially anything that touches a customer.

Automate the signal, not the action

A signal can be almost anything. An account quietly disengaging. Someone poking around your website. Support volume creeping up. Sales signals like hiring, firing, fundraising.

Automating the detection of those? Great. Those signals stay internal. Your customer never sees them unless you act on them.

And that’s where it gets dangerous. Because until you actually understand what a signal means, automating whatever comes after it is a great way to kill a relationship before it even starts.

Two examples of how this goes wrong

1. Sales signals misread as a reason to reach out.

Someone trips a signal, so you fire off an email — except you got the context wrong, and now they’re offended because you misunderstood their situation. To make it worse, everyone else pulled the same signal off the same data. So unless you’ve got something unique to add, you’re not cutting through the noise anyway.

I’ve done this.

2. Jumping to automate your best accounts.

Your tier-one, high-touch, strategic customers. You wire up workflows off sentiment analysis, ticket volume, engagement data — and because you don’t have the full picture, you may speak out of turn. You can miss an important clue or misread the room.

Different flavors, same outcome: an unhappy customer.

The problem is that there’s no air between the signal and the action. No room for error. Until you’ve tested and worked out the signal-to-action bridge and learned what the right action is for each signal, doing it at scale is reckless.

So where do the humans go?

Two ways to figure it out:

1. Start with the human.

Decide upfront where you want genuine human-to-human connection, and work back from there. What can you automate around it?

2. Start with the machine.

Map the whole process as if it were fully automated, then decide where to drop a human back in.

For high-value, strategic work, I like starting with the human. Where do I want the points of contact? The human in the loop? Then build the automation around that.

Us humans bring something that the models structurally can’t: context.

AI is getting scary good at pulling data from everywhere. But you can never be 100% sure it knows everything about a customer. A human picks up the externalities like the emotions, the offhand comments, the subtle cues none of the tooling sees.

We bring the personal touch. The quirks and the personality. All of which gets flattened and abstracted away if you tool up too fast.

I’m banging on about this because I watch it happen on repeat.

We demo Accoil and the conversation goes: “we can automate this, and that, and the next thing.” Straight from zero automation to dreaming up every workflow imaginable, then deflated when it doesn’t all happen with a snap of the fingers.

So if you take one thing from this, take the exercise:

1. Pick one high-value workflow — sales, onboarding, or retention.

2. Segment your customers down until you actually know who you’re talking to, and pull out your 20 most valuable — by revenue, lifetime value, strategic weight, whatever fits.

3. Then decide, deliberately: where do the human touchpoints go, and what should they be?

After that, automate the signals. Automate the tools around the human so they can do their best work.

And automate the bits in between the touchpoints, so there’s a steady, relevant cadence without your people having to do every little thing by hand.

Automate the signal. Let the humans take action.

Peter

I talk about signal fidelity every day for work. It’s the whole reason our product exists. Brendan Short named his newsletter “The Signal,” and his latest piece with Mercy Bell (ex-Webflow enablement leader) circles the same idea from the people side. It’s the same conversation: the fidelity of the signal.

The more layers of abstraction between you and a signal, the lower its fidelity. A dashboard isn’t raw truth. It’s data that’s been shaped through whatever lens the person or tool that built it happened to have. Maybe that’s your lens. Often it isn’t. And raw data, on the other end, is just noise.

What’s the antidote?

You have to know what you are looking for before you start. This is Decision Deck Thinking. Define the decision you’re going to make — don’t make it yet, just name it — and work backwards from there.

You’re not looking for data that confirms what you already believe. You’re looking for data that will help you make the call. High fidelity means getting as close to the original data as possible while still knowing what you’re trying to learn from it.

A rev ops leader at a scaling media tech company told me something that’s stuck with me: he killed his team’s big BI dashboards. They had “beautiful Looker boards”, color-coded, and the data team loved them. They got rid of them because the team said things like “they’re too much” and “I don’t go in there.”

He was adamant that he didn’t want to go to the other extreme and just hand his team answers either.

In a scaled company, you shouldn’t tell people what to do rather than have them thinking. Have them thinking, analyzing, making their own decisions. Just telling everyone ‘this is good data or bad data.’ That puts you in a blind spot.

So raw data is too noisy. Spoon-fed verdicts kill judgment. I think what we actually want is a contextualized signal that gets people thinking. A signal that us humans can interrogate, dig into, and not just receive on faith.

In Mercy’s article on Brendan’s newsletter, she talks about how we put more extraordinary care into the environments we build for AI agents than we do for humans. We architect entire worlds for our agents, and we give the humans a stale dashboard and a pat on the back saying, “you’ll figure it out.”

The same RevOps leader I mentioned above said something else I think about a lot: “People lie.” He means a customer will tell you they’re happy and then not renew because what they do is truer than what they say. That’s fidelity in one. Their behavior is the high-fidelity signal. The sentiment is the lo-fi one.

Here’s a model that I keep landing on when thinking about how to handle this hi-fi / lo-fi situation: black box versus glass box

A black box hands you an answer. You can’t see the filtering, you can’t see the setup, you can’t dig behind it. You either trust it or you don’t. And trusting something you can’t inspect or interrogate is more like blind faith.

A glass box gives you the same abstracted signal, but it lets you move up and down the chain. You can see the raw data, work your way back up, and decide for yourself whether you believe the signal. A glass box lets you get in the reps to understand the signal and develop trust in that signal. A glass box helps the signal earn your trust.

This matters more, not less, in the AI era because AI will hand you a smooth, confident, beautifully worded answer, and it might be completely lo-fi. Another way of saying it’s complete BS.

And it’s easy to overlook that when it’s busy telling you how awesome your ideas are.

A confident answer you can’t interrogate is a black box with nice manners and a penchant for flattery.

There’s a paradox at the heart of this, especially if you build software for a living: customers want a strong point of view, and they want to trust that point of view.

We hear it often: people want Accoil to have an opinion, but it’s also not enough to say, “Here’s the answer” and be done. We have to show our work. We have to let people reach down into the data.

The harder you make it to dig behind your signal, the less people trust it. Black Box vs Glass Box.

How do you work with this?

When you work with data, you need to spend time close to it. Dig into the signals and understand why they say what they say. Don’t take the first dashboard you see as gospel.

If you’re building tools for other people, give them a glass box. The more you let people see through, the more they trust what they’re looking at.

Work speeds up when there’s trust in the signal.

I have this burning desire for A.I. to do more and more and more, but I need to be able to trust it. And at the same time, I want to keep working with people, doing the best work we can together, not quietly being misled by a smooth-talking LLM.

Great work is done by people. We need to enable each other with the highest fidelity signal we can.

Ciao for now,

Peter

This simple idea may seem too obvious to be useful, but there is an old two-part rule that often works well in business, science, and elsewhere:

1. Take a simple, basic idea and

2. Take it very seriously.

When you step back and think about what we’re all building here, it’s a bunch of simple ideas we’ve taken seriously enough to invest time, effort, and resources into building.

The graveyard of obvious ideas

But there’s a graveyard of obvious ideas lurking just around the corner from all of our businesses.

Every founder I talk to already knows the things that would move their business faster and in the right direction. Talk to more customers.

• Follow up faster.

• Charge for the value you deliver.

• Watch how people actually use the product.

None of it’s a secret. For all of us, there are things we don’t do, not because we think we shouldn’t, but because they feel obvious, and obvious things don’t feel like progress. Simple ideas get a nod, then they quietly die in the graveyard.

I’ll out myself: the simplest idea I’ve been given for our business is to block off time for sales every single morning and not let anything get in the way. Some days I do it, some days I don’t.

It’s a simple idea I haven’t taken seriously enough.

What’s funny is, I believe it. I know it will work, and yet some days I look at the clock and it’s noon and I haven’t done that sales block yet.

The one we built a company on

The idea Accoil is built on is almost embarrassingly simple, but here it is: if customers use your product, they stay; if they don’t, they leave.

Almost everybody we speak with agrees. They’re willing to accept the simple idea. But not many are willing to take it very seriously, to instrument it, to score accounts, to understand what good customer behavior really looks like.

When you take simple ideas very seriously, you realize that “[s]implicity is the end result of long, hard work, not the starting point,” as Frederic Maitland supposedly said.

Frederic is considered the modern father of English legal history, so yeah. Smart guy, not otherwise relevant to this discussion.

What I believe Frederic is saying is that, to see the value in a simple idea or to harvest its value, you have to take it more seriously than it feels like you should.

The dumb-idea test

It’s easy to get overwhelmed by all of the growth tactics and tools and AI news of the day. Carving out just a little bit of time to think about simple ideas that’ll move the needle for your business is valuable.

So here’s something I’m trying:

Write down the simplest, most obvious idea in your business, one that feels almost dumb to say in a meeting.

Then ask: Am I taking this seriously, or am I just nodding at it on my way to the clever stuff?

Munger’s point is that his edge was never in being clever. It was in taking the obvious thing more seriously than the next person.

What’s a simple idea you keep nodding at but have not run with, and are not taking seriously enough? Let me know.

TTFN

Peter

Most of what we do in the tech world and in AI is critiquing what someone else has already done, the status quo, or just the way things are.

I’ve been a fan of 37signals for a long time, a customer sometimes, but a fan for a long time.

They recently relaunched Basecamp.com. It’s basically a critique of their competition without naming the competition. Part of the launch is a letter from Jason Fried calling out what he and his team see as problems in the space.

What I like about their approach is that they often write to critique how things are done, to draw attention to things they don’t believe in, and to highlight things they do believe in. But rarely is it just a critique.

They build what they believe should be built, and what they build is often a direct critique of what already exists in other tools.

You can write a takedown. You can tell everyone why X thing is broken. You can dunk on the competition. That’s critique by commentary. It’s cheap to produce. It’s easy to ignore. It leaves the broken thing still standing there.

And what we often do in this business is that we build the thing that should exist instead. This is critique by construction.

When we build something that is distinct and different, it can make the alternatives look stale and old. Getting current customers or prospective customers to even just compare what you’re building to the way things have always been done is an argument made quietly.

I love this about technology. About building a business. We get to look at things that we don’t really like and dream up and build ways of doing it better.

The Godard move

In 1962, Jean-Luc Godard quit writing film reviews and became a director. The line he gave to Cahiers du Cinéma: “Instead of writing criticism, I make a film.”

His films became the argument against the studio filmmaking he’d been critiquing in writing.

A bit closer to home for most of us: Marc Benioff didn’t sit at Oracle writing op-eds about how on-prem CRM was clunky and dying. He built a browser-based alternative and ran the famous “No software” campaign. Salesforce was the critique.

What I’ve always liked about 37signals is how they approach underdoing the competition. They don’t win by out-features or by attacking. They win by doing less, by doing it better, and by shipping their own opinionated alternative to what already exists.

Basecamp.com, the new version, feels 20 years old, and it was definitely on purpose. It’s criticism with no commentary required. But of course it’s Jason Fried and DHH, so there was commentary.

The punch-up trap

When you’re a small team, it’s almost expected that you’ll punch up at incumbents. That’s the scrappy startup energy: you win the room by naming what’s broken with the big guys.

It can get attention, but I’m not sure it actually serves anyone. Scrapping and clawing your way into a market by pointing at someone else’s product is exhausting and inevitably forgettable.

The other path is to take a distinct point of view, hold it loudly, and be proud of it. Let the right people find you. The more our customers say they like that we have one, the more I notice they are not just receiving it, but actually shopping for it.

As Seth Godin called it, “the tribe”: people like us do things like this. You can add to that and say people like us don’t do things like that. We do things like this. You can stand for something and against something.

A spin on scratching your own itch

A lot of software starts with someone scratching their own itch. Flip that framing a bit, and you get: you critique what exists today, then build the antithesis: the thing, the workflow, the ethos that runs counter to what you can’t stand.

It’s a little spin on “be the change you seek.” Be the product you seek.

Build, then explain

Building isn’t free. Commentary, though, is cheap, fast, and easy. And because we’re in business, we actually have to tell people about what we’re building, so it’s not enough to just criticize by creating.

We have to be clear about what we’re building and why we’re building it. We have to tell people about it.

This is the brand voice section: the public-facing one. You still have to talk the talk, but you also have to walk it out. Be distinct and different. Hand people the point of view by demonstrating it.

Attract more people to you and the thing that you’ve built. Keep making the argument every time someone sees it and uses it.

In sum, it’s amazing that we can build in response to things that we don’t like or to situations that we want to improve. When we do that, we have a great story to tell, and we need to make sure that we tell it.

Build it, then explain it.

So what are you building in critique of? Let me know. I’d love to hear your point of view on it.

Peter

A few webhooks, an API or two, and some MCPs to get data flowing between all the different tools we run. Maybe Obsidian, something like Karpathy’s Wiki, or a chief-of-staff framework like Dex. Honestly, any of them felt like they’d make more sense as a CRM than an actual CRM.

And then I actually said it out loud to myself, “This is not my main game.”

I’m glad I didn’t get too far. It was just a thought experiment I outlined on paper, but it was far enough to feel the pull. I really wanted to do this, and I took it far enough to see the cliff.

The moment you scratch the surface of a CRM, you realize how much actually goes into building one that does the things you want it to do in the first place.

You might have felt the same pull to build things rather than buy things. I think there are a few signs right now that the market is about to shift how we feel about this question.

We took the free sample

Vibe coding and all the hype around it made “we can just build this ourselves” feel true. I certainly felt it. When you can stand up something that works in 39 minutes, of course you think you can and should own this thing.

But of course, the price of building this right now, given AI tooling, isn’t a real price.

It’s easy to stay comfortably inside our CloudMax subscriptions right now. It’s $200 a month for a lot more than $200 in value, so it’s a great deal. It’s also subsidizing this build vs. buy conversation. All the big labs are selling compute below cost, which is great for getting us all using it and experimenting and playing.

But for a lot of businesses, there’s a huge risk involved. Ours included.

When an AI workflow or an AI-enabled workflow becomes load-bearing and runs whether or not someone is watching, it can become a liability later on.

The moment, for example, Anthropic decides to bump the rate cards from subscription to metered API, the math doesn’t just shift a little bit. It explodes.

This has implications for our build vs. buy decision-making. We need to be more mindful of our spend. What fits within a Claude Max subscription today could become a gigantic bill tomorrow. That includes AI-assisted workflows, but also all of these tools that we’re building instead of buying. We own those costs.

I haven’t seen it bite our customers yet, but it’s starting to come up in conversations, and the warning signs are adding up.

The State of Brand has written several articles about this price hike and its implications. If we’re not ready for it, it can be a scary, scary thing.

Building isn’t the cost. Maintenance is.

Even if the tokens stay cheap forever, there’s the thing that most of us don’t price in very well, and that’s people.

Every hour I spend building, tweaking, fixing, and maintaining an internal CRM is an hour I’m not selling our product. Unless this home-baked tool makes me 10x more effective in the hours I do sell, it doesn’t pay for itself.

I think about it like I think about our little family farm.

We have enough room to grow vegetables, run a few cows and some sheep. Every hour I spend in the garden is an hour taken away from the business and from my family. One of those things has to suffer. It’s not a discipline problem; it’s just how time works.

Some companies have the margin and the people to build their own tools. Ramp seems to be doing this a lot, but most companies can’t. The ones that do pull it off often take dedicated teams and months of effort to get there. To me, it’s like having a business within a business whose only customer is the main business. If that tracks.

The razor

Despite my shiny object syndrome and my strong urge to tinker with everything, I’ve had to keep asking myself one stupid simple question:

Is this my main game?

Be honest about the resourcing, not just to build it but to run it, to maintain it. Keep it alive. Keep it valuable.

What business are you actually in? If building this thing lets you do that business dramatically better, build it. If it would cost you dedicated staff time and money to get there when a tool already gets you 80 to 90% today, buy it and get back to work.

Most tools are about 80% of what you want them to be, especially given that every person and team across an org wants slightly different things. I have to remind myself that the same is true for the tools I build — unless I spend all of my time making it perfect, it’ll always be 80 to 90% of the way there.

Over the last year, dozens of prospects told us they’d build it themselves. A handful of them came back six to nine months later and said it was harder than they expected.

The rest? Some gave up, and some just did nothing about the problem.

And that seems to be the real shape of build vs. buy: not some triumphant in-house platform. Mostly silence.

Keep building and playing, though

Given how fast all of this is moving, we need to tinker and hack things together. We should be poking at these tools to see what they can do, not just for ourselves, but for our products and for our customers.

Remember, though, that every hour spent spinning up a tool that you probably won’t keep is an hour that you could have been working on the main game. For most of us, the main game is:

• growth

• keeping customers happy

• winning new ones

• selling

All that said, if you’ve been building anything with AI that you couldn’t have built before, I’d love to see what you’re doing. After all, it’s still fun to mess around and see what we can do.

Happy building, people.

Peter