4 Amazing pieces of advice for VR indie management by Daniel Sproll

Last week I was in Berlin to attend the XRCC glamhathon (a very glam hackathon) as a mentor and in the mentors’ team there were other very talented XR professionals. One of them was Daniel Sproll, the CEO of Realities.io, the game studio behind Puzzling Places, one of the most successful indie VR games out there (buy it if you have not it in your library, yet!). I had never met him in real life before, but I spent a great time with him, talking about VR, eating, and playing games like table tennis or table soccer (I still have nightmares thinking about his goalkeeper’s strong shots).

But I’m not here to write how much I loved him (even if I do) but to tell you about some very practical pieces of advice he gave to me and to the other participants of the event about the management of VR projects. I was able to hear in particular four important lessons that indie teams should remember when they are developing a game if they don’t want to go out of business.

1. If you can’t complete the prototype in 2-3 weeks, you can’t complete the game in 1 year

When Daniel told us this “practical law” the people of Realities.io have, our reaction was basically this:

This “law” (which has been formulated by Realities.io’s Shah) is very interesting because it’s true as a rule of thumb: it was true for Puzzling Places, and it was true also for Beat Saber. I clearly remember to have read that Beat Saber was prototyped in a couple of weeks, and then the team spent around one year before releasing the actual game.

The fact is that developing a prototype and shipping an actual product is a completely different beast. Prototypes are all hardcoded, buggy, and simple. Products should be ultra-polished, and refined, have a good UX, and a good onboarding procedure. A product takes a lot to build. And you have to release a very good product if you want to be successful: Beat Saber became a hit because it was ultra-polished, from the perfect synchronization of the slashes to the beat of the songs to all the graphical effects happening around you, not to mention the coolness of having light sabers in your hands. The game was cool to see, and it appeared even cooler in the mixed-reality videos made with LIV. That was the beginning of its success. I don’t think the game would have been the same if they just shipped two sticks in the hand with which you could hit some gray Unity cubes. If you want to ship a hit game, it should be a very polished one. This takes a lot of time, much more than what you need to build a prototype.

This rule of thumb is important because it lets you frame the size of the work that your team has to commit to to ship your next game. If you are an indie team you are probably tight on money, so you can not commit to a game that needs 5 years of development: you can do that if you are Rockstar Games, not if you are a small team in Italy. So if you are doing a prototype and that prototype alone is taking too much time, it means that the development of the game is taking such a long time that probably you can not sustain it. If the prototype takes 2-3 weeks, probably making the fully polished game takes around one year, which may be sustainable, so you have to plan accordingly your resources (time, money, people) to deliver that. I doubt that a small team can commit to a project longer than a year without seeing the money back, so don’t work on projects that you can not prototype in less than 3 weeks.

2. Underpromise, underdeliver

Shah has formulated also this other law, which looks like the manifesto of lazy people: “Underpromise, underdeliver”. This statement mocks the usual one, which is “Underpromise, overdeliver”, which means you shouldn’t be too bold with your promises, but you should always deliver over expectations.

While I still love the usual statement, because I like to deliver always more than people expect, I understand also the power of this one. While it looks silly at first glance, it is actually a powerful statement about not trying to do too much. Overdelivering means putting pressure on the team, and probably not respecting the deadlines.

It’s 10 years that I’ve been in XR startups and I’ve seen that every time, every project takes much more than expected, and in the end, you are forced to cut features before the delivery date. Everyone is always very stressed about the delivery because there are always too many things to do in a too short time. It would probably make much more sense to just be realistic about the times and not try to overdeliver some features that are not going to happen anyway. On the contrary, most probably even some of the forecasted features for the “normal delivery” have to be slashed away for the lack of time, so maybe it makes more sense to even plan for underdelivering.

Of course, this shouldn’t be a suggestion to be lazy: it’s always good to be ambitious and to try to push the limit. But at the same time, it’s important to be very realistic about timing.

3. Define well the scope of your work

Daniel was the mentor of the gaming track. He went around the tables with the teams that were participating in the hackathon and one of his most precious advice was about defining very well the scope of the work.

Most teams in hackathons start with ambitious ideas like using multiplayer or developing very complicated technical features. This is going just to put a lot of pressure on the team, making all the team members sleep very little, just to deliver in the end a very crappy application that is never going to win. It’s much better to assess exactly how to deliver an interesting application, being realistic about the available time, and focus on the few important things you can build.

One of the projects that won the hackathon was just about assembling cubes together to create objects. The mentor from Meta who gave the award said that the idea was simple and not original, but the implementation was one of the best he had ever tried, so the team deserved to win. On the contrary, some teams tried to make crazy things like multiplayer mixed reality with spatial anchors and didn’t win.

I know, it’s a hackathon and it is made to have fun, so it’s ok to develop weird stuff (I would do that myself), but it is an example of what usually happens with products. You must have a clear focus on what are the main features you want to build and define your scope of work accordingly.

This point is a bit of a mix of the above two: since you must deliver a polished product, you must be very careful about what features you are going to add because you need to deliver them well. I remember in the past trying to create applications with many features, but then realizing that every single thing I was adding required not only more time for development but also for polishing, debugging, and testing before the delivery and also for the updates after the delivery. Every feature you add is adding a big toll to the total project time. And trust me, if you ship 20 very rough features, you are just going to receive a lot of negative feedback from your users. It’s much better to ship only 5 features, but deliver them very well, so your users will be enthusiastic about them and ask you to go on.

Defining your scope of work, when your resources are limited, is the way to go. Don’t try to do too much, focus on what is important.

4. Commit only to products that “click”

Daniel told us that Puzzling Places was prototyped in a couple of weeks and the people in the team loved it when they tried it. Then they left the prototype there for some time without further developing it, then they played it again, so that they could be more cold about its evaluation. Playing it again, they loved it again. They knew that it could have been a great game, it “clicked” in their mind, so they decided to commit to developing it. The game went out to become a widespread success.

There are two important lessons in this story. The first is that when you create something great, you know it. The moment you try the prototype, you feel that is fun, you feel that you’ve created something many people will like. So you can commit to it, knowing that most probably it will be a success. Of course, you can not be sure about it: entrepreneurship is always a bet. But you should bet only on the horses that have the most probability to win, not on the weak ones. When you try your own prototype, if you feel that thing is amazing, and the other people who try it also tell you it’s amazing, then it’s worth betting on it. We all know that “click” sensation you feel in your brain when you try something great. I felt it myself when I tried Puzzling Places: I thought it was amazing and relaxing. When you feel that click, you know it’s time to take a bet.

VR is still a niche, and notwithstanding all the numbers about the studio making millions that Meta likes to share, the reality is that most development studios are starving because the market is too small. You can not afford to ship an “okay” game. If you ship a game that is “okay fun”, you will probably get just “ok” sales and you won’t get back from the investment you put into developing your game (the famous year of development). This puts the survival of your whole company at risk: as an indie team, you can not afford to invest your resources in a title that fails: you risk remaining without money. So you have to try to ship a great game, a game you feel is special from the moment you try its prototype. This is how you can create a sustainable business for your game studio.

The second lesson in the story is much more subtle and it’s about not evaluating your prototype when you are emotionally committed to it. When you do something, that thing is your baby, so you are emotionally tied to it: of course, you are going to like it as soon as you try it. And probably you get angry when someone criticizes it. But this is not a healthy way to evaluate a business: you have to think with your brain, not with your heart. And that’s why the team at Realities.io waited some time after the prototype was made to evaluate it again. After a few weeks, you are de-committed to your application, so you play again with what you did with fresh eyes, and you can be more rational in evaluating if it is good or not. And if it “clicks” again, then it means that probably what you did is actually cool and you can make a business out of it.

I hope these life lessons may be useful for the indie teams out there. I want to thank Daniel Sproll for having shared his wisdom with all of us and I invite you all to share the other VR management lessons that you may have in the comment section here below or on my social media channels.

(Header image by Mapbox from Unsplash)