Technology strategist Marcello Genovese learned a counterintuitive lesson early in his career: the more confident a product team feels, the more danger they’re probably in. Confidence without continuous user validation, he argues, is how promising products turn into expensive failures.
“Talk to your users, do reviews, run user testing,” Genovese explains. “There are plenty of testing platforms out there. Even if you can’t find the right user for your product to test it, sometimes the least likely person helps make your product stronger and gives you a different viewpoint.”
That willingness to test with anyone, even users outside the target demographic, signals a deeper philosophy at Genovese. He believes product teams suffer less from bad ideas than from unchallenged assumptions. The solution isn’t better brainstorming. It’s relentless reality-checking against how real people actually interact with what you’ve built.
Genovese traces his skepticism about unchecked product intuition back to his unconventional entry into technology. Before launching his first company at age 15, he spent years performing as a wedding singer and DJ across Germany, often accompanying his father, a professional artist, to events.
“My father was always my mentor,” Genovese recalls. “Since I was a kid, I went with him to events where he was singing. Instead of going hiking or skiing, we went to events, made music, and did business.”
That entertainment background taught him something most product leaders learn too late: what works in theory can die onstage. Performers get immediate feedback. A crowd either responds or doesn’t. Product teams, by contrast, can insulate themselves from users for months while building elaborate features nobody asked for.
The question of when product intuition stops being enough, and process needs to take over, elicits a sharp response from Genovese. “If you think through a product and you have an idea about how the user wants to use it, you need a process before building. You can start building without one, but then you risk failure or building something the user won’t like.”
His point cuts against the “just ship it” mentality that pervades startup culture. Shipping without validation isn’t bold. It’s reckless.
Genovese offers a diagnostic for identifying when a company’s internal incentives are quietly working against the product: check who the team is actually building for.
“The user is what matters most,” he says. “You should keep the company mission and build a product that solves a problem, but I would never change a product just because an investor wants something. If it’s stupid, I don’t care who’s making money.”
The pattern he describes is common enough to be predictable. A product gains early traction with a clear value proposition. Investors get involved. Suddenly, the roadmap fills with features designed to impress pitch meetings rather than solve user problems. Metrics get optimized for fundraising decks. The original vision gets diluted in pursuit of growth signals that look good on paper.
“Teams try to fulfill investor needs or CEO wishes, but you should keep your vision and what you stand for. Don’t build a product that does everything,” Genovese observes.
This mission creep shows up in predictable ways. Products add complexity instead of refinement. Feature bloat replaces focused execution. Teams mistake activity for progress, shipping updates that serve internal stakeholders while actual users get increasingly frustrated.
The correction requires discipline that many teams lack: repeatedly asking whether each decision serves the person actually using the product or someone else entirely.
When the conversation turns to artificial intelligence, Genovese’s user-first framework reveals why so many AI features feel gratuitous rather than useful.
“AI isn’t over-applied right now in products,” he says. “It’s more about doing it the right way. If AI doesn’t solve a problem or help the user, and it’s just a button that says ‘do this with AI,’ it doesn’t make sense. But if it solves a problem and gives additional help, then it’s useful.”
The distinction matters more than most product teams acknowledge. Adding AI capabilities because competitors have them or because investors expect them produces exactly the kind of feature bloat Genovese criticizes. Users don’t care about the underlying technology. They care whether something makes their lives easier.
“What does it help the user? Does it make the user’s life easier? Is it solving a problem?” Genovese asks. That’s the question product leaders should answer before integrating AI into user-facing systems, not after.
His broader point extends beyond AI to any technology decision. “Technology should support the product. Everything is possible. We have enough computing power and everything needed to make a great product. For me, it’s always about the user interface. It’s about speed. It has to react immediately, not have long load times just because of the technology.”
Technology serves the user experience, not the other way around. When teams prioritize technical sophistication over practical utility, they’ve already lost the plot.
Genovese draws a clear distinction between product leadership and the founder-led chaos that often passes for it in early-stage companies. The difference shows up most clearly when things aren’t going well.
“Good product leadership means going back to your roots,” he says. “What was my initial vision for this product? What was my idea? Are we focusing on solving a problem for the consumer, or just fulfilling wishes from people who don’t actually use the product and have unrealistic ideas?”
That ability to cut through accumulated complexity and return to first principles separates leaders from founders who’ve simply been promoted. It requires intellectual honesty about what’s working and what isn’t, without the ego protection that makes many founders allergic to negative feedback.
“If your product isn’t doing well, look into why. What was the initial vision? What are you solving? How is the user experience now, and what could be better? Talk with your user, talk with your customer. Find out what they need, what they want, and what they don’t like. That’s what’s important.”
The advice sounds simple because it is. Complexity isn’t the problem. Avoidance is. Teams accumulate features, processes, and stakeholder requirements while systematically avoiding the hard conversations with actual users that would expose fundamental issues.
Founder-led chaos, by contrast, produces thrash without direction. Decisions get made based on whoever spoke to the founder last. Strategy shifts with each new insight or competitive threat. The roadmap becomes a wish list rather than a coherent plan. Users experience this as inconsistency, confusion, and a product that never quite delivers on its promise.
“The biggest problem is that now everyone thinks they can build a good product, but they don’t think the product through. You should sometimes go back to your roots and rethink the product first, then start building. Don’t just add features and hope it somehow works without really understanding how.”
Genovese’s harshest judgment is reserved for the mistake most teams keep making: confusing early traction with product-market fit. A product can show promising initial metrics while fundamentally misunderstanding what users actually need.
“My biggest lesson is to keep your vision, keep your first idea, and focus on solving the problem for the user. That’s the biggest problem when you grow. When you have paying customers, focus on them. Don’t focus on the investor, the CEO, the CTO, or the engineers. Focus on what makes the customer happy.”
The repetition is intentional. Genovese sees teams repeatedly make the same error: optimizing for everyone except the person actually using the product. The pattern becomes self-reinforcing. Internal stakeholders have louder voices and clearer asks than users do. Investors have leverage. Executives have authority. Users just quietly stop using the product.
By the time usage metrics show the problem, months of work have been invested in the wrong direction. That’s when Genovese’s most radical advice becomes relevant: sometimes you need to throw everything away and start over.
“Be bold enough to throw away what you’ve done and start from scratch.”
Most teams resist this advice because of the sunk cost fallacy. They’ve invested too much to abandon the current approach, even when evidence suggests it isn’t working. Genovese argues the opposite: when a product is built on faulty assumptions, incremental fixes just compound the error. Better to acknowledge the mistake and rebuild with proper user validation from the beginning.
“I’ve seen products improve their design and structure when they started from scratch and rethought from the beginning what problem they’re actually solving. The product became much better.”
The practical question becomes how to embed continuous user testing into team culture rather than treating it as a one-time validation exercise. Genovese’s answer combines accessibility with frequency.
“Try it out, test it, find out if it works. If it breaks, then redo it,” he says simply. The key is removing friction from the testing process so it becomes routine rather than special.
This means using simple prototypes that can be validated quickly. “I test products with simple prototypes that may look ugly, but they have the functionality, and that helps.” The goal isn’t to impress users with polish. It’s learning whether the core concept resonates before investing in refinement.
It also means accepting feedback from unexpected sources. Genovese explicitly advocates testing with people outside your target demographic because they’ll spot confusing elements that regular users might overlook or accept. Fresh eyes catch problems that familiarity masks.
The broader principle is to treat product development as continuous discovery rather than as sequential stages. You don’t research users, then design, then build, then test. You’re constantly cycling between all those activities, using each insight to inform the next decision.
Teams that separate building from testing inevitably build the wrong thing. The gap between what users say they want and what they actually respond to can only be bridged through repeated contact with real usage patterns.