Skip to main content
FRAMEWORKS

Mental Models for Building Products

Four frameworks that guide how we approach product development—and help clients build conviction before committing resources.

Clarity Precedes Illumination

Design the circuit before the lightbulb

The most elegant execution is meaningless without an underlying system of clarity, behavior, and intent. A lightbulb is a brilliant invention, but it only works because a circuit directs energy with intent.

Modern product teams rush to be the lightbulb—the visible execution. They skip the essential work of designing the circuit. We start with clarity: the system that gives shape to energy and ensures the right experience is illuminated for the right people.

In Practice

  • Map the problem space before the solution space
  • Define behavior change, not features
  • Build conviction before execution

Course Before Speed

Direction is the new bottleneck

AI has given everyone unprecedented speed. But without clear direction, more speed only gets you lost faster. A ship moving slowly in the wrong direction is a problem. A ship moving at high speed toward disaster is a catastrophe.

The rise of AI has accelerated everyone's engines, but this has created a new bottleneck. Speed is no longer the primary constraint; direction is. We serve as the navigator—charting the map, revealing unmapped waters, and providing a clear bearing before the engines ignite.

In Practice

  • Validate assumptions before scaling execution
  • Test the hardest risks first
  • Build the map before accelerating

Environment Shapes Behavior

Build systems where better outcomes are the default

To change something, you don't fight the existing system. You build a new one that renders the old one obsolete. Buckminster Fuller taught us that lasting change comes from designing new environments, not fighting old systems.

Most products try to change user behavior through friction, forcing functions, or persuasion. We build new environments—workflows, behavioral systems, and mental models where better outcomes happen naturally.

In Practice

  • Design for defaults, not willpower
  • Make the right choice the easy choice
  • Build systems, not just features

Working Software as Thinking Tool

Build to think, not just to ship

Prototypes aren't just for testing ideas—they're for generating them. The act of building reveals constraints, opportunities, and insights that no amount of planning can surface.

Specs describe what you think you know. Prototypes reveal what you don't. We use working software as a thinking tool—a way to externalize assumptions and test them against reality before committing to expensive production builds.

In Practice

  • Prototype the riskiest assumptions first
  • Use builds to generate clarity, not just validate it
  • Ship to learn, iterate to ship

Applying These Models

These aren't abstract principles—they're operational frameworks we use on every engagement. They shape how we scope projects, where we focus attention, and how we sequence work to reduce risk.

When you work with Rationale, you're not just getting execution. You're getting a systematic approach to building conviction—one that's been tested on our own products and refined through dozens of client engagements.