The Birth of Product-Led Product Analytics

The calendar read 20 April 2022 – a date now holds special significance. On this day, we officially greenlit myCountly with an intensive kick-off meeting that was initially planned for 90 minutes but, in actuality, extended to a fruitful 150-minute discussion. Our team, consisting of engineers, designers, dev ops, and product specialists, was excited to bring myCountly to life.

Before diving into the technicalities, I felt it was essential to slow down and remind everyone of the purpose behind our venture. I wanted to reestablish our shared understanding of the mission and reignite the initial enthusiasm that sparked myCountly. This was crucial to ensure everyone was on the same page and to boost morale after a challenging year.

In 2021, we faced difficulties while completely revamping the user interface and experience of the Countly server. Although necessary, this undertaking took a toll on the whole team's spirit.

With the start of the myCountly project, we had the unique chance to reenergize the team and remind them of the compelling reasons driving our journey. It was a moment to reflect, gather strength, and prepare for the exciting road ahead, benefiting not only the myCountly team but the entire company.

We were kicking things off, but there were still many details to iron out. We had wireframes to be converted into designs, and we had many decisions on the tech stack and the level of automation to aim for in the first version; we would also need many changes on the Countly Server side since, after all, Countly server is the product and myCountly is a SaaS built around it to make it accessible to a larger audience.

Deciding the Tech Stack

The engineering team, prior to the kick-off, had this lovely series of threads on Slack discussing every individual item. My only involvement was pretty much “Let’s please not overengineer”. In new projects/products, there is always quite an excitement to try the shiny thing everyone seems to be using or talking about, but it’s important to balance things out.

‍

‍

We have been developing in Javascript since the Countly server runs on NodeJS, and we have had some projects we used Typescript for. The engineering team was keen to go with Typescript for myCountly. As part of the UI/UX transformation of the Countly server, we switched the UI to Vue and thus decided that’s the way to go for myCountly from the get-go as the team already had enough know-how. 

The other details are history now, but clearly, we were learning from past engineering mistakes and planning things at a higher level, making the decisions we had to make now but still keeping room for adjustments down the road.

Laying Down the Wireframes

From a UI perspective myCountly is a rather simple product. Maybe it’s better to say that it has to be simple as it is a layer on top to make creating, configuring, and managing Countly servers easy, and the real heavy lifting is under the hood.

‍

‍

Our initial screens were pretty much limited to:

• Signup, login, password reset
• Dashboard
• Deployments and deployment details
• Management (company, team and project)

We agreed with the design team that we’d prioritize the signup, login, password reset, etc. screens for the engineering team to set the skeleton of the project but also get started with authorization and authentication as the first step.

A Refined JIRA Workflow

After our Countly server UI/UX work took more than a year, we decided to alter our development and release workflow rather drastically. In the past, we did around two major releases yearly, which may sound too scarce, but the main reason was the number of customers we had that self-hosted Countly. We wanted to keep things manageable from their perspective, not to anticipate and plan for a new Countly server version too frequently.

However, after the new UI/UX work and finally the release of it, we felt like we needed to show more agility, and we certainly had to get back on pace in terms of the new features we bring out. That’s why we switched to cycles, 4-6 week sprint-like periods where we made a release at the end of each cycle. We didn’t necessarily follow all the aspects of an Agile Sprint, but the main ideas were:

1. Not keeping a long-term roadmap, just having a guideline of what we would like to achieve in a year
2. Adapting the cycles based on the current priorities of our customers and the market conditions
3. Having a balanced out “big three” in each cycle: something for the customers, something for us, and bugfixes 

We wanted to follow the same cycle mentality for myCountly too. Of course, with myCountly, since it is a pre-launch product, we knew it wouldn’t matter too much until we have our first user in production, but still, we wanted to make this a habit until then.

Automation and Dev Ops

myCountly is like a tiny cloud provider with a small catch of only letting you create servers that run Countly on them. Even though myCountly isn’t as complex as a full-fledged cloud provider, from an automation perspective, there were still a ton of things we could technically automate, but is it worth the time to do so now was the question.

• Do we auto-scale servers?
• Do we auto-adjust the disks?
• Do we make every deployment a highly available one, with replication of the data?
• Do we make the servers try auto-healing when they have issues?
• How do we upgrade the servers to the latest version of Countly?
• Do we let the users scale their servers down?
• Do we let the users change the region that their Countly servers are?

As we were just kicking things off, we first wanted to explore the feasibility of all of these; however, the general agreement was that we can add more automation down the line and only take care of the absolutely necessary items in the beginning.

Countly Server 

From the get-go, we knew, wanting to build myCountly in a product-led way, that there would be many changes and additions necessary to be done on the Countly server itself. The two very obvious starting points were:

1. Countly Enterprise comes with all our feature plugins. In myCountly, in order to let the users configure their server the way they exactly need and to save costs, we wanted to make some of the features add-ons. However, enabling and disabling plugins on the Countly server requires some wait time since we don’t soft toggle but run a series of commands when you toggle any plugins. We needed to change this for myCountly, to enable a fast and easy toggle of features as the user changes their server add-ons via the myCountly UI.
   
   
2. One of the most critical aspects of Countly Enterprise is the aftersales operation we support our customers with. A team of Customer Success Managers, Support Engineers, and even hands-on involvement of our Server and SDK Developers on many matters, including the onboarding of our customers. myCountly has to automate this to the maximum extent possible, and to be able to do that, we needed to think through what we can add to the Countly server experience to make our myCountly userbase as self-sufficient as possible without impacting their experience in a bad way or reducing the value they get out of Countly. We’ve called this an “onboarding plugin”, but as you’ll witness, this concept will continue to evolve throughout our journey.

The challenge was that any change we would need to make on the Countly server would need to go through the Countly server development cycle. Given myCountly is a new development, just starting out and possibly with fast movement compared to the Countly server, it was clear that we would have to be very careful about planning our asks from the Countly server team properly to get things on time for myCountly.

Additional Considerations

There were several other important topics that required attention and decision-making. Maybe not immediately, but certainly sooner than later. These included positioning myCountly in the market, determining the necessary adjustments for our website to accurately reflect our offerings, and establishing our pricing strategy. While these topics deserve detailed exploration in subsequent posts or discussions, it's worth summarizing the general sentiment at that stage.

The positioning of myCountly in the market was a critical consideration. We needed to clearly define our value proposition and communicate it effectively to our target audience. This involved identifying the specific benefits and advantages that set myCountly apart from competitors and articulating them in a compelling manner.

In parallel, we recognized the importance of aligning our website with our new offering. We understood that it was necessary to update and restructure the content and design elements to accurately represent myCountly's features and functionalities and how it sits with Countly Community and Enterprise Editions. We needed to ensure that visitors to our website can easily understand which Countly product they should choose and why.

Additionally, pricing was a significant factor that needed careful deliberation. We needed to determine a pricing model that not only reflected the value myCountly provided but also resonated with our target market. This involved considering factors such as cost analysis, competitor pricing strategies, and customer expectations.

While these topics were still works in progress, the fact that we were actively discussing and addressing them was encouraging.

Timeline

We set our target to launch the alpha testing phase for myCountly by the end of 2022, which provided us with approximately eight months to focus on development. While there were still a few aspects that lacked clarity, the overall timeline seemed feasible, and it motivated everyone to dive into their respective tasks.

We agreed that before starting our first cycle, we’ll need some pre-work from engineering, design, and dev ops, but things were clear and ready to go!

Countly’s Product-Led Story

In our upcoming post, we'll jump ahead a few months to explore the progress made in shaping myCountly. We'll delve into the engineering challenges we encountered, the experiments we conducted, and the decisions we ultimately settled on to propel us forward.

Join us as we continue to explore Countly's product-led story, revealing the challenges, triumphs, and lessons we've encountered along the way. Be inspired by our journey and gain valuable insights that can help shape your own path to success!