Who asked for that feature?

For founders shipping real product with AI in the loop. An essay worth your time, plus the sharpest things I've read, filtered hard. No hype. Just signal.

Ask a founder about any feature in their product and you will get a good answer. A customer asked for it, or the team saw a gap and filled it.

When I look at a product with a founder, most of the time the trouble is the total. Features get added from a few clients' feedback, or from a guess about what the rest would want. Each one makes sense on the day it ships. Over time the product carries a long list of features that do not really answer what most of its customers need.

The last issue argued that cutting features because a product feels bloated rarely moves the numbers you care about. This issue looks at how the features got there in the first place. The answer to both is the same: find out what your customers actually do.

The best things I read this fortnight on building product. I read them so you don't have to. Click the ones that earn it.

Building product in the age of AI · 9 min
TBM 441: AI, the Loss of Positive Friction, and What to Do About It
By John Cutler, writer of The Beautiful Mess and four years at Amplitude working with product teams.
Cutler follows customer feedback from the call to the shipped feature. The slow steps in between were where people judged what mattered: “The friction was judgement and discretion's friend.” AI now turns five customer calls into 80 tickets and 400 tasks. His first rule is the one to keep: “Keep original feedback atomic, and preserve its path back to the source.”

Craft & judgment · 11 min
Strong Opinions, Loosely Held
By Marty Cagan, founder of Silicon Valley Product Group and author of INSPIRED.
Cagan lists the ten biggest things he has learned since INSPIRED came out in 2008. One sits right under this issue. The question he says teams should be asking is “why are people using – or not using – our product?” He also asks you to “consider how much of an enabler these artifacts are for thinking we know more than we really do.” He means roadmaps and requirements documents.

Building the business · 18 min
The Rise of the Forward Deployed Engineer, and How To Do the Job Right
By Vinoo Ganesh, CEO of Kepler, previously at Palantir and Citadel.
At one of his earlier startups, a customer's data quality engineer blocked a file-format change for close to a year. Then someone watched her work. She was downloading the files and reading the rows by eye. The new format would have taken away the only check she had. The team built her a viewer that night, and she approved the change two days later. “She would never have said any of this in an interview.” On requests he is just as blunt: “Three firms asking for the same feature is easy to notice and worth relatively little.”

The counter-argument · 15 min
If computers count all the petals, who tastes the cherries?
By Liam Spradlin, in Aeon. Designer and author of the forthcoming book Does Design Matter? Human Agency in the Digital Interface (2027).
Spradlin argues against half of the fix in this issue. The fix says read the data. He says measuring what users do changes what a designer can see: “To the computer, then, actions constitute the person – which means that the person, as anything more than a set of actions, disappears from the designer's view.” His line is the one to sit with: “It's impossible to experience the taste of a cherry just by counting the petals on a tree.”

Take the five features your team spent the most time on in the last year, and write down who asked for each one. Then check each of the five against the data and against the people who use it.