THE HORSE IS BEHIND THE CART
During my time studying at Wharton, an instructor showed us a picture of a horse and cart. The horse was positioned behind the cart. The driver sat at the front, whip raised, looking expectant.
Nothing was going to move.
It was funny for about two seconds. Then it was uncomfortable, because I had seen this exact configuration in real products, real teams, and real decisions — including some of my own.
The backwards cart in product building
The backwards cart is what happens when you build the solution before you understand the person using it.
It looks like shipping features before watching anyone actually use the product. It looks like designing an interface around what is technically convenient rather than what feels natural. It looks like writing the code first and asking "who is this for?" second.
The cart is beautifully built. The horse is in the wrong position. Nothing moves.
A note on attention
Zuckerberg once told a Facebook engineer at 2am: figure out a way to capture people's valuable attention, and you can always figure out how to turn that into money later.
That advice is often read as a growth-first, monetize-later strategy. But the word that matters is valuable. Valuable attention is attention someone gives willingly because what you built is genuinely useful to them.
That is the opposite of a backwards cart. The horse — the value — has to come first. The cart — the revenue, the engagement, the metrics — follows when the horse is in the right position.
Build something worth paying attention to. The rest figures itself out.
What Apple taught me about order
The Genius Bar had a structured troubleshooting methodology that was easy to dismiss as bureaucratic — it felt like following a script. But the script existed for a reason: it forced you to understand the problem before you reached for a solution.
Swap the order and you waste time, replace parts that do not need replacing, and occasionally make things worse. I saw it happen. I did it myself, early on.
The best technicians I worked with were not the ones who knew the most fixes. They were the ones who asked the best questions before touching anything.
What Curious Garden taught me about users
When I built Curious Garden, the temptation was to build what the technology made possible. The Gemini Live API could do a lot. I could build a lot.
But the user is a child. A child does not want a feature-rich interface. A child wants to feel heard, helped, and not confused.
Every UX decision I made — card-first instead of transcript-first, explicit camera capture instead of always-on vision, short spoken responses instead of long text answers — came from asking what the child actually needs in that moment, not what the system can technically deliver.
The horse has to be in front of the cart. That is not a design principle. It is the only configuration that works.
The question that fixes it
Before drawing, building, or coding anything, one question reorders everything:
Who is this for, and what do they actually need right now?
Not what they might need. Not what would be impressive. Not what is easiest to build. What they actually need, right now, in this moment.
Answer that first. Build second.
The cart goes nowhere until the horse is in front.