In this episode, we are interviewing Kirill Soloviev, founder of Nimi.
Nimi is a startup that helps people who are choosing a name for their company, product, or brand. It helps to stay away from poor name choices and avoid hurting their business.
Kirill will share some useful insights that could help non-technical founders: how to build your MVP without technical people and not to obsess with finding one.
There are many solutions which don’t need any knowledge about coding. They work out-of-the-box and you need to learn how to apply them to solve the customer problem.
You will end up focusing more on your customer without waiting for the engineering team. You will be able to communicate and inform the development team in a much better way when it is time to start coding.
Let’s deep dive in the interview.
From idea to execution
Tell us about yourself.
My name is Kirill Soloviev and I am the founder of Nimi. It is a startup that help you analyze your brand name for global fit.
I have a background software engineering even if that was more than 10 years ago. So, I am not an engineer by any means in the recent years. I am aware what engineers can do but I wrote my last line of code 10 years ago.
Even if you have a background in engineering, it is not always so easy to talk with developers. I still fail to do a good job to communicate the business part of the startup. It is difficult to do, that’s how life is. I will explain how it worked for me.
How did you start?
I started working on this idea quite for a long time (2015). It actually started when a startup was contacting me about a branding problem. They were from Russia and wanted to grow their startup in UK. They were unsure if the product name they’ve chosen was the right fit for that UK market.
After few weeks, a VP of marketing of another startup contacted me for the same exact issue. At that point, I almost made up my mind.
Two unconnected startups contacting me with the exact same problem. Lots of challenges for solving this problem but a clear opportunity.
This was the start for Nimi.
Moving to Estonia and the Hackathon
My wife and I have been moving to Estonia for 3-4 months. Exactly, in these months a 48-hours Hackathon was going to take place in their city.
There were 20 teams for a total of 150 people.
It was the perfect space for developing my idea from scratch in very short time and see if people would like it.
I pitched the idea and I’ve got a team that would work with me during the weekend. The team included 6 people: 3 engineers, 1 product manager (Kirill), 1 salesman and 1 person for UX / Design.
I had the pressure of showing his idea was valuable. It was a good motivator that helped the idea off the ground. On Sunday, we had our final deadline: demo day. All the teams would present their final accomplishments.
Looking for similar events around the world?
We had talked to all the teams and we needed a plan for succeeding on the final day. The jury wanted to see from all the teams a real working product.
We decided to split our team in two: the engineering team and the product team. The engineering team would continue building the Nimi Platform. The product team would focus on delivering immediate value to the other teams.
The engineering team used the first day for building the backbone of the real product. Yet, It was only the backend and they still had no screens that could show to us after one entire day.
Meanwhile, the product team was talking to the other teams. We were trying to understand how Nimi team could help them even before writing a single line of code. Many people actually experienced a sort of problem when choosing a name for their teams.
We started immediately bringing value to the teams using already available online services.
We used something called Google Forms for creating surveys. We get useful insights from our customers and users. It is free and part of the Google product suite.
Google Forms also collect the responses and visualize the results in a very nice manner.
Are you not enjoying making a form with Google Forms? Here 5 alternatives that could be useful:
We designed a simple survey and we were used any messaging apps for sharing it. We were shared it with people that could give us good insights about a given brand name in their country.
We had our minimum viable product (MVP) for learning how people reacted when faced to a business name. It didn’t cost anything and required zero lines of code to operate.
“Don’t wait the engineering team for the perfect platform but start immediately bringing value to the customers. Plus, use the tools already available for building your MVP.”
Sunday arrived and demo day would start around 4:30 P.M. We were 4th in the presentation list.
One small problem: it was already 4 P.M. and the engineering team was not done yet. The engineering guys still did not have anything to show of what they have built. They built some of the components like gathering data and placing an order in the system. Yet, one component was missing: showing the results from the surveys. It was an important part of our system because it would show the real value of the product.
It was a clear failure in communication between the product team and the engineering team.
As you can imagine, I was pretty frustrated. The most important component was not there. It was important for showing why we built this startup in the first place.
Well, we went with plan B: fake it until you make it. We took the results that were stored from Google Forms and screenshot the report page.
We put this image in the missing report view built from the engineering team. The product was only 60% ready but it could actually show how the solution would work.
The jury could see that we actually built and delivered real value to our customers. Even if the most important part of the software did not work, we managed to find a workaround. We satisfied all the requirements from the hackathon and show some end results.
After the hackathon
After the hackathon, I talked to the team. The engineering team was not going to continue working on this idea. They would not focus on my idea over their ideas or jobs. If I was relying on their code, it was going to be bad for my startup.
I would have a bunch of code, and zero people that actually know how it works. Very little possibility of building it further.
During the hackathon, you have very little time and engineers do not have much time to do things in the right way. In short, it means that you will often end up with crappy code.
At the end, I throw it away!
Zero code mentality
You should switch to a zero code mentality: use the tools available and you can go pretty far with that.
We still work with many of these available tools. We use them in a very manual way. At the moment, we focus more on having a better understanding of the actual customer’s problems.
Our need for building a custom technology is still far far away in the future. Software development is a huge and intensive job. Code can break. People make mistakes all the time. There are always delays on deadlines because of the software part being not ready.
It can be a huge pain from the business perspective of a former technical guy. A startup should be much leaner if they can afford to go without customer code for as long as possible.
Interesting online services that do not need any coding skills
What are your takeaways from this experience?
Some key takeaways:
Don’t obsess with the solution. Obsess with the customer’s point of view of the problem. How far can you go in a pure manual way delivering value to the customer, before writing a single line of code. This is a mentality that startups could benefit from.
People obsess with “omg, I don’t know how to code”, “ I need to find an engineering partner”. There are many solutions that don’t need you to know how to code.
They work out-of-the-box. Learn how to apply these tools to solve your customer’s problem.
Being a technical founder, you don’t have to build everything from scratch. It is about reducing the amount of code that you write. Engineers love to code and they would always be ready to open their editor and start coding. But, you hire them to develop solutions and not being code monkeys! You hire them to bring value to the company.
Exactly, it is actually a good point. Unfortunately, not every engineer would agree with that. Less code, being efficient and understanding that writing code is not the only way.
What is your current tech stack? We use several tools in our current stack like Tilda, Typeform, Paypal, Zapier and much more.
The website is the first touch point for our customer. I built it using Tilda.
This tool helps you to build a website with zero lines of code involved in a very short amount of time. It took us only a couple of hours to build the landing page.
It also did not cost anything for few weeks. We updated to the paid plan because we needed to attach our domain. It integrates very well with other tools that we are using in our current stack like Typeform and Paypal.
There are many alternatives to Tilda for building your site.
Here’s the list:
We use Typeform to actually gather the intelligence from our customers. I could not recommend enough. It is a beautiful way to capture any kind of information from the users.
It turns something boring like surveys into something a bit more exciting.
For us, a survey is something that we use to gather intelligence. Typeform gives us a better completion rate with respect to using Google Forms. Customers and users love them. We are using a Basic plan and paying very little for it.
For the visualization tool, we use a tool called Infogram. It is an online tool for infographics and it is very good for building visual reports.
It helps you to gather data from some external services (e.g. Typeform). Export them to an excel file and importing it to Infogram.
Infogram updates data in real time. If you want to change any of your data, change them and your customer can refresh the report in real time. Very useful and much better than sending many pdf around. It is a real time saver. Any modification to the layout and the data will be updated automatically; we do not need to email again the customer.
Typeform and Infogram are the core of our application.
How do we get paid? We use PayPal!
We send the customer a link from PayPal. You can define in the link itself how much money the customer has to pay (e.g. 50euro, 200 euro, …) and that’s it.
No code, we needed a PayPal account and with few clicks we got our payment in our account.
Another tool that we are using is Zapier. It is very useful. For not technical guys, it is like glue between different applications online. We are using Zapier for automating notifications. For example, when a customer place an order
Zapier talks to Typeform, and if anything happens in there it will push a message to our Slack channel.
Slack is our information hub! We do all our communication between team members there.
This is our flow for getting a payment from our customer. The customer arrives at the website (Tilda) and fills the integrated form (Typeform).
They enter their details:
- the country that they want to launch
- other general information about the customer.
When the customer submits the form, we get a notification through Zapier on our Slack channel.
At the same time, we will send a link to the user for the PayPal payment. The user will add their credit card information and we will get the money.
Afterward, we use the email to contact the customer back.
What is important for us is to be able to shut down a tool and use any other tool at any time.
The most important part is that we found a real problem and how to solve it with little technology involved. We were immediately able to deliver value to our customer.
Start with a problem first. When you start designing a solution, try to think in a way that actually needs zero coding.
Can you be the one pulling all the strings behind the scene? Can you be the one answering the phone or typing in a chat window? Can you build a solution that works for the customer without writing any custom code?
The challenge with code is that it is hard to produce. It needs high qualified people, it is hard to maintain and it is difficult to change.
At the beginning of a startup you have many things that are not defined. You might not know the complete customer problem. Or, how much profit the startup could make, etc…
Trying to write code at this stage could be a very bad idea. There is a chance that you will throw it away in few weeks or months because you will discover that you did it wrong.
Then, you will need to start from scratch. Our code did not work but we found a workaround to that. What I am trying to say is try to do as much as you can before starting building custom software.
Even a technical founder would benefit a lot from this mindset in the beginning.
Want to know more about Nimi? Check their site at nimi.io