When to Stop Coding, Start Testing, and Get Your Product to Market: With Stas Nikiforov- Bite


Bitekiosk.com builds self service kiosks for quick service and hospitality companies. The benefit of these particular kiosks is that they have a personalization aspect. The kiosk can recognize each guest that uses the machine and will provide personalized recommendations. Stas Nikiforov heads up the technical operations.

How to Test Before You Fully Build

Starting off, Bite Kiosk wanted to target retail, hotel and hospitality companies. They had no idea if their product would work or if people would be interested in it. So they didn’t want to spend all their time creating the full app with the chance of no one wanting the product. Instead, they created a bottom line product. They developed a few hypotheses to test. Basically they built the shell of the product to see if people were even interested in seeing more of it.

The app was built pretty superficially. There were a few exceptions to the lean build, for instance, payments were something the users needed to see. But as long as the UI worked, the app worked for the purpose of testing. And the UI didn’t need to be scalable, it just needed to work once and then they could reset and restart for each user. That saved a large amount of time and effort. In the words of Stas, “you just build a kind of scaffold, throw a drape on it, and see if it sticks.”

At the International Restaurant and Foodservice trade show, Bite Kiosk put their baseline product to the test. They received a generous amount of feedback from users. What features would be useful to add, what would not be useful, and if users would be interested in having the product in their stores. What Bite Kiosk realized after taking the product to multiple trade shows was that they could personalize the kiosk depending on the customer.

Aim to sell the promise of the product, the vision. It typically takes about two months to actually complete a deal with a client. So during that time, work on building the app out. Lucky for Bite Kiosk, the menu part of the app is built with HTML. So building out features takes very little time.

Creating the Habit of Testing

To make sure they had a something to show for themselves, Bite Kiosk gave themselves a deadline by booking a trade show date. That meant they HAD to have something working by that particular date. If they only had three weeks, they needed to create something in those three weeks that worked and also looked like it could be tested. That meant letting go of features that would take months to build. Instead they needed to focus on features that they could build in a short amount of time and would still show the functionality of the app.

Learning to leave your OCD at the door is crucial to this process. Most software engineers are perfectionists. “We like things to be aligned, variables to be named properly” says Stas. It becomes a push-pull with this method of testing. You’re having to build this one-time use, potentially throw away product as opposed to working on something that is crisply built. So a deadline is key to mastering this. Because that forces you to give up the time to make the app look pretty and be a well oiled machine. Instead you have to throw some things together and just make the app function. That way you can spend time on the correct bells and whistles later on.

It’s also helpful to lay out  a mental framework for yourself. Make notes on where you cut some corners to create the test version of the app. That way you can come back and perfect  or fix what was missed once you know the app is worthwhile.

Also, having a calendar for yourself with deadlines is crucial. This will help you keep track of where you’re at and if you’re spending too much time on particular areas.

Sometimes Blood, Sweat and Tears in a Feature Doesn’t Equal Success

Stas started his career at Hulu in LA. Often, Stas and his Hulu team, would develop an enormous amount of resources and spend a lot of time planning out certain features. Later they would realize that these particular features were not very useful. For instance, Stas worked on a heat map for Hulu. It mapped out certain parts of each episode that were particularly popular. It was a significant engineering undertaking to index the parts of episodes people watched the most. He had to record where users dropped off in each episode, as well as when viewership increased. Stas and his team quickly learned that the heat map was only used by viewers to find some sort of nudity or sexual content in TV episodes. It was a month and half worth of work just for a result that brought no value.

How does Stas combat creating valueless features now? It’s hard to do. “I have a hunch I suppose” claims Stas. “But I can’t solely rely on that.” At Bite Kiosk, they are noticing the huge trend of calorie counting. So they developed a feature to display the calorie count on menu screens for each menu item. But they have found that some restaurants want to portray being healthy, even though they actually are not calorie wise. This taught Stas that his hunches should always be verified. It’s best to consistently run features by a few users. People are always open to give feedback because it’s in their interest to have an efficiently working product.

The Best Way to Test

Get the product into the hands of customers and have them give feedback. Hit your demographic. Testing with customers will teach you so much more than running tests with yourself or employees. If you run tests on yourself you inevitably fall into patterns and you just don’t touch the screen the same way as a customer.

For Bite Kiosk, they don’t quite have a particular demographic because everyone goes to fast food restaurants. So they installed the application and sat there for a day to see how people reacted. They installed a kiosk at a Casino in Connecticut to run some tests, and then just sat there to answer questions. Customers would come up to the kiosk, play around with it, ask questions, and provide feedback. And even just being able to physically see how people use the machine provided a massive amount of necessary information.

You’re Done Coding and Testing, Now What?

In order for the product to go to market, you obviously need someone to buy it. Some companies are tempted to offer the product for free for a period of time just to get the word out there. This method can actually make users more suspicious. Trade shows have given Stas and the Bite Kiosk team the most promising leads. That and simply installing the kiosk in restaurants for a trial period.

The best way, according to Stas, to get your product to market, is to find who your target audience is and then approach about 100 different possible users. Trade shows is one way to do this. Another route that Stas took was to contact people on LinkedIn. He would tell them about the product and ask if they would be interested in testing the product out and giving feedback. Most people said yes and later on became customers. Once a few customers were interested in the product, it gave Bite Kiosk the opportunity to test when customers started to drop off from the app, and why.

Instituting Tweaks to a Launched Product

Stas tries to attach tweaks to metrics. He and his team will do weekly experiments to compare the current week to the ones before. The nice thing about working on a product for restaurants, is that you can test the use in each restaurant against each other. They can make tweaks to certain features and have that update be available in some restaurants but not others in order to test it’s value.

Once you quantify the value of certain tweaks, you wean yourself off the idea of having to constantly perfect certain features. But again, giving yourself permission to move on is always key. Don’t get lost in perfecting, focus on building an app that works and provides value.


Sarah Shook

Sarah's a professional and creative writer with experience in marketing, film production, and research.