Pablo Hernandez Leal
CommunicationDecisions

Change the Representation

Is this actually small, or does it only look small in the representation I'm using?

Use this when two people describe the same change as radically different in size or complexity.

You’ll be able to restate a comparison so that different descriptions can be checked against the same facts.

The idea

Something can be small at one interface and large inside the system—or technically difficult while almost irrelevant to the user.

Worked example · illustrative

Moving a meeting by one hour

Situation. Someone suggests moving a regular meeting from 4 PM to 5 PM. It’s a small shift on the shared calendar, but one person asks to keep the original time.

The tempting conclusion. It’s only an hour. Surely we can make that work.

What changes the view. They explain that finishing later would mean missing their usual train and being late for childcare pickup. On the meeting calendar, you’re moving one box. In their day, you’re changing how they get home and who picks up their child. Someone with a free evening might barely notice the change.

What this supports. Looking at the meeting alongside the rest of the day gives everyone a clearer picture of what moving it would mean. A shorter meeting or a different day might work better. There may still be competing needs, but “only an hour” no longer tells the whole story.

Useful when

Estimating a proposed changeCoordinating schedulesDiscussing scopeComparing visible effort with downstream consequences

Watch for

A more complicated representation isn't automatically the more relevant one. Ask which representation matters for the decision.

Where this came from

Engineering, Product work

Related tools

Look at the BoundaryComplements

Read the reasoning

Problems at the BoundaryPrimary post · Sep 24, 2026