Learnings from working at a Japanese startup

Japan’s education focuses heavily on exams and memorization. This is nothing unique as eastern Asian countries are all somewhat similar including South Korea and China. However, the key point here is that English curriculums in Japan generally lack any kind of interaction.

If you’ve tried to learn a new language before, you’ll probably know that the best way to get better at that language is to talk to people. Hang out, chit chat, and talk about random/serious stuff. There are a ton of information included in face to face interactions, and you can pick up a lot of vocabulary and social context in those conversations, but that’s never really part of the curriculum when it comes to English education.

Unfortunately, it’s all about memorizing grammar and vocabulary, but they’re rarely put to use. Everything needs practice, and obviously if it isn’t, then there’s nothing that can come out of it.

People are generally afraid to speak unless they think their English is Good.

And Good in Japan means close to a native speaker level. That’s a very high bar for someone who hasn't spoken that language before, and it causes folks to go into a negative loop of not wanting to speak, hence losing the chances to improve their communication skills.

It’s extremely hard to communicate intentions.

A Japanese startup obviously and justly will have Japanese employees. However, an unknown fact about tech startups (and even large enterprises) in Japan is that many of their engineering teams are not Japanese, and my organization was not an exception either.

So while myself is fluent in Japanese, a large portion of my team is not, and finding someone that can bridge that gap is difficult simply because of language requirements.

And language is just the beginning when it comes to communication. There are different social norms, assumptions, biases, expectations based on racial and even individual backgrounds. And on top of that, Japanese are not well known for being vocal, so with all these as compounding factors, it makes communication between teams, and cross department collaboration very hard.

If you were able to close an enterprise deal, great! Things are going to be smooth moving forward!

Well, not so fast. As with any enterprise customers, their demands are (rightfully) high. Accommodating their needs after closing the deal is just as resource intensive as trying to close the deal itself.

Some of the enterprise companies we’ve worked with have been very understanding, a lot more than I’d expected and they were extremely reasonable. Some, I just have no idea what to do with them.

Another interesting learning is that SLA means pretty much nothing to enterprise customers.

This is probably true universally, as I’ve seen the VP of Engineering having to go on a trip to apologize to customers whenever we had a large outage at Cloudflare.

Finding a local partner that will distribute your service can be a lot faster than trying to close an enterprise deal. Depending on your partner, they might also actively help you sell your service and provide some amount of customer support.

If you don’t have anyone on your team that speaks Japanese, these are all great deals. But like everything in life, there is a tradeoff.

1. The way it’s sold might not align with your brand: Unless you have stringent brand guidelines, how your product gets sold might not be what you expect. They also might not be sold to your target customers either. Your partners are not your sales team, meaning they won’t know what you want them to know and sell how you want them to sell. Partnerships are generally revenue share or commission based, so the incentive is to sell to as many customers as possible regardless of the demographics.
2. Customer support won’t get you the details you want: If your partner helps with providing customer support, it can be a lifesaver for you, especially without a Japanese speaking team. However, they might not have an English speaking team that can communicate with you either. Even if they do, they’re unlikely to help dig into issues that can result in actionable items to be passed on to product and engineering. This is especially true if your partner has a lot of other partners, so they simply won’t have the time or incentive to give you the white glove support.

And if you’re a fast moving startup, any changes you make could be their potential nightmare as support procedures could change frequently, and eventually, they’ll want to stop dealing with you because you’re too much work for them.

Your headwind for making changes to the system will get stronger over time. Unless you have a system that can segment customers and provide different release schedules, this is generally true.

We’ve done things like,

• providing feature flags for managing feature releases
• an on-demand release schedule
• staging => RC => production environment release flow

and even providing a very simple canary environment to mitigate risks while balancing the speed of changes but still push backs for releasing changes never decreased.

The last thing you want to do as a startup is to stretch yourself thin. Features are usually never deprecated once they’re released, and it’s one more thing you need to maintain. Unless of course, you’re the type of person that always tracks the usage of your product features.

Even then, scope creep is pretty much inevitable when you’re working with potential customers in Japan. In order for them to make the switch, it’s a requirement for them to make sure things continue to work smoothly and without disruptions. Because many of their systems are custom made, there are no good ways to just deactivate certain portions of their system and expect things to continue to work well because who knows how those systems are built.

Potential customers will ask a lot from you, and rightfully so due to how their current system works. It will sound unreasonable if you don’t understand the context. Well, on second thought, it’s quite unreasonable even if you do.

As the SaaS market (hopefully) grows, these issues could be resolved over time.

One more thing. People generally forget about security until the very last minute, so here are some observations when it comes to deal closing.

Japan doesn’t really have a security or compliance standard like SOC2 or ISO27001. There’s a thing recently introduced by the Japanese government called ISMAP but it’s a joke so unless you have the resource level like Amazon, Google, or Microsoft, don’t try to even get certification since it’s just not worth the effort and cost - we were quoted around $300k-$400k equivalent when we checked with auditors last time.

Having said that, any large enterprise usually has some kind of single sign-on implementation. Either it be SAML or LDAP. If you’re going to persuade Japanese companies, make sure you have those systems implemented so it’ll make the conversation a lot smoother. The last thing you want is a deal falling through because of security concerns.

Another interesting thing a lot of companies love to do is IP address whitelisting. As a startup operating on AWS, it was close to impossible trying to comply with that while also making improvements to things like caching and CDNs.

There are ways to do this using Elastic IPs, and if you own an IP CIDR already (which we end up securing an CIDR with APNIC), there’s the BYOIP service by AWS (I assume there’s something similar in GCP and Azure).

It’s likely a lot easier as well if your product is a TCP based request/response type of service, because you know, the servers accepting traffic should be stateless. We unfortunately, were a WebRTC based service built on UDP so it was very challenging when it comes to releasing changes while making sure IP addresses don't change after deployments.