The problem with advice isn't the advice.
People love tearing down advice. “Move fast and break things” gets mocked constantly. “Fail fast” has become a punchline. Every few months, someone writes a post about why some well-known piece of startup wisdom is actually terrible. Here’s the thing: most of that advice is great. The problem is that people take it literally, apply it out of context, or twist it into something the original person never meant, and then tear it apart. You can rip any advice to shreds if you try hard enough. That doesn’t mean the advice was bad. It usually means the nuance got lost somewhere along the way.
My general principle: when I hear advice from someone else, I don’t ask “is this right or wrong?” I ask “how do I make this my own?” If I need to tweak what they said to fit my interpretation, make it more relevant, or align it with how I see the world, I do that. Advice is a starting point, not a destination.
Here are some of the most common pieces of startup advice that I think people have gotten wrong, not because the advice is bad, but because the nuance got lost along the way.
“Move fast and break things.”
I love this advice. I’m genuinely sad that everyone’s abandoned it.
When Zuckerberg made this Facebook’s internal motto, the problem it was solving was real. People were so scared of breaking anything that they couldn’t move fast. All he was saying was: you have permission to make a mistake. He wasn’t literally telling people to go break the app and make it stop working. That’s an asinine interpretation, and it’s what people have turned it into so they can write hot takes about why it’s wrong.
Here’s what “break things” actually looks like in practice. It’s permission to ship something imperfect, even if you haven’t solved every edge case. You’re taking a calculated risk that some users in certain scenarios might run into a problem, maybe even a bug or what I’d call a UX flaw. If that’s going to affect less than 1% of your audience, and you’re small and need to move fast, it makes sense to release it and take the chance. Nine times out of ten, those edge cases never come up.
The key is that you know the edge cases. It’s not about blindly shipping something and hoping nothing blows up. It’s about making a conscious decision not to address every known edge case before you release. You accept that you might have to manually intervene for some users, or that a few people might drop out of a conversion flow. You ship anyway, knowing the trade-offs.
And when something does come up, including edge cases you never thought of, you iterate. You evolve the feature based on real feedback from real users, feedback that never would have come in if you’d spent another month trying to think of everything before shipping. If it’s truly mission-critical, like people’s bank account balances, then yes, do the work and ship it right. But most things aren’t that.
The advice created a real cultural shift in startups. We all started moving faster, taking more risks, being less afraid of shipping something imperfect. And because we changed, the advice now sounds dated. It’s being given to a completely different audience than the one that originally needed to hear it. The rest of us already internalized it.
Even Facebook updated the motto to “move fast with stability.” Fine. But the original advice did what it was supposed to do. It gave a generation of builders permission to take chances.
In practice, what I do is ask two questions before shipping: is this mission-critical, and what percentage of users will actually hit this edge case? If the answer is “not mission-critical” and “very few,” I ship it and move on. If something does break, I fix it fast. That’s the real spirit of this advice.
“Design doesn’t matter until you have product-market fit.”
This one is more nuanced than people give it credit for.
When people say “design doesn’t matter early on,” I think what they actually mean is: don’t invest heavily in custom designs, polished UIs, and bespoke design systems when you’re still figuring out if your product solves a real problem. And I think there’s truth to that. It’s like putting a $5,000 set of rims on a car prototype when you don’t even know if the engine runs yet.
But here’s where people get it wrong. They hear “design doesn’t matter” and use it as an excuse to have a terrible user experience. Those are two completely different things. In my experience, UX matters even when everything else is rough. If your product is confusing or frustrating to use, it’s hard for product-market fit alone to overcome that. Functionality creates value, but design can’t get in the way of delivering that value.
There’s also a distinction between product design and brand design. I’ve found that a strong brand matters earlier than people expect, because early on you don’t have a lot of functionality to show off. A strong visual presence helps cover the gaps. It makes you look like a real company before you fully are one.
I see design as a spectrum that should match the maturity of your product. You don’t need everything custom from day one, but clarity matters, and looking like you give a damn goes a long way. Craigslist is one of my favorite examples here. The app is ugly. Nobody would argue otherwise. But they solved a real problem, and the UX never got in the way. That’s the bar. Not beautiful. Just clear.
“Just ship it.”
I say this all the time, so I can’t call it bad advice. But like all of these, it needs context.
Every feature has a tipping point where it goes from being too incomplete to creating real value. That’s the moment I want to ship. Not before, not long after. When you go beyond that point, you start adding bells and whistles that would be better informed by actual user feedback and real-world data.
The problem is that “just ship it” means different things to different people. For the founder who’s been perfecting the same feature for three months, it’s exactly the right advice. For the founder who’s already shipping half-baked work with no quality bar, it’s the last thing they need to hear.
This is what I mean about advice needing to be interpreted for the person receiving it. The same words can be great advice for one person and terrible advice for another, depending on who they are and what they’re struggling with.
“Fail fast.”
This is in the same family as “move fast and break things.”
Eric Ries popularized this idea in The Lean Startup, and the original concept was simple: validate your assumptions quickly. Don’t spend a year building something nobody wants. Test it, learn from it, and if it’s not working, move on to the next hypothesis. Another way to say it: just try a lot of things as fast as you can. That’s not as catchy, but it’s what the advice actually means.
Nobody was telling you to build a failure on purpose. It’s silly to even imply that’s what the quote means. They were telling you to take risks, run experiments, and not be afraid of being wrong. The advice was about speed of learning, not speed of quitting.
What this looks like in practice: set a short time horizon for testing an idea. Build the leanest version you can. Define what success looks like before you ship it. If it doesn’t hit that bar, learn from it and move on to the next thing. That’s failing fast. It’s not quitting. It’s being disciplined about where you spend your time.
“Listen to your users.”
This one feels obvious to me. Getting feedback, listening to the market, seeing where you’re getting traction — I don’t see how you build a good product without that.
People love to cite the Henry Ford quote: “If I had asked people what they wanted, they would have said faster horses.” It’s probably misattributed (there’s no evidence Ford actually said it), but the idea is powerful and gets used constantly as a reason to ignore user feedback.
Here’s what gets lost though. The users wanted faster horses. Ford could have given them faster horses and built a fine business. Instead, he decided to build the automobile. Both would have solved the underlying problem: people wanted to get places faster. The horse part was their solution. His job was to understand the need and figure out a better way to address it. That’s listening. He didn’t ignore what they wanted. He interpreted it.
The people who tear this advice down are confusing “listen to your users” with “do whatever your users tell you to do.” Those are completely different things. One is about gathering signal. The other is about abdicating your judgment.
What I try to do is separate the request from the need. When a user says “I want feature X,” I ask why. What problem are they actually trying to solve? Sometimes the feature they’re asking for is the right answer. Sometimes there’s a simpler or better solution they haven’t thought of. But you only get there by listening first and interpreting second. I wrote more about this dynamic in my post on why founders struggle to stay focused, where the loudest feedback often isn’t the most important.
“Data-driven everything.”
There’s definitely a balance to data.
What I’ve found in my career, at a much higher rate than I would have expected, is how many people don’t actually know how to interpret data. They don’t understand how data can misrepresent things. They get tricked by their own numbers because they’re looking for an answer they want to find, and they can usually find it.
That’s the double-edged sword of data. You can use it to tell almost any story you want. I do it all the time in marketing. But that’s not necessarily the full truth. We’ve seen this play out in the political environment too. People on every side are using real numbers, but they’re cherry-picking the ones that tell the story they want to tell.
And then there’s A/B testing, which I think is wildly overleveraged. People run tests that any data scientist would know are invalid because there’s no real control, too many variables changed at once, not enough sample size. But they go with the “winner” anyway and call it data-driven. That’s started to feel less like data-driven decision making and more like confirmation bias with a dashboard.
Data is an important component of making good decisions. But there’s a balance. Some of the best product decisions I’ve seen were taste calls that no A/B test would have validated.
What I try to do is use data to inform decisions, not make them for me. Look at the trends. Understand the behavior. But when the data is inconclusive or the sample is too small, trust your judgment and your understanding of the user. And when someone presents data to win an argument, ask what data they’re not showing you. That’s usually where the real story is.
“Hire fast, fire fast.”
Mark Suster popularized this one in a 2011 TechCrunch article, and I completely disagree with the first half of it.
I had a former boss early in my career who forced me to raise my hiring bar. I was interviewing designers, and maybe four or five interviews in, I wanted to hire one of them. My boss wouldn’t let me. He kept challenging me on different aspects of the candidate’s strengths and gaps. I remember being pissed. I was 32, I had just become a manager, and I thought, “I was hired to do this job. Let me make my own decision.”
He wouldn’t budge. I had to go back and interview way more people. And because of his feedback, I ended up raising my requirements without even realizing it. I was looking for things I hadn’t thought to look for before. I ended up building one of the strongest teams I’ve ever built at that company.
Since then, I’ve learned to be extremely patient when hiring. I will interview and interview and interview. I don’t care how long it takes. Because when you onboard someone and invest weeks or months ramping them up, if you made a mistake, there’s nothing fast about fixing it. You can hire someone in a day, but you can’t onboard them in a day. You’re committed to seeing if they can perform, and that takes time no matter what.
“Fire fast” I agree with more. Being decisive about when it’s time to move on from someone is really important. I’ve worked with executives who were unwilling to have the hard conversations, and it dragged down morale across the whole organization.
But the advice as a package, “hire fast, fire fast,” implies that hiring is a low-cost, easily reversible decision. It’s not. Take your time on the front end.
“Say no to everything.”
Steve Jobs said “innovation is saying no to 1,000 things.” Warren Buffett said “really successful people say no to almost everything.” Saying no is important. There’s way more you have to say no to than you can say yes to, and being able to do that without offending people is a real skill.
But rather than defaulting to no, I prefer to say maybe. Not as a way to avoid the decision, but as a way to capture the idea. Instead of rejecting it outright, I’ll say “that’s interesting, let’s put it in the backlog.” I log it as an idea or an epic, and then every few months when I’m reevaluating priorities, I look at everything that’s accumulated. Sometimes the thing I would have said no to six weeks ago suddenly makes sense because the business has evolved, or the market shifted, or we got new feedback that changes the calculus.
Staying focused is a huge challenge for startups, especially for executives. I wrote about this in my playbook for managing up, where a lot of the techniques are really about finding ways to say “not yet” without saying “no.” The skill isn’t in saying no. It’s in knowing when to say not yet.
My general feeling is that most of the advice on this list is genuinely great advice. The problem is that people want everything to be black and white, and advice doesn’t work that way. If you take any of these literally, you can rip it apart. But I don’t think that’s a useful exercise. The work is in figuring out how to make it useful for your situation.
The best advice I’ve ever gotten wasn’t the advice itself. It was learning to take what resonates, adapt it to who I am and what I’m building, and leave the rest. I’ve learned to make the rules my own. That’s the approach that’s worked best for me.