Building Good Products Means Understanding More Than Tech
Published at March 14, 2026 ... views
One thing I keep coming back to is this: being good at building things is not the same as being good at building the right things.
It's fun to obsess over models, systems, stacks, and frameworks. But if nobody actually needs what you build, even great execution misses the point. You're basically polishing a spaceship that flies to the wrong planet.
The best engineers I've seen are not just technically strong. They understand the customer, the business, and the "why" behind what they're building.
That's what pulled me into product thinking. Not "business" in the spreadsheet-and-buzzword sense. More like: how do you think clearly about who you're building for, what problem you're solving, and whether any of it actually matters?
Tech alone is not enough (unfortunately for us)
Technical skill matters a lot. But by itself, it's like having a great engine with no steering wheel.
You can be smart, creative, and hardworking — and still struggle if you don't understand the customer or the real need behind the product.
That doesn't mean every engineer needs to become a marketer overnight. It means the further you go, the more valuable it becomes to see the bigger picture.
This reframes engineering in a healthier way. Technical work is not isolated. It's one link in a chain of decisions that determines whether something actually ships and matters.
The most valuable people own pieces of the problem
Here's an idea that stuck with me: the people who become indispensable are not the ones who complete the most tasks. They're the ones who can own a meaningful chunk of work so well that other people stop worrying about it.
That trust doesn't come from raw intelligence. It comes from judgment, context, and follow-through. It comes from understanding not just what you were asked to do, but why it matters.
That's a much better path to growth than "learn more tools." Tools change every year. Judgment compounds.
Every organization still has to create value somehow
Different organizations look different on the surface, but they all face the same core challenge: sustain yourself or disappear.
For-profit, non-profit, government, military — all of them operate with constraints, goals, resources, and some kind of value model. Even a non-profit still needs revenue to keep the lights on. Even a government agency has stakeholders and budgets.
Products don't exist in a vacuum. They sit inside organizations that need to survive, prioritize, and make trade-offs. Understanding that context makes you a better builder.
A product only matters if it solves something people care about
A product is not valuable because it exists. It becomes valuable when it helps someone do something they actually care about — something practical, emotional, social, or some mix of all three.
That leads directly to : why is this thing worth the customer's money, time, trust, or attention?
If you can't answer that clearly, you'll struggle to build the right features, make the right trade-offs, or even explain why the product should exist. It's like cooking dinner without knowing who's eating. You might make something delicious, but it could also be a peanut dish served to someone with a peanut allergy.
People don't buy the thing — they buy what the thing helps them do
This is probably my favorite idea from the whole set.
The framework shifts focus from the product itself to the outcome the customer actually wants.
Nobody buys a hammer because they love hammers. They buy a hammer because they want to hang something. And even that's not the full story — maybe they want to hang a family photo. Or mount a TV. Or make a room feel more like home.
Clayton Christensen, who popularized this idea, used to tell the story of a fast-food chain trying to sell more milkshakes. They improved the taste, the texture, the price. Nothing worked. Then someone asked: what job is the milkshake being hired for? Turns out, morning commuters were "hiring" milkshakes to make their boring drive less boring and keep them full until lunch. The competition wasn't other milkshakes — it was bananas, bagels, and boredom.
Once you start thinking like this, features stop being the center of the conversation. Outcomes take over.
Product-market fit is the hard part
A lot of good ideas sound promising in isolation.
But is where things get real.
It's not enough for a product to be technically possible. It's not enough for it to be interesting. It's not enough for a few friends to say they like it. (Your mom doesn't count either.)
The harder question: is the right product meeting a real market need in a way that can actually sustain itself?
That intersection looks simple in a diagram. In real life, it's incredibly hard to find. Marc Andreessen described it well: "you can always feel when product-market fit isn't happening... and you can always feel it when it is." Before it clicks, everything feels like pushing a boulder uphill. After it clicks, the boulder starts rolling on its own.
That's probably why so many products look exciting at first and then quietly disappear. Enthusiasm feels linear. Failure usually compounds.
Revenue streams matter more than they first appear
Sometimes the money doesn't come from where you'd expect.
A product might look like it makes money from direct sales, but the real engine could be subscriptions, advertising, ecosystem lock-in, or something else entirely.
Case in point: Google pays Apple roughly $20 billion per year just to remain the default search engine on iPhones. Apple's "product" here isn't a search engine — it's access to eyeballs. Understanding the real revenue engine behind a product changes how you think about priorities.
That's also where the rundle comes in — Scott Galloway's term for a recurring revenue bundle. Think Amazon Prime: streaming, shipping, music, photos, all bundled into one sticky subscription. Predictable revenue, higher lifetime value, and a customer who now feels guilty canceling because "but I use the free shipping." It's the business-model equivalent of a roach motel. Customers check in, but they don't check out.
Head, heart, and gut — a quick product lens
Some products win with the head. They feel rational, useful, efficient. Excel doesn't make anyone cry tears of joy, but it gets the job done.
Some win with the heart. They feel enjoyable, meaningful, or beautiful. Nobody needs a Moleskine notebook, but writing in one feels different than scribbling on printer paper.
Some win with the gut. They signal status, identity, or ambition. A Rolex tells time exactly as well as a Casio. The extra $9,000 buys you a conversation starter.
Most products hit more than one. The iPhone is all three at once: useful (head), delightful (heart), and a status symbol (gut). That's why people sleep outside stores for it.
Not every product is a painkiller
Some products are painkillers. They solve a sharp, urgent problem. When your tooth hurts, you don't comparison-shop dentists — you call the first one with an opening.
Some are more like vitamins. Nice to have, maybe even delightful, but not urgent. "I should really start using a meditation app" is something millions of people say and approximately twelve of them actually do.
This distinction matters because it affects everything: adoption, retention, pricing, and how hard the product has to fight to earn a place in someone's daily life.
The RIBS test: a practical product filter
One of the more useful frameworks is the RIBS test.
A product idea gets stronger if it is:
- Relevant — does it solve a real need for a real market?
- Inevitable — does it feel like the world is naturally moving toward this?
- Believable — is the solution technically credible, and is the team capable of building it?
- Scalable — if it works, can it grow far beyond a small niche?
I like this because it forces an idea to face reality early. Not just "is this cool?" but "is this worth betting on?" It works at every scale — whether you're in a giant company deciding what gets prioritized, or in a garage deciding what deserves your next six months.
The Kano model: not all features matter equally
The splits features into three types based on how they affect satisfaction.
Must-have features: nobody praises them, but if they're missing, the product feels broken. Like seatbelts in a car. You never think "wow, great seatbelts!" but you'd notice instantly if they weren't there.
Performance features: the better they get, the happier people are. Faster loading, more storage, better battery life.
Attractive features: people don't expect them, but when done well, they create genuine delight. The first time the iPhone responded to a pinch-to-zoom, nobody had asked for it. But everyone loved it.
This is a great counterweight to feature creep. Just because something can be built doesn't mean it should be. Some features move the needle. Others just make the settings menu longer.
Product thinking and technical thinking should connect
All of this product theory is great, but at some point you still have to build something real.
Once you understand the customer, the , and the , the question becomes: how do you actually deliver it?
And for most modern products, that means understanding how clients and servers talk to each other.
The web is really a conversation
Most web systems boil down to one pattern: a client asks, a server answers.
That's it. Everything else is decoration.
Browsers, phones, smart devices, APIs, voice assistants — they're all just different shapes of this same conversation. Once you see it, modern systems feel a lot less mysterious.
Client-server is a foundation, not just a web detail
The web is just the most accessible way to learn a pattern that shows up everywhere.
Whether it's a browser talking to a web server, an iPhone talking to an API, or a smart fridge telling the cloud it's out of milk — the underlying idea is the same. Distributed systems are conversations.
Requests are simple, even when the systems get complex
At a high level, a client usually does one of four things:
GET, POST, PUT, DELETE. Read, create, update, delete. A surprisingly large amount of modern software can be understood by starting from these four interactions. It's like learning that every sentence in English has a subject and a verb — once you see the structure, the complexity becomes manageable.
Frameworks help you focus on what matters
You can build everything from scratch. And you can also hand-wash your clothes in a river. But you probably shouldn't.
Frameworks exist because so much of web development is already patterned: routing, request handling, database integration, sessions, caching, and testing.
Using a framework doesn't make the work less important. It means you spend more time on product logic and less time reinventing plumbing.
A product only works when the thinking and the building actually meet
If I had to pull all of this into one idea:
The best products don't come from thinking only about business or only about engineering. They happen when both meet in a useful way.
Not just building cool things. Not just analyzing customers. But connecting the need, the value, the system, and the implementation into one coherent whole.
A few things I'm taking away
- Technical skill matters, but context is what makes it valuable — a great engineer who understands the customer is worth ten who don't
- Products succeed when they solve meaningful , not when they just have interesting features
- Your should be clear enough that you could explain it to someone at a coffee shop in one sentence
- is harder than building a prototype, and most products fail because they skip this step, not because of bad code
- Revenue streams aren't always what they appear — understanding where the money actually comes from changes your priorities
- The web is one of the most accessible ways to learn client-server communication, which is a pattern that shows up in almost everything
- The is a great antidote to feature creep: not every feature moves the needle, and some just add noise
- Ownership and judgment compound faster than technical knowledge alone — tools change, but the ability to think clearly about problems stays with you
That last one is where this all lands for me. This isn't just about building better products. It's about becoming the kind of engineer who can look at a problem and ask the right questions before writing a single line of code. And honestly, that feels like a more useful goal than learning any specific framework.
Sources
- Theory of Jobs to Be Done (Clayton Christensen, HBS) — the original framework for understanding why customers "hire" products, with the famous milkshake example
- The Only Thing That Matters (Marc Andreessen, 2007) — the essay that defined product-market fit as the single most important thing for a startup
- Kano Model — ProductPlan — overview of Noriaki Kano's framework for categorizing features by their impact on customer satisfaction
- Court documents reveal Google's payments to Apple reached $20 billion — Business Insider reporting on the Google-Apple search deal
- The Algebra of Happiness (Scott Galloway) — source of the "rundle" concept (recurring revenue bundle) and broader product strategy thinking