A product launch means all hands on deck to try to get everything out the door as smoothly as possible. One founder offers insight about the lessons her team learned.
By Mary Juetten (Founder & CEO, Traklight)
Startups — even on a good day — are not for the faint of heart. When my startup recently rewrote our software from scratch and completely revamped our website, I learned a few important lessons about process — and about biting off more than you can chew.
Though aspects of the 3.0 launch were certainly challenging, seeing the enthusiasm and determination to pull together across the line was inspiring. Many individuals stepped up and shone, some in completely new areas. When all was said and done, our group benefited from stronger team bonds. And, we had a brand new website, e-commerce system and several software applications we could be proud of.
Yet the next time we undergo a product launch of any size, we’ll draw upon these 10 lessons we learned from our 3.0 launch.
1. Take Small Bites
Re-launching our entire website, e-commerce system and software applications all at the same time might have been a bit much for one go.
Now that all of the above are complete, regular monthly updates with a tight process will be manageable.
2. Plan and Document with Details
Each leader had their own project plan. A couple of attempts were made to create overall plans, but we needed to have a detailed planning session with one overall list or project management Gantt chart that everyone could work from.
A product launch is a team effort, but one person has to have accountability for each project that needs detailed tasks with timelines. We experienced some pain in terms of people working on the same task, which led to missed tasks and rework.
3. Quality Assurance is Key
Without a detailed plan, we also had a free for all testing system (or lack of system) that led to mass confusion.
Testing should be orchestrated to have first programmers testing (that worked); then official QA testers, followed by the “average bear” tester. An average bear can be a team member that does not normally spend time in the software, not anyone in development or in the software on a daily basis.
For example, our average bear testers noted that it was difficult to locate the report download button on the dashboard. We choose to launch with the button “as is” and sure enough, customers were confused. We’ve since changed the dashboard to make the button more clear. The average bear is an important source of feedback.
Testing and stopping to debrief is critical. If the root cause is not determined quickly and testing continues, it can be extremely difficult to isolate problems and it wastes resources. Like everything else, having a detailed testing protocol will save time and headaches.
4. Daily Huddle Plus Critical Path
The daily standup or scrum meeting works. But now we’ve decided to add a critical path component with a top three priorities to our ongoing operations. This would have helped us greatly during the launch.
Syncing up priorities to ensure that we are all focused is a weekly task for the team and a daily task for all the Trakers. But we would have benefited from taking it one step further to flag the critical tasks to move forward with more focus.
An example: I have on my list to document the features and other details for the new pricing page and write a blog post for launch. I need to assess the critical path of both tasks and evaluate who is waiting on me for both.
For the blog post, it will just need some editing and can be easily posted using our Hubspot COS, even by me! But for the pricing page I have to confer with our CFO, VP Technology and our marketing team, then pass onto our creative person. She has to do a layout that includes pricing, and then pass onto the programmer. You get the idea: pricing page work first and blog second. Seems logical, but in the chaos that is a huge launch, a daily check-in on priorities and critical path can be a lifesaver.
5. You Cannot Know too Much
We all need to know our own software and how all the systems work together. Gone are the days where you say you work in marketing, thus do not have to understand the software applications.
We’re having a team-wide session on the topic of ITSMARKETING™. Our software applications, ID your IP® and IP Vault®, are our proprietary IT and we have Infusionsoft® plus Hubspot® that are our sales and marketing or SMARKETING and our IT systems. A lack of understanding of how those systems integrate on our staging and live sites can create challenges regardless of your role.
6. You Can Review too Much
If you’ve reviewed something twice, it’s best to bring on a new team member for further review. We had some very funny typos and whoops go up on the site because we did not follow this simple rule.
7. Launch Slowly
It’s tempting to shout to the world when you launch, but you are better off quietly alerting existing members and working with close fans first, at least for one or two days.
8. Put Customers First
When you’re no longer in beta and are making significant changes that require password resets, as we did, make sure you notify the current customer members first. A simple advance post on the website of scheduled “system maintenance” or a short email or blog post will do.
All launching early morning Pacific Time and scrambling with some early bumps in the payment system, we will only be conducting system updates during off-peak hours or late night/early morning determined by time zone.
9. Use One PM System
Use one primary, predetermined system of project management (PM) and find your groove working with team members – emails, instant messages, Excel lists and visual plans.
10. Keep Visual Plans
Our new rule is that any project lists posted to office white walls must remain until the project is completed. We had a great list of 3.1 items that we built over several weeks.
In an ironic twist when I asked for the picture of the lessons learned from launch, it was nowhere to be found and the walls had been erased. Thankfully our Ops Specialist had the notes!