Code became abundant. The market did not.

Over the past few months, I managed to take a mobile app to TestFlight on my own. The software worked. What I could not prove was that anyone would change a habit because of it.

I have followed Claire Vo's work for some time. Recently, I watched the video of her talk at Compile 2026, a Cursor event, about what it means to work in product as building software becomes more accessible.

Ending Fio is what made the talk resonate with me. Claire put backlogs, story points, and new multi-agent loops in the same conversation: how much activity are we producing without knowing whether it creates value?

Building Fio became easier than proving it should continue to exist.

Fio separated software from product

Fio was an iPhone app that turned articles, tweets, PDFs, newsletters, links, and screenshots into private podcasts.

To build it, I combined OCR, different LLMs, AI agent orchestration, evals, APIs, source retrieval, and voice generation. Accessing each of these technologies is much easier now. Integrating them, evaluating the output, and making the system reliable still took real work, but the distance between an idea and a functional beta has become much shorter.

Fio worked well enough for a beta. The part that did not prove itself was different. I had a few dozen people on the waitlist, but conversations did not show enough urgency or willingness to pay. Free alternatives raised the bar, and the weekly format did not demonstrate meaningful differentiation.

I ended the product instead of treating a functional demo as validation.

That experience changed how I think about constraints in product. When engineering was scarcer, PMs had to protect the team's capacity. With Fio, I had the capacity to keep building. What I lacked was evidence from the market.

That is when Claire's phrase became concrete for me: code became abundant, but we did not suddenly get more things people want or are willing to pay for.

Where behavior changed

Claire returns to a familiar product phrase: build something people want. Her provocation is to ask what wanting actually means.

I do not think it is enough for someone to say that a problem exists or praise a prototype. Those responses help form a hypothesis, but they still leave two questions open: would someone pay to solve it? Would they change the way they work to adopt the solution? (Read the excellent book The Mom Test if you want to learn more about this.)

The work that remains for the PM

I did not finish the video thinking every PM needs to become an engineer. I came away with a simpler challenge: as ideas become easier to materialize, choosing where to spend that capacity matters more.

When anyone on the team can put a solution together, the title of the person who made the decision matters less than the quality of the decision. This does not erase the differences between product, design, and engineering. It does make the old division less useful, where one function decides, another specifies, and a third executes without participating in the choice.

With Fio, I used AI to explore alternatives, build parts of the system, and review the result. It could also produce an elegant defense of a weak idea. No model could decide for me whether the evidence was strong enough to keep investing.

Data helps reduce uncertainty. Research reveals problems. Experiments expose hypotheses to the market. Even so, there comes a point when someone has to choose a direction with incomplete information and take responsibility for that bet.

Claire also talks about the future of the role. The Product Manager title will probably remain, especially in larger organizations. The work, however, will move away from simply organizing backlogs, writing tickets, and protecting capacity.

For me, the center of the job is deciding what deserves to be built, finding evidence that it matters, and stopping the investment when that evidence does not appear. Speed still matters. It just cannot be confused with progress.

Fio left me less impressed by the speed of building and more attentive to what happens afterward. I can turn an idea into something real very early now. That only makes it more urgent to find out whether someone changes their behavior, comes back, and pays.

Building is no longer proof. Product judgment shows up in the evidence we require to continue and in our willingness to stop when it does not appear.