Tech for PMs — what are environments?

What software and school exams have in common

If you’ve recently heard the words “dev”, “prod”, “staging”, “UAT”, “QA” and are beginning to despair that your brain can’t handle any more jargon 🤯 then I’ve got good news.

All these confusing terms are different types of the same thing: environments.

But what are environments? And why are there so many of them?

TL;DR

An environment is the collection of hardware and software that runs your app.

Apps usually have 3 environments:

• Development environment where developers build the feature
• Staging (or test or UAT or QA) environment where QA and PM test the feature
• Production environment where customers use the feature

Having 3 separate environments is useful for one simple reason: it allows the team to build and test features of the app without impacting customers.

As a Product Manager, knowing what each different environment does will allow you to test features, set up analytics events and much more.

—

Environments and exams

To start off with, it might be helpful to think about environments in terms of a different kind of test. Let me take you back to some of the more stressful moments of your youth: preparing for exams at school.

If you were anything like me, this involved a lot of procrastination followed by a late burst of fear and an all-nighter before the exam. Sometimes the exam went well, sometimes it didn’t.

My brother, on the other hand, was the studious type. His preparation went more like this:

• Do some practice questions at home. No pressure, can check the answers if you get stuck. Might try out a few different ways of answering the question
• Second, do a mock exam in class and have your teacher mark it. A bit more pressure and feels more exam-like
• Finally, sit the exam in an exam hall in total serenity knowing that you’ve done the necessary prep and your final grade will likely reflect that

My brother didn’t go on to be a software developer (would have been good for the story if he did 😒). But if he had, I’m pretty sure he would be using development and staging environments to build and test his features before pushing them to the production environment in the tranquil knowledge that they would work perfectly in the hands of his customers.

Why environments are essential

Can you think of all the hardware and software needed to make your favourite app work?

Let’s see, there’s the operating system, the servers, the databases, the back end services, the analytics tools, Intercom, Twilio, Sentry etc

We can collectively refer to all this hardware and software as the production environment. The production environment literally 🌳 creates an environment for your customers to experience your app 🌳

Now, when developers test things, they don’t normally want to test them on the production environment. You can imagine sending your customers a push notification saying “TEST” when they’re least expecting it is not the best user experience (something similar actually happened at HBO Max recently)

Instead, they “copy and paste” the production environment and create a couple of replica environments. These replicas are used for development (the development environment) and testing (the staging environment).

So most apps usually have a:

• Development environment — to develop the feature
• Staging environment — to test the feature
• Production environment — to put the feature in customers’ hands

The goal is for the feature to have been rigorously tested in the development and staging environments so that when it reaches the production environment it works as expected.

The development environment

AKA a messy place for developers to try things out 🛠 as they build a feature

For developers, the development (“dev”) environment is a sandbox where they can try almost anything they want without the pressure of it needing to work right away. It’s like doing exam questions at home in our earlier analogy.

If you were to use your app on its dev environment, you might get a shock as there could be features and bugs 🐞 flying all over the place! But don’t panic, this is completely normal.

In the dev environment, a developer can code something, see how it works in real time, and quickly make changes to get it working how they want. All this without the pressure of a QA, PM or, most importantly, a customer to judge their work.

And it’s because developers don’t want to impact customers, that the dev environment uses test databases and a test back end.

Here are some key features of the dev environment:

Once a developer is satisfied with how the feature works, they’ll ask another developer for a pull request (remember those?) and then promote the feature to the staging environment.

The staging environment

AKA the dress rehearsal 🪞 before a feature is released to customers

The staging environment (also known as “staging”, “test”, “QA” or “UAT”) is designed to mirror production as closely as possible. So if your feature works correctly on staging, you know it’ll work correctly on production.

If the development environment is the developer’s playground, the staging environment is the QA tester and the Product Manager’s classroom 👩‍🏫

The QA tester and the Product Manager are the teachers marking the mock exam. The QA puts the new feature through its paces, trying to root out any bugs or performance issues. They have an arsenal of tools at their disposal, including end to end tests, regression tests and performance tests. Additionally, the Product Manager checks that the feature behaves as it should for the user.

The production environment

AKA the app in the customers’ hands

When the QA and Product Manager are happy that that the feature is ready to go ✅ the developers release it to the production environment (“prod”) so that it can be used by customers.

Releasing to prod is exam day. If the necessary prep has been done in dev and staging, there’s no reason why it shouldn’t go smoothly.

Why does a Product Manager need to know all this?

As a Product Manager, you’ll need to have access to the staging environment in order to test features before they are released to customers. It’s the QA’s job to make sure all bugs 🐞 get spotted, so as PM you can help by testing the feature from a user behaviour point of view and checking that everything in the experience is coherent and as expected.

The QA environment is also where you might demonstrate features 🤳 to other stakeholders and just generally play around with the app in order to get inspiration. Personally, I spend a lot of time on the QA version of my app, just tapping around and daydreaming on ways to make it better!

As a PM, it may also be your job to set up analytics events 📈 for a new feature. It’s easiest to do this in the staging environment so that as soon as the feature is released to production, the team can start tracking how customers are using the feature.

Some further reading

There’s loads more to environments. Here’s some recommended reading if you’d like to dive further into it:

• When has Wikipedia ever let us down? There article is concise and links to loads of useful resources
• This article from TestProduct focuses specifically on the QA / staging environment
• Another one from TestProduct which advises how to manage each environment