Want to run experiments on your consumer-facing app, in order to achieve greater revenue, engagement, and retention? Traditionally, you’ll need engineering resources for that.
Of course, in an ideal world, we would all have robust technical teams full of experienced engineers, willing to work around the clock to turn every idea into a reality. But that’s not how it works. Technical resources are famously in-demand, and the need for more sophisticated and responsive technology is only growing.
Even without a sea of programmers on your staff, there are ways to be agile and to experiment all the time. Here’s how you can free up your engineers, and empower other teams, to create a culture of agile experimentation.
It can be tempting to push experimentation down on your priority list. After all, experiments don’t guarantee an increased ROI, and having a product out in the world is sort of like running a full-time, ongoing experiment. But don’t be fooled; you need to set aside time for experiments in order to continuously create a better product and experience for your users.
1. You test new experiences against old experiences. You won’t grow if you don’t understand how the new version of your product compares to the old one.
2. You need a place to be wrong. There’s a time and a place for embracing failure on your team. With constant pressure to be productive, you don’t leave room for listening and learning. Quite frequently, the most helpful realizations come from failures.
3. All ideas are good ideas is a generative phase. When you experiment, more and more ideas see daylight in the form of tests, user research, and data collection. When you’re not preemptively killing ideas, you find that some of the questions you didn’t think were important become mission-critical.
4. You create a culture of input. Your team will be more motivated when their ideas are valued and implemented out in the world. When you create a culture of input, you can start discussing concrete data over abstract theories that never actually happen.
The Path Toward Experimentation
The vast majority of engineering tasks requested from business teams have to be backed by realistic ROI goals. And app experimentation helps business teams create improved digital experiences for end users and customers, and enables companies to increase revenue, user engagement, and user retention and loyalty. Whether you’re in the ecommerce, finance, fitness, or other consumer-facing space, don’t you want your user cohorts to have the most relevant experience possible? After all, relevance is a big factor in creating a better digital experience as well as increasing your business metrics (revenue, retention, growth, etc.).
There’s a large opportunity cost that you miss out on if you’re not running experiments. So how can you achieve the scale, volume, and agility in your experimentation initiatives, without increasing dependence on engineering resources and releases?
1. Empower your business teams. When growing your engineering team isn’t a feasible choice, you need to empower other parts of your organization to run experiments (we’ve created a whole post here to help you achieve this). What if your product teams could build variants without having to go through a new app release? What if your marketing teams could personalize promotions, user experiences, and customer journeys, all without committing a single line of code? You need to find a way for your teams to create and deliver multiple experience versions, without any tech dependencies.
2. Reduce dependence on code. If all of your teams can contribute to app configurability, without having to depend on tech teams, then your product becomes the best version of itself in real-time. Instead of sending every change through a ticket with the tech team, there’s a way to free up your code base to be accessible to business teams. And you don’t have to worry about protecting your valuable code base; your back-end systems and microservices can remain invisible to experimenting business teams.
Agile Experimentation in Practice
Let’s take, for example, a made-up app development company called Alpha. Alpha’s business team has just finished with a series of meetings with their client, a Payroll and Benefits app. Alpha’s business team wants to launch a new automatic payment feature.
They don’t want to do a one-time launch. Instead, they would like to repeatedly fine-tune the parameters of automatic payments, based on the results of some experimentation. Hansel creates a dashboard, which makes it easy and effortless for business teams to make changes, without having to return back to the tech team again and again for tweaks, or repeat the launch sequence from scratch.
Additionally, the business team would like to create complex user segments, to target certain Payroll and Benefits features solely to contractors of their company. Hansel allows the Payroll and benefits app to target specific user groups based on their profile attributes, usage patterns, geolocation, in-app engagement, or simply by a list of user names. Each attribute related to the feature can be grouped into modules and then assigned to owners, with relevant approval mechanisms.
Alpha is confident using the Hansel configurability platform, because they can easily explain the results of their tests. They can measure the impact of changes deployed to each feature at runtime, without having to debrief with the developers. Hansel can import events from multiple analytics providers to integrate seamlessly into the organization’s existing dashboards.
Removing the Code Cycle to Enable Experimentation
Because of the cloud, system architecture no longer requires hard-coding data. It’s possible to pluck logic, data, and content from the cloud to conduct experiments, without having to make permanent changes to your app as these experiments run.
Hansel helps teams quickly conduct these experiments. Thanks to the configurability framework that extends into internal and external data systems, nothing gets hard-coded into your app until your engineering teams decide to make permanent changes.
Agile experimentation allows you to build software incrementally, without having to work in fits and starts; it can be a streamlined and flexible process that allows you to make changes even as frequently as on a daily basis.
The ripple effects of experimentation are substantial. Through your small, repeated, and frequent experiments, you can achieve goals like:
- Driving more revenue
- Increasing engagement
- Retaining your customers
- Fixing bugs
- Improving app configurability
The manpower for enabling those experiments has generally come from engineering teams. Traditionally, that means there is a backlog queue of asks from business teams that engineers are too inundated to address.
Whatever small wins you have in this scenario are canceled out by other frustrations and roadblocks, due to technical team constraints.
You can drive more revenue, engagement, and retention by getting around your technical limitations. Business teams can experiment in a controlled environment, without having to bug engineers.
This way, your business teams can:
- Run experiments they want in clicks
- Deploy experiments for segments of user cohorts
- Experiment with isolated goals in mind
- Review performance and see the impact of the changes made
- Continue iterating to get from “almost there” to “it’s perfect!” without having to bother the tech team
Business and tech teams both love newfound experimentation capabilities at scale. Tech teams don’t have to feel the stress and weight of business teams, and business teams are free to run experiments while keeping tech teams in the loop, but not being 100% dependent on them.
Whether you’re a business team member or a tech team member, Hansel makes your life easier. See how it works today.