The idea to open an online store comes to head of probably most of the owners, and the decision usually goes one of the two ways:
Some believe that setting up an online store is a simple and easy task. In this case, the new owner usually spends little to no time thinking about any sales strategy, calculating the budget for promotion and development. They simply open the website builder, make few twists with templates, post products that they consider necessary - and voila, the webshop is ready. Even though this can be an acceptable technique for testing certain categories, but not for everyone. Many stores, which started quickly, also close quickly - the customers did not rush to buy those goods, the budget for promotion and daily operation was not calculated, or some other organizational difficulties arose.
And then there are those who believe that an online store is a serious endeavour, which requires detailed studies of the market, product, competitors and customer behaviour. In this case, the owner tries to foresee possible challenges and create the most functional store and service. The goods are properly selected, the assortment is formed, the potential customers identified - now the task is to start the business and automate the processes. A well thought out website is an important part of these business processes, it can become one single most important tool to save time and cost for the owner while driving sales and generating revenue. However, in some cases, the startup process is too complicated and turns into a real problem.
In this article, we will talk about the owners who don’t gamble on luck and think ahead. About those who have already tested their product decided on a niche market, assembled a serious assortment and wants to open a proper online store, with a view to grow sales and scale-up in future.
No matter If this is your first or even second online store, it is often difficult to find what are the priority tasks. It is even more difficult when there is a lot of pressure from ‘Big Boys’ - large competitors with their hundreds of thousands of customers in the database, Big Data, full automation and other intricate things. Needless to say that gathering such a big customer base and having all this functionality costs a lot of money.
However, the most important thing when starting an online store is to launch it quickly, without delay. At the same time, it is important to keep cost under control and withing specified budget, with the aim to break even and turn a profit in a short time, because, at the end of the day, the aim of business and store is to make a profit.
The market situation is constantly changing, and some times can be unpredictable. The project must be launched in the given time frame, otherwise, the owner has a choice a) to push for an increase of development speed before such changes occur, or b) constantly change the start conditions, which can become extremely unfavourable. In addition, the delay in launching an online store is lost opportunity and obviously lost profit.
In other words, the speed of entering the market is at most importance. No wonder business people always talk about Speed to Market as one of the prerequisites of a successful launch.
Earlier we have already found out that the sooner we launched the store, the faster we potentially can start earning profits. But how to build a store structure so will help to earn money instead of interfering with the sales process?
For that, we need to define a list of functions that will be sufficient to launch a store that in turn can start generating sales and provide effective customer service. That is, the MVP (Minimum Viable Product) of your online store.
There are many books written about MVP and how it can help any business. In the nutshell, and also a very important point: MVP is not the final version of your product! This is just the starting version but developed enough with most necessary functions that will allow you to test your ideas and strategy and adjust on the way. Once you have launched your store, you can immediately begin to expand it by introducing new services.
Another important point is which store is considered small and which is medium?
In this article, for convenience, it is assumed that:
It seems to be successful it is necessary to start big. Before our eyes are those Giant Online Stores where everything is complicated: personal recommendations, a complicated personal accounts for a different type of buyers, a number of various promotions and marketing campaigns, bonus programs and cashback, automation and other advanced features. It gives the impression that it’s absolutely impossible to do without all of this, and all these features cost a lot of money and a considerable amount of time to develop. But it is good to remember that a modern time giant Amazon was founded in the garage with just a small team to take care of the customer service!
And at our launch stage, it will not be superfluous to remind that the main purpose of the store is to sell.
Perhaps, in your small store, at first, there will be a limited number of functions and amenities - however, it should meet its main goal: to sell the goods and not interfere with the owner to receive payment for goods sold.
The classic process of development implies that the owner spends time to think through the entire structure of the store, up to the smallest details, and then transfer it into the comprehensive Software Requirements Specifications. This document (SRS) is the starting point and a guiding map for the developers, first to evaluate the project and secondly to follow during the process of development. The development process and planning can be described using various methodologies, but that is not a topic of this article.
During the project development many challenges could arise:
Lean-method of development (and, in particular, the version of it called the Agile method) can help to optimize the process. In the case of a small store, it makes sense to initially agree with the developer that:
Having determined the composition of the modules and the overall project budget, you can hand over the Software Requirements Specifications (SRS) in parts as the project progress and modules being developed. On the other hand Requirement Specifications for the design itself, it is usually formed separately from the development, and it is desirable to submit it to the developer as a complete document, and not in parts. As for the development, as a rule, they begin with the implementation of the catalogue - accordingly, first of all, you hand over to the developer description of the general structure of the project and a detailed description of the catalogue, and further down the list of other modules.
Agile implies that you keep a close track of the project development process. In the Agile method of software development there is constant collaboration between cross-functional teams, and where requirements and solutions can change and evolve as the project moves on. Good planning here allows breaking a project into smaller pieces that can be taken in parts during the development process - for example, a separate product card or separate news. It is also possible to combine these task pieces into longer sprints, but not necessary. What is more important is to control intermediary results, where the developers present for review a completed smaller task with shorter intervals of around three days. Such intermediary reviews will allow avoiding bigger mistakes and in the event of an error to correct them quickly, while avoiding irritation of the development team if more rigid controls and shorter intervals are applied.
There are some developers that might find such control uncomfortable as it seems the owner of the projects does not trust the development team. Yet, this is not about trust and should not be misunderstood as such: control is required to make sure that tasks are well understood and no big mistakes happening. At the same time checking smaller tasks helps to keep the entire project well on track and avoid unexpected setbacks where corrections might be costly in terms of both money and time. The easiest way to get rid of such setbacks is to break the project in smaller sections (tasks) that are easier to control and fix. Secondly, it is also possible to begin work on uploading contact and product catalogue once some modules are ready and approved, subsequently reducing total development time.
One should always manage expectations and set reachable targets in respect of the development schedule. Pushing the development team to do tasks faster than they committed might be counterproductive and often cause frustration to both parties. Therefore it is very important to agree on the time frame while factoring in some unexpected delays or challenges.
The main mistake that beginners often make is the desire to do everything perfectly while forgetting old wisdom that “Perfect is an enemy of Good”. This often results in the following issues:
Imagine a situation, where the store is almost ready, just a few modules left and it can go live.
... And suddenly ...developer suggests that database can be optimized, things can be improved, and anyway, seemingly working module can be developed further improving ease of use and perhaps adding functionality that might (or might not) be needed in the future. It is not a Must at the moment, just Good to Have!
Technically, the programmer is right, he wants to make his task as best possible, and perhaps even better. But that would mean redoing half of what is done, turning back and rescheduling the launch of the project. And let’s not forget, the market does not wait, conditions are always changing, new competitors are coming.
In most of the situations, the correct decision would be to put such improvements aside, perhaps to the later stage. Remember we talked about MVP? The point is that the project is almost finished. Perfect or not, at the very least, is working, and ready to bring sales and revenue. To start an alteration right now means lost profit and the beginning of long-term development, and this could become a never-ending story.
The store is created for customers, let them judge which functionality on the site to be and which not. The store is not created for Developers own portfolio.
At the end of the day, once the store is up and running, there is ample time to do analytics: find out which sections users go to most often, is it convenient for them to use the basket, sortings, etc. Based on such data and customer feedback it would make a much wiser organizational and financial decision to change or add some functionality on the site.
But at the same time, your imperfect website will already work and bring you income!