The Art of Making Algorithms Understandable

One of the hardest parts of being a product manager for search and recommendations is not only designing the system, it is explaining it.

Modern discovery systems are built from many layers of intelligence. A streaming service may use viewing history, search behavior, content metadata, semantic similarity, sequence models, freshness signals, popularity, editorial judgment, marketing priorities, business rules, diversity constraints, experimentation frameworks, and long-term satisfaction objectives. Each layer may be understandable on its own. The full system is harder to explain because the experience emerges from the interaction of all of them.

• The user sees a row of titles.
• The executive sees a homepage.
• The marketing team sees a campaign.
• The scientist sees a model.
• The engineer sees a retrieval and ranking pipeline.

The product manager has to connect all of those views into one coherent explanation.

For years, we have relied on the same set of artifacts to do this work:

• PRDs
• architecture diagrams
• strategy decks
• metric dashboards
• ranking examples
• and verbal walkthroughs.

These tools are useful. They are still necessary. But they are often not enough for systems that are dynamic, probabilistic, and personalized.

A PRD can describe the intent of a feature. It does not always show how the system behaves. A dashboard can show whether a metric moved. It does not always explain why. A system diagram can show the components. It does not always build intuition. A ranking formula can be technically accurate. It can also lose the room.

This is one of the quiet challenges of AI product management. The product is not just the interface. The product is also the intelligence behind the interface. If that intelligence is invisible, stakeholders are forced to reason from symptoms. They see a title in a carousel, a campaign placement, a surprising search result, or an unexpected recommendation, and they try to infer the system from that one outcome.

That is a poor way to understand a complex product. It is also a poor way to make decisions.

The Explanation Gap

Most AI product teams live with an explanation gap.

On one side are the people building the system. They understand the moving parts. They know the retrieval strategy, the ranking objective, the model constraints, the feature interactions, the calibration logic, and the edge cases. They know which signals are strong, which are noisy, which are experimental, and which are there for business or editorial reasons.

On the other side are the people who need to make decisions about the system. Executives need to understand the strategic tradeoffs. Marketing teams need to understand how campaigns will interact with personalization. Editorial teams need to understand how curation fits into automated discovery. Designers need to understand what behavior the interface should expose or hide. Legal, policy, and brand teams need to understand where judgment, safety, and control enter the system.

They do not all need to understand the model architecture. They do need a faithful mental model.

When a stakeholder asks, “How does the recommendation system work?” the technically complete answer may be too detailed to be useful. The overly simplified answer may be too vague to be trusted.

“The model personalizes the experience” is not enough.

“The candidate generator retrieves from multiple embedding spaces, then a ranking model scores user-title affinity using contextual, behavioral, and item-level features before applying constraints and slate-level optimization” may be accurate, but it is not always useful in an executive discussion.

The product manager’s job is to find the layer of explanation that preserves the important logic without burying the audience in implementation detail.

The product manager’s job is to find the layer of explanation that preserves the important logic without burying the audience in implementation detail.

That is not dumbing it down.

That is product translation.

Why Search and Recommendations Are Especially Hard to Explain

Search and recommendation systems are difficult to explain because they are not one decision. They are a sequence of decisions.

A system first has to understand the user or the query. It has to identify a large set of possible candidates. It has to score those candidates. It has to balance relevance with freshness, popularity, diversity, novelty, availability, business priorities, and sometimes campaign objectives. It has to assemble a page, not just choose one item. It has to learn from what happened next. It has to do all of this under latency constraints, catalog constraints, experimentation constraints, and product constraints.

The result looks simple.

• A row appears.
• A title is ranked first.
• A search result is shown.
• A campaign module is inserted.

But the simplicity of the interface hides the complexity of the decision system.

This creates a recurring communication problem. A single recommendation is easy to criticize because it is visible. The system that produced it is harder to defend because it is abstract. A stakeholder can point to one title and ask why it appeared. The real answer may involve user behavior, candidate availability, model confidence, ranking objectives, diversity logic, business constraints, and experimentation state.

That is not a satisfying conversation unless the audience already understands the machinery.

The same issue appears with more advanced AI concepts. A Transformer sequence model, for example, is not intuitive to a lay audience. The idea that a model can look across a sequence, weigh relationships, and build a representation of context is powerful, but it is not naturally visual. The words “attention,” “tokens,” “embeddings,” and “context windows” are familiar to technical teams. They do not automatically create understanding for everyone else.

The challenge is not only that the concepts are complex. The challenge is that the concepts are invisible.

LLMs as an Explanatory Medium

This is where LLMs create a new possibility for product managers.

The most obvious use of LLMs is to build product features: chat interfaces, summarization, generation, customer support, productivity tools, coding assistants, creative tools, and new discovery experiences.

But there is another use that may be just as important for AI product leaders.

LLMs can help us explain complex systems.

Not by replacing technical documentation. Not by pretending that every system can be reduced to a simple metaphor. Not by generating confident but unverified narratives.

The value is different. LLMs can help turn a technical system into an explanatory artifact.

That artifact might be a narrative walkthrough. It might be a storyboard. It might be a visual script. It might be an animation. It might be a simulated user journey. It might be an interactive explanation that lets a stakeholder change inputs and see how the system responds.

The traditional artifact describes the system. The new artifact can show the system behaving.

The traditional artifact describes the system. The new artifact can show the system behaving.

For search and recommendations, that difference matters. These systems are easier to understand when people can see the flow: a user arrives with a history, the system gathers candidates, different signals shape the score, constraints modify the slate, a campaign enters the decision space, and the final experience is assembled.

The point is not to reproduce every implementation detail. The point is to preserve the right mental model.

The Right Mental Model

A good explanation of an AI system does not have to be complete. It has to be faithful. Completeness is often impossible in a stakeholder conversation. Faithfulness is mandatory.

A faithful explanation keeps the important relationships intact. It shows which forces are interacting. It makes the tradeoffs visible. It does not imply that the system is deterministic when it is probabilistic. It does not imply that one signal controls the outcome when many signals contribute. It does not make the algorithm sound more magical than it is. It also does not hide the judgment that went into the product design.

This is where LLMs are useful, but also risky.

They are useful because they are good at translation. They can take a dense technical explanation and generate a simpler version for an executive, a designer, a marketer, or a general audience. They can help find analogies. They can produce a sequence. They can create a storyboard. They can convert abstract behavior into a concrete scene.

They are risky because they can make a wrong explanation sound elegant.

That means the product manager still owns the judgment. The LLM can draft, simplify, reframe, and visualize. The PM still has to inspect. The scientist still has to validate. The engineering team still has to confirm the mechanics. The final artifact has to be reviewed against how the system actually works.

The goal is an accurate explanation that people can understand.

From PRD to Simulation

I recently explored this through a small Algorithm Animation project.

The idea was simple: instead of writing another static explanation of how the algorithm interacts with a discovery system, create an animation that makes the interaction visible.

A campaign in a streaming product is not just a banner or a marketing message. It enters a system that already has many other forces at work. The system may be trying to personalize the experience. It may be trying to surface relevant content. It may be trying to respect user intent. It may be trying to balance freshness, popularity, diversity, and business priorities. A campaign is not operating in empty space. It is interacting with a recommendation environment.

Explaining that in a PRD is possible. Showing it is better.

An animation can start with a user. It can show the user’s context. It can show candidate titles entering the system. It can show personalization signals shaping the ranking. It can show campaign logic entering as another force, not as a magic override. It can show constraints and tradeoffs. It can show the final slate as the result of multiple interacting decisions.

It also makes the product conversation more precise. Instead of debating an abstract statement like “campaigns should influence recommendations,” the team can discuss the actual behavior they want.

• Should the campaign create eligible candidates?
• Should it boost titles that are already relevant?
• Should it reserve placement in a module?
• Should it change the ordering of a row?
• Should it only apply when the user has a demonstrated affinity?
• Should it be constrained by fatigue, diversity, or satisfaction signals?
• Should it be visible to the user as an editorial moment, or invisible as part of personalization?

Why This Matters for Executives

Executive teams do not need every implementation detail. They need enough understanding to make strategic decisions.

That often means understanding the shape of the system more than the code behind it.

For example:

• an executive may need to know whether personalization will reduce editorial control.
• a marketing leader may need to know whether a campaign can reach the right audience without degrading user experience.
• a content leader may need to know whether the system is biased toward existing hits or capable of creating discovery for deeper catalog titles.
• a product leader may need to know whether the team is optimizing short-term clicks or long-term satisfaction.

These are not purely technical questions. They are product strategy questions. But they cannot be answered well if the underlying system is treated as a black box.

A good explanatory artifact creates shared language. It gives the executive team a way to reason about the system without pretending to be machine learning experts. It helps them ask sharper questions. It helps the product team avoid vague answers. It reduces the gap between technical design and business decision-making.

This is especially important in AI products because the language can become slippery.

• “Personalization” can mean many things.
• “Relevance” can mean many things.
• “Optimization” can mean many things.
• “AI-driven” can mean almost anything.

A visual explanation forces more precision. It makes the team say what is actually happening. It turns strategy words into system behavior.

The PM as Translator

The AI product manager is increasingly a translator between forms of intelligence.

• There is machine intelligence: the models, signals, rankings, embeddings, predictions, and generated outputs.
• There is organizational intelligence: the strategy, constraints, business priorities, brand judgment, and executive decision-making.
• There is user intelligence: intent, taste, attention, behavior, frustration, curiosity, and satisfaction.

The PM has to connect these layers. That has always been true in product management, but AI makes the translation problem more intense. The system is more complex. The behavior is more probabilistic. The outputs are more fluent. The risks are more subtle. The explanations have to be stronger.

This is why I think LLMs will become part of the product manager’s communication toolkit as PMs turn complex product intelligence into reviewable artifacts: explanations, simulations, walkthroughs, diagrams, animations, and decision narratives that make the system easier to inspect.

The artifact should not merely persuade. It should be reviewable.

The artifact should not merely persuade. It should be reviewable.

• A stakeholder should be able to look at it and ask, “Is this really how the system works?”
• A scientist should be able to say, “That part is too strong.”
• An engineer should be able to say, “That is not where the constraint applies.”
• A designer should be able to say, “If that is the system behavior, the interface needs to expose this differently.”

A good explanatory artifact creates alignment because it creates something concrete to inspect.

The New Product Artifact

The PRD is not going away. But the PRD is no longer enough.

AI product teams need artifacts that show behavior, not just requirements. They need artifacts that explain judgment, not just functionality. They need artifacts that make evaluation visible, not just outcomes. They need artifacts that can be understood by people who were not in the model review, the architecture discussion, or the experiment readout.

The explanatory simulation may become one of those artifacts.

It sits somewhere between a PRD, a prototype, a system diagram, and a teaching tool. It is not production code. It is not a model card. It is not a dashboard. It is a way to make the product logic visible before, during, and after the product is built.

For AI systems, this can become part of the operating model.

• Before building, use it to align on intended behavior.
• During development, use it to check whether the implementation still matches the product concept.
• Before launch, use it to educate stakeholders and pressure-test edge cases.
• After launch, use it to explain what changed and why.

The artifact becomes a bridge between strategy and system behavior.

The Discipline Behind the Elegance

There is a temptation to treat this as a storytelling problem. It is partly that.

But for AI products, storytelling without discipline is dangerous. A beautiful animation can make a weak idea look strong. A smooth explanation can hide uncertainty. A simple metaphor can erase the real tradeoffs. An LLM can generate a narrative that sounds right while quietly changing the mechanics.

The discipline is to keep the artifact connected to the truth of the system.

That means starting with the actual architecture or intended design. It means identifying which details matter for the audience and which can be safely abstracted. It means reviewing the explanation with technical partners. It means making the simplifications explicit. It means avoiding false precision. It means distinguishing between what the system does today, what the product intends to build, and what the artifact is using as a conceptual simplification.

The best version of this work is not theater. It is product clarity.

The product manager is not using an LLM to make the system seem simple. The product manager is using an LLM to create the simplest faithful representation of a complex system.

The product manager is not using an LLM to make the system seem simple. The product manager is using an LLM to create the simplest faithful representation of a complex system.

Making AI Legible

As AI becomes more central to product experiences, the ability to explain AI systems will become a leadership skill.

The teams that build these systems will need to do more than improve models. They will need to make the behavior of those models understandable to the organization. They will need to explain how signals interact, how tradeoffs are made, how constraints are applied, how quality is evaluated, and how human judgment remains part of the system. This is especially true in discovery products.

Search and recommendations shape what people find, what they watch, what they buy, what they read, and what they believe is available. These systems influence attention. They influence demand. They influence the perceived value of the catalog. They influence the relationship between user intent and business strategy. That makes them too important to leave opaque.

LLMs give product managers a new way to make them visible. Not perfectly. Not automatically. Not without review. But meaningfully.

They can help us move from static documentation to living explanation. From dense system descriptions to clear mental models. From abstract strategy to visible behavior. From “trust us, the algorithm handles it” to “here is how the system thinks about the tradeoff.”

That is a better conversation for executives. It is better for cross-functional teams. It is better for the people building the product. And ultimately, it is better for users, because teams that understand their systems more clearly are more likely to build them responsibly.

The black box will not disappear, but we can make it more legible. And for AI product managers, that may become one of the most important parts of the job.

---

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.