Thinking

Ideas that inform how we work.

Not a blog. Not a portfolio. A record of how we think about the problems we help people solve.

Why "Move Fast and Break Things" Was Always Bad Advice

The phrase entered the technology lexicon as a badge of startup ambition. It left behind a generation of engineers who conflated carelessness with speed, and a generation of products that broke trust before they built it. Speed matters. Carelessness is expensive. These are different things.

The fastest teams we've worked with don't move fast by cutting corners — they move fast by being extremely clear about what they're building and why. Clarity eliminates the rework that slows everyone down. The advice should have been: move fast and be deliberate.

The Prototype Is the Argument

When a team argues about a product decision, they are arguing about competing mental models of how the world works. One person thinks users will understand the flow. Another thinks they won't. There's only one way to resolve it: build the thing and test it.

Prototypes are not deliverables. They are arguments made tangible. The purpose of a prototype is to kill bad ideas quickly and cheaply — before you've invested six months writing code for something that doesn't work.

What NASA Taught Me About Product Requirements

NASA's requirements documents are legendary for their specificity. Every interface, every measurement, every constraint is stated explicitly. This seems like bureaucratic overhead until you consider what happens when requirements are vague: ambiguity gets resolved by engineers making guesses, and guesses made at 3am under deadline are often wrong.

The lesson isn't to write thousand-page requirements documents. It's that the cost of vagueness is paid downstream, and it's always higher than the cost of specificity upstream. Write the requirement. Save the argument.

The Best Products Are Designed Backward

Start with the experience you want someone to have. Not the features you want to build, not the technology you want to use — the experience. Then ask: what would have to be true for that experience to be real? That question drives every decision backward through the design process, from launch to line of code.

Forward design produces feature lists. Backward design produces coherent products. The difference is whether you started from the user or from yourself.

Constraints Are Not Obstacles. They Are the Work.

Every product engagement starts with a set of constraints: budget, timeline, technical debt, team size, existing infrastructure. The instinct is to treat these as problems to solve before the real work begins. That instinct is wrong.

Constraints are the creative material. The best products we've built were shaped by tight constraints that forced us to be more precise, more deliberate, and more inventive than we would have been with unlimited resources. Abundance is the enemy of clarity.

Why Every Software Project Needs a Minimum Viable Process

The opposite of no process is not heavy process. It's a minimum viable process: the smallest set of agreements, rituals, and documentation that lets a team operate without constant coordination overhead. Without it, teams spend more time negotiating how they work than actually working.

We've found that three things cover most teams: a clear definition of done, a shared place for decisions and their rationale, and a weekly rhythm for reviewing progress and adjusting priorities. Everything else is overhead until proven otherwise.

The Hidden Cost of the Last 10%

In almost every project, the last 10% of scope takes 40% of the time. Not because the work is harder — because of perfectionism, scope creep, and the difficulty of saying "done." The last 10% is where good products go to die, and where projects go over budget and over deadline.

Shipping discipline is a skill. It requires the ability to distinguish between things that matter to users and things that matter only to you, and the courage to leave the latter for later. The version that ships is better than the version that never does.

Observation Is a Design Tool

The most important design tool we use isn't Figma. It's attention. Watching people use software — without intervening, without explaining, without defending our design decisions — is how we learn what's actually true about the product. Everything else is a guess.

Most design failures are observation failures. We designed for the user we imagined, not the user who exists. The remedy isn't better design taste. It's more time watching people struggle, and less time assuming we know why.