Non-obvious behaviors that will kill your startup
Inertia is the default mode of most companies
Welcome to Product for Engineers, a newsletter created by PostHog for engineers and founders who want to build successful startups.
1. Not praising people for day-to-day work
Who is more valuable?
Someone who occasionally does something very visible and noteworthy, or the person who does their job to a consistently high standard every day?
It’s a false comparison, really. They’re both valuable, and they’re not mutually exclusive qualities, but which you praise most often says a lot about your company or team.
Teams that praise highly visible contributions more than day-to-day excellence foster resentment, cynicism, and success theater. Why bother doing your job consistently when conspicuous one-off success is what gets noticed?
Most people don’t nail their jobs every day. Make a habit of recognizing those who do and their success will compound throughout your team.
What we’ve learned: We made “acknowledgments” a core part of our weekly company all-hands. It’s explicitly for thanking people for their work, rather than praising major milestones.
2. Giving mostly positive feedback
This isn’t a contradiction.
It’s important to praise people when they do good work, but a lack of constructive feedback is corrosive.
Remember, it’s human nature to avoid difficult conversations, but our anticipation of them is much worse than the reality.
Constructive feedback, when delivered and received with good intent, is liberating.
Why does this matter?
Inertia is the default mode of most companies – most people, really. The day you stop giving each other constructive feedback is the day inertia becomes the default.
What we’ve learned: Transparency is key. All our small team off-sites include a 360-degree feedback session. Good feedback is based on observations, not emotions. Our SuperDays are designed to see how candidates receive feedback.
3. Taking shortcuts when hiring
Hiring people is hard.
Take this recent example:1
Screening 900 candidates = 15 hours (~1 min each)
86 first interviews = 43 hours (30 mins each)
55 tech interviews = 55 hours (60 mins each)
20 founder interviews = 10 hours (30 mins each)
10 SuperDays (work trials) = 80 hours (8 hours each)
That’s over 200 working hours to hire four people – 200 hours of intense, exhausting time spent on video calls instead of productive deep work.
It’s eventually tempting to accept “good enough”. To suppress your nagging doubts so you can get back to “proper work.” All this hiring is slowing you down!
This is wrong for three reasons:
Working with very talented people is hugely motivating.
Nothing slows you down more than a bad hire who isn’t working out.
What we’ve learned: Focus on whether hires will raise the bar. See everything we've learned about hiring for startups (so far) for more.
4. Not trusting teammates
We’ve all worked with micromanagers, or colleagues who second guess everything. They’re rarely malicious, but it’s impossible to build a successful startup this way.
Startups live and die on speed – it’s the biggest advantage they have against incumbents. A lack of trust leads to bottlenecks. Bottlenecks kill momentum.
Why does this happen? Often it’s because:
You hired someone that doesn’t raise the bar.
You failed to give them constructive feedback.
What we’ve learned: Be decisive when you lose trust in a colleague. When we let people go, we communicate the reasons why to the whole company, and conduct retrospectives on what we could have done better. If someone is surprised when they’re let go, you’ve failed to give them the necessary feedback.
5. Sticking rigidly to plans
People often conflate “good execution” with executing a specific plan. This is a trap.
How many times can you say “we’ll do that next quarter” before you realize you should ship the thing users really care about, instead of the quarterly goal?
Here’s an example from the feature success team2 at PostHog:
In Q3 2024, they decided to focus on making experiments a dedicated product separate from feature flags with its own pricing. It made good business sense3 and it’s something we still want to do.
As the quarter progressed, the team realized that (i) no users were asking us to do this, and (ii) they had loads of ideas and requests that would delight users, and could be shipped faster.
They switched focus, shipping an overhauled UI that made setting up experiments and shipping winning variants to production way easier. Usage and feedback proved this was the right call.
There’s always tension between being opinionated and building what users want. When in doubt, execute based on values and impact, not plans.
What we’ve learned: Judge people on what they ship, how often they ship, and the impact of their work, not on whether they “stuck to the plan.” People who feel like they must stick to the plan won’t bias for impact.
6. Waiting “one more week” to ship something
One more week sounds harmless enough, right? It’s just ONE week.
But this attitude extrapolated out over months or years = way less momentum. The sooner you get something into the hands of users, the sooner you’ll find out:
If it’s something they’ll use and value
How to make it better
Now you can use that extra week to improve your feature based on real user feedback, and you’ll delight users with you quick progress.
Exceptions include:
You’re building some kind of mission critical infrastructure.
Your product is a design-led take on a product that already exists (e.g Linear), where design and polish are the reason to use it over alternatives.
What we’ve learned: Product engineers who can work autonomously are essential, as is a “no design by default” approach so engineers can ship basic UX on their own. We use feature flags to test in production, and we avoid innovating on MVPs, so we don’t get bogged down in minutiae.
7. Not following-up with customers
We bang on about talking to users all the time in this newsletter, but it’s important to remember it’s a two-way collaboration, not a one-way transaction.
When someone gives you feedback about your product, respond with something useful – a pull request, an issue about how you’ll address their problem, or a thoughtful note asking them for more context.
Failing to do so will teach them not to share more feedback in future. If and when you do ship a fix, or the new feature they wanted, let them know.
What we’ve learned: Don’t outsource this to a specific team – make it everyone’s responsibility. Reward helpful users with merch store discounts (also, have a merch store!) and early access to new features. We pull all feedback into a single Slack channel, so everyone sees it.
8. Obsessing over competitors
Any startup that has some degree of success will spawn competitors and imitators. There are two failure modes here:
Doing things because your competitor is doing them.
Not doing things specifically because your competitor is doing them.
They’re extremes of the same problem.
It’s easy to get sucked into believing competitors have some grand insight you’re lacking. “Why are they doing that? They must know something we don’t!”
In reality, companies do things for all sorts of reasons – rational and irrational – that aren’t obvious from the outside.
You shouldn’t ignore competitors, but the decisions you make about your product should be dictated by what makes sense for your users, not someone else’s.
What we’ve learned: The best way to avoid this problem is to have clear values about what you’re building, why, and for whom – see issues on building an ideal customer profile and how we decide what to build.
📖 Box fresh reads, delivered to your inbox
Actionable metrics for mobile apps – Lior Neu-ner
I interviewed 100 DevTools founders and this is what I learned – Jack Bridger
How we built an (actually useful) AI community support bot – Cory Watilo
Words by Andy Vandervell, mechanical pencil enthusiast.
Want to work at PostHog? Read How to get a job at a startup, then head to our careers page – we’re always hiring.
We’ve since split this team intro three dedicated teams for feature flags, experiments, and surveys because of the magic of small engineering teams. We’ll be hiring for these teams soon so, you know, see above.
We find charging for a specific product increases usage because people see you’re taking it more seriously. One of our goals for pricing is to make experiments cheaper, so users can run more of them without fear of running up a big bill.