Bring the thing, not the promise.

I wanted to understand my golf better. Not my swing. My numbers.

Strokes Gained is the method tour players use to see where they actually win and lose shots against a benchmark: off the tee, on the approach, around the green, on the putting surface. I had a rough idea for an app that would do this for an ordinary club golfer. That was all I had. A rough idea.

So I did what I've been doing all year. I opened Claude Code and asked it to do the research first.

It came back with business requirements. Then it designed the tests. Only then did it write the code.

Read that order again. Research, requirements, tests, code. That's the textbook. I've defended that process in steering committees for most of my career. The only thing that had changed was who did the writing.

The app worked. Pretty well, in fact. But it had a problem I hadn't specified and hadn't thought about: there was no easy way to start it. A working app that only its builder could launch.

Last week, ProductCon, Product School's conference for product leaders, put a name on something I'd been circling for months. The message I took home: writing code has become cheap. What's expensive now is knowing what to build. And that means working much closer to the people you build for.

One session on the agenda was literally called "Building Backwards": starting from working code instead of a spec.

I'd felt this before without naming it. In July, I wrote that I built a RAG assistant overnight, and the evaluation took weeks. The code was never the hard part. Knowing whether it answered the right questions, in the words real people actually use, was.

To fix my golf app's launch problem, I turned to Lovable. I gave it the project documentation Claude Code had produced and asked for a web app with a simple interface.

Two things surprised me.

The first was creativity. Lovable designed screens and added features I had never specified. Some of them I'd have asked for, if I'd thought of them.

The second mattered more. Changes cost almost nothing. I wanted an extensible list of options instead of a checkbox. One prompt. Done.

Later, I tried to log in, forgot my password, and found no reset link on the login page. One prompt. Link added.

That's when the idea landed. Not in the code. In the conversation.

Think about how a good restaurant creates a new dish. The chef doesn't start with a written specification. She cooks, tastes, lets the waiters and a few regulars try it, adjusts the salt, swaps an ingredient. Only when the plate is right does anyone write the recipe card so the kitchen can cook it the same way 200 times a night.

For most of my career, the PRD (product requirements document) has been a recipe card written before anyone had tasted the dish. We wrote down, in detail and weeks in advance, what the business would need. Then we built it. Then we served it to the business and found out what they really wanted.

When I started working with Claude Code, I followed the classic order: research, documentation, test plan, then build. Only with Lovable did I realise you can reverse the order and start by building to understand the requirements.

That's the test kitchen. Sit in one room with the people who will use the app. Build a working prototype together, prompting as they talk. "Can that be a list?" One prompt. "Where do I reset my password?" One prompt. They react to something real, not to a document they had to imagine.

Then, once the prototype does what they need, ask AI to write the full project documentation from it: requirements, flows, edge cases. Hand that to the team building the enterprise solution. The technicalities come afterwards.

The PRD becomes the recipe card. It records what we tasted and agreed on in front of a working screen, so the enterprise team can build it properly at scale.

To me, that's Agile in its purest form. The Agile Manifesto put "working software over comprehensive documentation" and "customer collaboration over contract negotiation" on the wall in 2001. For twenty-five years we nodded and kept writing the documentation first. Because building was the expensive part. It isn't anymore.

Sources: ProductCon San Francisco