tl;dr
handshake: the two-party agreement on what makes work usable
AI made “looks right” free, so usable-by-the-next-person is the product
entry point like the ritual: ritual gets a product used, handshake gets its work accepted
ALT H FD S O X G E ↵ ALT H F C M TAB ALT B 255 ↵
So what is that gibberish?
It is the Konami code for people with no personal life.
More specifically, it’s the keyboard shortcut sequence to select all the “hardcodes” or numbers that have been manually typed into cells in Microsoft Excel and color them blue.
It’s just a color, but it means that someone you have never met can open your model and understand how to approach it. You’ll disagree about almost everything else, but not about how to read it.
Excel is basically a sandbox that lets you do whatever you want. So in terms of structure, it contributes essentially nothing to this.
Let’s break down the shortcut:
ALT H FD S opens Go To Special
O X G E selects the constants and unchecks everything except numbers
ALT H F C M TAB ALT-B 255 turns the font a specific blue
Excel knows which cells were typed and which were calculated but doesn’t need to know why anyone cares, and it will happily let you color data invisibly white if you want.
The users supply the opinions, the software is the blank slate.
Now that software is doing the work, no one is standing between the software and the next person, holding that understanding on its behalf. Either the product knows what that person needs in order to use the work, or the work comes back.
A lot of people call tools with this knowledge baked in highly opinionated, but I think that obscures the true source of it’s value as a wedge in software.
Instead, I’ve been calling it a handshake.
Real quick, some awesome news—Forward This is presented by Ambart Law, our newest community partner. Learn more here:
Two entry points.
Few weeks ago, I wrote about the concept of a ritual as an entry point for B2B software startups. A ritual is a moment the institution already performs, such as a debrief, an inspection, or a shift handoff. It works because products that enter one the right way don’t ask users to change behavior.
The handshake is another one of these entry points because it ships meeting an existing standard: the recipient of the work it produces can work from the output on day one.
Work that looks right and work you can use.
In real life, a handshake is an agreement in context. Doesnt really matter if it’s a fist bump or firm corporate handshake. Ultimately, it boils down to:
In professional workflows, some handshakes are explicit while others aren’t. Contracts specify what to do and professional standard defines the bar it must clear. We learn them through certifications, training, or from our boss after messing something up.
Everyone has the same model.
A foundation model is a lot like Excel. It can do nearly anything and does not know what any of it means. The model supplies the capability, and the founder supplies the understanding of what the work has to be when it reaches the other side.
That is where a generic capability becomes a specific product.
Bloom, one of our portfolio companies, works with visual researchers, who gather and arrange references so other creatives can work from them. Anyone can point AI at collecting images.
But “here are some images” and “here is the direction we are working toward” are different deliverables, however similar they look from outside the profession. The researcher is judging throughout: the light in one image, the composition in another, the pacing of a sequence.
The next creative can only work from the result if those judgments arrive with it. Bloom leaves the judging to the researcher and concerns itself with what has to arrive.
Hostie, another portfolio company, works with restaurants. Consider what the phone is for. A party of eight calls. One person cannot manage stairs, and everyone needs to leave in time for a show.
A usable answer is a commitment: the restaurant knows what it has agreed to provide, and the guest knows what has been arranged.
Getting there takes seating, timing, policies, sometimes a follow-up question, and an understanding that sometimes a person from the restaurant stepping in is a feature, not a failure.
The two companies share almost nothing on the surface but, in both, the product is defined by what the person on the other side needs in order to rely on the work.
What follows.
The handshake as an entry point for software startups suggests an attractive growth pattern that starts from a very simple perspective:
The other side does not have to change.
This isn’t a new insight, but the economic viability of this type of solution exists in tiny wedges now.
Work that crosses a handshake is accepted or it comes back, and the person deciding held that job long before the product existed. A founder does not have to teach the market what good output looks like. The counterparty will tell them, usually the same day.
Accepted work earns a position. The counterparty adopts nothing, but they see the work over and over, in a form they already trust. That is how a narrow product moves toward the rest of the exchange and the transaction behind it, and it explains expansion better than three concentric circles in a deck.
And it can be tested in one conversation, before there is any traction to examine. Ask the founder what gets work sent back. People who have done the job answer immediately, in detail, and with some lingering resentment.
Recommended for you:
Knowing the handshake is not enough.
The convention and the handshake are different things. Some conventions are only adaptations to bad tools, and automating them faithfully preserves the workaround.
Nobody owns a handshake. Knowing the handshake is an edge in building the product and not a moat around it. Durability has to come from what accepted work earns.
Some exchanges check who did the work as well as what it says. A licensed engineer’s stamp, an auditor’s attestation, and a physician’s signature are all handshakes, and none of them can be satisfied by output that merely reads correctly.
The diligence questions are specific:
What gets work sent back?
What does the other side need in order to rely on it?
Does the counterparty have to change anything?
Is there real economic activity past the counterparty?
Does accepted work put the product in front of it?
A convincing answer should survive an awkward exchange as well as a clean demo.
The small things tell you where to look.
Yes, the spreadsheet shortcut looks absurd written out.
Day -to-day, no one actually experiences it as a decision. I actually didn’t really remember what the shortcut was, but it was just muscle memory because making the model ready for the next person is such a familiar moment.
That familiarity makes these details easy to overlook. People inside an industry barely think to explain them. People outside it see formatting, preferences, bureaucracy, a weird flex, or ceremony.
A founder who knows the work knows what the next person needs in order to use it. In software, that knowledge is most of the product.