Nomster

My reflective, challenging yet illuminative startup journey back in 2015. Nomster is a geolocation-based, gamified food discovery mobile application.

This is a story of lessons learnt, trials and evaluation.

Role: Founder, Product Manager
Duration: 15 months
Developed with: Unity, PHP

The beginning

In March 2015, I founded a startup called Nomster. I was inspired about the power of gamification and how gamification could change habits, retain engagements and improve experience. Nomster started out as a mobile app that engages users to eat healthier through gamification. Think ‘Tamagotchi’ (the digital pet that grows/dies based on how good you take care of it) meets healthy Yelp. Serendipitously, I pitched to Singapore’s largest broadcast centre Mediacorp and was so fortunate to receive their investment and incubation. This began my amazing journey that taught me more than I could ask for. To run a startup, however, was not as easy as I thought.

Early challenges

Having little technical understanding of software development at that time was a huge challenge in itself. Who do I need to build the application? What are my technical needs? How do I optimise my timeline, developing the MVP? How… do I go about managing the development, business and users? Managing my first technology startup during college was demanding. While I was trying to find co-founders, I consulted several product managers and mapped out my team needs.

Software developers in Singapore are scarce and costly. I could outsource all my development and focus on user experience and the business side, but starting this venture was more than a learning experience for me than anything else. I knew I know too little to begin with, but at that time, I wanted to learn and challenge myself as much as I could so I decided to find and manage my own team. I went to Ho Chi Minh City, Vietnam and talked to dozens and dozens of software developers. Finally, I built my team of 5 – a Unity developer, PHP developer, designer, project manager and marketing. 

Conceptualising the story

We defined the general direction of the application and interface, and wireframed the user flow. The more a user discover and enjoy healthy food around their vicinity, the more progress they can make in the captivating game and characters. 

Prototyping

As we start to prototype, we focused on the ‘Tamagotchi’ monster – that was central to creating the concept of ‘feeding’ healthy food to your monster. You could interact with your monster – in our case Nom-ster – by tapping, swiping or moving it. Our initial response to the interaction with the nomsters were amazing, it was akin to taking care of a pet.

The Nomster character (akin to ‘Tamagotchi’)

Alpha version interface

Alpha testing user flow

On clicking ‘Nom’, users could see discounted food and eateries around their vicinity. To verify that the user visited and purchased at the merchant’s outlet, the merchant will enter a unique 4-pin code and the user’s nomster will be fed (it will be regained back to 5 lives!). If you fail to feed your nomster long enough, it will get upset or sick along the way. With full lives, you can play more mini games, rake up points and level up.

Challenges

At the start of prototyping, there were many considerations that we struggled: What constitutes healthy food? Macdonald could be serving salad and that dish could be considered healthy too. Would the interaction between user and merchant (or the restaurant’s server) be awkward since there is a quick exchange of phone to enter the 4-pin code? How about QR scanning or beacon technology? Eventually, we decided to reach out to accessible (regardless of how ‘healthy’ they are) merchants to onboard them to the app and 4-pin code seems to be the familiar mode of verification with our users. We wanted to get started to test the interaction first.

As a startup with limited budget and time, it was challenging to conduct in-depth focus groups and interviews with potential users. Through convenience sampling, we gathered some initial qualitative feedbacks after the first usable prototype was developed. Many of the users loved the interface, the graphics and most importantly, the mini games – it was short, addictive and easy-to-learn (similar to ‘Doodle Jump’ or ‘Flappy Bird’). However, most of the users had lackluster responses to redeeming discounts and visiting merchants around the vicinity. Many users said “I would (redeem) if the discounts are enticing enough.”, “Maybe.. if the restaurants around my vicinity suits my appetite at that moment, but I will play the games – its super addictive!”.

That said, what were we missing here?

Plenty. Was convenience sampling the right way? Probably not. We were asking users who were in our age range (18, 19) and they were at the very end of the ‘young adults’ spectrum. It was not a representative sample of our target audience. Secondly, the mobile app was a ‘jack of all trades, master of none’. There was no focus for the user – is it a food app, or a game app? The interface seems to be more like a game, but the food discovery element is mandatory for monetization. Back then, measuring what was healthy (without knowing what users ordered) was unmeasurable. But testing the prototype without the ‘healthy’ element to it, almost defeats the purpose. 

We were trying to do too many things, all at the same time. We wanted users to be able to have fun, enjoy deals around their vicinity, check out different restaurants, interact with their nomster, and worse of all – know and learn that they could do all of that! Trying to display and show everything were at the expense of everything. It diluted the focus of the application and made the team worked on everything (web portal to manage all the deals, the mini games, browsing through the list of merchants, the map function and the list goes on). 

Our attempt to monetize

We realized that the mini games were stealing a huge spotlight from the food discovery element of Nomster (our monetization channel). What was interesting was our users were spending alot of time playing the games, trying to beat the high score and they love it. But, they only visited the merchants if they won a free meal (yes! you can win a free meal by just playing our games) or a highly discounted meal (e.g. 1 for 1 deals for a high value meal, not just a drink).  That was a problem – to sustain, we need to start monetizing well. 

Apart from having native advertisements through mini games and avatars, we also updated the interface to improve on the redemption process. After a couple of times ‘mystery shopping’ and redeeming deals at random restuarants, we realized a couple things with the 4-pin code feature (though some other food application still uses it): 

  • It’s hard for service crews to remember 4-pin codes to so many different food app
  • F&B has a high turnover rates for service crew, that meant training and retraining staff to remember how to handle redemption methods across different mobile application
  • Easy to abuse the system. Once a user sees what the 4-pin code was, he could type it by himself the next time without spending.

Hence, we thought to ourselves: let’s keep things simple. You could only redeem when you are less than 0.3 or 0.4km from the restaurants, and you could only redeem once a day – but no 4-pin code required at all. This greatly reduces any change in operation in our partnering restaurants. 

We cleaned up the interface alittle to make it look slightly less game-y, and more food discovery. New features in the food discovery (such as discounts when dining with your friends or winning a Gachapon when you dine at a restaurant etc.) were introduced in an attempt to encourage users to visit merchants and redeem deals. We wanted to slowly change the focus back to the Nomster character and food discovery (and less on the mini games). 

What I realized…

Our users were still more intrigued with the mini-games, and our food discovery functions was not as comprehensive and appealing than major food application out there that had spent years building their database and functions. It was not easy converting our players to customers. If only we had tested early (like way, way earlier), if only we focus on being good on one thing, if only this and if only that. There was a potential for us to focus on what the players like – mini games – but being a purely games company was not what we wanted (gaming industry is highly competitive, difficult for retention and mostly dominated by large publishers). We could extend development longer and tide this through, but we knew it would meant a revamp of the mobile application and its direction. People heard about the things we did, saw our work, and web/mobile application development opportunities came pouring in. 

Before I talk about what happened next, I want to share some of the important lessons learnt. 

Lessons that will go a long way

In the development of the application, there were many things we could have done differently. But there 3 important lessons that I learnt, could make or break a product:

01. Start testing as early as possible (even during brainstorming or with paper prototypes)

This lesson held so dear to me that I went on to take a master’s degree to be specialized in it 😂 Have an early focus on your users and tasks. Fully engage with your users, such as engaging them in a design workshop, co-designing or participatory design. Until you have truly engaged and directly talked to your users, you don’t really know what they want or like. If we had talked to our users alot earlier, we might have rethink about our approach to gamify and to have food discovery as a core component of the app. We would have saved alot of time and resources. 

02. Less is more

We started with a simple goal of gamifying (healthy) food discovery, but as more users reacted to the game-y elements, we wanted to add in more features. Soon, our definition of alpha version became larger and larger – complicating the mobile app with unnecessary hurdles. Keep the product simple, direct and really-good-at-what-it-does, before thinking about other features/things. 

03. Find a good balance between familiarity & novelty

Users are comfortable with what is familiar. Our main button that shouts ‘Nom’, although stands out, does not really calls users to search for food around their vicinity, especially in a game-y interface. The food discovery elements of the application was displayed in an unfamiliar setting and it took some time for users to understand its function. Although the app tried to look fun and novel, it should look familiar especially for important CTAs. 

My takeaways in building a startup

Within the year, I have learnt so much more than I thought I would. To keep it brief, I would like to share 3 takeaways that I have learnt in this entrepreneurial journey. 

01. With more experience comes better decision making

Having more experience and exposure means knowing when and what to do to avoid potential pitfalls (such as the above). However, if a founder is young and inexperienced, the lack of experience could be alleviated with great vested mentorships as well.

02. Walk the journey with (better) others

Back then when I was still in college, it was difficult to find like-minded individuals who have technical experience and who is vested enough to commit and take a gap year (or semester) on this startup. I was the sole founder (with an amazing team) who has to raise funds, learn the in’s & out’s of product development, manage developers, do testings etc. Looking back, I would have spend that additional one or two months to look even further for great co-founders. Co-founders who have their skin in the game makes the journey less lonely and more informed. 

03. Unless you are an established company, your product should always (at least strive to) solve a problem

Although we started with a problem to solve – engaging people to discover and eat healthy food with gamification – it was not a very clear problem (or solution to be honest). We also pivoted towards the end as users were more captivated on the games, and ended becoming more of a lifestyle/entertainment app. Products that are ‘nice-to-haves’, instead of ‘must-haves’, have to compete with dozens of other established and better ‘nice-to-haves’. Strive to be a painkiller, and not a vitamin. 

Our lessons learnt was what made us valuable to our clients

Having heard and seen our work, other companies and startups began asking the Nomster team to help in product development and user experience design for their digital projects. Ranging from a simple e-commerce site to building mobile apps, the team eventually believed that a boutique digital agency would be more sustainable and better for growth in a long run. With what we learnt from Nomster, we started Nomster Media, under Nomster Technologies, helping others kickstart or improve their products. 

Leave a Reply

Your email address will not be published.

Skip to content