Developing a new software product in just 6 months
Developing new products is a challenging job. Most of the times there isn’t a clear path to success. Product development teams deal with dilemmas all along their way to release. One of them is when to launch and what features the first version should include. The Lean approach tells us to release fast with the minimum features covering the basic needs of the customer, get feedback and make the product better. Still, it’s not easy to decide which features are these and the most important what to do if they need much more time that you have or want. The product development journey I describe below taught me that there are other ways to answer to these questions if you try to think out of the box.
To give some context, I work for Cytech and we develop a SaaS platform for companies in the Telecoms sector. More specifically our customers are active in the mobile messaging, marketing and payment sectors. It’s a cloud based product we continuously evolve the last 10 years with customers all over the world. You can find more information on our website but this is not really the reason I decided to write this article.
The main reason behind it, is to describe how we managed to launch a new product that is very related to our platform but it is also a standalone software. The important thing about it, is that we managed to have a time-to-market that was less than 6 months. To give some context, in the past, in order to do something similar it used to take us more than a year. Most of the times double this time.
Following the Design Thinking process, we tried to define the problem to be solved by talking to our customers and presenting the initial idea.
The brief version of the idea is that “high volume mobile messaging, marketing and payments businesses need better search, monitoring, reporting and alerting solutions”
So we understood that there is an opportunity to develop a software tool that can cover this business need. Our market research showed that although our competitors try to solve these problems on their own, there isn’t any tool that does it fast, efficiently and with a user-friendly way.
I make a break here and I’ll describe how we failed to solve this problem in the past. As all our competitors did, we also tried different solutions during all these years. The first one was to offer the reporting and alerting inside the messaging suite. It worked but only for low volume traffic as it competed for resources with the main job of the platform which is to route and serve SMS and other messages. The second attempt was to use a lightweight library that can render the charts with less resources. Still, it proved not a scalable solution. The result was that we were limiting the number of messages a table can display or the report can have so we don’t disrupt the normal operation of the platform. The third attempt came after we moved to the Amazon Cloud. We have resources and we could elastically alter them for each of our customers. But as the bottleneck still was the database it didn’t really make any sense to use vast amount of memory just for a few minutes during the report generation. The last attempt that worked well till now was to have a read-only replica of the database that is used only for reporting and that didn’t interfere with the other operations of the platform. But still, although it is a good solution, it’s expensive to maintain and extend and not designed for free-text search. It’s also not suitable for monitoring. That’s why we looked for something that can cover all the aspects of our customers’ needs: search, reporting, monitoring and alerting.
Back to the new product development…
It took us one month to get the initial feedback from our existing customers. We met them in person in international events of the mobile industry. We also organized an event in our headquarters and invited customers from Europe and Asia. It was a nice surprise for them by the way to come to a sunny and friendly place with unique cuisine like Crete, Greece. We presented all the new upcoming features of our product and we also trained them how to use the platform better for their business. During this one week long event we made some presentations about the need of a Business Intelligence tool for the messaging and marketing industry and starting demoing our solution. The first reaction was a bit awkward. They couldn’t understand how this fit to our suite. They didn’t expect to get a reporting and analytics tool from us. After the first shock they started to propose things and how it could be helpful for them. It’s all we needed. It went really well and it validated our belief that there is business value in such a tool. We also managed to create a value based hierarchy about the features. What really matters and what not for each one of them.
After one more month of ideation and discussions on the feasibility in terms of technical and financial effort we had in paper what and how to develop our first prototype. Here is the main difference from all the other products we have developed so far.
We are very keen on building new things. We love to start from scratch and create something from nothing.
I have to admit that it was tempting to do it again then but no, this time it wasn’t the right way to go.
We searched for alternatives: tools or components that can work with our existing technology and solve the main business problems I mentioned earlier. At some point we reached the work Elastic does with Elasticsearch, Kibana and the other tools they develop.
It was love at first sight.
Not only because we were in front of a beautiful technology but also because it was the perfect match for our case. It was built for Search that it’s one of our main needs. We need to search into vast amount of messages to extract information. In addition, Kibana was good looking — maybe not so good looking as it is today — and configurable so we can create beautiful charts and visualizations. Reporting was at its first steps but we knew reading Elastic’s announcements that it will follow. And alerting was also possible.
There were other reasons we loved Elastic as well, it was open-source, backed by a technically strong company which was growing really fast. So we were confident that we can invest our time and money basing our new product on their technology.
We are about 4 months after the inception of the initial idea and not really far from implementing a prototype. The hardest part was to make our platform, mCore, to send the right data in the right format to Elastic Search. We worked on it for some time trying to get as much information as possible from the database. So we started populate our new database with messaging data fast. Next step, to create valuable visualizations for our customers so they can get answers for their everyday questions like how many messages were delivered? Through what gateway? To what network? What is the fail ratio? etc. That took us some time as we had to overcome the learning curve of a new technology but we create our 4 demo dashboards in less that 3 weeks time.
In the meantime, we continuously evolved the integration with our platform both in the application and the infrastructure level. Not an easy job to do but in the end we had a new software tool that was loosely coupled with our platform so it can also be presented in the market as a standalone Business Intelligence and Analytics tool for the mobile messaging business.
The big day had come. We were almost 6 moths after we started talking about mCore Dashboards — this is the name of the product now — and we were ready to demo it to our first customers. The early adopters first. We were exhibiting at the Mobile World Congress 2018 and it was the right place to meet them and get their feedback. It was one of the most weird experiences for our team. We were thrilled we would show our 6 months work and at the same time we were nervous about their reaction. Finally, it was an amazing success.
You understand that you developed something valuable when the customer starts to think ways to use your product without waiting from you to suggest them.
I remember we were presenting in a small meeting room to a couple of guys from Kuwait and we didn’t manage to tell a thing. They started discussing between them how they can exploit all these data and charts and reports etc. How they can make more money if they sell a new service to their customers and what kind of extensions would be nice to have. This was the point I felt that we have made the right decision to choose Elastic as our base technology and to bring a new product to market fast.
OK that was an interesting story one might say but what is the meaning of all these. I know many teams that work on many valuable and interesting products but they constantly feel that something went wrong and they didn’t get the success they deserve.
One of the reasons is that we spend much time in designing and building stuff and less in getting feedback. We spend much time on implementation and we don’t take advantage of technologies and frameworks that are ready out there.
Product development is not only about nice processes and innovative ideas but also about smart choices in terms of technology, features prioritization and ways to get feedback from the customers. Our choice to go with an existing open-source technology, to develop and present only a subset of the features and to invite our customers to visit us and get their feedback made the difference. We delivered our MVP (minimum viable product) in 6 months with the right features and we are running the next iteration.
The next day for mCore Dashboards includes many amazing new features that have business value as traffic behavior forecasting, machine learning and even more beautiful reports. We are currently validating them with our potential customers so we set the priorities right.
Our vision is to develop a Business Intelligence tool for the whole mobile messaging industry capable of digesting data from different platform even our competitors’ software.