The call does not arrive on your schedule

Most founders imagine selling the company as a decision they will make someday, once everything is polished and the timing feels right.

That is a comforting fantasy.

The real call can arrive in the middle of a messy quarter. A larger company noticed the product. A competitor wants the customers. Someone sees strategic value you did not know was visible. The opening sentence is exciting: "We're interested in buying you." The next conversation is considerably less romantic.

Can you send three years of financials? Customer contracts? The cap table? Churn by cohort? Vendor agreements? Security policies? Proof that every employee and contractor assigned their intellectual property to the company?

At that point, "I am pretty sure we have it somewhere" is a terrible answer.

Cooley's guidance for companies preparing for an M&A exit makes the timing problem plain: once a buyer is interested, transactions can move quickly. The records need to be ready before the request arrives.

Time is the killer of deals

Every extra week creates another opportunity for something to change. Revenue slips. A large customer churns. The buyer's priorities move. A different acquisition appears. Someone on the buyer's side gets nervous. The people involved get tired of talking about the deal and start wondering whether they should be doing it at all.

The problem with missing records is not merely that they look sloppy. They consume time, and time gives uncertainty room to grow.

McKinsey's analysis of delayed acquisitions focuses on much larger deals, but the damage it identifies is familiar at any size: delays erode value, distract the people running the business, weaken momentum, and exhaust everyone involved.

A buyer may accept a known problem. A buyer can price a known risk. What buyers hate is discovering that every answer produces two more questions.

A buyer is not buying your explanation

Founders get very good at explaining why things are the way they are. The books are a little unusual because of that annual contract. The contractor definitely agreed that the company owns the code. The cap table is accurate once you understand which spreadsheet to ignore. The security process exists, although nobody has written it down.

None of this sounds reassuring during diligence.

A buyer is trying to determine what it owns, what it owes, what could break, and whether the story told during the courtship survives contact with the records. Deloitte says a prepared seller can answer diligence questions faster, strengthen credibility, and reduce disruption to the operating business.

That credibility is part of the value. Clean records tell the buyer that the rest of the company may also be what you said it was.

You cannot recreate clean history under pressure

You can create a policy next week. You cannot honestly create evidence that the company followed it for the last three years.

The same is true everywhere else. You cannot go back and get an intellectual-property assignment from a contractor who has disappeared. You cannot reconstruct every approval from Slack archaeology. You cannot make an unsigned customer agreement become signed by putting it in a very organized folder.

Orrick recommends setting up the data room early so sellers can identify and fix problems before buyer diligence begins. Its broader technology M&A guidance warns that uncertainty about intellectual-property ownership can delay or derail a transaction or reduce its value.

This is why you protect the exit from the beginning, even when you have no current plan to sell. Get signatures. Keep board and equity records current. Store contracts where somebody other than the founder can find them. Know who owns the code. Do the boring work while it is still boring.

Founder math will not survive diligence

An annual SaaS payment feels like revenue because the cash is sitting right there. Accounting does not care how emotionally available the money seems.

Under ASC 606, companies identify the contract and performance obligations, determine and allocate the price, then recognize revenue as those obligations are satisfied. FASB's revenue recognition overview explains the standard and its history.

Contract details matter. Deferred revenue matters. Consistent reporting matters. Do not wait for a buyer's quality-of-earnings team to discover that the revenue schedule depends on a spreadsheet named final-revenue-v7-USE-THIS-ONE.xlsx.

Clean books let the buyer understand the company faster. They also reduce the chance that an avoidable surprise becomes a price reduction, another condition, or a reason to walk.

SOC 2 is useful rehearsal

AICPA describes SOC 2 as an examination of controls relevant to security, availability, processing integrity, confidentiality, or privacy. In normal founder language, an outside party is going to ask the same rude question over and over: can you prove it?

Your first audit may still feel like a slow death. Good operating habits determine whether it is merely painful or a full-scale apocalypse. More importantly, those habits teach the company to preserve evidence before acquisition diligence puts far more than a certification at stake.

A SOC 2 report is not acquisition readiness by itself. It will not clean the cap table, find missing contracts, fix the books, or establish ownership of the software. It does help build the reflex a seller needs: do the work, record the event, and keep the proof.

Build the exit path while you build the company

You do not need to run a five-person SaaS company like General Electric. You do need a reliable home for the records that explain what the company owns, owes, earned, promised, protected, and approved.

Keep the system simple. Update financials and revenue schedules every month. Store signed customer, vendor, employee, and contractor agreements. Maintain the cap table and corporate approvals. Record material security events and access changes. Keep policies honest enough that the team can follow them.

This does not mean exposing sensitive material in a permanently open data room. It means keeping the underlying records organized and involving qualified legal, accounting, tax, and security advisors when an actual transaction becomes possible.

You may never sell. Fine. The same habits make the company easier to operate, finance, audit, and survive. But if that call does come, you will not be trying to build three years of credibility in three weeks.

Founders see proof of work

Every feature has a dramatic backstory inside the company. Someone argued for it, designed it, built it, broke it, fixed it, documented it, and dragged it across the finish line. By launch day, we are emotionally invested. Look at this beautiful thing. Do you have any idea what it took to make the permissions work?

The customer does not care. They see another screen, another login, another implementation, and another vendor asking for money.

That is why a technically impressive product can be strangely difficult to sell. The founder is proudly presenting an accomplishment. The buyer is quietly calculating whether the problem is painful enough to sit through another onboarding call.

The customer started somewhere else

The customer did not wake up hoping to buy a dashboard. Something happened. A handoff failed. A report took three days. An important request disappeared into a shared inbox. An audit exposed a mess. A customer became angry. A manager got tired of asking the same question every Friday and receiving seven slightly different spreadsheets.

The Christensen Institute's Jobs to Be Done theory describes products as things people pull into their lives to make progress in a particular circumstance. That circumstance explains the purchase better than the product category or a list of attributes.

For SaaS, the ugly workflow and its consequence come first. The software is merely how the mess stops happening.

Make every feature survive "so what?"

Automated routing is a feature. Less manual triage is a benefit. Fewer missed escalations and a shorter response time are outcomes.

Those distinctions sound obvious until you read most SaaS homepages. "Advanced analytics," "seamless integrations," and "AI-powered automation" describe the product while leaving the buyer to do the hard part: figuring out why any of it matters.

A good explanation completes the chain: this capability changes this part of the workflow, which improves this result, which matters because the current problem costs the customer time, money, trust, or control.

Vague benefits are features wearing nicer clothes

"Save time" and "streamline operations" are features wearing a blazer. Almost every software company can say them, and neither tells the buyer what will actually change.

Ask how the customer measures the problem now. Minutes to first response. Hours spent reconciling reports. Incidents missed. Deals delayed. Days required to onboard an employee. It does not always need to become a perfect ROI calculation, but it should be concrete enough that the buyer can recognize improvement.

Strategyzer recommends focusing on customer jobs that are important, tangible, unsatisfied, and economically attractive. That is a better road map filter than the number of times a feature was requested.

The outcome also changes the product

Outcome language is not marketing cologne sprayed on the product after development. If the desired result is fewer missed escalations, the product needs reliable routing, clear ownership, useful alerts, auditability, and reporting that proves the improvement. A beautiful dashboard that does not change the handoff is decoration.

Clayton Christensen and his coauthors argued in Harvard Business Review that companies struggle when they collect data about customers without understanding why those customers make a choice. The same mistake happens when a product team measures feature use without asking whether the customer's situation improved.

The problem should shape the message, the road map, onboarding, support, and the proof you show at renewal. If it only appears in the headline, you are not selling an outcome. You are decorating a feature list.

Building first feels productive

Founders who can build software have a dangerous place to hide. Code gives us visible progress. We can finish a screen, close a ticket, fix a bug, and point to something that did not exist yesterday.

Market research is less satisfying. It produces notes, contradictions, uncomfortable questions, and reasons to change an idea we already like.

I understand the urge to start building. Velaro and StatusCast each took me close to a year to write by hand before they reached the market. When the first version carries that much time and risk, trial by fire is an excruciating research method. The fact that AI can shorten the build now makes uninformed development less defensible, not more.

You can know more than founders pretend

You can read hundreds of competitor reviews and sort complaints by customer type, workflow, and severity. You can compare pricing, packaging, positioning, integrations, documentation, and release histories. Search results reveal the words buyers use. Community discussions reveal the workarounds they tolerate and the places where they ask for help.

Harvard Business School's startup market research guidance separates this into secondary research, using existing market and competitor information, and primary research gathered directly through interviews, surveys, and other customer contact. Both are available before a founder writes much code.

None of that proves the product will work. It does give you a better starting position than a blank page and personal enthusiasm.

Research should force you to take a position

A useful research phase ends with choices. Who is the first customer? Which problem is painful enough to deserve a budget? What do they call it? Which alternative are they replacing? Why would they trust you? What price fits the value and the buying process? Where can you reach them without lighting money on fire?

If the answer is still "everyone who needs better software," you have collected information without making a decision.

Your initial position will be wrong in places. That is expected. It should still be specific enough that a launch can challenge it.

Do not ask customers to approve your idea

Founders ruin customer interviews by turning them into polite sales calls. "Would you use this?" and "Do you like this idea?" invite encouragement, not evidence.

Strategyzer warns against mistaking customer opinions for facts. Ask about the last time the problem happened. What did the customer do? What did it cost? Who noticed? Which workaround did they use? Why have they not replaced it already?

Past behavior is imperfect evidence. It is still more useful than a compliment about a hypothetical product.

You still have to launch

Research can become another hiding place. You cannot interview your way to retention, and no competitive spreadsheet can predict every objection or edge case.

The point is to arrive at development with a set of informed assumptions. Build the smallest credible test of the riskiest one. Watch what customers do. Ask for a commitment that costs them something. Change the position while the cost of changing it is still low.

Harvard's product-market fit guidance makes the same distinction: market research begins the process, but the hypotheses have to keep changing as the product meets real customers.

The celebration happens too early

Someone in finance, marketing, support, or operations gets tired of waiting for an internal tool. They open an AI builder, describe the problem, connect a spreadsheet or database, and have something useful by the end of the day.

The demo works. A few coworkers ask for access. The person who built it gets congratulated for moving quickly. There is probably a Slack thread containing several fire emojis.

Then everyone moves on without asking the boring questions. Who controls the permissions? What data is being stored? Which systems does it depend on? Who answers the support messages? What happens when the person who built it changes jobs, forgets the password, or simply stops enjoying their new unpaid career in software support?

The application may have been created casually. The responsibility becomes real the moment another employee depends on it. Adoption is the line between a clever experiment and a company problem.

This is already happening at scale

Microsoft and LinkedIn's 2024 Work Trend Index, based on 31,000 people across 31 countries, found that 75 percent of knowledge workers used AI at work. Among those users, 78 percent brought their own AI tools rather than waiting for their employer.

That same instinct now applies to software. People do not need to open a procurement request or wait for an engineering sprint. They can make the thing themselves, which is both genuinely useful and how every good horror movie begins.

Microsoft's own Power Platform governance guidance warns that growing adoption produces ownerless and unused apps. When a maker leaves, the apps and workflows they created can become ownerless. Widely used apps that skip proper lifecycle management create business continuity risk.

Every shortcut creates a list of obligations

The tool needs credentials. Those credentials need to be stored and rotated. The data needs rules about who can read, change, export, and delete it. Every integration can change without warning. Every dependency can introduce a vulnerability. Someone has to test updates, investigate failures, and decide when the application should be retired. "It is just an internal tool" does not perform any of those jobs.

NIST's Secure Software Development Framework makes the point plainly: security practices belong throughout the software lifecycle. They include preparing the organization, protecting software and its components, producing secure releases, and responding to vulnerabilities after release.

AI can help perform those jobs. It cannot accept accountability for them.

The creator is not automatically the owner

The employee who solved the initial problem may have no budget, authority, or interest in running production software. They may not know that the app has quietly become part of payroll, customer onboarding, reporting, or another process that cannot simply stop on Tuesday morning. "Ask Melissa, she built it" is not an operating model.

An internal application needs a named business owner and a named technical owner. It needs an inventory record, an access policy, a support path, and a retirement plan. If nobody is willing to accept those jobs, the company is not ready to depend on the application.

Ask five questions before sharing the link

1. Who owns the business process and the technical system?
2. What data, credentials, and permissions does it use?
3. What breaks if the app stops working tomorrow?
4. How will ownership transfer when its creator leaves?
5. Who decides when to repair, replace, or retire it?

If the answers are vague, the application is still a prototype. Treating it like production software does not make it one.

I remember what a first version used to cost

I wrote Velaro and StatusCast entirely by hand. Each first version took close to a year to build before it had a real chance to meet the market.

That was not a romantic year of tinkering. It was time, money, and risk accumulating every day. By launch, I had already made hundreds of decisions about a customer I was still trying to understand. If the premise was wrong, I could not shrug and throw away a weekend prototype. I had a year of my life tied up in it.

That is why the research had to come first. When code was expensive, an uninformed guess was an excruciating way to start a company.

AI removed the excuse to research later

The change in development speed is real. In a controlled GitHub study of 95 professional developers, the group using Copilot completed a coding task 55 percent faster.

DORA's 2025 research found that 90 percent of technology professionals use AI at work and more than 80 percent believe it has increased their productivity. It also found that higher AI adoption was associated with more delivery throughput and more delivery instability.

Speed is not certainty. In the 2025 Stack Overflow Developer Survey, 46 percent of respondents distrusted the accuracy of AI tools while 33 percent trusted them.

A founder can now turn an idea into a plausible application in days or weeks. That is wonderful. It should make experimentation cheaper and make bad ideas easier to discard.

Instead, some founders are learning the opposite lesson. They assume that because the application was easy to create, the company will be easy to build.

The expensive work moved. It did not disappear.

A working product still needs a customer who cares. That customer has to understand why the product is different, trust it with real work, get through onboarding, and receive help when something breaks. Someone has to find that customer in the first place.

Then come the parts that demos avoid: permissions, security reviews, billing failures, contract negotiations, odd integrations, support coverage, and all the edge cases created by actual customers.

AI can help with every one of those jobs. It does not decide which market is worth years of your attention, and it does not make customers appear.

Use the savings before you build

If AI gives you months of development time back, spend some of it learning. Study competitor reviews and support complaints. Understand how buyers describe the problem, what they already pay for, which workaround they hate, and where they go for advice.

Then use fast development to test an informed position. Put a narrow solution in front of the right people. Watch what they do. Throw it away if the evidence says you were wrong. Cheap code is most useful when you are willing to discard it.

I think we may be writing thought leadership for AI now

Not because AI has money, authority, or a procurement department. It does not. Not yet, anyway.

But increasingly, it is the first reader.

It crawls the article, decides which parts are worth extracting, rewrites them into an answer, and may give the human enough information that they never visit the source.

Very efficient. Especially for everyone except the person who did the work.

That is a strange audience model. We still say we are writing for founders, buyers, operators, and the hidden people inside a company who can quietly kill a purchase. But between us and them now sits a machine reading at industrial scale and returning very little traffic.

Apparently, the middleman no longer has to introduce the two parties.

AI is already my researcher, editor, sparring partner, occasional second brain, and, more often than I care to admit, my first brain. On a busy day, half my thoughts appear to be sitting in a server farm.

I am not arguing that we should keep AI out of the writing process. I am asking whether it has also become the main audience.

If the buyer asks ChatGPT, Google AI Mode, or another answer engine instead of visiting our site, who did I actually write this for? The person making the decision, or the machine deciding which pieces of my argument survive the trip?

The answer cannot be "write for AI." That produces the same lifeless material the machine already makes for free, and the internet has a generous supply.

But pretending AI is not standing between the idea and the reader is becoming equally ridiculous.

Thought leadership was already in trouble

Too much of it was ordinary marketing content wearing a blazer: five trends shaping the future, seven lessons from successful leaders, and a conclusion nobody could possibly disagree with.

AI can summarize the accepted view, smooth out the language, add a tasteful amount of confidence, and produce a conclusion that sounds important without creating any risk for the person whose name appears above it.

If that was the whole product, then yes, its importance is diminishing. It probably deserved to.

Thought leadership should contain thought. That means judgment, a position, evidence, and enough specificity that another informed person can disagree. AI did not remove the need for those things. It exposed how often they were missing.

The human reader did not disappear

The 2025 Edelman-LinkedIn B2B Thought Leadership Impact Report surveyed nearly 2,000 management-level professionals. Sixty-four percent of target decision-makers and 63 percent of hidden decision-makers said they spend more than an hour a week consuming thought leadership. Fifty-six percent of target buyers and 55 percent of hidden buyers said they use it to evaluate vendors.

Edelman and LinkedIn both have an obvious interest in the category, so I would not carve those percentages into a monument. The more useful point is that the people who affect a purchase are still looking for ideas before they volunteer for a sales call. Many of them are the finance, legal, security, procurement, and operating people a marketer may never know by name.

They are still human. They still decide whether an argument is credible, whether a company understands the problem, and whether somebody should take the vendor seriously.

The reader did not vanish. The route to the reader changed.

The machine may read it first

Pew Research Center analyzed 68,879 Google searches made in March 2025. When an AI summary appeared, users clicked a traditional result in 8 percent of visits. Without the summary, they clicked a result in 15 percent. A link cited inside the AI summary received a click in just 1 percent of visits.

That is more than a change to the search page. The answer engine has become an intermediary between the person with the question and the person who did the work.

Cloudflare's 2026 data found that 52 percent of AI crawler requests were for training, up from 22 percent in spring 2025. Across leading AI companies, it observed crawl-to-referral ratios ranging from 118 pages crawled for every referred visitor to nearly 50,000 pages per visitor.

Google says overall organic click volume has remained relatively stable and that the clicks it sends are becoming more valuable. Both things can be true. Google can send billions of clicks in aggregate while AI answers remove a large share of the visits an individual publisher once expected from informational searches.

Whatever the final ratio becomes, the old bargain is changing. We publish. A platform reads. The platform may deliver our conclusion without delivering our audience.

A citation is useful. It is not a relationship.

If an AI answer carries our name, our evidence, and our point of view into a buying conversation, that influence has value. It may shape a shortlist before we know the shortlist exists.

But we should not confuse being used as a source with owning an audience. A person who never reaches our site cannot join our list, explore the rest of our work, see the full argument, or notice where the machine flattened an important qualification.

This makes thought leadership harder to measure. Traffic still matters, but branded search, direct visits, citations, sales conversations, invitations, and buyers repeating our language may tell us more than a pageview report. Influence has always been messy. AI has made it messier and given the mess an API.

For 25 years, publishers accepted crawling because search engines returned traffic. AI systems weaken that exchange. We should be clear-eyed about the economics even while we make our work easy to find.

Do not write for AI

Write for the person making a decision. Format the work so a machine can carry it there without mangling it.

Those are different jobs.

An answer engine benefits from direct definitions, descriptive headings, named sources, clear comparisons, and sentences that survive being quoted out of context. A 2026 preprint studying citations across ChatGPT, Google, and Perplexity found that pages contributing more to generated answers tended to be structured, semantically aligned with the question, and rich in extractable evidence such as definitions, numbers, comparisons, and procedures. The research is young, but none of that requires us to sound like a machine.

Writing only for extraction creates the same generic sludge AI already produces for free. There is no competitive advantage in becoming easier to summarize because you removed every surprising thought.

The better rule is simple: write for the decision and format for retrieval.

AI can help with the work. It cannot own the judgment.

I use AI in the writing process. I have already argued that we should judge the finished work instead of treating the tool as a verdict. I am not changing that position here.

AI can find a weak claim, challenge a conclusion, organize research, suggest a clearer structure, and rescue a sentence I have made unnecessarily difficult. That is useful leverage.

But if the machine supplies the premise, the examples, the position, and the conclusion, I am not leading anyone's thinking. I am laundering consensus through my byline.

The part that has to remain ours is the part with consequences: what we believe, why we believe it, which experience changed our mind, where the conventional answer fails, and what we are prepared to recommend under our own name.

AI can be half the brain. It cannot be the opinion.

Publish something the machine could not have known without you

That might be original research. It might be a decision you made, a pattern you observed across twenty years, a technical tradeoff that failed in production, or a position that becomes obvious only after living with the consequences.

Name the evidence. Link to the source. Separate what the data proves from what you infer. Make the main point clear enough to survive a summary. Keep enough personality in the piece that a human wants the full version.

Then distribute it where people already spend time. Put the sharpest version on LinkedIn. Put the compact argument on X. Let the canonical article hold the evidence and context. Waiting politely for every interested person to discover the company blog has become an eccentric marketing plan.

Google's own guidance for AI search features says there is no special AI schema or machine-readable file required. It recommends the familiar work: make the page crawlable, keep important material in text, use structured data that matches the visible page, and create helpful, reliable, people-first content.

That advice is self-serving, but it is still directionally right. Machines need access and structure. People need a reason to care.

So who are we writing for?

We are writing for people who increasingly ask machines what to read, what to consider, and sometimes what to think.

Thought leadership is not becoming less important. Average thought leadership is becoming worthless. The path is less direct, attribution is worse, and the standard for having something worth repeating is higher.

The AI may be the first reader. It is not the final buyer, the skeptical CFO, the security lead, the board member, or the person whose reputation rides on the decision.

That is still who we are writing for.

So Why the Hate for AI Content?

Is it because we can tell? Are we all now required to be Hemingway so people don’t think we used AI?

Or is it because once we think we can tell, we assume the quality must be low?

To be fair, people are pumping out huge amounts of AI-written content that does little more than regurgitate what is already online and game search rankings. It’s bad content, and it has made people suspicious of every other reason someone might use AI in prose.

But is using AI to sharpen an argument, untangle a sentence, or become a better writer really the same thing as publishing thousands of empty pages?

Is it because it threatens gatekeepers who built their brand on "I have the magic words"?

Some of the backlash is about quality, and some of it is deserved. But "I can tell AI was involved" is not the same as proving the writing is bad.

The Double Standard Is the Real Problem

We’re perfectly fine using technology to do math, assemble cars, edit photographs, write code, and build entire software applications.

But when technology helps someone explain something, tell a story, or teach a concept, suddenly the work is "low value"?

That’s not a principled stance. That’s inconsistent and absurd.

The Better Question

Stop asking "Was this written by AI?"

Start asking "Is this useful, accurate, and created with integrity?"

That’s what readers actually care about.