How to use Super Intelligence to see a problem from multiple perspectives is not about asking an AI system to pretend that it knows what everyone thinks. It is about deliberately changing the frame of a problem so hidden constraints, incentives, risks and interpretations become easier to see.
A single perspective can be accurate and still incomplete. A parent sees learning from home. A student experiences the task from inside the difficulty. A teacher sees classroom performance. A tutor may see error patterns. None of those views automatically contains the whole problem.
In the eduKateSG life series, Super Intelligence, or SI, is our editorial name for practical AI assistance. This guide follows How to Use Super Intelligence for Second-Order Thinking and extends the thinking cluster by changing vantage point rather than time horizon.
The central rule is: a generated perspective is a hypothesis about what a viewpoint might reveal, not evidence of what a real person believes.
Why Multiple Perspectives Improve Reasoning
Problems look different depending on what a person can see, what they are responsible for and what consequences they bear.
A manager may see missed deadlines. An employee may see unstable requirements. A customer may see inconsistent service. An engineer may see technical debt. A finance team may see cost. Each view can identify a different part of the same system.
- They reveal constraints hidden from the original viewpoint.
- They expose incentives that make behaviour more understandable.
- They separate disagreement about facts from disagreement about values.
- They identify people who carry costs that the main decision-maker does not see.
The objective is not to average all viewpoints into one bland compromise. It is to improve the model of the problem before deciding.
Perspective Is Not the Same as Truth
A viewpoint can be internally coherent and factually wrong. A stakeholder may misunderstand a process. An expert may lack local context. A user may experience a real problem but misidentify its cause. A generated role-play can invent motives.
Use perspective-taking to generate questions and hypotheses. Use evidence to decide which claims survive.
Ask SI to label statements as direct evidence, stakeholder-reported experience, inferred perspective, simulated viewpoint or unresolved question.
This prevents a useful empathy exercise from becoming counterfeit evidence.
The Seven Perspective Lenses
1. First-person perspective
What do I directly experience, value, know and fear? This lens matters because decision systems often hide the user’s own values under supposedly objective criteria.
2. Affected-person perspective
Who experiences the consequences but does not control the decision? A child affected by a tuition schedule, a family member affected by a move, or a colleague affected by a workflow change.
3. Operator perspective
Who has to make the system work every day? Operators see friction, exceptions and maintenance that strategic planners miss.
4. Expert perspective
What domain knowledge changes the interpretation? An expert can identify technical constraints, but their perspective should still be connected to evidence and the actual context.
5. Customer or user perspective
What does the person receiving the service experience? This lens reveals usability, waiting, clarity and trust.
6. Adversarial or red-team perspective
How could the plan fail, be misunderstood, exploited or produce unintended consequences? This is not cynicism; it is structured challenge.
7. Future-self perspective
How might the decision look after six months or several years? This lens connects perspective-taking with second-order thinking and lock-in.
The Perspective Map
A useful perspective map contains five fields for each viewpoint: goal, information, constraint, risk and question.
Goal: what outcome matters to this perspective?
Information: what can this person or role see?
Constraint: what limits them?
Risk: what do they stand to lose?
Question: what would they want clarified before supporting the decision?
This structure is stronger than asking, “What would a teacher think?” because it makes the basis of the perspective explicit.
Stake, Knowledge and Authority Are Different
A powerful perspective framework separates three dimensions: stake, knowledge and authority.
Stake
How much is this person affected?
Knowledge
How much relevant information or expertise do they possess?
Authority
What are they entitled or authorised to decide?
A child can have high stake and limited formal authority. A technical expert can have high knowledge but low authority over family values. A manager can have authority but incomplete operational knowledge.
Do not confuse one dimension with another. SI can build a stake-knowledge-authority map to identify whose input is missing and which decisions require actual consent.
Worked Example 1: A Student’s Falling Mathematics Results
The parent sees a score decline and considers adding tuition hours.
Parent perspective
Concern: results and confidence are falling. Constraint: limited weekly time. Risk: waiting too long.
Student perspective
Experience: homework feels manageable until unfamiliar mixed questions appear. Constraint: fatigue after school. Risk: extra lessons reduce recovery time.
Teacher perspective
Evidence: class topic pace, recent assessment structure and school-level expectations. Constraint: class time and cohort needs.
Tutor perspective
Evidence: individual working, error sequence and response to hints. Constraint: limited direct observation outside tuition.
System perspective
Question: is the bottleneck knowledge, method selection, execution under time or total workload?
SI can synthesise the map into testable questions. It cannot claim the student “really feels” a certain way unless the student says so.
The next action may become a diagnostic rather than immediate additional hours.
Worked Example 2: Choosing Between Two Jobs
Employee perspective: role fit, flexibility, learning, compensation and commute.
Family perspective: schedule, travel, household responsibilities and financial stability.
Manager perspective: scope, performance, collaboration and decision authority.
Future-self perspective: what capabilities will each role compound over two years?
Risk perspective: what assumptions about culture, manager quality or advancement remain unverified?
The multiple-perspective analysis prevents salary and title from monopolising the decision and identifies what needs real-world confirmation.
Worked Example 3: Introducing a Household SI System
A family wants to use SI to organise school notices, appointments and recurring tasks.
System-designer perspective: one clean dashboard and fewer missed obligations.
Other family members: simplicity may matter more than detail; they may resist another system to maintain.
Privacy perspective: are sensitive documents being copied unnecessarily?
Reliability perspective: what happens when the AI summary is wrong or the service is unavailable?
Labour-distribution perspective: who maintains the system and does invisible administration become concentrated in one person?
The design can now use source links, shared ownership and a minimal record instead of building the most sophisticated possible household command centre.
Perspective-Taking Without Mind-Reading
The biggest danger is turning a simulated viewpoint into a claim about a real person.
Instead of “Your manager thinks you are unreliable”, use: “A manager who sees repeated missed deadlines might worry about reliability; ask what evidence your actual manager uses to evaluate delivery.”
Instead of “Your child hates tuition”, use: “A student experiencing fatigue and low control may resist additional lessons; ask the child directly about workload and where help feels useful.”
Simulated perspective should generate questions for reality.
Useful wording
“One plausible concern from this role is…” “This stakeholder may care about…” “Ask the actual person whether…”
Unsafe certainty
“They definitely think…” “Their real motive is…” “This person is behaving this way because…”
The difference protects relationships and epistemic discipline.
Disagreement Has Different Types
Factual disagreement
People disagree about what is true. Resolve with evidence or source verification.
Interpretive disagreement
People agree on facts but explain them differently. Identify what evidence would distinguish explanations.
Value disagreement
People want different outcomes. Evidence alone may not resolve the conflict.
Constraint disagreement
People agree on goals but disagree about what is feasible.
Risk disagreement
People assign different importance to uncertain downside.
Authority disagreement
People disagree about who is entitled to decide.
SI can label the disagreement type. This prevents value conflict from being disguised as a factual debate.
The Perspective Matrix
For complicated decisions, create rows for perspectives and columns for goal, evidence, constraint, risk, authority and unanswered question.
Do not score the perspectives. The purpose is coverage, not ranking.
A blank cell can be valuable: it may reveal that nobody has direct evidence about a stakeholder’s actual experience.
Use the matrix to decide who needs to be asked, what source needs to be checked and which trade-off needs human negotiation.
Perspective Coverage Check
- Who is directly affected?
- Who performs the work?
- Who approves the decision?
- Who has specialist knowledge?
- Who pays the cost?
- Who receives the benefit?
- Who maintains the system later?
- Who is absent from the current conversation?
- Who experiences the decision after the first-order effect?
You do not need every conceivable perspective. Include the ones capable of revealing a material constraint or consequence.
Power and Perspective
Not all perspectives enter a decision with equal power.
The person most affected may have the least formal authority. The person with authority may not experience the operational burden. A child, junior employee, caregiver, customer or operator can carry significant consequences while having limited control over the decision.
SI can help expose this asymmetry by separating stake from authority.
Ask: “Which affected perspective has the least ability to correct a bad decision after it is made?”
That question is especially useful when the decision is difficult to reverse.
Do Not Use Multiple Perspectives to Create False Balance
Sometimes evidence strongly supports one conclusion. Generating an opposing viewpoint does not make the two positions equally credible.
Multiple perspectives should reveal legitimate differences in information, values, incentives or experience. They should not manufacture symmetry where one claim lacks support.
Ask SI to distinguish “another stakeholder priority” from “another factual claim”.
Expert Perspective Versus Lived Perspective
Expertise and lived experience answer different questions.
An expert may know how a system typically works. The user knows what happened in this specific case. A teacher knows curriculum requirements. The student knows where they became confused. A healthcare professional has clinical expertise. The patient knows their symptom history.
Good reasoning combines rather than collapses these perspectives.
SI can help translate between them: turn technical language into questions, organise observations for an expert or map how general guidance applies to the user’s actual constraints.
Do not let simulated expertise replace real expertise when consequential judgement requires it.
Temporal Perspectives: Past Self, Present Self and Future Self
Past self asks what you knew when the original decision was made. This helps avoid hindsight bias.
Present self asks what evidence, values and constraints exist now.
Future self asks what maintenance, lock-in and delayed consequences may matter later.
Ask SI to compare the decision from all three time positions without pretending to know how your future values will change.
A useful output is a list of questions future-you would want present-you to have considered.
The Operator Perspective
Operators know where abstractions break.
A strategic plan may say “update the database weekly”. The operator sees that the source arrives in three formats, one field is ambiguous and approvals are often late.
- What input arrives?
- In what format?
- What exceptions occur?
- Who resolves ambiguity?
- What happens when the source is late?
- Which step requires manual judgement?
- How is completion verified?
Ask SI to generate these operator questions, then confirm them with the actual people who perform the work.
The Maintenance Perspective
Most plans focus on creation, not upkeep.
Ask what the workflow looks like after six months. Who updates sources? Who reviews permissions? Who removes obsolete prompts? Who notices when the context changes? Who trains the next person?
A system that is excellent on launch day can become burdensome if the maintenance perspective was absent.
A Full Multi-Perspective Case: A New Learning Platform
Situation: a family is deciding whether to add a new AI learning platform alongside school and tuition.
Parent perspective: wants visibility, practice and efficient use of limited time.
Student perspective: wants help that does not turn every evening into more school.
Tutor perspective: wants practice aligned with diagnosed gaps rather than random volume.
Teacher perspective: wants school tasks completed and concepts understood at curriculum pace.
Privacy perspective: asks what student data the platform collects and whether identifiable information is necessary.
Maintenance perspective: asks who configures topics, reviews generated questions and monitors use.
Future-self perspective: asks whether the platform builds independence or becomes a permanent crutch.
The combined analysis suggests a pilot: use the platform for one diagnosed topic over three weeks, cap usage, require independent transfer tasks and review whether the student becomes more or less dependent on hints.
The multi-perspective result is not a recommendation for or against the platform. It is a better experiment design.
A Full Multi-Perspective Case: Moving House
Parent perspective: minimise disruption. Child perspective: preserve routine, school travel and access to familiar activities. Budget perspective: total move, rent, deposits and recurring transport. Operator perspective: packing, mover access, utility activation and document changes. Future perspective: commute, neighbourhood fit and maintenance over years. Risk perspective: tenancy obligations, valuables, document loss and service gaps.
The perspectives reveal that “which home is nicer?” is not the whole decision. The family can build criteria that reflect transition and long-term living, not only property features.
Perspective Synthesis
After viewing the problem from several angles, synthesise without flattening disagreement.
Shared facts: what perspectives agree is true.
Different priorities: where values differ.
Missing evidence: which perspective introduced a question requiring verification.
Decision rights: who needs to decide, consent or be consulted.
A strong synthesis can preserve unresolved value conflict. Not every disagreement needs to disappear before action.
A Copyable Multi-Perspective Prompt
“Help me examine this problem from multiple perspectives without pretending to know what real people think. Identify the main affected, operator, expert, customer/user, risk and future-self perspectives that could reveal a material constraint. For each, state likely goals, information, constraints, risks and questions—not motives. Label simulated viewpoints as hypotheses. Then separate shared facts, value conflicts, missing evidence and decisions that require real stakeholder input.”
Common Failure Modes
Mind-reading
Generated perspective is presented as what a real person thinks. Repair: label it hypothetical and ask the person.
Perspective overload
Too many viewpoints produce noise. Repair: include perspectives capable of changing the decision.
False balance
Unsupported factual claims are treated as equally valid. Repair: separate stakeholder priorities from evidence.
Authority confusion
The most expert person is assumed to own the decision. Repair: separate knowledge, stake and authority.
Empathy theatre
The system produces emotionally rich role-play with little operational value. Repair: require concrete goals, constraints, risks and questions.
Ignoring operators
Strategy is designed without the people who perform the work. Repair: include implementation and maintenance views.
Ignoring future maintenance
The launch perspective dominates. Repair: add the six-month operator.
Consensus pressure
The synthesis tries to eliminate genuine value differences. Repair: preserve the conflict and make the decision right explicit.
What Progress Looks Like
- you can identify whose perspective is missing;
- you separate simulated viewpoints from real evidence;
- you distinguish stake, knowledge and authority;
- you classify disagreement before trying to resolve it;
- you ask real stakeholders better questions;
- you include operators and maintainers, not only decision-makers;
- you can see who carries hidden cost;
- you avoid false balance;
- you preserve legitimate value conflict; and
- you use perspective shifts to improve the problem model rather than to perform role-play.
Perspective Quality: A Viewpoint Is Only Useful if It Changes the Model
Adding perspectives can become decorative. A list of “student, parent, teacher, tutor” is not useful unless each viewpoint reveals different information, risk, authority or constraints.
Use a quality test: what becomes visible from this perspective that was invisible before?
If nothing changes, remove the perspective.
For example, “finance perspective” is useful only if it changes the understanding of cost, cash flow, risk or budget. “Future-self perspective” is useful only if it reveals maintenance, lock-in or delayed consequences. “Operator perspective” is useful only if it reveals exceptions, handoffs or workload.
A strong multi-perspective analysis becomes smaller after this filter because low-information viewpoints are removed.
Perspective and Role Are Not the Same
A role is a position in a system. A perspective is the information, incentives, responsibilities and lived consequences visible from that position.
Two people with the same role can hold different perspectives because their experience and values differ.
Do not ask SI to stereotype a role. Ask what information and constraints are structurally associated with that role, then identify what must be confirmed with the actual person.
Example: “teacher perspective” should not become “teachers dislike AI”. A useful structural question is: what classroom evidence does the teacher see, what curriculum obligations apply and what constraints affect individualisation?
The Missing-Perspective Test
Many decisions are distorted not because the included views are wrong, but because one important view is absent.
Ask: “Who experiences the consequences after the decision-maker has moved on?”
This often reveals maintainers, junior staff, children, caregivers, editors, reviewers, support teams or future users.
The missing perspective is especially important when the person has low authority but high exposure to the decision.
Hidden-maintenance perspective
A new system may look excellent to its designer while creating weekly upkeep for someone else.
Exception-handling perspective
Routine cases work, but one person handles all unusual cases. Their workload may grow as automation expands.
Failure-recovery perspective
Who has to repair the system when something goes wrong? This perspective sees backup, traceability and reversibility.
Use SI to ask who inherits work when the happy path fails.
Perspective Triangulation
When several perspectives describe the same problem, look for overlap and divergence.
Overlap suggests a shared fact or shared concern. Divergence may indicate different information, different incentives, different values or different interpretations.
Triangulation does not mean majority vote. Three people can share the same mistaken assumption.
Instead ask:
- Which claims appear across perspectives?
- Which claims come from independent evidence versus copied information?
- Where do perspectives disagree on facts?
- Where do they agree on facts but differ on values?
- Which person has direct experience of the disputed part?
- Which claim can be checked externally?
SI can organise these intersections, but the user still needs to inspect whether the sources are genuinely independent.
Perspective Compression
After exploring multiple viewpoints, compress them into a short synthesis.
A good compression includes: shared facts, unique constraints, unresolved disagreements, affected parties, decision rights and missing evidence.
If the synthesis becomes a generic statement such as “everyone has different needs”, it has lost the useful structure.
The compressed output should make the next action clearer: verify a fact, ask a stakeholder, change the design, add a guardrail or make a value trade-off.
Worked Example: A Student Wants to Drop an Activity
Situation: a student wants to stop a long-standing co-curricular activity because school workload has increased.
Student perspective
Sees fatigue, homework pressure, social experience and personal interest. High stake. Some authority depending on age and context.
Parent perspective
Sees family logistics, commitment history, cost, long-term development and concern about giving up too quickly.
Coach perspective
Sees skill progression, team commitment and whether the current difficulty is temporary.
School perspective
May see academic load and official participation requirements.
Future-self perspective
Asks whether leaving creates relief, regret, or capacity for another priority.
The perspectives reveal at least three different questions: Is the workload temporarily unsustainable? Does the activity still align with the student’s values? Are there intermediate options such as reduced commitment?
The decision becomes richer than “quit or continue”.
SI can generate intermediate options and questions, but the student’s actual preference must come from the student.
Worked Example: A Family Decides Whether to Move
Property features are only one perspective.
Parent work perspective: commute, flexibility and employment location.
Child perspective: school route, friendships, activities and routine.
Financial perspective: housing cost, transaction cost, transport and future flexibility.
Household-operations perspective: storage, groceries, medical access, caregiving and daily logistics.
Future perspective: likely changes in schooling, ageing parents, workplace location or family size.
Risk perspective: what if expected commute savings disappear because work location changes? What if maintenance is higher?
A multi-perspective map may reveal that the best decision is not the home with the highest isolated score but the home that fits the family’s combined operating system.
Worked Example: A Manager Introduces AI into a Team
Manager perspective: reduce repetitive work and improve turnaround.
Employee perspective: concern about workload, role change, surveillance, skill development and accountability.
Customer perspective: faster response, but also risk of generic or inaccurate communication.
Compliance perspective: data access, retention and approval.
Operator perspective: prompt maintenance, exception handling, source quality.
Leadership perspective: cost, consistency and scalability.
Future-work perspective: which human capabilities become more important when routine drafting is cheap?
The resulting design may automate preparation while preserving human review, invest in exception-handling skills and measure total team load rather than only response time.
The perspective exercise therefore changes implementation, not merely the presentation of the idea.
Worked Example: A Personal Health-Information Workflow
User perspective: wants to understand symptoms and prepare for an appointment.
Healthcare professional perspective: needs accurate timeline, medication list and relevant observations rather than model-generated diagnosis.
Privacy perspective: asks which health details actually need to enter the system.
Risk perspective: asks what happens if a generated interpretation sounds plausible but is wrong.
Future-record perspective: asks how confirmed medical instructions will replace earlier uncertainty.
The workflow becomes: organise facts, label uncertainty, prepare questions, consult the clinician, then update the personal record from professional guidance.
SI supports communication without pretending to become the clinician.
Perspective-Taking in Research
Research benefits from several epistemic perspectives.
Primary-source perspective
What does the original record directly support?
Method perspective
How was the evidence produced, and what are its limitations?
Population perspective
Who does the evidence actually describe?
Historical perspective
Does the claim belong to an earlier period rather than the present?
Contrary-evidence perspective
What credible evidence points in another direction?
Decision perspective
Which evidence actually changes the practical conclusion?
This prevents research from becoming a collection of citations with no model of their scope or relevance.
Perspective-Taking in Writing
Before writing, identify the reader perspective.
What does the reader know already?
What question brought them here?
Which terms need defining?
What evidence would make the argument credible?
What objection will occur before the writer addresses it?
What action should the reader be able to take after reading?
SI can simulate these questions during editing. The writer should still avoid pretending a simulated reader represents all readers.
Use real reader feedback where the stakes or audience diversity justify it.
Perspective-Taking in Negotiation
Negotiation improves when each side’s interests are separated from stated positions.
Position: “I need Friday.”
Possible interest: deadline, childcare, travel, coordination or another dependency.
SI can help generate questions that uncover interests without assuming them.
“What makes Friday important for you?” is stronger than “You are being inflexible.”
Then identify shared and conflicting interests.
Multiple perspective does not guarantee agreement. It can reveal where trade becomes possible and where values or constraints genuinely conflict.
Perspective-Taking and Consent
Consent cannot be simulated.
If a decision assigns work, shares information, changes a booking or affects another person’s rights, their actual agreement may be required.
A model can identify that consent is relevant. It cannot supply the consent.
This is one of the most important boundaries in family, workplace and agentic AI systems.
Perspective Bias: The View You Ask For Shapes the Answer
The prompt itself can frame the perspective unfairly.
“Act as a frustrated customer and explain why this product is terrible” will produce a different analysis from “Map the customer’s likely goals, evidence, frustrations and reasons they may still prefer the product.”
Use neutral role prompts.
Ask for both constraints and potential benefits.
Avoid identity stereotypes and emotionally loaded instructions unless emotion itself is the subject being examined.
A perspective prompt should expose information structure, not manufacture a character.
The Perspective Assumption Audit
Every simulated perspective contains assumptions.
For each important viewpoint, ask:
- What are we assuming this stakeholder values?
- What are we assuming they know?
- What are we assuming they can control?
- What are we assuming they fear or prefer?
- Which of these assumptions can be checked?
Then remove or soften unsupported claims.
This makes perspective-taking compatible with the assumption-challenge method from the previous article.
Perspective and Second-Order Effects
A perspective can change over time because the system changes behaviour.
A student may initially love instant hints, then become dependent on them.
An employee may initially value automation, then find that the remaining work is disproportionately difficult.
A customer may initially value fast AI replies, then become frustrated by repeated escalation loops.
Add a future perspective to recurring systems: what might this stakeholder experience after adaptation?
This links multiple-perspective thinking with second-order thinking.
Perspective and Decision Matrices
A decision matrix can hide perspective conflict inside one set of weights.
Before averaging weights, create separate stakeholder matrices or at least separate criteria contributions.
If a family travel choice scores highest only because one person’s priorities dominate, the matrix should reveal that.
SI can compare stakeholder weight sets and identify options that remain acceptable across them.
Do not turn a social decision into a numerical majority vote when consent or hard constraints matter.
The Multi-Perspective Review After Action
After a decision, ask whether the perspective map predicted the real issues.
Which stakeholder concern actually mattered?
Which simulated concern never appeared?
Which missing perspective became important only during execution?
Which person carried more burden than expected?
Which disagreement was factual and which was value-based?
What question should have been asked directly rather than simulated?
This review improves future perspective selection.
A Perspective Ledger
For recurring systems, keep a lightweight ledger:
Perspective: role or affected group.
Stake: what they gain or lose.
Evidence: what we actually know.
Assumption: what is simulated or inferred.
Constraint: what limits them.
Authority: what they can decide.
Question: what must be asked or verified.
Update: what changed after real input.
This prevents simulated perspectives from being remembered later as real stakeholder statements.
The Perspective Escalation Rule
Move from simulation to real stakeholder input when:
- the stakeholder has high stake;
- their consent is required;
- the decision is difficult to reverse;
- the simulated perspective materially changes the choice;
- the model is making assumptions about private preferences;
- the stakeholder has unique operational knowledge; or
- misunderstanding their view could cause harm or significant conflict.
Simulation is preparation for consultation, not a substitute for consultation.
The Perspective Stop Rule
Stop adding perspectives when new views no longer reveal a material constraint, risk, missing fact or value conflict.
A decision with three affected parties does not become wiser because SI generated twelve fictional personas.
Use the minimum set of perspectives required to understand the system and make the next decision responsibly.
A 30-Day Multi-Perspective Practice
Week 1: practise separating perspective from evidence. Use low-stakes decisions and label every simulated viewpoint.
Week 2: practise stake, knowledge and authority mapping. Include one operator or maintainer in every workflow analysis.
Week 3: use real stakeholder input. Generate questions with SI, ask the actual person and compare their answer with the simulated view.
Week 4: combine perspective-taking with second-order thinking and decision matrices. Review which perspective most often changed the final decision.
At the end of the month, save only the perspective prompts that led to better questions or better system design.
The Final Perspective Check
Before deciding, ask four final questions:
- Whose experience is still missing?
- Which viewpoint is simulated rather than evidenced?
- Which person has high stake but low authority?
- Which real conversation would improve this decision more than another AI-generated perspective?
The purpose of perspective-taking is to widen perception, then return to reality with better questions.
Perspective-Taking in Group Decisions
Group decisions contain at least two problems: understanding what each person needs and deciding how much authority each person has.
Do not begin by averaging everyone’s preferences. First identify hard constraints, legitimate vetoes, areas of shared value and areas where trade is possible.
Example: a family choosing a holiday destination.
One member has a medical-access constraint. Another has a hard budget ceiling. Another strongly prefers outdoor activities. A fourth is flexible.
The medical-access requirement should not be averaged with the outdoor preference. It is a constraint. The budget may also be a constraint. Activity preference is tradeable.
SI can help classify the structure of disagreement before generating a compromise.
Shared decision, unequal consequences
Some group choices affect people unequally. A move may affect a child’s school travel more than a parent’s work if the parent works remotely. A new household routine may place maintenance mostly on one person.
Ask SI to identify which perspective carries the largest downside if the decision is poor.
This does not mean that person automatically decides. It means the cost asymmetry should be visible.
Perspective-Taking in Negotiation
Negotiation becomes clearer when positions are separated from interests.
Position: “I need Friday.”
Possible interests: a fixed deadline, caregiving, travel, another team’s dependency or simple preference.
Do not let SI assume the interest. Use the simulated perspective to produce a question: “What makes Friday important?”
Once interests are known, the option set can expand. Perhaps Thursday afternoon works if another dependency moves. Perhaps the deliverable can be split. Perhaps the real conflict is not date but review time.
Multiple-perspective thinking therefore creates negotiation space by making hidden constraints askable.
Do not negotiate against a fictional person
A model-generated “counterparty” can be useful for rehearsal, but the actual negotiation partner may value different things. Treat the rehearsal as preparation, then update from the real conversation.
Perspective-Taking in Conflict
Conflict often contains several simultaneous layers: events, interpretations, emotions, values and requests.
Ask SI to create a perspective map with those layers separated for each side.
Example: one person says a household task is unfairly distributed. Another says the task was never formally assigned.
Shared fact: one person completed the task three times this month.
Perspective A: repeated completion feels like an unfair default responsibility.
Perspective B: no explicit agreement was made, so the person did not see a standing assignment.
Value conflict: fairness versus flexibility.
Operational gap: no explicit ownership rule.
The solution may be a coordination rule rather than a judgement about motives.
SI helps by moving the discussion from “who is bad?” to “what happened, what did each side believe, and what agreement is missing?”
Perspective-Taking in Research
Research benefits from perspective diversity when the perspectives correspond to different evidence or methods.
For a broad topic, ask for:
- primary-source perspective: what the original records directly support;
- method perspective: how the evidence was produced;
- population perspective: who the findings describe;
- historical perspective: whether the claim belongs to another period;
- practitioner perspective: how the issue appears in operation;
- user perspective: what affected people experience;
- counterevidence perspective: what credible evidence does not fit the main story.
The purpose is not to collect opinions. It is to identify blind spots in evidence and scope.
When a perspective introduces a factual claim, trace it to a source. Do not cite the simulated perspective itself as evidence.
Perspective-Taking in Writing and Communication
Writing improves when the writer can shift from author perspective to reader perspective.
Ask SI to evaluate a draft from several reader states:
- reader who knows the topic;
- reader who is new to the topic;
- reader who is sceptical of the main claim;
- reader who needs a practical answer quickly;
- reader who may misunderstand one key term.
Then compare which revisions are actually useful across readers.
Do not optimise for every reader simultaneously. Define the intended audience first.
Reader perspective is not reader data
A simulated reader can reveal likely ambiguity. Actual audience testing is stronger evidence when the stakes are high. Use real feedback to correct the simulation.
Perspective-Taking in Product or Service Design
A designer sees features. A user sees tasks. A support team sees failure modes. A finance team sees cost. A maintainer sees long-term complexity.
Ask SI to map the same feature from all five perspectives.
Example: adding an AI assistant to a learning platform.
Designer: richer interaction. Student: faster help. Teacher: more practice support. Support team: new failure classes. Privacy perspective: data handling. Maintainer: prompt and model drift.
The map can change launch criteria: not only “does it answer?” but “does it preserve learning, privacy, teacher visibility and maintainability?”
The Perspective Shift Ladder
Use perspective shifts in increasing depth rather than opening with a large persona set.
Level 1 — One alternative viewpoint
Ask what one affected person may see that you do not.
Level 2 — Stake and constraint map
Identify goals, constraints and risks for several key roles.
Level 3 — Evidence comparison
Separate what each role actually knows from what is assumed.
Level 4 — Authority and consent
Identify who can decide, who must agree and who must be consulted.
Level 5 — Future adaptation
Ask how the perspectives may change after the system has been used repeatedly.
Stop at the shallowest level that reveals the decision-relevant blind spot.
The Perspective Gap Test
A perspective gap exists when the decision-maker cannot see a consequence that another stakeholder experiences directly.
Examples:
- a manager cannot see the daily friction of a reporting workflow;
- a parent cannot feel the student’s fatigue;
- a software designer cannot see how a customer handles an error;
- a traveller planning from a map cannot feel the accessibility constraints of a companion;
- an expert cannot know which explanation a beginner finds confusing without feedback.
The repair is not better simulation alone. The repair is data, observation or direct conversation from the missing perspective.
The Perspective Evidence Ladder
Use a simple hierarchy when combining perspectives.
Direct stakeholder statement: what the person actually said.
Direct observation: what happened.
Role-based structural inference: what a person in that role is likely to encounter.
Simulated perspective: a generated hypothesis about possible goals or concerns.
Pure speculation: unsupported motive or internal-state claim.
The lower you go, the more cautious the language should become.
SI can help label these levels so an empathetic narrative does not outrank direct evidence.
The Perspective Update Rule
When real stakeholder input arrives, update the map.
Do not preserve the generated perspective simply because it was elegant.
Example: SI predicts a student will dislike extra practice because of fatigue. The student says the real problem is that the practice feels repetitive and they would accept the same time if the tasks were more varied.
The model should change from “time burden” to “practice design”.
The ability to update is what separates perspective-taking from stereotyping.
The Low-Power Stakeholder Check
Some people are highly affected but have little ability to change the system after a bad decision.
Children, junior staff, patients, customers, caregivers and operators can fall into this category depending on context.
Ask SI:
- Who has high stake and low authority?
- What cost do they carry?
- How can their actual input be gathered?
- Which decision can they reasonably influence?
- What protection is needed if they cannot easily exit?
This does not dictate the decision. It prevents low-power impact from disappearing simply because the perspective is less visible.
The High-Authority Blind-Spot Check
Authority can reduce exposure to operational detail.
A manager may approve a process they never have to run. A parent may choose a timetable they do not personally experience. A system owner may deploy an automation whose errors are repaired by support staff.
Ask: “Which consequence of this decision will the decision-maker not personally experience?”
Then make that consequence visible before approval.
Perspective-Taking and Ethics
Ethical questions often involve conflicting legitimate values: autonomy, fairness, privacy, safety, efficiency, access, loyalty, responsibility.
SI can help map which value each perspective protects and where values collide.
It should not declare a moral verdict merely because one framing sounds more persuasive.
Use perspective-taking to ask better ethical questions: who benefits, who bears risk, who can consent, who can exit, who lacks voice, what duties already exist and what harms are reversible.
The final normative judgement remains human and context-dependent.
A Full Case Study: Choosing an AI Workflow at Work
A team wants SI to draft customer responses from support tickets.
Manager perspective: faster response and lower backlog.
Support-agent perspective: fewer repetitive messages but more difficult exceptions.
Customer perspective: faster replies, but need for accurate context and clear escalation.
Compliance perspective: data handling and inappropriate disclosure risk.
Quality perspective: whether generated replies preserve policy and factual accuracy.
Training perspective: junior staff may see fewer routine cases and need different training to handle the harder residual work.
Maintenance perspective: prompt updates, policy changes, model drift, exception rules.
The final design might automate drafting for low-risk categories, require human review before send, escalate ambiguous cases and sample outputs regularly.
The multi-perspective method changes the permission architecture, training plan and metrics.
A Full Case Study: Choosing a Learning Path
An adult wants to move into data analytics and is comparing a bootcamp, self-study and a part-time formal course.
Learner perspective: time, motivation, prior knowledge.
Employer perspective: evidence of applied capability.
Instructor perspective: prerequisites and feedback needs.
Financial perspective: fees and opportunity cost.
Future-self perspective: which route builds a portfolio and network.
Risk perspective: what happens if the learner cannot sustain the advertised hours.
The analysis may reveal a sequence: complete a short diagnostic project first, then choose the formal route based on evidence of persistence and skill gaps.
The useful outcome is not a simulated employer verdict. It is a better evidence-gathering plan.
A Full Case Study: Family Schedule Conflict
A teenager wants two evenings for an activity. A parent wants those evenings for study. Another family member depends on transport. The school workload is currently high.
Student perspective: identity, friendships, enjoyment, stress relief.
Parent perspective: academic risk and future options.
Transport perspective: time and coordination burden.
Learning perspective: whether the student is actually behind and on which skills.
Wellbeing perspective: total load and recovery.
The map may reveal that the real question is not “activity or study”. It is whether current academic risk requires two additional evenings or a more targeted repair approach.
A diagnostic can reduce the conflict by replacing broad fear with evidence.
A Multi-Perspective Decision Protocol
Step 1: state the decision and your current perspective.
Step 2: list directly affected stakeholders.
Step 3: add operator, expert and maintainer perspectives if relevant.
Step 4: map stake, knowledge and authority.
Step 5: label simulated claims as hypotheses.
Step 6: classify disagreements by fact, interpretation, value, constraint, risk or authority.
Step 7: identify high-stake low-authority perspectives.
Step 8: collect real evidence or stakeholder input where material.
Step 9: synthesise shared facts, different priorities and missing evidence.
Step 10: make the decision at the appropriate authority level.
Step 11: review whose perspective turned out to matter during execution.
The Perspective Preflight
Before using a generated perspective in a consequential decision, ask:
- Is this viewpoint based on real stakeholder input or simulation?
- What evidence supports its factual claims?
- Am I assuming motives?
- Does this role actually have the authority I am assigning it?
- Is someone highly affected but missing?
- Would a direct conversation be cheaper and more reliable than further simulation?
If the answer points toward real stakeholder input, stop role-playing and go get it.
The Perspective Review Card
Decision: what was being decided.
Perspectives used: which roles were considered.
Real input: which views came from actual people or sources.
Simulated input: which were generated hypotheses.
Missing perspective: what was absent.
Key disagreement: fact, value, constraint, risk or authority.
Change caused by perspective-taking: what shifted in the plan.
Execution evidence: which perspective mattered in reality.
Lesson: which viewpoint should be included earlier next time.
This lightweight record helps improve perspective selection without turning empathy into bureaucracy.
The Final Multi-Perspective Rule
Perspective-taking is valuable when it changes the questions, evidence or design.
If the exercise produces only a longer list of fictional opinions, stop.
If it reveals an affected person, hidden constraint, operator burden, value conflict or missing source, act on that discovery.
Use SI to widen the field of vision. Use reality to determine what is actually there.
The Perspective Transfer Test
A perspective method becomes a real thinking skill only when it transfers across domains. Test the same structure on a learning problem, a household decision, a work process and a purchase. The specific stakeholders change, but the reasoning pattern should remain stable: identify affected people, separate stake from authority, distinguish evidence from simulation, and ask which viewpoint reveals a material blind spot.
If the method works only when the roles are obvious, strengthen the coverage questions. Ask who performs the work, who maintains it later, who pays, who receives the benefit, who can veto, who cannot easily exit and who experiences the consequences after the decision-maker has moved on.
Transfer example: learning
The missing perspective may be the learner’s experience of where confusion begins.
Transfer example: work
The missing perspective may be the operator who handles exceptions after automation.
Transfer example: family
The missing perspective may be the person carrying transport or scheduling burden.
Transfer example: purchase
The missing perspective may be future-you maintaining, repairing or replacing the product.
The goal is not to memorise a list of roles. It is to learn to ask which vantage point can reveal a consequence your current position cannot see.
The Perspective Question Bank
Use these questions when you need a fast multi-perspective pass.
Affected person: What consequence do they experience directly?
Operator: What repeated friction or exception do they handle?
Expert: What technical constraint changes the interpretation?
Customer/user: What does success or failure feel like at the receiving end?
Maintainer: What has to be updated, checked or repaired later?
Risk owner: Who is accountable when something goes wrong?
Future self: What future option, cost or dependency could this create?
Low-power stakeholder: Who is highly affected but has little ability to change the decision?
Adversarial perspective: How could the plan fail even if everyone follows it?
Evidence perspective: Which claims are supported and which are merely plausible stories?
A short question bank is often more useful than elaborate personas because it keeps the perspective tied to decision structure.
The Real-Conversation Handoff
The strongest output of simulated perspective-taking is often a better real-world question.
Instead of “The student probably hates this schedule,” the handoff is: “Which part of the week feels most overloaded, and which support actually helps?”
Instead of “The operator will resist automation,” the handoff is: “Which exception takes the most judgement today, and what would make an automated handoff unsafe?”
Instead of “The customer cares most about price,” the handoff is: “Which trade-off matters most when choosing between lower price and faster support?”
A good SI perspective exercise ends by reducing uncertainty through observation, evidence or conversation.
Perspective Quality Control
Before keeping a generated viewpoint, inspect four things.
Specificity: does the perspective reveal a concrete goal, constraint, risk or question?
Evidence: is the viewpoint grounded in known information or clearly labelled as hypothetical?
Decision value: could it change what you verify, design or decide?
Respect: does it avoid stereotyping, diagnosing or inventing motives?
Discard perspectives that fail these checks. A smaller set of disciplined viewpoints is better than a long set of fictional narratives.
The Multi-Perspective Exit Test
Before ending the analysis, confirm that you know which facts are shared, which differences are values rather than facts, which stakeholders require direct input, which person or group has decision authority, and which hidden cost became visible only after shifting perspective.
If those elements are clear, the perspective work has done its job. Continue to evidence gathering or decision-making instead of generating more viewpoints.
The best perspective shift changes the model enough to improve the next action, then gets out of the way.
The Perspective Boundary Rule
A perspective exercise should stop at the boundary between useful simulation and claims that require real evidence. SI can help you imagine what an operator might worry about, but it cannot certify that your actual operator has that concern. It can suggest what a customer may value, but it cannot replace customer research. It can model what future-you may regret, but it cannot know your future preferences.
Use the boundary rule: simulate to discover questions; verify to discover reality. When a simulated perspective becomes load-bearing for the decision, move from modelled viewpoint to direct source, observation or stakeholder conversation.
This rule is especially important when the perspective concerns another person’s consent, health, finances, employment, family obligations or other high-consequence matters. The more consequential the claim, the less appropriate it is to treat generated perspective as evidence.
A well-designed multi-perspective workflow therefore alternates between expansion and correction: generate possible viewpoints, identify the material ones, gather real input, update the map, and discard whatever the evidence does not support.
The result is not a collection of personas. It is a more complete and better-grounded model of the problem.
The Perspective Accuracy Check
Before a perspective enters the final decision, ask whether it has been corrected by reality. Did the student actually say workload was the problem? Did the operator actually report the predicted exception? Did the customer evidence support the assumed priority? Did the family member agree to the responsibility?
If the answer is no, keep the statement in hypothesis language. “This may be a concern” is honest. “This stakeholder believes” is not justified until the stakeholder has supplied the belief.
The distinction becomes increasingly important as SI systems become more fluent at role simulation. Fluency can make fictional viewpoints feel researched. The safeguard is provenance: where did this claim about the perspective come from?
Use a simple label beside each material viewpoint: directly stated, directly observed, structurally inferred, or AI-simulated. Only the first two should be treated as direct stakeholder evidence.
This small discipline preserves the value of perspective-taking while preventing generated empathy from becoming fabricated testimony.
The Perspective Documentation Rule
When a perspective materially affects a decision, record whether it came from a real stakeholder, direct observation, role-based inference or AI simulation. This single label prevents a later summary from flattening all four into the same status.
For example, “student says the schedule feels overloaded” is direct stakeholder evidence. “A student in this position may feel overloaded” is simulation. Both can be useful, but they should not be stored or cited as though they were equivalent.
As the decision moves into execution, replace simulated perspectives with real input wherever the person has high stake, unique knowledge or required consent. The final record should show which concerns were confirmed, which were rejected and which remain unresolved.
This is the last guardrail that keeps multiple-perspective thinking grounded: remember where each perspective came from.
Frequently Asked Questions
Can SI tell me what another person thinks?
No. It can generate plausible perspectives or questions, but it cannot know a real person’s internal state unless that person has provided relevant information.
Why use multiple perspectives?
Different viewpoints reveal different constraints, incentives, risks and information. The exercise can improve the decision model before action.
How many perspectives should I use?
Use enough to cover material stakeholders and hidden system roles, but stop when additional perspectives no longer change the model.
Should every perspective get equal weight?
No. Perspectives differ in stake, knowledge, evidence and authority. Multiple-perspective analysis is not a voting system.
What is the difference between perspective and evidence?
Perspective is a vantage point that shapes which questions and consequences become visible. Evidence supports factual claims.
How do I avoid mind-reading?
Use tentative language, focus on goals and constraints, and turn simulated perspectives into questions for the real person.
Can perspective-taking help with conflict?
Yes, particularly by separating observations, interpretations, values and requests. It should support rather than replace the actual conversation.
Why include the operator perspective?
Operators see exceptions, maintenance and handoff problems that high-level plans often miss.
Why include future-self perspective?
It highlights delayed costs, lock-in and capability changes that may not matter immediately.
What comes next?
The next guide shows how to use SI when you do not yet know what question to ask.
Helpful Reading
- How to Leverage Your Life with Super Intelligence
- How to Use Super Intelligence for Second-Order Thinking
- How to Think More Clearly with Super Intelligence
- How to Use Super Intelligence to Challenge Your Assumptions
Change the View, Then Return to Reality
Multiple perspectives are useful because one vantage point rarely reveals every constraint.
But the purpose is not to create fictional certainty about other people.
Use SI to ask what another role might notice. Use real sources and real conversations to discover what is actually true. Then return to the decision with a larger, more accurate map.
Perspective-taking should expand the questions you ask, not invent the answers other people would give.