What I’ve learnt about startups and games so far

When 2012 was about to end, I couldn’t find the energy to summarize the year, and didn’t have any clear view of my next steps. It was one of the hardest years I ever had both financially and mentally. I was very pessimistic about the future.

The only text that somehow resembled a summary or reflection was the post I wrote for the Junction, the accelerator we participated in (July – October 2012).

Now, in the last days of 2013 and the beginning of 2014, although I am far from being a successful entrepreneur, and Stix is still far from a financial success, I can reflect upon this year (and the year before) without fear, with healthy criticism but also with a lot of satisfaction.

The Hardest Thing Ever

Most of my early life was pretty easy, from my point of view. I was fortunate to have caring, hard-working and stable parents, who didn’t have a lot, but never deprived me of anything I needed. I was a good student early on, and continued to excel all the way to my graduation. Even my bachelor and master’s degree were fairly easy tasks. I was always a valued employee, I had interesting jobs, and my salary was pretty nice. It all was very easy.

I always felt it’s not fair. And somehow, I figured, that running my own business will challenge this “unbearable lightness of being”. Well, it seems I was right about that. Running a gaming startup is the toughest thing I ever did.

The moment you leave your safety net (as an employee), it becomes an ever running emotional rolling coaster. It’s all up to you and your team, you call the shots, but you also get the hits. There’s no one to tell you are great. The only metric of success is the results of your business – did you create something that others value? have you succeeded in getting an investment? is there traction? revenues?

And yet, it might be a cliché, but I am certain – today more than ever – there’s nothing of real value, that can be created, without real, hard and sweaty work.

So, would I do it all over again if knew how hard it is few years ago? Would I recommend it to other people? Certainly, if they are really, really passionate about an idea, a way to improve other’s life, a problem they want to solve, a life-changing product they just must build.

I would also give them some piece of advice.

Start

Start Early

I left the Israeli Air Force at age 35 (it was 2008). Most people don’t leave the army at that age, they either quit before they are 30, or they stay until the retirement (~45). I realized I want to become an entrepreneur, build products and companies. So I left, even though it was a bit “late”.

But I was afraid to take a deep dive in. I knew very little about entrepreneurship, business, marketing, consumer product or game development. Even worse, my social network was mainly irrelevant for my new career. So I took a safer path – I became a full time employee (in UX and Product positions), and in my spare time I ran several game projects. Only after 2 years (2010), I chose to focus on a single project, and only after another year (2011), I partially (50%) left my job. Only after 4 years after leaving the army (2012), I fully quit my job to lead our venture.

During this time, we’ve seen the rise of the mobile devices and the decline of the personal computer, casual games shifting from portals to Facebook to smartphones. Our initial venture was a multi-player browser toolbar, which shifted to a Skype-like gaming platform, then to a cross-platform mobile service, and finally to become a social-mobile game company…

Looking back, I am not totally sure if I could do it in a different manner. But I know that during the 4 years I worked as an employee, I learnt a bit about business, and marketing, building consumer products and even games. But I have learnt 10 times more in the last 1.5 years of running a company full time.

My advice – start it as soon as you possible. Don’t wait for the right moment, as it might not come at all. Drop your your excuses and just start.

You think you don’t have enough experience? Bullshit. Entrepreneurship is a totally different career path. The most relevant lessons for building your company will be acquired through the process of building your company, not by being employed by others.

You don’t have the financial security yet? Tough. The older you get, the harder it will be for you to take financial risks. When you are young and don’t have a lot, but you also don’t need a lot.

Markets change, you change. What is relevant today, might become irrelevant in 2 years. Make your move, and when ready commit 100%.

Start Small

Building a customer-worthy product is not an easy task. Especially, if you haven’t really led the design and development of a full consumer product before. It takes time (usually more than you’d expect), it needs iterations (usually more than you’d expect), and managing, designing, developing, and testing the product becomes an ever growing complexity.

My initial projects were fairly small – stand-alone single player games. A multi-player game, and especially a platform for mobile multi-player games, is a totally different league. The complexity of this thing is much bigger than I expected.

Looking back, I think I should have tried to transform one of my smaller projects to a real product, try to market it, monetize it, etc. I would have learnt so much, and would have been more ready for taking bigger, bolder projects.

No matter how small the product in size, you will have to go through all the main steps: building a team (unless you are doing everything alone), planning, testing, iterating, shipping. The smaller the project, the more chances you have to make it better (though never perfect…).

At first, learning should be your main goal. So choose your first project as small as possible. Even smaller. Tiny.

After making it for the first time, you can constantly challenge yourself with bigger, bolder projects. One of them might become the “one” you’d like to commit yourself to.

Founding Team

Size

We are a founding team of 4.

I always heard investors are more likely to invest in team of 2-3 people. A single person might not have enough skills or the mental strength to run a startup, but teams bigger than 3 have hard time in making decisions.

Based on my experience, they are right. We found ways to deal with this problem, but it’s not easy. The group dynamics are more complex and tedious. I felt it many times, that in sub-groups of 2 or 3 we have faster progress and better decisions.

So I would advice on a team of 3. I presume 2 could be enough if you hold all the critical expertise diversity needed to run your business. Later, as business grows you would hire employees, but they won’t be critical decision makers as the founding team members.

Diversity

Our founding team is product-oriented. All the four of us. Most of us had previously worked as product designers and/or product managers. Although we possess an excellent software engineering capabilities, it’s the product that we are all passionate about. Sometimes, maybe too passionate.

We spent hours discussing different issues regarding the product, from high level concept to the smallest details. The biggest disputes were about game design.

Everyone thinks his idea is the better one, and that it is critical for the success of the product. And although having lots of ideas is usually great, this model (of many people owning the same area) has it costs: time wasted, bad vibes, slow decision making process, and more.

I think diversity is a key in the founding team. The founding team should cover: business, marketing, product and engineering. People may have experience in several, and overlapping in some parts is not a bad thing, and having opinionated team-members is important, but people should feel ownership on their domain. They should feel super-heroes.

Leadership

Leadership is not an easy task. I found it easier in the past, when my leadership also came with a title (e.g. Major or Team Leader), but leading people has much more in it. It’s about showing the way, making hard decisions, but also about doing the dirty work, being a professional, a person that others trust.

I know I made a lot of mistakes as a leader. I didn’t always make the hard phone calls or sent the emails I needed, I let discussions continue instead of stopping them and taking a decision, I wasn’t always nice to my team members, I wasn’t always optimistic about the future, I wasn’t always solid as a rock.

And yet, I definitely lead the team. Most of the time I make the hard decisions, most of the time I try to do the hard and ugly tasks, and I try my best in being nice and optimistic. It’s not easy, especially when I feel bad and pessimistic.

So my advice – build a good, diverse, and small team, and lead them by showing the way, making hard decisions and helping your team members achieve greatness.

Endurance

This might be the most important ability of your team.

It’s not the idea (that changes during the process), not the market size. It’s your team, and mainly its endurance.

You need endurance because you will get hit, because you will be down, because there are going to be really bad moments. And the one thing that will save your team is endurance.

Our venture almost died. Actually, it did die, but right at the next day, our (future) investor called in to ensure our offer is still relevant…

If you stay long enough in the ring, get the hits but always come back, you will probably win (or at least give a good fight). Never loose hope.

Process

Plan

I already wrote about planning in my previous post. Planning a long-term project is hard. It’s even harder when you are doing it for the first time.

When we started planning our first commercial game – Loonies -  we had only one relevant experience: The President, which was a pilot game we have developed to test our conceptual and technical assumptions. So we knew how much it takes to develop a game, but not how much it takes to develop a commercially successful game…

We estimated it will take us about 6 months to launch. We even had good industry references telling us we are about right. We were wrong.

Initially, we estimated  it would take us about 3-4 months to get to a public beta (soft launch). It took us 9 months. And we are still building critical features.

Initially, we estimated it would take us a month or two to tweak all parameters, and achieve good metrics. We are 4 months in beta test and expect it will take us at least 2 more months to achieve these numbers.

So I will advice – again – to always plan, and then multiply your estimations. If you already have experience in this kind of project I assume multiplying it by 2 will be enough. The less experience you have, the bigger the number should be. Project will never run as planned – people become sick, go out on vacations, time will be wasted on discussions, meeting people, updating plans, learning new tools, and iterating and iterating and iterating (more about that later).

You might have read about startups that built a product in 3 months and had tremendous success. I don’t know any person who did that, and I am pretty sure these stories don’t tell everything. And if it happened to someone, he is the outlier. You shouldn’t build your expectations on these kind of stories.

Test

Your first idea will probably suck. And if it won’t suck, the initial implementation of the idea (aka product) will.

The only way to learn whether you have a good idea, a good design, a good product is to test it. And you probably can start testing it much earlier than you believe. At least some parts of it.

With a need-based product you can probably start validating the concept even before writing a line of code. There’s a lot of writing regarding the Lean Startup, which is a scientific-based approach to building products and companies (therefore experiments are in the heart of the concept). If you haven’t had the chance to learn about it yet, go and educate yourself. It is practical and important.

With games, it’s not different, at least regarding the state of mind. The only problem I found with testing game ideas, is that it’s much harder to validate them early enough.

When your product solves a need, you can find people who are your target audience to validate the idea with them, to show them some mockups of your product. But games don’t solve problems per se. They are entertainment, even worse, they are interactive entertainment. It’s very hard to know if a game idea is a good idea only by talking about it, or even showing some game art. Videos do a better job, but still not perfect. So you need to find the way to create a prototype of your game as fast as possible and test it.

I didn’t have the chance to try it myself, but in a away Kick Starter and Steam Greenlight, are closing the gap (by validating the interest and generating funding for your game), but it feels to me as if they appeal to niche audience (and we were trying to develop a game for the big general market).

So in our case we focused on prototyping. But there’s still a catch – while a crude prototype could be enough for your team (and other industry experts) to evaluate the game (is it fun, balanced, etc.), it will be very hard to test it with users, as their expectations of a “game” is of something much more polished, live and juicy.

It’s like a pilot show on TV. Although audience might watch only 2-3 chapters, these chapters still need to be well produced, or it might affect the audience’s opinions, you can’t just read them the script or show them a rough sketch.

While your team can evaluate the fun in the game pretty early by playing the game (a lot), all team members will be totally blind to usability problems, the learning curve, the level of difficulty, etc. These issues mustn’t ever evaluated by your team. You must test these things with new users (If possible do it face to face).

Only after you found the fun, and your game teaches the rules clearly and easily (based on the tests you made), you should start testing your game in the wild, with large audiences, data gathering and analysis tools.

I found multi-player even harder to test, as you need several people to to play every game. An a-syncrhonous turn-based game (like we did) is even harder, because the real gameplay experience is revealed only by playing it a-synchronically over a period of several days, at least. On the other hand, we found multiplayer games have some benefit in learning about your players behavior and gameplay styles, because we were able to really play with our users.

So to sum it up:

  1. In the prototype stage, test with experts (your team and other industry experts). Your main goal is find the fun.
  2. In Alpha stage (when the game should look, sound and behave much closer to the final product), start testing with your audience. Test mainly for usability (general UI, tutorial), but you can learn about fun too. If possible (sometimes you have to) let your testers the chance to play in their natural environment (in mobile games this means an installed application).
  3. In Beta stage, you need to start testing with a lot of people (hundreds, thousands). Target your audience. Statistics start to be more important than the individual feedback.

Test early, Test often! And learn how to test properly before you start. Good testing (which will bring meaningful learning) is a matter of design too (the audience to target, the tools to use, the data to collect, the metrics to evaluate by, etc). 

Iterate

Testing is the first part of your cycle. That’s the part where you learn about your product. After the learning stage, you need to implement what you’ve learnt. Design solutions to your problems, prioritize, update your product, and go back to testing.

This process will not only increases your chances of creating a good product, it also eliminates much of the arguments and fights over different concepts or priorities. It’s much easier to prioritize features, after you have results based on real user behavior.

Ship

I don’t know a lot about shipping a product. But I know shipping is critical.

The first time we “shipped” a product (The president), it was half-baked. But we committed to shipping, and so we did. It was painful. We should have treated it as an Alpha, but we didn’t have the runway back then. We just weren’t aware of how much time we really need in order to create a good product.

The main question is when is your product ready to be shipped? Based on my experience, your product will never be perfect, and if you are time constrained (you should), than your dilemma becomes clearer but harder. 

So how to overcome this problem? Again, it is wise to build the smallest valuable product (see Start Small above). The smaller it is, the less testing and iterations it needs, the more chances it has to become great (even through your own eyes) and be shipped. Just don’t forget that for the product to be shipped, you’ll need at least twice the time you originally estimated.

To sum it up: plan to ship and commit to shipping (or else all your work might not be ever seen by anyone else), define a small product (especially, if you never shipped before) and multiply your original estimation to get a more realistic goal.

Product

A Game Company vs. Product Company

I already mentioned that games are different from need-based products. And yet the bigger problem is the difference between a game company and a product company.

Startups get money to grow a successful company. Product startups focus on a single problem and try to solve it. They sometimes pivot, but they don’t usually create several different products, at least not in their early life.

But game companies are different. They are usually expected to build several (or 52) games with which  they will have some rate of success, as games (like other entertainment endeavors) are still regarded as hit-based industry. So game companies should usually plan to ship several games in the time they got (the time they got based on their founders’ financial situation, investments, etc.)

Games vs. Products

Games are a type of product, but they are different from the need-based products.

Like in any product your need to know your audience, and you need to understand what is the product concept, but it’s much harder to validate the acceptance of your product by your audience early enough.

You can always innovate in the same genre, so in a way competitors are not a direct problem, but there is a big competition on users time.

Games are entertainment, so the polish level is pretty critical early on – it’s impossible to get “early adopters” if your product is not fun enough (and fun is comprised of  both features and art).

Games are usually played for a short time (days, weeks, sometimes months), because it’s very hard to create games that are diverse and challenging for years (unlike a need that usually can be served for a very long time), so you can’t launch the game and iterate it after that. If players had bad experience or already tired of your game, they won’t come back.

And yet there are similarities too. You still need to validate it as early as possible (though in games it’s not as easy), prototype, test, iterate, find product/market fit (meaning the exact audience, good retention, and maybe even good monetization), and than launch. Moreover, there are games that are played for years, because they diverse enough and challenging enough even after a long time.

Either way, to become a successful game company you need a strategy that will capture specific audience and create value for a long time.

Games as a platform

So this is it. If you are planning on getting funded as a game company, you should have plans to create a “platform” (and I am not talking about a service company that provides technological solutions for other game developers). I see 3 ways of creating a platform as a game company:

  1. A game that is designed to entertain people for years (Clash of Clans, Candy Crush)
  2. Develop a creative-based franchise (portfolio) of relatively short-span games (Angry Birds, Cut the Rope)
  3. Develop unique model-based (portfolio of) games, e.g. multiplayer games. Even better – own a technology to support it (like Newtoy, the developer of Chess with Friends and Words with Friends who was bought by Zynga).

Each of these paths – if successful – can be transformed into growth (developing more games, partnering or publishing for smaller game studios, buying companies).

Conclusion

Tips and lessons learned are great, but the best lessons are the ones you learn by yourself. So as always, my best advice is go out and start.

Advertisements

Building a startup? Five Obvious Things You Will Probably Do Wrong

This post was originally published on the Junction blog (http://thejunction.co.il/blog/).

 

Doing a startup is really REALLY hard. It is much harder than you expect. Trust me.

We have learnt a lot on our journey: about ourselves, about our domain, and about building a startup. Boiling it all down to a readable post is not easy. Nevertheless, I can highlight the most important lessons I’ve learnt:

Commit 100 Percent

Our venture started off as a hobby. For a long time, most of us worked on it in our spare time. And then we switched to part time jobs and worked on our venture 50% of our time. Only at the last 4 months we fully committed ourselves to our venture.

Our progress during the first stage (the hobby) was painfully slow. Even worse, only when we switched to 50%, we understood we were working on the wrong product all along. Working at 50% was much better, as we met more and worked more, but we still deprived ourselves of important things like a working space (“why pay for a place when you are not there 50% of the time”?). Working together, on a daily basis, positively affects your team’s mindset, focus and efficiency.

So my advice is work on your startup 100% of your time. If you are not sure you are willing to do this, than do whatever needed to be sure, or don’t do this at all.

Going slow is bad. Not only because markets and technology change, but because at the end of the day, what your mind really remembers is the time-span you are working on your project and not the amount of hours you invested.

Have a Plan

By having a plan I don’t mean just the milestones for development. If you are a part of the “makers” community you will be able to craft a product development plan (although it will be 2, 3, or 4 times too optimistic than the reality). By having a plan I mean understanding your business plan, thoroughly. I am not saying you need to write a business plan document, but you need to understand your customers and their needs, your market (size, limits, regulations, and competitors), and how will you make money. Your product should give an answer to all of these things. Ignore one of them, and you might be building a piece of software that is doomed to fail.

On our first iteration we were creating a cross-device (Desktop and Mobile) multiplayer gaming platform. We haven’t invested too much time in understanding the market (and its limitations), nor did we really understand how are we going to generate income. We sometimes told ourselves we would open our platform for 3rd party game developers (though we never spoke to them at the time) and users could download games and we would share revenue. So after we invested in building a desktop version of our product (WTF?!), and started thinking of creating a mobile version of it, we understood our whole product model was wrong because one cannot create an app that behaves as market/store on mobile devices.

So, have a business plan. Only after you formed this plan thorough enough, you can design your product, create a development plan and build it (don’t forget to multiply it by 2, 3 or 4).

Have Rigid Deadlines

After you have multiplied your work-plan, set a milestone and commit to it. And I am talking about important external milestones: installing to beta testers, launching the product. It would be even better if the date is external (like a holiday), so you cannot postpone it.

Having a rigid deadline will create focus – what are the most important features to be developed, what are the really important bugs to fix. Having a rigid deadline will create commitment – you and your team will do everything to achieve the goal.

Hitting milestones according to plan is hard. My advice is work iteratively. Some part of the product can (should?) be designed and built in a waterfall method, but most of your product development plan should be iterative.

It enables you to continuously test your product and reflect on it, prioritize features and bugs better, and have an ongoing sense of accomplishment. You might not have the perfect product at launch (yet). But you will have more chances of having a product that is good enough to be shipped on time.

We are a quality driven team, and it’s very hard for us to ship a product that is not perfect. So we have committed to an external deadline: the US elections. Our first game, although not directly related to the US elections, would benefit a lot from the hype around the event. We knew we must ship before the elections, and totally changed our work, our decisions and level of expectations.

Mind Your Potential Customers Not Your Potential Investors

I found it is hard to get funded, especially because we are a team of first time entrepreneurs. Nevertheless, during the last 12 months we were trying to do exactly that. Obviously, reaching investors, require specific tasks that affects your decisions and priorities.

Not only talking to investors takes time (setting meetings, getting prepared, meeting them, following up, etc), if you are not careful you might make bad decisions regarding the product development. For instance, investing (way too much time) in an irrelevant feature only to demo or impress potential investors.

We made this mistake twice (a bad habit for itself). Once, we started building a demo, and found ourselves building the wrong product (because we never stopped to think about the whole business plan); and second, we implemented a design that we knew we won’t ship, mainly because we thought it will be impressive enough for potential investors.

At the end of the day, most potential investors are (said to be) more impressed by traction than by a cool product. So whatever makes your customers happy, will probably make your investor happy.

Get feedback. ASAP!

No matter at what stage your venture is, talk to people. Talk to people about your product, talk to people about your business model, talk with potential users, talk with fellow entrepreneurs. Just talk. And if you having something to show already, than show it (mockup, demo, beta…)

So many times we live in a “world” we have created, that we start to believe it is true, or perfect. It’s not as if every feedback should immediately change what you are doing, but having many opinions will give you a wider view of your venture.

We have been building our first iteration for many months, and didn’t get any real feedback during this time. Only when we started talking about it (and showing it) to people, we got to the sad conclusions we were building the wrong thing.

Bonus: Be ready to make mistakes. A lot!

Nothing will really help you not making mistakes. Not this post, nor TechCrunch posts, or TNW, or any other blog posts. People don’t learn well through other people’s mistakes.

I know, you probably read these lines and say to yourself that you are different, or maybe you even think you are implementing these tips. But it’s only after you make the mistake and understand you did them, you might really learn something.

Therefore, you should just start doing it. It won’t be easy. I promise.

Good luck!