A launch in seven days

You can launch a new operational process in a week. The trick is not working faster but deciding, before you start, what must be right on day one and what can be improved afterwards. And the launch is not the finish line: what happens in the following months decides whether the process becomes good.

What did the launch involve?

At Amazon Spain, the site where I was an area manager was asked to take over a returns process from another location, with about a week’s notice. Nothing was ready: no adapted processing line, no flow, no trained people, no standards. The volume was already on its way.

We had seven days to adapt a line, reverse the flow to fit the existing conveyor, write the training material, train the instructors and the associates, and set up sortation areas for every product category. On day seven, the process was live.

How do you plan a launch that short?

By splitting the work into three groups before doing any of it.

1. Must be right on day one. Safety, the physical flow, the core steps people repeat hundreds of times a shift, and enough trained people to run it. These got almost all the attention.
2. Can be good enough on day one. Layout details, reporting, secondary workstations. Simple, temporary versions were fine, as long as everyone knew they were temporary.
3. Can wait. Optimisation, automation, nice-to-have tooling. Written down so they were not forgotten, then deliberately ignored.

That split is what makes speed possible. Most launches are slow not because the work is large but because everything is treated as equally important.

What made the week work?

• One owner and a daily plan. Each day had a short list of outcomes, checked at the end of the day.
• Training before perfection. Instructors were trained first and then trained the rest, using material written for the people doing the work, not for a manager reading it.
• Benchmarks, not invention. Before taking over the volume we visited sites that already ran the process, so we copied what worked instead of designing from scratch.
• Temporary is allowed. We adapted an existing line first and installed the definitive layout later. Waiting for the perfect setup would have meant missing the date.

What happens after go-live?

This is where most of the value is. Over the following months the workstation layout, audit routines, scanners and reporting were improved step by step, each change small and measured. Quality standards were written down and taught. Productivity was reviewed every week, with a clear owner for each action.

The process went on to set a worldwide productivity record, and the European target for every site was raised by 10% as a result. None of that was designed on day one. It came from treating the launch as the beginning of the work.

How can a smaller company use this?

The same approach works for launching a new service, opening a new location, moving to a new system or taking on a new client with tight deadlines:

• Write the three lists first: must be right, good enough, can wait. Agree them with whoever owns the result.
• Protect the core flow. Spend your time on the steps people repeat most and on anything that can hurt someone.
• Find someone who already does it. A one-hour visit or call with a team that runs a similar process saves days.
• Train early and simply. Short, practical material for the people doing the work.
• Plan the first three months, not just the launch. Book weekly reviews before go-live, with a short list of what to improve next.

What is the broader lesson?

Speed comes from clear priorities, not heroics. Decide what matters on day one, accept temporary solutions for the rest, and keep improving after launch. A good process is rarely launched; it is built in the weeks that follow.

If you have a launch coming and too much to do, sorting the work into those three lists is a good first conversation.