The Software Development Lifecycle for eCommerce (and everyone else)

You run an eCommerce business and there’s always a lot going on. Keeping customers engaged, sales moving, your team operating effectively, your operational costs in check, affiliates happy... I can keep going. With everything moving a mile a minute, the need to react sometimes kills planning and making sure things are done right. With speed sometimes comes pain, either immediate or down the line, which leads to wasted time, capital, and negative business impacts all around.

Over the past 20 years, having been a Founder, CEO, Head of Product, VP Platform, Software Engineer, and Venture Capitalist I’ve had the fortune (and heartache) of going through software product development from every angle.

So, I thought I’d put together this post describing the Software Development Lifecycle (SDLC) to help describe how software development happens, roles in the process, and expected outcomes at each stage.

The benefits of understanding and aligning across the SDLC include:

·      Save time and money

·      Better customer experiences

·      Efficient business processes

·      Happy, high performing team

·      Happy, converting customers

Here’s how this applies depending on where you are in your growth:

 

·     Starting out - Requirements, Design (UI/UX), and Testing

You’re on an all-in-one platform (like Shopify) and don’t do much development since you’re using standard themes and plugins. As you grow, you’ll be changing the experience, adding integrations, and customizing plugins.  

 

·     Growing brand - Requirements, Design, Testing, Deploy, Maintain

You’ve got an agency hacking away to customize your theme, using a lot of plugins, worried about conversion, have integrated outside services for analytics. You’re not really developing your own software.

 

·     GrowthMode and bigger brands - The full SDLC

You’ve now have even more in your architecture and have hit the limits of what that all-in-one solution provides and are either thinking of replacing it or have already for a more scalable solution. You’ve got some or all of fulfillment and financial systems, API integrations, an application storefront, deeper analytics, etc. You’re developing your own software or have an architecture based on lots of integrations.

 

Great execution means a great team communicating and working together. Creating an awesome experience for your customers works the same way.

  

The Big 4 of Product Management

Before we get to software development, the process really begins when a need is first identified that requires investigation. This is typically a high level need for any of the following reasons, which I’ll call the Big 4:

  1. Strategic: Strategic importance to the business, long term goal
  2. Feature: Product feature to meet or exceed competitors
  3. Defects: An issue has been identified with the product and needs to be fixed
  4. Tech Debt: Known items that should be corrected but are not critical

…or in real-life:

”hey, we need to start subscriptions, can we get that in by next week?”

“We’re launching a new product tomorrow only to people that visit on mobile. Oh and it also needs a discount attached. And only in Canada.Is that easy to do?”

You get the point.

Such is the life of your Director of eCommerce or Product Manager. I’ll plan to dive deeper into Product Management in another post (subscribe to our newsletter so you don’t miss it) but these four areas broadly make up the basis for what gets includes in each cycle to varying degrees based on the current needs of the business.

Software Development Methodology

 

We won’t dive too deep into the various software development lifecycle methodologies but it’s important to note the two majors and how the SDLC applies. The differences are simple to understand and regardless, the SDLC guides the path and the triangle must be respected if you want to deliver quality products.

 

Waterfall:

-      List of requirements that define a fixed scope that needs to be delivered

-      Costs and schedule will likely change since you’ll likely need more resources and time to deliver the full scope

 

Agile:

-      Fixed schedule (e.g. two-week sprints), deliver within that time and resources

-      The schedule doesn’t change, the work and resources might

 

With an agile approach you do the same requirements gathering and feasibility as waterfall in order to fill a backlog of work. Then, you prioritize and fill your work cycles from that backlog based on yourBig 4 needs and deliver iteratively. Development moves faster and you get things out the door in smaller chunks vs. waiting until everything is done and doing a large release.

 

Phases of Software Development Lifecycle

Once you’ve identified your needs, the SDLC can be divided into the following stages and we’ll dive into each stage.

 

Phase 1: Requirements Gathering & Validation

C-Suite idea: “We need our customers to be able to wear these shoes in the shower”

Product Manager: “Why?”

C-Suite: “Because I like to wear shoes in the shower.”

Product Manager: “That’s nice. Give me actual customer or market data please.”

The point is that every requirement should at least be challenged for validity. Some might be obvious while others are based on a dataset of one, legally not allowed, or simply out of left field. If you’re not validating needs you’re doomed to waste time, money, and probably give customers features they didn’t ask for and impact conversion. Note: Anything is possible but doesn’t mean valuable.

That old adage that people don’t know what they need until you give it to them? Not really, there is always a test of validity. Apple spends millions every year on projects behind the scenes that never make it to market. You don’t need to spend millions; you just need to make decisions based on awesome innovation or actual need.

Requirements Analysis and gathering is the single most important step. It’s your foundation, and every step forward relies on your teams being aligned on what needs to get done.

The Requirements Phase breaks down like this:

Purpose:Your whole team is on the same page

 

Who: Senior stakeholders from each effected group and sometimes industry experts, etc.

 

Input: Idea, innovation, customer feedback, sales feedback, market need, etc.

 

Output: Gain a clear picture of scope, capture the need, why it matters, assumptions, risks, actors, next steps. Provide the basis for test cases.

 
Deliverable: Documented requirements signed off by stakeholders, input to test cases.

You might decide to capture requirements as stories in your project management software, create a requirements specification document; it doesn’t matter, the point is write down your requirements and get sign-off from stakeholders

Requirements will likely change as you move forward and new information becomes available so keeping the master record of documented requirements updated is critical to keep everyone moving in lock-step effectively, saving time and money.

But, if you have an unlimited budget and all the time in the world then feel free to skip this step. And I’d love to meet you because you are a mythical creature.

 

Phase 2: Feasibility

Once you’ve got your requirements documented the work begins to figure out what it takes to make them happen. Could be something easy or require more conversation and investigation.

But, again…the triangle must always be respected if you expect to deliver quality.

When determining what it takes, there is simply no getting around the fact that you must make trade-offs:

·     Scope: How much needs to get done (features, functionality)?

·     Resources: How much money and how many people do you have dedicated?

·     Schedule: How much time do you have to deliver?

Want to get something deployed faster and make sure it’s done right? You’ll need to either reduce scope or add more resources, otherwise quality will suffer. Makes sense.

The Feasibility Phase breaks down like this:

·     Purpose: Determine feasibility based on scope, schedule, and constraints

·     Who: Product and Engineering Management

·     Input: Requirements

·     Output: Software Development Schedule

Phase 3: Design

Time to design! Design can include some or all of these areas depending on what is being developed:

·      Product User Interface / User Experience Design: what the product looks and feels like.

·      System Design: the software and system architecture, integrations, etc.

·      Organizational Design: impacts to the organization including processes, workflow, etc.

Designs are defined based on requirements and help everyone to understand how the software needs to be developed and impacts across the organization.

Although you’re likely thinking “isn’t design my website/store experience?” it’s more than that.Remember, we’re talking software here and software and systems need to be designed before they can be developed.

UI/UX design is fun, exciting, beautiful. We can all see and appreciate it so it gets done.

System design is behind the scenes, lines and boxes, boring. Skip it at our peril.

It’s up to you when to put in the effort to not only design what customers see but how the tech behind the scenes interacts, but the sooner the better. No matter how small your tech teams are or how they’re organized you should always have at least high level system documentation. As your company and teams grow across engineering, architecture, and systems, then it’s even more important to have low level system architecture documentation.

If you’re using an all-in-one platform for everything then you likely don’t need system design but if you’re starting to integrate outside systems or building your own architecture, then typically you’re looking at creating system design documentation.

High-Level System Design Specification(HLD)
  • Overall architecture diagrams along with technology details
  • Name and description of each module
  • Summary of the functionality of each module
  • Relationships and dependencies between modules
  • Database schema and tables including keys and elements

Low-Level Design System Design Specification (LLD)
  • Describes the functionality and logic of each module including inputs and outputs
  • Detail of each interface (e.g. API specifications)
  • Describe database tables (type and size)
  • Describe all dependencies and issues
  • List and describe all error messages

The Design Phase is like this:

·     Purpose: Ensure everything that needs to get built is well defined

·     Who: UI/UXDesigners, Developers, System Architects (depending on your size it could be your CTO, VP/Director Engineering, Senior Engineer, Architect, you get it)

·     Input: Requirements

·     Output: UI/UX designs and components, System Design Specifications

 

Phase 4: Development

This phase is short to describe and the longest phase of the SDLC. We’ve moved through validate >define > design and now it’s time to build!

Tasks are divided and planned out across the development team. It’s up to your engineering manager how to divide and assign tasks and also when new software versions will be deployed (hot fixes, two-week sprints, monthly, etc.).

What’s important is that your engineering and product teams are aligned on methodology (e.g. agile) and on priorities (the Big 4).

Also, the development team should be choosing common programming languages, compliers, task management, debugging tools, etc. You don’t want everyone using their own stuff.

Finally, the developers should be unit testing their own code to make sure it works and then testing in a staging or testing environment to make sure they didn’t break anything else.Even better if you have automated regression testing but we won’t get into that here.

The Development Phase

·     Purpose: Build software

·     Who: Product Manager, Engineering Manager, Engineers/Architects (tech people)

·     Input: Designs (and they also lean back on the SRS…like we said it guides everything)

·     Output: Awesome software/product, deploy for testing

 

Phase 5: Testing

Ok the software is built(e.g. your amazing store, new feature, etc.) but before it goes out to the world it needs to be tested to make sure things work as expected. This is functional testing and there’s nothing complicated here, but unfortunately it’s where a lot of corners get cut.

Here’s how to make testing successful not painful:

1.    Turn your requirements into test cases. That’s what your business people or a QA team is doing while design and coding is happening.

 

2.    QA team(or business people) do the functional testing. Your development team should not be your testing team. They built it and won’t test and find things like a customer.

 

3.    Regression tests should be with every deployment to make sure nothing breaks. This means creating scripts that should be executed, and even better, automated.

 

4.    Use a bug tracking tool to make validating, assigning, fixing and re-testing issues efficient. Be sure that everyone updates their tickets, this goes a long (long)way!

In the end, your goal is to make sure there aren’t any major issues and you’re comfortable launching to the adoration of your customers and envy of the competition.

The Testing Phase:

·     Purpose: Test what was built based on the requirements that are expected

·     Who: QA Manager, Engineering Manager, Testers, Developers

·     Input: Test Cases and Scripts (based on the requirements), Software

·     Output: Awesome software/product that’s ready for the world

 

Phase 6: Deploy

Here’s where the world gets to enjoy all the hard work. The software is deployed into your production environment, checked for any issues, and live. If you’re following agile methodology you might be deploying every two weeks or packaging up two sprint cycles for a monthly release, it’s up to you.

 

Phase 7: Maintenance

Finally, you always need to make sure things are humming along beautifully while you’re back up to the start of the cycle for your next set of fantastic innovations and capabilities.

Sometimes you might need to fix something that was missed in testing (called a “hot fix”) or upgrade the version of an interface because the 3rd party/partner has changed things on their end. No problem, you can execute on the emergencies while planning upgrades and enhancements as part of your SDLC.

 

The Last Word

If you’re a brand just starting out then as you grow you’ll inevitably run into more unique and complex use case, your basic themes and plugins become restrict your ambitions and you’ll start adding more integrations, systems, and building a lot of it with your team or partners.

To optimize customer experiences and operations, a solid understanding of the Software DevelopmentLifecycle and Product Management is a must. Put your new found knowledge to work, share with your teams, and deliver effectively.

Of course, if you’re looking for the fastest, most flexible eCommerce solution on the planet designed to keep you in control as you grow then check out Shopistry. Onward my friends.

 

Stay updated on new posts, tips, resources and more!
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.