Ikenna Paschal, founder of ditData - a unified data intelligence platform for teams.
That is really an interesting question considering how much that has contributed to my personal journey. Well, I spent the last two years building data infrastructures for businesses. For the most part it was the execution part. You know, right after they have done some consulting and told what to do by the experts.
So what we did was basically just code, deploy and disappear. Most customers might need help with constant maintenance but it was rarely the case we were contacted.
This experience actually clouded my judgement of what the problem was. I felt it was with the technical complexity of development, deployment and management. While this is true, it does leave the whole picture behind.
It is actually interesting how the real problem could be lost in the sight of a much more attractive problem. We started out to build a solution that automates the process. Our early product page also focused on selling this. It would turn out we werenât entirely wrong, we just werenât right.
That was actually how the idea was conceived and the product started.
As mentioned, the journey so far hasnât been easy - it wasnât meant to be. We have had to throw away weeks of work because we missed the point of what exactly the customers need. Class amateur move.
Well, after we launched the initial product which was simply an easier way to automate the âbig dataâ infrastructures. Some users did check out the product, they werenât impressed. I actually got roasted on a slack group for it. Not that they thought the idea wasnât good. Not at all, on the contrary, they were eager to test it out to see how it works.
They felt we missed critical things in the early release, and the overall product performance wasnât great. I knew this by the way. I guess I took the startup advice of âlaunch a shitty product as fast as you canâ more seriously than I should have.
Nevertheless, after the failed launch and subsequent roast, most users were willing to provide constructive feedback on the product. And hey, one even paid for the product.
Using the customer feedback, we would try to connect the dots between the problem the infrastructures we built for businesses initially solve, what the few who stuck with the product actually used it for and who will most likely need our solution.
We found that we need to look beyond the tech, the exciting part for me actually, to the problem. We need to architect for the problem we have confirmed exists. So we took weeks to develop a new version of the product, one that solves 3 major hurdles for organizations - cut cost, hire less and innovate faster.
To do this we have to solve the first problem of decentralizing intelligence in organizations within the team level, not make the tools that solve the problem cool.
Glad you asked. The short answer is âsalesâ. I understand that sales might not be this hard for some professionals but coming from the developer side, it is nearly a hard nut to crack.
I think also my personality plays a part in affecting what my experience has been so far. I tend to look more towards just sitting alone and writing codes and if any communication is required, we can just use slack to do so. That has changed, tremendously. Now, not only do I have to go out there to look for customers, I actively have to talk to them every step of the way, be there if they ever need any help. Hasnât been easy but I love that the impact is directly measurable.
Still struggle with it to this moment hence we are actively seeking for a cofounder with experience in sales. Regardless, I hope to continue doing sales, learning more about the customers and getting direct feedback from them.
I do work most of the time on this. Interestingly enough, it is hard to put a number on the average number of hours per day. But considering I only take bathroom, sleep and launch break, I think it is safe to say around 12 - 16 hours per day.
Usually, the day starts off with checking the sales channels I have set up. Then follows the traditional checking of emails and support tickets. This could be 2 am, it could also be 10 am.
As banal as that might seem, the biggest success has been transition from product driven development, or rather a solution driven development to understanding the need to take every action, towards solving the problem we identified not the other way around.
We started out with cold reach out, being amateur, we made mistakes but we have learnt a lot. Now, the acquisition isnât just pulsating unsolicited emails. We now understand the concept of sales channels and how to harness them for growth. So from facebook, through twitter to saashub, everything is an opportunity to interact with the individuals running businesses, teams that build the world.
The initial launch was a PH launch, it failed miserably. At least according to our expectations, it did fail. Knowing what I know now, I think I will probably still make the same mistake if all the conditions are equally constant.
Now, we try to have a smarter approach to launch. Which is to always launch. I have redefined launch to mean every chance of talking to someone about our product, every release, product update. Not sure if this will help anyone else but it helps me to adapt a behavior that allows increase in customer contact.
Yes, we used PH for the initial launch. As mentioned initially, it was a botched launch but the lingering lessons was one we needed badly at that moment.
Freemium, a majority of our users are on the free tier. This makes sense considering what our long term product goals are. We hope to work on conversion rates but that remains a growth crusade weâll plan for.
The biggest challenge has always been building something that customers will love. As simple as that might seem it is pretty hard to get right. We have gone back to the planning table multiple times, discarded codes we wrote and changed things constantly. Not easy but something we are glad to see have a measurable impact on the overall business goals.
With time, we hope to grow our user base to at least 400 paying teams in the coming years. And our revenue to a 30K MRR.
Currently we rely solely on founder to founder introduction. You know, on connecting with communities that might find our product useful in meaningful ways without being the spam guy or sending unsolicited messages. I think founders are uniquely immuned to unsolicited sales messages.
I contact the users by email. Being B2B, most founders are always willing and open to tell you the hard truth about the product.
Along with a sense of purpose, starting ditData.com has provided us with a chance to make something people love. You know, something that stands a chance at actively competing.
AWS primarily because we are familiar with the ecosystem.
Brian Chesky - Airbnb.
Masters of scale by Reid Hoffman, founder of Linkedin. Although his approach is geared towards mass B2C products, it nevertheless does have important life lessons that anyone regardless of industry will find interesting and helpful.
My first exposure to the podcast has been from a mentor, Todd. I took the initiative I checked it out. I have never regretted it.
Just get started already, stop aspiring to. You might be wrong but you will learn and make changes.
Related Interviews