Whether you need a team to build your digital product, create the product strategy for your app,or handle every element of the product devleopment process, our team can help. Get in touch to learn how we can help you reach success, faster.
Raise your hand if you think launch is the easiest part of product development. Just pick a date, tell the team, and watch them go-go-go, right? That’s one way to approach it.
But you might find yourself in a bit of a bind when launch day arrives and you find out your Lead Engineer is on vacation and the security policy of your server host requires their credentials to access the production database. Or that making a copy of your most critical data takes more than four hours to run from start to finish. Or that the “Routine Maintenance” message will only render for your customers when the front end can get through to the back end, and not when the back end is down for maintenance.
For many startups and growing product companies, launches happen on the fly, deployments go out as soon as they possibly can, and new integrations get tested in production.
Maybe you can concede that this isn’t a great experience for your customers and maybe you’re starting to realize that it creates a lot of stress for your team. The good news is, it doesn’t have to be this way.
Organizations like yours can plan and execute launches, implementations, and migrations to support growth, vacate deprecated systems, set your team up for success, and truly delight your customers without overtaxing your team. Here’s how:
Plan for Success
Over and over again, we’ve seen organizations go into new releases, upgrades, and launches without an Orchestration Plan (OP) and it’s hard on everyone involved. As a founder or product leader, your first steps will be to recognize that your team needs an OP, get an understanding of what it is, and learn how they can lean on it for success in every planned deployment activity. It can even come in handy for unplanned activities and third-party outages.
An OP is exactly what its name implies: It’s a plan for the orchestration of an event. Think of it as the script to a play or the sheet music for a performance. It can be super short and simple, long and detailed, or more frequently, somewhere between those two extremes.
At the end of the day, however, an OP is an easy-to-follow outline of the components of your event in the specific order in which they should flow.
Each component has an owner, an estimated time to completion, and any necessary details (server names, DB commands, etc). When put together into one document, your OP will give every person involved in the event a concise understanding of what to do, when to do it, and how to do it. Most importantly, it gives you and your team peace of mind and redundancy in case you need to sub someone in or out at the last minute.
How Do We Get an Orchestration Plan?
Every OP will be different, but the basic elements are the same. You need some time with the team to create and review at least three (if not more) drafts of the OP over a period of time. With each review, your team will uncover more, gain clarity, ask new questions, and (if you’re doing it right) eliminate uncertainty.
Timing will vary from a couple of days for simple plans to months for more complex efforts. The more people and teams involved, the longer you’ll need from first draft to “done”.
I like to start simple and get more complex with each iteration of building an Orchestration Plan. In the first session, you’re just trying to get broad strokes and an idea of the steps it will take to get from start to finish.
If you’re in-person with your team, start with sticky notes, where each note represents a step in the plan. The small size of the sticky actually helps keep the task itself limited and discrete. If your team is remote, use a virtual whiteboard or even just a simple spreadsheet shared with all the participants.
It’s essential to remember that, at the end of your working session, you should assign any task that’s ambiguous or needs more info to a person or team. They’ll take that task, research it, and bring it back to the team at or before the next working session.
The next session will start with going through what you have so far from the previous session and filing in the blanks for anything that needed more research. Expect that each item on the plan will be a little more detailed than it was with the last draft.
Once you’ve stepped through from start to end, look back and ask your team to consider dependencies and ordering. What needs to be done before something else, what should happen right after this other thing, etc. Ask what (if any) steps could be done in advance or done in parallel with other steps. Make note of order, timing, and concurrency in the OP at this stage.
By the time you get to your third full team session, everyone will likely be tired of walking through the OP. You may hear grumbles of resentment for having to sit through another meeting that is just the same AGAIN.
You won’t be able to help that, but there are ways to make this session a bit more engaging. We’ll cover what those are in part two of this post.
Now you have a foundational understanding of what an OP is and the initial steps to building one. Most importantly, an Orchestration Plan keeps your launch on track, sets your product up for success, and helps keep your team from being overwhelmed leading up to launch day so your product is set up for success from the jump.
