Let’s face it – the prospect of starting from scratch and launching a fully functional eCommerce presence online is daunting. From the number of internal stakeholders involved and level of effort to get everyone in agreement to the cost and technical decisions that will need to be made – it’s a large project to take on.
So, if your organization is not ready for a full-blown eCommerce website, you don’t have to start there. There are a number of options to successfully build and launch a smaller project to get things in motion. It’s an approach we like to call “Light eCommerce.”
What does “Light eCommerce” mean?
Before you can define what it is – it’s important to know what it isn’t. Light eCommerce means, in short, not building everything all at once. In other words, you can start anywhere or build anything you want, but don’t build EVERYTHING. At least not right away.
So, if I’m not building everything how do I know what to build?
If you were to sit down and draw up the design, development, and engineering that could be done to fully build out that eCommerce project for your company, you would end up with an extremely long list of “requirements.” The to-do list would be intimidating and end up creeping into months (or years) worth of effort. Therefore, it’s important to clearly identify the “needs” and the “wants” from your internal stakeholders. Compile that list – we’ll review it later.
The wants can be as simple as concepts or ideas:
- “>product information online
- Create a small product downloads and resources portal – secured by login
- Improve product content for SEO
- Generate leads or improve product awareness
The “light eCommerce” part is then reviewing these requirements and determining what is feasible to get launched quickly.
Step 1: Will launching “light” work for us?
Why can’t you launch everything now? Acknowledge and recognize what might be holding you back:
- Cost?
Aspects of the process are going to require significant investment in terms of time and money – from design and development to copy and other marketing investment, there are a number of cost factors. - Are there any cost savings to doing some of the work internally?
- Are certain portions of the development more expensive than others?
- Lack of internal buy-in from all departments involved?
There are likely to be internal stakeholders who haven’t bought into the change that a full eCommerce implementation can (and will) bring to your organization. - Internal Team?
No project manager or internal team with time or expertise to help lead the project. - Technical Challenge or Impediment?
There might be an existing system in the way or your internal team is missing an associate with required technical skills and experience.
Step 2: Identify Quick Wins in the Requirements List
You worked with your team and have a lengthy list of requirements – now it’s time to determine what’s included in that first round. You can choose to sort the requirements into two lists – a “now” list and a “future” list or go further and divide the future list into longer-term phases (Phase 2, Phase 3, etc.).
What can I use to determine whether or not to include this item in the “Light eCommerce” phase?
- How much time, money and effort are required to get this done?
- Does this item require getting a larger number of related items done?
- What kind of impact would this requirement have on the business (sales, support, etc.) if it were completed?
- Do we have the resources (experience, money, time, etc.) needed for this requirement?
- If large, complicated or expensive, can this requirement be broken down into smaller parts?
- How can we measure success?
What should be delivered?
At the end of this step, you should be able to create a high-level list of the functionality that will be included in the launch “Light eCommerce” phase. The list should have enough detail and clarity for your technical team to begin an engineering phase – creating a detailed statement of work, functional specifications, designs (if necessary), wireframes and project plan.
It should have enough high-level depth and detail for everyone to understand what’s going to be delivered. For example, instead of “Product Catalog” you may include “Catalog: Display a listing of products with a link to more information organized by category” – clearer and more specific to everyone.
Lastly, as that list is built out – make sure the same internal stakeholders who helped you build the requirements list have a chance to review it. There are likely to be some who are disappointed when they realize their pet projects aren’t included in the list, however, at least you’re informing them ahead of time. Be prepared to explain why something was or wasn’t included in the “Light eCommerce” launch.
Step 3: Review & Plan The Quick Wins, Beware of Feature Creep
You’re building and launching something that you know is incomplete and there’s likely to be some really great stuff that everyone wants – it’s just going to have to wait. There is often a tendency during any of the subsequent phases (engineering, design, development) to begin to add back those non-priority items.
“Wait, can’t we add this?” or “Aren’t we missing?”
The short answer is… yes, it is missing and it was probably done on purpose.
Slowly, over time, features and new changes creep their way into the process. While most requests are relatively minor – they can begin to add up to a significant time investment when totaled together. More importantly, they slow down the process – your quick wins turn into something significantly less “quick”. Additional requirements and changes mean more development, more testing and more delays.
So, how can you avoid feature creep? Planning!
1. Set Dates and Timeline
When timelines and dates are outlined, stakeholders can adjust their expectations and prepare to deliver what’s expected of them to meet these deadlines.
Don’t be afraid to let a timeline adjust your “Now” list. If the timing is too far out – are there things that can move to the follow-up phase?
When the time comes to actually put time estimates and delivery dates for the list that’s been discussed – the truth tends to come out in terms of the level of effort. Be prepared to adjust accordingly.
Remember that working with your project management process (or your web development teams) means that there may be some tasks/features that can happen immediately while others will take up the entire time you have budgeted.
2. Refer to the List!
Once the work starts – the change requests are also likely to start. Using your “Now” and “Future” lists and your timeline, you can determine where those changes and requests should fit in. Is the change important? Will it make something you’re committed to dramatically better? Can you live without it?
3. Communication
If you haven’t communicated your plans internally – the rest of your team will assume they don’t exist. For each phase of your launch of quick wins or milestones that you establish to get things rolling – set a target date and communicate that out.
You will need to decide how much (technical) detail you go into based on the team you’ll be communicating with, but it’s important to fill everyone in. Regardless of the makeup of the team, you’ll be outlining three key things:
- What You’re Launching
- How Long You Expect it to Take
- The Goals of the Launch
Step 4: You launched something – now analyze what you’ve done
The changes you make don’t happen in a vacuum. Making changes, updates and launching updates should have had some impact on your plans going forward.
Refer to the last bullet point in “Step 1” – how can we measure success? Beyond those measurements, there are some key points to focus on in order to move into the next phase.
- How does this first project impact the next items on your requirements list? Are they changed?
- Did some piece of what you’ve launched necessitate moving another project up or down the priority list?
- Were there any surprises – positive or negative – in the reaction or results from what was launched
Step 5: Promote & Plan
Your team showed some good hustle and got something launched quickly plus you received some good feedback – now it’s time to talk about it.
Set aside some time to review the results the organization is seeing and measuring post-launch. Depending on the audience, go into as much detail as you need to. “This is what we did… this is why and here’s how it’s a good thing…” For example, if you launched some new content or tools for the sales team – let them know about it. Especially when it affects how they can do their job.
Don’t fall into the trap of building something that never gets used because your team isn’t aware it exists, doesn’t understand what it does or hasn’t let anyone know it doesn’t work.
Finally, it’s time to go back and begin planning the next steps.
