Features
Features are the basic building blocks of everything in Wingback and are crucial to manage and maintain carefully. While you might be used to working with feature flags in your product that map more into your development flow (for example, a new design for a dashboard or a change in button color), features in Wingback represent a customer-facing functionality of your product. Think of it as a permission to access parts of your product.For example, let’s look at a company like MailChimp. Here are some of their features:
- Email Markup Editor
- Manage Subscriber Lists
- Send E-Mail Campaign
- Advanced Reporting
- Read Receipts
- Automation and Segmentation
- Multivariate Testing
- Create Custom Templates
Choosing the Right Feature Slugs
Choosing the right slugs is very important. Here are some rules:- Only create slugs for the actual customer-facing functionality. Most features will be an action that your customer triggers while using your application. A helpful way to decide on your initial set of features is to look at the boundary between your backend and frontend. Most of your API endpoints should correspond to a feature in Wingback.
- Do not create slugs for things that are not part of your code base. “Great service” or “the leading solution in X” might be part of your sales/marketing copy but cannot be directly translated into your product.
- Avoid creating generic slugs, like CORE_PRODUCT or BASE; always look at actual features of your product. It can, however, often make sense to prefix your slugs if you have a complex application with many parts or panes.
- Never use quantifiers like 1000_OF_FEATURE_A as these limits might change in the future, and individual limits are fully configurable in the plan editor.
- Similarly, be careful not to accidentally create multiple slugs for the same feature.
- Don’t create slugs for features that are in development, as unreleased functionality might still significantly change or get abandoned. This is where you could use a feature flag solution during testing, and only add the actual feature slug in Wingback as part of your release process.
If you already have a pricing page today and are in the process of implementing Wingback, we don’t recommend relying on it to create your feature slugs. Your pricing page was probably created from a sales/marketing perspective and might only partially map into or represent your product accurately. Instead, take the time to thoroughly examine your product’s functionality and ensure that your features and slugs accurately represent the customer-facing functionality of your application.
Examples
Good | Bad | |
---|---|---|
✅ EMAIL_MARKUP_EDITOR | ❌ 100_REPORTS_PER_MONTH (quantifier) | |
✅ MANAGE_SUBSCRIBER_LISTS | ❌ LEADING_SOLUTION (not part of the codebase) | |
✅ SEND_EMAIL_CAMPAIGN | ❌ CORE (generic) | |
✅ ADVANCED_REPORTING |
Entitlements
Entitlements are the customer-specific access rights to features based on their plan. They define which features are available to a customer, and in some cases, the usage limits or quotas for those features. As your customer base grows and more plans are created, there will be many different configurations and ways your customers pay for them. A customer might also upgrade, downgrade, or change their plan at any point. Entitlements can take many different forms, such as:- Simple flat pricing
- Features with a limit on usage
- Usage-based pricing
- Bulk discounts
- Per seat pricing
- And many more…