The 5 biggest mistakes our startup has made
If you go through life without having ever made a mistake then you’ve never taken a risk. If you’ve made mistakes but you’ve not learned from them then you’re a fool.
At RealtimeCRM we’ve learned a lot since we began. We’ve made some good decisions and some bad ones, especially in the beginning.
Like all businesses it’s easy to set goals but easier still to get distracted from them. There’s always something that seems to take priority and you kick the can down the road.
1) Putting enough time into RealtimeCRM
Our beginnings were as a software consultancy. It paid the bills and we did really well at it so it was difficult at first to transition towards product development.
We were going to create RealtimeCRM and fund its development with the income generated from the consultancy side of the business, the problem was in the beginning when you’ve got clients on the phone with deadlines coming up - you prioritise them but we weren’t just giving too little time to RealtimeCRM, we weren’t giving any time to it. Each time we’d say “this is buying us some future development time for our product” but guess what? It never happened as there’d always be another urgent thing in the way.
In the beginning RealtimeCRM was more an idea, an aspiration than a reality - the only time spent on it were in off hours because someone decided to throw some time into it and so progress was cripplingly slow. It was a side project rather than a serious endeavour and we wasted a lot of time not sticking to our convictions and acting on the decision we had made to move over to products.
We got out of this by treating RealtimeCRM like a client. That way it wasn’t pushed down the priority list every time some new paying work came up. At some point you have to put aside the distractions and focus on achieving the goals you’ve set yourself, and the only way to make real progress is to work on those goals consistently over time
2) Not thinking about marketing early enough
This was a really big mistake. We had a blog for a long time but really there was nothing going on, so it was an asset that wasn’t doing anything for us.
In our minds we thought if we built the best product possible that it would sell itself - it comes back to the whole if a tree falls in a forest does it make a sound if there’s no one there to hear it?
You can argue about that question but you can’t argue against the fact that if nobody knows about you no one will buy from you.
Our focus was on adding cool features that we thought would be useful and amazing. We were making RealtimeCRM better, meanwhile our blog was by comparison terrible. I don’t think we even talked about the product but about CRMs generally, we posted infrequently and we didn’t even have a mailing list to keep in touch with visitors.
We’ve fixed that and we’ve doubled down on content marketing. Including guest posting. We’ve seen traffic to our site skyrocket, our conversion rate increase and we have a growing community of readers to talk about RealtimeCRM with. There’s a lot more we can and want to do, but like development work what counts is consistent effort over time.
We didn’t have any of this before, it won’t sell itself - you have to do it.
3) We can do everything even if you don’t want it
Just because you can do something doesn’t mean you should. In software you can be a wizard and do amazing things, some of them are really dumb but they’re so dumb they seem kind of smart.
For example, in the very early days of RealtimeCRM due to a miscommunication one of our devs built local custom fields. These are custom fields that apply only to the record they were created inside. It was a mistake but we kept it because we thought ‘hey nobody else is doing this and it’s kind of cool, let’s keep it’.
So we did, we even made a big noise about it amongst our users. The problem was they were kind of useless because since they’re tied to a single record they’re not searchable unlike normal custom fields which are applied to all records of a certain type, say contact records.
Plus it added another level of complexity to RealtimeCRM for the user and for us, it increased our code debt making maintaining and updating RealtimeCRM over time more difficult.
Therefore we added this new thing which really wasn’t all that useful because it was difficult to access the information it stored, and it turned out no one used it except us.
That’s right we were the only ones who used it, we found that out when we came to the decision of removing them and checked the database to make sure we wouldn’t hurt anyone who had been using them.
Do you know why we used them? Because we built them and felt like we had to justify them by using them. A really dumb mistake.
4) Learning to say no
Another mistake we made in the early days was to not say no. If a user suggested a feature we really bent over backwards to get it into RealtimeCRM.
We were not confident enough to say no because we didn’t want to lose the user and were not yet clued into what feedback is useful and will improve the product, and what is so parochial to that specific user that it really only applies to them.
You have to have an overarching goal, a job that you want your product to do well. If the suggestion doesn’t fit into that goal it probably isn’t relevant to you.
But we were young and really wanted to please everyone, and in that way you don’t really please anyone. So we’ll throw an example at you. A user suggested product bundles, we implemented it expecting it would do well but it didn’t, and worst of all the user who suggested it didn’t use it either.
It wasn’t that it wasn’t good, it did what they wanted but we’ve come to realise when you ask people what they want they start dreaming and listing everything they could possibly want not what they actually need and will use.
We’ve learned to listen to suggestions but also watch behaviour, if there’s a correlation between the two and there’s a problem that really needs a solution then we begin the process of implementation.
5) Too tied to our previous work
Before there was RealtimeCRM in its current iteration, there was EliteBMS. It was desktop based and very heavy duty. It was an ERP rather than a CRM and so was a lot wider in the breadth of business needs it covered. At the same time it was also designed for a small group of companies and so was very particular to the way they worked.
Learning from real experience is priceless and there are parts of RealtimeCRM which users love and owe a legacy to EliteBMS (e.g. our flow from Opportunity to Projects). There are also parts we knew wouldn’t work due to essential differences between a desktop and web based product and so are completely new (e.g. many people now use a webmail client so we dropped our Outlook plugin in favour of a forwarding email address to handle adding emails to our CRM).
The tricky part is the middle ground where those decisions aren’t obvious. We put in features we weren’t sure about just because the old product had them (e.g. purchase orders), implemented things a certain way to match the old version when it didn’t make sense (e.g. our original tasks system) and were sometimes too cautious with new ideas because they didn’t exist previously (e.g. tags).
It’s always hard to see beyond what you’ve done before, and the key is to be self critical - do you think something is a good idea because it’s comfortable and you’ve done it before, or because it’s tried, tested and loved?
The past year has seen us learn a lot and grow in confidence. We’re still as wide eyed and enthusiastic as ever, but we have the wrinkles of experience to help us navigate the future.
What doesn’t kill you makes you stronger and a lot wiser too which in many ways is invaluable.