eCommerce re-platforming, start with the WHY! / Case Studies

eCommerce re-platforming, start with the WHY!

Start with the Why

I’m sure many of us have seen Simon Sinek’s Ted Talk “Start with the Why.” In the talk, he introduces the golden circle, which consists of what, how, and why. Sinek suggested that every company knows what they do; some can even articulate how they do it, but few get to why they do it. Companies looking to replace their ecommerce system often know what they are doing: replacing their ecommerce system. Some even get to the how, deciding on technologies and partners. But from my experience, few understand why they are replacing their platform. The re-platforming project will be complicated and expensive, and you will need a ‘why’ to align everyone in the company. Here are some of the whys that I have heard over the years:

Legacy systems that are no longer supported
Security concerns
Increasing total cost of ownership
Looking for modern functionality
Board/CEO/CIO/CMO — want something new and shiny

There are other reasons why, so make sure you understand yours. Often, it will have multi-layers. For example, who doesn’t want modern functionality? However, you need to ask yourself what you think you are getting. Is it enough for the investment? Technical debt and legacy systems can force your hand, but your why will need to be bigger than “we have to do it” to get you through the difficulty of the project. One last word of caution: while having your C-suite on board might be enough, wanting something new or shiny is not enough to sustain your project over the long run. Your Why is likely to be multi-faceted, and the better you can get to the bottom of it and get transparent with all stakeholders, the more you will set yourself up for success.

Requirements

To accomplish your why, you must decide on what you are building, which is the role of requirements. Requirements are an iterative process, starting with high-level requirements often defined by your why. I have been a part of many projects that required analytics. “Enable Google Analytics” would be recorded as a requirement for the project. That is a high-level requirement from the why, but you will need to define what types of data you need, what you want your dashboards to look like, and whether you have internal resources to build them. There are a couple of other watchouts when defining requirements, over and under engineering.

Once you start to understand your requirements, it is important to consider prioritization. One question that an architect on one of my projects used to ask was, “If this was the only thing not ready, would you still go live?” You will eventually have to make those decisions, so understanding what is truly necessary versus nice to have will make the project run smoother.

Over Engineering

As you define your requirements, you may over-engineer the problem. Industry trends, such as “composable or headless commerce,” can cause additional work and overhead.

I worked on a re-platforming project to implement headless commerce. We needed a high-level strategic resource to design the system, then an architect for the front-end work, an architect for the commerce work, and two or three developers for both the front and back-end work. Requiring a headless commerce system added overhead to the project. You may have an excellent WHY for using more complicated architecture, but make sure you know what you are gaining and what it will cost you.

Another common reason for overengineering is to future-proof your platform by ensuring you get every requirement in the first build. Not understanding or prioritizing your requirements can lead to everything being important and nothing being important. It also could prevent you from seeing times when an “out-of-the-box” solution could have been adopted with a few tweaks to the requirements, saving costly customization. Remember, you don’t just build these systems; they must be maintained and expanded to meet your consumers' needs.

Under Engineering

Under engineering can also be problematic; phrases like “Lift and Shift” or “Out of the Box” are often used to simplify requirements. With “lift and shift,” you focus on moving the existing site’s functionality into the new technology platform. It may seem the easiest way to avoid scope creep and constrain the project. It doesn’t work because not every requirement can be ported over. Most legacy systems were engineered over a decade ago, and there is a reason you are considering a re-platform. At the same time, you may have built those into your legacy system, but the new system tends to handle them differently. Another common mistake is using the “Out of the Box” functionality. You should select a modern e-commerce platform because they have already figured out many of the challenges you are dealing with.

Technology Platform & Partners

You have your team identified; they are clear about the why and have started the hard work of defining the requirements. The question is, have you already decided on a technology platform? It is tempting to lean heavily on the IT department to make this decision. They will, after all, be responsible for maintaining it, so shouldn’t they have the final say? Since a replatforming involves more than IT, it should be more than their decision. Your chosen platform has business, merchant, and marketing implications, so you must ensure everyone is comfortable with the decision. Some things to consider as you look at different platforms:

Are you B2C or B2B? Do you need to support other marketplace channels?
How do your requirements line up with the functionality of the platform?
Will this platform scale with your growth?
Support and community: are there resources to turn to? What does the broader partnership ecosystem look like?
Interfaces and integration: will this platform integrate with your backend systems?
What is the total cost of ownership, and what do maintenance, licensing, and support costs look like? How do they increase over time?

One last thought on platform selection: Make sure you talk to customers using the platform. Ask the vendor for references, but also do your homework. Reach out to folks in your network to get a sense of how people use the platform, what challenges they have had, and how they feel about it post-launch. You can’t have too many of these calls; they will help you understand what and how the platform works day to day.

Funding and ROI

You will need to understand the total cost of ownership and the benefits or gains the new system will bring. If your why is technological debt, and you have been in a maintenance mode, it’s more than likely that your new system will cost more. Your old system doesn’t cost anything and feels like a freebie. Not since the early days of commerce have I seen a new system with double conversion rates, so you will need to get creative about what benefits the business and your customers will derive from the project. Having the team bought into the why will pay dividends. Hopefully, they will be able to see the benefits. They could be as simple as freeing up your sales teams to have more time to sell and not take orders.

Once you understand your ROI, you can decide how to structure your project and its costs. I have seen two different ways.

Only fund the upfront work, requirements gathering, and UI/UX that informs the cost of the development portion of the project. I prefer this method, but most CFOs/CEOs won’t sign off on a project if they don’t have at least some idea of the total cost.
Get a bid for the entire project upfront. If you have done enough requirements gathering, you can look to get a bid for everything. Your system integrator should know what they typically charge, although none are typical builds. If you go this route, add 40% internal contingency to your request so that you have room for surprises. The last thing you want to do is have to go back and ask for more money.

The other way to manage costs is to be flexible with your requirements. From my experience, this is hard to manage. Most people feel they will never get the functionality if it doesn’t happen at launch. At one company, there was an internal joke that there “was no 2.0,” meaning that once something launched, it was there for good, and nothing would change or get upgraded.

Conclusion

The decision to re-platform your ecommerce business is always a challenging one. As Rick Watson once said, “No one ever got fired for not replatforming, but plenty of people have been fired for botched replatforms.” Starting with the Why, getting clear about your requirements, resisting the urge to over/under engineer, and selecting the right technology platform is crucial to having a successful re-platform project. Hopefully, this will help you understand the importance of firmly setting the foundation for your project. Even still, you can fall into many pitfalls as the project goes along. I will address those in my next article.