--- title: The Hidden Cost of Letting the Loudest Voice in the Room Shape the Product description: Why vanity products fail. Spot the warning signs of founder bias, make research count and challenge strong opinions before the budget burns out. image: https://weareaffective.com/hubfs/learning-centre-images/the-hidden-cost-of-letting-the-loudest-voice-in-the-room-shape-the-product.webp --- [Skip to content](https://weareaffective.com/learning-centre/the-hidden-cost-of-letting-the-loudest-voice-in-the-room-shape-the-product#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # The Hidden Cost of Letting the Loudest Voice in the Room Shape the Product Table of Contents Two products we worked on, a fitness and wellness app and a grassroots football product, ran out of money in much the same way. In both cases the founder held a strong, clear view of what the product should be. Both sat through research studies, focus groups and surveys. Both carried on building the thing they had pictured before any of that started, and both spent the whole budget on design and build without ever reaching a full live version. We flagged the direction early on both projects. Being right early counts for very little once the money is committed to the wrong shape of product. > A product built around one person's preference still gets made, it just never gets used by anyone. The loudest voice in the room is usually the founder, and that makes sense. They raised the money, they carry the risk, and most of the time the idea started with a problem they felt themselves. What follows is less about blaming them and more about what the pattern costs, how early it shows up, and the handful of practical things that catch it before a developer writes a line of code. ## What a Vanity Product Actually Looks Like A vanity product is one shaped by what the founder prefers rather than what the research keeps pointing at. On both the fitness and wellness app and the grassroots football product, the founder was solving a problem they had personally lived with. That gave them genuine conviction and a genuine blind spot at the same time, because their own experience started to stand in for everybody else's. The shape of it is recognisable once you have been through it. Research gets commissioned, [findings get presented, and the product carries on](https://weareaffective.com/learning-centre/why-your-app-needs-real-users-not-just-your-mums-opinion) in the direction it was already heading. Features arrive because they sound good in a meeting. The launch date slides because the product never feels finished to the one person who has to sign it off. ots football product, the founders kept adding. We advised against cramming so much into one place and said so more than once. The product became so complex that development had to stop, and we ceased working with them. More than a year on from the start, there is still no marketable release in public, just shifting dates and repeated announcements that it is coming soon. Both of those projects spent their money on design and build. Neither of them reached users in any meaningful way. ## Why Founder Conviction Feels Like Evidence When someone in the room says a flow feels wrong, the first thing we do is ask where that idea is coming from. A feeling from people around the table, numbers from analytics, and findings from user research all sound similar when spoken aloud in a meeting, and they carry completely different weight. Founder conviction is the first kind wearing the clothes of the third. It feels like evidence because it is built on something real. The founder has lived the problem, often for years, and they know the category from the inside. That depth creates insider bias. Someone who knows a product deeply finds [flows obvious that a first-time user finds baffling](https://weareaffective.com/learning-centre/when-users-blame-themselves-for-your-confusing-app-youve-already-lost-them), which is how two quite different journeys through the same product end up being needed. We worked with a founder who had deep industry experience and very strong views about how their product should work. The research process ran properly. The findings came back. None of it landed, because the research had been a box-ticking exercise from the start and there was never any intention of acting on it. ## Design that understands *your* users We build app experiences around real user behaviour, not assumptions. Research, psychology-driven design and technical specs that turn users into loyal advocates. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## The Warning Signs That Appear Before a Line of Code Is Written The useful thing about this pattern is how early it shows itself. Long before build starts, the behaviour around decisions tells you what sort of project you are in. - An unusual drive to perfect everything before anyone outside the company sees it. - Sign-offs rolled back weeks later so more changes can be requested. - Decisions that take months and then get reopened anyway. - Research findings described as interesting, then never referenced again. - Features justified by what a competitor does rather than by a user need. On the grassroots football product, the rolling back of agreed decisions was the clearest early signal. [Scope kept growing after sign-off](https://weareaffective.com/learning-centre/what-scope-creep-actually-costs-a-sports-club-app-that-spent-twelve-months-growi), each addition sounded reasonable in isolation, and the cumulative effect was a product nobody had scoped and nobody had budgeted for. > Scope that grows after every sign-off is a decision problem wearing the mask of a feature problem. MVP thinking gets resisted in these projects for a consistent reason. Releasing something small means finding out whether people want it, and finding out is exactly what the founder is avoiding. Projects that insist on launching everything at once are at real risk of never launching anything. ## When Research Becomes a Box-Ticking Exercise Proper [app user research](https://weareaffective.com/app-user-research) that nobody intends to act on still costs money, still takes weeks, and still produces a document. What it buys is the appearance of rigour, which is worse than skipping it, because now the founder can say the work was done. With that industry-experienced founder, we showed compelling evidence that large numbers of their potential user base did not want particular features and preferred alternatives. The evidence was clear and the sample was theirs, drawn from the people they intended to sell to. They did not move. We eventually walked away from the engagement. They launched a product in line with what they had always a year later, and by our reading of it, the product went nowhere for the reasons the research had already named. This is the most common way products die. Among 101 startup post-mortems analysed by [CB Insights](https://rightidea.app/blog/startup-idea-validation), 42% of failed founders put no market need at the top of the list, ahead of running out of cash. Before research starts, ask the founder out loud what finding would make them change the plan. If there isn't one, you are buying a document, not a decision. ## The Spreadsheet Trap: Competitor Mapping Instead of User Conversations A pre-launch founder in the football industry came to us with a colour-coded spreadsheet. Every competitor product sat in a row, every feature sat in a column, and the plan was to merge several of those products into one. They were excited and visibly pleased with it, and the work behind it was real. We started asking about prospective users. Why someone already using two specialised apps picks an all-in-one instead. Whether pulling everything together risks dumbing down the features people chose those apps for in the first place. They were deflandably so, because the spreadsheet had not been built to survive those questions. | | Competitor spreadsheet | Six user conversations | | --- | --- | --- | | Cost | A few days of someone's time | Recruitment, incentives, sessions | | Tells you | What exists already | Why people pick what they pick | | Can disagree with you | No | Yes | | Feels like | Validation | Risk | That last row explains the preference better than cost does. A spreadsheet gives immediate backing to opinions the founder already holds, and nothing in it can contradict them. [Talking to real people carries the worry](https://weareaffective.com/learning-centre/why-your-app-needs-real-users-not-just-your-mums-opinion) that the idea is wrong, or that nobody wants it. ## Feature Creep as a Symptom, Not a Cause On a grassroots football app, the client compared each feature of their product against the best single-purpose app in that category, then kept telling us the booking process needed to be "more intuitive". We pushed back, explained what we thought the actual problem was, and in the end made the changes they asked for. The difference it made was close to nothing. The booking flow was never the problem. The client was trying to do too much in one product, and there was a reason those features lived in several separate apps elsewhere. Despite real effort to make something cohesive and emotionally grounded, what came out was [overly complex, far too verbose](https://weareaffective.com/learning-centre/why-does-my-app-feel-cold-even-though-the-design-looks-good), and not fit for the audience or the core purpose. Feature creep is what founder conviction looks like once it reaches a backlog. Each addition closes down an awkward question, and the cost lands later. The [Standish Group CHAOS Report, 2015](https://www.studocu.com/da/document/erhvervsakademi-aarhus/systemudvikling/chaos-report-2015-the-standish-group/19026719) put the share of software features that are never used at 45%, which is a lot of design, build and testing spent on things nobody opens. Fixing an interaction rarely fixes a product that is trying to be four products. ## The Real Cost: Budgets Burned, Products Never Launched On a dating app built around verified profiles and keeping bots out, the client wanted to skip discovery for messaging and put everything into onboarding. We built a generic messaging feature because that is what skipping discovery produces. It allowed automated messages and fake messages, which is precisely the behaviour the onboarding had been designed to stop. The two halves of the product argued with each other. The whole messaging section had to be rewritten, at roughly £15,000 of extra budget and about two months of extra work. > Discovery skipped in one place shows up as a contradiction somewhere else in the same product. That project recovered, because the client paid for the rewrite and the product held together afterwards. The fitness and wellness app and the grassroots football product did not get that chance. Both used the budget up in design and build, and neither reached a full live version, so nobody ever found out whether the idea had legs. Money spent on a product that launches badly teaches you something. Money sp teaches you nothing at all, and that is the more expensive outcome of the two. ## What Listening to Research Properly Looks Like On a concierge app for a high-end property development, we ran focus groups with two very different sets of people. One group was high-net-worth individuals, the target customers. The other was people living in social housing, who were never going to buy a flat in that building. We brought in the second group because they already had the thing we were trying to design into the product, a real sense of community, openness and knowing your neighbours. High-rise developments tend to lack exactly that. The sessions pointed at one thing repeatedly, which was communication. So we stopped trying to solve every offline problem inside the app, automated the mundane tasks instead, added personalisation so residents saw their neighbours' interests and something of the concierge's personality, and built a social space into the product. It worked really well. On a genetics wellness app, our audit found the brand promise was sound. The narrative of showing people a real inside look at how their body works and ages was strong. Built largely by developers, the product had lost that storytelling and become purely functional, so [people never connected with their own results](https://weareaffective.com/learning-centre/why-does-my-app-feel-cold-even-though-the-design-looks-good). We put the narrative back rather than touching the promise. Recruit one group who are not your customers but already live the behaviour you want your product to create. They explain the feeling better than your target market can. ## Mechanisms to Catch This Before Build None of this needs a heavy process. It needs a few points where an assumption has to survive contact with somebody outside the company. 1. Write down, before research starts, which decisions the findings are allowed to change. 2. Trace every requested feature back to a research finding, an analytics number, or a named user. Anything with no source goes on a separate list. 3. Run discovery across every connected part of the product, including the parts that feel obvious. The dating app messaging rewrite came from treating one component as not worth asking about. 4. Put something small in front of real users early, then plan for the direction change. We have never launched a product where the feedback failed to push it somewhere the internal team had not pictured. 5. Re-present the findings that were rejected at the next milestone, with the cost of ignoring them attached. The fourth point does most of the work. Once a founder has heard three strangers describe their product back to them, the conversation changes shape. Research stops being a report and becomes a set of voices they can picture. Mechanisms also protect the founder. Writing down what the research is permitted to change makes the later disagreement about an agreed rule rather than about whose opinion is better. ## How to Challenge a Founder Without Losing the Room The football founder with the spreadsheet left that meeting deflated, and we knew they were going to. Our job is to be honest about a product and what makes it succeed, because building on vanity metrics alone serves nobody, leastying for it. Honesty lands better when it arrives as questions about users rather than verdicts about the idea. Asking why someone already happy with two specialised apps switches to an all-in-one is a question the founder can go and answer. Telling them the idea is wrong is a position they have to defend. There is a simpler route that works more often than people expect. Everybody in the room is a user of products like this, so when we play back a design change and ask how it feels to them, the response is immediate and genuine. That question sits alongside formal testing rather than replacing it, and it keeps the founder inside the process instead of outside judging it. Bring the founder to the research sessions. Watching one person struggle with a flow does more than a slide reporting that eleven people struggled with it. Challenge the evidence, invite them to help gather more of it, and the room usually stays with you. ## Knowing When to Walk Away We walked away from theep industry experience after it became clear the research was never going to be acted on. We had shown them evidence that large parts of their intended audience did not want particular features. They did not move. Carrying on would have meant taking money to build something we had already told them was heading for failure. On the grassroots football product, the stopping point came from complexity rather than disagreement. The product grew past what the scope and the team could carry, development had to halt, and we ceased working with them. We advised against the overcomplication early and that advice sat on the table unused for months. > Walking away is cheaper for the client than another six months of building something nobody asked for. The signals are consistent. Findings get dismissed without a counter-argument. Sign-offs stop meaning anything. The launch date moves without any work having been removed. Scope grows while budget shrinks. Staying on a project like that damages everyone, including the next client who gets a tired team and a case study with no users in it. ## Conclusion Founder conviction is worth a lot. It carries a product through the long middle stretch where nothing works yet, and most good products start with someone who felt the problem personally. The trouble starts when that conviction is treated as a substitute for finding out, because a strong opinion and a researched position look identical in a meeting and behave completely differently in the market. The cost is rarely a bad launch. On the fitness and wellness app and the grassroots football product it was no launch at all, with the budget fully spent. On the dating app it was £15,000 and two months to rewrite a section that discovery would have shaped correctly the first time. Those are real numbers attached to decisions that felt small when they were made. The fix is unglamorous. Decide in the research is allowed to change, trace features back to a source, run discovery across the whole product, and put something in front of real people early enough to act on what they say. If you are heading into build with a product shaped mostly by what the room believes, [let's talk about testing those assumptions first](https://weareaffective.com/get-started). ## Frequently Asked Questions What exactly is a vanity product? A vanity product is one shaped by what the founder prefers rather than what the research keeps pointing at. It usually comes from someone solving a problem they have personally lived with, which gives them real conviction and a real blind spot at the same time. The tell is that research gets commissioned and presented, then the product carries on in the direction it was already heading. Why does founder conviction get mistaken for evidence? Founder conviction is built on something real, often years of lived experience in the category, so it sounds authoritative when spoken aloud in a meeting. The problem is that a feeling from the table, numbers from analytics and findings from user research all sound similar but carry completely different weight. Conviction is the weakest of the three wearing the clothes of the strongest. What is insider bias and how does it damage a product? Insider bias is what happens when someone knows a product so deeply that flows feel obvious to them while a first-time user finds the same flows baffling. It leads founders to design for themselves without realising it. The practical consequence is that you often need two quite different journeys through the same product, one for insiders and one for newcomers. How early does this problem usually show up? It shows up well before development starts, typically at the point where research findings are presented and nothing changes. The warning signs are features arriving because they sound good in a meeting and launch dates sliding because the product never feels finished to the one person signing it off. Spotting it early matters, because being right early counts for very little once the money is committed to the wrong shape of product. What happened to the two projects described in the article? A fitness and wellness app and a grassroots football product both ran out of money in much the same way. Both founders sat through research studies, focus groups and surveys, then carried on building what they had pictured beforehand. Both spent their entire budget on design and build without ever reaching a full live version or meaningful numbers of users. Why did the grassroots football project stall completely? The founders kept adding features despite repeated advice against cramming so much into one place. The product became so complex that development had to stop and the working relationship ended. More than a year on, there is still no marketable public release, just shifting dates and repeated announcements that it is coming soon. Is there any point running research if the founder has already decided? Not really, and that is the uncomfortable part. The article describes a founder with deep industry experience whose research process ran properly and produced findings that never landed, because it had been a box-ticking exercise from the start. Research only pays for itself when there is genuine intention to act on what comes back. What is the simplest way to challenge the loudest voice in the room? When someone says a flow feels wrong, ask where that idea is coming from before you act on it. Separating opinion from analytics from user research forces the strength of the evidence into the open. Doing that consistently catches the problem before a developer writes a line of code, which is the only point at which it is cheap to fix. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.