Hello developers!
Let me first ask, are there any Douglas Adams fans out there? It's OK if you aren't. Those who are will hopefully appreciate the reference. RESTaurant at the ENDPOINT of the Universe being a direct reference to the novel of the late and great Douglas Adams. I know, I know... it's not much of a joke if you have to explain it. However, I am not here to tell you jokes. This is kind of serious. OK!?
For those who would like to learn more about APIs, what is REST and what are Endpoints, have a look here.
1st Step Towards Building a Unicorn
I wish the 1st step toward building a Unicorn was so simple as having money to buy a horse and some carrots. It's not, unfortunately. Here's a word that has been overused in the last couple of years and is being pushed down our throats by many of the biggest tech and business influencers. It is good to be aware of it and to know how it works and impacts you and your business. However, when you overuse it people tend to go deaf when they hear it. My mind just goes: "Oh jeez, here we go again with this $&!?#". Sorry, you had to read that.
OK, so what is this word Davor!?!? - Ready? It's empathy!
Have empathy for your customer!
Have empathy for your employee!
Have empathy for your colleague!
I rarely see people say: "Have empathy for yourself"! The importance of it is in my opinion very underrated. It's not all about keeping a sane mind. It is a part of it. However, when you are put to the test and things are not working out as planned, don't shut down. Yell if you must. Get it out of your system (just don't yell at somebody living - keep yourself in check). After that, LEARN! Understand where you made a mistake. Understand how you and your team (if you have one) can improve. But be HONEST about it. If you screwed up - well, own it. I am not saying you should beat yourself up about it, just be aware of it. You are permitted to be mad at yourself for a minute or two, then get over it and push on.
I am not too smug to say this is the only way, but I am 100% sure it is a good way, an honest one, to make and build up an awesome product - maybe even a game-changer, a Unicorn if you will. So, I guess what I'm also saying is to try and not be delusional. Believe in your product and in yourself. Just do not ignore the facts when they smack you in the face. Having empathy for yourself doesn't mean you need to lie to yourself to make yourself feel better. On the contrary, it means being honest with yourself and having the courage to deal with the obstacles in front of you, instead of ignoring them.
Made by X for X (Made by Developers for Developers)
Many successful products are made by people that had some kind of a problem. They fixed the problem for themselves, and then they fixed it for everybody else who had the same problem. I work in a SaaS startup, so my brain immediately goes to developers, but this can be true for any industry. Our product, Treblle, is exactly that. It is made by developers for developers. Before launching it, Vedran, Darko and Tea had a development agency. They were working with APIs a lot. When you are working with APIs a lot there is a plethora of things that can go wrong and a lot of things you have to be mindful of. Writing documentation, retracing user steps to see how something went wrong, having daily meetings with various CEOs, CTOs, developers and the like.
...the problem was spending too much of their time and energy...
So the problem was spending too much of their time and energy on things that had almost nothing to do with developing (administration, meetings, tracking down errors that aren't in the code...). Let's look at the "human" side of the problem and you will quickly see what's the deeper motivation they came up with.
Let's start simple. Humans like to be happy, we can all agree on that. So, if you are spending long hours on side tasks and meetings, that means:
- You are never home on time
- You are constantly on-call for every possible problem
- Your vacations are spent looking at the phone stressing out if it will ring
- That's when you empathize with yourself. That's when you say, "Okay, enough of this! We need to fix this!"
And that's exactly what my team did. They fixed it. At first, it was only for themselves. After a while, they realized that their lives got better - which is the point if we are being honest. That's when they realized they might be onto something.
There are a couple of boxes that need to be checked before you decide to share your "discovery". The most important one is probably: is the problem you solved for yourself a specific problem that only you and a few others have, or is the problem much bigger and is happening to developers everywhere.
They did their research quietly and shared Treblle with some of their partners and colleagues around the World (you get to have connections when you are 10 years in the industry).
...the results were surprisingly good!
The results were more than they expected, the results were surprisingly good! Not that it only helps developers, it actually has wider uses. Non-technical staff could now understand what was happening in the app since it has a really easy-to-understand analytics dashboard. It was only one tool that is doing the job of 3 (in some cases even 10, depending on how you are building and maintaining your APIs).
NEXT STEPS - The Sales Point of View
From a sales point of view, CEOs of big companies want to know "numbers". How much time does it save? How much money? How long does it take to do onboarding?
Honestly, this is super hard to determine at this point so we went with
While this number is probably just the minimum of time that can be saved. It is a bit tricky to calculate. If you are a developer, try asking yourself questions like
- How much time do I spend not developing?
- How many meetings do I have to sit through?
- How long do I have to wait for other team members to resolve an issue?
We can't calculate that. What we can say is that our developers have maybe (if any) one meeting a month. And those meetings usually aren't to talk about issues. Those are being resolved practically in real-time.
no retracing steps and calling the user...
The other time-consuming thing is writing documentation. How long does that usually take? With Treblle - it doesn't take any time since it auto-generates docs for you. What if there's a problem - let's say for some reason a user can not log into an app. We have a use case describing a similar problem (link). So, it turns out your code is fine, something else is the issue. Treblle can track that down and show you how the user is interacting with your API. So, no retracing steps and calling the user to try and remember what they did. You can easily search for the API call in question, and test it with 1 click.
There are many more uses and features of Treblle (they are all free in every of our plans btw.). These were all born out of being aware of "how can I help myself be better", which in time turned into "now we can help you be better as well".
Are you also looking on ways to solve a problem you are having? I would love to hear from your experience! My advice would be, stay the course, don't give up and keep solving it for yourself until you feel the time has arrived to share your solution with the world.
We did. That was the easy part. We are now in the "yelling and scratching, notice us, we can help" phase. Wish us luck!
