The making of the product-tech backbone of a SaaS startup
In the hustle-filled early days of SaaS unicorn Postman, an office tour would end barely a minute after it began.
It was a one-bedroom apartment that Ankit Sobti, Abhijit Kane, and Abhinav Asthana had rented and repurposed as their office. There, bookshelves doubled up as workstations, and one didn’t need to holler for a meeting—a mere mumble would do.
It was in that cramped workplace that one of the fundamental discoveries that had an overarching impact on the journey of the startup was made. Postman had been trying to simplify their microservices architecture around the turn of 2018, trying out a lot of technological solutions to the design problem. In this milieu, the founders moved to a larger apartment (office), and, to their utter disbelief, the architecture they were trying to redesign mirrored the change in the layout.
“It was a fundamental eye-opener for us. When we moved from a single-bedroom apartment to a four-bedroom one, we could see how the code was evolving based on how we were interacting in the new office. Office layout and code decisions!” Sobti exclaimed, the unfinished sentence an expression of sheer incredulity.
What Sobti and the other founders saw in action was the postulations of a research paper by computer scientist Mel Conway in Datamation magazine over five decades ago, that an organization would produce a system (defined broadly) whose structure was a copy of its communication structure. Once aware of this, the founders wondered if the inverse was true: if they communicated differently, would the system they were building change commensurately?
The realization that struck the team was further reinforced by the writings of software development guru Eric Evans and Throughtworks Chief Scientist Martin Fowler, a loud-mouthed pundit on software, particularly enterprise applications. Postman parlayed what it had learned into real-world applications for its design, enabling it to make efficient systems and serve its customers better.
In its most recent fund-raise, Postman was valued at $2 billion. But for all the glitz of blitzscaling, it would not have worked without a “strong foundation of values,” said Sobti, narrating his way into the crux of the nine-speaker virtual event organized by the Pay-it-Forward SaaS community SaaSBOOMi. The virtual event, SaaSBOOMi Build, was a series of talks to set entrepreneurs and leaders up for product-tech success.
Invariably, most speakers eventually gravitated toward values and the importance of evolving culture codes quite early in the development of products and the subsequent scale-up of business.
Inculcate product thinking right from the beginning
STS Prasad, Freshworks’s Senior Vice-President of Engineering, has witnessed from close quarters its much-storied growth spurt over the past four years. Through such a steep trajectory, a startup should not lose focus on its “product thinking,” advised Prasad.
By that, he meant clarity over what a startup wants to deliver to the identified market and enabling engineers to develop the ability to think long-term. “They’re not just thinking about ‘What do I need to build this week or this month?’ but are certainly able to think about the architecture, the overall technology investment that they need to make to keep themselves aligned with the product and business strategy of the company.”
It is in the $1-10 million annual recurring revenue (ARR) phase that your engineering teams get pulled in different directions. Their time could get taken over by customer issues and bug fixing, making software development just another contender for their mindspace. As you scale up, what should the ideal size of your engineering team be? Prasad had some suggestions:
One of the fundamental focus areas, also one of the trickiest in terms of execution, is hiring. Startups across the globe have evolved their own styles of recruitment; some have boldly experimented with unorthodox methods that have upended established notions about the ideal candidate. Prasad urged recruiters to hire candidates who are willing to push their own boundaries; it’s an intangible, and sometimes elusive, trait, but, nevertheless, worth pursuing.
At the same time, never compromise on the basics: “We do sometimes tend to get carried away by educational background or which college the engineer went to, or which company the engineer had worked at, to keep track of, maybe, some specific expertise. But by and large, I would ask you to really focus on the eagerness of your engineers to be able to learn new technologies, learn new engineering skills, be flexible to take on whatever needs to be done.”
Prasad underscored his suggestions with his own experience building Freshrelease, an agile software project management product from the Freshworks stable. It was built by a team of 10 engineers, the majority of whom had fewer than two years of work experience and did not belong to the Ivy League grad category. “We were able to replace Jira [Atlassian’s workflow management tool] with Freshrelease in a kind of an internal pilot. The key takeaway is that the things to look for in an engineer are eagerness to learn and hunger to win.”
Take your time defining your viable product
What Prasad came to realize from his experience in building products are learnings that one can find codified in the hiring practices of other startups, too. Speaking immediately after Prasad at the SaaSBOOMi summit was Soham Mazumdar, co-founder at Rubrik. The Palo Alto-based company is into ensuring business continuity, solving problems related to data security, backup, disaster recovery, and cybersecurity for its customers.
Rubrik’s line of business demands a direct understanding of the customer. The selling is enterprise-grade, customer support is high-touch, and the average ticket size of sales is “pretty high,” in the words of Mazumdar. “We are going after the replacement market, meaning there have been many products that cater to the same market. This is very much an established market.”
In such a competitive business, Mazumdar, too, emphasizes the importance of defining product utility down to the last word, making it crystal clear to founders themselves as to what the product would do for the targeted market. By doing that at Rubrik, it became clear to the founders whom they should go for during hiring drives: “We realized that our minimum viable product was as much about monitoring the system as it was about just the basic act of data protection. Once we were clear on that, we knew whom to hire.”
Rubrik soon realized that effectively managing/storing data was the key requirement. Mazumdar remembers that the founders all looked at each other as this realization dawned upon them, and came to the conclusion that they would have to make a key hire. “We all had strengths but this particular area was not a strength for any of us.”
Once a startup’s founders have crystallized their product idea, the hiring of the first 20 engineers is crucial. Mazumdar suggests an even mix, and warns against not hiring specialists and perfectionists, for some of them go on to become great technical leaders and code reviewers in the future. And, of course, life is too short for “brilliant jerks.”
Design as a competitive advantage
Design aimed at making lives easier for customers and users is essential to the success of any software company and its products. It is as much a product function as it is a marketing tool. Design isn’t just about making products look great.
“To design a chair, you need to understand how it will be used, whom it is meant for, where it will be kept,” said Bharath Balasubramanian, senior director of design at Freshworks. “Design is all about creating something that your users will love to use.”
Bharath’s post-lunch session was an instructional journey into the design process and its central role in building and scaling an enterprise startup. He packed it with guidelines and dos and don’ts that can make the difference between success and failure.
Talking about website design, for example, Bharath emphasized the need to convey the message in the first fold of the webpage so visitors would want to explore further. “The first step in a company’s customer journey is the website. It is where most customers would first experience your brand. The website is your storefront. It needs to instill trust and draw in your customers. So build it with care.”
But how do you ensure effective design? According to Bharath, the solution lies in talking to customers and understanding their needs in the early stages of the design process. “Try to deliver as much delight as possible with your features. Delight helps reduce churn,” he said.
Now, design of the kind Bharath talks about cannot be an afterthought. It needs to be an integral part of a product company’s DNA. Which also means a product startup needs a designer from Day 1. A designer who understands business problems and focuses on delivering solutions to fix those problems.
“As soon as you start the product definition, you need to have a designer,” he said. “You cannot take shortcuts.”
Building enterprise SaaS on the public cloud
The differences between on-premise software and software-as-a-service provided over the public cloud can be categorized under three primary buckets—scale, cost, and security, explained Milind Borate, setting the stage for his session.
The SaaS model allows optimizing for economies of scale. But because of multiple cost factors, gross margins tend to be smaller than for on-premise software, said Milind, co-founder and CTO at backup-as-a-service provider Druva. “Gross margin still needs to be above 70%,” he said, delving into the intricacies of building enterprise SaaS on the public cloud.
Security, he added, is a challenge because enterprise customers are finicky about it and demand certifications that validate the robustness of the SaaS solution. “Third-party security audits and certifications are a minimum requirement,” he said.
On the architecture for public SaaS, compute, storage, and network are the key parameters, said Milind. He emphasized on systems being resilient enough to handle varying loads, efficient use of resources, and capacity planning—all of which also help optimize costs.
As for storage, Milind suggested that, depending on the scale of operations, companies could begin with a relational database and switch to a distributed database later. “You will go through multiple cycles as the software evolves and you get more customers. So there will be a chance to switch to a more distributed architecture on storage,” he said.
And finally, on network, Milind said companies should ensure that the network-heavy components of their architecture such as API gateways and HA proxies are scaled out separately versus their compute instances.
Milind’s learnings on the difficult tradeoffs and the areas of cutting edge in the SaaS model are complemented by those of Monish Darda, co-founder and CTO of Icertis, scaling his company in the tricky dimension of enterprise SaaS.
With Microsoft as its first customer, Icertis has been able to widen its contract management platform within a short time: the company moved from two engineers to over a hundred within a span of 7-8 months, according to Darda.
One of the unique things about Icertis’s platform is that it has undergone three refactorings in its history. It holds a lesson for founders trying to accelerate platform development with a robust engineering team and how to be agile while doing it. “Those refactorings have become re-writes. Probably not many companies can claim that. If there is a new proposal, say, a new library, or database, we have a completely new way of approving it quickly, depending on its impact,” he said.
Today, Icertis has a set apparatus to decide what surfaces to senior leadership, and how to ensure decisions are taken fast.
Darda’s notes from his experience of refactoring his platform received a rousing reception at the virtual summit, which had yet another informative session by Anjali Kumari, India product head at ThoughtSpot, and Dinesh Varadharajan, vice-president of product management at Kissflow, who engaged participants on prioritizing the product roadmap through the enterprise and SMB lenses.
That was right after a virtual interactive workshop on planning the product roadmap. The interactive workshop required participants to make tough choices on the critical trade-offs in roadmap planning.
Harnessing the trio for delivering a world-class experience
All said, setting yourself up for product success is somewhat similar to working on the right brew: too much Robusta will make it bitter while no one can stand an excess of the sickly sweet Arabica. Just like coffee, the manner of combining inputs matters a lot in delivering a great product experience to customers.
“One objective that keeps us up in the night as founders or leaders is, ‘Can we build this great product with world-class user experience (UX) and deliver it in time in the market?’ That’s what we always strive for,” said Deepak Diwakar, co-founder at sales enablement platform MindTickle, as he began his session on ‘Aligning the trio of product, UX, and engineering to deliver world-class experience.’
MindTickle’s approach, he said, derives from three primary ingredients—purpose, operating readiness, and catalyst.
Let’s begin with purpose. “There’s a big difference between purpose and objective. Objective is driven by your goal, but both of these can keep changing. Purpose gives the ‘what’ and ‘how’, not ‘when’, because that too can change,” Deepak said. “Once you align with the purpose, even if you need to change direction, your product, UX and engineering teams will understand why that decision was made.”
Purpose needs to be accompanied by a high-level operating framework for your teams to work with. The framework is important for teams to align with the company’s growth plans. “When you are inching toward $4 million or $5 million ARR, you begin to get some sort of rhythm and at that point of time you need to have a framework,” Deepak said, adding that it’s okay to have a framework for six months or a year so long as it gives you a broad alignment for operating readiness.
For the third ingredient, catalyst, Deepak employed the analogy of a credit card—you need to have it but you must figure out when and where it should be used. “The catalyst can take different forms and shapes. It could be an object, an event, or people’s persona that would help in particular situations.”
[This blog was originally published by SaaSBOOMi]
Subscribe for blog updates
Thank you for subscribing!
OOPS! something went wrong try after sometime