From Nurse to Product Manager – How Combined Knowledge Improves Value-based Care
In learning that I would be awarded a spot on the FedHealthIT100’s list, I reflected on my career. As a nurse, IT was not a chosen field for me. In fact, when I was looking at master’s degree programs, I could have selected a Master of Nursing in IT, but I did not. I chose Nursing Leadership because my career view did not include sitting in front of computers developing healthcare IT. I recognized the importance of this field and appreciated nurses who chose to work in IT to make EHRs and the other IT that clinicians use more effective and user-friendly. I didn’t know all the future buzzwords (i.e. human-centered design, product thinking, etc.) that encapsulate this notion of users designing IT solutions at that time.
As my career evolved from a staff nurse to a nurse leader to a clinical manager to policy work with the federal government, I still did not consider going into IT. Then, in a new role within the Centers for Medicare and Medicaid Services (CMS), I became accountable for the development and implementation of a new IT system. This was not a new IT system to replace a legacy system, this was a brand-new system that would impact CMS and state Medicaid agency staff. To say that I was a little overwhelmed would be an understatement. I was proficient on a computer to do my work, but that was the extent of my IT knowledge.
Words like Drupal and MySQL were a foreign language to me. Fortunately, the evaluation panel selected a strong contractor to build the system. Thus, my foray into IT began, using product thinking and human-centered design before they were cool. The end-users of the system are policy people, not IT people. We had no system to consider or react to, let alone any concept of what user stories were. I was determined not to fail (I am Type A, after all, and had started my doctorate program at the same time).
I frequently met with the contract’s project director. I let them know that this was not a typical contract where the government hands off requirements and disappears, leaving the contractor to figure it out. I also sought help from my IT colleagues who could guide me when I had questions. When you are taking a group of 20+ people and states from no IT system to support their work to a structured IT system, there’s a process. In theory, people should be thrilled and excited to finally have the technology. In practice, it was an organizational change for stakeholders who were accustomed to barriers in their work. There was no excitement, just resistance.
To get my colleagues and the states on board, I insisted that we have frequent communications about what was happening and what was coming. I insisted on frequent requirements meetings, short enough to fit in people’s schedules and often enough to get feedback. Our initial meetings were used to listen to what the users wanted from an IT system and capture their vision. Since the notion of what an IT system would look like was abstract, I asked for wireframes. Ok, I didn’t know that I was asking for wireframes at the time. I probably said something naïve like “Can you develop a model or demo for us?” My contractor partner willingly did that for us. Yes, I now viewed the contractor as a partner because if we didn’t work together, this project would not succeed. I couldn’t let failure happen. We frequently met with stakeholders and attempted Agile methodologies (we weren’t ready to be completely agile – we couldn’t meet the standard timelines or having a product owner in the scrum team full-time). We developed advisory groups that met frequently. We provided in-depth training sessions that were flexible enough for people to attend as they could.
We hit barriers, such as waiting on the provisioning of cloud services, delays in leadership approvals, etc. The delays were all normal and to be expected in a government environment but, again with my IT colleagues and my contractor partner, we delivered the minimum viable product on time and under budget after re-baselining. Yes, we re-baselined after the delays we had no control over.
Fast forward a few years, we continued to launch major releases every year. We were known to have a successful IT system, even though my senior leadership was relatively unaware. That seems backward, but when the system isn’t known, it means you have had no significant issues. Even when we won a FedHealthIT Innovation Award, we stayed under the radar.
Fast forward a few more years to the present. I have amazing colleagues in the industry who do phenomenal things like Artificial Intelligence (AI) and Machine Learning (ML), create software start-up products that simplify what used to be a daunting task, and cybersecurity experts who speak a whole other IT language. I now understand that I was a product manager implementing product thinking before it was a thing. I applied my nursing expertise to IT system development and change management without realizing it.
As I now reflect on what is product thinking and management—why is it the new cool, and why does it result in better products – I realize that these concepts are no different from my soapbox about what is the meaning of true value-based care. Bear with me here. In nursing school, we are taught to develop care plans and to focus on what is meaningful for patients: establish goals and the outcomes to measure whether those goals have been achieved. Working in hospice solidified this notion for me. It is about what is important to the patient and family – not what the textbook defines as a good outcome. I could go on, but that warrants its own blog.
Nurses and product owners carry out very similar functions, mind you in different environments. When tasks are boiled down into simple forms, there is a striking resemblance. For all my clinician colleagues and friends, I am not downplaying the importance of caring for patients and families. I am referring to the common skill sets needed for both roles.
Both roles must communicate effectively with a wide variety of people with a range of personalities using different techniques. Nurses communicate with other clinicians, patients, family members of all ages and opinions, management, and any other well-meaning person (ahem – IT support). Product managers must communicate with their teams, their clients, the end-users, and all those stakeholders that may touch the system along the way (such as other developers, system security personnel, etc.). Often, both roles may also face conflicting opinions and needs. A successful nurse or product manager must make sense of multiple inputs and formulate the plan forward. They need relationship skills, conflict resolution skills, and motivational skills. And for both roles, pictures say a thousand words. Most people appreciate visualizations, whether it’s conveying treatment plan or product metrics; thus, communication through visuals needs to be in your toolkit. Product managers and nurses must do all of this with a keen awareness of themselves.
That brings me to emotional intelligence. To manage conflict– among people, perceptions, schedules, etc. – to motivate a team and make progress, and even to visualize the future – a manager needs to understand their own biases, knowledge, impact on others, and organizational impacts. This type of intelligence cannot be understated. We need to know our limitations, how to engage with other people, and how to elicit the information we need when we need it. This includes understanding everyone who will interact with the product (or in the case of a nurse, interact with the plan of care). This topic could be a blog by itself. Emotional intelligence is crucial and encompasses many levels of awareness, some of which may contradict others.
While being aware of yourself, those around you, and organizational impact – one must also balance a level of technical knowledge. Some would say technical knowledge is crucial for a good product manager. While I find that this is very helpful (and essential in nursing), it is possible to be an effective product manager without a significant level of technical knowledge if you have the right partners. Self-awareness is knowing your limitations and being able to confidently surround yourself with those who fill your gaps. The same is true for nurses – none of us knows everything. Working as a team to meet the needs of patients or clients requires flexibility and working iteratively. Both roles work with people and design solutions for people. People by their nature change and evolve. Situations change and evolve. Sometimes, a lack of technical knowledge may lead you down the path of the right solution because you are not constrained by how you’ve been taught or past experiences.
Solutions and care plans need to be adaptable to meet the changing needs of clients or patients while still maintaining a schedule. The evolution cannot disrupt the schedule. Nurses and product managers must also be prepared for unexpected interruptions. There is a lot of external chaos during a nursing shift, but patients still need their medicine or need to be seen on time. The chaos usually needs attention but cannot detract from the patients’ needs. For product managers, there is daily chaos coming from different angles – clients, the team, bugs, business challenges – but the product development has to progress, and deadlines are real.
So, how did I get here? By translating one skill set to another problem, stepping out of my comfort zone, and learning non-stop. I took an opportunity and ran with it. That’s what product managers do. Effective product management requires continuous learning, flexibility, determination, and soft skills.