How do you decide which startup advice to ignore?
by•
There is so much advice for founders now that a lot of it starts to contradict itself.
Launch fast, but don’t launch too early.
Talk to users, but don’t build everything they ask for.
Focus on one thing, but keep testing channels.
Build in public, but don’t become distracted by content.
I’m curious how other founders filter this.
When you hear advice that sounds reasonable, how do you decide whether it actually applies to your product or stage?
61 views
Replies
Source matters more than the advice itself. If the person giving it raised VC money and you're bootstrapping, their playbook doesn't apply to you. I always ask "what was YOUR situation when this worked?" before taking anything seriously. Most advice is just someone pattern-matching their one experience into a rule.
@antwon_randolph2 Exactly. The context behind the advice matters a lot. The same advice can be smart for a VC-backed team and completely wrong for a bootstrapped founder trying to stay lean.
I always fall back to first principles. If the advice does not allow for deeper tought (if its too broad/vague/anecdotal) I generally ignore it. If it's narrow and with an attached argument to it, then it's interesting to think it throught. Always interesting if it's data backed!
For example if someone wins the lottery and advises you to play because it worked for them, that's a bad advice for sure. Even if there are 1000s of lottery winners saying the same thing. But if one annonymous person explains the statistics/math of lottery P&L and advises not to do it, thats excellent advice because its backed up!
@code402 That’s a really good way to frame it.
I agree, broad advice without context is usually dangerous because it sounds true, but you don’t know what situation it came from. The advice that’s actually useful usually has some reasoning behind it, or at least clear assumptions.
The lottery example is perfect. Outcomes alone can be very misleading without understanding the process behind them.
I really relate to the second point "talk to users, but don't build everything they ask for."
We're building a productivity product now and many of our features have come directly from user feedback and suggestions. But at the same time, we've learned that we can't take every idea because users have different workflows and different needs.
What has helped us is regularly picking the ideas that come up most often, then bringing them back to community for focused discussion or voting. It helps us understand not just what users want, but why they want it, and whether it fits the product direction at the current stage.
@evakk That’s a solid approach.
I like the part about bringing repeated ideas back to the community, because it prevents feedback from becoming a simple “most requested = build next” system.
Understanding why users want something is usually more useful than the request itself. Sometimes the feature they ask for is just their version of a deeper problem.
The contradictions are real but most of it's because the advice is collapsed by stages, so people are compressing "What worked for me in the beginning" vs. "What saved me at launch" in the same sentence and before too long it's passed around like universal law.
I'd ask what kind of failure the advice is protecting against. "Launch fast" is a correction for the founders who keep tweaking this and that and never get a signal. "Don't launch too early" is a correction for those who ship work full of bugs and burn their one shot with the best audience. Both of them mare true, just aimed at different types of people When you get advice like this, I'd ask "what went wrong for the person giving this advice," then ask yourself if that's the trap you're in right now.
Likewise I'd match the advice to what's actually holding you back. "Talk to users" matters the most when you're trying to understand the problems they're facing. "Don't build everything they ask for" is when your focus goes toward what you should be prioritizing. The advice itself didn't change, but the thing holding you back the most, did.
Most of the advice you're being given is a reaction to a certain mistake but framed as if it's a rule. You have to reverse-engineer the mistake and decide if that's something you're really making while you're on your specific path.
@kicksaascopy This is a really good way to look at it.
I like the idea that most advice is a reaction to a specific mistake, but gets repeated later as if it applies to everyone.
“Launch fast” and “don’t launch too early” sound contradictory, but they’re really solving two different problems. Same with user feedback — sometimes you need more of it, sometimes you need to stop letting every request pull the roadmap around.
The question “what failure is this advice protecting against?” is probably the best filter here.