Over the past few years, we have seen that the enterprise is becoming cool again. This has lead many software developers to venture into building enterprise applications. However, some things have changed from the previous time enterprise software was the “in thing”, in the late 90s.
Here is a disambiguation of what has changed and what has not.
Technology that works
Enterprise software typically have large companies as customers. And as you’d expect, with big companies come “big” support requirements. At Compile we ran into a scenario where we were in the process of building our Marketo integration. We realized that there are 3 ways we can integrate Compile Leads with Marketo:
1. Post via web-forms that our customers create
2. API integration via SOAP
3. API integration via REST
As a developer today, my default choice would be an API integration via REST. But we decided against this approach. The simple reason being, our customers trust the SOAP integration. Giving access to their CRM data is not something a customer is comfortable with. So we decided to pick a technology that imparts trust, even if old and not the shiniest technology out there.
Going mobile or not?
The world is moving towards a mobile-first approach. That makes sense –– people are always on the move and need information on the go. Data indicates that desktop usage will decline more steeply in the coming years. But, here is the twist. Your company need not always build a mobile app.
You need to build your tool to cater to the environment the tool is going to be used in. Over the past 2 years (2012-2014) we have seen that Compile Leads are mostly used during office hours on large screens by people sitting at a desk.
For this simple reason, we haven’t invested time in building a mobile app. This doesn’t mean that we wouldn’t do it in future, but not just yet. We have also made sure that our product is responsive and works well on small screen browsers too.
Making it big
This also means they aren’t that easy to scale. But this has not been a problem for our sales team. The product sells because it solves a core customer problem, which is inability to get quality leads. We have built our systems to scale well to our business needs. We don’t serve 40 million users everyday and we don’t think we will be doing that anytime soon either (though that’d be a nice engineering challenge!). But we serve a few thousand users with our apps and this approach has worked well for us. After all, our customers are ‘genuine’ ones, unlike the @zeldman’s bar in silicon valley.
OH: A million people in Silicon Valley walk into a bar. No one buys anything. Bar is declared a rousing success.— Jeffrey Zeldman (@zeldman) June 27, 2012
Design that delights
Our product recently went through a major facelift. This led us to make some interesting changes in how our product is used. Now, every design change comes with many happy customers and some ‘not so happy’ ones. We don’t want to keep any customers less than delighted with our offering, so we spend our support cycles explaining and hand holding our customers about the changes in the interface. This effort has led to a lot of ‘not so happy’ customers joining the former group.
The lesson we have learnt from the recent design overhaul is to do extensive documentation for any part of our tool, and guide them through the transition. Over time, if designed right, customers will come to accept and love the changes. In contrast, here is a timeline of Microsoft’s start menu. Flip – Flop – Flip again.
In summary, here are a few things, I have learned from building tools and apps at Compile over the last few years.
- Be ready to embrace any technology, even if it is perceived as ‘old’ and ‘last gen’, you don’t know what will work best for your tool.
- Don’t build for everyone, build for the ones that matter.
- Don’t wait till you can scale, start shipping and sell more, and then drive the scale.
- And lastly, be ready to accept mistakes and fix them.