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.
csallen 5 hours ago [-]
> 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.
azhenley 2 hours ago [-]
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.
boris 22 minutes ago [-]
> 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).
argee 5 hours ago [-]
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.
ffsm8 1 hours ago [-]
Doesn't Jira only has 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
whh 3 hours ago [-]
Vaguely feels like "Atomic Design" but applied to engineering.
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.
cuu508 2 hours ago [-]
core tenets
perrygeo 4 hours ago [-]
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.
Synthetic7346 3 hours ago [-]
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
raincole 1 hours ago [-]
> 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?
frotis 38 minutes ago [-]
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.
CharlieDigital 5 hours ago [-]
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.
wanderingbit 6 hours ago [-]
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…
ChrisMarshallNY 6 hours ago [-]
I like these. I have never thought about it that way, but I guess that I generally have the same constraints.
disciplined 4 hours ago [-]
What are hacker news constraints?
mkl 1 hours ago [-]
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-...
Grosvenor 3 hours ago [-]
HTML 4.0
esafak 5 hours ago [-]
> 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.
1659447091 20 minutes ago [-]
> 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'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.
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).
Seems like there's quite a bit more to it: https://outliner.tana.inc/learn
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.
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.
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?
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.
I’m gonna go do these…
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.
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...
In the past, I worked in teams, building much more ambitious projects, and these rules would likely not apply.