Slack was built as an internal communications tool for a game studio that was making something called Glitch. Burbn was a check-in app; the founders noticed users kept ignoring the check-ins and posting photos instead. Odeo was a podcast discovery platform until Apple entered the space, at which point a side project built for internal SMS updates became Twitter. In each case, the product team found the actual product by following something they hadn't designed for. The default instinct would have been to correct for these deviations. The teams that succeeded treated them as direction.
Rick Rubin makes the same argument in The Creative Act, and it's easy to read it as artistic philosophy. It's actually a description of how information flows in creative work. Accidents and unplanned turns aren't noise to be eliminated; they often carry more signal than the original plan. This would be harder to take seriously without independent corroboration, but the mechanism has been studied directly. Eric von Hippel's research at MIT found that between 10 and 40 percent of users in fields he surveyed had independently modified or developed products to meet needs that producers hadn't yet addressed. Lead users, as he calls them, encounter needs that the broader market will face months or years later. The user behavior that looks like misuse is often ahead of the product.
What the process is built to prevent
Product development methodology is organized around variance reduction. Discovery de-risks assumptions. Prioritization frameworks filter for ROI. Validation gates prevent under-baked ideas from shipping. These tools produce reliable outcomes from defined inputs, and they do that job reasonably well. What they cannot do is treat variance as signal, because variance reduction is the whole mechanism.
When a user misuses a feature, a well-run discovery process asks whether the behavior is representative or an outlier. The answer is almost always "outlier," because the population facing tomorrow's needs is, by definition, small today. The workaround gets routed to the bug backlog. The unexpected use case gets filtered as a segment too small to act on. The discovery process, operating correctly, eliminates the most forward-looking information it receives. This is a feature of the methodology, not a failure.
Why ideas need room to form
The separation between generating ideas and evaluating them has a structural basis in cognitive science, not just culture. Finke, Ward, and Smith's Geneplore model, developed in the early 1990s, describes creative ideas as passing through a preinventive stage. These are loosely formed structures that need space to develop before they can be assessed against any constraint. The generative phase is largely unconscious; the evaluative phase is conscious and deliberate. Running both simultaneously doesn't produce evaluated ideas faster. It prevents ideas from reaching the preinventive stage where genuine insight becomes possible.
Product teams compress these phases routinely. Exploration, prioritization, and validation happen in the same meeting, often in the same sentence. A direction gets proposed and receives feasibility questions before it has finished forming. A team brainstorms and immediately votes. The evaluative reflex fires before the idea has enough structure to evaluate. What gets cut isn't the weak ideas; it's the ideas that hadn't developed enough to be legible yet.
Rubin arrives at the same point from the practitioner side, without the cognitive science framing. Trying to assess an idea while it's forming almost always kills it. The solution he offers is structural rather than motivational. Keep the two phases on separate schedules. Generate without filtering; evaluate on material that already has form. This works not because it gives ideas time to improve, but because it lets them reach the stage at which evaluation becomes meaningful in the first place.
Subtract until it's unmistakable
Once a generative phase has produced something with form, the evaluative question becomes precise. What is the irreducible core? Rubin argues that a work should be reduced until removing anything more would make it cease to be itself. A product that can absorb more subtraction without losing its identity hasn't found its center yet. The test has nothing to do with minimalism as aesthetic preference; it's a diagnostic for what the product actually is, as distinct from what accreted around it during development.
The default product management posture moves in the opposite direction. Scope expands to address every identified use case. Each reasonable addition gets made. The result is a product with large surface area and no clear center. Running the subtraction question before each major iteration produces a different kind of pressure. Has the work remained unmistakable, or has it drifted toward approximately nothing? The question is harder to answer than any prioritization framework, and more consequential.
Quality has no stable address
A piece of work doesn't have fixed quality. Its effect changes based on when and how it's encountered. Rubin makes this point about music, but the same logic applies to product design without modification. An onboarding flow that reduces friction in one context creates it in another, because what counts as friction depends on what users already understand about the product category, what they expect from the interface, and what competitive reference they carry. The feature itself doesn't determine the outcome. The fit between the feature and those circumstances does.
Product reviews spend time assessing whether something is well-designed without specifying the circumstances under which "well-designed" would mean "working." Introducing those circumstances early, before the quality assessment rather than after, changes what gets evaluated. It tends to produce more accurate answers and, practically, better decisions about when a feature is ready for which users. Asking whether the onboarding flow is good in the abstract tends to return no usable answer. Whether it works here, for this user, at this point in their relationship with the product, is a question that can actually be resolved.
What the book is actually for
The Creative Act was written for artists. The problems it describes are not specific to art. Making things under uncertainty, without a clear specification of what done looks like, where the most important information often arrives uninvited, describes product work as much as it does music production. Rubin is worth reading here because he is a practitioner writing about judgment rather than a consultant writing about process. The standard PM toolkit covers execution well. Judgment is what it doesn't cover, and judgment is where most of the consequential product decisions actually live.
Reading Rubin as a PM calls for a narrower claim than that creativity and product development are secretly the same thing. A specific set of failures that show up repeatedly in product work, including in teams that followed the methodology correctly, are failures of creative practice rather than execution. The diagnostic tell is that the team did everything right and the product still didn't cohere. Those failures respond to different interventions. Rubin describes them with more precision than most product literature does, which is why the book is worth reading even if you have no interest in music.