Applying Agile Methodologies to E-Commerce Platform Migrations

Simplicity

One thing I’ve always loved about e-commerce is the underlying simplicity of setting up a functional online storefront. If we set aside the complex needs of external integrations that provide business-critical functionality and focus solely on launching an extremely basic, minimal representation of what the e-commerce site needs to function, we find that there are really only four things you need to do before you can start placing test transactions online:

1. Choose a platform
2. Add some products
3. Add a payment gateway
4. Add tax and shipping calculators

By implementing these four features in the first sprint of an implementation project, we can concentrate on adding all the bells and whistles in future sprints. Since our MVP is now transacting, business stakeholders can see immediate value in Sprint 1, as they can now place test transactions on the MVP website, tangibly demonstrating the return on investment of the project from the start.

When it comes to enterprise e-commerce store migrations, this inherent simplicity is often thrown out the window.

The "Bells and Whistles" Mentality

In my experience, there is a mindset that launching an e-commerce store means maintaining feature parity from the legacy platform to the new platform, under the belief that your store will not be successful without those features.

Additionally, it's not uncommon for your existing e-commerce platform to have years, potentially decades worth of legacy integrations, custom features, and downstream dependencies. Untangling the intricacies of each and every one of those considerations equipped with only a small project team who are up against a tight timeline and budget is a bit intimidating — at worst, it's demotivating.

I'm not discounting that these are valid concerns to have. Just consider that e-commerce website don't really need all these fancy bells and whistles to function at the end of the first sprint. Technology-forward companies are adopting "lean" methodologies to prototype quickly, and improve based on user interaction data instead of speculation. Technology companies have entered the age of agile development, iterative value, and minimum viable products. We test early and often, and invite beta users to do the same. Stakeholders get to immediately see the impacts of their decisions, and they are enabled to quickly change features and functionality, instead of waiting 9 months for the rest of the website to be finished as well. At the end of the day, e-commerce websites that have not launched simply cannot demonstrate tangible return on investment.

Communicate "Why"

So the question becomes, how do you foster the shift in perspective to help your team view your e-commerce store as a technology product, and not a years-long waterfall project? How do you inspire your team to lose their fear of launching with less, and to instead invite challenges to what they believe is the definition of a successful migration?

You create context.

You are not communicating to your team that you'd like to launch a new website with "less" of what the current website has — you are selling the idea of launching a website that can be tested by your team and beta users in the first sprint, and iteratively improved upon in the following weeks.

Data is king, and the more data that you can collect from the current website to show what users are not touching, and to emphasize what they are using most is invaluable. Heatmap tools like Hotjar, Google Analytics, and other tracking mechanisms can help you do this.

Finding your Pareto Principle

I know it's not often that you find yourself with a need to migrate e-commerce platforms, but the next time you do, I want you to lead your team to focus on finding your e-commerce website's Pareto Principle. What are the 20% of features on your current website that drive 80% of its results?

It's a tough question, because the answer is so drastically different from company to company, vertical to vertical. However, the methods to find the answer to the question can be applied to most companies.

Define Your Target User

Most websites serve many different types of users with subtly varying needs and goals. Decide in advance who your target user segment is – the group of users who are most important to the success of your product. You can’t please ‘em all! When push comes to shove, it will be better if you can make prioritization decisions because they’re what’s best for your target user, even if doing so means forgoing the needs of others.

Analytics and Data

Ask yourself, what are the most used features of your existing website today? Tools such as Google Analytics can help you understand where your users spend most of their time on your website, and what features they hardly ever touch. As a very small, anecdotal example, before migrating my blog from Wordpress to Next.js, I had 20+ blog posts I thought I needed to migrate from one website to the other. Turns out, only three of those posts accounted for 97% of the organic traffic that was hitting my website. I almost spent 10 hours migrating useless content that only drove 3% of traffic to my website — instead, I spent 2 hours migrating the most important content that drove 97%.

Validate Your Assumptions

Even when certain feature ideas get prioritized as candidates — serious features you’re considering building — it would be unwise to send them right to designers and engineers to begin working on them. Carrying out high fidelity designs and writing production code involve time-intensive work from highly skilled members of your team. It’s always best to take the features you’re considering working on and run them by customers first – particularly those who requested them in the first place. Do they still need these features? Do you understand their need correctly? Do they envision the same final solution you do? If there’s a discrepancy, is it a sign of misunderstanding the underlying need? Try to answer all of these questions before beginning work on a certain solution.

Roadmaps — not Backlogs

Your shift in focus from being an e-commerce company to a technology company needs to have direction, and must inspire people to look ahead instead of leaving room to doubt the present. Your backlog, or product roadmap, should be your most powerful tool in achieving this, and you should use it to provide peace of mind to your stakeholders and larger audience that there is a larger plan you are all working towards.

In fact, you may not know it but by this point in the article you've already developed the first few sprints of your product roadmap. We've talked about the importance of early testing and MVP validation. We've found the 20% of features that will deliver 80% of the results compared to your legacy system, and you should now be able to begin grooming the backlog of your initial product roadmap.

Deliver Value with each Deployment

Your first sprint should focus on two huge milestones:

1. Deploying a functional, blank but transactional, e-commerce store. You should be able to add a test product to your cart, checkout, and view that order in your new e-commerce platform dashboard.
2. Opening channels that enable you and your customers to quickly test the features rolled out of each future deployment. This can be as simple as providing your team and beta testers a password to a password protected storefront, or as complex as integating your new store with downstream ERP systems, third party software, etc.

By the completion of your first sprint, you should already have a fully functional e-commerce store theoretically capable of recouping some of the capital invested to build it in the first place.

Your second sprint should be focused on delivering at least a fraction of those "Pareto" features identified to bring 80% of the value from your previous system. You should work with your team in each sprint planning system to talk about the value that is to be deployed along with the features. Understand and plan for how you will measure the results of the sprint — how do you show that the sprint produced more value for the website than what was present before the sprint?

An Example - Hardware and UX

The example that often comes to mind, and consequently the example that inspired me to write this article, was a small hardware company in North Carolina that sold primarily woodworking tools - abrasives, wood turners, tablesaws, etc.

The project requirements were intimidating. We were to migrate the merchant off their existing e-commerce platform, at the same time that they were working with another team to migrate them off their existing ERP and retail point of sales systems, and then ultimately finish the migration by integrating the three systems so that the ERP served as the source of truth for the website and the PoS.

After months of sacrificing features, delaying timelines, and paying invoices that were never scoped from the beginning, the project finished. It's a project I think about often because there were so many missed oppportunities to re-scope and de-scope so many unnecessary components. We started with the "what", and talked about the "how". What we never did was start with the "why", and work backwards to paint the picture of what was considered successful.

All that website really needed was a redesign, and some improvements to the store's search engine. Most of the traffic came from Google Shopping, so all we needed to do was implement reliable product feeds so that users could easily find the products they were looking for before they left Google.

Facing Reality

This post is of course, theoretical in nature. In a perfect world, every large e-commerce website would have a product manager, a UX designer, a data scientist, and a team of engineers. This may be the case with larger companies like Nike, Sonos, and other large brands that generate the revenue to justify those hires; but often times, smaller e-commerce companies simply cannot afford to hire full software teams for their e-commerce websites.

Regardless, a good product manager walks the line between reality and perfection - measuring real impacts of business decisions, while simultaneously inspiring teams to reach for more. Whether I like it or not, I respect that e-commerce websites are a means to an end. The customers that use the websites you build don’t care how the underlying software that runs the website works, they simply care that they can find what they’re looking for, and that they can buy it.

I encourage you to be the person that inspires your team to deliver value from day one, and to challenge the status quo of what is considered a successful e-commerce platform migration.