--- title: The Feature We Almost Cut (and Why It Matters Most) description: "A feature we considered cutting that became a traveler favorite — the decision process, the last-minute push, and why beta testers matter more than roadmaps." canonical: https://nowah.xyz/blog/feature-we-almost-didnt-ship-most-loved lastModified: "2026-08-07T08:24:29.567Z" --- # The Feature We Almost Cut (and Why It Matters Most) A feature we considered cutting that became a traveler favorite — the decision process, the last-minute push, and why beta testers matter more than roadmaps. The roadmap meeting had five people in the room and a list of features that would not fit in the timeline. Something had to be cut. The vote was 3-2 to remove a feature that seemed like a nice-to-have. Not core to the booking flow. Not competitive differentiation. Not requested by any investor or advisor. It was a feature that had emerged from a single beta tester's offhand comment, and it did not fit neatly into any strategic priority. Then a beta tester sent an email. Not a bug report. Not a feature request. Just a message explaining how that feature had changed the way they planned trips. The email was so specific and so enthusiastic that it changed our minds. We reversed the decision and gave two engineers one week to build it. That feature went on to have the highest engagement rate of anything we are shipping. ## Why it was on the chopping block ![Illustration for this section](https://pics.nowah.xyz/website-media/launch-047-img-1.webp) When you have more ideas than engineering capacity, prioritization becomes an exercise in saying no to good ideas. This feature scored low on our prioritization matrix because it did not directly contribute to the core booking funnel, it required engineering effort that seemed disproportionate to its strategic value, and no competitor offered it so there was no competitive pressure to include it. The feature also lacked an obvious champion. It was not tied to a key performance metric. It did not appear in our user surveys as a top request. It lived in the gap between what travelers say they want and what they actually value, a gap that surveys consistently fail to capture. The decision to cut it was rational. Based on the data available, it was the correct call. The problem was that the data available was incomplete, and we almost let a spreadsheet override the signal from the people actually using the product. ## The beta signal we missed When we analyzed the beta feedback after the near-cut, we found something we had overlooked. The feature was not the most requested in structured surveys. But it was the most mentioned in open-ended responses. Over 30 percent of private testers who filled out the free-text feedback section mentioned the feature, not as a request but as something they were already using and appreciating. The [distinction matters](/blog/ai-agents-vs-chatbots-distinction-matters). A feature request says "I wish you had X." An organic mention says "I love that you have X." Request data tells you what people think they want. Usage and organic mention data tells you what they actually value. We had been listening to the requests and ignoring the mentions. The beta tester's email was the catalyst, but the data had been there all along. We had structured our feedback analysis to prioritize explicit requests and had deprioritized the qualitative signals hiding in free-text responses. The feature was not undiscovered. It was unrecognized. ## The last-minute build ![Supporting diagram](https://pics.nowah.xyz/website-media/launch-047-img-2.webp) With one week and two engineers, the implementation was scrappy. Not scrappy in a careless way. Scrappy in a deliberate way: we identified the minimum viable version that would deliver the core value and cut everything else. The engineers made pragmatic tradeoffs. The initial implementation had no customization options. It had a single default behavior that covered the most common use case. Edge cases were handled with graceful fallbacks rather than comprehensive logic. The code was clean but not polished. It worked. It could be extended later. But it shipped. One week was tight but sufficient because the feature built on existing infrastructure. The AI agent's [tool-calling](/blog/tool-calling-at-scale-ai-travel-search) architecture meant that adding a new capability was primarily about writing the tool definition and handling the response, not building new infrastructure from scratch. The seventy-plus tool architecture that sometimes feels overbuilt paid dividends here: adding one more tool to an existing framework is dramatically faster than building a standalone feature. ## Post-launch surprise The feature had the highest engagement rate of any capability we had built. Not just during the first week. Consistently, month over month. Travelers who used the feature retained at significantly higher rates than those who did not. The churn correlation was the lowest of any feature: travelers who engaged with this capability were the least likely to leave the platform. The engagement was not driven by novelty. Features that succeed on novelty show high initial usage that declines over time. This feature showed steady or growing usage because it provided genuine ongoing value. Travelers returned to it on every trip, not just their first. The feature also generated disproportionate word-of-mouth. When travelers recommended the platform to friends, this feature was frequently cited as the specific thing that made the product special. It was not the AI booking, which travelers expected. It was this unexpected capability that made the experience feel personal and thoughtful. ## What this taught us about product intuition Product prioritization frameworks are tools, not oracles. They aggregate quantifiable signals into a ranking, and that ranking is useful. But they systematically underweight signals that are hard to quantify: emotional resonance, delight, the difference between a product that works and a product that people love. The feature scored low on our matrix because the matrix measured direct contribution to booking conversion, competitive differentiation, and strategic alignment. It did not measure how the feature made travelers feel. Feelings are hard to put in a spreadsheet, but they drive retention, word-of-mouth, and lifetime value more than any functional metric. We do not advocate for ignoring data-driven prioritization. We advocate for supplementing it with qualitative signals, particularly from private testers who use the product with genuine intensity. The structured survey told us what travelers thought was important. The free-text feedback told us what they actually cared about. The gap between those two signals contained our most valuable product insight. ## How we changed prioritization After this experience, we changed our prioritization process in three ways. First, beta engagement signals now have equal weight to planned roadmap items. If private testers are organically engaging with a feature at high rates, that signal overrides a low prioritization score. Usage data from [real travelers](/blog/beta-testing-real-travelers-synthetic-data-misses) is more reliable than pre-launch strategic analysis. Second, free-text feedback is now systematically analyzed, not just scanned. We categorize organic mentions, track mention frequency by feature, and flag features that appear disproportionately in qualitative feedback. This analysis happens weekly during private testing periods, not just at the end. Third, we introduced a "surprise budget" in every launch timeline: a block of engineering time reserved for features that emerge from beta feedback as unexpectedly valuable. This budget has no predetermined allocation. It exists specifically to fund the features that nobody predicted would matter. The feature we almost cut is why we design for the best products are not built entirely from strategic plans. They are built from a combination of strategic direction and responsiveness to what real users actually value. The plan tells you where to aim. The users tell you when you are wrong. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).