In conversation with Manikandan Vembu: COO, Zoho Corp
Like every business, the product business comes with its own challenges. From our experience, we know that neither market demand nor product success are permanent, and the only way to stay relevant is by evolving the product.
1. Initial success
Our first successful product was SNMP API and with that early success, we built Agent Toolkit, WebNMS, and Simulation Toolkit—all targeting the same telecom OEM (like Cisco, Motorola, Nortel, Lucent, Ericsson, and others). After the initial success in the telecom business, with growth peaking at 300% in 1999 to near zero growth in 2003, the peak and bust happened within four years. There is no guarantee of demand for any product. We were a 400-person company back then. The successful products we built didn’t have market demand; it dropped due to the telecom slump. From 10 new optical companies starting every month, more companies were shutting shop. We had zero new customers in August 2003, and that was the trigger for moving out of the telecom market to new markets.
2. Identifying the new market
With 400 engineers working on multiple products, moving them to build new products was not easy. The first product that came out of that telecom experience was OpManager—a server and network monitoring tool that targets businesses—which was built on top of WebNMS. It was a small team that built OpManager but the majority were still working on the telecom market, which wasn't growing and was in the decline. Instead of having people on products without market demand, we moved people to build new products in ManageEngine. We already had engineers, so we decided to go after other markets in the enterprise IT space that were already successful—it was proof of market demand. As OpManager was targeting IT, we wanted to build additional products that target IT for cross-sell opportunities. From ServiceDesk Plus to Endpoint Central to Active Directory, all the early products in ManageEngine grew that way. OpManager helped us revive growth and ServiceDesk Plus’ success helped us accelerate growth. When one product's growth is slowed, another pushes the company's growth.
3. Future-proofing the business
SaaS was just starting in the early 2000s and with our experience in telecom, we knew that SaaS could threaten the installed software business. With some additional resource from the telecom business, we started the Zoho brand and invested heavily in SaaS to ensure that we have strong presence in the SaaS market.
4. Finding product-market fit
While it was easy to build the product, it wasn’t easy to find product-market fit. Until the end of 2007, Zoho had decent sign-up but not much in terms of revenue. While ManageEngine was making good revenue and growing, Zoho was a non-starter. One product manager even suggested closing Zoho CRM because we couldn’t see traction. We persisted by improving the product, and that helped Zoho hit its 1st million dollars in 2008. While the ManageEngine side did our first $1 million in revenue in 1998 (just two years after the inception of AdventNet), it took more than four years for Zoho to hit the first million. Even though the first million took longer in Zoho, the business software market had much higher potential than the telecom market, and that potential is what brings more competition in the business software market.
It requires a lot of product focus to get the product-market fit. The majority of products fail here, and some of our own products in successful markets couldn’t find the product-market fit. This taught us that even with all the features, the product could fail if it lacks something. Identifying that challenge and getting the initial customer traction is the first big hurdle in the product’s success.
5. Scaling phase: Maintaining existing customers and keeping the product relevant
For a new product, finding the product-market fit is a challenge. For successful products, on the other hand, there are two challenges. We have to manage existing customer requirements and also identify new ideas that will help win new customers and keep the product relevant in the market. Most often, we serve existing customer requirements, which is a departure from the new direction that evolves in the market. So it requires a balance between keeping current customers happy and making the product ready for future customers. It’s a continuous discovery process, and it is not easy to identify new features or a direction that will help the product stay relevant and extend the customer base.
In service-based business, customers ask for what they want, so scaling is about building capacity and processes. Scaling in product-based business is about discovering the right direction for the product. Most companies in the product business fail after initial success because they cannot discover the right direction and keep the product relevant in the market. They often outsource the requirements to customers, which makes the product obsolete.
- Manikandan Vembu
Across all our matured products, we are in the scaling phase. Customers are not going to tell us what will help our product grow. It is our challenge to identify what is useful and build that. In any successful market, competition is unavoidable. Competition will always try to find better ways of solving the problem and staying relevant. We should also find better ways to solve the problem. This is where a deep understanding of the problem is important. Otherwise, the product becomes obsolete, and which is why some products stagnate even if the market grows.
6. Setting the direction for the market
The next phase in the product business is setting the direction for the market, and if that direction is right, all the competition will follow that direction. From being a follower in the market, the goal is to become leaders in the market, and that can happen only by successfully identifying future direction.
Product managers from Zoho and ManageEngine
- Srivatsav Balen
Srivatsav joined Zoho nearly a decade ago and oversees product management activities for Blueprint, a prominent feature of Zoho’s CRM solution. Here, he shares his perspective and experiences.
Product management does not utilize a one-size-fits-all approach. In general, there are two types of product managers - problem-seekers and solution-givers. At Zoho, we’re inclined to be problem-seekers. Our culture is, and always has been, that way. It boils down to what kind of problem we seek and what we’re trying to solve. What problem fascinates us? The solutions may be technically or functionally challenging, but we look forward to these challenges and see it as an opportunity for growth.
What does a typical day look like for a product manager at Zoho?
Here's how my team and I allocate time for all the tasks lined up for the day:
First, we work with anything that impedes the release pipeline and make sure things are addressed and it is not waiting for a PM. This ensures that the direction is set for the progress of the day.
Next, we work with the development team, including other APMs and senior APMs, to answer their queries. This could be to address use cases, challenges, or make changes in line with other features that may have been released that might conflict with the feature currently in the works.
Following this, we work with the design team. Our role here is to draft a wireframe or mock-up and coordinate with designers on the finer details. As a product manager, I must ensure the design meets the current design standards but at the same time doesn't lose ease of use. When the design satisfies our criteria in terms of form and function, we give it the go-ahead and it moves to development.
What inspires product managers to seek problems?
Truthfully, product management is not a job you can check in and check out of. It's a constant state of mind, and like any creative role, inspiration can strike anywhere, anytime. For instance, a friend of mine got married a few years ago, and I was in charge of vendor coordination. We had vendors for the venue, catering, decor, etc. Managing the data supplied by the vendors was arduous, to say the least. Let me give an example. The caterer would present a standard package, which I'd have to go back and share with the bride, groom, and their families. We'd revise the package based on their collated input and send it back. Let's say three desserts instead of two and a change in the main course. Then the vendor would come back with a revised quote. I then had to go back and confer with the families to approve. This back-and-forth was taxing and affecting productivity. I presented the challenges to my team, wondering if there was a logical solution within our product ecosystem. This inspired the creation of the Configure, Price, Quote (CPQ) tool in Zoho CRM. So, problems exist everywhere, and product managers can be inspired by a completely unrelated scenario to build something new.
For any given product or feature, there's bound to be multiple avenues for feedback, both internal and external. How do you decide what takes priority or what the team should work on next?
Requirements can be categorized as stated and unstated. Stated requirements are the ones we get from tickets, community, events, internal feedback, and social media channels. They usually know what the problem is and may even have a solution. There's clarity in their input. Unstated requirements are those that aren't from the users but are necessary for the growth of a tool. There's a famous anecdote from Steve Jobs that's often quoted in the product management world: "People don't know what they want until you show it to them." Until you show the customer what is available or make them aware that there is a problem that can be solved, there's no way for them to know what they need. In that case, our focus is on the output. As a product team, we try to balance stated and unstated requests, and resources are split between both kinds of requests.
What is the role of senior leadership in product management?
Often, product or feature ideas are shelved due to various reasons like feasibility issues, resource limitations, or difficulty in finding product-market fit, where the market was simply not ready for a launch or users were too niche. When a team comes up with the same suggestion later, it's possible that the current infrastructure is ideal to bring the concept to life. However, leaders hold valuable insights as to why it didn't work the first time. Their input must be factored in when working on it again and ensure it is no longer a roadblock. This approach works for us at Zoho because most of our leaders were engineers and were involved in the initial versions of our products. They know the product inside-out. Their mentorship and foundational knowledge play a key role in the trajectory of the product.
What do you think is a challenge for young product managers?
Finding a balance between design and functionality is always tricky for young PMs, especially when working on a mature product. Take the classic example of deleting an item. A PM may opt for something like a three-dot menu where the user selects "Delete," followed by a pop-up check-box where they reconfirm their choice. A designer might find that to be cumbersome and suggest an icon instead, to simplify the process. However, in this case, we want the user to be absolutely sure that their action is irreversible and cannot retrieve deleted data. Maybe as a workaround, they can introduce an additional block like admin approval before deletion. So, finding that level of balance is necessary and requires multiple one-on-one conversations between PMs and designers. I always recommend creating a wireframe with pen and paper before working with the design team as it helps me communicate my thoughts with clarity.
- Aparna TA
Aparna has been a part of ManageEngine for almost a decade, beginning her journey as an enterprise analyst before pursuing her passion to create new solutions. In this segment, she shares her approach to product management and the challenges that come with it.
How would you categorize your responsibilities?
To give a general overview, I'd say we categorize our work as:
- Discovery work: This is about exploring the different solutions we can build, understanding features, and market trends. We talk to different teams, engage with customers, and gather input. This serves as a base for the next step.
- Product work: Our main focus here is to come up with PRDs.
- Project work: First, we follow-up with stakeholders on the PRDs, then check their feasibility and alignment. We also prioritize features and conduct stand ups.
- Program work: Typically, we oversee projects, see if things are moving on track, align and prioritize items, and collaborate with other teams to iron out the finer details.
- Ad-hoc work: Anything that may be beyond the scope of product management responsibilities, we allot some time for that too.
Depending on which stage of the development process we're in, the distribution of work differs.
What were the challenges you faced when you first stepped into this role?
Product managers, in the early stages of their career, are usually tasked with coming up with very specific PRDs. Use cases are known, and from there, finding out the problem statement and identifying the functionalities required. A lot of newcomers (including me, when I was one) get into solution mode (feature listing) as soon as they get the use case without identifying the core problem. Here it's asking "what does the customer want to achieve, which they are unable to now?" It’s not about a feature that is missing, but about a task that needs to be done, usually irrespective of the tool.
Beyond that, collaborating and getting a buy-in from teams is a perennial challenge. Each team views the project from their perspective. Naturally, when there are different contexts and goals, it requires additional effort from a PM's side to understand their vision and functional objectives. From there, we need to pitch our ask or goal such that it aligns with theirs. There's a lot of back-and-forth—a lot of input coming from multiple stakeholders—so getting their buy-in is a slow process.
When we say buy-in, we need to understand that there are layers to this as well. The first level is leadership, where we seek broad alignment to initiate the work. Next, we need to be backed by senior managers to align with the outcome. Following this, we work with other PMs and developers on use cases and specific functionalities. We have to collaborate with every stakeholder at their level and work our way through to deliver what we set out to. Although it is a challenge, it is imperative that everyone gets the bigger picture and understands how they can help deliver the solutions.
How can managers stay inspired and come up with new ways to solve problems?
I have always believed that if you really look for it, you can find your inspiration anywhere. Inspiration is everywhere at Zoho and ManageEngine, with 100+ products, and so many functions, each trying to do so many different things.
Product managers must take the time talk to every stakeholder in the product to understand why something is designed a certain way; that’s when you begin to understand the complex machine every product is. Only when you know the complete picture can you find opportunities to change it. To put it simply, don’t wait for the inspiration to be handed to you.
Product managers should talk to their peers and product leads in other teams to see what they are doing and how they are approaching the problems in their domain. Reach out to leadership, ask them about the how far they have come and where they see company going. There are so many moving pieces. When you start taking such small initiatives on your own, you'll have more clarity in your purpose. I say this because I also spend about three to four hours a month doing this. It has been the most rewarding experience and usually a welcome distraction from the daily grind. There's so much happening around us on a daily basis; all we have to do is follow what inspires us and trust that will lead us to what we are searching for.