Michelle Monaco is Vice President of Product Management at Truepill, a digital and physical pharmacy infrastructure company powering innovative patient experiences. Before joining TruePill, Michelle held product leadership roles at health-oriented software and research companies.
In our conversation, Michelle discusses leading fully remote teams and how she enables collaboration, trust, and fun through honest conversations, team-building activities, weekly syncs, and innovation days. She also shares methods for keeping team members aligned in a remote work environment, such as creating normal cadences for certain meetings and tying sprint review conversations back to overarching objectives.
I think the root of it is taking time and being intentional about human connections. The mechanics of that are lots of 1:1s — I do them with my direct reports and product people, but I also do them with colleagues across the organization. We have regular, honest, heartfelt retrospectives.
You have to cultivate psychological safety to talk about uncomfortable things. It doesn’t come casually like the conversations that pop up in the kitchen; you have to create space for these things. One of the ways we do that is by having a random question of the day in our team meetings, like, “Tell me about a time that you embarrassed yourself” or “What’s your favorite sandwich?” Sometimes they’re lighthearted and sometimes they’re a bit meatier, but it’s about getting to know people as human beings and not just transactionally.
The other piece of it is creating space for fun and play. We always focus on productivity, but humans need to relax and have fun together. Otherwise, stress builds and we see a higher rate of burnout. We have done team-building activities, such as gingerbread-house-making, where we sent everybody kits to their home and then did the kit-making together on Zoom. We’ve done cocktail-making parties with our Women’s Empowerment Group. One of the product managers on my team tells a dad joke at the beginning of each of the meetings that he hosts, and that’s a predictable little snack of fun that helps build connection.
It has to be a blend of both synchronous and asynchronous communication.
For the synchronous aspect, we hold weekly team meetings as an opportunity to meet live and talk. It’s not just me talking at the team — we’ll create opportunities for the different team members to practice their presentation skills and to have Q&As. We also intentionally embrace the awkward pause and default to cameras on. There is so much human communication that is nonverbal, and so we need to be able to smile at one another and see when someone’s confused (without them having to raise their hand).
On the asynchronous side, I love Slack and adopting its best practices. I’ve seen organizations where Slack is a huge mess that creates frustration and distraction. But when you treat Slack as the asynchronous tool that it’s supposed to be — where you put things into public channels, tag people when it’s appropriate, set yourself as away and people are respectful of that — it helps fill in the gaps for all those asynchronous pieces.
When I made the transition to remote teams, it felt a little awkward. I missed all of the in-person ways that we celebrate. I come from a very food-oriented family, and there’s all the jokes about product bringing the donuts out there. Trying to be more creative around the things that are explicitly physical, like how we celebrate things, was one of the biggest transitions.
I think also, looking back, it took time to get used to being on camera all the time. A lot of people resisted it because they don’t like to look at themselves on camera. But when you look at it as a gift to your colleagues, it is easier to make the leap and realize it isn’t a fashion show.
At a prior company, we had a mix of in-person and remote employees. The remote team members, I hate to say it, became like passive observers. They were always at a disadvantage in collaborations, particularly during the discovery phase. There were logistics of missing meetings because of time zone differences. They couldn’t see what was on the whiteboard or take turns drawing.
When we got to the delivery phase on user stories, they were slower. We’d have to stop and re-explain things or document them again because they hadn’t participated in the discovery. By not engaging in the upstream efforts, instead consuming them, our output as a team wasn’t what it could have been for the size of the department we were running.
We talked about the problem candidly. We were having healthy retrospectives and iterated toward making the process more inclusive, so we added tools like digital whiteboards. We had each in-person participant on their own computer and they would have to come off mute as well to speak, as opposed to using a conference-room-wide audio. That actually ended up increasing our velocity. I think the big takeaway was finding ways to make the in-person aspects equitable.
I love a normal cadence and creating a rhythm of normalcy around certain ceremonies and meetings. At the top level, we have a monthly product council meeting with our senior leadership team. We have a clear charter. Each month, we have a published agenda and send the content out as a pre-read, so that when the team comes to participate, we can have meaningful discussions and make decisions.
After each product-council meeting, about a week later in that same monthly cycle, product hosts a monthly roadmap and strategy review session with all the internal stakeholders. It covers a lot of the same content that we went over at the product council, but we report any of the relevant decisions.
On a more frequent cycle, our product development teams work in two-week sprints within the scrum framework. As part of the sprint review, our product managers talk about the sprint goals and how they tie to overarching objectives. It’s always tying back up to that, and then it feeds through and cycles through on that cadence.
We send a sprint recap with highlights across teams every two weeks about what was delivered and what’s coming up next. There’s a link in there to a form for new product ideas.
On top of that, we have a recurring product highlight segment during our monthly company all-hands. Someone from product does a demo and presentation to the company about something that was delivered recently or that we’re working toward.
One of the products I’m most proud of is a product that we never built.
Essentially, it would add a user interface on top of the data we were already selling. We sized the effort and it looked pretty expensive.
Before we built it, we created a lightweight prototype. We intentionally went low-fidelity so people didn’t get too attached to the designs. We structured interviews with all of our current customers, including people who had anecdotally said they liked the idea, to gauge their interest and willingness to pay.
The overwhelming feedback from our customers was that it looks kind of cool but, no, they wouldn’t ever have the budget to pay for that. We ended up with multimillion-dollar savings and the associated opportunity cost savings by not building that product that nobody would’ve paid for. The only way we would’ve known that is by talking to the clients themselves.
Because I’m an agileist and we’re using scrum, empiricism and the whole idea of inspect and adapt is embedded in the scrum DNA. That’s part of the ceremonies you participate in when you’re following that framework. With remote teams, a lot of people will dial it in, so you have to inspect and adapt your processes. You have to have those conversations and inspect and adapt your product.
We made sure that was happening by picking one tangible item out of our sprint retrospective that we wanted to focus on process-wise. For product innovation, we hold a monthly innovation day — it’s like a hackathon but different. It’s your own time to work on professional development through learning or iterating on a current capability, evolving a process, or cleaning up your inbox. Really, it’s whatever it might be that will help drive you forward for that next month.
At Truepill, we don’t have a regular cadence. At other companies, I’ve done it once a quarter or twice a year. We’re actually having our first one at Truepill next month and I’m very excited.
It’s one of my favorite things to do because people who are drawn to software engineering are usually incredibly bright and creative, but don’t always tap into their creative side as much as they should. This lets the business see what autonomy can do.
Every time I’ve done it before, it shines and opens all kinds of new doors for collaboration going forward. The prompt we’re doing for this one is, “What have you always wanted to build, fix, or learn, but didn’t have the time?”
For brainstorming, I think some of it is knowing when to get together in person. There are things that are done more easily and effectively in person and workshopping is one of those. Another is using technology for those tools and finding a way to capture the voice of introverts.
We use tools that allow people to participate. I love brain-writing instead of brainstorming, so people take turns writing and then you pass it to someone else. You can do that digitally using different tabs within Google Sheets or mind-mapping tools.
Another thing is limiting the group size. For remote teams in particular, anything beyond six people will have people switching into the role of observer instead of participant, so we’ll host multiple sessions. Or, if it’s a big one, we have done facilitating breakout rooms where there’ll be one facilitator for each small group of six, and then the whole group comes back together.
I am a big fan of Dan Pink’s book, Drive: The Surprising Truth About What Motivates Us, about how motivation comes from autonomy, mastery, and purpose. We can help align people around a shared sense of purpose and vision for the product and the company, but we also need to know their personal purpose.
We make sure that people have an opportunity to do something new — that’s easy in a startup but sometimes harder in a big corporation. I also have my teams pick their own goals and the timing that makes sense for the goal. We have regular career development conversations and try to maximize training budgets. We’ll spread out and not all go to the same seminar or conference and then come back to the team to teach what we learned.
I am incredibly optimistic about the future of work for technology teams in particular. There are certain industries where remote work is just not an option. But COVID really accelerated a rethinking of this mindset that came from the Industrial Revolution era about what management meant and what work meant. We’re continuing to see an acceleration of change. We’ve got AI, globalization, and better collaboration tools than we ever did.
I think we’re going to see an even bigger shift toward humanizing work — things like empathy-driven leadership and outcomes-based management. Instead of, “Are you at your desk for these hours a day?” I think we’ll see more flexibility around scheduling and work and life, living to work as opposed to working to live.
Remote work also creates opportunities for more diverse and equitable teams, people who’ve been historically marginalized or unavailable because of the need to all be in the same room at the same time. I think we will see a shift there.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
To help demystify stakeholder management, you can use tools that introduce a structured approach for your product team.
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.