Should Your SaaS Feature Use Machine Learning?
For product managers at SaaS companies · Based on Ng Machine Learning Orientation Framework
// TL;DR
SaaS product managers can use the Ng ML Orientation Framework to decide whether a proposed feature genuinely needs machine learning before scoping engineering work. The framework defines ML as learning without explicit programming, then guides you to state the feature's job plainly, test whether rules would suffice, map it to a known pattern like recommendation or anomaly detection, verify your product generates the learning signal (user behavior, outcomes, feedback), classify it as consumer or industrial ML, and justify the choice. It stops you from over-engineering features that simple logic handles and flags data gaps early.
When should a SaaS feature actually use machine learning?
Product managers face constant pressure to add 'AI' features, but many proposed features are better served by simple deterministic logic. The Ng ML Orientation Framework helps you decide before you commit a sprint. The pivotal test: can every rule governing this feature be written out by hand? A feature that sorts tasks by due date needs rules, not ML. A feature that predicts which tasks a user is most likely to complete next needs a pattern learned from behavior data—that's ML territory.
Start by stating the feature's job in plain language, free of jargon: 'Suggest the next action a user should take.' Only after you understand the job plainly should you evaluate whether ML fits. Describing a feature in ML terms too early obscures whether ML is even needed.
How do I map a SaaS feature to a known ML pattern?
Most SaaS ML features fall into recognizable categories. In-app recommendations (suggested templates, next actions, related content) map to the recommendation pattern, like streaming services. Smart search and result ranking map to ranking/retrieval, like web search. Auto-tagging, categorization, and priority scoring map to classification/labeling, like photo tagging. Fraud or abuse detection and unusual-usage alerts map to anomaly/spam detection, like email filtering. Identifying the pattern tells you what method and, crucially, what data you'll need.
This is where the learning-signal check becomes decisive. Your SaaS product may already generate the signal—clicks, completions, conversions, churn events, user feedback. For a recommendation feature, the signal is which items users engaged with. For churn prediction, it's historical accounts labeled churned or retained. If your product doesn't yet capture these outcomes, the ML feature is blocked until you instrument that data.
Is my feature consumer ML or something higher-stakes?
Most SaaS features are consumer ML—personalization, content surfacing, communication—which tolerates occasional imperfect predictions. A slightly off recommendation is a minor annoyance, not a safety event. That relatively high error tolerance means you can ship earlier and improve iteratively. But if your SaaS serves regulated industries—healthcare, finance, legal—your feature may cross into industrial ML territory with much stricter accuracy and auditability requirements. Classifying this early sets realistic expectations for accuracy, review, and rollout.
How do I write the justification for a spec?
Use the framework's final step to produce a crisp rationale: the rules are too complex to write by hand, OR the pattern lives in user behavior not in product logic, OR the feature must generalize to users and contexts it hasn't seen. For example: 'Recommending relevant templates requires learning from aggregate user behavior, since no fixed rule captures which template fits each user's evolving workflow.' This one-sentence justification, backed by a named data source, belongs at the top of your feature spec.
Watch for pitfalls: don't apply ML where a rule engine works (it adds complexity and unpredictability), don't assume data exists without checking your event tracking, and don't treat ML as magic that skips the data-and-iteration work.
What should I do next?
Take your top AI-flavored feature idea and run it through the six steps in a single planning session: plain statement, rules check, pattern mapping, learning-signal verification against your actual event data, consumer-versus-industrial classification, and a one-sentence justification. If the feature clears the rules check and you can point to real behavioral data as the learning signal, you have a validated ML feature worth scoping. If not, you've saved a sprint—and you know exactly what data to start capturing.
// FREQUENTLY ASKED QUESTIONS
How do I tell if a feature needs ML or just a rule engine?
Ask whether you can write out every rule governing the feature by hand. Sorting by date or applying fixed thresholds needs rules. Predicting behavior, personalizing content, or generalizing to unseen users needs patterns learned from data—that's ML. If deterministic logic covers it, skip ML to avoid unnecessary complexity and unpredictability.
What learning signal does a SaaS recommendation feature need?
It needs records of which items users engaged with—clicks, completions, or conversions paired with context. This behavioral data is the learning signal the model infers patterns from. Before scoping the feature, verify your event tracking already captures these outcomes; if not, the ML feature is blocked until you instrument that data.
Are most SaaS ML features consumer ML or industrial ML?
Most are consumer ML—personalization, recommendations, search—which tolerate occasional imperfect predictions and let you ship and iterate quickly. But if your SaaS serves regulated sectors like healthcare or finance, features can cross into industrial ML with stricter accuracy and auditability demands. Classify this early to set realistic rollout expectations.
What belongs in an ML feature spec's justification?
A one-to-two sentence rationale anchored to the specific feature: that rules are too complex to hand-code, the pattern lives in user behavior, or the feature must generalize to unseen contexts—plus the named data source that serves as the learning signal. Put this at the top of the spec so engineering understands why ML, not rules, is warranted.