Things we've learned about building products
newsletter.posthog.com
Things we've learned about building products
1–10 of 121 posts
Re: Things we've learned about building products
#2Sorry, what "successful products"?
And I have to say that "Technical Content Marketer " is one of the most dubious job titles I have ever seen.
Re: Things we've learned about building products
#3> Your product is downstream from your ideal customer profile (ICP).
Do not start with an idea. Start with a problem, and then construct a solution. The solution is the product. The problem implies someone who has that problem: this is the customer. How much of a problem it is tells you how much they want it and how much they will pay for it. Because an idea doesn't necessarily have a problem, it results in a product that doesn't necessarily have a customer.
> As 37Signal’s Jason Fried says “You cannot validate an idea. It doesn’t exist, you have to build the thing. The market will validate it.”
Similarly, don't set out to change the world. Put your product into the world, and the world will decide whether to change as a consequence.
Re: Things we've learned about building products
#4This list mentions A/B testing a few times and it's worth noting that A/B testing is great but it's not free.
I've seen a nontrivial number of smart engineers get bogged down in wanting to A/B test everything that they spend more time building and maintaining the experiment framework than actually shipping more product and then realizing the A/B testing was useless because they only had a few hundred data points. Data-driven decisions are definitely valuable but you also have to recognize when you have no data to drive the decisions in the first place.
Overall, I agree with a lot of the list but I've seen that trap one too many times when people take the advice too superficially.
Re: Things we've learned about building products
#518. Instead, forcing PRs into day of work unit, it is better to be minimum testable increment. Some features just need more work to be tested. Forcing everything into tiny tickets make both planning tedious and often introduce bugs in half finished features.
22. I saw design system fail in many companies. It is very hard to get right people and budget for this to succeed. For most startups are better to pick existing UI toolkit and do some theming/tweaking.
27. I disagree, If you put Product manager as gatekeeper to users you will transform the organization into a feature factory. Engineers should be engaged with users as much as possible.
Re: Things we've learned about building products
#6Sorry, what "successful products"? And I have to say that "Technical Content Marketer " is one of the most dubious job titles I have ever seen.
On their homepage, they have their own logo in the section listing companies that use their products. I mean, if you dogfood it, great, but it doesn't exactly instill confidence if you have to reach for your own company to fill out the list.
Re: Things we've learned about building products
#7Sorry, what "successful products"? And I have to say that "Technical Content Marketer " is one of the most dubious job titles I have ever seen.
On their homepage, they have their own logo in the section listing companies that use their products. I mean, if you dogfood it, great, but it doesn't exactly instill confidence if you have to reach for your own company to fill out the list.
They have customer testimonials here which have more companies than the front page: https://posthog.com/customers
Re: Things we've learned about building products
#8This list mentions A/B testing a few times and it's worth noting that A/B testing is great but it's not free. I've seen a nontrivial number of smart engineers get bogged down in wanting to A/B test everything that they spend more time building and maintaining the experiment framework than actually shipping more product and then realizing the A/B testing was useless because they only had a few hundred data points. Dat…
It probably helps that one of PostHog's core products is an A/B testing framework, so it's much easier for them to iterate on it internally for what they need to A/B PostHog. Even when you already have a best in class A/B testing framework though, I agree—A/B testing too much or waiting too long for "more data" to make decisions can slow down momentum badly for features that should be no-brainers.
Re: Things we've learned about building products
#9There are companies out there that probably do none of these things and are x1000 more successful from a revenue or market cap perspective. Seems like the biggest successes are simply being at the right place at the right time and not being a complete idiot. Nobody wants to hear that though.
Re: Things we've learned about building products
#10This list mentions A/B testing a few times and it's worth noting that A/B testing is great but it's not free. I've seen a nontrivial number of smart engineers get bogged down in wanting to A/B test everything that they spend more time building and maintaining the experiment framework than actually shipping more product and then realizing the A/B testing was useless because they only had a few hundred data points. Dat…
A/B testing is also high risk: a good test produces valuable data, a bad test produces harmful data. A company that does no testing is better off than a company that does bad testing. Many people treat product decisions made based on test results as unimpeachable, whereas they treat product decisions made on a hunch with a healthy skepticism that leads to better outcomes.