DronaHQ was a rapid app development platform till 2019 march. 2014–2019 our sales and marketing was focused on selling enterprises a platform to build their mobile applications on the RAD platform. Platform was cloud native and it gave a bunch of SDKs to our customers using which they would build their applications. Our distribution was top-down and our customers were business buyers in large enterprises. Say HR or Sales or Marketing heads would signup building their application on the platform. Behind the scene — we would have to create an account for the customer on the platform and give appropriate licenses to the account. Top down meant sales was 90% outbound and sales cycle would look like: leads ->demo -> proposal -> Closure. Everything under the sun that Aaron Ross would write in Predictable revenue is what would be applicable in our operating model. At a high level (product & sales) & (product & marketing) were mutually exclusive and had 0 integrations between the two systems.
2019 March we went beta live with our evolved RAD — Low Code/ No Code platform and we also made it SaaS enabled. This meant we were now opening the door for bottom up distribution. As signups grew, we were staring at a few challenges ahead of us:
- customer management had to be automated and couldn’t rely on a manual process (managing trial period, upgrades, downgrades, etc)
- our sales team wouldn’t be talking to every prospect to convert them to a paying customer. Nor could we add every prospect from our signup into the CRM as is to manage the lead due to multiple reasons. One major reason — SaaS was self serve.
We now had to reimagine our customer journey from visitor to paying customer and figure intersections where our sales, marketing and customer success team would get in touch with the customers and figure out tools that they would now need to help them do their job.
At a high level customer journey looked like Visitor -> interest -> evaluate-> engagement -> purchase -> Renew. Let’s take an example by zooming in to this customer journey. Say in evaluate phase — customer may need an extension of evaluation. A simplified user story would then be — account executive would get a request from within the product and he must have a simple interface to add a trial extension.
Similar such commerce enablement features would be needed at every step in the customer journey.
Subscription management, Invoice automation,Annual contracts & license management, Upgrade/downgrade services, Ticket management, Refund management, Promo code management, Incentive management
Now to deliver such stories, your engineering would have had to deviate to non engineering tasks and build the system to enable commerce on your SaaS. This would be super critical for commercial success of your SaaS.
We had to add commerce blocks on top of our SaaS. Our SaaS block diagram now looked like in the figure below
In the hindsight, adding low code to our stack helped us
- build these modules way faster
- stay super agile to meet ever evolving business requirements.
for instance upgrade/downgrade service was not our day 1 requirement. But as number of customers grew and such requests increased, we took it up to build the service with low code.
Let me know how you have build your SaaS tech stack to support ever evolving business needs.