For the past year, as Director of Training Products for Mind the Product, I’ve been creating a training platform and service. During this time I’ve worked with dozens of companies and hundreds of product managers; hearing about their challenges, and working with them to set game plans for shifting practices.
The one theme that has come out of working with these clients is that other departments in a company could work better with the product team/s. In my musings on how to address this issue, two tactics have emerged; the creation of understanding, and building a roadmap towards complementary practices.
So, how can departments who are not building software “mirror” the approach of product teams? By viewing their outputs as products, and taking the same approach to evaluation, communication and optimisation as best-practice product teams. Until my current job, my products were all software projects, so it was an eye-opener for me that, even though I’ve shifted to building a service model, nothing about the process I run has materially changed.
I’ve managed to shuffle the myriad of Mind the Product activities into four buckets in order to break down the process into pieces that other departments can mirror:
Align Around Goals
Product teams understand that in order to explore a complex and changeable domain, clear goals are a rock-solid requirement. This includes top-level goals that define a clear vision, but also more detailed goals that help teams to understand how they should measure their day-to-day outcomes.
I believe that once “testing goggles” have been acquired, they cannot be let go. Once a team understands that, each action they take is then a hypothesis, and outcomes either validate or invalidate what was understood about the product. At MTP this means that we structure all our activities as hypotheses, for example, “We bet that sending materials ahead of time will impact participant engagement,” and then we measure the results.
Take Stock Regularly
If a team is always testing and therefore always learning, then the distillation of what has been learned must be fed back into the product at regular intervals. For every major activity or milestone that MTP Training experiences, we have a retro with the team involved, evaluating what went well or what didn’t go well.
Bake in Continuous Improvement
Just reviewing the good and bad is not enough. Teams must also create and address activities that might cause improvements. Retros should culminate in a list of action items that are meant to alleviate past friction. An organisational culture of openness and transparency is needed in order to enable continuous improvement, but you can get started by scheduling retros consistently, and following through on the action items they surface.
I’ve seen bakeries and law firms espouse these concepts. In general, if an organisation can drive for general adoption of these processes, then not only will departments work more effectively with product teams, but they’ll generally work better.