The Mind the Product Training curriculum is written in collaboration with dozens of expert product managers from countries and companies around the world. One the most consistent and frequent lessons that we teach in different workshops is “test early, test often”, also known as lean methodologies.
Two years ago, when I started as Director of Training Products, I knew that we wanted to create the world’s most comprehensive library of training topics for the product development lifecycle and all the skills therein, for product managers. It’s a Herculean task – which I began alone – and I began learning straight from the start.
In January 2018, we moved forward to create our third full-day workshop on the much-anticipated topic of Metrics and Analytics. However, because of the size and complexity of this topic, I rather lost the plot on the creation process. We ended up writing and then completely trashing two entire versions of the full-day workshop. This was wasteful, maddening, and completely avoidable. Luckily, we kept learning, and kept iterating, and in October 2018, rolled out our full-day workshop, titled A Product Mindset on Metrics, which received extremely positive feedback from a group of product managers at our London conference.
I’d like to reflect on the lessons we’ve learned over the past year, in the hope that these will help other product managers to identify and rejig their experimentation process.
The Process Stays the Same, no Matter What you Create
I initially lost the plot creating the Metrics workshop because I was thinking of it as something different from software, but it is still a product. It still solves a customer’s problem, it is still experienced, and its value proposition still needs to be clear. One of the most surprising things I discovered when I moved into service design is just how universal the product process is.
Start With Your Customer and Their Current Reality
We were making decisions about which new content to focus on based on customer requests and feedback, which is a good first step. However, I neglected to do a round of in-depth research about what product managers’ experience is with specific skills and how they learn them. If we had conducted that research upfront we could have saved ourselves a lot of time and tears.
Slice up the Product Into Testable Chunks
On two occasions I waited until the majority of the full-day workshop was in place before showing it to people. I didn’t have to. I could have done smaller review sessions with two or three product managers and got enough information to know if a specific module made sense and created value. It’s a fallacy to think that the whole experience has to be in place before you reveal it. Find your perforated edges and get your feedback.
Don’t be Afraid to say “This Isn’t Working”
Chucking out two versions of the workshop was not an easy choice, but carrying on blindly with content that I ultimately knew wasn’t fixable would have been worse. It’s a product manager’s job to report truth to power and to stand up for quality work. I took responsibility for not getting the research in place that would have helped us to course-correct sooner.
Fix the Process
While it came late in the game, we finally lined up the information we needed to write the workshop our audience needed. We had the courage to say “not good enough” and go back to the drawing board with the data and perspective we needed to do it right. You can also bet your boots that I will never embark on a writing project, large or small, without following the process that we developed through our mistakes.
While some people might give us side-eye for our admission that writing Metrics was tough, I think it’s beneficial to the community to admit when stuff is hard. It’s difficult to remember that we are not the user, it’s difficult to remember not to just go heads-down on something, it’s difficult to show ideas we are unsure of to critical audiences. At the end of the day, if we do not do these things, our customer’s suffer and we suffer. Mind the Product has believed for eight years that talking about the messy side of things is how we learn, and learning helps us build better products. In this case, it helps us build better product training.