And we are back! I was grateful for the fantastic feedback on Part I of “What does “product” mean in a virtual healthcare service environment.” It was encouraging and frustratingly validating to hear from others who have felt the pain and inconsistency of navigating product in healthcare. Part I focused on organizational inconsistencies of leading product in healthcare (e.g., is it just marketing or not?) and the value of having an “Expanded Product Team” responsible for designing and delivering the end-user experience. Part II will focus on the Team Rhythms to enable the structure to perform and drive value for the business.
Rhythms can mean a lot of things. In this case, I am referring to the regular cadence of reviews, discussions, prioritization, and updates that enable the delivery of excellent product experiences. Real-life examples can bring that pain to life; so, similar to Part I, here are two examples of how this has gone down for me in the past:
Company: There is an upcoming board meeting, can you send me the product roadmap?
Me: Ok… what level would you like this at or anything you want to focus on specifically? What time frame? What product areas especially?
Company: Yes. The whole thing.
Me: 🤨
Company: We need to be more agile in our development processes.
Me: Ok.. what do you mean? As in the traditional agile framework that some big companies in some industries view as a “best practice” or do you just mean we need to be more responsive and be able to shift gears on a dime?
Company: Both. I just want to show that we are agile.
Me: 🤨
It is easy to overthink and over-process the regular rhythms of how a product team works. This spans across teams, impacting work with each other, engineering, design, operations, and other key stakeholders (e.g., clinical team in a healthcare setting). These rhythms need to take into account the audience and the purpose. I am going to focus on the cross-functional company rhythms we have adopted as a product team that help ensure everyone is moving in the same direction at the same time with the same objective. Given our company size and stage, we have found these to be most effective in ensuring that work has the right level of visibility while not overtaxing the individuals driving the work.
This is a highly structured, highly interactive 2 hours spent every other month where all product and operational leads rapid-fire “pitch” a project they would like to start in the next 6–9 months (this is just how far we can look out at our stage). Projects show up to this forum when they require a high degree of cross-collaboration, and we need other teams bought into the work. The pitch must include the problem we are trying to solve, metrics for success, why we need to do this now, what teams need to be engaged, the customer/end-users impacted, and justification of its timing. We do not rely on slides. Attendees include the executive team and all key stakeholders who would be peripherally involved in the project. All participants are expected to challenge and ask questions to ensure this is the highest priority project that should be worked on. All product and operations managers are expected to defend their position and be prepared for follow-ups if there are holes in their proposal. Lastly, important and time-sensitive customer requests are discussed with the Sales Lead, Product Manager, and Tech Lead to get aligned on relative priority and shift the roadmap if needed to accommodate.
While individual product teams will create formal retrospective documents for specific projects, this time is focused on sharing learnings, best practices, misses, and post-launch performance. Participants include everyone involved with the development and delivery of the work. Teams are encouraged to focus on the broader takeaways that other teams can leverage as to why something was successful or failed. In our stage, it’s critically important to pause and reflect on the things that are bringing Curai success or holding Curai back.
We strive to take care of everything status related asynchronously via our project management software of choice, Asana. Our product and operations team leverages Asana as the backbone for tracking and connecting all of our work to our team and company goals. This goes beyond the typical tech roadmap items but focuses on the end-to-end experience. Here is how this works in reality.
As someone who operated at all levels in the product hierarchy, I deeply appreciate how tedious and redundant “status updates” for the executive team can be. While we are by no means perfect, simply setting up the right discipline and expectations has saved us many, MANY hours of meetings and conversations regurgitating project status.
Product Team Rhythms and Structure will get a company pretty far, but certainly not all the way to becoming a high-functioning product team in healthcare. The last piece is creating product culture, which I will cover in the finale — Part III — of what " product " means in a virtual healthcare service environment, which I promise will not take another ten months.
Thank you for taking the time to read, and I would love to know what you think.
