Stop arguing in the abstract

Most people are using AI to get more done. More code, more output, more stuff. I do it too. But on a lot of teams, what's actually holding up the roadmap is a decision nobody can close.

Here's one I went through. A mobile app needed a design update. It was bad enough that Sales didn't want to sell it and Product didn't want to talk to customers about it. The information hierarchy was confusing, so both teams kept explaining parts of the app that should have explained themselves. Nobody liked where it was, but there were more opinions on direction than there were people in the room. The conversations kept cycling, and nothing moved.

First I asked Claude to build a mockup of one slice of the app running as a two-minute loop in HTML. Beside it, I hooked each stakeholder's wants and dislikes into a toggle. At the same time, I had an agent write a short feasibility report on each toggle, covering what would have to be added or removed and the risk. Some were trivial. Supporting everything would have meant a few refactors, like adopting new rendering libraries.

Then I sent the page to each stakeholder with one instruction: toggle these to your heart's content, and send me your best one. A one-click export sent me each person's settings.

Once I ran everyone's picks through the LLM, it turned out people were a lot more aligned than they'd seemed, and almost all of them had landed on the cheapest options. There were still a few conversations to have and a few compromises to ask for, but we had agreement in hours. A new version was ready a few hours after that, and it went out that night.

Think about what that kind of stall costs. While a debate like that cycles, Sales is holding back on the product, the team keeps explaining screens that should explain themselves, and the decision keeps landing back on the founder. And the easy way out, building everything on the list so nobody loses, would have meant signing up for those refactors when almost everyone had picked the cheapest options.

That's where I think most teams are holding AI wrong. The value isn't in the extra output. It's in the meetings you don't have to have and the agreements you reach faster. If you already know what to do, ship it. If you don't, use AI to figure it out: the mockup, the feasibility reports, everyone's picks in one place. That's the part it really speeds up.

The full story is in my post You're holding AI wrong.

Accounting and finance aren't the fun part of building a company, so they tend to get left in the background. Then it's time to raise, and that's exactly the part the people with the money want to talk about.

That was the thread through my conversation this week with Brandon Valentine, founder of the Valentine Advisory Group. His point was simple. People keep going and going and want to raise capital, but you can't raise capital if you can't speak to your unit economics: the costs and revenues driving your product. Whether the money comes from a bank, a grant or an equity partner, the people providing it want to understand how the company makes money and how they get their capital back.

Brandon described the bad version plainly. You show up and say, "hey, I want money because my idea is very good," and ask people to believe in you because of your years of experience. His verdict: "That doesn't work in conversations and situations like that." The version that works sounds like this: we need this much, it's going to be spent on these few things, and here are the numbers that support it.

And if you skip that foundation and try to go back and do it backwards later, Brandon's warning is that it puts everybody behind the eight ball on closing deals and getting capital.

The point I added in our conversation is that bad unit economics don't get fixed by scale. If you're losing money on one widget, you lose money on a hundred widgets and more on a thousand. You lose more the more you scale, and a founder who can't see that is spending runway to dig the hole deeper.

The basics Brandon starts with aren't glamorous. Know what it costs to produce one unit of your product or service. Know what the market will pay. Know what your customer gets back, in time or money saved. He gave a good example of what a concrete number looks like: cutting the time it takes to collect payments from a hundred days to fifty frees up cash you can put into other projects or into hiring.

If you're planning a raise in the next year, try this now. Write the paragraph you'd say about use of funds, then check whether every line has a real number from your own statements and models behind it. If one doesn't, that's the work, and it's a lot cheaper to do it before an investor asks.

Listen to my full conversation with Brandon on Build & Break Through.

Two big companies made opposite calls about AI agents in the last couple of weeks, and if you run a B2B SaaS company, both are about you.

At Dreamforce, September 15 through 17, Salesforce pushed AIforce and its Headless 360 architecture, which open Salesforce data, workflows and permissions to outside interfaces like Claude, Slack and Gemini Enterprise. Salesforce co-founder and CTO Parker Harris put it bluntly: "Why should I ever log into Salesforce? Maybe you never will." (Reported by UC Today and Salesforce Ben on September 16.)

Then Amazon went the other way. By Sunday night, September 20, it was blocking Meta's Muse agent from shopping on Amazon.com, citing its Conditions of Use. Amazon says Meta never told it Muse would access the store, that the agent doesn't identify itself, and that it appears to capture and store customer credentials. Meta has said Muse has no visibility into passwords or payment methods. (GeekWire, September 21.)

Here's why that matters for a company a lot smaller than either one. Your customers are going to try to do their work in your product through an agent, whether you planned for it or not. Amazon can afford to block agents because it owns the store and the demand. Most B2B SaaS companies aren't in that position. If a customer's agent can't get in, the customer may just move the job somewhere it can.

Look at what Parker Harris is admitting, too. If people may never log in, the screen isn't where the value lives. I'd argue the building itself is now very heavily commoditized. What's left is understanding your customer better than everybody else and building something adapted to them. If your product's value is mostly "we have a nice interface for this," that's exactly the part an agent routes around.

This quarter, start with the jobs customers hire your product for, and ask whether an agent could do those jobs without your UI. Then ask what a customer's agent would actually hit if it showed up tomorrow: an API, a login wall or nothing at all. And look hard at pricing. If it assumes a human logs in, what happens at renewal when fewer humans do?

You don't need a grand agent strategy. You do need to make the call on purpose, instead of finding out at renewal time which call got made for you.

When a customer leaves, you usually get some kind of story. They went to a competitor. The budget got cut. The champion left. There's a newer one that doesn't make it into the loss report at all: the customer who got fed up and built their own.

Friction has always cost you customers. Add a certain amount of it and some group of people just drops off. Classically, they went to a competitor. What's changed is the slope got steeper. People drop off faster now, because they can vibe code a replacement for the part of your product they actually use.

My own bar as a customer is pretty simple. If your application is easier to use than me talking with Opus for 30 minutes, I'm going to use your application. I don't want to talk to Opus for 30 minutes. I just want to solve my problem. Flip that around and you've got the test your product has to pass now.

So where does the friction come from? Usually from stuff inside the product that's there for your business and not for your customers. Or for your sales team and not for your customers. Or for your engineers and not for your customers. Each one makes sense to somebody in the building. The customer just sees another thing standing between them and the job they're paying you for.

And more features won't paper over it. At the end of the day, customers don't really care about new features. They care about their problems being solved. I've been on the customer side of this myself lately. There's a tool I pay for one thing above all, they keep adding all this other stuff, and I've been thinking about canceling for months.

Here's a friction audit you can run this week. Walk through the three or four workflows your best customers use most. For every step, ask who it's for. If the answer is anybody other than the customer, flag it. Then ask the uncomfortable question: is doing this job in your product easier than 30 minutes of talking to Opus? If the honest answer is no, the flagged steps are where your renewal risk lives.

That's the part to take seriously. A loss to a competitor shows up in your pipeline data, and you can fight it. A customer who quietly builds their own just doesn't renew, and the real reason never reaches you.

Here's something I've seen repeated with AI. A company rolls out the tools, everybody gets individually faster, and the work that actually moves revenue still doesn't ship. It's so easy for people to be tactically fast as individuals and then have the organization swallow all of those gains.

Part of the reason is the kind of work AI is actually eating. When I prioritize work, I sort it into four buckets: mechanical, normal, risky and uncertain. AI is fantastic at mechanical work. It eats all of that. What's left is the really technical, complex stuff, and at the far end is uncertain work, where AI is garbage. Humans are pretty good at uncertain work. And if something is uncertain, you need to go do your homework and make it not uncertain before you start building it.

Now look at where your biggest revenue bets tend to sit. Think of the pricing change nobody has tested, or the enterprise requirement nobody has fully scoped. That's rarely mechanical work. It's usually out at the uncertain end. So you can double your AI spend, clear the mechanical backlog in record time, and have the work that decides your next round sit exactly where it was.

That's how a team looks busier than ever while the roadmap that matters doesn't move. Burn goes up, the easy work gets done, and the founder is still waiting on the same decisions.

Before the next tool purchase, take your roadmap and sort it. Put each item in one of the four buckets. Hand the mechanical pile to AI and stop spending your senior people on it. For the uncertain items, don't start building. Assign the homework first: the customer conversations, the prototype, the numbers. The goal is to turn uncertain work into something your team can actually estimate and ship.

If most of what matters is sitting in the uncertain bucket, more AI spend isn't going to move it. Put your people on that homework before you put more money into tools.

Remember that perfect is the enemy of good - just keep making progress. See you next week.

- Hunter