Should PMs ship code? At a ProductCon panel this month, four product leaders gave four different answers. The one that settled it for us came from the panelist from Interpret: separate “build to learn” from “build to scale,” and most of the friction goes away.
Build to learn
You're answering a question. Will users understand this flow? Does this data say what we think it says? Is this worth an engineer's week? The output is a decision, not a product.
- Who builds: you, fast, with whatever tool gets you there.
- Quality bar: honest enough to learn from. Ugly is fine.
- Lifespan: days. Throw it away when you have your answer.
- Never: real customer data without permission, production systems, anything people will start to depend on.
Build to scale
You're making something people will rely on. Now it needs to be secure, maintained, monitored and owned.
- Who builds: engineering owns it, even if your prototype started it.
- Quality bar: review, tests, and for AI features, evals and guardrails.
- Lifespan: as long as it's used.
The handoff
The expensive mistake is a learning prototype that quietly becomes production because people started using it. Prevent it with three habits:
- Label it. Say “prototype, will be thrown away” in the tool itself and in the message you share it with.
- Hand over the learning, not the code. Engineers need what you found out: what users did, what broke, what surprised you. The prototype is evidence, not a spec they must copy.
- Write the requirements last. After the prototype, you finally know enough to write them well.
This week's Weekly Build is a build-to-learn exercise. Treat it that way.