3 ms·

> We felt the people building the thing should have the context of usage data and this shouldn't only sit in another team - which was a behavior we saw happenin

> We felt the people building the thing should have the context of usage data and this shouldn't only sit in another team - which was a behavior we saw happening quite frequently when we did user interviews early on. What is preventing the engineers from getting access to that data? Existing product analytics tools usually don't charge by seats, so if they wanted to look at the data, they should be able to get access to Mixpanel, Amplitude, etc. Compare that to Posthog's pricing of $25/user/month which incentives you to minimize the number of people at your company that have access to Posthog. > We had no idea if that hypothesis was correct - that engineers would care. We did a launch HN to find out and got quite a lot of good feedback and growth. Heap also found a lot of success on HN when they launched: https://news.ycombinator.com/item?id=5424206 https://news.ycombinator.com/item?id=5424206. While there was a lot of excitement early on, the kind of crowd it attracted wasn't a good demographic to sell to long term. > We have users doing 5 million events/day on Heroku's cheapest standard tier dyno. The challenge isn't ingesting the data. Especially with an analytics tool where you can turn off synchronous_commit so ingesting an event doesn't require writing to disk. The bigger challenge is around processing queries that span years of data. Queries get proportionality slower the more data you've collected. A query over 12 months of data is going to be 4x slower than a query over 3 months.

mritchie712 6y ago
> What is preventing the engineers from getting access to that data? In addition, should they even be spending a lot time looking at it? There is a reason companies hire PMs and data analysts (which are cheaper than engineers). I'd totally encourage engineers to understand the business, but at a certain point, they should probably get back to engineering.
hitekker 6y ago
> Heap also found a lot of success on HN when they launched: https://news.ycombinator.com/item?id=5424206 https://news.ycombinator.com/item?id=5424206. While there was a lot of excitement early on, the kind of crowd it attracted wasn't a good demographic to sell to long term. I hope posthog's founders heed this crucial implication: the paying customer for analytics are analysts, not engineers. Analysts want analytics that work. Engineers want analytics to go away. An analyst wants to augment their data analysis, in order to produce more conclusions or support more decisions for the decision makers they report to. An engineer wants to focus on building technically challenging, long-lived systems, not on churning out short-lived weapons in the justification-explanation wars waged between Data Science, Business Intelligence, Product Management and the C-Suite. To use a market analogy, the engineer-as-a-customer will pay on cost, not value. Analytics are necessary but secondary to their day-to-day work: for most, it's just a one-line telemetry SDK logging call. If an engineer builds a feature doesn't lead to an uptick in a business metric, that engineer can shift to another org with little fuss. The analyst, on the other hand, is tied to proving the performance of their feature or subject-of-analysis. The longer an analyst has to wait for engineering to build a tool to analyze (sell) a feature, the riskier their position is in the company. Analysts like Product Managers or embedded Data Scientists or BI experts, will accordingly pay a value-based price for analytics. They need it for their jobs. Posthog will likely work for companies where engineers are also analysts. But in larger companies where the roles are more clearly divided, I forsee posthog's current focus leading them astray.

mritchie712 6y ago

> What is preventing the engineers from getting access to that data? In addition, should they even be spending a lot time looking at it? There is a reason companies hire PMs and data analysts (which are cheaper than engineers). I'd totally encourage engineers to understand the business, but at a certain point, they should probably get back to engineering.

hitekker 6y ago

> Heap also found a lot of success on HN when they launched: https://news.ycombinator.com/item?id=5424206 https://news.ycombinator.com/item?id=5424206. While there was a lot of excitement early on, the kind of crowd it attracted wasn't a good demographic to sell to long term. I hope posthog's founders heed this crucial implication: the paying customer for analytics are analysts, not engineers. Analysts want analytics that work. Engineers want analytics to go away. An analyst wants to augment their data analysis, in order to produce more conclusions or support more decisions for the decision makers they report to. An engineer wants to focus on building technically challenging, long-lived systems, not on churning out short-lived weapons in the justification-explanation wars waged between Data Science, Business Intelligence, Product Management and the C-Suite. To use a market analogy, the engineer-as-a-customer will pay on cost, not value. Analytics are necessary but secondary to their day-to-day work: for most, it's just a one-line telemetry SDK logging call. If an engineer builds a feature doesn't lead to an uptick in a business metric, that engineer can shift to another org with little fuss. The analyst, on the other hand, is tied to proving the performance of their feature or subject-of-analysis. The longer an analyst has to wait for engineering to build a tool to analyze (sell) a feature, the riskier their position is in the company. Analysts like Product Managers or embedded Data Scientists or BI experts, will accordingly pay a value-based price for analytics. They need it for their jobs. Posthog will likely work for companies where engineers are also analysts. But in larger companies where the roles are more clearly divided, I forsee posthog's current focus leading them astray.