Gokul Rajaram: belief

Transcript context

…Wow, so much good advice. There's a couple of things I want to follow up on there. What are some common pitfalls you've seen in startups trying to set up product development processes or the way they build product? What do you find are kind of some of the more common mistakes that founders make that early teams make? The biggest one I think is the founder becomes too tactical and disempowers their team. I think the founder thinks they know what customers want. I think they don't empower their teams enough and they basically just tell the engineers what to build. And I think that leads to teams that are basically tactically just shipping feature after feature without truly solving problems. And I think that then creeps into when you hire a PM, they see this is how the company is working. And they then also start working the same way. I think the best founders early on trust their engineering teams and product development teams to solve problems and more clearly present the problem to them and help them. And this is true for PMs also. They help them brainstorm solutions. and try to work with the team to understand why we chose a certain solution versus another solution, and then the team feels empowered to go build it, versus dictating them we should build an iOS app, while the actual problem to solve is we want to increase the percentage of people using our service to five times a week versus two times a week, and building an iOS app is one tactic, but there are many other tactics, which is improving our web experience, etc., So decision making and transparency of decisions around how products change customer behavior is probably there. And that leads to the culture of what is called a feature factory, where product teams basically are very proud of shipping feature after feature without truly knowing how much impact the feature has. If a feature is shipped, but it doesn't change customer behavior at all, is it really a feature or no? It's like a tree falling in the forest. Oh, my God. I love that. And I've definitely seen these teams that you're talking about. And that only becomes worse once they hire a PM. I like your rule of thumb of hiring a PM when you've gotten like eight to 10 engineers. What kind of points to it's time to hire a PM? Other than that, is there other things you've seen of just like, oh, my God, this team really needs a PM or they should wait longer? What have you seen there?…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.