Hi Reader,

Have you ever had a developer tell you they deployed something, you went to check, and it wasn't there? Turned out it was somewhere else entirely.

If so, you've met the reality of having multiple environments.

Today we're breaking down environments: what they are, why you need more than one, and what it takes to keep them from drifting apart.

Today in 10 minutes you will:

• Understand what dev, staging, and production actually are, and why you need all three
• See where sandbox, SIT, UAT, DR, and demo environments fit in, and when you actually need them
• Get a decision tree for choosing where your dev environment should live
• Learn the concrete practices that keep dev, staging, and production from drifting out of sync
  ​

Why I Am Writing About This

I still remember when I joined my first product team, an SAP team, and people used to talk about "boxes." I had no idea what they meant.

Then someone mentioned trying it on a sandbox, which left me absolutely confused.

What sandbox are you talking about?

Understanding different environments is instrumental to being a PM: understanding what to do with each, their purpose, and how to handle them. That's where you don't just "know" about them, but actually set standards and guidelines for how to use them.

Environments help us streamline our delivery. It's one of the biggest, simplest levers you have to make that happen.

What Are Environments, and Why Do We Need Them?

Environments are places where you deploy the same application, but with different configurations, and potentially different data.

Each one exists to support a different stage of the software development lifecycle. Each one gives you a place to test with a specific purpose, matching where you are in that stage.

Why do we need them?

Environments help us catch issues before they reach production.

Imagine if every developer could push straight to production. Production would be in a constant state of fire. And you'd have a hard time figuring out why, because you'd have skipped all the testing history that normally leads up to that point.

Main Types of Environments

When we talk about software environments, we mostly mean three: dev, staging, and production.

Some teams introduce additional environments depending on their context.

→ Teams with many integrated products sometimes add a System Integration Testing (SIT) environment, kept always up to date, so they can test whether a new change breaks anything else in the ecosystem.

→ Other teams set up a dedicated UAT (User Acceptance Testing) environment, separate from staging, specifically so real users can test with their own real data.

→ There's also a sandbox environment, where you can inv

ite any user to play around with the product without risking anything.

→ Some orgs keep a dedicated disaster recovery (DR) environment, a standby copy of production that only gets used if production goes down.

→ Others run a demo environment, a stable, curated version used for sales calls or exec walkthroughs, so nobody demos on an environment mid-deploy.

Here's how these fit together:

Today we're sticking to the three most common ones: dev, staging, and production.

Keeping Environments Consistent

Each environment has its own applications installed, sometimes in different versions, its own configuration, and its own data. That means something working in one environment is no guarantee it will work in another.

To get reliable testing results, someone needs to keep these environments consistent. Here are the best practices I have seen work:

1. Central maintenance team that looks after the environments

2. Maintenance windows for patching, security upgrades, and similar work

3. Refresh schedule: data, configurations, and applications are copied over directly from the current production environment

4. Data maintenance: a central team handles general data upkeep, while product teams create their own data for specific use cases

5. Clean up after yourself: whatever you spin up for a test, you tear down when you're done

6. Environment ownership documented somewhere visible, so people know who to ping when something drifts

7. Automated drift detection or a recurring manual check comparing config and versions across environments

8. Access control reviewed periodically, since dev and staging tend to accumulate stale permissions over time

​
​🧪 Dev

This one used to confuse me a lot, since it turns out there are a few types of dev environments. And everyone means something different when they talk about "their dev environment."

Goal: give developers a space to write and test code freely, without any risk to real users or real data.

Characteristics:

→ Fast, disposable, and often unstable on purpose

→ Frequently reset or rebuilt

→ Usually uses fake or sample data, not real user data

Disadvantages:

→ Too different from production, and you risk "it worked in dev" surprises later

→ If shared across a big team, developers can step on each other's changes

Where dev actually lives:

→ Local: on your own laptop. Fast feedback, but the setup only reflects your machine, not necessarily the team's environment.

→ On-prem server: a specific server your organization hosts and maintains. More consistent across the team, but someone has to own the upkeep.

→ Cloud server: a specific hosted, shared server your team maintains long-term, usually with integrations and data pre-wired in. Easier to keep consistent and scalable, but adds cost and cloud dependency.

→ Codespaces (or similar cloud dev environments): the persona

l version of the above. Spin it up on demand, throw it away when you're done, closer to a cloud copy of your own laptop than a shared team environment.

Here's a quick way to think through which one fits your team:

What to do to keep your dev environment useful:

→ Maintenance: someone owns keeping it aligned with staging, even if it's meant to be disposable

→ Data: keep sample or fake data realistic enough to catch real bugs, without using actual user data

→ Reset cadence: rebuild or refresh on a schedule, not just when something breaks

→ Onboarding: document how to spin up dev so new team members aren't stuck guessing

​
​

🧪 Staging

Goal: mirror production as closely as possible, so you can catch integration issues before they reach real users.

Characteristics:

→ Configured to match production: same architecture, similar (often anonymized) data volume

→ Where QA, UAT, and final sign-off usually happen

→ The last stop before a change ships

Disadvantages:

→ Expensive to maintain if it truly mirrors production

→ If it drifts out of sync with production, it stops doing its job and starts giving false confidence

→ Often the environment used for load or performance testing, since it's the only one realistic enough to trust the results

→ Sometimes the environment external integration partners test against, not just your own QA team

What to do to make your staging environment useful:

→ Maintenance: keep it refreshed on the same schedule as your dev-to-prod parity checks

→ Data: use realistic, anonymized data close to production volume

→ Monitoring tools like in production, so issues surface the same way they would for real users

→ Product teams should have access, not just engineering and QA

→ Test everything as if it's in production: deployment, config, usage, and performance

→ Access control: review who can push to staging periodically, it tends to get treated as lower-stakes than it should be

🧪 Production

Goal: this is the real thing, what your users actually touch.

Characteristics:

→ Real data, real traffic, real consequences

→ Changes here should already be validated everywhere else first

→ Monitoring and rollback plans matter more here than anywhere else

Disadvantages:

→ Difficult to debug live, so testing and debugging need to be thorough before anything ships here

→ Goes through full change management, which slows things down, one more reason to get staging right

What to do to keep your production environment useful:

→ Maintenance windows for security patches and upgrades, same discipline as dev and staging

→ Monthly upgrade cadence, not just reactive patching

→ Continuous monitoring, with alerting tied to on-call ownership

→ Access control: the tightest of the three environments, reviewed the most often

​
​

Behind the Scenes

I built another workshop!

This time it's a hands-on API workshop for product managers who want to become technical.

If you've been thinking you should really learn more about APIs, and actually practice using them, not just read about them, this one's for you.

Join me on September 7, 17:00 CEST. Completely free.
Sign up HERE. ​
​

What do you think?

Did this newsletter help you make sense of dev, staging, and production?

Hit reply and let me know, or tell me where your own environments have gotten out of sync.

See you next week,

Maria