In this interview, Kevin Weil discusses the challenges he faced transitioning from an engineering role to product management. He emphasizes that a product manager’s primary responsibility is to be the voice of the customer, focusing on the jobs the product is hired to do and the problems it solves, rather than on how the underlying systems work. Weil explains that his deep technical knowledge initially caused him to shortcut ideas based on perceived implementation difficulty, which he had to consciously suppress to maintain a pure focus on the problem at hand. He stresses the importance of not discarding solutions early due to technical complexity, instead collaborating closely with engineering teams to find high‑value, feasible solutions later in the process. The conversation underscores the need for product managers to balance customer‑centric thinking with realistic engineering constraints while preserving the integrity of problem definition.
Chapters
There's a funny thing. When you're an engineer, you know how all the systems work. And then when you're a product manager, you're not really responsible for knowing how the systems work. Your job is to be the voice of the customer. You're supposed to be thinking about what jobs your product is hired for. Like, why do people use your product, what are they trying to do? What problems does it solve for them, and how can you solve those problems better? But coming from an engineering world where I knew how the systems worked, it was actually, you know, in general, it's a strength. It's nice to be. It's good to be technical because you were still building products. But the challenge I think that I had to overcome at least, was because I knew how the systems worked, I would sort of short circuit certain ideas because I knew they'd be harder than other ideas. And I had to learn to actually, like, not use that part of my brain or part of my history. Because it's way better if you can think about what problem you're trying to solve and why, independent of whether it's easy or hard. Figure that part out later. But you want to sort of keep the purity of thinking about the problem you're trying to solve and not be like, well, I know this one's easier, so maybe we'll try and go in this direction a little bit, because we can do that faster. So I really. I had to sort of try and shut that part of my brain off, and then it kind of happened automatically because as we grew, I'd actually seen less and less of the code as time went on. But in the beginning, I really had to work at it.
Right. So you could throw it over the fence to the engineers and say, figure out how to make it work.
Well, no, it's definitely not that. Definitely not that. I think it's really important to be able to work directly with your team, but you just don't want to be. You don't want to be throwing out certain solutions just because you know they're hard. You know, at the end of the day, you absolutely work really closely with your engineering team. And maybe the perfect solution is actually not feasible from an engineering perspective, and you find the sort of 80, 20 value proposition that you can actually build. You just don't want to be throwing things out at the beginning. You want to do that sort of towards the end, once you figure out what the right thing is with the team.
