Otachidokoro Sushi Ki, Kyoto, Japan, April 2026 - edited with GPT Image 2.0

I recently had omakase in Kyoto, and I was thinking more about the concept of “omakase” in the context of SaaS.

I think DHH was the one who popularized the concept of “omakase” in the context of thinking about software products, and it’s a useful way to draw a distinction between something where the product path is very much tightly controlled and chosen vs. something that is left open to the customer to choose.

One thing I struggle with as a developer is that I tend to go in the direction that everything should be completely flexible and made of Lego blocks you can stitch together how you like. Because that’s the right way to architect systems so you can expand on them. But that’s not the right way to build a product.

In reality a lot of successful SaaS products are:

1. Heavily sales-led
2. Meant to solve a super specific problem for a specific ICP.

Given this, omakase is the right approach more often than not.

Think about precisely what you can give to the customer that will make them successful.

Then deliver it in a way they can actually use.

Product in the GPT-5.5 / Opus 4.7 era

Building software products in April of 2026 is a weird time. But building the perfect feature that your customers can understand and intuitively use is hard.

It’s easier than ever to ship features.

And yet…

It’s harder than ever to be disciplined about what you ship and why.

For the first time ever, I have a ton of unreleased features sitting behind feature flags in my product. They work and they could be launched. But should they be?

The more features you have, the more you must unify them into a coherent product.

What is a coherent product in B2B SaaS?

Well, it’s something that causes pain and confusion when it’s wrong. Does everything make sense? Do the pieces fit together?

This is not so easy to do.

The more features you have, the harder this becomes. Each feature has a cost, and the cost is not development time anymore, it’s product complexity and customer brain damage.

The customer doesn’t want software.

I have come around again and again to the cluster of ideas that:

• Customers don’t want to think (about how to use your software).
• Customers do think about their problems.
• The software is just a tool to solve their problems.
• The tool should be effortless to use.
• All sharp edges should be removed.

All of this stuff is immensely hard to execute on.

Can you think of really good B2B software products you like using? How many? Slack? Figma? Shopify? There are not many.

Eating with your hands.

One of the things about omakase is that you are supposed to eat with your hands.

It’s an intimate experience.

To draw the analogy…

The next best approach in B2B SaaS is this:

1. The customer hates your software and just wants the problem solved.
2. The “Service” part of SaaS is more important than the “Software” part.
3. At least figure out how to get them across the finish line with Service (with your own labor).

Maybe until you do the done-for-you service, you don’t even understand how to make the nice software that solves their problems.

So maybe you can’t even understand how to design a nice omakase experience until you’ve done the done-for-you service.

I believe there are some product savants (perhaps e.g. Dylan Field from Figma) who are able to design a nice product on the first try, but most of us obviously cannot do so.

So in the age of agentic coding, all of this matters a hell of a lot more.

Because the code is not the blocker. The product is.

So at least you had better have world-class onboarding and world-class service until your product is world-class.