Our method
We work BIND.
Four moves, in this order, on every product we have shipped. The name is the house's own job: a bindery is the thing that collates loose sheets into one volume, which is what this method does to a product.
- B
Buyer first
We start at the buyer
- I
Isolate one job
We build the narrow thing
- N
No proxy
We run it ourselves first
- D
Defer to the desk
We hand it to people doing the job
A bindery collates loose sheets into one volume · out of order it stops being a method and becomes a to-do list
B
Buyer first
Which companies, who inside them signs, and what that person is doing on the day the tool is supposed to help. Everything after this is an argument with that description.
Skipped, it produces a persona deck nobody opens again. You can tell it happened because every later argument about the product is settled by whoever talks longest, rather than by what the buyer does at eleven on a Tuesday.
Five questions, answered in writing before anything is built
- 01Which companies, stated as a filter with disqualifiers, not as a wish
- 02Who signs, who blocks, and who only has to not object
- 03What that person is doing in the hour the tool is supposed to help
- 04What they use today, and what it would take to make them stop
- 05What has to be true for this to be worth their attention at all
I
Isolate one job
One job, done properly. A tool that tries to cover a whole department ends up covering nobody, so we ship the part that changes your week.
What gets built
What gets written down as not now
The one job, shipped whole
The next three, written down and dated as not now
A first version in a real inbox, pipeline or offer
A staging environment nobody sells from
A decision, made and defended
A configuration wizard standing in for a decision
The part that changes your week
The part that makes the feature grid look complete
Skipped, it becomes the platform trap: six half-features, each good enough to demo and none good enough to keep
N
No proxy
Our pipeline, our offers and our inbox go through these products before anyone else is asked to trust them. It is the fastest way to find out what a feature is worth. Nothing here is tested by proxy, which is why the three products are also the three places our own company runs.
Our pipeline
Every deal we work sits in it, including the ones that go nowhere. Scoring gets judged against our own week, not a demo dataset.
Our offers
Every offer we send goes out through it, so we find out what a read-through report is worth on a deal we care about losing.
Our mail
Our mail lands in it first. A bad classification costs us the morning before it costs you one.
Skipped, you end up selling a workflow you have never had to live inside · pleasant in a demo, exhausting on a Thursday afternoon
D
Defer to the desk
Then it gets used, argued with and corrected. The roadmap comes from that argument, which is why the software keeps its opinions and drops the decoration.
Every correction meets one question
Does this hold for the next ten accounts, or only this one?
- It holds
- The change ships and goes in the log next to what came out to make room for it. Nothing gets added silently.
- It does not hold
- It stays an account-specific setting or it does not happen. One customer's exception is not a roadmap, and paying for it twice is how a product loses its opinion.
Skipped, the roadmap goes to the loudest request and the product forgets what it is for
Where it lands
The same four moves, on three different problems.
BIND does not change between an offer, a pipeline and an inbox. What changes is which of the three areas the answer belongs to.
Lift
Sales enablement
Give the team something better than willpower.
Read
Sales intelligence
Know who to call before you pick up the phone.
Route
Go-to-market
Decide who you sell to, then build the machine that does it.
Before you adopt it
Three things BIND is not.
- It is not a framework you buy
- There is no certification, no canvas and no two-day workshop at the end of it. If you read this page and run the four moves yourself, that is the page working, not the page failing.
- It is not a way of moving faster
- Move one usually makes the first month slower, because writing down who you sell to settles arguments that teams prefer to keep having. What it buys is not speed, it is fewer rebuilds.
- It is not a fit for everything
- It assumes you can still change the product. If the software is fixed and the only question is distribution, you want a go-to-market plan, not this, and we will say so on the call.
Run it on your own stack
B, done on your business, for free.
Send us what you sell with and what your last ten deals looked like. You get the first move back in writing: who you are actually selling to, and where that description and your stack disagree.