Every product company has principles on a wall somewhere. Most of them don't survive contact with a difficult engineering tradeoff. Ours might not either — but we've been running these four for long enough that we trust them enough to put them on the wall and actually follow them.
Here they are, with what they actually mean when a team is under pressure and the easier path is right there.
One. Simplicity.
If it takes a training course to use, we designed it wrong.
This is the one that sounds most obvious and gets violated most often. Simplicity isn't about having fewer features — it's about the feature doing what the user thought it would do, without asking them to learn a new mental model.
The practical test we use: can a competent operator who has never seen the software before complete their core task within fifteen minutes, without opening documentation? If the answer is no, the design is wrong, and that's not a training problem. That's a design problem.
We've killed features for failing this test. Not because the feature wasn't valuable, but because the cost of teaching it exceeded the value of having it. A product that requires ten hours of onboarding before it pays off has a much smaller addressable market than a product that's useful in the first hour.
Two. Structure.
Good software makes the right action the easy action.
This is borrowed from a much older idea about user interfaces, but we apply it specifically to operational software. If you're designing dispatch software, the most common action — scheduling a technician — should be the easiest click in the interface. If you're designing quoting software, creating a standard quote should take fewer steps than creating an exception.
The dark version of this is worth naming: software that makes the wrong action the easy action actively harms operations. We've seen field service tools where marking a job complete requires seven taps on a phone, and adding a new job takes two. Guess which action gets done carefully and which one accumulates errors.
Structure isn't about constraining users. It's about reducing the cost of doing the right thing so much that the wrong thing becomes visible.
When structure works, you don't have to train people to follow your preferred workflow. They just do, because it's the path of least resistance.
Three. Automation.
Remove repetitive work so people can focus on judgment calls.
There's a version of automation that's about replacing humans. We're not interested in that version. The version we care about is the one that frees human attention for the parts of the job that actually benefit from it.
In a print operation, automating the creation of a work order from an approved quote is good automation. The work order has to exist, the data is already known, and no human judgment improves the output. A person doing that data transcription by hand is a person being paid to type. Remove it.
But automating the final sign-off on a complex job — where the operator might notice that the paper stock is backordered, or that the customer's last three jobs had color correction issues — is bad automation. That step needs a human to think. If you automate it, you're not freeing time; you're introducing errors that will cost more than the time you saved.
The test: does this step benefit from thinking? If yes, keep the human. If no, automate ruthlessly.
Four. Scalability.
Every product should work for ten users or ten thousand.
This one is the least poetic and the most expensive to get wrong. Scalability isn't about whether your infrastructure can handle load — that's a solved problem. Scalability is about whether the design of the product still makes sense at 100x the scope it was built for.
A quoting tool that works beautifully for a team with three approvers falls apart at a company with a seven-step approval matrix across five departments. Not because the software is slow, but because the mental model of "approval" the product was built around doesn't match what "approval" means at the larger company. The product works. The model doesn't.
So we design for the range. PrintPLANR has to make sense for a five-person print broker and a three-hundred-person commercial press. FieldPLANR has to work for a ten-technician HVAC company and a national service provider with four hundred vans. That doesn't mean we build every feature at day one — we don't. It means when we make a design decision, we ask: does this decision still hold at 100x? If the answer is no, we're building technical debt we'll pay for later.
What these four get you
Together, these principles describe a particular kind of software: opinionated about the work it's designed for, light on configuration, fast to adopt, and built to grow with the customer rather than be replaced at the next inflection point.
They also describe what these principles are not: they're not about being minimalist for its own sake, not about the latest design trend, and not about reducing feature count as a marketing message. They're about making the product genuinely useful for operators — which, as it happens, is the only durable way to build a company in this category.
We're not claiming these principles are unique to us. They're probably not. What we're claiming is that we actually use them. That you can read them here, then look at PrintPLANR, FieldPLANR, QuotePLANR, or ANSWR, and see them in the product. If you can't, the principles aren't real — they're just wall decoration, and we should either fix the product or stop printing the poster.
Principles are either binding or they're not. These are binding.