The Product Manager Guide to Self-Models

TL;DR

• A self-model is a structured representation of what your product knows about each user - their beliefs, preferences, goals, and how those evolve over time
• Product managers who write specs with self-model requirements ship personalization that compounds rather than plateaus
• You do not need to be an ML engineer to use self-models - you need to be able to answer three questions about each user

A self-model is a structured representation of what a product knows about each user: their beliefs, preferences, goals, and how those evolve over time, with confidence scores on every dimension. Product managers who understand self-models can spec personalization as a first-class feature rather than an afterthought, producing experiences that compound rather than plateau. This post covers the three questions every PM needs to answer, how to write a belief inventory, and a spec template for shipping self-model-powered features.

What Is a Self-Model

A self-model is a structured representation of what your product understands about an individual user. Not a user profile. Not a preferences page. Not a behavioral log. A self-model captures three things:

Beliefs - what the user thinks, wants, and values. A belief might be: this user prefers concise technical explanations over detailed walkthroughs. Or: this user cares more about security than performance. Beliefs have confidence levels that change over time as you observe more interactions.

Context - the situations in which those beliefs apply. A user might prefer concise explanations when browsing documentation but detailed walkthroughs when debugging. Context makes beliefs situational rather than static.

Evolution - how the user’s beliefs change over time. A new user might start with high confidence in wanting simple explanations, then shift toward technical depth as they gain expertise. Self-models track this evolution rather than overwriting it.

Think of a self-model as the difference between a contact card and a relationship. A contact card tells you someone’s name and email. A relationship tells you how they think, what they care about, and how that has changed since you met them.

The Three Questions

As a PM, you do not need to understand the math behind self-models. You need to answer three questions for every feature you spec:

1. What does the product need to believe about this user to do its job well?

This is your belief inventory. For a writing assistant, the inventory might include: preferred tone (formal vs casual), expertise level (beginner vs expert), primary use case (emails vs reports vs creative). For a code assistant, it might include: preferred language, architecture philosophy, documentation style.

2. How will those beliefs be learned?

Some beliefs can be asked directly during onboarding. Others must be inferred from behavior. Others emerge over time as confidence accumulates. Your spec should identify the learning mechanism for each belief.

3. How will those beliefs be used?

This is where the self-model connects to the user experience. Each belief should map to a specific product behavior. If the product believes a user prefers concise responses, what changes? The default response length? The level of detail in explanations? The number of examples shown?

If you can answer these three questions, you can write a self-model spec.

Writing the Belief Inventory

The belief inventory is the most important artifact a PM can create for self-model features. Here is how to write one.

Start by listing every decision your product makes that could be personalized. For each decision, identify the user attribute that would inform a better choice. Then classify each attribute as a belief rather than a preference.

The difference matters. A preference is what the user says they want. A belief is what the product understands about the user, including what they have not said. Preferences are explicit and static. Beliefs are inferred and evolving.

1// PM belief inventory for a code assistant← one per feature area
2const beliefInventory = {
3  response_style: {
4    belief: 'Prefers concise code with inline comments',
5    confidence: 0.78,← learned from 12 interactions
6    learned_via: 'behavioral inference',
7    used_for: 'response length and comment density'
8  },
9  architecture: {
10    belief: 'Favors functional patterns over OOP',
11    confidence: 0.65,← still learning
12    learned_via: 'code analysis + direct question',
13    used_for: 'code generation style and refactoring suggestions'
14  },
15  risk_tolerance: {
16    belief: 'Conservative - prefers well-tested approaches',
17    confidence: 0.82,← strong signal from behavior
18    learned_via: 'behavioral inference from library choices',
19    used_for: 'dependency recommendations and migration suggestions'
20  }
21};

Self-Models vs Segments vs Preferences

Product managers are used to thinking in segments and preferences. Self-models are different. Here is a comparison:

The mental model shift for PMs is this: stop asking what segment is this user in and start asking what does the product believe about this user and how confident is it.

How to Spec Self-Model Features

Here is a template for writing product specs that include self-model requirements:

Feature name. What it does in one sentence.

Belief requirements. What the product needs to understand about the user to deliver this feature well. List each belief, its expected confidence threshold for activation, and how it will be learned.

Adaptation rules. For each belief above, specify how the product behavior changes. If belief X has confidence above 0.7, do Y instead of the default Z.

Cold start behavior. What the product does when it has no beliefs yet. This is your default experience - it should be good enough to retain the user while the self-model bootstraps.

Evolution expectations. How do you expect beliefs to change over time? Which beliefs stabilize quickly and which keep evolving? This informs your confidence calibration.

Success metrics. How you will know the self-model is working. Alignment score, retention delta, user satisfaction change.

This is not more work than a traditional product spec. It is more specific work. And specificity is what separates personalization that compounds from personalization that plateaus.

Trade-offs

Specifying self-models in product requirements introduces complexity. Here is what to expect:

Higher spec complexity. A belief inventory adds a new artifact to your product development process. Some teams will resist the overhead. Start small - one belief inventory for one feature - and expand once the value is proven.

Engineering alignment required. Your engineering team needs to understand the spec format. If they have never built self-models, expect a learning curve. The PM guide only works if engineering has the corresponding implementation guide.

Measurement difficulty. Traditional A/B tests measure feature impact. Self-model features improve gradually per user, which makes measurement harder. You need longitudinal metrics rather than snapshot comparisons.

Over-specification risk. It is tempting to specify 50 beliefs for a single feature. Resist. Start with 3 to 5 beliefs that map to the highest-impact product decisions. You can always add more as you learn.

Privacy by design. Belief inventories force you to be explicit about what you model. This is actually a benefit - it makes privacy reviews easier - but it requires upfront thought about data governance.

What to Do Next

1. Write your first belief inventory. Pick one feature in your product that would benefit from personalization. List the 3 to 5 things the product would need to understand about each user to deliver that feature better. For each, note how the belief would be learned and how it would change the product.

2. Run a belief mapping workshop. Get your product, engineering, and design leads together for 90 minutes. Walk through the three questions for your most important user journey. You will be surprised how quickly the team aligns on what the product should understand about users.

3. Add belief requirements to your next spec. Take your existing product spec template and add three sections: belief requirements, adaptation rules, and cold start behavior. Use the template above. Ship one feature with self-model requirements and measure the impact on user satisfaction and retention.

Stop specifying features without specifying understanding. Start building products that know their users. Get the PM toolkit for self-models at Clarity.

References

1. Twilio Segment’s 2024 State of Personalization Report
2. 2016 survey of 2,000 Americans by Reelgood and Learndipity Data Insights
3. Product vs. Feature Teams
4. only 1 in 26 unhappy customers actually complains
5. not a reliable predictor of customer retention

Related

• Three Layers of AI Personalization Architecture
• The Feedback Loop That Compounds
• How Self-Models Change the Discovery Process