FusionCharts is one of the top JavaScript charting libraries worldwide. It enables developers to create stunning data visualizations on their applications and websites.

As Head of Products, this was my second major initiative after fixing the release cadence across the organization. In a shrinking market, we had to reinvent ourselves to grow again. I worked with the leadership to redefine FusionCharts into a Business Intelligence product from the JavaScript charting library.

Problem definition

Growing FusionCharts once again: In the late 2000s, FusionCharts was one of the fastest-growing technology companies in India. Everyone from Whitehouse to Apple, Salesforce to Atlassian used FusionCharts for data visualization. However, with the rise of open-source software, the data visualization market began to shrink rapidly by the late 2010s. As a result, FusionCharts' growth declined rapidly. As a company, it was time to reinvent ourselves and grow again.

Discovery

Market research

• Market research is essential for starting any good venture. As a company, we had expertise in Developer Ecosystems and Data Visualization. Therefore, we decided to study both markets.
• When FusionCharts was founded, the data visualization industry was relatively new. Today, two decades later, it has transformed into a billion-dollar industry known as Business Intelligence (BI), dominated by PowerBI (Microsoft), Tableau (Salesforce), and Qlik, among others.
• Similarly, we have been building products for developers. As a result, the developer ecosystem has also grown into multiple billion-dollar industries, such as Application Development Lifecycle and API Platforms. Like BI, this industry is also dominated by major players such as Microsoft, Atlassian, Amazon, and Google.
• FusionCharts was constantly battling against open source; hence, moving into the developer ecosystem was not a scalable idea except, if you get into infrastructure and DevOps like Amazon Web Services, Microsoft Azure, Google Compute Cloud, Atlassian, etc.
• We always excelled in data visualization; hence, we decided to move forward with the Business Intelligence (BI) industry.

The BI Opportunity

• The Business Intelligence (BI) industry is worth over $20 billion, and is primarily divided into two parts:
• Self-service analytics: Enables CIOs and their teams to make sense of data easily. Most products, such as PowerBI, Tableau, and Domo, cater to this audience.
• Embedded analytics: Allows software products to embed a reporting layer in their applications. Out of the $20 billion, around $5 billion belongs to Embedded Analytics, where no clear leader exists.
• With our expertise in developer ecosystems and data visualization, Embedded Analytics was the best industry to focus on.
• Any BI product is divided into the following components:

1. Infrastructure: How the whole BI application is hosted and will be scaled.
2. Data Warehousing: How the data is stored. It could come from various sources like Google BigQuery, MongoDB, SQL Servers, or third-party apps like Salesforce, HubSpot, etc.
3. Data Modelling: Ability to structure the data, especially when the data is coming from various sources.
4. Data Discovery and Analysis: Analyse the data, and find trends (probably using NLP and ML).
5. Data Visualization: Visualize this data so consumers can get data-driven insights and make decisions.
6. Collaboration: Share this data and insights with others and collaborate.

• If we had to move into BI, we had to build solutions for all the components. Since our expertise was primarily in the front end, we came up with potential products that could help us build solutions for these components in the near future.
• Furthermore, we also spoke with some of the customers who build SaaS dashboards and BI products and came up with a roadmap of new products that could help us move in this direction.

Execution

Mission statement

• Our idea was to slowly move in the BI paradigm by building products that users will pay for (and use regularly). We deliberately decided against building a full-fledged Embedded BI product because that would have taken at least 3-4 years. Being a bootstrapped company, we were not open to exploring where we could have burned millions of dollars without earning anything in return.
• Once it was clear that we were moving into the BI industry, we needed to develop a mission statement that was easy to communicate and rally the entire organization behind it.
• We called it “Charts to Dashboard Journey.” Although as simple as it sounds, it was incredibly effective. When planning one of the sprints, a Junior Developer criticized our decision by asking, “How does this initiative fit ‘charts to dashboard journey’?”. It was one of the proudest moments for me because I had never met this person; All I had done was, present the 2-3 years roadmap to the engineering and product teams. And yet he was rallying behind the common goal. It proved the importance of a mission statement and how effective was the current statement.
• After determining the business goals, and customer requirements, we developed a few products that could help us move in that direction in the next 12-18 months.
• FusionExport: Ability to run a server that could export any dashboard to PDF, PNG, JPEG, or even run cron jobs to send alerts.
• FusionGrid: Grid visualization product that complemented the charting product.
• FusionDataStore: Cross-platform client-side data management library that could manage millions of data and run CRUD (Create, Read, Update, Delete) operations along with aggregation at an incredibly fast speed. We eventually filed a patent for this (which is still pending).
• To build these products, I was tasked with building a solid product team which I managed to set up in a few months. The team was intact till FusionCharts was acquired.

Results

• We started growing again for the first time in almost 3-4 years. However, the major credit belongs to the sales team. Without the product team’s initiatives and swifter release cadence, it wouldn't have been possible.
• We released two new paid products and took them to product-market fit, which helped us slowly diversify the revenue.
• We filed three patents, out of which one of the patents has been approved while others are still pending. It improved our intangible assets. But most important, it was a testimony to our constant endeavor to innovate.
• After the acquisition, the new parent company acquired one of the Embedded Analytics companies within two years: Yellowfin. This was also a testament to our vision.

Dialpad is a pre-IPO company with over $200m in revenue that designs groundbreaking, truly unified communication products—all powered by the most advanced communications Ai in the world. The company makes it easy for teams big and small to call, message, meet, and support their customers in one beautiful workspace.

As a Product Manager, I lead the ‘Ai Meetings’ product, where I ensure the product is on par with the incumbents yet has its niche so that it could be valuable to the customers.

Problem Definition

Build a competitive video conferencing product: Dialpad builds products that unifies all business communication needs, and what is more important than video conferences? However, in Dialpad’s portfolio, Ai Meetings had been under-invested for a while, making it outdated compared to other meeting solutions. It was important for Dialpad to offer world-class products across calling, messaging, meetings, and support that are ‘unified.’ Hence, one of the first problems of ‘Dialpad Ai Meetings’ was to have parity with meeting solutions.

Discovery

• The company builds various products for three industries:
• UCaaS (Universal Communication as a Service): Almost $80b industry includes products like calling, messaging, meetings, conference room solutions, etc., bundled into one product.
• CCaaS (Contact Center as a Service): A contact center product goes beyond voice-only ‘call centers’ and allows companies to communicate with customers through additional channels like text, email, chat, or social media to provide complete customer service. It is a $20b industry.
• Sales enablement: Relatively small (~$5b) but a new industry that focuses on improving the productivity of sales teams.
• UCaaS and Sales enablement use the Ai Meetings product for internal and external communications. While CCaaS, it is primarily used for internal communications.

• Since we were trying to build products that would be used across the industries for both internal and external, we had first to ensure that the product of the meeting fulfills the basic needs for video-based collaboration.
• After the pandemic, Meetings Solutions became a commoditized market dominated by Zoom, Google, and Microsoft. After doing the market research for both Meetings Solutions and UCaaS industry, along with speaking with our existing customers, we discovered two key areas to focus on:

1. Parity of meeting solutions: Ensure the product provides at least ‘table stake’ features to communicate efficiently.
2. Improve productivity of Digital Workers: With the rise in remote collaboration due to Covid-19, meeting fatigue has become the biggest problem. Hence, we focused on improving the customers' productivity so they don’t have to conduct redundant meetings.

Execution

• Since we focused on the parity of meeting solutions and productivity improvements, we worked on both initiatives in parallel throughout the year and more.
• Any meeting solution could be split into the following phases:
• Pre-Meeting: Everything that happens before the start of the meeting, like scheduling.
• Introduction: The first few minutes of the meeting where you define the agenda and introduce participants.
• Core Meetings: Where the actual discussion takes place.
• Conclusion: Last few minutes of the meetings where you summarize everything.
• Post Meeting: How you refer to the meeting once it is over.
• Based on the phases, we tried to find all the missing components of the product and implemented them. Most of them were ‘table stake’ features that helped us be closer to achieving parity with meeting solutions. This list included: virtual backgrounds, waiting rooms, unique meeting URLs for better security, emoji reactions, video recording, etc.

• Furthermore, we collaborated with Google, Microsoft, Salesforce, etc., to build seamless third-party integrations for calendars and scheduling. In addition to that, we built a whiteboarding feature in collaboration with Miro.
• Apart from meeting solutions parity, we focused on reducing meeting fatigue by improving productivity. We tried solving it with a combination of Ai and UX.
• We released meeting timers that remind people when a meeting is about to end so that people won’t spend any more time than necessary.
• We always focus on providing exceptionally good user experience (since our tagline is ‘Work beautifully’). We wanted all participants to join the meeting in any medium they were comfortable with, without downloading anything. That’s why Dialpad Meetings is a ‘browser-first’ video conferencing tool (unlike others where you need to download apps). We followed the same philosophy of mobile, where we were one of the earliest products to support mobile web-based meetings.
• In this age, Ai is the buzzword. But Dialpad has been investing in it for the last 6 years (especially after the acquisition of TalkIQ). And that’s why it was a cakewalk for us to release in-build transcriptions when even market leaders relied on third-party integrations for transcriptions.
• Powered by Ai, we also launched automatic and custom action items so that people know what needs to be done after the meeting.

Conclusion

• Within 12-18 months, we started appearing in the top 10 list of video conferencing products across many sites like G2Crowd, TrustPilot, Capterra, etc.
• Many analyst sites recognized us. Some of these recognitions include being a leader in FrostRadar™ for Global Cloud Meetings and Team Collaboration Market, first-time inclusion in Gartner Market Guide for Meeting Solutions, innovator in Aragon Research Globe for Intelligent Video Conferencing, Visionary in the Gartner Magic Quadrant for UCaaS, and many more.
• All the constant endeavors in the quality of the products helped us achieve a consistent NPS of 65!

FusionCharts is one of the top JavaScript charting libraries worldwide. It enables developers to create stunning data visualizations on their applications and websites.

During my first 12 months as a Product Manager, I successfully executed projects such as rebranding, building integrations for JavaScript frameworks, and optimizing conversions. As a result, I was promoted to Head of Products and tasked with leading the entire product team.

As Head of Products, I was responsible for both the "Core Product" (the JavaScript library used by developers) and "Developer Experience" (the website and documentation used by decision-makers to evaluate the product without writing a single line of code). FusionCharts is one of the products where the user persona and buyer persona are completely different.

Problem Definition

• The growth team couldn't perform experiments on the website quickly: The growth team couldn't iterate quickly on the conversion funnels, leading to many missed growth targets.
• Increased churn due to long release cycles: Many customers were not renewing their licenses due to very few or no updates. Some releases took almost 18 months to complete, impacting the company's bottom line.

Discovery

As mentioned earlier, the product team was split into two parts: Core Product and Developer Experience. The Core Experience team collaborated with the Growth team, while the Core Product team worked with the Sales team. Each product team had different output expectations:

After spending time with both teams, we identified different root causes for their problems and required different approaches to mitigate them. The following were the root causes for each team:

Execution

Since both teams had different problems, no solution could work for both. Fixing these problems required 9-12 months of work, with various iterations based on each team's comfort and culture.

Improving the predictability of the Developer Experience with Scrumban

• The Developer Experience team used the Kanban model, with a public Trello board visible to everyone. Various teams would dump their requirements onto it. However, the team was distributed across two cities, leading to much non-verbal communication.

• Lack of communication and poor scope definition made it difficult to implement things on time.
• We first implemented Scrum, including backlog grooming, standups, sprint planning, retrospectives, review, etc. We replaced time-based estimations with points and velocity.
• A two-week sprint would start with taking requirements from the growth team. Using story points and velocity, we could estimate how far we were from the deadline and improve our delivery.

• However, this led to slower release cycles, as the growth team had to wait two weeks before changing the experiment. Not very agile, right?
• Hence, we decided to transition back to Kanban with a hint of Scrum, aka Scrumban. Scrum ceremonies had advantages, such as daily standups, sprint planning, and retros. At the same time, Kanban focused on speed and transparency.
• Each 'In Progress' card had a limit based on 'Story Points' to ensure we did not overcommit.
• Daily standups ensured we had clear requirements and were on track to meet our committed deadline.
• Reviews helped us determine if there was room to improve the 'In Progress' limit so that we, as a team, could improve.

Implemented quarterly releases for the core product

• The engineering team of the Core Product excelled in core competencies such as code quality, stability, and estimations. They didn't follow a story points-based approach but provided absolute time-based estimates, which were spot on.
• Their major concern was scope creep and the roadmap. When the product team took over, it made their lives much easier and helped them be more agile.
• Before the product team's intervention, the engineering teams often followed the waterfall methodology. However, after the product team was formed, we followed a combination of Scrum and Kanban.
• Unlike SaaS products, FusionCharts resided in the customer's application, so the quality of the product was always crucial. Also, frequent release cycles like weekly or bi-weekly would make the customers' lives difficult, especially in enterprises.
• Hence, we implemented quarterly releases that included one week of planning and estimations, six weeks of development in Scrum, a review, and four weeks of QA cycle in Kanban mode with two weeks of buffer.
• We iterated between Scrum and Kanban but eventually found that a combination of both worked in our case.
• One week of planning ensured the engineering and QA had enough time to gather estimations. Six weeks of focused development cycle ensured there was no loss of productivity. And four weeks of Kanban, they ensured that the software was thoroughly tested and that all the bugs and regressions were addressed immediately.

Conclusion

• With Scrumban, the Developer Experience team released many major projects, including rebranding and redesigning Dev Center (a developer API documentation website that is more developer-friendly).
• Regarding the Core Product, it took almost 18 months to move from FusionCharts v3.12.0 to v3.13.0. However, all releases after v3.14.0 were made every quarter. Even after FusionCharts was acquired, the same practice continued. You can see it yourself by navigating through the entries on the version history.

Your agile is someone's waterfall!

• This was the biggest lesson I learned. Everyone wants to do agile, so they assume others are doing waterfall without understanding the methodologies.
• Focusing on outcomes/delivery and understanding what your team is comfortable with is important instead of forcing something just for "following processes." Processes are created for teams; teams are not created for processes. Every process will vary from team to team.
• Phrases like "sprints should never be modified" are used to shrug off responsibility and make the team anti-agile. The Agile Manifesto focuses on speed, quality, efficiency, collaboration, and outcome. It doesn't even mention sprints, scrum, or points. So, in the end, the outcome matters, not the processes.

1. Part 1: Why traditional economics concepts do not apply to software?
2. Part 2: Elasticity of demand explained for software products
3. Part 3: When to invest in the infrastructure using the cost curve?
4. Part 4: Measuring the efficiency of product teams using the output curve

So far, we have covered many concepts like supply and demand, the elasticity of products, cost curves to determine operational efficiency. This essay will explore the output curve to assess efficiency. Furthermore, when and whom to hire.

What is an output curve?

An output curve is a relationship between the number of employees and their output. It helps us determine the efficiency of the employees. The output curve for traditional industries like manufacturing consists of the number of goods manufactured by the employees. Let’s take the example of mobile phone manufacturing from the earlier essay.

As we keep adding employees, the amount of the goods produced also increase. But it does not tell us anything about the efficiency. So let’s take the average of the number of goods produced per employee and plot a graph:

After we add the 4th employee, productivity decreases. If we plot the same curve with the cost curve learned earlier, we will get a complete picture of the operational efficiency. It provides us with helpful information about how to grow. For example, in this case, every manufacturing unit should not have more than three employees. Let’s try to understand something similar for software teams.

Plotting output curve for Scrum teams

As I mentioned a few times before, the marginal cost for software is almost zero. Once you have the product ready, you can produce infinite copies. This makes it difficult to plot an output curve. However, we could achieve this if you have a Scrum team. Scrum is an agile project management technique focused on increasing efficiency and reducing wastage. It has a concept of story points and velocity that could be useful here. I won’t go deep into the explanation of Scrum because that’s a topic for another day, but let me provide you an overview:

1. Scrum consists of breaking down the project into smaller chunks called sprints. The duration of these sprints could be two weeks (or more, but it should be constant)
2. Every feature you will cover in the sprint has a weightage called story points.
3. These story points differ from feature to feature. For example, if a feature is complex, it will have higher story points and vice versa.

Now, let’s take a hypothetical example and plot an output curve:

As per the graph above, having more than three engineers per team would reduce productivity. So it is best not to have more than three engineers per project.

However, there are a few flaws with Scrum. First, the story points are subjective to every team. So if you have a huge engineering team, the story points will vary from team to team. So this method becomes unreliable. Hence, we need to determine a different way for an efficient hiring process.

Hiring matrix for product organizations

We have established that measuring productivity could be difficult for software companies. Unless we get clarity about productivity, it is difficult to understand when to hire. But as a product organization, we should not employ recklessly. Although there are metrics like revenue per employee, it comes into the picture after hiring. So let’s try to take a jab at it.

There are two segments in a product organization:

1. Supply team: Consists of engineers, QA, designers, product managers who drive the supply side of the software
2. Demand team: Consists of sales and marketing folks who drive the demand side of the software.

Unlike other industries, KPIs for both supply and demand defer because of the zero marginal cost of the software. The demand side has clear KPIs like increasing sales or customer acquisition. And the supply side, well, there isn’t one that could directly relate to the business. You have performance and release frequency, but it is not directly related to the supply side metrics. To understand the hiring strategy for the product team, we need both supply and demand to have the same metrics. So how could we do that? Adoption and Acquisition.

1. Adoption: As the name suggests, deals with the supply side.
2. Acquisition: As we already established, it deals with the demand side.

Have a look at the diagram below:

Let’s try to understand every single scenario and how it helps us in hiring:

The obvious question is determining a good benchmark for adoption and acquisition. Product or feature adoption varies from product to feature, but I strongly recommend you read Intercom on Product Management; they have done a great job explaining feature adoption. As far as growth metrics are concerned, they also vary from company to company and phase to phase. For example, if you are in the super early stage, then 100% growth MoM would be feasible for you, but 30-40% growth MoM would be treated as a victory as the product matures.

How does this help me as a PM?

Unfortunately, the Product Manager is the most influential person in a product organization but has little control over the organization. Unless you are a senior product leader, you are very unlikely to have a say in the hiring decisions. However, you could always provide opinions in the hiring decisions. After all, delivering a successful product is what you care about. If your peers are hiring at the wrong phase, you will be able to figure it out.

And that’s all we have in the fourth part of the series. I hope understanding the output curve was helpful to you. Feel free to share your feedback at nihar@sawant.me. I am more than happy to hear your thoughts.

1. Part 1: Why traditional economics concepts do not apply to software?
2. Part 2: Elasticity of demand explained for software products
3. Part 3: When to invest in the infrastructure?
4. Part 4: Measuring the efficiency of product teams using the output curve

In the earlier essays, we learned about the supply and demand of software. How traditional concepts may not be directly relevant to the software industry. Furthermore, we explored what elastic and inelastic products are; why building inelastic product is essential. In this essay, we will learn how to measure efficiency and determine when to invest in infrastructure.

What is a cost curve?

A cost curve determines the operational efficiency of a business. In economics, a cost curve allows you to establish a relationship between the production and quantity of goods. Let’s take an example of a traditional industry like the manufacturing of mobile phones.

The cost of an employee is $100/month; as you keep adding employees, the cost will increase, and so will the number of mobiles manufactured. The fixed cost (in this case, it could be rent) is $100/mo. So regardless of the increase in the employees, the fixed cost remains the same. Now let’s plot the total cost:

As we keep adding more employees, the curve gets steeper. It indicates that employees are becoming more and more unproductive. Similarly, let’s calculate and plot the average cost; it will help us understand the efficiency better.

As you can see in the chart, the average cost starts dramatically increasing after we have more than three employees. So this could be the time when we need to invest in the infrastructure. For example, having one manufacturing line with more than three employees is not productive, so it is better to invest in another manufacturing line and employ other people.

Let’s plot the cost curve for a server

Let’s take a hypothetical example of server costs and active users. As we discussed earlier, the software industry does not follow the traditional supply and demand model, where an increase in supply increases the quantity produced. Once you have software available, you can make infinite copies. In this case, we will plot against the ‘active users’ of the software:

As you noticed above, after 75 active users, the cost started to increase drastically. This is the place where we need to start investing in infrastructure optimization. You must be wondering what infrastructure optimization is. There are different ways:

1. Caching: When you have just released a product or a feature, you will likely not invest in caching. Instead, you would simply fetch the data from the database as it is. In the beginning, it won’t cost you much, but as the number of active users increases, you will start bleeding money because querying a database is expensive. This is the time when you could invest in caching libraries like Redis or Memcache. These services act as an intermediary between a database and a client. Most common queries are served by these services, helping you reduce cost.
2. Indexing: If you use SQL as a database, querying them could take time as the active users increase. Simple practices like indexing could save bandwidth.
3. Technical Debts: Technical debts occur when engineers sacrifice quality over speed of execution. Ideally, they should be addressed regularly. Otherwise, it is good to invest some time to deal with them.
4. Performance Optimizations: Optimizing the source code too early is called Pre-mature Optimizations, but as mentioned earlier, once you understand the right time, it is worth spending time on it. It could involve refactoring the code, implementing a few techniques (similar to caching), etc.
5. Cleanups: You have no idea the amount of space storage, backups, unused staging servers could occupy especially, when you are building the product for a few years—simple audit to save a lot of costs.
6. Platform rewrite: Rewriting the entire infrastructure could vary from multiple quarters to years. Back 2010s, Twitter’s failwhale had become a meme. They rewrote their whole platform for a couple of years to deal with this problem. While rewriting, you need to be sure about the opportunity cost. In the case of Twitter, it was already hampering their growth, costing them millions of dollars.

How you could plot a cost curve of your product

Plotting a cost curve for your product requires two things: active users and billing data. I will not define active users, but please keep in mind that it is not the same as user signups. You could signup millions of users with, but hardly 10 of them will use the platform. Now coming back to the billing, very likely you must be using AWS, Google Compute, Digital Ocean as your infrastructure. All these platforms provide a detailed statement of the services every month. You can use these numbers to determine the cost. If you have multiple products hosted on the same database, you need to comb through the details to decide which services belong to your product. Eventually, you could use the aggregated cost as a server cost. Since billing information is fetched every month, it is best to have Monthly Active Users data ready.

Once you have MAU and billing data ready, you can plot the cost curve.

How does this help me as a Product Manager?

Learn to say ‘no’

There is a new framework and library released every other month, and it is pretty tempting for engineers to jump out of the ship by initializing mega rewrites! Even the finest architects could fall for this trap. In his famous essay, Joel Spolsky advised, “You don’t have to rewrite the whole thing. When optimizing for speed, 1% of the work gets you 99% of the bang!” But as a PM, you should understand the opportunity cost. In the above example, if an engineer would have told you to rewrite the infrastructure when there are hardly 50 active users, you should say no. Because it is not worth it. The cost starts increasing when there are more than 100 users. Here is a comic that sums it up neatly:

Rationalization of engineering decisions

It is always difficult to justify decisions like technical debts, architecture rewrites, optimizations, etc. You can’t quantify these decisions even though these are beneficial to the engineering teams in the longer run. Martin Fowler wrote a wonderful essay on the importance of technical debts, but he agrees that it is difficult to measure. Understanding the cost curve could help you visualize when there is a need for improvement and take decisions accordingly.

Plotting a cost curve requires you to understand two essential data points, Active Users and Operational Costs. If you have a subscription model, you can calculate the revenue using active users as well i.e., Gross Revenue. All these data points are sufficient for you to determine the gross margin of the product. Although the gross margin is a topic for another day, a good software product generally has a gross margin of 70%.

I hope understanding the cost curve was helpful to you. Feel free to share your feedback at nihar@sawant.me. I am more than happy to hear your thoughts.