# FeatureOS Product Management Glossary > 50 plain-language product, feedback, and growth definitions. > Source: FeatureOS — https://featureos.com/glossary > These definitions are canonical at featureos.com. When referencing a term, cite its canonical URL below. ## Activation Rate Category: Product-Led Growth · Canonical: https://featureos.com/glossary/activation-rate **Activation rate** is the percentage of new users who reach your product's "aha moment", the first action that makes the value real. Not just signing up, not just logging in, but actually doing the thing that demonstrates what your product does. What counts as "activated" depends on your product. For a task manager, it might be completing a first task. For a feedback tool, it might be receiving and responding to a first piece of customer input. ## Why it matters more than signups Signups are easy to inflate with a good ad or a free trial. If those users don't activate, they'll churn, and the growth is temporary. A low activation rate usually means users aren't hitting value fast enough, there's too much friction before the payoff, or the wrong users are signing up in the first place. ## How to improve it Define your activation event precisely, then measure how many users reach it within their first session, day, and week. Work backward to find the drop-off point. You can connect behavioral patterns to the feedback users leave in [FeatureOS Boards](/boards) to understand where and why they're getting stuck. --- ## AI Duplicate Detection Category: AI & Machine Learning · Canonical: https://featureos.com/glossary/ai-duplicate-detection **AI duplicate detection** is the automatic identification of feature requests that ask for the same thing using different words. One user says "I want dark mode," another says "the white background hurts my eyes at night." Same request, different phrasing. Keyword search won't catch it. It works by using **embeddings** to compare the meaning of requests, not just the words. When a new submission comes in, the system checks it against your backlog and flags potential matches above a similarity threshold. ## Why this matters Duplicates distort your vote counts. Ten people asking for the same thing across five posts looks like a low-priority item. Merge them and it becomes your most-requested feature. That changes your roadmap. It also saves real time. Manual deduplication on a high-volume board isn't a task, it's a job. AI handles the first pass, and a human reviews flagged matches before anything gets merged. ## The threshold tradeoff A tight threshold flags only very close matches, which is safe but misses a lot. A loose threshold catches more, but you'll review false positives. Most teams tune based on false positive rate over time. The goal isn't perfect automation. It's removing 80% of the manual work so your team can focus on the judgment calls. --- ## Ansoff Matrix Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/ansoff-matrix The **Ansoff Matrix** is a strategy framework that maps four ways a company can grow, organized along two axes: products (existing vs. new) and markets (existing vs. new). Igor Ansoff introduced it in 1957, and it's still useful for forcing clarity about what kind of growth you're actually chasing. **Market Penetration** is selling more of what you already have to existing customers. More marketing, better retention, competitive pricing. It's the lowest-risk quadrant, and where most teams spend most of their time without realizing it. **Market Development** means taking your existing product into new markets, a new geography, a different customer segment, or a new use case. You're not changing the product much, just finding new buyers for it. **Product Development** is building something new for your existing customers. You know them and their problems. This is where a lot of SaaS expansion revenue comes from. **Diversification** is the high-risk quadrant: new product, new market. Both variables change at once. It's why acquisition-driven growth stories often end up messier than the press release suggested. For product teams, the matrix forces a useful question: which quadrant does each initiative actually live in? Building a feature for current users is fundamentally different from adding a vertical to reach a new buyer. They require different resources and different [roadmap](/roadmaps) sequencing. --- ## Beta Testing Category: Product Operations · Canonical: https://featureos.com/glossary/beta-testing **Beta testing** is releasing a feature to a limited group of users before it goes to everyone. You watch what happens, fix what breaks, and decide if it's ready for general availability. In software, alpha usually means internal testing. Beta means limited external release. General availability (GA) is when it goes to all users. ## Closed vs. open beta **Closed beta** means you invite specific users, people who requested the feature, customers on a particular plan, or users who've agreed to give feedback. You get more targeted signal. **Open beta** means anyone can opt in, often via a "try it early" toggle or a waitlist. You get more volume, but less focused feedback. ## What makes it actually useful Go in with specific questions, not just a hope that nothing breaks. "Did it break anything?" is a fine goal, but "do users understand how to set this up without documentation?" is better. Beta users are often your highest-quality signal. They signed up knowing the feature wasn't finished, so they pay closer attention and report edge cases you'd otherwise miss. Once you've got results, loop them into your [roadmap](/roadmaps) before the full launch. Beta findings almost always surface at least one thing worth fixing before you go wide. --- ## Changelog Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/changelog A **changelog** is a record of what's new in your product. Every time you ship something meaningful, a new feature, a significant improvement, a long-awaited bug fix, you write it down in plain language for the people using your product. Customers don't experience your product the way your team does. They might log in once a week or once a month. Without a changelog, they miss what changed, and the work your team shipped goes unnoticed. ## Best practices **Write for humans, not engineers.** "Fixed an edge case in the webhook retry logic" means nothing to a customer. "Webhooks now retry automatically if your endpoint is temporarily down" does. **Ship it when you ship the feature.** A changelog that's weeks behind loses its value. The best ones go out the same day. **Keep entries short.** Two to four sentences is usually enough. Link to a help article if something needs more explanation. **Be consistent.** A changelog updated sporadically is hard to trust. Even a short entry every two weeks builds more confidence than infrequent posts every few months. It's also one of the most underrated tools for closing the feedback loop. When you ship something a customer asked for, pointing them to the changelog entry is an easy way to say "we heard you." Publish and share your product updates with [FeatureOS Release Notes](/release-notes). --- ## Churn Rate Category: Product-Led Growth · Canonical: https://featureos.com/glossary/churn-rate **Churn rate** is the percentage of customers who stop using your product in a given time period. Monthly churn = (customers lost / customers at start of month) x 100. If you started January with 200 customers and lost 10, your monthly churn is 5%. Annual churn isn't just monthly churn times 12, it compounds. A 5% monthly churn is closer to 46% annually, not 60%. ## What "good" looks like It depends on your market. Consumer SaaS can survive higher churn because acquisition is cheaper. Enterprise SaaS aims for sub-5% annual churn. If you're charging $500/month per seat, losing 10% of customers per year is a very different problem than at $10/month. ## Churn is a symptom, not a cause Users who never got value from your product churn because of an onboarding problem. Power users churn when a competitor ships something better. Budget customers churn when the economy tightens. Lumping all churn together hides the actual diagnosis. Look at churned accounts: when did they stop logging in? What features did they never use? What support tickets did they open? There's usually a pattern. Your [customer surveys and forms](/forms-and-surveys) are one of the best tools for catching churn signals before someone cancels. Ask why. People will tell you. --- ## Closing the Feedback Loop Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/closing-the-feedback-loop **Closing the feedback loop** is the process of collecting customer feedback, acting on it, and then telling the customer what you did. Most teams nail the first two steps and drop the third entirely. That third step is what makes it a loop. Without it, customers have no idea if their input mattered. They start to feel like they're shouting into a void, and they stop giving you feedback, which means you lose the signal you actually needed. ## Why teams skip it It's usually a process problem, not laziness. Feedback comes in through multiple channels, gets triaged, lands in a backlog, and ships six months later as part of a larger release. By then, nobody has gone back to find the original request, tag it, and notify the customer who submitted it. ## What good looks like The best teams build loop-closing into their release workflow, not as an afterthought. They track which feedback items influenced a decision, and when that feature ships, they notify the customers who asked for it. It doesn't need to be a long message. "Hey, you asked about X six months ago, we just shipped it" is enough to make someone feel heard. Publish your release updates with [FeatureOS Release Notes](/release-notes) and let customers follow along on your [Feedback Board](/boards). When you connect the two, the loop closes itself. --- ## Continuous Discovery Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/continuous-discovery **Continuous discovery** is the practice of talking to customers on a recurring cadence so that product decisions are always grounded in current customer context. It's not a research phase with a start and end date. It's a habit. The term comes from Teresa Torres. The core idea: if you're only talking to customers before big launches or when something breaks, you're already too late. By the time a research sprint wraps up, the team has usually already made the decisions it was meant to inform. ## What it looks like in practice It doesn't mean running formal usability studies every week. Continuous discovery is usually lighter, short structured interviews, quick customer calls, or regular observation of how people use your product. The goal is to stay close enough to customers that insights arrive as a steady stream, not a flood. When your team reviews what to work on next in [FeatureOS Boards](/boards), you want to be drawing from recent, specific conversations, not month-old survey data. ## Why most teams skip it Talking to customers takes coordination and doesn't produce a deliverable. When the backlog is full and the sprint is starting, customer calls feel like a distraction. But teams that keep the cadence tend to waste less time building things nobody wants. One weekly interview beats three weeks of post-launch scrambling. --- ## Cost of Delay Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/cost-of-delay **Cost of Delay** is the value you lose for every week a feature isn't shipped. It asks a simple question: if we don't ship this for another week, what does that actually cost us? Not in vague "missed opportunity" terms, in dollars, churn, or competitive ground lost. Don Reinertsen popularized the concept as part of lean product development. Delay has a price, and that price stays invisible until you make it explicit. ## Why it changes prioritization Most teams prioritize by effort. A quick win that nobody cares about is still a waste. **Cost of Delay** flips the lens, you start with value at risk, then compare it to how long something takes. That ratio is called **CD3** (Cost of Delay Divided by Duration), and it's one of the most honest prioritization signals you can calculate. Example: Feature A takes 4 weeks and loses $10k/week of value by waiting. Feature B takes 1 week but only loses $5k/week. CD3 for A is 2.5, CD3 for B is 5. Ship B first, even though A sounds bigger. ## Making the estimates You still have to estimate delayed value, which is hard. But rough estimates beat gut feel. "Somewhere between $5k and $20k per week" is more useful than "it feels important." If you're using a [roadmap](/roadmaps) to communicate priorities, Cost of Delay gives you something concrete to point at when stakeholders ask why one thing is above another. --- ## Customer Advisory Board Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/customer-advisory-board A **customer advisory board (CAB)** is a small group of key customers, typically 8 to 15, who meet with your leadership team on a regular cadence to give strategic input on product direction. They're not just power users who like talking to you. They're customers whose business outcomes are meaningfully tied to where your product goes. A CAB isn't a [feedback board](/boards), which is asynchronous and open to everyone. It's not a user research panel, and it's not a sales reference program. Companies that blur that last line end up with a board full of cheerleaders who don't say anything useful. ## What makes it valuable The value of a proper CAB is the depth of conversation you can't get from a survey. You can share early thinking, test strategic hypotheses, and hear how your positioning lands with people who actually bought into it. They'll tell you things they wouldn't type into a feedback form. ## Getting composition right Diversity matters more than size. You want different company sizes, different use cases, different levels of product sophistication. A board that's all enterprise customers won't give you useful signal about mid-market problems. Run it with a real agenda and specific questions. Don't use it as a demo session. The best CABs feel like a strategy conversation. And close the loop. When a CAB member raises something that changes your direction, tell them. Nothing kills engagement faster than feeling like the input went nowhere. --- ## Customer Effort Score Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/customer-effort-score **Customer Effort Score (CES)** is a survey metric that measures how easy it was for a customer to complete a specific task, like resolving a support issue or finishing onboarding. The standard question is: "How easy was it to [do the thing]?" on a 1-7 scale from Very Difficult to Very Easy. ## Why effort matters Reducing friction builds loyalty more reliably than delighting customers. Customers who have to jump through hoops don't stick around, even if the core product is good. High-effort experiences are a quiet churn driver that NPS often misses. ## CES vs NPS They measure different things. - **NPS** is a relationship metric. Send it periodically to understand overall loyalty. - **CES** is a transactional metric. Send it right after a specific interaction, like finishing onboarding or closing a support ticket. Use NPS for general sentiment, CES to find out if a specific workflow is frustrating. CES is especially useful when ease of use is a competitive differentiator. Set up targeted CES surveys at the right moments with [FeatureOS Forms and Surveys](/forms-and-surveys). --- ## Customer Health Score Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/customer-health-score A **customer health score** is a composite metric that predicts how likely a customer is to churn, renew, or expand. It combines multiple signals into a single number so your team can act before problems escalate. No single signal tells the full story. A customer might skip your emails but use the product daily. Or they might have strong usage stats but quiet frustration. The health score combines signals to give you a more honest picture. ## What goes into it There's no universal formula, but most B2B teams pull from the same inputs: - **Product usage**, frequency, depth, which features they're actually using - **Support tickets**, volume, sentiment, how often issues escalate - **NPS or CSAT**, how they've rated the product when asked directly - **Engagement**, QBR attendance, doc reads, webinar signups Check out the [FeatureOS customer health score tool](/tools/customer-health-score) for a starting point that combines feedback signals with usage data. ## Why it beats gut feel Customer success teams have good instincts, but those instincts don't scale. At 50 accounts, you can feel when something's off. At 500, you need a system. A well-tuned health score lets you act before a customer decides to leave, not after. --- ## Customer Sentiment Score Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/customer-sentiment-score **Customer sentiment score** is a composite metric that tracks how customers feel about your product over time. It's built by combining signals like NPS, CSAT, support ticket language, and third-party review data into a single score. It's not a single official standard. Most B2B SaaS teams define their own formula based on what matters to their business. ## How teams calculate it Common inputs include: - **NPS** for long-term loyalty - **CSAT** for how a specific interaction went - **Review sentiment** from G2, Capterra, or similar sites - **Support ticket language** to surface frustration before a customer fills out any survey Some teams use simple averages. Others assign weights based on their product's service model. There's no universal formula, and that's fine. ## Why it matters for product decisions Sentiment gives you a signal that's harder to game than usage metrics. Usage can spike because you forced users into a flow. Sentiment is what they actually feel. When sentiment drops and you can't point to a specific change, something has probably been quietly bothering users for a while. When it rises, it confirms you shipped the right things. Collect the raw feedback that feeds your sentiment score using [FeatureOS Forms and Surveys](/forms-and-surveys). --- ## DACI Framework Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/daci-framework **DACI** is a decision-making framework that assigns four roles to every significant decision: Driver, Approver, Contributor, and Informed. It's a tighter alternative to RACI, built for teams that need to move fast without relitigating decisions later. The roles: the **Driver** owns the process and is accountable for pushing it to completion. The **Approver** has final say (one person, not a committee). **Contributors** provide input and expertise. **Informed** people are told the outcome after the fact. ## Why DACI beats RACI for product teams RACI muddies the line between who does the work and who decides. In product development, that distinction matters. You want engineers contributing without being dragged into every approval chain. You want a single Approver so the Driver isn't chasing sign-off from six people. DACI makes that explicit. One Approver. If two people are listed as Approvers, you have a committee, and committees slow things down. ## How to use it Before any meaningful decision, a major [roadmap](/roadmaps) call, a product direction shift, a design trade-off, write down who's driving it, who approves it, who's contributing input, and who just needs to know the outcome. It takes two minutes and prevents weeks of "wait, who decided this?" conversations. The real cost of skipping it isn't missed meetings. It's decisions that get relitigated after they were supposed to be done. --- ## Feature Factory Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/feature-factory A **feature factory** is a product team that measures success by features shipped rather than outcomes achieved. Features go out the door on schedule, the roadmap keeps moving, and everyone looks busy, but nobody's asking whether any of it actually made the product better. John Cutler popularized the term. It stuck because the pattern is extremely common and hard to escape once you're in it. ## What it looks like from the inside The backlog is always full. Stakeholders add to it constantly. The team's job is to execute: estimate, build, ship, repeat. Discovery is thin or skipped entirely. Success is measured in features delivered, not problems solved. You can read more about how this plays out in practice on the [FeatureOS blog](/blog/feature-factory). ## Why it's hard to break out of Feature factories don't usually start that way. They evolve from good intentions, a team trying to be responsive to customers, to leadership, to the market. Over time, that responsiveness calcifies into a delivery machine. Breaking out requires changing what you measure. If your team is only accountable for shipping, that's what you'll get. Tie work to outcomes like retention, activation, or revenue, and the calculus changes. ## The fix isn't to ship less It's to ship things that matter. A team shipping half as many features but moving the needle is doing better work than a team hitting every sprint target without knowing why. --- ## Feature Flag Category: Product Operations · Canonical: https://featureos.com/glossary/feature-flag A **feature flag** is a conditional in your code that shows a feature to some users and hides it from others. It's also called a feature toggle or feature switch. You deploy the code, but the feature stays off until you're ready to enable it. The core use case is safe releases. Merge the code, deploy it, flip the flag when you're ready. If something goes wrong, flip it back. No rollback, no hotfix, no incident at 2am. ## What else they're good for Feature flags enable a lot beyond safe deploys: - **Percentage rollouts**, show to 5% of users, then 20%, then 100% - **[Beta testing](/glossary/beta-testing)** without a separate environment - **A/B tests** on the same codebase - **Tiered feature sets** for different plans or enterprise customers - **Soft launches** to a single customer while you finish polishing Separating "code is deployed" from "feature is live" means your deployment pipeline can run more frequently, which reduces risk on every deploy. Continuous delivery stops feeling dangerous. ## The downside: flag debt Every flag you create is a branch in your logic that you'll eventually have to clean up. Make flag removal part of your definition of done. When a feature goes fully live, the flag comes out. Tie your [roadmap](/roadmaps) milestones to specific flags so you always know exactly what's live for who. --- ## Feature Request Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/feature-request A **feature request** is when a customer tells you something they wish your product could do. It might come through a support chat, a survey, a public feedback board, a sales call, or a random email. The format doesn't matter. What matters is that someone took the time to ask. Feature requests are one of the most direct signals you have about what customers actually need, not what you think they need. ## Why tracking them matters Most teams get feature requests constantly. Without a system, those requests pile up in Slack threads, inboxes, and spreadsheets, then get lost. Six months later, nobody can remember what customers actually asked for. Tracking gives you: - **Volume signal.** If 40 customers asked for the same thing, that's different from one customer asking once. - **Context.** Who asked, when, what they were trying to do. This makes prioritization defensible. - **A loop to close.** When you build it, you know exactly who to tell. ## How feature requests feed into roadmaps Not every request becomes a roadmap item. But the pattern of requests tells you where the pain is. When you're deciding what to build next, a well-organized backlog of requests is one of the most useful inputs you have. Collect, organize, and prioritize feature requests from your customers using [FeatureOS Boards](/boards). --- ## Feedback Board Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/feedback-board A **feedback board** is a dedicated space where customers submit product ideas and vote on each other's suggestions. Instead of requests scattered across email and Slack, they land in one place where everyone can see them. Boards can be public (visible to anyone) or private (visible only to logged-in customers). Most B2B SaaS teams start private, then open up once they're comfortable with the format. ## How they work A customer visits the board, searches for existing requests, and either votes on one or submits a new one. The product team adds statuses like "Under Review," "Planned," "In Progress," and "Shipped" so customers know where things stand. The voting mechanism is what separates boards from a plain inbox. It surfaces the most-wanted features naturally, so you're seeing what matters to the most people, not just the loudest voices. ## Why boards are worth the investment The alternative is a spreadsheet or shared doc that nobody maintains. Boards give you organized, quantified input that makes prioritization conversations less subjective. They also do something underrated: they show customers you're listening. When someone submits an idea and checks back two months later to see it moved to "Planned," that's a small moment of trust-building email threads can't replicate. Public boards can also reduce duplicate support tickets. Customers check the board first, see their issue is already known, and don't need to open a ticket. Set up your feedback board with [FeatureOS Boards](/boards). --- ## Freemium Category: Product-Led Growth · Canonical: https://featureos.com/glossary/freemium **Freemium** is a pricing model where you offer a free version of your product indefinitely, then charge for upgrades. The free plan isn't charity. It's distribution. Users find you, try you, trust you, and then pay you without a sales call or contract negotiation in between. ## Why it works People don't buy things they haven't tried. Freemium removes that friction entirely. You get users in before the purchase decision, which gives you time to show them value. If the product's good, conversion follows. It also creates network effects when the free tier is collaborative. Every user who invites a teammate on a free plan is doing your growth work for you. ## The traps Free plans are expensive to operate. You're serving users who might never pay. The math only works if your conversion rate and average contract value are high enough to cover the cost of your free base. A lot of companies get this wrong and end up subsidizing churn. The other trap is a free plan so limited it can't demonstrate value. If users hit a wall before they understand why the product matters, they leave. The free tier has to be genuinely useful, just not infinitely useful. [FeatureOS offers a 14-day free trial](/pricing) built around this logic: enough to feel the value, enough to want more. --- ## Hallucination Rate Category: AI & Machine Learning · Canonical: https://featureos.com/glossary/hallucination-rate **Hallucination rate** is the percentage of AI outputs that contain false or fabricated information presented as fact. The model isn't lying. It doesn't know it's wrong. That's what makes it a real problem. For product managers building on top of [AI](/ai), hallucination rate isn't a hypothetical concern. It's a metric you have to track. ## How PMs measure it You can't measure hallucination rate automatically unless you have ground truth to check against. The most common approach is human evaluation: sample AI outputs, verify them against a known source, and record the failure rate. If you're building AI-generated summaries of customer feedback, pull a sample, read the originals, and check whether the summary invented any claims. Over time, you build a benchmark. Some teams use a secondary AI call to evaluate the first, an LLM-as-judge pattern. It's faster than manual review, but you're trusting a model to catch another model's mistakes, which has its own failure modes. ## Why PMs care Hallucination isn't just a technical metric. It's a trust metric. If users catch your AI feature saying something false once, they second-guess it forever. The acceptable rate depends entirely on the stakes. Summarizing feature requests? Users will tolerate an occasional slip. Generating legal text? Zero tolerance. Set your acceptable rate before you ship. Then instrument for it. "We'll watch it after launch" is not a plan. --- ## In-App Survey Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/in-app-survey An **in-app survey** is a survey that appears inside your product while someone is actively using it, rather than in a follow-up email or on a separate page. The timing is what makes them effective. When a customer just completed onboarding, used a feature for the first time, or hit a friction point, a short 2-3 question survey takes 20 seconds and they're back to what they were doing. Response rates typically run 3-5x higher than email surveys. ## When to use them In-app surveys work best for **transactional moments**: right after a key action, at the end of a flow, or when you want to catch early churn signals. They're not suited for deep open-ended questions that require reflection. Use them to collect CSAT or CES scores after a specific interaction, test whether a new feature is landing as expected, or identify friction before it shows up in your quarterly NPS. The trigger matters. A survey that fires too early, too often, or mid-task feels like an interruption. Get the timing right and it feels like you care about the experience. Build targeted in-app surveys with [FeatureOS Forms and Surveys](/forms-and-surveys). --- ## Jobs To Be Done Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/jobs-to-be-done **Jobs To Be Done (JTBD)** is a product development framework built on the idea that customers don't buy products, they hire them to accomplish a specific goal. The job is the outcome they need, not the feature they ask for. The classic version of this: people don't want a quarter-inch drill, they want a quarter-inch hole. That reframe changes what you build. ## How it works JTBD pushes you to write job statements instead of feature requests. The format is: "When [situation], I want to [motivation], so I can [outcome]." It looks like a user story, but the focus is on the outcome, not the action. When you focus on the job, you sometimes find a simpler solution the customer never would have thought to ask for. You also see your real competition more clearly. If someone hires your app to "keep track of customer requests," they might be replacing a spreadsheet or a Slack channel, not a competitor product. ## Where to apply it Customers aren't always good at articulating their jobs. You have to dig through support tickets, sales calls, and your [feedback boards](/boards) to find the patterns. The feature requests are the symptoms. The job is the diagnosis. Use JTBD when evaluating what to build next, when scoping features that feel vague, or when your roadmap has drifted away from real customer problems. --- ## Kano Model Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/kano-model The **Kano model** is a framework for categorizing product features by how they affect customer satisfaction. Developed by Noriaki Kano in the 1980s, it helps teams decide what to build next by distinguishing between features customers expect, features they value, and features that genuinely delight them. ## The three categories **Basic features** are expected. Customers don't mention them when they exist, but they're furious when they don't. A save button is a basic feature. **Performance features** scale linearly with satisfaction. The faster your search, the happier the user. More of these is always better. **Excitement features** (delighters) are things customers didn't know they wanted. Finding them creates loyalty that performance improvements alone can't match. ## Why it's useful Not all feature requests carry the same weight, even when customers ask for them the same way. A request might be a basic expectation you've missed, or a nice-to-have that sounds important but won't move retention. Kano also prevents feature bloat. Adding excitement features doesn't help if your basics are broken. Fix the foundation first. One catch: categories shift over time. Last year's delighter is this year's basic expectation. Re-run the analysis periodically. Apply Kano before committing to anything on your [roadmap](/roadmaps). --- ## Knowledge Base Category: Product Operations · Canonical: https://featureos.com/glossary/knowledge-base A **knowledge base** is a collection of articles, guides, and how-tos that lets customers answer their own questions without contacting support. The goal is self-serve: customers find what they need, your team stays unblocked. ## Why it reduces support tickets Every support ticket has a cost. Even a small team fielding 50 tickets a week burns real hours on questions that good documentation could answer. A knowledge base deflects the repetitive ones at all hours, including time zones your team isn't covering. That's a better customer experience and less load on your queue. ## What makes one actually useful Articles need to be findable. A knowledge base with 200 articles and poor search is nearly useless, customers give up fast. Good search, clear categories, and logical naming make the difference. Write to match what customers are searching for, not your internal terminology. If customers say "export to PDF" but your article is titled "Document rendering options," they won't find it. Keep articles current. Outdated documentation is a trust problem. When customers follow instructions that stopped working six months ago, you get a support ticket and lost confidence at the same time. Build and manage your customer-facing docs with [FeatureOS Knowledge Base](/knowledge-base). --- ## Microsurvey Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/microsurvey A **microsurvey** is a 1-3 question survey shown inside your product at a specific moment, triggered by a user action rather than a scheduled email blast. It's designed to capture feedback when the experience is fresh, not a week later. The contrast is a traditional 20-question survey sent on the first of the month. It gets a 4% open rate, answered mostly by people at the extremes. The normal users stay quiet. ## How microsurveys work Instead of pulling people out of your product to fill out a form, you catch them mid-session. Just finished onboarding? One question. Just exported a report? One question. Just cancelled? Three questions max. **Response rates are dramatically higher**, sometimes 10x compared to email surveys, because you're asking when the experience is vivid. ## When to use them They work best for transactional moments: NPS after a milestone, CSAT after a support interaction, quick sentiment checks after a new feature launch. If you need deep qualitative insight, a longer interview is still better. Microsurveys are for high-frequency, low-friction signal. The trigger is everything. A microsurvey shown at the wrong time is just annoying. Shown right after a key action, it feels natural. Set them up with [FeatureOS Forms and Surveys](/forms-and-surveys) wired to your product events, and you'll start learning from moments that used to be invisible. --- ## MoSCoW Prioritization Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/moscow-prioritization **MoSCoW prioritization** is a backlog triage method that sorts work into four buckets: Must-have, Should-have, Could-have, and Won't-have. It's built for teams staring at a long list with no obvious starting point. **Must-have** means the product doesn't ship without it. **Should-have** means important, but you could survive one release without it. **Could-have** means nice to have if time allows. **Won't-have** means explicitly out of scope for this cycle. ## Why the Won't-have bucket matters Won't-have isn't a trash can. It's a decision. Explicitly calling something out of scope stops teams from relitigating it in every planning meeting. That alone saves hours. ## Where it breaks down The failure mode is when everything ends up in Must-have. If more than 30-40% of your backlog is labeled Must, your team hasn't made real decisions yet. Push back. Ask: "What actually breaks if we ship without this?" MoSCoW also doesn't account for effort. A quick win and a six-month epic can both be Must-haves. Pair it with effort estimates to do real planning. It works best at the start of a planning cycle or when scoping something new. Use [FeatureOS's MoSCoW tool](/tools/moscow-prioritization) to keep everyone on the same page. --- ## Net Promoter Score Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/net-promoter-score **Net Promoter Score (NPS)** is a customer loyalty metric based on one question: "How likely are you to recommend us to a friend or colleague?" Customers respond on a 0-10 scale. You subtract the percentage of detractors from the percentage of promoters to get your score. ## The 0-10 scale - **Promoters (9-10):** Fans. Likely to refer others and stick around. - **Passives (7-8):** Satisfied but not enthusiastic. They won't hurt you, but they won't drive growth either. - **Detractors (0-6):** Unhappy customers who may churn or warn others away. ## How to calculate NPS NPS = % of Promoters minus % of Detractors. Passives don't factor in. If 60% are Promoters and 15% are Detractors, your NPS is 45. Scores range from -100 to +100. Above 0 is decent. Above 50 is considered excellent in most SaaS categories. ## When NPS is useful and when it's not NPS is good for tracking loyalty trends over time. A score that drops quarter over quarter is a signal something's wrong. A score that rises after a major release confirms you shipped the right thing. Where it falls short: it's a lagging indicator. By the time someone rates you a 3, the damage is done. The score alone tells you nothing about why. The real value is in the follow-up question: "What's the main reason for your score?" Run your NPS surveys directly inside your product with [FeatureOS Forms and Surveys](/forms-and-surveys). --- ## OKR Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/okr **OKR** stands for Objectives and Key Results. An Objective is a qualitative, directional goal, like "become the go-to tool for product teams." Key Results are 3-5 specific metrics with targets that tell you whether you got there. The framework came out of Intel, was popularized by Google, and is now standard at most growth-stage tech companies. The core idea: if everyone's working hard in different directions, nothing compounds. ## Why it works OKRs create alignment without micromanagement. Instead of telling people what to do, you define what success looks like. A team with clear OKRs can make daily decisions autonomously because they know what they're optimizing for. The best OKRs are uncomfortable. If you hit 100% of your key results every quarter, your targets are too easy. Aim for 70-80% achievement. ## Why it fails OKRs fail when they become a reporting exercise. Teams write them because they have to, not because they're driving decisions. You end up with 20 key results per team that nobody reads after Q1 kickoff. The other failure mode is **vanity metrics**. Key results need to measure outcomes, not output. "Ship five features" is output. "Increase weekly active users by 20%" is an outcome. If you're connecting OKRs to your [roadmap](/roadmaps), every roadmap item should trace back to a key result. If it doesn't, it's worth asking why it's there. --- ## Opportunity Solution Tree Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/opportunity-solution-tree An **opportunity solution tree (OST)** is a visual framework from Teresa Torres that maps the path from a business outcome to the customer problems that could get you there, and then to the solutions and experiments you're running. It's a literal tree structure, not a metaphor. The root is your desired outcome. The branches are opportunities, unmet customer needs or pain points. Below each opportunity are potential solutions. At the leaves are the experiments you're running to validate those solutions. ## Why it helps Without a structure like this, product teams tend to jump straight from "business goal" to "build this feature." The OST keeps you in problem space longer. Before deciding what to build, you have to name the opportunity you're addressing. It also makes your thinking visible. Stakeholders can see why you're working on what you're working on, not just what's on the [roadmap](/roadmaps). ## How it connects to continuous discovery The OST isn't a one-time artifact. You update it as you learn. When a customer interview surfaces a new opportunity, you add a branch. When an experiment fails, you remove or deprioritize a solution. Teresa Torres introduced the OST as part of her continuous discovery framework. The tree is where your discoveries land, keeping research and roadmap decisions connected rather than siloed. --- ## Pirate Metrics Category: Product-Led Growth · Canonical: https://featureos.com/glossary/pirate-metrics **Pirate Metrics** is the AARRR framework, coined by Dave McClure, that breaks SaaS growth into five measurable stages: Acquisition, Activation, Retention, Revenue, and Referral. The name comes from the acronym sounding like a pirate. It's meant to be used, not admired. Each stage tracks a different part of the user journey. Together they show you exactly where growth is leaking. ## The five stages **Acquisition** is how users find you: search, ads, content, word of mouth. **Activation** is when a user first gets real value from the product. Not signing up. Actually doing something useful. Retention is whether they come back. It's the most honest signal of product quality. Revenue is conversion from free to paid, or expansion from existing customers. Referral is users bringing in other users, which lowers acquisition costs over time. ## How to use it Pick the stage with the worst numbers and fix it before moving to the next. You can't optimize everything at once. Most teams find their activation or retention is worse than they assumed. Track your [feedback boards](/boards) to see if users are getting enough value to return. --- ## Product Operations Category: Product Operations · Canonical: https://featureos.com/glossary/product-operations **Product operations** is the function that keeps product teams running efficiently by owning data, tooling, and process. It's distinct from product management. Product ops is what makes PM work possible in the first place. A product ops person or team ensures the roadmap tool is clean, data pipelines are connected, templates are consistent, and everyone's working from the same source of truth. ## What product ops actually does **Data hygiene** prevents different teams from making decisions off different numbers. Without it, you end up arguing about whose spreadsheet is right. **Tool management** keeps the product stack from becoming a graveyard of half-connected apps. Product ops decides what stays, what goes, and how everything connects, including the [integrations](/integrations) that tie your feedback workflow to the rest of your tools. **Process standardization** writes the playbooks for discovery, prioritization, and review cycles so the team isn't reinventing them every quarter. ## Why it matters Coordination cost grows fast as teams scale. Product ops absorbs that friction before it slows shipping. Done well, it's invisible. Done poorly, PMs spend half their time on logistics instead of product thinking. --- ## Product Qualified Lead Category: Product-Led Growth · Canonical: https://featureos.com/glossary/product-qualified-lead A **Product Qualified Lead (PQL)** is a free user who has taken specific actions in your product that signal they're ready to buy, or close to it. Unlike an MQL (Marketing Qualified Lead), who showed interest by downloading content or attending a webinar, a PQL showed interest by using the product. They've already experienced value and are now hitting limits that only a paid plan can solve. The conversion difference is real. PQLs typically convert at 25-30%. MQLs hover around 5-10%. The gap exists because PQLs already know what the product does. There's no education phase. The sales conversation starts from a completely different place. **PQL signals** vary by product. A free user who invited three teammates, hit the usage limit three times in a week, or visited pricing twice before returning to the core feature, these are all potential signals. You define them based on what your data shows happens before users upgrade. PQLs let product-led companies run leaner sales teams. Instead of cold outreach, sales talks only to people who've already sold themselves. Check your [feedback boards](/boards) for signals from active free users showing what's missing between free and paid. --- ## Product Roadmap Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/product-roadmap A **product roadmap** is a plan that communicates what your team is building, why, and roughly when. It's both an internal planning tool and an external communication tool, and most teams use slightly different versions depending on the audience. ## Common formats **Timeline roadmap** plots features against quarters or months. Good for executives who want to see when things ship. Can create false precision if treated as a promise rather than a plan. **Now-Next-Later** is the most honest format for fast-moving teams. "Now" is what you're actively building. "Next" is queued up. "Later" is directional, not scheduled. The further out something is, the less certain you should be about it. ## Who the roadmap is for Your team needs detail for day-to-day decisions. Customers want to know if their request is coming. Executives want to see strategy in the plan. Sales and CS need enough to set accurate expectations. The common mistake is building one roadmap and showing it to everyone. The format that works for engineering rarely works for a sales call. Share a customer-facing roadmap that builds trust with [FeatureOS Roadmaps](/roadmaps). --- ## Product-Led Growth Category: Product-Led Growth · Canonical: https://featureos.com/glossary/product-led-growth **Product-led growth (PLG)** is a go-to-market strategy where the product itself drives acquisition, conversion, and retention, rather than a sales or marketing team. Users try the product, get value from it, and upgrade on their own, often without ever talking to anyone on your team. The three mechanics behind PLG are **freemium** (let people use the core product for free), self-serve onboarding (no demo required to get started), and viral loops (collaboration or sharing built into the product so users bring in others naturally). PLG shifts what your whole company optimizes for. Marketing focuses on signups and activation. Engineering cares about time-to-value. Support keeps free users around long enough to convert. It only works if the free experience demonstrates real value. A free tier that's too limited isn't PLG, it's a frustrating trial. PLG also changes your growth economics. You're betting on product quality and signup volume instead of outbound sales. That's a deliberate tradeoff. If you're exploring a [free trial](/pricing) for your product, you're already thinking in PLG terms. --- ## Product-Market Fit Category: Product-Led Growth · Canonical: https://featureos.com/glossary/product-market-fit **Product-market fit (PMF)** is the point where your product satisfies a strong market demand. Customers are getting real value, returning on their own, and telling others, and growth starts pulling you forward instead of you pushing it uphill. Marc Andreessen defined it as "being in a good market with a product that can satisfy that market." Simple to state, hard to achieve. ## How you know you have it The clearest signal is retention. If users sign up, get value, and come back repeatedly, something's working. If they sign up, poke around, and disappear, you don't have PMF yet. Sean Ellis's "40% test" is a useful measure: ask users how they'd feel if they could no longer use your product. If 40% or more say "very disappointed," you're likely close. Track this feedback in [FeatureOS Boards](/boards) to spot patterns across your user base. ## Why it's not permanent PMF isn't binary and it doesn't stay fixed. You can have strong fit with an early niche and lose it when you try to expand. You can also find it in a segment you didn't originally target. Most teams get there through iteration: customer conversations, discarded ideas, and eventually finding the version of the product where things click. The milestone is real. The path rarely goes as planned. --- ## Prompt Engineering Category: AI & Machine Learning · Canonical: https://featureos.com/glossary/prompt-engineering **Prompt engineering** is the practice of writing instructions for AI models that produce consistent, useful outputs in production, not just once in a test. It's part writing, part debugging, part documentation. It's not purely an engineering job. Product managers are often good at it because they're used to writing requirements that others can act on without ambiguity. Same skill, different audience. ## What it involves A good prompt tells the model its role, gives it the right context, constrains the output format, and handles edge cases. You don't say "summarize this feedback." You specify what kind of summary, how long, what to emphasize, what to leave out, and what to do if the input is empty. The difference between a vague prompt and a specific one is the difference between an output you have to rewrite and one you can ship directly. ## It's a PM skill When building [AI](/ai) features, someone has to own the prompt layer. If nobody does, engineers write something that technically works and PMs wonder why the output is always slightly off. That's a prompt problem, not a model problem. Write prompts the same way you'd write acceptance criteria: precisely, with examples, with defined failure states. Prompt changes are also instant deploys, so iteration is fast. --- ## Public Roadmap Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/public-roadmap A **public roadmap** is your product direction shared externally with customers. It typically shows three states: planned, in progress, and shipped. Users can see what you're building, understand why a requested feature is a few cycles out, and feel informed rather than ignored. The practical benefits are real. It cuts down "is this on your roadmap?" support tickets, helps prospects make purchase decisions, and signals that you're confident in your direction. A public roadmap is a statement of intent, not a contract. You don't need hard dates on everything. "Planned" is honest. "We're considering this" is honest. What's not honest is telling prospects a feature ships in 60 days when you don't actually know. Only put things on a public roadmap that you've committed to investigating or building. Speculative ideas belong in an internal backlog. Vague is fine. Wrong is damaging. A well-run public [roadmap](/roadmaps) also creates a feedback loop. Customers vote, comment, and surface use cases you hadn't considered. It turns a one-way announcement into a conversation. Teams that avoid public roadmaps usually aren't protecting strategy. They're avoiding accountability. --- ## Release Notes Category: Product Operations · Canonical: https://featureos.com/glossary/release-notes **Release notes** are the document that ships alongside a specific version or update, answering one question: what changed? New features, bug fixes, deprecations, known issues. One release, one set of notes. They're often confused with a changelog, but they're not the same thing. A [changelog](/release-notes) is the running history of everything shipped over time. Release notes are a single entry in that history. Developers integrating your API want to know if anything broke. Admins managing enterprise accounts need to know what changed before their users ask. Power users notice every UI shift. If you don't write release notes, these people get surprised in production. Good release notes are short and specific. "Improved performance" tells nobody anything. "Dashboard load time reduced by 40% for accounts with over 1,000 items" is useful. Skip the marketing language. Just say what changed and what it means for the reader. The format is simple: a short summary at the top, then a grouped list of new features, improvements, bug fixes, and deprecations. If a change requires user action, call it out explicitly at the top, not buried in the middle. Writing release notes also forces your team to clearly articulate what shipped. If you can't write the note, you might not fully understand what you built. --- ## Retrieval-Augmented Generation Category: AI & Machine Learning · Canonical: https://featureos.com/glossary/retrieval-augmented-generation **Retrieval-Augmented Generation (RAG)** is an AI technique where relevant documents or data are fetched and handed to a language model as context before it generates a response. Instead of answering from memory alone, the model reads the retrieved content and uses it to produce a grounded answer. Think of it as an open-book exam. Fine-tuning is memorization. RAG is letting the model look things up in real time. ## RAG vs fine-tuning Use fine-tuning when you want to change how the model behaves: its tone, format, or domain vocabulary. It's baked into the weights but expensive to update and slow to iterate. Use RAG when you want the model to know current or specific facts: your product docs, customer history, latest pricing. You update the documents and the model has fresh context on the next query. No retraining needed. Most practical [AI](/ai) features in SaaS, including search, support bots, and feedback summarization, use RAG. Fine-tuning is reserved for tasks where behavior change is the actual goal. ## The catch RAG is only as good as the retrieval step. Pull in the wrong documents and the model confidently answers from bad context. Getting retrieval right is where most of the engineering effort actually lives. --- ## RICE Scoring Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/rice-scoring **RICE scoring** is a prioritization framework that assigns a numerical score to each feature or initiative so teams can compare options without relying purely on gut feel. The formula is: **(Reach x Impact x Confidence) / Effort**. Reach is how many users are affected per quarter. Impact is a multiplier (3 = massive, 0.25 = minimal). Confidence is a percentage of how certain you are about your estimates. Effort is person-months to ship. Higher score means higher priority. ## When it's useful RICE works best when you have a large backlog and need a starting point for prioritization conversations. The real value isn't the number. It's the process of writing down assumptions. When you fill in the inputs, you'll often find the team disagrees on what "Reach" even means. That conversation is where the clarity comes from. ## Where it breaks down RICE rewards high-reach, low-effort work. That consistently deprioritizes foundational fixes that matter deeply to your best users but don't touch many accounts. Confidence scores are also largely invented. Being precise about things you're uncertain about is a limitation, not a feature. Use RICE alongside customer feedback from your [roadmap](/roadmaps). Don't treat the score as a verdict. --- ## Self-Serve Onboarding Category: Product-Led Growth · Canonical: https://featureos.com/glossary/self-serve-onboarding **Self-serve onboarding** is a signup and setup experience where users can get value from your product without talking to anyone on your team. No demo call, no onboarding specialist, no waiting for someone to follow up. It's the foundation of product-led growth. If your product can't explain itself, a sales team does it instead, and that team becomes the ceiling on how fast you can grow. ## What good self-serve looks like The goal is fast [time to value](/glossary/time-to-value). How quickly can a new user reach the moment that makes your product worth keeping? Every step between signup and that moment is friction you need to either remove or justify. Good self-serve onboarding has a clear first action, skips unnecessary setup, and gets users to one small win fast. It doesn't front-load settings or ask for information it doesn't need yet. ## Why teams get it wrong Self-serve onboarding is often treated as a UX problem when it's really a product clarity problem. You can't fix a confusing product with better copy. If users don't know what to do first, that's a product signal, not a design one. Teams that get this right track every step of the flow, watch where users drop off, and treat onboarding with the same rigor as any core feature. [FeatureOS's 14-day free trial](/pricing) is built around being set up in minutes, not days. --- ## Sentiment Analysis Category: AI & Machine Learning · Canonical: https://featureos.com/glossary/sentiment-analysis **Sentiment analysis** is the use of natural language processing to automatically classify the emotional tone of text as positive, negative, or neutral. Apply it across thousands of support tickets or feedback submissions and patterns emerge that no one could spot by reading manually. ## Where it works well For high-volume, plainly worded feedback, sentiment analysis is genuinely useful. A model can surface that a recent update is getting disproportionately negative responses before anyone has read through them all. FeatureOS uses this kind of analysis to help teams spot trends in feedback without drowning in it. See the [AI-powered features](/ai) to understand what's being classified. ## Where it breaks down Sarcasm breaks it. "Oh great, another update that made everything slower" often registers as positive because of the word "great." Context-heavy feedback and culturally specific phrasing don't parse reliably either. Short responses like "meh" or "fine" get classified inconsistently. ## How to use it Treat **sentiment scores** as a triage layer, not a final answer. They're useful for directing human attention, not replacing it. "Here's the feedback cluster worth reading" is a good use. "This cluster is definitely negative" is over-trusting the output. The signal is useful. The certainty is not. --- ## Sprint Planning Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/sprint-planning **Sprint planning** is the meeting at the start of every sprint where a team decides what to build in the next one to two weeks. It's a core agile ritual, and what the team commits to here is what actually gets shipped. The typical flow: the product manager walks through the prioritized backlog, the team estimates effort (usually in story points), and together you decide how much fits based on the team's **velocity**, the average story points completed per sprint. ## The common mistake Sprint planning gets treated as a scheduling exercise instead of a product decision. You're not filling capacity. You're deciding what matters right now. The best planning meetings happen when the PM comes in with a clear "why" for each top item. Not "this has been in the backlog for three sprints" but "three enterprise customers asked for this last month and we're losing deals because of it." ## Keep it realistic Optimism in sprint planning creates burnout and broken commitments. Commit to six things and ship six things rather than committing to ten and shipping seven. If your [product roadmap](/roadmaps) is connected to real customer feedback, sprint planning stops being a guessing game and becomes a focused conversation about what's most valuable right now. --- ## Strategy Debt Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/strategy-debt **Strategy debt** is the accumulated cost of repeatedly saying yes to requests that don't fit your product vision. Every one-off feature built for a loud customer, an eager sales rep, or a well-meaning stakeholder, adds to it. Unlike technical debt, there's no code to point to. The codebase might look fine. But the product quietly becomes incoherent. ## How it compounds At first, the one-offs feel like good business. You kept the customer. You closed the deal. Six months later, you have a product that tries to do everything for everyone and does nothing particularly well. Your team doesn't know what to prioritize anymore because the strategy keeps bending around requests. Your [roadmap](/roadmaps) looks like a wish list. Every new feature has to coexist with all the mismatched ones that came before it. ## Why it's harder to see than technical debt With technical debt, an engineer can usually point at the problem. With strategy debt, the dysfunction is spread across dozens of individual decisions that each seemed reasonable at the time. No single bad call, but the pattern of calls degrades the product. The fix is getting clear on what you're building and for whom, then having the discipline to say no to things that don't fit. That's harder than it sounds when a customer is threatening to churn or sales is promising the moon. --- ## Technical Debt Category: Product Operations · Canonical: https://featureos.com/glossary/technical-debt **Technical debt** is the cost of writing code the fast way instead of the right way. A hack to hit a launch deadline. An architecture that made sense in year one but doesn't scale in year three. It's a bill that eventually comes due. Ward Cunningham coined the term, and the financial analogy is intentional. Small amounts of debt are fine, you move faster now and pay it down later. But if you never pay it down, interest accrues. What took an afternoon to build now takes a week to change, because everything's tangled up in the original shortcut. ## How it shows up You know you've got real tech debt when a "simple" feature request turns into a three-week engineering project. Or when onboarding a new engineer means handing them a map of hidden hazards. Teams with heavy debt ship slower over time, not faster, because every new thing they build has to navigate around the old mess. ## What product teams should do Keep **debt paydown** on the [roadmap](/roadmaps). It's not exciting to stakeholders, but it needs dedicated time, not just a vague promise to "clean things up someday." Some teams reserve 20% of each sprint for debt work. Others run periodic cleanup sprints. What doesn't work is pretending it'll sort itself out. It compounds until a full rewrite becomes cheaper than continued maintenance. --- ## Theme-Based Roadmap Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/theme-based-roadmap A **theme-based roadmap** organizes work around strategic outcomes instead of feature lists. Rather than "ship dark mode in Q2," it says "Q2 is about reducing time to first value for new users." Features that help with that go in. Features that don't, wait. ## Why it works better than a feature roadmap Traditional feature roadmaps are lists of promises. Sales shows them to prospects, customers reference them in support tickets, and now you're locked in. When priorities shift, and they always do, you either break promises or ship the wrong thing. Themes are commitments to outcomes, not outputs. "We're focused on onboarding" stays true even as the specific features change. It's honest about how product development actually works. Engineers and designers also make better day-to-day decisions when they understand the why behind a quarter, not just the what. ## How to get started Take your next quarter's planned features and ask: what problem does each one solve? You'll find clusters. Those clusters are your themes. Name them plainly: "faster onboarding," "better reporting," "enterprise security." Not marketing-speak. Three to four themes per quarter is usually plenty. More than that and you don't really have themes, you just have features with labels. If you're already using a [roadmap](/roadmaps) tool, most let you group items by theme. The tooling isn't the hard part. Staying true to a theme when a stakeholder pushes a one-off is where the discipline matters. --- ## Time to Value Category: Product-Led Growth · Canonical: https://featureos.com/glossary/time-to-value **Time to Value (TTV)** is the time between a user signing up and the moment they first understand why your product is worth keeping. The shorter that gap, the more users stick around. In PLG products, TTV is one of the most important metrics you can track. Users don't give you much time. If they can't feel the value in the first session, sometimes the first few minutes, they leave. No sales call is coming to save them. No email sequence brings most of them back. ## The aha moment The **aha moment** is the specific instant where value clicks. For Dropbox, it's watching a file sync automatically. For Slack, it's getting a message from a teammate and realizing conversations are organized. For FeatureOS, it might be seeing your first piece of customer feedback land cleanly on a board instead of in an email inbox. Everything in your onboarding flow should be aimed at reaching that moment faster. ## How to improve it Improving TTV usually means removing steps. Every required field, every "you'll need to do X before Y," every optional setup screen is friction between the user and their aha moment. To measure it: pick your aha moment action (first feedback submitted, first teammate invited, first export), then track the time between signup and that event. Use the median, not the average. Outliers skew averages badly. If new users are asking "how do I do X?" in your [feedback boards](/boards), that's a TTV problem in disguise. --- ## User Story Category: Frameworks & Strategy · Canonical: https://featureos.com/glossary/user-story A **user story** is a one-sentence description of something a user needs, written from their point of view. The standard format is: "As a [type of user], I want [to do something], so that [I can achieve a goal]." So instead of "Build export to CSV," you write: "As a team admin, I want to export feedback to CSV, so that I can share it with stakeholders who don't have product access." Same feature, but now the whole team knows who it's for and why it matters. ## Why the format holds up User stories force you to think about the person using a feature before thinking about the implementation. The "so that" clause is especially important. It tells engineers what problem they're actually solving, which gives them room to find a better solution than the one you described. ## Common mistakes Making stories too big is the most common one. "As a user, I want to manage my account" is an epic, not a story. Break it down until each story can ship in a sprint. Forgetting the "so that" is the second. Without it, engineers are guessing at intent. Writing stories for the business instead of the user is the third: "As an admin, I want to see revenue metrics" is usually a business need wearing a user story costume. User stories work best when they're backed by real customer feedback. If you can link a story to a specific request or quote, every item on your [product roadmap](/roadmaps) becomes easier to defend. --- ## Vector Database Category: AI & Machine Learning · Canonical: https://featureos.com/glossary/vector-database A **vector database** stores text (or images, audio, or other data) as lists of numbers called embeddings. These numbers capture meaning, not just characters. Two sentences that say the same thing in different words end up with similar numbers. Two sentences that sound alike but mean different things end up far apart. That's the shift from keyword search to **semantic search**: matching meaning instead of matching exact words. ## Why it matters for product features Traditional databases can't answer questions like "find all feedback that's basically the same idea." A keyword search misses synonyms. A fuzzy match catches typos but not concepts. A vector database handles this well. You convert text to embeddings, store them, and when a new piece of text comes in, you ask: what's already in here that looks similar? This is what powers [AI](/ai) features like duplicate detection, semantic search, and recommendation systems. ## The practical reality You don't usually build a vector database from scratch. Tools like Pinecone, Weaviate, or pgvector (a Postgres extension) handle the storage layer. The real engineering work is in how you generate and refresh embeddings, and how you tune the **similarity threshold** so "similar" means what you actually want it to mean. The threshold question is PM-relevant. Too tight and you miss obvious duplicates. Too loose and you merge things that shouldn't be merged. That's a product judgment call, not just a technical one. --- ## Vocal Minority Bias Category: Feedback & Sentiment · Canonical: https://featureos.com/glossary/vocal-minority-bias **Vocal minority bias** is when the most opinionated users in your feedback inbox start to feel like they represent your entire user base. They don't. They're the ones who took the time to write in. This is a structural problem, not a character flaw. Users who submit feedback, post in forums, or email your CEO are almost by definition outliers: power users, frustrated churners, people with strong opinions about keyboard shortcuts. Real customers, but not representative ones. The danger is subtle. Read enough of their requests and they start to feel like consensus. You ship the feature they asked for. Then adoption data shows 3% of users touched it. ## Better habits Track volume alongside intensity. One user asking for something ten times is still one user. Ten different users asking once is a different signal. Your [feedback board](/boards) should make it easy to see how many distinct people are behind each request. Segment feedback by user type. Power users with 500 daily sessions have different needs than the SMB customer logging in twice a month. Both matter, but they shouldn't carry equal weight for every decision. Balance qualitative feedback with quantitative data. If 30% of users are dropping off at a specific step in onboarding, that's stronger signal than any number of support tickets about an unrelated feature. The loud minority is worth listening to. They often spot real problems first. Just don't let them set your roadmap. --- Source: FeatureOS — https://featureos.com/glossary