The utility of hard constraints in product design
May 17th, 2022
We self-impose a lot of hard constraints on product design at HASH.
Some of these are commonplace and practiced throughout good tech firms. For example, in frontend web we develop style guides and storybooks which we stick to, and on the backend we maintain a high standard for in-code comments and internal documentation.
However, one such constraint that we impose upon ourselves is by far the most important. This is the “non-negotiable principle”.
The non-negotiable principle dictates that everything we allow users to do within our products must be portable and accessible. This means that every page edited or property updated needs to be captured and accessible. This can mean "self-hostable" (as in, if we have a tool, you'll be able to run a version of it locally). It can also mean exportable, at least in a raw form such as JSON. In addition, every action taken by a user should be logged. Support for this kind of provenance is being built directly into our open source (and therefore equally portable) HASH application.
Our non-negotiable principle exists for four reasons:
Being absolutist about our non-negotiable principle has wide-ranging implications for our business model, as well as our product.
Conventional strategy dictates that companies (and their managers) should 'preserve optionality'. By self-imposing hard constraints and writing about them publicly, we bind ourselves to them. Whole business models are — for us — ruled out. For example, there can be no “embrace, extend, and extinguish”. Instead, we work in the open and make our outputs available publicly by default. You can read more about this process in our open source at HASH blog post.
Get notified when new long-reads and articles go live. Follow along as we dive deep into new tech, and share our experiences. No sales stuff.