Applying Agile Methodologies to E-Commerce Platform Migrations

Simplicity

One thing I’ve always loved about e-commerce is the underlying simplicity of what it takes to set up a functional, online storefront. As long as you’re not engineering your own custom e-commerce platform, there really are only four things you need to do before you can start selling online:

Choose a platform
Add some products
Add a payment gateway
Add tax and shipping calculators

That’s it. Those four steps are all that are required to build and publish a fully functional, transacting e-commerce store.

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

The "Bells and Whistles" Mentality

Fundamentally, 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.

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 well. 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 just another sales channel? 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 with less of what does less for your customers.

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. For example, before migrating my blog from Wordpress to Gatsby.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:

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.
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 allow users to easily find the products they were looking for. The manual work it would have taken to import orders into the ERP system once a day instead of spending thousands of hours integrating the two systems to automate those processes would have been trivial.

Facing Reality

This post is of course, theoretical in nature. In a perfect world, every large e-commerce website should have a product manager, a UX designer, a data scientist, and an engineer. This may be the case with larger companies like Nike, Bose, and other large D2C brands that boast the revenue to justify those hires, but unfortunately your average 20 person team doing $20MM a year online selling auto parts online simply cannot afford to hire full on software engineers for their e-commerce websites.

Regardless, a good product manager walks the line between reality and lala land - measuring real impacts of business decisions, while simultaneously inspiring teams to reach for more.

I encourage you to be that person for your team.

Notes

Launch on a subdomain, shop.store.com - Measure that subdomain and see what happens with users - A/B Testing
For every single day you spend adjusting the colors of your website, making sure the padding around your buttons is 15 pixels and not 16 pixels, you are failing to demonstrate return on investment.
You don’t need your ERP to be a PIM, you need it to track stock levels, set prices, and ingest orders. That’s it. There are more important things to worry about
E-commerce websites are a means to an end. The customers that use the websites don’t care how software that runs the website (BigCommerce) works, they simply care that it works.