Let’s Ask Jose - Q & A with Navgar Founder Jose Brotons
In our second installment, we pick the conversation back up with Navgar founder Jose Brotons and get his impressions on challenges and what success looks like for his new startup.
MT: Can you tell us about a time when you faced a significant challenge while building your company, and how did you overcome it?
JB: Although the company is young, being a startup it feels like there are constant fires to put out. One of the ones that caught us by surprise (as it did many) was the war in Russia. We were in the process of signing on a development team (we were in the contract phase) based out of Bielorussia when the war erupted. Seeing the turmoil, sanctions and talent migrations that happened immediately after that meant that we had to scrap that entire plan and build our own internal team. I am very happy that we did so, but at the time it was a severe blow as it delayed proper product development by a couple of months - which in a start-up feels like a whole lifetime.
MT: What do you think is the key to your company's success, and how do you maintain that success?
JB: It is too early to talk about success per se. What we have seen is a lot of keen interest in the product indicating that we may be close to Product / Market fit. We have had to work really hard to get to this point as the product offering morphed substantially even in the exploratory phases.
I set off with a very clear objective - to make flows an integral part of any business. I had seen their impact and I knew what they could bring to the table. Therefore my focus was on that specific problem. But was this something that other people felt or even understood?
At Product Madness we literally had millions of users. There I learnt that my hunches were not always right - actually more often than not they were wrong. I had played with Human Centered Design and thought that it could be a useful tool. Therefore I jumped into the deep end and took a “Mastering a Design Thinking” course at MIT which fundamentally changed my perspective on the product - so much so that I have had my head of Product take the same course.
Our analysis ended up becoming a document of hypotheses which guide what we do everyday. One surprising realization was that we were not solving flows - we were solving communication, in a structured way, but nonetheless communication. I have come to realize that Operations and Communication are intertwined and that the quality of the operations of any company is often a reflection of the effectiveness of its internal communications.
Team members want to do their work and they want to do it well. However when communication fails often people are not even aware that something needs to get done. So suddenly Navgar was not about Flows, it was about communication.
We also realized that even though Flows could have a major impact in the day to day operations of a company, the current implementations required additional effort on the side of team members. Effort for which often there was no perceived value on an individual level and people already have sufficient workloads to not want to do tasks for the sake of tasks or for the sake of reporting. This is the reason why many tools out there fail to gain traction within the organizations where they are implemented.
Through all of this exploration we learnt that if Navgar was going to enable flows in organizations it meant that:
Navgar was really a communication tool
As a communication tool, it needed to be used by as many people as possible. The overall value obtained from any communication tool is proportional to the size of the pool of users and how often the tool is used.
This meant that it needed to be relevant to everyone in the same team. This is a very difficult design challenge since in this case adoption had to be really high within a very specific user group - the company. It could not be a design that appealed only to very specific users dispersed within the general population which could be located through ad-money spend - something that is often done in games.
Flows - although a main driver for the potential outcome for the business had to be non-intrusive and extremely easy to set up and use. They were no longer about the when and what tasks of everyone involved, but also about the team communication and how it helped the team to achieve the Flow’s final goal.
By focusing on these hypotheses and realizations we have been able to create a product that seems really compelling and which companies are actively testing without us having to do much effort to get them to do so. Some have even reported back that the system has completely changed how they operate and that they are starting to see increases in revenues which is really satisfying. Our idea is to continue refining and working on our hypotheses and to implement HCD as a live practice within our day to day operations.
