I build the prototype before I write the PRD

I used to bring a document to the conversation where I now bring a working prototype. AI has changed the order of my product work: I can build a small version of an idea, put it in front of people, and use what happens to decide whether it deserves a detailed plan and a larger investment.

That has changed my day more than any tool I've adopted.

The old process was familiar. Spend time with user research. Build a baseline understanding of the problem. Map an opportunity tree. Develop hypotheses with design and engineering. Write the product requirements document. Work through executive reviews and revise the long-form explanation of what we should build and why.

There was real thinking in that work. Understanding the customer, sorting the opportunities, and making the case for an investment all mattered. They still do. But a lot of time could pass before a user got to interact with the thing we were describing.

We were doing so much work to decide whether to build something that we delayed one of the best ways to find out.

I've always thought of the old model as a kind of capacity management. An airline has a finite number of seats on a flight and wants to fill them. We had a finite number of engineering hours in a sprint and tried to make the best use of them. Story points, estimates, prioritization meetings: a lot of the operating system of product development grew around that constraint.

Now I can use a coding agent to get a small, functional application running while I'm still exploring the problem. Engineering time and production constraints still matter enormously. But for many of the discovery questions in front of me, getting something built is much less of an obstacle than it used to be.

The harder question has become: how do I know this is the right thing to build right now?

The kind of thing I'm building for discovery is a small application on a separate subdomain, with its own database and the necessary IT approvals. It's clickable. It's interactive. It does enough of the actual job that somebody can try it and tell me where the value is.

It can be rough. It can have limited capacity. I don't need to solve every problem associated with serving a large customer base before I learn whether the basic idea helps anyone.

I can put that application in front of a paid user-test group, an alpha group, or a few design partners. Then I can watch where they get stuck, ask what they found useful, and change the experience while the question is still fresh.

I still want the qualitative understanding of what hurts and why. I still want quantitative evidence when it's available. The prototype gives that research something concrete to work with. People can respond to an experience they've actually had, and I can see where my explanation of the value fails to match theirs.

In my own work, that has compressed discovery that used to take months into days. It hasn't made every answer certain. It has made the next useful question much easier to reach.

The part I keep coming back to, though, is shared context.

If I run a useful experiment and the findings stay in my head, the team gets very little benefit from how fast I worked. Somebody else might test a related assumption the following week without knowing what I learned. We can all move faster individually and still miss the connection between our work.

So I put the findings somewhere the rest of the team and our agents can use them. Other people contribute what they're learning from different users, problems, and prototypes. Those observations start to inform one another.

The useful record includes the problem we were exploring, what we tried, what people actually did, and what remains uncertain. It also needs the things that didn't work. I want the next person to understand why we changed direction, especially if they're about to revisit the same idea.

That shared context is becoming a central part of how I do product management. Each experiment adds to the team's understanding. Over time, we have more evidence to draw on when deciding which opportunities deserve a bigger commitment.

It also changes how I work with engineers and designers.

I can bring them in at the beginning with a very concrete invitation: help me build this prototype in the next hour. Poke holes in the interaction. Challenge the assumption. Help me figure out what we need to learn before this gets any further.

Getting the product, design, and engineering trio together that early is fun. We can work on something tangible, get it in front of a small test group that day, and come back with better questions. The conversation has a different energy when everyone can touch the idea and change it.

I've also found that disagreements become more useful. We have observed behavior to discuss alongside our hypotheses. We can disagree about what the evidence means, whether the test reached the right users, or what remains unproven. Those are productive disagreements to have before committing to a larger build.

The substantial work of bringing a product to market still follows. A promising prototype needs engineering for scale and reliability. It may need legal review, security work, a marketing plan, and a detailed PRD. I still go through the gates required to make that investment responsibly.

What changes is what I bring into those decisions. I have something people have used, findings the team can examine, and a clearer account of what we still need to learn. The document can explain a decision informed by that work.

For the next uncertain product idea, I'd start by writing down the decision the experiment needs to support. Then I'd get design and engineering together, build the smallest useful version, and put it in front of people who have the problem. I'd preserve what we learned in the same place as the team's other findings and use that evidence to decide the next investment.

That's the product work I want to spend more of my time doing. Get close to the problem. Make the idea tangible. Learn with the team. Give the promising ones enough support to become real products.

Once you've worked that way, it's hard to go back to waiting for the document to be finished before anyone gets to try the idea.