--- title: Why your best feature idea might be your worst business decision description: Feature ideas can quietly become costly mistakes. Discover why assumptions and founder conviction lead product teams astray before build begins. image: https://weareaffective.com/hubfs/learning-centre-images/why-your-best-feature-idea-might-be-your-worst-business-decision.webp --- [Skip to content](https://weareaffective.com/learning-centre/why-your-best-feature-idea-might-be-your-worst-business-decision#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 # Why your best feature idea might be your worst business decision Table of Contents A founder walks into a brief with a colour-coded spreadsheet. Every competitor product is mapped across dozens of columns. Features are ticked, gaps are circled, opportunities are highlighted in green. The energy in the room is high. The plan feels airtight. And then we start asking questions about the [actual people who will use this thing](https://weareaffective.com/app-user-research), and the energy changes. > The gap between founder conviction and validated user need is where budget disappears and timelines extend. This happens at the brief stage, at the research stage, and sometimes deep into build. A feature idea that felt like a genuine insight turns out to be shaped almost entirely by what the founder wanted the product to be, rather than what the market was asking for. The gap between those two things is where budget disappears, timelines extend, and products stall. We have seen this across enough projects now to know that the most expensive feature decisions are rarely the obviously bad ones. They are the ones that looked completely reasonable at the time, backed by competitive analysis and personal conviction, but never tested against a real person with a real problem. ## Why the brief stage is where bad feature decisions take root The brief is where product direction gets set, and it is also where [assumptions harden into requirements before anyone has checked them](https://weareaffective.com/learning-centre/what-are-the-most-common-mistakes-startups-make-when-building-their-first-app). By the time a feature reaches the build stage, it often carries months of belief behind it. Questioning it feels like going backwards. So the assumption travels through design and into development, and only surfaces as a problem once the cost of undoing it is real. What we notice is that the brief stage rarely has enough friction in it. Founders bring a strong point of view, and the instinct of everyone in the room is to receive it rather than examine it. The feature list grows, the scope expands, and the product starts to reflect the founder's mental model of the market rather than anything a user has actually said. The brief for a pre-launch football product we worked on was built almost entirely on what the founders believed the product should do. The feature set was broad, the ambition was high, and the market research was essentially competitive observation. We flagged the risk of overcomplication early, but the brief had already baked in assumptions that proved difficult to walk back. Development stalled, the product grew too complex to ship, and more than a year later it still had no marketable release, only a series of rolling "coming soon" announcements. Before any feature enters a brief as a requirement, write down the specific user behaviour it is responding to. If the answer is "we think users will want this" rather than something observed or tested, treat it as an assumption that still needs checking. ## The difference between founder excitement and validated user need Founder excitement is a real signal, but it is a signal about the founder, not the market. The problem is that conviction and insight look identical from the inside. A founder who has lived inside an industry for years genuinely believes they understand the problem. And often they do understand part of it. But the part they understand most clearly is their own experience of it, which is not the same as [the experience of the people they are building for](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you). We worked with a pre-launch founder in the football industry who arrived with a colour-coded spreadsheet mapping every competitor product across dozens of features. The idea was to merge the best of all of them into one product. The founder was visibly excited, pleased with the thoroughness of the work. When we started asking questions about prospective users, specifically why someone would choose an all-in-one product over the specialist apps they already used, and whether consolidation would water down the features that made each one valuable, the energy in the room shifted. The founder became deflated. But those questions were not obstacles to the work. They were the work. Our intention in moments like that is not to dismiss what a founder has built. Quite the opposite. The competitive analysis was real and useful. What it was missing was the dimension that makes it actionable, which is [whether real users share the problem](https://weareaffective.com/learning-centre/how-to-pressure-test-a-product-concept-with-people-who-arent-your-target-users-y) the founder has identified, and whether the proposed solution fits how they actually behave. ## 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 ## What it actually costs to undo a feature built on assumptions The cost of a bad feature decision includes the development time spent building it, the discovery time diverted away from it, the design decisions made around it, and the rework required when it fails to fit the product it sits inside. These costs compound, and by the time they become visible they are usually much larger than the original saving that justified skipping the research. We saw this directly on a dating app project focused on verified profiles and preventing bots. The client chose to skip discovery for the messaging component and concentrate all research effort on the onboarding process. The logic made sense on the surface: onboarding was where the verification happened, so that was where the attention went. > Skipping discovery on one part of a product creates contradictions that the rest of the build cannot paper over. The messaging feature was built generically, without any of the constraints the onboarding had been designed to enforce. It allowed automated and fake messages, which was precisely the behaviour the verification system existed to prevent. The mismatch between a rigorously verified onboarding flow and an open messaging system meant the entire messaging section had to be rewritten. That decision cost approximately £15,000 in additional budget and two months of extra work. The research that would have caught it cost considerably less. When a client wants to [skip discovery on one part of a product](https://weareaffective.com/learning-centre/how-to-scope-a-pre-build-research-phase-when-the-budget-is-already-signed-off-fo), map the dependencies first. List every other feature that relies on the same behavioural assumptions. If skipping discovery in one area creates contradictions elsewhere, the saving is likely to cost more than the research would have. ## Why competitive feature mapping is not the same as user research Competitive analysis tells you what already exists. It does not tell you why users chose it, what they still find frustrating about it, or whether the gap you have spotted is a genuine unmet need or simply a feature that was tried and removed. A spreadsheet of competitor features is a map of supply. It says almost nothing about demand. The appeal of competitive mapping for pre-launch founders is understandable. It is tangible, it is controllable, and it validates the founder's existing opinions without requiring anyone to contradict them. User research, by contrast, introduces uncertainty. [Talking to real prospective users risks surfacing](https://weareaffective.com/learning-centre/5-user-testing-methods-that-will-save-your-app-from-failure) the finding that the idea is not what people want. That is an uncomfortable position, and it is why the spreadsheet often gets more attention than the interview guide. CB Insights' [post-mortem analysis of failed startups](https://www.articos.com/blog/user-research) found that roughly 42% of failures traced back to no market need, making it the single most common cause of failure, more common than running out of cash. That pattern is exactly what competitive mapping cannot protect against, because it only shows what others built, not whether anyone needed it. What competitive analysis and user research do together is more useful than either alone. The competitive work maps the space. The user research tells you where the real friction is, and whether the feature you are planning to build will land in a place people actually care about. ## When research becomes a box-ticking exercise Research that a founder has no intention of acting on becomes a formality, and it tends to look like one. The sessions happen, the findings are written up, and then the product continues in the direction it was always heading. The research existed to satisfy a process requirement, not to inform a decision. We walked away from one engagement where this became clear. The founder had deep industry experience and very strong pre-formed views about how the product should work. The research process was agreed to, but it was a box-ticking exercise from the start. When we presented compelling evidence that a large portion of the target user base did not want particular features and preferred alternatives, the founder did not move. The findings were acknowledged and set aside. The product launched roughly a year later, largely unchanged from the original plan. By our account, it did not go anywhere, for the same reasons the research had flagged. The evidence was there. The decision had already been made. Research is worthwhile only when the team is genuinely willing to act on what it finds, including findings that require changing something already decided. Without that willingness, the sessions are just a cost with no return. Before commissioning research, agree internally on what a finding would need to show to change the direction of a feature. If the team cannot answer that question, the research is unlikely to change anything regardless of what it finds. ## The vanity product: how conviction without evidence shapes a release A vanity product is shaped by the founder's preferences rather than user evidence. It tends to look polished and feel personally meaningful to the people who built it, and it tends to miss the people it was built for. The warning signs are recognisable before launch: an excessive drive to perfect the product before release, recurring requests to revisit decisions that had already been signed off, and a pattern of rolling timelines that extend without a clear trigger. We identified this pattern across two separate projects, a fitness and wellness app and the grassroots football product mentioned earlier. In both cases, the founders had strong personal conviction about what the product should be. Both engaged with research processes. Both then ignored the data that came out of those processes, [from focus groups, from surveys, from user sessions](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). The product continued to reflect what the founder wanted rather than what the evidence suggested. In both cases, the budget ran out during the design and build phases. Neither project reached a fully live product. The football product is still accumulating "coming soon" announcements. The fitness app never shipped in the form it was designed. The conviction that drove both projects was genuine. So was the cost of building on it without evidence behind it. ## How complexity compounds: the all-in-one trap The logic of the all-in-one product is appealing: consolidate what users currently do across multiple apps into one place, reduce friction, and own more of their daily behaviour. The problem is that the features that make specialist apps valuable tend to be deeply considered for a narrow purpose. When you lift those features out of their original context and combine them, the coherence that made each one work starts to degrade. The grassroots football app we worked on ran into this directly. The client compared each feature of their app to best-in-class single-purpose competitors and pushed repeatedly for the booking process to be more like the leading booking product, the communications more like the leading messaging product, and so on. We pushed back, but ultimately complied with the requests. The changes made little material difference to how the product felt. The real problem was not the execution of any individual feature. It was that the product was trying to do too many things at once. There was a reason those features existed across several separate apps. The attempt to consolidate them produced something overly complex, too verbose, and not fit for the audience or its core purpose. The feature decisions that looked like improvements in isolation were compounding a structural problem that no individual fix could resolve. | Approach | Strengths | Risk | | --- | --- | --- | | Specialist product | Deep focus on one problem, features designed for a specific context | Narrow audience, limited scope for expansion | | All-in-one product | Broader appeal, single destination for multiple needs | Features lose depth, complexity compounds, coherence breaks | | Focused MVP | Validates core need before complexity is added, reduces waste | Requires discipline to resist scope expansion before validation | ## What discovery actually changes about a product Discovery does not just produce a list of features to add or remove. It changes the frame through which the whole product is understood. Teams that run discovery properly often find they are solving a different problem than the one they started with, or solving the same problem in a substantially different way. That shift tends to produce a better product at a lower cost than the original plan would have delivered. We worked with a property developer building a concierge app for high-rise buildings. They came in with a suggested budget and a clear idea of what they wanted, and they were looking for validation of that plan rather than a full scoping. We convinced them to run a proper discovery phase, including focus groups and user workshops. What emerged was that the [product needed to be considerably simpler than envisaged](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one). Many of the features they had planned were dropped. The focus shifted from replacing existing building systems to creating a human connection with the product, something warm and useful rather than comprehensive and complicated. The result was a better product than the original plan would have produced, and it cost less to build. Discovery did not slow the project down. It removed the work that would not have earned its place. Research investment pays back measurably. [Forrester](https://uxarmy.com/blog/ux-research-roi-product-metrics/) has estimated that every pound spent on UX research saves roughly £100 in development costs later, because the mistakes it prevents are far more expensive to fix than to avoid. ## How to pressure-test a feature idea before it enters the build A feature idea that survives a few honest questions is a better candidate for the build than one that has never been examined. The questions do not need to be complex. They need to be direct, and the team needs to be willing to hear the answers. The questions we find most useful are organised as a short sequence before anything enters the backlog. 1. What specific user behaviour or expressed frustration is this feature responding to? 2. How many users have we observed or spoken to who share this problem? 3. Does this feature fit the core purpose of the product, or does it pull against it? 4. What would we remove or stop doing to make room for this? 5. What would we need to see in testing to conclude this feature is not working? The last question is the one that teams most often skip, because it requires agreeing in advance on what failure looks like. Without that agreement, [no amount of post-launch data will be enough](https://weareaffective.com/learning-centre/why-does-our-competitor-feel-more-trusted-even-when-our-product-is-better) to retire the feature, and it will accumulate technical debt and design complexity long after the evidence has moved against it. The removal test is a related check. Ask what would happen to engagement if a specific feature were disabled for a group of users. If the honest answer is "we would never do that, " that response tells you something. Features protected by instinct rather than evidence tend to be features retained for product metrics rather than user value. ## Conclusion The feature ideas that do the most damage are rarely the obviously bad ones. They are the ones that felt right, were backed by conviction, and moved through the brief without enough friction to surface the assumptions underneath them. By the time the cost becomes visible, it is usually measured in budget spent, timelines extended, and products that never reached the people they were built for. What the grassroots football product, the dating app messaging rewrite, the all-in-one football app, and the fitness product all have in common is not a lack of effort or ambition. They were built by people who cared deeply about what they were making. What they were missing was a process that introduced the right questions early enough for the answers to change something. Discovery is the thing that makes the build worth doing. When it is skipped, or treated as a formality, the costs tend to arrive later and larger than the research would have. When it is done properly, it removes work, clarifies direction, and produces something that fits the people it is for rather than the person who built it. If you are heading into a build with a strong feature list and a clear point of view, the most useful thing you can do before anything enters development is to put those features in front of real people and ask honest questions. We can help you do that. [Let's talk about your product before the build begins.](https://weareaffective.com/get-started) ## Frequently Asked Questions Why do bad feature decisions so often go unnoticed until it is too late? The most expensive feature decisions tend to look completely reasonable at the time, backed by competitive analysis and personal conviction. The problem is that they are rarely tested against a real person with a real problem, so the flaw only becomes visible once significant budget and time have already been spent. What makes the brief stage so risky for product development? The brief is where assumptions harden into requirements before anyone has properly examined them. By the time a feature reaches the build stage, it often carries months of unchallenged belief behind it, making it very costly to reverse course. How is founder excitement different from validated user need? Founder excitement is a signal about the founder, not the market. A founder may understand an industry deeply, but the part they understand most clearly is their own experience of it, which is not necessarily the same as the experience of the people they are building for. What is wrong with using competitor analysis as the main basis for feature decisions? Competitor analysis tells you what others have built, not what users actually need or struggle with. Mapping features across a spreadsheet can feel like thorough research, but it skips the step of speaking to real people about real problems. How can a team spot an assumption masquerading as a requirement in a brief? A useful test is to write down the specific user behaviour each feature is responding to. If the answer is something like 'we think users will want this' rather than something observed or tested, it should be treated as an assumption that still needs checking. What are the practical consequences of shipping a product with unvalidated features? As shown in the football product example in the article, unvalidated features tend to multiply, making the product too complex to ship on time. The result is stalled development, missed launch windows, and a product that exists only as a series of 'coming soon' announcements. At what point in the process should user research happen? User research should happen before features are locked into the brief as requirements. Waiting until the design or build stage means any findings come with a much higher cost to act on, as assumptions have already shaped decisions across the project. Is there value in a founder's industry experience when shaping a product? Yes, industry experience is genuinely useful and should not be dismissed. The key is recognising that it provides part of the picture, and that it needs to be tested and complemented by direct input from the people the product is being built for. ## 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.