The Case for Continual Development: The New Way to Approach Ecommerce

In many cases clients can be extremely reactionary when approaching the design of their ecommerce websites. They see a successful site that has reviews, so they want reviews on their own. They see another that approaches checkout in a certain way, so they want that too. This list of reactionary client requests can go on and on.

But for the ecommerce projects we work on to be successful, we need to start engaging our clients in a new, different way. We need to look beyond simple, fixed scope projects and begin advocating for continual development in all ecommerce projects we take on.

Challenging the ecommerce project status quo

Many site owners have been heavily influenced by Amazon.

We know that any website’s success is a lot more complicated than slapping on reviews or designing the perfect checkout. Yet in the ways that matter, both our clients and ourselves fail to embrace the lessons we can learn from these exceptional ecommerce experiences.

Take, for example, Amazon’s commitment to continual iteration. Amazon didn’t just build their site, and walk away. They didn’t even do a periodic redesign every few years. Instead, they have been evolving both their website and business model organically over the years (it’s easy to forget that Amazon started out selling books).

Amazon has continually evolved over the years.

Unfortunately, few ecommerce clients work in this way. They come to you asking for a fixed price project, where they launch and then consider the site 'finished.'

We don’t help either. That is the kind of engagement we know well, and so that is how our processes are set up. We define a specification based on the brief we receive. We build to that specification, and then move onto the next client.

But things are changing in our industry.

Clients are becoming better educated, and many agencies are adopting a different model. A model where they act like an internal development team for clients, one that iterates and improves websites on an ongoing basis.

In such engagements, things are different from the outset. Instead of a detailed specification, the project begins with a Minimum Viable Product.

Begin by launching a Minimum Viable Product

Many of the briefs we receive from clients are a wish list of functionality. Features that they might not need today, but want built-in from the start just in case. Features like real-time integration to stock control systems, CRMs, or finance software.

These kind of integrations make sense when the site is generating large volumes of traffic. But they aren’t essential on day one. It’s possible to import and export this kind of data by hand, when sales are low.

Building these kinds of features in from the start doesn’t make sense from the client’s perspective. They increase the cost of initial development before clients are sure they can generate a return from the site. But clients want these features because they see the competition have them, or they have seen them elsewhere. Clients fail to grasp that they can add these features over time, and that they don’t have only one opportunity to engage you.

Of course we don’t argue. We build these features anyway, happy for the extra revenue. But what if we didn’t?

What if we instead built a Minimum Viable Product? The most basic version of their site possible. Sure, we would be turning away short-term revenue. But it would establish the basis for a much longer-term business relationship.

For a start, the client is going to like us. We have just reduced their costs, helped manage their risks, and enabled them to get to market faster.

By putting out an easy Minimum Viable Product, they can gauge interest and begin generating revenue. Revenue that they can put back into further developing the site.

But most of all, it establishes the principle of continual development.

Focus your business model on continual development

By holding back on some features in the short term, you establish the idea that an ecommerce site is never done. You get the client thinking about phase two and beyond, almost immediately after the initial launch.

You are also holding back some budget for post-launch improvements. This means that once your Minimum Viable Product is live, you can start monitoring how users interact with it.

Together with the client, this will help you start identifying problems. You can run usability test sessions, and discuss possible solutions that you can then prototype and test before releasing to the public site.

In essence you are introducing the client to the basic process used by the companies they revered at the onset of the project. This is the cycle of monitoring, experimenting, and building for the long-term.

We need to introduce clients to the principles of Lean UX that include continual iteration.

When you think in this way, the traditional relationship between client and developer breaks down. That is why you will need to introduce a different way of working together as well.

Embrace a different way of working

A series of fixed price, fixed scope projects make little sense in a world of continual iteration. You need to monitor the website and find solutions for the problems you encounter. You cannot do that if you are not working on the site.

Some ‘solve’ this problem by offering support contracts. But is that a solution?

I would argue it’s not. You see, most support contracts rely on the client coming to the developer with specific work they want completed. We need to be more proactive than that. We need to be the ones watching users and fixing issues. After all, we are the ones being paid for our expertise.

Perhaps it’s time more of us throw out the old ways of engaging clients, and start working on retainers — committing to an agreed number of development hours in return for a fixed monthly fee.

This model makes more sense for everybody. It helps your cash flow, making the future of your business less unpredictable. But it also makes more sense for the client too, as it reduces their upfront cost and makes the expense of running their site more consistent.

Of course, clients may be reluctant to commit to a long-term relationship on day one. That is where the Minimum Viable Product comes in. You could develop your MVP in a more traditional fixed price project. If the client is happy with the working relationship, they can move to a retainer. If not, they can take the site elsewhere.

Once that first site is live, the relationship changes. You move to a retainer model, where you are the one actively managing the feature set and user experience of the site. This is when you start constantly looking to improve the conversion rate, and other related micro-conversions, on the site.

You also could take this model even further. You could take on the management of the entire online experience, from marketing to placing an order. If you have that kind of end-to-end control, then you could waive a monthly retainer in return for a percentage of sales. This further lowers the risk for the client, but allows you to enjoy more of the rewards of your own work.

There is no right or wrong way

Of course, there is no “right” way of running an ecommerce project, and the ideas I have outlined here will not fit every client.

But that is the point.

I believe many of us have fallen into a pattern in the way we engage clients, when there are so many more possibilities. It’s time to consider other approaches beyond fixed price, and explore how we can build continual, long-term working relationships with our ecommerce clients.