> One defining constraint must shape the product... Minecraft is built entirely from blocks. IKEA is flat-pack, self-assembly furniture.
I've been calling these things product primitives. I can't remember where I heard that term, but it refers to things like...
Blocks in Notion. Messages and conversations in Telegram. Frames and layers in Figma. Tweets in Twitter. Cells and sheets in Excel. Tools and layers in Photoshop. Commands in a CLI.
I think what makes for good product design is having a very small number of primitives. A bad product doesn't know what its primitives are. Or it has a very large number of primitives. It feels like everything in the product is some unique thing that works in its own unique way. So users have to learn a ton of different top-level primitives/concepts. It's confusing and intimidating and hard to teach. Ideally you just want one or two or three main primitives.
The complexity/power in an app comes from choosing powerful primitives that have depth, that are composable, etc. You can do a lot with Notion blocks. You can do a lot with Excel cells. You can do a lot with a CLI command. You can do a lot with a Minecraft block. There's depth there.
We used to call this “concept count”. You usually want to minimize the number of core concepts that make up your product. I’ve also heard it as the “nouns and verbs” of a product.
Insightful, to think of a product and its interface as a "language" that the user learns. Some products give you a small and powerful vocabulary, where just a few words can accomplish a lot. Other products are like a badly designed language that lacks coherence and ease of use, where tasks that should be simple require many words, or some words don't fit together well with others.
I think this philosophy might be oversimplified. Tana has basically two primitives (bullets and supertags) and manages to be devastatingly complex to use to the point you have to watch hours of tutorials to do very simple things. Conversely Google Maps has a lot of “primitives” but the UX is fairly tight for 90% of use cases.
It applies more to design software, where a user is creating durable things and needs to understand those things themselves. Google Maps is more of an agent: It's responsible for understanding its own complexity and answering your queries.
My point is that, sometimes, going for the lowest common denominator or "noun" and declaring it to be your primitive (focusing on minimalism), is a worse approach than picking a larger set of primitives that suits your design. Take Hangul (한글) for example, where the primitives are designed to serve a goal, and there's no effort to "ruthlessly" minimize the number of primitives, and this is something you can learn to read in 10 minutes, or at least in a day. Whereas if you go over to something like Chinese, your numbers 1, 2, and 3 look nice thanks to your stroke primitive, but your needs quickly overwhelm your design and you end up with something quite unwieldy compared to if you had picked a more complex set of primitives — you will never learn to read all Chinese in your whole life even as a native speaker. It's a counter-intuitive design lesson.
Doesn't Jira only have one primitive: the ticket.
Everything else just augments it.
You could say that these augmentations are separate primitives, but then the same would apply to all tools in the other cited examples like Photoshop too
Yeah... this sounds a bit like the Alexandrian Pattern Language concepts which directly inspired the Gang of Four's Design Patterns.
I wonder, though, if what you're describing as "product primitives" actually maps more closely to what Alexander later called "Centers," rather than the patterns themselves.
From what I understand, while the software world heavily adopted his patterns, Alexander spent his later career arguing that the ultimate building block of a system is actually a Center: localized focal points of utility and coherence, eg a well-lit courtyard, window seat, or fireplace. A strong center is naturally composable; it "resolves local tension," is made of smaller centers, and acts as a building block to generate larger ones.
When a product feels confusing or bloated, it's rarely out of bad design intent. It's just that user needs—while not necessarily glaringly—are empirically discoverable, while the true, underlying "centers" that could elegantly solve them are incredibly subtle and hard to identify. The path of least resistance is almost always to just build a unique, rigid interface for the immediate user need right in front of you. Doing the deep architectural work to discover a core primitive that naturally absorbs those needs is difficult.
So maybe that's why we build so many faster horses.
I used a similar metric when judging programming languages. The language can get huge but if it's conceptually small, one can learn it and then leave the rest to compounding due to experience. Conceptually large languages had a barrier for me. The case when I felt this was perl.
> Commands in a CLI … I think what makes for good product design is having a very small number of primitives.
Small but not too small. Case in point: shell scripts (POSIX shell, bash) where the scripting part was decided to be modelled as commands thus not introducing another bunch of concepts. We all know what the result is (hot, slow mess).
I know it's in vogue to bash Bash but I feel that criticism is unfair.
Shell scripting is a victim of its own success: it is _so easy_ to get started that most users get value out of knowing the first one percent and never bother to actually learn the rest.
There aren't many who have read the Bash manual, or know what zsh can do that Bash cannot, etc.
"Shell scripting is a hot, slow mess" is the same hot slow mess that you get wherever the barrier to entry is extremely low (e.g. early PHP, early JavaScript/frontend development, game development with a game engine where you can just click around in the editor, etc).
There’s also the fact that shell scripting is for automation of what you may do interactively. It’s not for stuff where you want data structures to manipulate in memory. Trying to use it like python is an exercise in frustration.
I remember a friend saying they had a university assignment to implement something like a spreadsheet program in bash - I suppose it was to teach them the intricacies of bash but the big takeaway was meant to be - don't use bash for anything too complicated.
The author really extracted the core tenants of exactly how my former research mentor and I ended up building our business.
We started with the second two points: our core technology was a sampler that enables arbitrary hierarchical Bayesian graph models for sparse data, our constraint was cpu bound tractable compute. The piece that took us the longest to discover was the fact that our end products need to be separate from our underlying technology.
We were given that advice in various words from many people even before we started but some lessons need to be lived to be learned.
One unique core concept per tenant, because the SaaS is nominally multi-tenant but it's really N unrelated websites for N enterprise customers in a trenchcoat
It would have been great if the author could have provided a complete example of the constraints in action, I'm kinda lost on how the third one would look in practice
seems like a made up hook, you come up with something. i like the "everythings a file" idea in linux. you can go a long way with a strong concept like that.
I love the one page idea. If you can't spend the time to articulate a page worth of constraints, you're going to flail around discovering them as you go. And these aren't "bugs", they're "oh shit we're building the wrong thing" flaws.
I have no hard data to back it up, but in my experience, projects that take the time to put everyone on the same page conceptually (even if it's a 1 pager, high level, here's what we are and are not doing) end up succeeding far more often than projects that wing it. The wing it projects always end up disappointing everyone who had opinions but never bothered to articulate them.
We are trying to design our kitchen for a renovation and I can see how these 3 constraints would be useful for us to do for something more about design than software.
people space, storage space, operations space... everythings a space? too basic? what about space and flow, flow of people, flow of light, flow of food, transitions etc... heh, this is fun
I like all three constraints, but while I agree with tenet "1a: write something down" I wonder if "1b: in one document that is exactly one page long" should
depend on the complexity of the project. For a small-to-medium project, one
page will be enough. For a mars flight control software system, the one pager
might have to hyperlink to a whole range of sub-specifications before starting
to build.
Tenet 2, separate tech from product is very wise. Someone in the comments people asked for example, so I'll give you one: remember Skype? It has a back-end peer-to-peer communication technology and a front-end application to make calls via HTTP and voice networks. Its smart creators incorporated the two parts in two companies, and when the front-end (Skype the application) was sold to Microsoft, they still owned the core IP company, which held the P2P communication backend technology!
Tenet 3: I can buy into that, too. I would sometimes posit more than one constraint, or a ranked list of major and minor ones. From a business point of
view, if the top tenet is hard to commercialize, if you treat it like a immutable doctrine you will by definition drive your venture into bankruptcy,
which would be a shame if one of your team has an idea for a rather dramatic
pivot that would make it easier to sell (albeit something racically different).
Example: Twitter originally was going to do something else, the "public status update" thing was apparently rather a side project ("In March, Jack Dorsey, Noah Glass, Biz Stone, and Evan Williams created Twitter, which was originally a side project stemming from the podcasting tool Odeo.").
The constraint I'd add for solo SaaS is "can I find one beta user this week." Time, scope, tech all stayed reasonable on my one pager but a project can pass those filters and still die because no one walks in the door. Adding a distribution constraint upfront forced me to validate the audience before I went deep on features.
I think one of the biggest constraints is not directly visible to users, but its effects are: HN is built in Arc, a small LISP dialect that for a long time didn't have great performance. Some info here: https://lisp-journey.gitlab.io/blog/hacker-news-now-runs-on-...
stay thoughtful and focused on the tech industry or other nerdy subjects and dont get emotional and make one line snarky comments that immediately attract an avalanche of downvotes and risk getting your account shadow banned.
> The core tech must be separable from the product
Won't this lead to premature abstraction and application of design patterns everywhere? I mean, sure, of course you should do separation of concerns, keep your business domain layer clean of persistence/network/UI/… concerns etc. But your domain layer will still be very much tied to your product. There is no way around that.
Maybe he is saying that there’s always a veneer which is how you attract buyers, but the internal that may make things work is not the latter’s concern.
So while you may have a few concepts that serve as interfaces between the two layers, but how the latter evolve should be disconnected..
how about time? most founders do this as a moonlighting gig and it dawns on you that the experiment you start has to run for a year with only you in the critical path to get validated which usually kills a lot of feature ideas before they even start. I guess this is probably how ideas get weeded out so you don't actively have to.
A clear hierarchy may be secured through these constraints. That's the unifier - it'd be hard to achieve these three without it.
A one-pager begs of you to find the foundational value simply - no fooling yourself with a multitude of prospects and complexity.
The separable aspect makes explicit the need to build the foundation to stand on its own. You can't lean on the branches prematurely as if features are solid ground.
The single-defining constraint forces one to conceive and recognize the single-most fundamental functionality - and its shape, and its abilities; its character.
Well, yes, but no. It didn't matter to the user what it was built around. What mattered was that it was much faster and much more relevant search than what was available at the time.
> The biggest product of the century thus, LLMs, are the core tech.
I would not say LLMs are products. It's still early adopters stage and it's going to be skewed on HN -- a large portion of people here evangelize the virtues of digging through an electronics store's parts bin to finish off a pcb they made in their garage then run an obscure version of linux on it for work. It's a lot of tech kludged together, not a product, not in the context of this article anyway. Same for the current state of LLMs. It's a tech waiting for a product to make it useful for the general population. For developers, Github's copilot is probably the closest, it bundles LLM tech to leverage their tech (github) creating a product you don't have to piecemeal together if you don't want too.
The internet was a tech that was first played with like we play with LLMs now. It was the web browser -- a product that leveraged a core tech -- that made it widely usable. Large parts of the population have no idea the internet is not their web browser (or now apps that access that web through a different interface).
I read a quote from the new Apple CEO on AI, that I think highlights the tech vs product separation and why Apple is where it is: 'We never think about shipping technology. We always think about 'how can we leverage technology to ship amazing products'
I don't get that quote. Does that apply to teams working on SDKs, GPU design, internal tools, etc? Are those all reframed as "products"? Seems like there would be a lot of groups at Apple concerned entirely with shipping technology? "Leverage" makes it sound like they just use other people's tech but we know that's not true. Why throw shipping technology under the bus? I don't get it.
I would guess they label things differently or use different language to talk with their internal product teams/employees. But the end goal being to ship an end-user Apple Product orchestrating tech/products in ways that the individual tech/product could not do on its own.
> One defining constraint must shape the product... Minecraft is built entirely from blocks. IKEA is flat-pack, self-assembly furniture.
I've been calling these things product primitives. I can't remember where I heard that term, but it refers to things like...
Blocks in Notion. Messages and conversations in Telegram. Frames and layers in Figma. Tweets in Twitter. Cells and sheets in Excel. Tools and layers in Photoshop. Commands in a CLI.
I think what makes for good product design is having a very small number of primitives. A bad product doesn't know what its primitives are. Or it has a very large number of primitives. It feels like everything in the product is some unique thing that works in its own unique way. So users have to learn a ton of different top-level primitives/concepts. It's confusing and intimidating and hard to teach. Ideally you just want one or two or three main primitives.
The complexity/power in an app comes from choosing powerful primitives that have depth, that are composable, etc. You can do a lot with Notion blocks. You can do a lot with Excel cells. You can do a lot with a CLI command. You can do a lot with a Minecraft block. There's depth there.
We used to call this “concept count”. You usually want to minimize the number of core concepts that make up your product. I’ve also heard it as the “nouns and verbs” of a product.
> the “nouns and verbs” of a product
Insightful, to think of a product and its interface as a "language" that the user learns. Some products give you a small and powerful vocabulary, where just a few words can accomplish a lot. Other products are like a badly designed language that lacks coherence and ease of use, where tasks that should be simple require many words, or some words don't fit together well with others.
I think this philosophy might be oversimplified. Tana has basically two primitives (bullets and supertags) and manages to be devastatingly complex to use to the point you have to watch hours of tutorials to do very simple things. Conversely Google Maps has a lot of “primitives” but the UX is fairly tight for 90% of use cases.
It applies more to design software, where a user is creating durable things and needs to understand those things themselves. Google Maps is more of an agent: It's responsible for understanding its own complexity and answering your queries.
My point is that, sometimes, going for the lowest common denominator or "noun" and declaring it to be your primitive (focusing on minimalism), is a worse approach than picking a larger set of primitives that suits your design. Take Hangul (한글) for example, where the primitives are designed to serve a goal, and there's no effort to "ruthlessly" minimize the number of primitives, and this is something you can learn to read in 10 minutes, or at least in a day. Whereas if you go over to something like Chinese, your numbers 1, 2, and 3 look nice thanks to your stroke primitive, but your needs quickly overwhelm your design and you end up with something quite unwieldy compared to if you had picked a more complex set of primitives — you will never learn to read all Chinese in your whole life even as a native speaker. It's a counter-intuitive design lesson.
Doesn't Jira only have one primitive: the ticket. Everything else just augments it. You could say that these augmentations are separate primitives, but then the same would apply to all tools in the other cited examples like Photoshop too
Tana is basically a programming environment disguised as a text editor (in this way, it follows in the grand tradition of emacs you could say)
Vaguely feels like "Atomic Design" but applied to engineering.
what is Tana?
This I think: https://tana.inc/
Seems like there's quite a bit more to it: https://outliner.tana.inc/learn
Yeah... this sounds a bit like the Alexandrian Pattern Language concepts which directly inspired the Gang of Four's Design Patterns.
I wonder, though, if what you're describing as "product primitives" actually maps more closely to what Alexander later called "Centers," rather than the patterns themselves.
From what I understand, while the software world heavily adopted his patterns, Alexander spent his later career arguing that the ultimate building block of a system is actually a Center: localized focal points of utility and coherence, eg a well-lit courtyard, window seat, or fireplace. A strong center is naturally composable; it "resolves local tension," is made of smaller centers, and acts as a building block to generate larger ones.
When a product feels confusing or bloated, it's rarely out of bad design intent. It's just that user needs—while not necessarily glaringly—are empirically discoverable, while the true, underlying "centers" that could elegantly solve them are incredibly subtle and hard to identify. The path of least resistance is almost always to just build a unique, rigid interface for the immediate user need right in front of you. Doing the deep architectural work to discover a core primitive that naturally absorbs those needs is difficult.
So maybe that's why we build so many faster horses.
I used a similar metric when judging programming languages. The language can get huge but if it's conceptually small, one can learn it and then leave the rest to compounding due to experience. Conceptually large languages had a barrier for me. The case when I felt this was perl.
> Commands in a CLI … I think what makes for good product design is having a very small number of primitives.
Small but not too small. Case in point: shell scripts (POSIX shell, bash) where the scripting part was decided to be modelled as commands thus not introducing another bunch of concepts. We all know what the result is (hot, slow mess).
I know it's in vogue to bash Bash but I feel that criticism is unfair.
Shell scripting is a victim of its own success: it is _so easy_ to get started that most users get value out of knowing the first one percent and never bother to actually learn the rest.
There aren't many who have read the Bash manual, or know what zsh can do that Bash cannot, etc.
"Shell scripting is a hot, slow mess" is the same hot slow mess that you get wherever the barrier to entry is extremely low (e.g. early PHP, early JavaScript/frontend development, game development with a game engine where you can just click around in the editor, etc).
There’s also the fact that shell scripting is for automation of what you may do interactively. It’s not for stuff where you want data structures to manipulate in memory. Trying to use it like python is an exercise in frustration.
I remember a friend saying they had a university assignment to implement something like a spreadsheet program in bash - I suppose it was to teach them the intricacies of bash but the big takeaway was meant to be - don't use bash for anything too complicated.
When I think about products with too many primitives, I instantly think of Snapchat and Instagram - my two least favorite apps.
The author really extracted the core tenants of exactly how my former research mentor and I ended up building our business.
We started with the second two points: our core technology was a sampler that enables arbitrary hierarchical Bayesian graph models for sparse data, our constraint was cpu bound tractable compute. The piece that took us the longest to discover was the fact that our end products need to be separate from our underlying technology.
We were given that advice in various words from many people even before we started but some lessons need to be lived to be learned.
core tenets
I actually love typos these days because it usually lets me know Im talking to a fellow human :)
For some SaaS products it's both. :p
One unique core concept per tenant, because the SaaS is nominally multi-tenant but it's really N unrelated websites for N enterprise customers in a trenchcoat
"We have a proven business model: Do random shit to make a sale."
Constraints are underrated.
The most elegant solutions typically arise not out of unbounded degrees of freedom, but building specifically with a constraint in mind.
I think that this goes with point 1: composing the one pager helps define those constraints.
It would have been great if the author could have provided a complete example of the constraints in action, I'm kinda lost on how the third one would look in practice
seems like a made up hook, you come up with something. i like the "everythings a file" idea in linux. you can go a long way with a strong concept like that.
your example also reminded me about the "file over app" concept in Obsidian. this constrain actually limits and shapes the product decisions
I love the one page idea. If you can't spend the time to articulate a page worth of constraints, you're going to flail around discovering them as you go. And these aren't "bugs", they're "oh shit we're building the wrong thing" flaws.
I have no hard data to back it up, but in my experience, projects that take the time to put everyone on the same page conceptually (even if it's a 1 pager, high level, here's what we are and are not doing) end up succeeding far more often than projects that wing it. The wing it projects always end up disappointing everyone who had opinions but never bothered to articulate them.
> Google has Kubernetes
This is more to disable its competitors than anything.
We are trying to design our kitchen for a renovation and I can see how these 3 constraints would be useful for us to do for something more about design than software.
I’m gonna go do these…
people space, storage space, operations space... everythings a space? too basic? what about space and flow, flow of people, flow of light, flow of food, transitions etc... heh, this is fun
Cost is the primary constraint for most people and the tighter money is the more creative your solutions need to be.
I like all three constraints, but while I agree with tenet "1a: write something down" I wonder if "1b: in one document that is exactly one page long" should depend on the complexity of the project. For a small-to-medium project, one page will be enough. For a mars flight control software system, the one pager might have to hyperlink to a whole range of sub-specifications before starting to build.
Tenet 2, separate tech from product is very wise. Someone in the comments people asked for example, so I'll give you one: remember Skype? It has a back-end peer-to-peer communication technology and a front-end application to make calls via HTTP and voice networks. Its smart creators incorporated the two parts in two companies, and when the front-end (Skype the application) was sold to Microsoft, they still owned the core IP company, which held the P2P communication backend technology!
Tenet 3: I can buy into that, too. I would sometimes posit more than one constraint, or a ranked list of major and minor ones. From a business point of view, if the top tenet is hard to commercialize, if you treat it like a immutable doctrine you will by definition drive your venture into bankruptcy, which would be a shame if one of your team has an idea for a rather dramatic pivot that would make it easier to sell (albeit something racically different). Example: Twitter originally was going to do something else, the "public status update" thing was apparently rather a side project ("In March, Jack Dorsey, Noah Glass, Biz Stone, and Evan Williams created Twitter, which was originally a side project stemming from the podcasting tool Odeo.").
The constraint I'd add for solo SaaS is "can I find one beta user this week." Time, scope, tech all stayed reasonable on my one pager but a project can pass those filters and still die because no one walks in the door. Adding a distribution constraint upfront forced me to validate the audience before I went deep on features.
That’s not really a constraint. It’s more of a target or goal.
What are hacker news constraints?
I think one of the biggest constraints is not directly visible to users, but its effects are: HN is built in Arc, a small LISP dialect that for a long time didn't have great performance. Some info here: https://lisp-journey.gitlab.io/blog/hacker-news-now-runs-on-...
HTML 4.0
- Just submitted links and threaded comments
- An advanced ranking algorithm
- Moderated contribution and discussion
stay thoughtful and focused on the tech industry or other nerdy subjects and dont get emotional and make one line snarky comments that immediately attract an avalanche of downvotes and risk getting your account shadow banned.
Thank you for this piece! I never thought consciously about creativity unlocked by constraints.
> The core tech must be separable from the product
Won't this lead to premature abstraction and application of design patterns everywhere? I mean, sure, of course you should do separation of concerns, keep your business domain layer clean of persistence/network/UI/… concerns etc. But your domain layer will still be very much tied to your product. There is no way around that.
Maybe he is saying that there’s always a veneer which is how you attract buyers, but the internal that may make things work is not the latter’s concern.
So while you may have a few concepts that serve as interfaces between the two layers, but how the latter evolve should be disconnected..
how about time? most founders do this as a moonlighting gig and it dawns on you that the experiment you start has to run for a year with only you in the critical path to get validated which usually kills a lot of feature ideas before they even start. I guess this is probably how ideas get weeded out so you don't actively have to.
A clear hierarchy may be secured through these constraints. That's the unifier - it'd be hard to achieve these three without it.
A one-pager begs of you to find the foundational value simply - no fooling yourself with a multitude of prospects and complexity.
The separable aspect makes explicit the need to build the foundation to stand on its own. You can't lean on the branches prematurely as if features are solid ground.
The single-defining constraint forces one to conceive and recognize the single-most fundamental functionality - and its shape, and its abilities; its character.
I guess every successful product that doesn’t fit these constraints will be built by someone else.
I doubt that is an empty set.
How big is this page and what's the font size?
> The core tech must be separable from the product
I don't know... none of the examples makes sense for me. Especially:
> Google has Kubernetes
I mean, yeah, and? Google was originally a product built around PageRank, the core tech, wasn't it?
Well, yes, but no. It didn't matter to the user what it was built around. What mattered was that it was much faster and much more relevant search than what was available at the time.
>One defining constraint must shape the product
>This constraint limits feature creep and forces identity.
With AI Agents this is a bit outdated. Now I tell people to be maximilist.
I like these. I have never thought about it that way, but I guess that I generally have the same constraints.
[dead]
[dead]
[flagged]
[dead]
> The core tech must be separable from the product
The biggest product of the century thus, LLMs, are the core tech.
I don't doubt these rules have helped the author, but readers should be mindful when heeding them.
> The biggest product of the century thus, LLMs, are the core tech.
I would not say LLMs are products. It's still early adopters stage and it's going to be skewed on HN -- a large portion of people here evangelize the virtues of digging through an electronics store's parts bin to finish off a pcb they made in their garage then run an obscure version of linux on it for work. It's a lot of tech kludged together, not a product, not in the context of this article anyway. Same for the current state of LLMs. It's a tech waiting for a product to make it useful for the general population. For developers, Github's copilot is probably the closest, it bundles LLM tech to leverage their tech (github) creating a product you don't have to piecemeal together if you don't want too.
The internet was a tech that was first played with like we play with LLMs now. It was the web browser -- a product that leveraged a core tech -- that made it widely usable. Large parts of the population have no idea the internet is not their web browser (or now apps that access that web through a different interface).
I read a quote from the new Apple CEO on AI, that I think highlights the tech vs product separation and why Apple is where it is: 'We never think about shipping technology. We always think about 'how can we leverage technology to ship amazing products'
https://www.tomsguide.com/computing/macbooks/i-interviewed-j...
I don't get that quote. Does that apply to teams working on SDKs, GPU design, internal tools, etc? Are those all reframed as "products"? Seems like there would be a lot of groups at Apple concerned entirely with shipping technology? "Leverage" makes it sound like they just use other people's tech but we know that's not true. Why throw shipping technology under the bus? I don't get it.
I would guess they label things differently or use different language to talk with their internal product teams/employees. But the end goal being to ship an end-user Apple Product orchestrating tech/products in ways that the individual tech/product could not do on its own.
The product is automation; the tech is llms
Agreed, but he is talking about limited-scope projects, that he probably does himself. That’s how I work, myself (these days).
In the past, I worked in teams, building much more ambitious projects, and these rules would likely not apply.
[dead]