When people say “product,” they’re often talking about two very different games: one dominated by physics and hard constraints, the other dominated by intent, feel, and taste.
In this post, we’ll unpack those two worlds, anchor them on the technology S‑curve, and explore how your design process, team, and strategy should change depending on which world you’re in.
At a high level, you can think of product work falling into two broad archetypes:
1. Engineering‑constraint design: Deep tech, IP‑heavy, early‑curve products where the limiting factor is what is physically or technically possible.
2. Intent, feel, and taste design: Mature, commoditized technologies where the limiting factor is whether users _want_ it—experience, aesthetics, story, and brand.
These archetypes are simplifications, but they’re useful because they drive completely different rhythms of R&D, validation, and differentiation.
---
Most technologies follow an S‑curve: slow progress early, rapid improvement in the middle, then flattening as you hit physical or architectural limits.
Early on, you invest heavily just to make the thing work at all; later, the core tech stabilizes and value shifts to integration, design, and ecosystem.
As a technology matures and components standardize, offerings converge on similar underlying tech and costs, and design becomes the main visible differentiator.
That is exactly the transition from an engineering‑constraint game to an intent, feel, and taste game.
---
In engineering‑constraint design, your primary question is: “What does the universe allow us to do?”
You are pushing against fundamental limits—material properties, thermodynamics, algorithmic complexity, safety, or regulatory constraints—rather than styling or brand.
Typical examples include:
Investors and analysts group these under deep tech: technologies built on scientific discovery or meaningful engineering innovation, where progress depends heavily on R&D and validation rather than just market insight.
Deep‑tech companies usually spend their first years tackling technical risk—proving that something is _possible_ and _repeatable_ at all.
A few patterns almost always show up:
These teams run lab work, FEAs, simulations, and physical testing long before they worry about “delightful UX.”
Their milestones read like “achieve X efficiency,” “meet Y lifetime cycles,” or “pass Z regulatory test,” not “ship onboarding v2.”
Deep‑tech ventures typically require larger early equity rounds, expensive equipment, and non‑dilutive funding to survive the long pre‑revenue phase.
Manufacturing ramp‑up, regulated roll‑outs, and long procurement cycles create a “late‑stage wall” if you haven’t planned capital and proof points carefully.
The moat is in patents, proprietary processes, or core performance curves—better energy density, better signal‑to‑noise, better throughput, or dramatically lower cost per unit at scale.
Brand and UX still matter, but they are downstream of whether the technology beats alternatives on objective metrics that customers care about.
In this world, design is in service of making the tech work, safe, and viable at all—mechanical design, thermal management, reliability engineering, and test design are the “UX” your first customers buy.
---
On the other end, you have product categories where the core technology is stable, widely understood, and easy to manufacture or source.
Components are standardized, supply chains are mature, and a competent OEM can deliver “good enough” performance with little novel engineering.
When that happens, design becomes the primary battlefield.
Product differentiation lives in how it feels to use, how it looks on a shelf or in a feed, what story it tells about the user, and how coherently it plugs into their life.
Examples range from consumer electronics accessories and Bluetooth speakers to kitchen goods, tumblers, and many software categories where infrastructure is commoditized.
Common patterns in this second world:
Hardware components, manufacturing processes, or software infrastructure are available off‑the‑shelf, with many vendors capable of hitting similar spec sheets.
Competing brands often share suppliers, factories, or code bases while competing fiercely on experience and brand.
As one UX essay notes, once a technology is well established, design becomes the key way to stand out because underlying technology and parts converge.
That includes interface flows, micro‑interactions, ergonomics, packaging, and how the product onboards you emotionally into its world.
In saturated household goods, brands differentiate through innovative packaging, tactile features, subtle scents, and emotionally resonant storytelling, not radically new chemistry.
Hardware design firms talk about crafting aesthetics, materials, and UX/UI so products “pop” visually and feel frictionless to use, precisely because performance is already baseline good.
At this stage, the primary design question shifts from “What is possible?” to “What do we want people to feel, believe, and do?”
Engineering is still crucial, but it is optimizing reliability, cost, and manufacturability under a strong vision for the user journey.
---
A few canonical examples help make this concrete:
Multiple MP3 players existed before the iPod, all based on similar digital audio technologies and storage media.
The breakthrough was not inventing MP3; it was designing a far better experience that integrated hardware, software, and content—the scroll wheel, iTunes, and a clear narrative of “1,000 songs in your pocket.”
You can source double‑wall steel tumblers from overseas manufacturers with similar thermal performance at a lower price point.
YETI differentiated by brand story, perceived quality, and lifestyle signaling—“this is who you are when you use this”—layered on top of competent but not magically unique engineering.
Commentators have pointed out that PCs don’t _have_ to be pure commodities competing only on price; industrial design and software experience can still create excitement and willingness to pay.
Good‑looking hardware, better screen typography, and more polished software UX have all been used to escape pure price competition in a maturing category.
In each case, the _physics_ were available to everyone, but the intent, feel, and taste of the design created the moat.
---
Because the problems are so different, the design processes diverge sharply.
Teams start from “Can we hit X performance at Y cost within Z constraints?” rather than “How might we delight this segment?”
User research still matters, but early users are often co‑developers—governments, enterprises, or specialists who tolerate rough UX in exchange for breakthrough capabilities.
The primary prototypes are simulations, bench tests, and physical experiments rather than Figma flows.
Design reviews look like design‑for‑manufacturing and safety reviews, tolerance stacks, FMEAs, and reliability analysis.
You celebrate hitting efficiency, precision, durability, or runtime numbers; customer satisfaction is often measured via performance against spec and successful pilots, not NPS.
Go‑to‑market is gated by certifications, pilot deployments, or demonstrators crossing specific technical thresholds.
Here, you ask “Where does this fit in someone’s life?” and “What tension or aspiration are we designing around?”
Detailed personas, journey maps, and UX research drive the definition of experience before engineering optimizes cost and robustness.
You iterate on flows, language, visual identity, and lightly functional prototypes to understand how people perceive and feel the product.
For physical products, that includes mock packaging, material samples, and sensory cues like sound and haptics to build a cohesive feel.
You watch adoption, retention, satisfaction, and perceived differentiation—elements like shelf impact, unboxing delight, or reduction in friction at key moments.
Because the underlying tech is similar, the battle is for mindshare and emotional resonance more than raw performance numbers.
Both modes require collaboration between engineering and design, but the direction of constraint‑setting flips: in deep tech, engineering constraints box design; in mature categories, design intent boxes engineering.
---
The two archetypes also imply very different organizations and cultures.
Founders tend to be scientists, hardware engineers, or deep specialists, and the earliest hires are often PhDs and domain experts.
Product management is closer to technical program management, orchestrating complex R&D roadmaps and experiments.
Investors familiar with deep tech expect slower early ramps because the first years go into tackling tech risk, not scaling marketing.
Non‑dilutive funding (grants, research programs) and strategic partnerships are key to surviving this phase.
Early “design” is heavily mechanical, electrical, and systems design; classic UX and brand often arrive closer to commercialization.
When they do, they’re often constrained by hardware that is already frozen from a technical validation standpoint.
Design‑driven companies focus intentionally on solving users’ problems and crafting experiences, rather than maximizing technical cleverness per se.
Designers and product managers frequently lead strategy, with engineering asked to realize a holistic vision rather than define it.
Teams can ship quickly, test concepts, and pivot based on qualitative feedback because they’re not bound by multi‑year R&D cycles.
Brand, community, and content play outsized roles in building defensibility in a commoditized technical landscape.
Reliability, manufacturability, and scalability are where engineering excellence shows up, ensuring that the beautiful experience is robust at scale.
Most technical work is in integration, optimization, and cost engineering, not in inventing new physics.
---
Many products travel from one world to the other over their lifetime.
Early on, they are deep‑tech bets; later, they are experience‑and‑brand plays.
Using the S‑curve lens, early phases focus on learning basic physics, manufacturing, and use cases; the middle phase sees dominant designs emerge and supply chains mature; the late phase is about squeezing out incremental improvements as returns diminish.
Once your core performance is good enough and similar to competitors, you are effectively in the intent, feel, and taste game whether you like it or not.
For founders and product leaders, this shift demands organizational ambidexterity: you need R&D and product roadmaps for early‑curve tech, and design‑driven, brand‑savvy capabilities for late‑curve offerings.
If you keep running an engineering‑constraint playbook in a commoditized market, you over‑invest in tech that users don’t feel; if you run a taste‑first playbook too early, you paint beautiful skins over tech that simply isn’t viable yet.
---
To make this actionable, ask yourself:
1. Is our main risk technical or experiential?
If you fail, is it more likely because the physics didn’t work or because people didn’t care?
2. Where is our market’s S‑curve?
Are we still inventing the category, or are we one of many similar options fighting over preference?
3. What are our real differentiators today?
If a competent competitor copied our engineering stack tomorrow, what would still be unique: performance curves or the way people experience and talk about us?
4. Where is our next moat going to come from?
In early phases, the moat is in IP, data, and technical know‑how; in later phases, it shifts to brand equity, ecosystem, and habitual usage.
Your answers should drive how you weight engineering constraints versus intent, feel, and taste in your roadmap, hiring, and culture.
---
The healthiest product organizations recognize that these two archetypes are ends of a spectrum, not mutually exclusive camps.
Even deep‑tech ventures benefit from early thinking about user journeys and future UX, so they don’t paint themselves into intractable usability or integration corners.
And even taste‑driven brands win when they have a quiet backbone of solid engineering that makes their promises real and their experiences reliable.
The art is understanding which game you are primarily playing _right now_, and designing your process accordingly:
Know your game, then build the org, roadmap, and design language that actually fits it.