A Perfect Path to Production

When I was first dipping my toes into the world of product management I remember my PM coach, Kate, telling me that I didn’t need to be technical to do the job, but that it would help if I was.

Below is the rollercoaster of thoughts/questions my brain went through:

…What?

If it helps, shouldn’t I learn how to be technical?

I want to be a good PM one day, so I need to learn this.

What does “being technical” even mean?

Oh my God… I have to sign up for Code Academy, don’t I?

She talked me off the ledge, and even though I didn’t end up signing up for a coding class, I did learn that a fundamental skill I could carry into my product management career is to understand the capabilities of the software/technology my team is using.

The method I’m going to share is a general example for a standard product’s path to production.

Congratulations! You’re a PM and you’ve written kick-ass user-centered stories ready for your development team to start building. But what does that process look like? How does it get started? When does the PM get brought back into the mix? Who plans for the release to actual users?

Let’s first learn a little relevant vocabulary before I walk you through how to answer these questions.

CAN we push to production?

The answer should always be yes!

CI: Continuous Integration:

Is our team set up to seamlessly push code with minimal hand-holding? When we’re ready to push our software to users, are we able to? Do we know all of the steps required?

SHOULD we push to production?

This is for the product manager and the development team to decide together.

CD: Continuous Deployment (Deployment = Release)

Is our team consistently pushing code to production? How often are we releasing?

In order to avoid bug fixes or even worse, rolling back to an earlier version, it’s important to have a conversation with your team and understand CI/CD. Ideally, your team should be releasing code through this pipeline as often as possible, which might even be many times a day!

Let’s get into the process.

Phase 1: The Local Environment

Meet Developer Deb. Deb is an engineer on the development team and is responsible for writing software to deliver the features described in the user stories. She is representing the first step of our path to production: the local environment. The local environment is where code lives that is being written on an engineer’s personal machine, like a laptop.

When she begins to work, Developer Deb pulls code from the live environment, or main branch, (we’ll talk more about this later!) so that she is working off the most recent version of code. This is important since it is likely constantly changing and can have several engineers working on it at once.

Developer Deb has just finished a user story. She has tested it and the functionality for that user story works locally on her own machine. Developer Deb then pushes that code to what we call the staging environment.

Phase 2: The Staging Environment

The staging environment is a place where code is live online for engineers to review. A user will never have access to the staging environment. This means that on a good team — there will always be more than one version of the software being built. Think of the staging environment as a practice rehearsal before users get the chance to see the entire show.

(My coach is a talented thespian and I am a huge lover of theater arts so forgive me for a second while I geek out over this analogy)

The purpose of the staging environment is to be able to test Developer Deb’s delivered user story next to all the other user stories that have recently been written to make sure it all still works. That means Developer Deb’s code needs to work next to Developer Doug’s, Developer Dan’s, and so on.

The staging environment is now filled with delivered user stories that have not been accepted yet. Now that they are all integrated, they risk being potentially broken because they were written on different machines and local environments. If developers discover that Developer Deb’s code is broken or no longer works, they will send it back to her to fix in the local environment.

How do developers know if the code is broken or not?

Well… Developers write tests and use compiling tools to review code. There are so many software tools that exist, like Github, that were created to expedite checking an engineer’s code.

Imagine this tree trunk represents the production environment (main branch), where users can see and use the software we’ve built. Tools like Github help keep a team on track to make sure that they don’t write features on top of stale code, or build anything too far removed from the main branch we’ve established. Eventually, everything will have to funnel back to the trunk and get pulled into the entire production environment again.

Once Developer Deb’s code has gone through all the appropriate checks and everything looks great, she submits a PR or pull request. A PR is a step where Developer Deb is now saying that her code worked on local and staging and is now ready for the other developers to review it. The reason we go through this extra check is to make sure that other developers have also put their eyes on it to confirm that it’s ready. This is a safety mechanism before the code gets to the PM.

Once it’s been approved by Developer Doug, we can move this user story’s code to the acceptance environment.

I’m sure you can imagine that staging can be a mess, but it is so necessary to do before the curtain call.

Phase 3: The Acceptance Environment

Here’s where the product manager comes back into the mix, baby! In the acceptance environment the PM now sees user stories that have been built that are ready for acceptance. Because you’re an incredible PM and have written detailed acceptance criteria, this process should be a breeze to review.

Rarely, the PM will find a bug by the time the story makes its way to the acceptance environment. This is because the user story has already gone through multiple rounds of review. More likely, the PM will discover that a developer missed something in the acceptance criteria while they were building. If this happens, the PM rejects the user story and it gets sent back all the way to the local environment and Developer Deb needs to start over.

If Developer Deb’s user story has been accepted by the PM it should be ready to go live, right?

Not necessarily.

If it’s a crucial bug fix, also known as a hot fix, the story will get moved down to production, no questions asked.

But, Developer Deb’s story can also move into a pile of user stories that are accepted and ready for release. This part is important to understand especially when you are working on a gigantic epic that has multiple user stories that are being completed at different times.

How are these user stories organized so that the PM can keep track of them?

The team might decide to put a feature flag on stories that are accepted but not ready to go live just yet.

Considerations before Release

Great. Now we have a system that seems to be as organized as it can possibly be. But now… who answers the question “Should we release?” The answer is the product manager, the team, and the stakeholders. But let’s backup a little bit and talk about how to get here.

It’s also important to recognize and revisit the difference between these two questions:

“Can we push to production?”

The answer should always be yes.

“Should we push to production?”

Again, this depends on your other features, stakeholders, processes and barriers.

There are so many considerations that need to be addressed before exiting the acceptance environment and entering the production environment or “live”.

Here are some things teams might consider in their release plan:

• Are we following a release plan?
• How has this been communicated to users?
• How are we going to market this?
• Do our stakeholders trust us to ship this?
• Is this an A/B test?
• If it is an A/B test— what is the plan or timeline of when to rollback on the feature that we don’t end up choosing?

Pro tip: marking milestones in Pivotal Tacker or Jira is a great way to visualize and track dependencies to clear before your feature is ready to release.

Phase 4: “Live”! (Production Environment)

Congratulations! You’ve been approved to go live! (This live environment, or latest saved version, is where Developer Deb pulls her code from that I told you about in the local environment!!!)

Now that we’re finally here, users can officially use the feature that we’ve spent so much time building.

Show time.