Hard Truths About Building Products
Throughout my career, I've watched smart people make the same mistakes over and over again when building products… and I’ve made them myself. These aren't edge cases or rare missteps—they're systemic delusions that kill products, burn cash, and waste years of effort. If you're in product development, you've probably seen many of them.
Big Client Logos Signal Success
Landing a Fortune 500 logo feels like validation. It's not.
If you want a real predictor of whether a small private tech company will succeed, divide annual revenue by the number of unique customers. You want this number to be as LOW as possible. Better yet: divide new (non-renewal) revenue by new unique customers.
Why? A large number of clients each paying a small amount for a valuable product is a scalable model. A handful of clients paying exorbitant fees that stick around only until their contract expires means lumpy revenue, unpredictability, and no scalable growth engine. It means you're selling solutions and promises rather than products and value.
What about ARPU? Yes, it very close to being the inverse of what I’m describing but it’s an operational health metric, not a predictor of success.
Those big logos on your website? They might be masking a fundamentally broken business model.
One Client Bought It, Others Will Too
You sold a solution that [might have] satisfied the needs of a single client over a contractually obligated period. Productizing it doesn't mean others will buy it. They almost certainly will not.
If they do, it'll end up being a solution requiring tons of customization rather than a scalable product. Often, we fail to truly understand why that one client wanted this specific thing—clients rarely divulge all of their reasons—and because we never understood their needs in the first place, we fail to understand why others don't need it.
Markets, needs, and expectations change rapidly. What one client paid for two years ago is not a product roadmap.
Build-to-Sell Works
You cannot build a product in a vacuum and start selling it immediately. You do not have all the answers. Nobody does.
Product development is an iterative process requiring consistent pivots and repositioning based on user analytics, real feedback, and an evolving understanding of markets. You don't build something this year, create a pitch deck, unleash your sales team, and start selling it next year for $500k. It just doesn't work that way.
The companies that win iterate faster than everyone else. The ones that lose build in isolation and wonder why the market doesn't care.
Synergies Will Emerge
Companies acquire other companies for many reasons—talent, IP, market access, or just to eliminate a competitor. But the belief that combining two product lines will magically create value greater than the sum of their parts is almost always wrong.
I've seen this play out firsthand: a company acquires a handful of struggling products thinking that their core technology will suddenly enhance everyone's value proposition. It doesn't. Failing products fail. Bolting a new data source or capability onto a product that couldn't find market fit doesn't fix the underlying problem—it just adds complexity and burns integration cycles.
Platform plays sound great in board decks. In practice, they're a graveyard of good intentions.
IP Shouldn't Go to Waste
If you showed up to a board meeting and said "I think we should build it and then find a market," you'd get a chuckle—they'd assume it was a joke. Otherwise, you'd be relieved of service.
But this happens ALL the time. Companies have a speck of IP, a unique script, a report they used to sell to a handful of clients, and they can't let it go because they're under pressure to grow revenue. So you're forced to "productize" a terrible idea and start the long, painful process of commercializing a hopeless product without a market.
Sunk cost fallacy kills products. Just because you have IP doesn't mean it's worth anything.
Science Sells
Selling a forecast, prediction, or the output of a model is harder than selling a $4,000 vacuum cleaner door-to-door; I know because I’ve done both in my career.
Forecasts are great for internal BI or government organizations, and science is valuable for big pharma and biomed—industries where gigantic budgets and regulatory moats justify the price tag.
It doesn't matter that your forecast is better—or even the ONLY thing available. Clients won't pay enough for the unit economics or CAC to work out. You have to sell value, which comes in many shapes and forms.
"What about prediction markets?" They're not selling science or predictions; they're selling entertainment and endorphins. "What about Anthropic, OpenAI, Perplexity?" They're not selling science either; they're selling utility, knowledge at your fingertips, getting the job done faster and better.
And here's the kicker: if a client IS interested in your forecast that you claim is better than publicly available information, their first comment will be "prove it." Their second will be "I don't agree with it; tell me why it's forecasting that." They will make these same comments repeatedly until they leave.
We’re Smarter Because We Have Data and Technology
There's a dangerous assumption that if you have better data or a smarter model, you can waltz into an industry and build a valuable product. You think: "These people are using spreadsheets and gut instinct. We're smarter than they are. They’ve been waiting for us to show them how it’s done."
Wrong.
Below the surface of every "low-tech" industry is deep domain expertise you don't know about. Decades of institutional knowledge, workarounds, and pain points that have already been addressed—imperfectly, maybe, but addressed. The day-to-day reality of how people actually work is invisible to outsiders.
If you don't have someone on your team who has lived in that world, you're guessing. And guessing is expensive.
Lessons Are Translatable Across Industries
You cannot easily or quickly extrapolate lessons from one industry to another… even though it seems logical and feels natural.
What worked in media doesn't work in agriculture. What worked in fintech doesn't work in logistics. The surface-level patterns might look similar, but the underlying dynamics—buyer behavior, sales cycles, regulatory constraints, incumbent relationships—are completely different.
I've watched teams burn years trying to apply playbooks from their previous industry before accepting that they need to start from scratch.
People Need Your Product
Here's a hard truth: most of the time, people don't actually NEED your product.
They already have a solution. Maybe it's a competitor's product. Maybe it's a combination of spreadsheets, email, and tribal knowledge they've developed over years. Maybe it's a process that's inefficient but good enough.
"Good enough" is an incredibly high bar to clear. You're not just competing against other products—you're competing against inertia, switching costs, and the cognitive overhead of learning something new. If your product isn't 10x better at the ONE thing that matters most to them, you're not going to displace what they already have.
Your Product Is Unique
It's not.
Even if your technology is novel, the problem you're solving probably isn't. Your prospects have seen pitches before. They've tried other solutions. They've been burned by vendors who promised transformation and delivered headaches.
Thinking you're special leads to lazy product marketing and weak positioning. The companies that win understand exactly how they're different—and more importantly, how they're perceived as different by buyers who've heard it all before.
You Can Innovate Without an Autonomous Team
You cannot develop products that get traction without a fully autonomous, cross-functional team. Period.
I'm talking about a pod that includes product, product marketing, leadgen & content creators, engineering, science (if applicable), and sales—all working together collaboratively with a shared understanding (product vision), and the authority to make decisions. Not a matrix organization where everyone reports to different VPs with competing priorities. Not a "tiger team" that meets weekly but has no real power.
Innovation requires speed. Speed requires autonomy. Autonomy requires trust and a team structure that actually enables it.
If your "product team" is really just a PM writing tickets that get prioritized against sixteen other initiatives by a project manager who reports to someone else, you don't have a product team. You have a suggestion box.
It Has to Be Better Than the Competition
Inferior products with dedicated, engaged product marketing people on the team will ALWAYS get more traction than better products that don't. I’ve already written about it here.
You Can Price Based on What You Need to Charge
It’s obviously not rational to base your pricing on internal demands and constraints but it gets forced on PMs all the time.
"We need to charge $250k to cover customer acquisition costs and provide healthy margins." Fine—but the market doesn't care about your cost structure. Buyers pay based on perceived value, competitive alternatives, and budget constraints. Not your P&L.
Immature products can sell. They can get traction. But they rarely generate the type of revenue that executives at larger companies need to justify ongoing development costs or unleashing a direct sales team. If your pricing is a function of what you NEED rather than what the market will BEAR, you're setting yourself up for painful conversations six months from now.
The Bottom Line
Product development is hard. Most products fail. And most of them fail not because the technology was bad or the team was lazy, but because someone believed one of these delusions long enough for it to matter.
The companies that succeed are brutally honest with themselves about what's working and what isn't. They listen to the market, iterate fast, kill bad ideas early, and never confuse motion with progress.
Image by J_Blueberry from Pixabay