Stepping out of leadership challenges for a moment, here’s a practical topic that some product managers struggle with: is the next thing we’re working on a feature or a whole product? IMO, there aren’t any universal/magical answers, but assorted hints and indicators.
BTW for this post: a product is something that we'll sell with exactly the same contents/capabilities/features many times to many customers. It's packaged to appeal to a large-but-specific segment or audience or JTBD. A feature is something that our product can do, which ideally adds value.
And I'm using "edition" or "tier" to identify how most SaaS software is packaged and sold. There's usually a Bronze/Silver/Gold or Good/Better/Best or Basic/Expanded/Advanced structure where each tier of the product has lots of features/capabilities. When we add a new feature, we insert it into the appropriate edition. We rarely add a tier or branch off a whole new product.
Splitting this into three sub-thoughts
- Have A Rationale For Each Customer-Visible Item
- It's More Likely To Be Its Own Product If...
- Things That Customers Don't Care About
1. Have a Specific Rationale For Each Item We're Building
I often find that we ask packaging/pricing questions when we're just about to ship something, rather than when we start the work. That's a bit backward: we should have thought about why this work is important before we start full development. That avoids delivering a new feature/capability and realizing (too late) that it doesn't have a home, or we don't know how real end users will think about it, or we've spent too much.
So what's our goal (intent) for this new set of bits?
- Answer competitive threats for a feature that we're missing but is well-understood/already in competing products
[It should probably be a feature, bundled into our base edition so that everyone gets it. Success = fewer lost deals.] - Drive upsell from Bronze to Silver, or Silver to Gold
[It's probably a feature in the relevant Silver or Gold edition. Success = increased upsell revenue.] - Reduce churn at renewal time, or fewer abandoned trial accounts
[Probably goes into the tier having these problems. Success = lower churn or higher trial conversion.] - Help sell another product, perhaps owned by a different group
[Should this live in our product or theirs? Success = increased sales of that other product.] - Create a whole new/separate revenue stream
[Probably a new product or product line. Success = sales in a new category. Do we have sales/marketing/support lined up to sell our new widget?] - Reduce our internal costs or make us more efficient
[If feature X cuts our Tech Support time or simplifies updates or shrinks our AWS consumption, we should probably give it away for free to every customer.] - Keep us in business. We typically spend about half of our engineering/design effort on infrastructure and capabilities that customers assume we provide: security, scalability, usability, bug fixes, privacy, better workflows, documentation, data validation, etc.
[Most of this should be invisible to end users and quietly goes into the platform or appropriate edition. And may overlap with cost savings item just above.]
Notice that we don't need final decisions or specific price points when we start development, but we should have a clearly stated goal. Having product-versus-feature arguments at launch time suggests we're not planning early enough.
2. It's More Likely To Be Its Own Product If...
Here are some of qualitative indicators I use. If your item checks more items on the left, then IMO it's more likely to be its own product:
| More Product-Like | More Feature-Like |
|---|---|
| Can sell separately from our other products | Dependencies, can't use stand-alone |
| Compelling (separate) customer ROI | ROI is for larger or other products |
| Ongoing/continuous customer value | One-time savings or benefit |
| Integrates with third-party products or services | Supports only our stuff |
| Priced in relevant value/consumption units (more units → more customer value) | Scaled based on some other product's units |
| Priced high enough to interest our sales team | Small relative to existing products, sales incented to give it away |
| Customer sees separate problem or value stream | Customer thinks they already bought Product A from us to solve this |
BTW if you have multiple products or product lines, consistency is extremely helpful to your GTM teams and customers. Common naming model, shared upgrade policies, simple pricing units, similarly structured ROI stories, etc.
3. Customers Don’t Care About...
It's easy to fall into solipsism: focusing on what our team or company needs without serving our users and buyers. So let's call out what our customers don't care about (and therefore shouldn't be how we sort products from features):
- Customers don’t care about how hard we worked. Our product either does what the customer needs, or it doesn't. And it should be priced based on customer value, not recovering our expenses. Users don't care how much we spent, how big (or great) our team is, margin demands from Finance, remote versus on-site teams, development velocity, scrum vs. kanban vs. XP vs. lean.
- ...Which business unit built it. I see a lot of companies 'ship their org chart' where each BU sets pricing and packaging to satisfy its own internal P&L scorekeeping. ("Database connectors are priced separately on a per-container basis because they come from the Integrations team.") If our feature helps sell more of a product in another BU, we should figure out internally how to transfer budgets or account for it.
- ...If we think this is a product. Ultimately, the market decides if we can price and ship something separately, or we need to fold it into an existing thing. The hundredth time that a customer complains that "they already paid for X as part of Y" is a hint that we got it wrong.
Sound Byte
Product-versus-feature decisions are part of our broader thinking about customer value, revenue, upsell, and impact. We should think about them as a group, evolving over time, and be intentional about why/how each new item fits into the whole.