The most significant continuous improvement project that I have led was improving performance of the product website to make it the fastest website amongst the competitors.

In my previous company, I was tasked with development of website from scratch. The key goal of the website as per our product strategy was to acquire users which meant the site had to be optimized for conversion. I realized that we have to go after improving the performance because. As per Google, for both SEO and SEM, conversion rates vary inversely with performance. Faster the performance of website, better the SEO and better the paid marketing conversion. This was the genisis of this project and since this would positively impact consumers as well, we aimed to be the best in performance as compared to major competitors.

The first thing I did was to decide the metrics and set the goals. This was done after benchmarking our competitors. Once the goals were set, we broke down the things to improve into infrastructure, back-end and front-end related tasks. For each of these buckets, we then prioritized tasks into effort vs impact. And over a period of 7-8 months, we were able to do the major changes and meet the goal we had set.

It was most significant improvement project because :-

1. It was technically challenging and involved multiple teams.
2. It had a very positive impact on consumer experience.
3. It positively impacted our business goals.
4. Last not the least, was important from confidence perspective as well since it showed that if given opportunity, we can be the best
5. It strengthened the performance mindset in our team and from that point on, performance became a gate in our CI processes.

• Situation: I was leading the data conversion work thread on an implementation program, where the scope was to migrate a million provider and member records from the legacy platform to the new platform. This migration was pretty complex, since the legacy platform and new platform stored this information in very different ways and, the transformation requirements were not very well documented and understood. UAT work thread was dependent on this program to provide them with good quality data, that they can use to test their capabilities.
  • The issue we were dealing with, was that UAT and DC were sharing the same environment. So, once the data was loaded, DC and UAT would execute their test cases at the same time. This meant that UAT was executing their test cases using untested/unstable converted data, which was blocking their progress, resulting in false positives and impacting business morale.
  • Additionally, the DC work thread was unable to properly re-test any fixes they implemented, since they couldn’t wipe out the env and reload it since that would impact UAT testing.
• Task: the goal was to define an approach to data conversion that allows us to continuously measure progress, iterate quickly to improve load quality, and pro-actively manage dependencies with other testing work threads and get us to go-live
• Action: I worked with the business and IT teams to jointly define a set of success KPIs related to data load, accuracy, and usability. I then designed a testing approach that consisted of running ‘mock runs’ on a dedicated conversion environment, decoupled from the UAT / SIT env, where we would iteratively load the data and test our load against pre-defined KPIs identify fallouts and their root causes. Before each load, the environment would be refreshed and reloaded with data, to allow us to re-test our fixes and measure improvements in our data load quality against the KPIs.
• Result: We were able to provide high-quality data to the testing work threads, unblocking their testing, improving their testing accuracy, and reducing the time it took for them to complete testing. Additionally, despite poor requirements, we were able to iteratively improve our data quality loads, significantly improve progress tracking by measuring against our KPIs,  risks identification which meant that there were no surprises at the time of go-live.

Project: Initiative to inculcate a product mindset in the organisation.

Problem: I was working in a team that was following a delivery mindset with no interest in understanding the “why” part. Basically we were a team of mercenaries instead of a team of missionaries as Marty Cagan puts it. The entire team including engineers, designers and product owners were delivering features defined by the Product Manager or the Tribe leader (as in the Spotify model). Our team was not the go-to-place to solve complex or innovative problems. We started realising that we were not sure of what value we were generating.

Solution or what was thought to improve the situation: Over a period of 2 years, we wanted to improve the mindset of our team. We wanted to ensure that everyone was interested and inquisitive about what they were working on and that they knew why they were building what they were building.

To inculcate this culture, we needed start from scratch, we needed to understand the domain, the use cases for which we were implementing solutions.

I was part of a team of 4-5 members that were to bring about this change to our team in an incremental fashion. The goal was to become team of missionaries who was generating tangible or substantial business value.

How it was done: Over a period of multiple quarters, we designed a charter for this initiative. We started by capturing the “why”, “what” and “how”. We divided into work streams, each targeting the engineering, agile and product pillars.

Each stream was to understand the problem areas in their pillars and then conduct sessions or trainings accordingly. I was leading the domain/product pillar. I realised that most of us were not exposed to the domain aspect of things and neither did we question this. I facilitated sessions with customers or end users of our product and invited the entire team including engineers to understand the domain and see how users use our product. I also facilitated sessions with other teams that were following a product mindset. We organised sessions on topics such as setting business KPIs to capture value, Discovery vs Delivery and so on.

We set quarterly goals and KPIs and then reviewed our progress after each quarter to see how close we were to achieving our goal. We also took feedback from our team and leadership teams and improved our strategy accordingly.

This is an ongoing process and we improve as a team continuously.