The data, the people, and the world under a tool

Most of Saturday's reading is not about features at all. It is about the people who build productivity software, the data those people trust, and the wider world the tools sit inside.

A quieter day is a good day to slow down and ask how you judge a tool, rather than which tool won the week.

The growth stack and the data under it

SaaStr published a working account of its agent-led growth stack as it stands now, drawn from a live session it ran this week [1]. The headline it put on the piece makes the argument plainly: first-party data beats every signal tool.

It is worth being precise about the two things being compared. First-party data is what a customer gives you directly: the enquiry they sent, the meeting they booked, the reply they wrote, the thing they bought. You collected it through your own contact with them, so you know when it happened, and you know it is about a real person who chose to talk to you. A signal tool works the other way around. It infers interest from behaviour it observes elsewhere — a company visiting a page, a job change, a rise in searches around a topic — and sells you that inference as a lead. The appeal is obvious. It promises to tell you who is in the market before they tell you themselves.

The trade-off hides in the word infers. A signal is a guess about intent, and a guess goes stale. The person who looked may not be the person who buys. The company that matched the pattern last month may have shelved the project. First-party data has the opposite shape. It is narrower, because it only covers people who have already made contact, but every record in it is something that actually happened. That is why it holds its value: it does not need to be true about the future, only about the past. The reasons a bought signal decays are the same reasons any record does, and they are worth understanding before you pay for one — see why data gets out of date and what a customer record should contain.

So if you are choosing between a tool that enriches your own records and a tool that buys you signals about strangers, the question is not which has more rows. It is which data a salesperson can act on with confidence on an ordinary Tuesday. A record that is thin but true beats a file that is rich but inferred.

The same session is where SaaStr describes handing growth work to agents directly [1]. An agent that books a meeting or answers an inbound enquiry is acting on data, and the quality of that action is capped by the quality of the data underneath it. This is the practical reason first-party data matters more as you give software more to do. An agent fed true records does useful work; an agent fed inferred ones repeats the inference at speed. Before you let any agent act on your behalf, it helps to be clear about what automation should never decide — the handful of judgements that should stay with a person however good the tooling becomes.

The people behind a tool

The second piece is a personal essay from the founder of Basecamp. Its subject is not software but friendship, and the shared interest that holds a certain kind of friendship together. "We should all strive to be our brother's keeper: to look after each other, inspire each other, and simply enjoy each other's company," he writes, and he is open that for him the shared interest has always been computers [3].

That is a long way from a buying decision, and in one sense it has nothing to do with one. But there is a thread worth pulling. Software is made by people, and the tools that last tend to come from people who care about the craft, and about each other, enough to keep showing up. When you choose a tool you are also choosing a group of people and the culture they keep. A feature list will not show you that. It shows up in how a product is maintained, in how its makers talk about their work, and in whether the people around it are still interested a year from now. That last test is the one worth applying deliberately rather than by accident, which is the whole point of trying to choose software that lasts a year.

The world a tool depends on

The third piece is also from Basecamp's founder, and it starts somewhere unexpected: a motor race. "I first went to China in 2011, racing for the Lotus/Jetalliance team at Zhuhai in the Intercontinental Le Mans Cup," he writes, before turning to what that trip showed him of the country's industrial side [2].

This is not a product announcement either, and it would be a stretch to claim it tells you anything about a spreadsheet or a CRM. What it is good for is a reminder. The software a business runs on feels weightless. It is a screen and a login. But it rests on a physical world of hardware, factories and supply that sits in particular places under particular governments. Most of the time that world is invisible, and most of the time that is fine. It is worth remembering when you quietly assume a tool will always simply be there. Resilience is not only a question of a software company's finances. It is a question of everything the software depends on without telling you.

For a buyer the lesson is modest and practical. Keep the ability to leave. Know where your records are and how to get them out without asking permission. That habit is the one we try to make easy in 360REV: your data is yours to export whenever you want, not held hostage to a decision to stay. The broader case for it is in the data you should be able to export on any Tuesday.

Put the three together and the thread is plain enough. Choosing a tool is choosing data you can trust, people who will keep building it, and dependencies you can live with. None of those three is printed on the pricing page. For the rest of the week's reading, see yesterday's briefing.