Learning by doing in product
When joining a new team or having a new product to manage, you want to get up to speed quickly and be able to start creating impact. I've found that by embracing vulnerability and learning by doing I have been able to navigate multiple new domains throughout my career and become the go-to person for the product.
Embrace the chaos
When I joined the Micro:bit Educational Foundation, I had never worked in a hardware product role before. Sure, I had experience with Arduino and Raspberry-Pi as a tinkerer, but as a generalist I built enough understanding of the tools to be able to talk about them, but I didn't use them day to day.
The micro:bit is deceptively simple small programmable device designed for education. The reality of the domain in which teachers and students use the device is complex. School networks, Bluetooth connectivity, iPad compatibility issues are all pain points I became aware of and needed to understand deeply, not just technically.
I soon found the perfect way to dive into the problem space at PyCon, a Python-focused meetup in Cardiff, Wales. The team were presenting a two day event and asked me to support attendees. I'd been given a device during my interview and understood its basic capabilities, but I was uncertain about the real-world use and friction users experienced.
I began with reading the documentation, knowledge-base and familiarising myself with the support articles, but I wanted to speak first-hand with people using the product to see how it fits into their specific context
To do this, I set up one-to-one conversations with Foundation colleagues, asking directly about user pain points. I reached out to local schools, speaking with teachers about their classroom experiences.
To immerse myself further, I volunteered to help give a talk at the PyCon event on common technical issues and solutions, creating a strong pull for me to learn and feel confident. Working with David Whale, "micro:bit Wizard", we evolved this into something more interesting a roleplay session where we acted out typical IT support scenarios schools face- it's probably still on YouTube somewhere. Though it meant putting myself in a more vulnerable position, open to criticism I learnt more about the typical problems that teachers faced when using the device and it helped me empathise and understand.
By roleplaying real support scenarios, we created an authentic connection with our audience. Teachers and developers approached us afterward with specific problems, giving me unfiltered insight into user pain points. Empathy and connection works both ways, people felt more able to approach me because of this talk and I am still in touch with some of those people today.
In terms of my work, I could now field technical support questions confidently, having experienced common failure modes firsthand. The support team were able to created canned responses for common issues, meaning a reduction in unresolved tickets.
From micro:bit to eLife
When I joined the Sciety team at eLife, I faced an even steeper learning curve. I had been working in education and ed-tech focussed roles for much of my career. Scientific publishing, preprinting workflows, scholarly communication was an entirely new domain with established stakeholders and complex user journeys.
I applied the same learning by doing approach. I immediately joined daily standups and offered to facilitate them, gaining shared language and visibility into team dynamics. More significantly,I set up a"story-time" session which was a team meeting based around sharing domain knowledge and creating pulls for learning.
Story time is aimed to be a safe space for team discussion, "silly" questions, domain exploration, and user research synthesis.
By facilitating story I was able to move from asking basic questions about preprints to contributing meaningfully to product strategy discussions.Developers began bringing their own observations and questions too.
What I've learned across both experiences is that strategic vulnerability, being willing to not know, to ask basic questions, to potentially look foolish is beneficial and it's important to create psychologically safe environments that allow for it, creating conditions where teams can navigate uncertainty together
This approach scales beyond individual learning. Story time is a repeatable pattern for accelerating domain knowledge while building team trust.
In product work, where user needs and market conditions constantly shift, shared understanding within the team is a great competitive advantage.