Thanks for writing this, and your other blogs about product engineering. They give me confidence when I'm trying to demonstrate this mindset to an unengaged feature team. Show that we are engineers and more is possible. Would love to join PostHog ✨
Every single post is like you’re reading my mind. I’ve been thinking (and suffering) about the same problems for years, but you express them so clearly. Great post!
The key premise is that this works when engineers are "You must stay switched on as no one will spoon feed you product requirements." but most engineers "just want to build stuff..."
For engineers who just want to build stuff, "Engineers make product decisions" will lead to dead end, because they are disconnected from what the market wants.
The simple answer is we don't hire those kinds of engineers. Our experience is there are lots of talented engineers who want to do more than "just build stuff". That doesn't invalidate that preference, though, and it's 100% true that our approach is compatible with everyone. Anything worth doing rarely is.
I totally felt and still feel this deadline doom loop in most companies I worked for.
I don't like the section good/bad product engineer because I feel like it is oversimplifying a lot of complex situations and may alienate people who actually need that kind of advices.
Lets say you're in a company that had this doom loop for years and then, changes its product management/engineering strategy. Now you're left with a massive tech debt and churning customers.
How do you actually go from this situation to fast feedback loops when the product and its technical base is neither supporting the needs of the business nor the needs of the customers?
In my opinion, to obtain this fast feedback loop, some of your engineers will have to spend a lot of time (maybe more than a month) (re)building the technical base before they can start releasing something to the customers.
Would the Posthog product team handle that kind of case differently?
Thanks for the article, feels pretty close to what I’m trying to do in my company.
One thing I’m struggling with right now is how do you deal with designers? One one hand I feel like they can really improve the user experience, on the other adding more people and questions to the team feels like it makes engineers move 5 times slower. And of course in the end it’s a better user experience if you have iterated 5 times with feedback instead of shipped one « perfect » version.
My current thinking is that designers should focus on the design system and setting up guidelines that engineers can then use to be autonomous. But it’s not an easy shift to make.
Maybe you don’t have the question so much at posthog because your product is made for engineers (at least when we tried it the PMs/ designers in my team found it extremely technical and hard to use)
Love the product engineer mindset, Posthog.
Thanks for writing this, and your other blogs about product engineering. They give me confidence when I'm trying to demonstrate this mindset to an unengaged feature team. Show that we are engineers and more is possible. Would love to join PostHog ✨
Every single post is like you’re reading my mind. I’ve been thinking (and suffering) about the same problems for years, but you express them so clearly. Great post!
The key premise is that this works when engineers are "You must stay switched on as no one will spoon feed you product requirements." but most engineers "just want to build stuff..."
For engineers who just want to build stuff, "Engineers make product decisions" will lead to dead end, because they are disconnected from what the market wants.
The simple answer is we don't hire those kinds of engineers. Our experience is there are lots of talented engineers who want to do more than "just build stuff". That doesn't invalidate that preference, though, and it's 100% true that our approach is compatible with everyone. Anything worth doing rarely is.
Very interesting article, thank you!
I totally felt and still feel this deadline doom loop in most companies I worked for.
I don't like the section good/bad product engineer because I feel like it is oversimplifying a lot of complex situations and may alienate people who actually need that kind of advices.
Lets say you're in a company that had this doom loop for years and then, changes its product management/engineering strategy. Now you're left with a massive tech debt and churning customers.
How do you actually go from this situation to fast feedback loops when the product and its technical base is neither supporting the needs of the business nor the needs of the customers?
In my opinion, to obtain this fast feedback loop, some of your engineers will have to spend a lot of time (maybe more than a month) (re)building the technical base before they can start releasing something to the customers.
Would the Posthog product team handle that kind of case differently?
Thanks for the article, feels pretty close to what I’m trying to do in my company.
One thing I’m struggling with right now is how do you deal with designers? One one hand I feel like they can really improve the user experience, on the other adding more people and questions to the team feels like it makes engineers move 5 times slower. And of course in the end it’s a better user experience if you have iterated 5 times with feedback instead of shipped one « perfect » version.
My current thinking is that designers should focus on the design system and setting up guidelines that engineers can then use to be autonomous. But it’s not an easy shift to make.
Maybe you don’t have the question so much at posthog because your product is made for engineers (at least when we tried it the PMs/ designers in my team found it extremely technical and hard to use)