Graham McNicoll

We don't have product managers at GrowthBook. That is deliberate... One reason is ownership. The usual setup puts a layer between the people building the product and the people using it. Someone gathers requirements, translates them, and passes them down. Every translation adds a little bias and loses a little signal. We took that layer out. Our engineers sit directly next to the users they are building for, who are often engineers themselves. This method encourages engineers to develop empathy with our users, and to do the creative side or product building. That leads to the second reason: I don't want the product manager doing all the fun and creative parts of product building. Engineering is, I believe, a creative discipline. To ask them to just follow someone else's product spec sheet is demoralizing. The final reason is speed. The more people that need to coordinate on what you're building, how you're building it, or the current status of the project, the slower things go. It would be one thing if that meant the product was better, but in my experience this is usually not the case. You can see it in 5.0. Bryce built configurations, which let you parameterize your product, save it as a reusable component, then use feature flags to test variations without rebuilding anything. The engineers I hire have taste. They know what good feels like because they work day to day with our users, and they are building a product they would want to use it themselves. As agents write more of the actual code, that judgment matters more than ever. Plenty of people think a company our size is crazy to run without product managers. If you are one of them, tell me what you think we are missing.