Product Migration: Moving from an MVP to a Scalable Product Base
We have transitioned from an MVP SaaS-based approach for validating market fit to a scalable product-based approach for the entire workflow.
Context
In the world of product development, building a Minimum Viable Product (MVP) is a common approach to validate market fit without investing too much time and resources upfront. Once the MVP is validated, it’s time to migrate to a more scalable product base to support the entire flow.
This was the situation when I joined Inventa, a startup that had been running for a year with an MVP constructed based on Shopify and Zoho customizations and a series of 1000-line lambdas. The market-fit results were impressive, but Inventa faced problems in product evolution and handling a lot of incidents. Our main goal was to change this scenario! We needed to prioritize a full product migration to a solid foundation for this promising startup.
The migration prioritization
We realized the need to internally establish a scalable foundation for our product in our infrastructure, which we referred to as “Shopify / Zoho Out”.
Creating a new marketplace involves more than just the front end. We had to reconstruct the entire workflow, from user sign-up to order management, finance operations, and internal back offices. Understanding and maintaining everything was challenging, so we recognized the need for an “engineering rebranding”. To ensure a successful product, our focus was on creating a solid and flexible foundation that would allow for easy and quick product evolution. We were able to do that because we shared the main limitations and incidents that caused a lot of instability and limitations to our business.
However, we also acknowledged the potential for quick wins and improvements in the current product. Therefore, we aimed to strike a balance between enhancing the current product and developing the new marketplace in-house, considering all trade-offs. This approach helped us understand the ROI (return on investment) for each promising new change.
Before proceeding with coding and developing the entire platform with 8 teams, we needed to create a detailed plan for executing this game-changing project. The following topics will outline this plan.
Mapping AS-IS e TO-BE
To ensure a smooth and successful migration, we conducted a thorough analysis of the system’s current state (AS-IS). Since understanding the current product was challenging, we created a service blueprint of the product as it is, which includes all its business rules and interactions with internal and external users.
The Engineering leadership led this process because no one truly understood the product, and we were still in the process of building a Product and Design Team at the beginning of 2022 and 2023.
Through this process, we gathered existing knowledge about the product and made several discoveries to understand and map the current developments. This helped us identify end-to-end rules that could be developed or improved.
We created a template for the expected service blueprint we needed. Although we did not strictly adhere to precise service blueprint principles, we created a representation of customer actions and backstage actions that could be taken by internal users or our system. You can see the template below.
With this template and through a rigorous and multidisciplinary effort led by the Engineering team, we have mapped the entire journey of Inventa. This includes the user journeys from their initial interaction to the final interactions, covering the perspectives of sellers, buyers, and internal operations.
This allows us to envision the desired future state (TO-BE). In this step, we need to:
- Address the issues identified in the current state (AS-IS)
- Incorporate new desired flows
- Consider potential possibilities
As a result, we have created a TO-BE blueprint using the same template:
This process was collaboratively built. We brought together different disciplines, stakeholders, and C-level individuals in the same room. Our goal was not to dictate every detail of how things should be done but rather to establish a guiding principle to follow.
“If you do not know where you want to go, it doesn’t matter which path you take.” — Lewis Carroll
This approach allowed us to identify areas that needed improvement and establish a clear vision for the migration process. Now, with all of this in mind, we need to create a plan to put it into action.
“A goal without a plan is just a wish.” — Antoine de Saint-Exupéry
Developing a migration plan
Putting it all together, we had a clear understanding of both the current product and our north star based on the available information. Now, it was time to develop a strategy for migrating our product. While many companies opt for the big bang approach, we were determined to avoid that.
When discussing a phased migration, the first step is to take a step back and consider all the potential options. This could involve exploring different user migrations, product flow migrations, or internal system migrations. There is no right or wrong approach, but it is important to determine the best option for your specific case.
When examining Inventa's scenario, I thoroughly considered the following aspects:
- Viability: Is it feasible to migrate in this manner? Are there any dependencies that could make it difficult or even impossible to change one part without affecting the other?
- Pros: What are the potential positive impacts of this migration? How would it benefit the team, maintenance, users, and the company?
- Cons: What are the potential negative impacts of this migration? What challenges might arise during the development process?
After carefully analyzing all the possibilities, it became evident that using the legacy product based on Shopify and lambdas was not a viable option for either the product flow migration or the system migration. The most suitable approach was to migrate by user groups.
This means that I needed to understand the personas of our users and the business requirements for each type of persona. This understanding would help me determine if there was a clear boundary that I could use to create delivery phases. The first types of personas were the Individual User (CPF) and the Business User (CNPJ).
However, having thousands of users for each type was not sufficient. We needed to determine the minimum business requirements for users to comprehend how we could promptly deliver the initial version and gradually enhance it to accommodate more users.
Consequently, we identified the following initial features that could assist us: Historical Info (for new users or those already registered with historical information) and Credit for Business Users (pre-approved credit that they could utilize in the marketplace).
Based on that vision, we drafted an initial rollout version with 6 phases, taking into account the business requirements and engineering complexities of the product development. We then held meetings with various teams and stakeholders. During these interactions, we evaluated and improved our versions of the phases to be delivered. The revised versions are outlined below:
Then we arrived at the final version (2.1) after successfully completing 4 phases. The final result was:
V0 — Alpha: This phase focused on signing up individual users. Since these users were unfamiliar with our site and we had minimal features, signing them up was the first step.
V0.1 — Beta: In this phase, we targeted all individual users who didn’t require the complexities associated with businesses, such as taxes, shipping, and enrichment by government providers.
V0.2 — Gamma: We focused on current business users in this phase. These users were already on our platform and had undergone credit analysis and business profile enrichment by the government. As a result, we were able to introduce these complexities in the final phase while delivering it to our existing users.
V0.3 — Delta: This phase involved signing up business users. It represented the last and most comprehensive stage of product development, catering to all users, including new ones, with all the necessary complexities.
The Beta and Gamma phases underwent internal rollouts, which were collaboratively constructed by the engineering and data teams. This allowed us to select the most active users for the rollout while excluding inactive ones.
Migrating Users
There are two important points to understand about the process of migrating all users: Users data migration and User group rollout.
For the user’s data migration, we started using the legacy platform to migrate users and their access to the new platform. When users log in to Shopify, we began the migration process 2/3 months in advance. This allowed us to migrate the data of all active users. When the migration time arrived, we constructed the structure and performed the data migration with the help of the data and engineering teams.
For the rollout of the user group, we created an isolated table in our database to control the migrated users. For each rollout, we brought together the product, engineering, and data teams. We defined the strategy for selecting users based on our business strategy, promotional campaigns, and what we wanted to test and monitor on the new platform. Next, we created a list of users and the engineering team added all of these users to our system through an endpoint. When a user did visit our homepage inventa.shop, they are redirected to the correct platform based on the information in this control table.
Mapping Dependencies and Delivery Dates
While creating the release phases, we considered the scope of each team and identified areas with higher demand. To align with the migration plan, it was crucial to understand how to execute it. This involved planning the game with all teams and mapping out the dependencies between them. Thus, the team planning puzzle emerged.
Delivery planning plays a vital role in ensuring a smooth and successful product migration. By understanding the relationships between different tasks, identifying dependencies, and estimating timeframes, teams can effectively coordinate their efforts. This is exactly what we did.
Initially, we faced the worst-case scenario where critical dependencies were estimated to be completed after the development tasks that required integration with them. To address this, we realigned the scopes and adjusted the delivery order for all teams and tribes. Recognizing the need for additional assistance, we focused our team efforts accordingly. With this plan in action, we successfully achieved the first Alpha release, marking a significant milestone.
Moving on to the next phase, we conducted a similar dependencies mapping exercise. As you can see, we successfully aligned all the necessary components for the upcoming versions. This accomplishment is illustrated in the image below.
Follow-up Process
As mentioned before, this project was the most important one for the company at that time. It was crucial for us to ensure that we stayed on track, monitored the progress, managed dependencies, addressed cross-discussions, resolved pending definitions, and handled any potential issues. To achieve this, we established a weekly meeting with the following structure:
Discussion Points
We began with an open agenda, providing an overview of the project’s progress. Then, all meeting attendees had the opportunity to add topics they wanted to discuss in the meeting notes. This approach worked effectively for everyone involved, as it allowed us to address cross-tribe themes that were important to all stakeholders.
Pending Definition
We also need to align follow-up pending definitions for each phase. This will help us keep track of progression, definition, and development blockers.
Intruders
One major challenge when prioritizing a structural task like migration is that the company’s operations continue, which means new bugs and requests may arise. Depending on how many of these we prioritize, it can increasingly delay our migration progress. It is important for us to be able to report this to the company leadership. Therefore, we make a note of all the issues that arise during development. This has been very helpful, especially when we needed to update the proposed timeline and get approval from the leadership.
This approach provides a clear and easy way to communicate what is happening and keep everyone informed.
Progression
Each tribe was responsible for conducting their own follow-up and updating the meeting table with the progression of each macro delivery before each meeting. They also indicated their level of confidence. This process greatly helped us understand which teams required more attention or assistance, as well as when we needed to rethink the plan or the defined dates. The discussions that followed were beneficial for everyone involved, particularly for the company and our users.
Results
I wrote this article one year after the migration, and I can confidently say the results were excellent. Not only during the migration process but also in terms of the solid foundation we built for our product. This foundation enabled us to conduct various tests, experiments, and developments for the growth and profitability of the company, all while keeping maintenance costs low. The engineering team has a clear and concise understanding of our system architecture and takes ownership, resulting in fewer recurring and preventive maintenance tasks. Incidents are now rare, which is a significant improvement compared to when we started this article.
It is not easy for any company to stop delivering new features or fixes to prioritize structural changes. However, the results that follow have a huge impact on everyone involved, especially our users. They now have a stable product that allows for faster delivery of new features and changes.
Learnings
Of course, it wasn’t a smooth journey. We have learned a lot from things we did right and from the challenges that gave us headaches.
Collaborative work between product, data, and engineering in the rollout
This was the best choice we made. We executed it well, and the results greatly contributed to the successful completion of the migration.
Corner Cases
One corner case that we overlooked was the creation of Personal and Business users with the same email on different platforms (legacy and the new marketplace). Although we had accounted for some of these cases, one slipped through. As a result, we had to perform additional migrations to fix it promptly. The main lesson here is to give more emphasis to corner cases and test them thoroughly before releasing them to the product. However, some cases will inevitably arise that we were unable to anticipate. This is part of the process, and the key is to monitor and respond quickly.
Data migration errors due to low-quality legacy data
We encountered challenges with low-quality legacy data that needed to be migrated to our new system for accurate take rate calculations. As we progressed, we discovered more and more corner cases, which led to the creation of complex rules to understand the migrated data. The key takeaway here is to simplify as much as possible and test the rules with a diverse group of people who may not have the same level of context as you do. This will help validate the rules being created.
In conclusion, the journey of migrating Inventa’s product from its initial MVP constructed on Shopify and Zoho customizations to a more scalable and stable platform was a complex yet rewarding process. The team recognized the need for a solid foundation and undertook a meticulous engineering rebranding. The results one-year post-migration were deemed excellent, with a stable product, reduced incidents, and enhanced understanding of the system architecture. The article highlights the significance of collaborative work, addressing corner cases, and the importance of data quality in ensuring a successful and impactful product migration.
If you want to know more about us, add me on LinkedIn or apply to one of our open positions! Let’s learn together and build something bigger and better than we could do individually!
Thanks for reading! I’m always open to receiving feedback, recommendations, or questions, feel free to contact me!!
Pamela Peixinho, Engineering Lead @ Inventa
LinkedIn: https://www.linkedin.com/in/pamepeixinho
My last name is LittleFish, “sea” you later! 😉
