Great tech doesn’t have to be complicated. The easier and more accessible it is, the more people will use it, love it and benefit from it – and the more successful its creators will be.
Simple, right? Unsurprisingly, in the SaaS age, it’s an approach we’re seeing from many of today’s tech innovators. They’re making tech that’s incredibly user friendly, intuitive and easy to get to know, with in-built tips and support rather than in-person training sessions.
But tech companies are also making the process of adopting that tech simpler too. With so many free trials, freemium offers and opportunities to buy extra services in-app, the risk is removed from trying new tech – or at least made so small it’s a risk worth taking.
It’s radically changed the way so many of us adopt new technology for our businesses. Of course, there’s always a central need at the heart of any new tech adoption – something we want to be able to do better. Historically, businesses have resolved this using a waterfall approach.
What’s a waterfall approach?
Well, it looks a bit like this: You conduct a fact-finding exercise to scope out your requirements, you then assess those options, narrowing them down bit by bit until you have a winner. You plan your roll out, buy the software, build it in and begin using it.
It’s like a funnel – a lot of time and effort goes in up front and you come out with one intensively researched new way of doing things. Before the internet, it was the only option – software was paid for up front and came on CDs or floppy disks, with no option for regular updates.
Traditionally, the waterfall approach has been a good way of mitigating risks, and a sensible choice when the stakes are higher – financially, operationally or in terms of brand reputation. It’s a careful, methodical approach that many still favour in these circumstances.
But here’s the thing about waterfall: it’s not a fast process. Once you’re done researching, there’s often lengthy procurement work to do. And while you’re doing all that work, you’re running the risk that your competitors will beat you to the solution or customer demands will evolve (as they so often do). Even with all that research under your belt, you’re still putting all your eggs in one basket. What if, when your team eventually uses this shiny new thing, it’s actually not that great?
That’s where the agile approach steps in…
…or probably somersaults in, being as it’s so agile. It’s a different way of exploring and adopting technology, and it’s becoming more and more commonplace. In fact, you might well already be doing it, without even realising.
It turns waterfall pretty much on its head because with agile, you dive right in and adopt the new tech straight away. Yes, it still starts with a need – something you want to do better. But this time, you spot some tech you like the look of and you just try it. Because the company behind that product makes trying it easy. No strings, no cost, no worries. And because of this exploratory, no-strings approach, risk is still low, even if the overall stakes of the project remain high.
You take a free trial, and if you like it you stick around, start paying, and start getting your colleagues to take a free trial too. Alternatively, you might have picked a product that uses a freemium model, like Dropbox, MailChimp, Slack, Spotify or Wistia. Again, if you like it, you pay to use more of it.
Either way, the tech company behind the brand is relying on your advocacy to grow and make money (rather than a big up-front investment) so they’re heavily into customer service, and you’re getting to thoroughly try what they’ve got to offer without making a major commitment.
Weighing up the risks
With so many companies offering their tech in this way, agile seems like a great opportunity to explore before you invest, or try before you buy. You roll out slowly, with team members able to advocate for and explain the tech to others – the software and the team do the training.
But it’s not without risk. There are so many products out there to try, and the chances of you hitting on the right one right away are, frankly, small. So there’s an investment of time (if not actual cash) in trying things out. There will be dead ends, abandoned trials and a lot of emails. Even when you do strike gold, successful roll-out depends on compelling communication that gives people a reason to believe in the product and the clarity they need to comfortably use it.
On the upside, these risks are small compared with those of the waterfall approach – the risk that you’ll research your way into second place, or you’ll invest heavily in something before really getting hands on.
Being agile in your own development
For us at Nimbus, agile really works. Because adopting new technology isn’t just about buying into new brands, it’s also about evolving what you’re offering to your own customers.
While some of the biggest players in the industry still use the waterfall approach, that often means they struggle to keep up with rapidly changing customer needs. On the other hand, agile helps businesses like ours shift gears quickly and pivot into new developments.
It’s the route we use to develop our own STORM hosting platform. As our core product, it’s got a smart, discerning customer base of creative agencies who rightly expect constant innovation. Getting to the heart of what they need and delivering it fast is critical for us, and it needs to happen constantly, year-round, no excuses – not when the waterfall spills out.
Delivering change faster, for everyone
So, while there might be a place for waterfall in small, standalone projects – like building a basic, one-off website – we find that for an ongoing project, the agile approach is much better. We have a huge number of users and possibilities, and no fixed end date, so being agile means we can keep exploring new ideas and rolling them out when we’re ready. It helps us test the water without disrupting the customer experience – and it means we don’t have to wait to define, develop and implement meaningful change.
For example, we might launch part of a new feature and ask for user feedback before integrating it fully – being agile enables us to really involve our users, putting features in front of them that they definitely want (and we know really work). It also means that if they’re telling us our new idea isn’t actually very helpful, we can park it before we’ve poured hundreds of hours into it.
We’re also able to break down our overall goal into smaller goals, with one- or two-week timeframes. This keeps the pace of work up, creates satisfaction that things are getting done and going live – and avoids the fatigue that can set in with a waterfall project that drags on for months. It’s hard to stay enthusiastic for so long.
Agile’s not a complicated way of adopting new tech or launching new features. In fact, it’s simpler than the waterfall route. And for us that fits in with an ethos of making great tech simple. Instead of planning, budgeting and developing, just get on and do it. Explore, learn, evolve.