How to crash your e-commerce?

19 Aug How to crash your e-commerce?

After more than fifteen years developing e-commerce for almost thirty customers, we have gained some important lessons, which have become basic premises for new projects to work correctly, mainly from the perspective of technology. On this path, we list a series of errors that are more common than they should be. Are they:

1. Approach the waterfall model:

Trying to guess all the requirements, the architecture, the designs, doing all the coding before testing and not knowing the user feedback is the most common mistake and the one that destroys the most value. You’re going to spend a lot of energy on a portal that, when the integrated testing starts, will show you the real state of the product and have thousands of issues taking you back to square one. At this point, the project will restart under enormous managerial pressure. Such pressure of the deadline that has already been spent will cause the product to have low quality and a lot of technical debt. The best way to develop a website is to approach the problem in learning cycles: do it, measure it, learn it, and change direction as often as necessary.

Even when it comes to e-commerce, which is widely discussed and studied, each business has particularities that need to be validated. There are several types of products: physical, virtual (generally services), packages, digital, subscriptions, etc., and each type of product involves a different back office (logistics, financial, commercial, production, after-sales, etc.).

2. Hire an advertising agency before:

Nothing against advertising agencies, but they would have to work together with the team and with a sense of team. The visual identity and information architecture must be done taking into account the Product Owner (PO) vision, technical and business constraints or the e-commerce platform. Developing a site that is primarily concerned with out-of-context layout leads to a first version with too many features and appropriates a mandate that should be the PO and the team.

Want to hire an agency, great! But her UX team has had to work closely with the development team from day one. Otherwise, the development team will be left with a backlog full of unnecessary features for going into production and the project will be susceptible to birthday(s).

3. Ignore the complexity of integrations:

Uploading an online store these days can only take a few weeks or even days, especially when it comes to cloud computing. The problem after that is feeding it and putting it to operate cohesively with the other systems. In our experience, integrations account for more than half of the project time.

You have to understand that an ecommerce is not just a website. It is a network of complex features that has to be thought of as a set of functions and that is integrated with a much larger legacy, like the metaphor of the tip of the iceberg. It is necessary to understand the relationships between the distribution center, the various forms of payment, after-sales management, fraud control and delivery logistics as well as the sales process on the website. The classic phrase is “now we just need to integrate”.

Integração de e-commerce

4. Only perform functional tests:

Imagine opening your website on the eve of a big sale or Christmas without support to handle all the purchases? It’s going to be a disaster. In addition to losing precious sales, your brand may fall into disrepute in the market and you will bomb on social networks #soquenao. Your e-commerce can look great and seem to work perfectly well until you put it into production.

It is extremely important and crucial to perform load, robustness and availability tests to try to anticipate how your portal will behave when traffic arrives. And it’s not just about application server, you also need to check disk I/O, network I/O between servers and Database load, mainly. The latter is most requested when your e-commerce maintains persistent carts or gift lists.

5. Do not use cloud:

If you don’t have the ability to change the architecture and scale your site horizontally to react to what will actually happen in practice and support the traffic that will come with the launch strategy, it’s best to hire a telepath to predict how many additional servers you’ll need and based on that, negotiate with your Datacenter, internal or external. Using cloud you can do this automatically as long as you have good server load ratios, either by network I/O, CPU load or allocated main memory, and your cloud hosting provides tools for auto scaling.

6. Don’t worry about charging time:

Time really matters on an ecommerce website. One more second of waiting and your consumer can give up on making a purchase that would have been won. According to Kissmetrics research, you can lose 10% of conversion in just one second. Letting all the load hit the application server is a problem, even more so if you spend money licensing your platform by CPU.

Use distributed cache to store images, css and javascript files. About ten years ago it was difficult to find such a service and when I did, it was very expensive. Nowadays, speaking of AWS CloudFront you will spend a few “Franklin” per month and, if you put it on the tip of your pencil, the cost of traffic that left your application server will be worth a lot.

7. Pay more on the product than on the service:

The platform alone will not solve all your problems. More than that, it is important that the team that will implement your website knows what it is doing and how it is doing it. Hire a team that does the right thing the right way and treat the platform as a first release that will iterate over the production experience. Also in this topic, be careful when switching platforms. You need a turnaround strategy that allows you to keep traffic split between the new version and the old version until the conversion level of the new one reaches the level of the old one. This allows you not to use an abrupt “roll back” strategy (by the way, you also have to test your roll back strategy).

E-commerce platform is not lacking in the market, it has for all tastes, be it technology, price or suitability. The most used by technology are:

PHP: Magento (eBay), Pinnacle Cart, WP e-Commerce (WordPress) and so on.
JAVA: WebSphere Commerce (IBM), ElasticPath, ATG (Oracle) and Intershop.
.NET: ZNode, Magelia and AspDotNet and so on.
Python: Satchless and even Open-ERP.
Ruby: Spree.

8. Launch the website with full functionality:

Here it is important to understand the concept of Minimum Viable Product (MVP). You don’t need all the functionality of your e-commerce to be ready before putting your website online, but just enough so that the PO, the marketing team and the project team can start testing hypotheses to improve the service and the conversion rate. Understand and organize the requirements needed to go into production of the site. Separate only the things that impede the sales and after-sales process; this will be the first release. Demands that do not impede these processes can be left for later. An important thing to emphasize, the lack of non-impeding requirements in the delivery should not be considered as incomplete delivery or lack of quality, just one step of the entire journey that still lies ahead. Thus, you can learn from using the site itself to develop what is missing without being in the dark.

Minimum Viable Product

9. Assemble a basic deployment team:

It won’t do any good if you set up a team of developers only, with a business person or the designer as Product Owner and a Project Manager. Good multidisciplinary teams, with well-defined PO, Marketing, Devops, client and server developers, Scrum Master and UX tasks are essential for any digital product. Forcing unskilled people to perform other types of services will turn your site into a carnival of things wrong. Don’t risk your success.

10. Contract the service with scope/closed cost:

Having the notion of time and cost for budget planning is essential, but don’t take this as a fact for the project for a simple reason: it will change, you can control cost and maintain quality, but for that you will have to make requirements more flexible. The main reasons for these changes are the lack of definition and the influence of external factors. The change generates rework and in the closed scope it means that you spent much more time to do one thing than planned – then you will have to do “change management”. From there, either assume it won’t change (it’s going to be wrong) or open the scope. I don’t think anyone in their right mind will decide to leave it wrong.

How about you, how do you treat your e-commerce? Leave your comment here!