Three months after raising their Series A, a founder I know spent $400K building an enterprise dashboard. Their customers were all small businesses. Nobody had an enterprise contract. Nobody was even close.
Why'd they do it? A VC mentioned enterprise during their last board meeting. Not as a directive. Just mentioned it. The founder heard that mention and turned it into their entire Q2 roadmap.
That's the pattern. Someone shares what matters to them, and we absorb it as truth. Their priority becomes our priority. We don't even notice it happening.
The advice absorption problem
You can track this in board meetings. Count how many action items come from actual problems versus things that got mentioned once. The ratio is about 30/70. Most of what founders commit to building comes from what someone else said, not what the business needs.
I watched a founder rework their entire go-to-market strategy because an advisor said "you should really think about product-led growth." The advisor ran a PLG company. Of course they think everyone should do PLG. That's their world. Their priority.
The founder's actual problem was that their sales team kept losing to the same competitor. Product-led growth wouldn't fix that. Better competitive positioning would. But they spent six months rebuilding their onboarding flow instead.
When someone else's experience becomes your roadmap
Here's what happens. Someone successful shares what worked for them. You're sitting there, trying to figure out your own mess, and their certainty feels like a map. They scaled to 100 people doing X. You should probably do X too, right?
Except they scaled to 100 people in a different market, with different timing, solving a different problem, with a different team. The thing that worked for them might be completely wrong for you.
Last year a founder told me they were switching to usage-based pricing. I asked why. They said a portfolio company at another fund had "crushed it" with usage-based pricing. I asked about their own customers. Turns out most of them wanted predictable costs. They preferred annual contracts. But this founder was ready to rebuild their entire pricing model based on someone else's win.
The board meeting trap
Board meetings are particularly bad for this. You've got 4-6 very smart people in a room, all trying to be helpful. Each one has a portfolio of 20+ companies. They see patterns. They share those patterns.
"Company X just hired a VP of Sales and it changed everything."
"Company Y doubled down on content marketing and saw 40% growth."
"Company Z restructured their engineering team around squads."
All true. All relevant to those specific companies. Not necessarily relevant to yours.
The problem is the phrasing. "Changed everything" and "saw 40% growth" and "restructured" all sound like answers. When you're in the middle of the mess, anything that sounds like an answer gets magnetic.
I've seen founders leave board meetings with 12 new initiatives. None of them tied to the thing that's actually broken. All of them reflecting what worked somewhere else.
The customer request version
This happens with customers too. Your biggest customer asks for a feature. Not just asks—needs it. Says they can't renew without it. You bump everything else and build it.
Then you ship it. They use it twice. Turns out what they actually needed was better onboarding for their team, but they phrased it as a feature request because that's how enterprises communicate.
You just spent eight weeks solving their stated priority instead of their actual problem. Their priority became yours, even though it wasn't real.
I know a founder who built five features in a row that came from customer conversations. All five got used by the customer who requested them. None got used by anyone else. A year later they had to deprecate all five and explain to those customers why.
What they should have done was watch for the pattern across customers. One customer asking for something is their priority. Ten customers hitting the same problem is your priority.
How to tell the difference
There's a test. When someone shares what worked for them, ask: "What problem were you solving?"
If they can't articulate the specific problem, just the tactic, it's probably their priority, not yours.
"We hired a VP of Sales" isn't a problem. "Our AEs kept discounting too much and we needed someone to own the process" is a problem. If you don't have that specific problem, you don't need that specific solution.
When a VC says "you should really think about enterprise," the question is: what problem does enterprise solve for us right now? If the answer is "we're saturating SMB and need larger contracts to hit our growth targets," maybe enterprise makes sense. If the answer is "a VC mentioned it," that's not your priority.
Same with customer requests. "We need better reporting" isn't specific enough. Push on it. What decision are they trying to make that they can't make now? What's broken about the current flow? Half the time they'll realize they actually need something different. The other half, you'll understand the real problem and can solve it properly.
The cost of borrowed priorities
This stuff compounds. Every time you adopt someone else's priority, you deprioritize something that actually matters to your business. Your roadmap fills up with things that worked elsewhere. Your actual problems stay unsolved.
Three quarters later, you're behind on revenue, your product has 15 half-used features, and you're not sure why nothing's working. It's because you've been solving everyone else's problems instead of your own.
The founders who move fastest have a different thing. They listen to everything, then filter ruthlessly. They're not rude about it. They just have a clear picture of what problem they're solving this quarter, and if advice doesn't map to that problem, it goes in a doc somewhere for later.
I started watching for this in portfolio companies. The ones that ship consistently have short roadmaps. Three to five things, all tied to a specific problem the business has right now. The ones that thrash have roadmaps with 20 items, each from a different conversation.
What actually works
Keep a problem list. Not a feature list. A list of the things that are actually broken in your business right now.
When someone gives advice or makes a request, map it to the problem list. If it solves something on the list, consider it. If it doesn't, say "that's interesting, but it doesn't map to what we're solving right now."
Most people respect that. The ones who don't weren't giving you good advice anyway.
Your job is to solve your specific problems with your specific constraints for your specific customers. Not to implement what worked at Stripe or what your biggest customer mentioned once or what a VC saw work at another portfolio company.
Their priorities made sense for them. Yours need to make sense for you.
