A Year in Review at Ginzametrics

A Year in Review at Ginzametrics

Happy 2012!
I was reflecting on the growth and changes Ginzametrics went through over the last twelve months and decided to share my notes with anyone else who may be interested. In particular, if other startups or startup founders find any of this useful, I’ll be happy.

Going from One to Five

A year ago this time, I was still mostly working out of cafés (though I had also started working out of 500startups) and my house. I was still in the middle of raising our first seed round, which was taking months and had relatively little money in the bank (about $100K). It was enough to last me for awhile if I needed it but I still didn’t feel comfortable hiring another engineer (especially in Silicon Valley). Fortunately, due to some early deals, I had hit profitability with the business so as long as it was just me, but having gone through two years of being cash-strapped, I was still relatively risk-adverse about expenses (and still probably am).
So, I was going through a daily ritual of trying to hustle new deals, keep up with blog posts, translate as much of the app and documentation into Japanese as possible (Japan is a big market for us), build new features and keep the existing features in production up and running, all while keeping existing customers happy. It was truly exhausting and I didn’t realize how tiring it had been until several months after making my first few hires.
Luckily, our first seed round closed about a month later and I started to make some hires. My first hire was Nick, who I had been speaking with for a few weeks. He made it clear early on that he wanted to join as a co-founder and was willing to make some sacrifices to prove it. Since then, we’ve added two more engineers on the West Coast, Shun and Carlos. It took us a few tries with different people to settle on the right engineering team (fortunately avoiding drama along the way) and now we’re cranking.

Building an Engineering Team

After getting the right people in place, probably the hardest part about growing the engineering team was transitioning me out of a primary role in product development. This took much longer and was much harder that I thought it would be. In the early days, I could write a feature, release it a few minutes later and then fix it again a few minutes later when someone found a bug. We still try to keep a very agile process but it’s not as easy as it was before because now we have real, paying customers. In particular, because we are serving the enterprise SEO market, there is less tolerance among our customer base for instability and regressions.
Another long term consequence of me building the product entirely myself early on is that I suck at building automated tests. Part of the problem is that when you’re building a product based on your perception of customer feedback, almost everything you’re doing is prototype code and there is a high likelihood that you’re going to have to discard it. Adding in extra time to test everything was something I could never bring myself to justify. However, as customers started to pay us for a quality implementation of certain feature sets, we had to invest time in building both automated tests as well as manual testing plans that we perform on every release.
Some of the best advice I received just before I made my first hire came from Dalton Caldwell, who also repeated some of Reid Hoffman’s advice about building an engineering team. The one piece of advice that really stood out was to set a clock speed or heartbeat for your product development, and do everything you can to make that heart beat as regularly and as often as possible. It took us quite awhile to get this right but we are now consistently doing two releases per week, on Tuesdays and Thursdays.
In the process, we did lose some of our early agility in being able to write and release features almost instantaneously but we have also created a relatively sane production schedule and all but eliminated regression errors. This also frees me up to work on product management and sales, although I also still work on product (more on that later).

Expanding Back into Japan

Ginzametrics was born in Japan and is being raised in Silicon Valley. I lived in Japan from 2008 to 2010 and our first customer was a large Japanese ecommerce company (a different ecommerce company than this one). I moved to Silicon Valley in May 2010 to attend Y Combinator. So between May of 2010 and September of 2011, we had no people in Japan, even though Japan is a huge market for us. Due to the support and belief in us from our early customers in Japan (highly unusual for big companies there), we were able to continue to expand, despite our lack of presence.
I was in Japan in April of 2011, just after the earthquake. In one of my meetings with a big customer, they made it clear to me that they wanted local support in Japan. Finding good people is hard anywhere, but finding good people in a country where you don’t live is even harder. The two years I spent in Japan building Ginzametrics (and doing consulting before that) were very hard financially at times but, even today, I continue to reap benefits from spending the time building a network there.
I reached out to a good friend, Tad Fujinaga, who reminded me of another friend that he had introduced a few years ago, Masa Shimizu. Masa and I had met at one of Tad’s famous mobile study groups / drinking fests and he had struck me at the time as someone I wanted to work with in the future. The timing was right this time as Masa was just beginning to look for new opportunities.
After a few conversations, we started working together and he has turned out to be a force of nature in the Japanese market. He has been a great example for me in learning more about building buzz, doing sales, getting commitments from customers when agreeing to provide additional features, and much more. I wish I could find another Masa here in the US market (and I’m actively looking :-)).


Speaking of Japan, which has held a large influence over my life since childhood, a word that my first (and favorite) martial arts teacher taught me continues to stick with me: irimi. Irimi basically means “to enter”, but in the case of its eponymous throwing technique in Aikido, it demonstrates that you literally cannot execute the move without pushing your body forward into where there appears to be no opportunity to move.
Many times, through the year, I found myself faced with various decisions and more often than not, the option that looked the least feasible even though it was the most direct and obvious turned out to be the right one. Sometimes, this means investing more than you feel comfortable doing. Other times, it means making big architectural changes when it seems appallingly risky to do so. Sometimes irimi leads you into the mother of all fuckups but, many times, things ended up working out better than I had expected.
A similar concept is a question that I got asked a lot earlier this year: aren’t you afraid of failing? (I stopped getting this question, for some reason, after raising money. The fear of failure, of course, never goes away.) I figured out somewhere along the way that there are two ways to fail. The first is, surprisingly, what seems to happen to most startups. They just lose hope somewhere along the way and whimper away.
The second way is to completely explode. Like, push so hard and keep pushing harder until the company literally just explodes. I decided early on that, if the company is ever going to fail (and I don’t think it is), it will be as massive and as gigantic as an explosion as humanly possible. This has the added advantage of saving some effort along the way because the things you have to do to explode in a good way are pretty similar to the things you would do to explode in a bad way. It all just comes down to a few critical decisions along the way.

Getting Comfortable with Remote Team Members

In addition to our five full-time employees, we also work with some great contractors, both in Europe and in Japan. In Europe, we work with an amazing devops guy who has moved us off of our earlier deployment process built on Rubber, to using Chef (which will be another blog post), and a killer Rails developer who is helping us add some sexy new features (to be released in a week or two). In Japan, Masa has two consultants that he works with to help on sales, marketing and social marketing and they have quickly paid for themselves.
Although I’ve managed outsourced teams in many countries around the world, this is probably the first time I’m really comfortable working with such a distributed team. I think a large part of it is that there are many more tools (Github alone makes life so much easier) available today than there were the last time I worked with such a distributed team, back in 2008. The developer ecosystem in general has really matured, I think over the last few years.
37signals had a great post about this topic a few days ago. We’ve come to the same conclusion and encourage startups who are struggling with hiring good people to look outside of their own markets, especially if you’re in Silicon Valley or San Francisco.

The Coming Year

Doom and gloom predictions aside, I’m really excited about 2012. We’re hitting all of our cylinders, we’ve got some cash for growth, we’ve figure out our niche and our product is coming along nicely. There is still a ton of work to do, of course, but I couldn’t think of anything else I’d rather being doing right now. As always, it’s our awesome customers, team members and investors that make it all possible. Thanks to all of you.