Product leaders hear the same demand from every direction: ship faster. Investors want momentum. Competitors launch features that need responses. Engineering teams want to prove velocity. Users expect constant updates. The pressure to move quickly becomes overwhelming.
Product executive Marcello Genovese argues this pressure often destroys the things teams are trying to build. Speed without direction erodes the trust that keeps users engaged. Velocity becomes valuable only when it serves a coherent vision rather than just producing output.
“Teams should keep their vision,” Genovese says. “Don’t just build for investors or others in the company. Keep the vision and the idea for solving the problem for the user. Always focus on the first idea you had.”
The challenge isn’t choosing between speed and quality, or between growth and trust. It’s maintaining clarity about what problem you’re solving when everyone around you is demanding you solve different problems faster.
Genovese traces the breakdown back to a fundamental confusion about what speed means in product development. Teams measure velocity by the number of features shipped, releases published, and sprint points completed. Those metrics capture activity but say nothing about whether the activity moves toward solving real user problems.
“You see products that start strong and get traction, then they try to fulfill investor needs or CEO wishes,” Genovese observes. “You should keep your vision and what you stand for, not build a product that does everything.”
The story unfolds predictably. A product launches with a focused value proposition. Early users respond positively. Traction leads to funding. New stakeholders bring new opinions. The roadmap expands to accommodate everyone’s ideas. Users experience this as confusion about what the product actually does.
The measured output speed looks impressive. Speed measured as progress toward product-market fit reveals stagnation or regression. The product moves quickly while going nowhere.
This matters particularly for trust. Users choose products based on clear promises about what problems they solve. When a product keeps adding capabilities in different directions, users can’t tell whether the core promise still holds.
“If you build a product that solves a real problem for the user, then you’re solving something important,” Genovese argues. “Build for the user, not for the technology or fancy interactions or excessive functions. That makes the difference.”
Genovese speaks bluntly about a dynamic most product leaders experience but few discuss openly: investor pressure to ship features that serve fundraising narratives rather than user needs.
The sequence repeats across companies. A board meeting approaches. Investors ask about competitive positioning. Someone mentions a feature competitors have launched. The roadmap shifts to prioritize features that look good in the next pitch rather than the capabilities users actually request.
“The user is what matters most,” Genovese states. “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 statement reflects hard-won lessons. Genovese started his first company before age 16, becoming one of Germany’s youngest entrepreneurs. Over years of building ventures with business partner Stefan Graf, he learned to distinguish between stakeholder pressure that improves products and pressure that just serves someone else’s agenda.
The practical question becomes how to resist that pressure without alienating people who control the company’s future. Genovese’s answer centers on user evidence. When investors push for features, the response isn’t refusal. It’s redirecting the conversation toward what users are actually asking for.
“Are we focusing on solving a problem for the consumer, or just fulfilling wishes from people who don’t actually use the product?” Genovese asks. Framing decisions around that question makes it harder for stakeholder preferences to override user needs.
The underlying principle is that user trust matters more than satisfying investors. If users stop trusting that your product does what it promises, no amount of investor satisfaction will save the company.
Most product teams think about trust as something that happens outside the product. Privacy policies. Security measures. Support responsiveness. Those elements matter, but Genovese argues trust is fundamentally about whether the product consistently does what users expect.
“Good product strategy is always about the end user and how they’re going to use it,” he explains. “People misunderstand that nothing is as easy as it looks. You still need to think through your product.”
This reveals why speed often erodes trust. When teams ship features quickly without validating whether users want them, the product becomes unpredictable. Users open the app and find new capabilities they didn’t request. Familiar workflows change without warning. Each change might be defensible on its own, but the cumulative effect is that users can’t trust the product to remain stable.
The corrective isn’t moving slowly. It’s moving deliberately. Genovese advocates for rapid testing with rough prototypes to validate ideas quickly, followed by careful implementation once you know something is worth building.
“I test products with simple prototypes that may look ugly, but they have the functionality, and that helps,” he says. Learn fast whether an idea resonates. Then, when you commit to building something properly, the pace can be more measured because you’re confident it’s worth doing.
As products scale and user bases grow, the stakes around trust and responsibility increase dramatically. Decisions that affected hundreds of users in the early stages now affect thousands or millions.
Genovese identifies this transition as particularly difficult for founder-led teams. The instincts that work for early-stage products often break when applied to platforms with substantial user bases.
“Good product leadership means going back to your roots,” he argues. “What was my initial vision for this product? What was my idea? Are we still solving that problem, or have we drifted into something else?”
The distinction between product leadership and founder-led chaos becomes most clear when things aren’t working. Founders tend to react to problems by adding features, launching initiatives, and reorganizing teams. The bias is toward action and speed. Product leaders step back and ask whether the activity serves the original vision or just creates motion.
“If your product isn’t doing well, look into why,” Genovese advises. “What was the initial vision? What are you solving? Talk with your user, talk with your customer. Find out what they need, what they want, what they don’t like.”
The responsibility piece comes from recognizing that at scale, your product shapes user behavior whether you intend it to or not. Interface choices determine what people pay attention to. Feature design determines what actions feel easy or difficult. Teams that move too fast skip considering those second-order effects.
Genovese returns repeatedly to maintaining product vision as the solution to competing pressures around speed, stakeholder demands, and trust.
“Keep your vision and what you stand for,” he emphasizes. This isn’t about rigid adherence to original plans regardless of market feedback. It’s about distinguishing between insights that improve how you solve the core problem and pressure that dilutes focus by trying to solve different problems.
The practical test is straightforward. When someone proposes a new feature or direction, the question isn’t whether it’s a good idea in isolation. It’s whether it serves users trying to solve the problem your product addresses. If yes, the feature strengthens the vision. If no, it’s a distraction regardless of who’s advocating for it.
“My biggest lesson is to keep your vision, keep your first idea, and focus on solving the problem for the user,” Genovese says. “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 hierarchy is clear. Users first. Everything else second. When that priority is inverted — when investor preferences, internal politics, or competitive anxiety drive decisions — products lose both focus and trust.
Products sometimes ship features that break user trust. The response from teams is often to move even faster, adding new capabilities to distract from the problems or patching issues with incremental fixes.
Genovese advocates for a more radical approach: sometimes you need to throw everything away and start over.
“Be bold enough to throw away what you’ve done and start from scratch,” he says. “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.”
This applies not just to technical architecture but to product positioning and user relationships. Once trust erodes past a certain point, patches and apologies don’t restore it. Users need to see a fundamental change that demonstrates you’ve understood what went wrong.
“What was my initial idea for this product? Are we still solving that problem?” Genovese frames these as the essential questions. If the answer reveals you’ve drifted far from your original vision and users no longer trust what you’re building, starting fresh often makes more sense than trying to repair something fundamentally misaligned.