9 ms·
Things we've learned about building products
- zabzonk 2y agoSorry, what "successful products"? And I have to say that "Technical Content Marketer " is one of the most dubious job titles I have ever seen.
- Etheryte 2y agoOn 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.
- hnthrow90348765 2y agoThey have customer testimonials here which have more companies than the front page: https://posthog.com/customers https://posthog.com/customers
- Centigonal 2y agoWe use PostHog for site analytics - it's a good product. IDK about popularity, but it's a joy to use.
- tene80i 2y agoSeems like a perfectly good description of someone whose job it is to achieve marketing goals by creating content for a technical audience.
- sergiomattei 2y ago[flagged]
- dang 2y agoPosthog is pretty successful! But since it isn't strictly necessary, perhaps we can make this thread more meaningful by removing success from the title above.
- zabzonk 2y agoWell, I'd never heard about it before today, but that may be just my bad, as I'm not really much into web stuff. But when I see something like this (from the top of their website): > The single platform to analyze, test, observe, and deploy new features my reaction is "Wha?" But what the hell - though I do think the job title is bad, but then I've had a few of those myself.
- dang 2y agoI never let startups get away with "The" on Hacker News when I see it. I always replace it with "A" :)
- dlisboa 2y agoThey list a few products on their home page: https://posthog.com/products https://posthog.com/products I've used PostHog and it's pretty good. I don't know if I'd classify all of those as different products, you rarely want one of those without the other.
- cjs_ac 2y ago> 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.
- kevmo314 2y agoThis 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.
- nightpool 2y agoIt 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.
- abxyz 2y agoA/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.
- pkaler 2y agoAgree! Most orgs should just be shipping features. Before starting an Experiment Program teams should be brainstorming a portfolio of experiments. Just create a spreadsheet where the first column is a one-line hypothesis of the experiment. Eg. "Removing step X from the funnel will increase metric Y while reducing metric Z". And the RICE (Reach-Impact-Confidence-Estimation) score your portfolio. If the team can't come up with a portfolio of 10s to 100s of experiments then the team should just be shipping stuff. And then Experiment Buildout should be standardized. Have standardized XRD (Experiment Requirements Doc). Standardize Eligibility and Enrollment criteria. Which population sees this experiment? When do they see it? How do you test that bucketing is happening correctly? What events do analysts need? When do we do readouts? That's just off the top of my head. Most orgs should just be shipping features.
- Chyzwar 2y ago18. 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.
- scottishbee 2y ago27. I don't think you do disagree. Read point 29: Hire and rely on product engineers. They have full-stack technical skills needed to build a product along with customer obsession. Yes, this means they need to talk to users, do user interviews, recruit tests for new features, collect feedback, do support, and respond to incidents.
- intelVISA 2y ago> skills needed to build a product along with customer obsession So a disempowered founder-lite? What's their incentive?
- abc-1 2y agoThere 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.
- dowager_dan99 2y agoI always look for the post with the "success formula" in this situation and can never find it, but luck and timing are components. Also skill, resourcing, execution, and what I'll call "grit". The ratio is not defined but you need components of each.
- light_triad 2y agoSure luck plays a role. There are techniques to increase your odds of getting lucky though. Sam Altman argued a startup's chance of success is “something like Idea times Product times Execution times Team times Luck, where Luck is a random number between zero and ten thousand” A lot of the success in startups is not due to getting the initial idea right, but what founders do once they realize that their initial idea is wrong.
- deleted 2y ago[deleted]
- ozim 2y ago"Your website is the first impression your product is making" - unless your company does not operate in market where no one cares about your website. We get serious leads only via networking of our C-levels and sales no customer cares about our landing page and leads when we cared about landing page were not serious and waste of time.
- AznHisoka 2y agoYep, I really don’t want to read any articles from any company that built their success during the SaaS greenfield period from 2008-2016. Plus, you already have had the brand and market share to built even more upon that foundation. Now if you’ve built something big that grew in the past few years organically, there’s more to learn from that success.
- light_triad 2y ago> If you’re going to pivot, make it big. This is a great point. I've seem teams apply lean startup by testing -> changing something -> testing -> changing something -> testing ... The problem is that the changes are so small that statistically you end up testing the same thing over and over and expecting different results. You need to make a significant change in your Persona, Problem, Promise, or Product to (hopefully) see promising results.
- deleted 2y ago[deleted]
- apsurd 2y agoThese are ok. They're great to highlight the surface area of product building. But the list is very biased from an analytics and testing perspective because posthog product is analytics and testing. Capturing analytics is a no brainer. however, most data in most products at most companies starting out just fundamentally does not matter. It's dangerous to get in the habit of "being data driven" because it becomes a false sense of security and paradoxically data is extremely easy to be biased with. And even with more rigor, you get too easily trapped in local optimums. Lastly, all things decay, but data and experimentation runs as is if the win is forever, until some other test beats it. It becomes exhausting to touch anything and that's seen as a virtue. it's not. Products need vision and taste.
- srameshc 2y agoI was always very passionate about programming and startups or small team/co, but I never even got to the first round because of my undergraduate degree. I think I would have tried hard given an opportunity and worked with lot of discipline and passion. So now I have my own small team and I try to see if someone who doesn't have the right background but still willing to learn and is passionate about building stuff. It is probably not the idea of the author and he is right in his approach as it has been established, but I will test and see if what I am trying will work or not.
- hk1337 2y ago#2 and #3 are sort of symbiotic. If you have a bad hire, then it's going to be difficult to give them autonomy.
- the__alchemist 2y agoThought on this one: > Trust is also built with transparency. Work in public, have discussions in the open, and document what you’re working on. This gives everyone the context they need, and eliminates the political squabbles that plague many companies. This seems prone to feedback loops; it can go both directions. If there are political squabbles, discussion may be driven private, to avoid it getting shut down or derailed by certain people.
- MrLeap 2y agoI've seen this. Takes management vigilantly guarding the commons from excessive drive bys and divebombs. It takes a lot less energy to throw shit than it does to clean shit. There's infinite signals. Big egos take a lot of energy to repel and redirect to maintain it. I think it's absolutely worth it when it's possible, but yeah. You wouldn't think so until you've done it, but it's really hard to get 6+ adults together where everyone's primary goal in that team is to make a thing. Seems like there's always one or more people who want to peck others, build fiefdoms, hold court.
- bilater 2y agoThe problem with having such a specific, prescriptive formula for success is that it never actually works out that way. Sure, there are high-level principles, the PostHog team executes brilliantly, and I love the product, but I think we're really bad at connecting the dots on what actually made something successful. Instead, we assign credit to random things just to make it all make sense. A lot of times, it's the equivalent of saying, "Bill Gates eats this cereal for breakfast, so if I do that, I should become a billionaire too."
- GoToRO 2y agoFirst you get the success and then you write the formula. Easy.
- phillipcarter 2y agoI know this is not related to the article, which is great, but I am wondering how long "posthog" is going to be the name of this company given what "post hog" means.
- skyyler 2y agoIn the first image in the article, what is a "SuperDay"? Is this like a trial day where you're invited to do a day of work for free?
- adamgordonbell 2y agoThey pay you for it, but it is a trial work day. Story time. I interviewed for a job at posthog. I knew that I really loved their communication style. But I hadn't used their product and didn't know a ton about them except that their writing is fantastic. The 'product for engineers' focus that they is cool but when I had an interview, it was clear that I wasn't a 'product for engineering' person. When they proposed the Super Day. I was like, I'm not sure because it's awesome to get paid for a day, but it's also not an unstressful event. And I sort of said I had some more questions before we moved on to the Super Day. And they basically just said: we don't think it's going to work out. It was actually a pretty positive experience. I think that they correctly assessed the situation pretty quickly and my hesitation was a real signal to them. (This is my recollection - I could have the details wrong.) But yeah, super day is a day of very structured work in the role that they setup. And its paid.
- rapfaria 2y ago> And I sort of said I had some more questions before we moved on to the Super Day. > And they basically just said: we don't think it's going to work out. Ouch, so their tight-knit, no-shortcuts hiring process is only thorough for them, not for the engineer applying.
- adamgordonbell 2y agoPerhaps, but it wasn't a bad experience. I've come to value hiring processes and I guess employers where they known how to swiftly make decisions.
- kayo_20211030 2y agoGetting paid is, at least, fair. Everyone has some skin in the game. Pretty impressive.
- fdlaks 2y agoWow. 900 applications down to 10 "SuperDay" participants down to 4 hires. All to work at.... posthog. What a depressing statistic. This felt like a humble brag to help make their point about hiring good talent and how many people want to be a hogger (or whatever they call people that work there) but this just really highlights how brutal the job market is. Yes the market is also flooded with unqualified applicants and or bots that will apply to any job listing thats posted, but still this is ridiculous. I really feel bad for the 6 people who had to endure the technical interview AND THEN were given the honor of attending the "SuperDay" which sounds like a full day of at least 5 interviews, 2 - 3 being technical, and still got rejected. Not sure what the technical interview is like at posthog, but assuming this is just an hour phone screen those 6 people still probably had more than 7 hours devoted just to interviewing at this place just to get rejected. That's not including any time spent preparing for interviews or anything else either. There must be a better way to do interviews. Posthog is not Google, Posthog (or any other startup) does not need to hire to the same standard that Google does. Let me know when you're on par with Google in terms of revenue or benefits or prestige, or anything else really that Google offers then sure I will jump through as many hoops as you want for the interview. Until then, hard pass.
- rbaudibert 2y agoSuperday is a paid day of work with a 30-minute talk with a founder + a 30min review about the day with an engineer
- fdlaks 2y agoAh ok my mistake, so that’s 8 hours including the review and discussion portion for the super day, then let’s say 45 minutes for the technical interview so 8 hours and 45 minutes of time spent interviewing at a minimum.
- sibeliuss 2y agoHaving attended a SuperDay, I can hands down state that their interview process is the best I've ever had (didn't get the job tho, which was probably for the best at this phase of life). Designed to perfectly lift signal and minimize noise, for what they're trying to achieve. Don't change a thing PostHog.
- deleted 2y ago[deleted]
- biglost 2y agoWait, i wouldnt hire someone who is ok spending so many hours after the first few hours, it shows me that he or ave can't handle the sunk cost trap and will fall again and again. But ok, that's my wr9ng opinion about this
- thesurlydev 2y agoI just want to say this blog is one of the best engineering/product blogs out there. I’ve been an avid reader for a while and always learn something. Very inspirational.
- seasluggy 2y agoAll that for product analytics? Lmao
- hackburg 2y ago[dead]
- nestoras_design 2y ago900 applications down to 4 hires looks like a small percentage to be optimistic about the market...
- pklien 2y agoA lot of psychological safety here. This is fundamental for team success.
- gwbas1c 2y ago> Rely on trust and feedback, not process Process is important when work is handed off from one team to another team. Any company with a non-trivial product will have a non-trivial team size; and thus it'll need to standardize how people hand off work. It doesn't have to be onerous: The best processes are simply establishing boundaries so lazy people don't throw their work over to the next person. (IE, "I won't work on a bug without steps to reproduce and an unedited tracelog that captures the failure" is a good boundary.)
- bleuwa3 2y ago[dead]
- ungreased0675 2y agoMaybe a hot take, but I think it’s better to build a successful startup with developers of average skill, intellect, and competence. You don’t need to obsess over finding genius level savants, unless the startup is a serious deep tech company. SaaS products will be fine with normal developers. Set up a process so you’re iterating and learning quickly, and it will be ok. I’d be surprised if any startup failures were due to a dev team not being absolutely cracked. It’s always something like poor sales, PMF, refusal to pivot, lack of focus, etc.
- tmarice 2y agoPosthog's newsletter is one of the few I re-subscribed to after a general newsletter purge, top content. Regarding the superday controversy: my best interviewing experience was a conversational technical interview followed by a paid-either-way-the-decision-went 2 week project. I did quite a bit of competitive programming so leetcode interviews are not a dealbreaker for me, but I feel there's just too much at stake for 1-2h coding exercise, and projects allow you to showcase all of your skills, not just speedcoding.
- anastasiapenova 2y ago[dead]
- sebastianowen 2y ago[dead]
- DonCalloway 2y ago[dead]