Fantastic read! The role of Product is not to see that the engineers are building the right thing. Product needs to look at the market. If they look at the engineers, they have their back to the users.
In the same way you went from the mentality of not hiring PMs to hiring PMs, overtime you would realize why engineers should not define the roadmap and take product decision.
I don’t completely disagree with you Apex or the author but I guess the tech team PostHog has is a dream tech team.
My developers dont write tasks in Jira based on Stories. They rely heavily on design. They dont have a slight understanding of how basic UX works.
Engineers dont even have the basic ideation thats upto date with market trends. They are completely reliable on libraries, SDKs and APIs available in the market.
The beat thing is that these people are from top tech schools like IIT and IIITs in India.
I would love to work like this but the post just does not do justice to all the operational activities that are going on within a team on a daily basis.
1. Engineers who are product driven and can do this are not exactly dime of a dozen. Same as PMs who can actually build things from scratch themselves.
2. Company stage & cycle matters here, I can't see any engineers being happy about managing stakeholders, doing presentations and aligning other functions. All of this inherently comes when you are decision maker in `what` and `why` of the product.
3. The type of product and expertise of the industry and customer understanding that comes with being a domain expert not only in the fundamentals of engineering but industry itself.
The lowest value work I see in the PM function is really parroting and translating requirements for engineers who could probably do the same but in some cases want to only focus on building.
Great to see that it works for PostHog! I wonder if you can sustain this whilst growing. (I hope you do!)
For example in the newsletter.posthog.com (this page) when I reply to a comment, a pop up opens asking me about my details (Signup) but Im already signed in.
Also the popup has a close button but it never closes. Same is the case for a guest user.
Second example,
Its impossible to write in this text box if the content is longer than screen. It can scroll down to where I want to write and the only way is to select all then move down on the page.
Awesome post James! 👏 Very insightful and inspirational.
How big a factor do you think it plays that at Posthog you have engineers building for technical people? Compared to if you were an organization building a platform for moms to track their pregnancy?
i think the most important thing is that we build products into competitive markets - where there is a "standard" set of features needed. for example, everyone knows roughly what web analytics needs to do to be useful. the big thing that's different is that it's all in one place, cheaper and - over time - we build more developer focused features. we have built plenty of products - web analytics, a data warehouse, for example that are not traditional for full stack engineers, who are mostly the people we employ.
this would be incrementally harder the further we are away from tools developers would ever use. pregnancy tracking, harder but not impossible, creating an ipad for the first time? probably a terrible idea. there's probably a judgement call here to make based on the specific product you have in mind and how demanding the product-skill requirement is of your specific product!
Fantastic read! The role of Product is not to see that the engineers are building the right thing. Product needs to look at the market. If they look at the engineers, they have their back to the users.
Pathetic post.
In the same way you went from the mentality of not hiring PMs to hiring PMs, overtime you would realize why engineers should not define the roadmap and take product decision.
I shall wait for an update in 1-year.
I don’t completely disagree with you Apex or the author but I guess the tech team PostHog has is a dream tech team.
My developers dont write tasks in Jira based on Stories. They rely heavily on design. They dont have a slight understanding of how basic UX works.
Engineers dont even have the basic ideation thats upto date with market trends. They are completely reliable on libraries, SDKs and APIs available in the market.
The beat thing is that these people are from top tech schools like IIT and IIITs in India.
I would love to work like this but the post just does not do justice to all the operational activities that are going on within a team on a daily basis.
As PM I weirdly like this.
However there is a big caveat which is context.
1. Engineers who are product driven and can do this are not exactly dime of a dozen. Same as PMs who can actually build things from scratch themselves.
2. Company stage & cycle matters here, I can't see any engineers being happy about managing stakeholders, doing presentations and aligning other functions. All of this inherently comes when you are decision maker in `what` and `why` of the product.
3. The type of product and expertise of the industry and customer understanding that comes with being a domain expert not only in the fundamentals of engineering but industry itself.
The lowest value work I see in the PM function is really parroting and translating requirements for engineers who could probably do the same but in some cases want to only focus on building.
Great to see that it works for PostHog! I wonder if you can sustain this whilst growing. (I hope you do!)
When engineers work, bugs prevail.
For example in the newsletter.posthog.com (this page) when I reply to a comment, a pop up opens asking me about my details (Signup) but Im already signed in.
Also the popup has a close button but it never closes. Same is the case for a guest user.
Second example,
Its impossible to write in this text box if the content is longer than screen. It can scroll down to where I want to write and the only way is to select all then move down on the page.
Awesome post James! 👏 Very insightful and inspirational.
How big a factor do you think it plays that at Posthog you have engineers building for technical people? Compared to if you were an organization building a platform for moms to track their pregnancy?
i think the most important thing is that we build products into competitive markets - where there is a "standard" set of features needed. for example, everyone knows roughly what web analytics needs to do to be useful. the big thing that's different is that it's all in one place, cheaper and - over time - we build more developer focused features. we have built plenty of products - web analytics, a data warehouse, for example that are not traditional for full stack engineers, who are mostly the people we employ.
this would be incrementally harder the further we are away from tools developers would ever use. pregnancy tracking, harder but not impossible, creating an ipad for the first time? probably a terrible idea. there's probably a judgement call here to make based on the specific product you have in mind and how demanding the product-skill requirement is of your specific product!