Your Workflow Is The Spec

We have argued elsewhere that a tool for a specific job should be narrow — that it is better to do the ten things an engineer does daily in three clicks than to offer three hundred operations and let them assemble the workflow themselves. We believe that. It also carries an obligation we should state out loud, because it is the part that can go wrong.

The Risk Of Building Narrow

A general tool is very hard to be wrong with. It hands over primitives and the responsibility for combining them, so if the result is awkward, the awkwardness belongs to whoever did the combining.

A narrow tool has no such shelter. Deciding that a run is the unit of analysis, that steps are how a run should be divided, that the default comparison is against a known-good reference — those are claims about how the work is done. If we read the work wrong, we do not produce a slightly clumsy tool. We produce one that is confidently pointed at the wrong thing, and the engineer using it has no escape hatch, because we removed the primitives that would have let them route around us.

The only real defence against this is to keep checking the claims against people who do the job. Not once, during a requirements phase that ended two years ago — continuously, including after we have shipped something and grown attached to it.

If You Have A Better Way, We Want The Argument

So this is an open invitation, and it is meant literally rather than as the customary closing line of a product page.

If you have a workflow that works better than the one the app pushes you toward, tell us and we will build it. If there is a step you do every single time that the software makes you do by hand, tell us and we will make the software do it. If something in the app is aimed at a version of your job that does not exist, we would much rather hear that from you than keep maintaining it.

We are aware of how this reads. Every software company says it listens to users. The distinguishing question is not whether a company says it, it is whether anything visibly changes afterward — so treat that as the test, and hold us to it rather than to the promise.

What Is Actually Useful To Send

The most useful message is not a feature request. It is a description of the work.

Walk us through the sequence: what arrives, what you do to it, in what order, and what you are trying to find out. Tell us where it gets tedious, and tell us the part you dread. Tell us what you check by eye because there is no way to state it precisely, and what you keep in a side file because the tool has nowhere to put it. If there is a step you have quietly automated with a script of your own, that script is one of the most informative things you could describe to us — someone building a workaround is telling you exactly where the product ends.

A feature request is a proposed solution, and proposed solutions are shaped by what the person already believes is possible. A description of the work is the problem itself, and it frequently has a better answer than the one either of us would have thought to ask for.

What We Will And Won't Build

In fairness, the invitation has a boundary, and it would be dishonest to leave it out.

We will not build everything. Saying yes to every request is precisely how a focused tool turns into the sprawling platform we argued against — each addition individually reasonable, the sum unusable. So some things will get a no, and when they do we would like to give you the actual reason rather than letting the request quietly expire in a backlog.

What we will do is take the description seriously, tell you honestly whether it fits what we are building, and — when it does — treat it as the specification rather than as input to one. The workflows engineers describe to us are not suggestions we weigh against a roadmap we wrote in advance. Fairly often, they are the roadmap.

How To Reach Us

Use the contact form on this site and say it is about a workflow rather than a purchase; it reaches the people building the thing. Rough notes are fine. Screenshots of the ugly spreadsheet are better. There is no wrong format, and you do not need to have a solution in mind — the description of how the work actually goes is the valuable part, and it is the thing we cannot get any other way.