Article

5min read

How Continuous Development Turns Product Managers into Experimenters

20 years ago, tech companies were hit with the ‘Agile Revolution’. The idea? Shipping working software every week or two would help teams deliver better products, even if this method implied more risk. In other words, the ‘move fast and break things’ mentality reigned.

But that was two decades ago. Today, agile is mainstream, and new philosophies, building on the agile movement, have come to the fore; namely, Continuous Integration, Delivery and Deployment, largely geared towards DevOps teams. Their big draw is that these processes and tools automate quality assessment, assuring that when code is merged in piecemeal fashion – and not on one big bang release day – it works. Even better, software can be deployed to the product environment at any time, by anyone. Now, your product manager can take the reins.

Today, the market is ready to go a step further. From Agile to Continuous Integration, Delivery and Deployment comes a thirst for Continuous Development. Continuous Development – we could even call it Continuous Activation – encompasses all of these ideas, but takes the logical next step. It puts even more control and autonomy in the hands of Product Managers. It allows them to not only deploy software themselves, (with mitigated risk), but also to pick and choose according to their own prerogatives which audiences are exposed to a given feature. In other words, they can run experiments, personalize the user experience, and exercise complete rollback control based on real-time data.

Continuous Development platforms and processes transform the Product Manager into a Chief Experimentation Officer, and there are many reasons to embrace this new paradigm shift:

Move Fast, Risk Less

‘Move fast and break things’ only works if you’re willing to accept the consequences of what you’ve broken. Most software developers would still like to move fast, but without the risk. 

Continuous Development and the tools that support it factor in risk assessment. By avoiding code merges on one big release day, and by enabling progressive rollout techniques (canary deployment, ring deployment), developers can avoid putting all of their metaphorical eggs in one basket. If your system has a feature flagging or rollback KPI embedded in the platform, switching off a defective or negative feature can be done instantaneously and painlessly.

Your Customers, Not Your HIPPOs, Decide

How do decisions get made in your tech company? Chances are, HIPPOs, new bosses, vocal salespeople, consulting groups or the noisiest Product Manager in the room dominate that discussion, letting their personal experience, gut feeling or intuition determine the road map. 

With Continuous Development platforms, the focus shifts from subjective ideas to customer feedback and data. Early adopter programs, beta testing, progressive deployment, A/B testsall of these methods, enabled by feature flagging and other Continuous Development techniques, make your main measurement of success the behavior and opinions of your customers. 

In a B2B context, this might look like extensive interviews with early adopters. In B2C, it’s likely your support teams or community manager who will pick up on positive or negative feedback around a new feature launch. Either way, Product Managers get direct access to the Voice of the Customer and can form data-driven arguments for why to rollback, stick with or modify a new feature.

Get off the Ford Line

If your team is project-driven, chances are your Product Managers and developers feel they need to keep their heads down and noses to the grindstone, working on their piece of the software production puzzle. They might be productive, they might be agile, but they might also not really feel the business impact of what they’re working on 40+ hours of the week.

When you can experiment with and test the features you’re developing; when you can get direct user feedback and adjust your work accordingly; when you have clear, measurable KPIs that determine success, your work all of a sudden feels a lot more meaningful. This keeps teams motivated, fresh and loyal.

Marketing and Product Manager Alignment

When you give your Product Managers more control, it’s easier for them to align with the teams around them, especially the Marketing and Communication departments. A new feature release, especially depending on the size and importance of your company, can mean a big web of marketing and communications campaigns. Emailings, press releases, articles, social network posting, corporate website updates…retroplannings and shifting deadlines are much easier to manage when your Product Managers are in the driver’s seat and not beholden to developer teams that have other priorities and are even more far removed from your marketing and communications personnel.

Developers Focus on Core Business Objectives

If you have a robust developer team, there’s a chance you could set up these types of feature management systems in-house, without the need for a dedicated platform. But this is time-consuming, and one could argue that it diverts skills and resources away from your core business objectives. 

I believe that the time is now for Continuous Development. By turning our Product Managers into Experimenters, we’re able to build a better product and bring it to market faster, with less risk; we continue in the vein of ‘customer obsession’; we keep our teams creative and motivated; and we generally build up what, at AB Tasty, we’ve been advocating for since our founding – a test and learn, experimentation culture.

Subscribe to
our Newsletter

bloc Newsletter EN

We will process and store your personal data to respond to send you communications as described in our  Privacy Policy.

Article

10min read

Use Case User Onboarding: What Impact Do Release Teams Have on UX?

According to a PWC survey, one in three customers would leave a brand after just one bad experience. Hence, your company may invest a lot of time and money optimizing your digital product to stay relevant in today’s often crammed markets.

A critical part of the overall product experience is user onboarding: get it right and win loyal customers, but get it wrong and lose those users forever.

So it makes sense to continuously tweak the user onboarding process – the perfect job for a product team. Such a team often consists of 5 to 8 people, including product managers, designers, and developers. Different companies work with various product team sizes and configurations – whatever is best for their use case. However, we rarely see DevOps engineers in these teams because many view DevOps as just a vehicle for successful feature releases. 

Ultimately, however, these DevOps engineers have to get up at night to fix a newly deployed feature that crashes the app every time a user navigates through the onboarding process.

We want to ask you: Can an app whose onboarding process doesn’t work technically be successful, and do release teams significantly impact UX after all? Let’s find out.

 

In this article, we’ll be exploring how to:
[toc content=”.entry-content”]

 

Make users feel right at home with a great onboarding experience

Most apps require an onboarding process to show new users how to achieve their goals as efficiently and conveniently as possible. 

For this, we need to keep in mind that the onboarding experience can affect your relationship with prospects – both positively and negatively. 

No matter how good your app actually is, the first impression counts! 

Large companies like Slack or Dropbox also frequently overhaul their user onboarding to ensure users have a comfortable, fun, and productive start to their product. But see for yourself. The following images show an excerpt from Slack’s onboarding process from 2014 and 2021. Of course, the design has changed drastically, but you can also see that instead of reading where the team name comes up in the Slack interface, we actually see the user interface and our team name on it. These improvements are certainly not the results of guesswork but of meticulously coordinated optimization workflows.

Slack Team Name

Slack Company Name
The evolution of Slack’s onboarding process (Source)

 

As even big enterprises invest in optimizing their onboarding processes, we realize that we should do the same and not rest on our laurels. The question remains, how do you make sure you are building the right onboarding experience in the right way? 

And this is where cross-functional product teams and Flagship come into play!

 

Leverage Flagship to unite product teams and ensure great UX

At AB Tasty, when we work towards a great user experience, we focus on two main themes:

  1. Release the right feature: We step into our users’ shoes and conduct experiments and tests to ensure that the feature delivers value and looks and feels good.
  2. Deploy the feature right: It’s not just about functionality and looks. We utilize feature management to ensure that what we’ve created works flawlessly at all times and on different platforms.

Flagship chart
Flagship provides a shared environment for experimentation and feature management

Flagship gives you the means to get the most out of both: data-driven experimentation and feature management to create and release features for great customer experiences. So we see release teams as an integral part of creating value for our users. This may not be the most popular opinion. Still, now we’d like to tell you more about why we think DevOps should be more closely integrated with product teams.

It’s no secret that teams that work toward a common goal are more likely to reach their true potential than those that don’t. By isolating DevOps from product teams, you probably can’t count on the positive effects of unity and passion necessary to create and release great products. For this reason, we encourage product teams to work more closely with DevOps. Release teams also care about delivering value and great experiences to users. And they bring the skills required to do so to the table.

Flagship provides product managers, developers, and DevOps engineers with a shared environment for experimentation and feature management. You get easy access to all the data and tools needed to have a productive conversation about the product optimization process in a common data-driven language. Simultaneously, instead of isolating specific roles and responsibilities in silos, each member of the product team can focus on doing their job while continuing to work as a collective force.

Now, let’s take a look at how Flagship’s experimentation and feature management capabilities enable product teams to deliver outstanding user experiences.

 

Deploy the feature right with feature management

First, let’s talk about a few examples of how feature management and releasing a feature right can positively impact your users’ onboarding experience.

Suppose you want to add tooltips to your onboarding process to help users navigate your product’s dashboard confidently. The product team prepares the new feature accordingly and thoroughly tests the functionality on the test servers. After everything seems to be working, they roll out the new feature for all users in one fell swoop. Hopefully, it’s not Friday afternoon, as the changeover could cause unforeseen problems on the production server, like:

  • Your user is stuck in an infinite loop that they can’t exit
  • User input isn’t saved, e.g., in a form
  • The app crashes repeatedly
  • The user is sent back to the start for no apparent reason

 

Just imagine what such behavior means for users going through your onboarding process and looking forward to finally using your product when it suddenly stops working. Poof, the magic moment has passed. The user has most likely lost confidence in your app due to bad UX.

 

Flagship makes code deployments stress-free

With Flagship’s feature management capabilities, your product teams can publish new features with ease – even on Friday afternoons.

Feature management enables release teams to provide the new tooltips feature to a selected target group before continually rolling it out to everyone. This way, you can be sure that the new feature works under realistic conditions, i.e., on production servers with real users.

Through controlled and monitored rollouts, DevOps teams immediately know whether something isn’t working correctly. This enables them to react on time and be glad that only a few users have noticed the error.

For example, suppose the developers wrapped the tooltip feature in a feature flag (which they really should be doing). In that case, they can quickly deactivate it via the flagship dashboard if a problem occurs. Of course, they can also configure automatic code rollbacks based on KPIs to react even faster.

Proper feature management can de-stress your release teams: Gone are the sleepless nights spent dealing with damage control! If you want to learn more about the benefits of feature management for tech teams, we recommend our blog post here.

 

Release the right feature with experimentation

Perhaps you have great empaths on your product teams and feel like you know your users pretty well. Still, it is wise to experiment and test to create an onboarding process that your users will love.

Let’s look at the tooltip example from before again. Suppose that after your product team successfully integrated the tooltips into user onboarding, your analytics data shows that something must be wrong. Many users still don’t know how to use your app and abandon the process midway through. If you can’t identify and resolve the problem right away, you need to leverage other means to improve the tooltip’s user experience. 

First, make sure that everything is fine from a technical point of view. Next, your product team should start working on possible variants to improve the tooltips’ presentation and functionality. You can then experiment and test with Flagship to determine which of these variants and ideas offer the best user experience.

For example, you could utilize A/B tests to see if showing a how-to video before displaying the tooltips helps users get started with your product. Or experiment with different tooltips sequences – perhaps the process is easier to understand if you change the tooltips’ order.

You’re also free to experiment with different colors, copy, UI elements, call to action, and so on. To make your experiments as meaningful as possible, you can define which users see which feature variant and track user acceptance, test results, and KPIs in the Flagship dashboard. 

Another advantage of Flagship is that you can utilize 1-to-1 personalization based on audience segments to provide users with unique experiences. For example, after a user registered for a paid subscription, show them a customized welcome message and add more value to their onboarding experience.

 

… What about client-side tools for experimentation?

Many client-side experience optimization tools, such as our AB Tasty, can also perform most of these experiments – without code deployments. However, the advantage of coding your experiments for a critical process such as user onboarding is that you don’t potentially slow it down with automatically generated UI overlays. Instead, tests and experiments with Flagship are fast, secure, and flicker-free, as they come directly from the server and don’t have to be calculated in the user’s browser. Of course, client-side tools still have their justification and unique uses – Flagship is a great tool to complement your client-side strategy.

 

Wrapping up

If you want to provide users with the best possible onboarding experience, you need cross-functional teams who know how to release the right feature and how to release a feature right. One of our goals is to advocate the importance of release teams to great UX – whether a product technically works is as important as how it looks and behaves.

Using Flagship’s experimentation and feature management capabilities, product teams can benefit from a shared platform to collaborate on improving the onboarding experience in a productive and data-driven way.

Would you like to try Flagship for your product teams? Book a demo and see how experimentation and feature management can transform your users’ onboarding experience from okay to Yay.