A few weeks ago I watched the documentary Jiro dreams of Sushi. I found it very interesting. The story of Jiro’s pursuit of perfection, his sons, how passionate he is about his craft and his product is amazing. I strongly recommend it.
During the documentary I found myself noticing some interesting parallels between Jiro’s business and Software as a Service (SaaS), and I thought Jiro had some very good lessons for the SaaS world.
Much like Software as a Service (SaaS) Jiro’s restaurant has a clear product core that he and his team have spent years perfecting. Years ago Jiro decided his restaurant would only serve Nigiri(s), no other food (some visitors find this odd). This ensures he and his team can focus on perfecting their product offering over time.
However, even when he has this simple menu Jiro adapts his customer service to specific customer needs, using insights he has gathered from his customers over the years.
A meal at Jiro consists of ~20 pieces of Sushi. Jiro serves the first piece to all customers at the same spot on their plate, and Jiro watches what hand each customer uses to pick up their food. If they pick up the sushi with their left hand, Jiro makes a mental note and from that point on starts serving left-handed diners at a different position in their plate, making it easier for them to pick the pieces up.
Another thing Jiro to prevent diners from getting full before trying all pieces is serve different size pieces to men and women, serving smaller pieces to women (whether that’s correct or not is not the point 🤷♂️, it seems to work for him after years of being in the business).
Jiro and his team also make a point of having a repeatable and efficient way of putting sushi in diners plates twice a day. One could say Jiro’s team deploys multiple times a day (lunch and dinner) 😋:
They have established relationships with specific market merchants to purchase a particular fish type from each. Each vendor is a specialist in their fish type. Jiro trusts merchants to know their craft, and merchants, in turn, feel pride in providing Jiro. The process to prepare ingredients and even the process to hand make each piece of Sushi is repeated day in and day out the same way, which allows predictability and continuous improvement of their technique.
Finally, Jiro’s place has very comprehensive and simple to understand documentation on how to use the product.
These are the lessons I gathered from Jiro’s documentary that I believe to be greatly applicable to SaaS companies, especially startups.
Do one thing well and perfect that. You might be tempted to “add more dishes to your menu” aiming to please some extra customers, especially in the beginning. Resist that temptation if you have the runway, and you’ll likely be more successful in the long run.
Multiple reasons can cause a company to “lose focus”. One that’s is fairly common is that while you and the team are building your SaaS product, you might run into situations when big customers want to pay you a lot of $$ for your product, only if you agree to build a certain set of features. What to do in this case depends on many factors, there are no easy criteria to say “yes” or “no”. But over time these decisions accumulate, so you need to be intentional about them!
The more “one-offs” (features that are only valuable for one or a few customers) you do:
- The more complex your product and codebase become, making development slower
- The longer it takes to get to your original vision because you are spending time doing other things and because of the impact of #1
- As a consequence of #1 and #2, the less motivated a team that believes in the vision will get.
As much as possible, once you have found product/market fit, try to resist the short term $$ temptation.
Initially at a startup you are trying to minimize cash burn. This means you might build some rudimentary things instead of buying.
If you get to a point when your company sees some success, changing mindsets and differentiating what your core is and what it is not is fundamental to grow and scale.
Jiro makes sushi. He does not fish his prawns. Unless it is your core business you too should prefer “buy over build”. This helps increase focus. Creating your container orchestrator, running your observability stack, or implementing your login 😛 are things to avoid as they reduce focus and increase cost in the long run.
For example: investing in observability (metrics, logs, tracing) is something all SaaS companies have to do, regardless of their industry. Unless you are extremely large and have particular needs (e.g. Uber and Jaeger, Facebook and Scuba or Google and Borgmon) you shouldn’t be implementing an observability stack (and ideally not running it either).
Pick your vendors and/or projects and use them. Don’t spend time implementing observability tools from scratch unless that’s your core business value.
Even when you have a SaaS product, all customers are unique. Learn from them, listen to them and over time you’ll be able to figure out what things you can do to provide a better service to all your customers. Take every opportunity to improve!
At Auth0 we constantly strive to learn from customers and prospects: early access programs, monthly or quarterly customer reviews, specific feature discovery sessions, and support tickets are some ways customers provide feedback. Whenever we build something we always think about how customers will use it.
You know your product, you know how it is meant to be used and you know what it shines at. To get users to see it, investing in good documentation and easy to understand UI is key.
Even something as simple as “how to eat sushi” can benefit from good documentation.