The Feature We Refused to Build

A few weeks ago we wrote a product requirements document for a mid-market consultancy, and the most important line in it was a refusal.

The situation is one you'll recognize if you've ever looked closely at how a professional services firm actually gets clients. One person owns all of business development and all of marketing. Not a team, a person. His highest-yield activity, by a wide margin, is being present on LinkedIn every single day: reading what his market posts, commenting with something worth reading, inviting leaders to be interviewed for a content piece, and never asking for anything. He described the discipline as "be present, be interesting, add value, don't ask." It works. Almost every new engagement the firm wins comes from an existing client, a referral, or a buyer who changed companies, and the relationships behind all three run through his daily presence in one tool.

So the automation practically writes itself. Scrape the profiles of everyone matching the ideal customer profile. Auto-send connection requests with a personalized opener. Auto-follow-up on accept. Turn one person's daily hour into a machine that runs at a hundred times the volume. There is an entire category of AI go-to-market tooling selling exactly this, and it demos beautifully.

We wrote into the PRD that we would not build it.

Not "we'd need to scope it carefully." Not "phase two." We named it as a hard product constraint, in writing, before anyone asked us to justify the fee.

The reason is arithmetic, not principle. Automated scraping and automated connection requests violate LinkedIn's terms of service. The penalty for violating them is not a warning letter — it's account restriction or termination. Which means the downside of the automation is the loss of the Sales Navigator account through which this firm's entire pipeline flows. Set the two sides next to each other. The upside is that one person saves somewhere between three and six hours a week of manual sending. The downside is that the company's only functioning source of new business stops functioning, and the person whose reputation is the actual asset gets his professional identity flagged as a bot.

That is not a close call. It is not even a risk decision. It's a trade where the best possible outcome is small and the worst possible outcome is the business.

What made this worth writing down, rather than just quietly not building it, is that the client would have said yes. Enthusiastically. Everyone in the market is being told that this is what AI does for sales, and the firms selling it are not lying about the mechanism — it does send the messages. They're just not pricing the tail. When a vendor builds something that puts a client's core channel at risk and the client approved it, the vendor still owns the outcome. "You asked for it" is not a defense anyone accepts on the day the account gets shut off.

So we priced the boring alternatives instead, all three of them, in the same document. Upgrade to the tier that includes a supported API, and pay for the data access rather than stealing it. License a third-party data provider that has already done the legal work. Or export manually on a weekly cadence and automate everything downstream of the export — the enrichment, the scoring, the prioritization, the draft messages sitting in a queue for a human to send.

That last one deserves a second look, because it's where most of the value actually lives and it's the option nobody demos. The hard part of this firm's business development is not the physical act of sending a connection request. It's knowing which twenty-five of five thousand possible accounts are worth being present for this quarter, and what signal tells you one of them just became ready to buy, and what you'd say that isn't generic. All of that is automatable without touching the terms of service. The part we refused to build was the least valuable part of the workflow. It just happened to be the most visible.

The rest of the design principles in that document followed from the same instinct, and they're worth stating plainly because they're the ones that survive contact with a real business. Nothing goes to a person outside the company without a human approving it first. Every recommendation the system makes carries the evidence it was based on, so a person can disagree with it. The whole thing has to be operable by a firm with zero engineers on staff, because that firm has zero engineers on staff and will still have zero engineers on staff in two years. And it sits underneath the tools they already use rather than replacing them — their CRM stays their CRM, their sales tool stays their sales tool, and the system we build is the connective tissue nobody currently owns.

None of that is exciting. All of it is why the thing will still be running in eighteen months.

There's a broader point here about how to evaluate anyone selling you AI automation, and it's a simple question: what have you refused to build, and why? Not "what are your guardrails" — everyone has a slide about guardrails. Ask for a specific instance. A real feature, for a real client, that they declined to ship, and the reasoning behind the decline. If the answer is vague, or if it's a story about refusing something obviously illegal, they haven't been in the room where the trade was genuinely tempting. The tempting ones are where the thing works, the client wants it, the fee is attached to it, and the failure mode is rare but terminal.

The instinct that matters is not "can AI do this." AI can do enormous amounts of it. The instinct that matters is "what happens on the day this goes wrong, how likely is that day, and who eats the cost." Most of the AI implementations that will embarrass companies over the next two years are not going to fail because the model was wrong. They'll fail because someone automated an action with an asymmetric downside and nobody in the room did the arithmetic out loud.

We do that arithmetic in the requirements document, before the fee is agreed, because that's the only point where it's cheap to say no.

If you're weighing an automation right now and the honest answer to "what happens if this misfires at scale" is that you'd lose the channel your business depends on, we're happy to look at it with you and tell you what we'd build instead. Sometimes the answer is that there's a better version nobody offered you. Sometimes it's that the manual step should stay manual and everything around it should get faster. Either way it's a shorter conversation than the one that happens afterward.