Lessons Learned in Rolling Out Software
I’ve been in software and technology the last eight years and so I’ve had my share of teaching and training hundreds of customers on software, while also internally touching and using many tools and technology for my own successful management.
In my role as Director of Customer Success, I manage our technology stack for our team of 21 to use, to make their lives easier and better. This includes the likes of Salesforce, Smartsheet, Trello, and WebEx. Since we’re in Customer Success, we’ve made our way around Customer Success platforms (a nascent market) and after trying them all, we landed on Gainsight.
Gainsight, although powerful, is one of the most challenging tools I’ve ever setup and rolled out to a team. As I prepared for launch, I really tried to think through every scenario and I realized that software roll-out applies to a lot of business principles so I’ve outlined them below into three key phases of getting started, launch day, and retro. I’ll add in snippets specific to Gainsight, but this should mostly apply to any roll-out.
Getting Started: To be prepared is half the victory.
- Project plan, timeline, goals, and launch date. Work your way backwards from this plan. Make sure this plan is public to your key stakeholders and you have the appropriate buy-in you need. It’s important to be strategic when launching so you know what “success” means and that you and your team are getting value out of the tool. Don’t start with the how before you’ve got the why.
- Lean into your vendor for best practices. Hopefully, the vendor can be an advisor and not just a tool, where they advise how to get started and answer your questions as you navigate the new water. Gainsight definitely had resources for us to ensure we had what we needed to get going. They heard from me a lot
- Send calendar invites in advance for launch. I booked time with our team a month ahead for the training day and follow up trainings. Not only did this give them plenty of context, but they knew what was coming with clear agendas.
- Over communicate the updates and timeline. I made sure to let the team know progress updates as we were nearing launch. This ensures there are no surprises.
- Involve key stakeholders in decisions. A big part of getting started with many tools is configuration or setup. Because this is a tool that many people would touch, I involved the leadership and key stakeholders from our group (and beyond) to ensure everyone signed off on it. Getting their input shows you value their feedback, but also ensures it’s going to be accurate. I also chose two key individual contributors on the team, that gave good feedback and showed them Gainsight early on. They got to play with it and give me early feedback. You can think of them as your “power users”.
- Give yourself enough time to do it right, not fast. In this case, the tool was a critical part of our day-to-day, so although we aren’t the types to take our time, I didn’t want to rush into launching this. It involved so many different people and groups, pending schedules, delays, hiccups, etc. it’s important to give yourself a buffer of time. Everyone, including yourself, will thank you in the long run. I chose a date a week out from the one I thought I would be ready by. That extra week helped with any loose ends.
Launch Day/Training: It’s ironic. I spent three months of prep rolling out Gainsight (about 75% of my working hours went to this for those months) and that included a three day onsite, their “Express” workshop at their offices. When launch day comes, it all leads to that, but it almost feels anti-climatic. The real work begins after the launch when they’re in the tool and the unforeseen comes to a head. Nonetheless, make launch day special. A lot of work went into it and you want it to go as smooth as possible so I treat it like an event or party I’m hosting, where I try to consider all sides.
- Executive mandate. Bring in the person that purchased the tool, and who is ultimately, the group’s boss. Our SVP Ryan kicked things off explaining the why and how, and asking for everyone’s support during the learning curve. You can go blue in the face teaching people a new tool, but unless their management doesn’t require it or give context as to why it will help them, it won’t be as impactful or even worse, may not succeed.
- Have guiding tenets. We have this when we roll out Kapost to customers. We outline good school of thought for launching and setting up Kapost. Things like: crawl, walk, run, I’m your project lead and will be your go-to resource, keep it simple to start, nothing is set in stone and we can make changes to ensure this makes your life better. I also was realistic knowing the team has used a lot of tools in the past, but this one was going be different (plus I infused some humor into that journey).
- Bring treats. I brought fruit, croissants, and baked goods to get them through the long training. I also wanted to give back by thanking them for their time and commitment.
- Laptops closed. Undivided attention was an ask from the beginning. I also let them know at the end of the training we would get into the tool, but please hold off from having them open until then.
- Build a deck (that can be used after as a reference guide). I built a deck with Google Drive so everyone could access it after. I also used it as the presentation that outlined the agenda, expectations, and each area we were launching with on the day-of. I included a lot of visuals with screen shots, best practices, and videos (more on that below) in the deck, as well.
- Create videos as a training channel. On each slide that included a key area we were launching with, I included a video that I made. The video showed them how to use said area and was another visual representation they could go back to later. I used Jing, a free screencast tool, and I highly recommend it.
- Hand-outs and homework. I’m a fan of printing things. Call me old school, but people take notes anyway why not have it on a contextual piece of information. I wanted to be very explicit in guidelines so I made a checklist of homework in a handout (and digital) format. It gave them a list of resources they could use after the training and something to “walk away with” so they knew their next steps.
- Whiteboard as a ‘parking lot’. I knew the team would have a lot of questions (this is a good thing!) and with a bigger group, you can often go sideways or down a rabbit hole. I addressed many questions because it should be interactive but sometimes I put items on a parking lot whiteboard to follow up with later. This is a fair tactic and just be sure you follow up with all of those items so the team continues to trust and value you.
Retro/Feebdack: This phase is really when the work begins, but people often front load the launch period and training, forgetting that you need to bolster a lot of support and feedback post-launch.
- Create slack channel. We use Slack, so we created a channel just specific to Gainsight to ask questions and allow others to step up if they knew the answer. I also can send quick updates on my end.
- Feedback loop. Be sure you have some way to capture feedback and let them know you’re listening. I created a Google spreadsheet with different tabs for each area of the app. I committed to checking it once a week, and answering / addressing all the feedback and questions.
- Follow up sessions. Remember, the real work begins. They don’t retain everything shared in the first comprehensive training and that’s okay. I find that you have to repeat something seven times before it really sticks. I setup multiple open office hour sessions, follow up Q&A sessions, and feedback sessions from the team. I made sure the feedback session was separate from how things work and reviewing best practices too because it’s two different outcomes.
- Iterate and be okay with it. Although I had key stakeholders sign off on setup and configuration, post-launch, we changed things probably everyday. When you’re really in the tool, you realize something may not work quite how you imagined. We have adjusted and tweaked things as a group, and luckily because I was enabled to do so, I can make all the changes myself. Just know that you don’t launch with a finished product and walk away.
- Close the loop on homework. I did set specific dates for the homework, so alongside all the other things the team has to keep track of, I made sure to follow up with them as reminders for the homework and see if they had any questions. You can also gamify it and make it a healthy competition as some people will become clear leaders surging ahead.
- Future state. I gave the team about a month to really dig into the existing launch plan we had. As an operations lead, I had to also consider what we wanted to expand to for next steps with Gainsight that we’re called Version II. I’m using the same above mentioned methodology to get input and feedback, while also ensuring it meets our strategic initiatives as a company. I believe in always innovating and being the “best” user of Gainsight so we definitely push the envelope.
As a final rule of thumb, I think it’s good to be ego-less. I didn’t build Gainsight (or any of the other tools the team uses) but sometimes it becomes your “baby” because of the time and consideration you spent working on the roll-out. People will have all kinds of opinions, some will be difficult, some will be supportive and it’s absolutely part of the game. Being able to balance many balls at once and stay calm is part of what I do. Also, staying open to the path changing and realizing that not everything will work out as you planned is very important. It’s life after all.
What about you? Have you rolled out a tool to your team? How did it go? What other tips do you have?