The non-negotiable principle

Self-imposed constraints

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 at HASH 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, accessible, and exportable in its raw form, and every action taken needs to be logged. Support for this kind of provenance is being built directly into our open source (and therefore equally portable) forthcoming HASH workspace application.

Our non-negotiable principle exists for four reasons:

1. It results in a better product. Better products sell themselves. Portable outputs are more integrable, and therefore more useful. Hard constraints force more deliberate design upfront.

2. It improves customer confidence. In marketplaces 'costly signals' — especially those in the form of absolute public commitments, such as our "non-negotiable principle" — set long-term expectations. These in turn allow users to adopt with confidence.

3. It lowers barriers to entry by lowering barriers to exit. Trying out new tools is easier to justify when you know you can always move away with ease, or fork a solution outright, should things not live up to expectations. Potential sunk costs are minimized, decreasing the downside risk of adoption.

4. It forces internal focus on the things that matter. This kind of public commitment forces us to compete on features and quality, which themselves attract ambitious people to the company, creating a virtuous cycle.

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.