Building products: The "Why? Ok, so?" framework

Posts like this one are hard for me to write. I'm a romantic. I romanticize designing, coding, and building products. I think building a good product, a product people actually want to use, is closer to art than science. I've spent most of my career dissecting the minds of users and building experiences and functionalities that become critical to them as I only work on mission-critical products.

But every artist, even the most methodical UX designer, needs a scientist that grounds them. Our art only gets us thus far. We get tangled in the web of emotions and we start calling our product "our baby". We need data-oriented people who check our wildest facts and challenge our assumptions. We need revenue-oriented people who ask the tough questions.

So the tough question that I'm proposing to you today is "Why?". It took me years to discover this question in product-building, and a few more to muster the courage to be brutally honest with myself and with others when answering it.

Most people don't ask why

Most teams, companies, and organizations don't ask why. The most creative people ask why in petit comité and very few are brave enough to ask in group settings. If Zoom had an in-meeting "Why?" button, the global GDP would increase in a noninsignificant way.

Instead, we spend weeks, months, and years, building features, products, and systems that don't scale, are not needed, and no one wants. The worst part? That Hanlon's razor plays an important part: a lot of the times this happens, it's not for a perverse misalignment of incentives. It's just incompetence.

Why don't we ask why?

Most of the time, because no one wants to be the party pooper. The biggest cultural shock I experienced when I moved to San Francisco was that people didn't speak up. Ironically, this gets worse and worse the more positive and happy the company culture is. Being a "team player" means smiling and doing as you're told, following the prevailing team sentiment.

Mind you, no one is actively seating you down and asking you to keep quiet. It's a subtle cultural trait enforced via peer pressure and west-coast manners: dissenting opinions are often met with forced apathy, odd looks, and mobbing.

The best teams have realized that is the root of disaster. Doing things for "shits and giggles" or just because someone in a position of authority, having created a top-down culture, said so. I'm a firm believer that this is the reason why billions have been wasted on the most useless crypto projects, NFTs, and many more will be lost to vapid projects with no useful outcome, while real crypto infrastructure projects go unfunded.

"Why?" as a cultural trait

When I decide who to work with or who to invest in, I always choose people who ask why, especially people who don't mind others asking why and challenging their assumptions. It takes a significant amount of self-awareness and tamed ego to be brutally honest with yourself. That's the people I will spend my time with. Those are the people shaping the future.

Not all is lost. If you work in a team that doesn't ask why and is just building mindless features, don't wait till tomorrow. Ask people to speak up, ask why rhetorically. Create a culture where no one is afraid of being the "party pooper". Party poopers save companies. They save teams from working on garbage. If you work at a company that refuses change: leave. There's no more stagnant place, and no bigger waste of professional time, than somewhere you're not learning by asking the tough questions. Talented people need a challenge.

The "Why? Ok, so?" framework to build better products

The most pretentious thing I've done this week is calling this a framework. So we'll call it a "2-question reality checker". Think of it as the kryptonite to most reality distortion fields. Even the most charismatic people can't escape from it.

Users, like suspects in a Hercule Poirot novel, have to have motives. There must be a reason why they want to use your product. Next time you're designing a new feature or product, please ask yourself, and your users, why they'd want to use it. I kid you not, most companies don't do this. Run it as an exercise team internally. Do it with different types of stakeholders.

Example: Our new amazing, slick, product magically connects shippers with freight brokers, creates a BOL, sends a request, and schedules a truck.
"Cool. Why do users need this?"
Well, our UX is incredible, much better than incumbent old systems.
"No, I understand the UX is better, but why would the user care?"
Oh, because they can book loads faster.
"Ok, so? Why is that important?"
Well, if they book loads faster and better, they can get better prices and have more time to keep selling.
"Ah, so their revenue increases and they also save costs?"
Yes.

One more thing: B2B software

Hopefully a small tidbit. I plan another post to dive a little deeper into this "framework" of sorts, some common examples I've run into, and most importantly: how not to collectively fall for fake explanations. It's very easy to lie to yourself and convince others that your product will do X, Y, and Z when it does neither of those things.

For now, I'll leave you with one last thought: in my humble opinion, every final answer of the "why? ok, so?" back and forth should end with the words "revenue" or "costs" if you're working on B2B. If the ultimate explanation of your B2B product's existence isn't defined by either of those 2 things or a measure connected to cash flow, then you're doomed.

Business employees need well-designed, well-structured software. Businesses need to increase revenue or cut costs. (I'm personally less interested in building things that cut costs down, as I prefer building software for people with growth mindset in non-zero-sum spaces, but that's a whole different rant)