Product Hero: Karen Tirozzi, VP of Solutions at ZappRx
Preparando audio para descarga.
Escucha patrocinada. El audio empezará en pocos segundos...
Escucha sin anuncios y sin esperas con iVoox Premium
Pruébalo GratisiVoox Podcast & Radio
Comparte éste audio
Enlace directo
A continuación: The Dirt: Creating Strategic-Minded Design Teams and Design-Minded Product Teams Cancelar 10
Preparando audio para descarga.
Escucha patrocinada. El audio empezará en pocos segundos...
Escucha sin anuncios y sin esperas con iVoox Premium
Pruébalo Gratis
Product Hero is our bi-weekly series to highlight outstanding members of the product management community. These industry leaders share tips on processes, team building, how to be a better product manager, and who they are outside of their careers. This week our product hero is Karen Tirozzi, VP of Solutions at ZappRx.
Listen to the Show http://traffic.libsyn.com/thedirt/Product_Hero_Karen_Tirozzi.mp3 Download the MP3
Subscribe through RSS
Subscribe on iTunes
Subscribe on SoundCloud
Subscribe by E-mail
Show notes: Follow Karen on Twitter and connect with her on LinkedIn
Learn more about Karen’s company ZappRx
Podcast transcript: Heath: I’d like to welcome Karen Tirozzi into the studio. Karen, welcome.
Karen Tirozzi: Thanks, thank you.
Heath: We first met when we worked together at a company called, PatientKeeper, but what I want to do is actually walk back before that. How’d you get to where you are today?
Karen: I think my first intro to it was very informal and actually at PatientKeeper, which was the first technology I worked at coming out of clinical practice, way back. I’m actually a clinical social worker. I made the switch from being clinical to the IT side primarily because PatientKeeper was looking for people that understood clinicians’ work flows, and since I was part of care team, that was the conduit for me to go over to this technology team, which was very nascent. I think we were series A at that point, maybe on the hunt for series B, but there really wasn’t a formal product team yet. Most of the feedback that was coming in was from those of us that were attempting to implement in the field for the first time. Not having ever worked with technology before, it was sort of yawning the gulf between what we were building and thought was the right thing, versus what the physicians might actually adopt.
Part of that came from my recognition of what the day in a life of a physician is, having worked side by side for as many years as I did. Part of it was sort of learning the technology and figuring out how to fit together or what the day in the life looked like, and what was possible on the technology and knit it together. My initial exposure to end users in technology was that sort of bleeding new product, and trying to figure out how to get it as close as possible to fit within the physicians’ workflow as it could be. It was surprising to me that the feedback that I was bringing was actually shifted the product. That was really fun.
To see the physicians actually start to use it and find value, and find value in ways that we didn’t expect. That was another learning point for me. This was a charge capture product that we were building, not very exciting. Doctors don’t love to gather their bills but at the time, the hook in the product, which was completely unexpected was, that when we could push out patients in their rooms, like what room number they were in, that was one of the impatiences to get the physicians to, then, that they had to physically sync their palm pilots, tell you how far back we’re going, to download the day’s schedule, but actually told them what room they were in. That was one of the features that got them to actually sync their device every day so that they knew where they were going as they were going through their rounds.
Little things that I learned on the front line in the beginning really excited me about how you could use technology or products to really enhance or change someone’s experience in their day to day world for the better.
Heath: The first thing that sticks out to me is that I often find that products are designed or created for one reason but once you finally put the focus on the end user, you find out they use your product for a totally different reason, or in the case of PatientKeeper, they were using it because it was bought for, say charge capture, but the value they were really getting out of it was to be able to find out where their patients were in their rounding, and how to literally find them, and then from there you start to iterate and expand on that value prop, and that starts to really drive adoption and getting really loyal customers who use your product because they love it and not because someone in administration bought it or something like that. Sounds like we had a similar entry point into product management where I was clinical as well, albeit on physical therapy side, started to work for a company as a precursor to WebMD. We didn’t have that role. We didn’t have product management.
Granted, back then, it was new concept, I think, in general. I’m sure Microsoft had it but it was sort of a new idea, product management, as a formal role. They approached me saying, “You seem to be asking a lot of questions about why do we do that and why do we do that,” and when I talk to users they don’t seem to get that. Someone had the idea of, “Well maybe we need something that, someone that focuses on the end user and how we build things instead of just building things to build them.” I’m finding that a lot of people come, no one leaves business school, for example, with a degree in product management. They end up in project management, I think the stronger product managers, myself excluded, they end up in product management because of a connection they have to a user. Either they were one themselves, so they had the clinical background, or at least they worked side by side with the target users so they had empathy for those users and could really dig into what it is they needed and why.
How did you make that transition at each stage? You started off as a clinical social worker. Was PatientKeeper was the first non-clinical job you had?
Karen: Mm-hmm
Heath: You were in client services, right? You ran client services.
Karen: I did eventually but when I first came to PatientKeeper, it was still a small company. Technically I did QA, implementation, some product management, but was never officially product management. I actually came to the QA team for about three months, until we actually started getting some beta customers, some pretty big ones. The idea had always been that I would just get in there and learn the product and the technology, and then go out in the field to help deploy it. That’s what I ended up doing for most of the eight years that I was at PatientKeeper.
Heath: Was there a particular event or place or product where there was an, “Ah ha,” either on your part or a recognition by the organization, that the user really needs to be driving this or that they are the ones who should come first in driving our road map, or what we’re releasing or what we’re developing?
Karen: For me, this is sort of a really rewinding but, my first two years of college, I was in the school of engineering at Boston University. I was taking programming classes, so I had a little bit of that background. In fact, I ended up switching my majors, only because I took four, my four credits that I had to take in humanities, all in one semester, and going to Spain for a junior year, and loved it so much I just didn’t want to look at a computer screen. I was like, “This is way more fun to be out in the world than programming.” I ended up going and working at a couple hospitals, then going back and getting my master’s degree in social work, and then doing some years in social work.
When a nurse friend of mine left the hospital to go to PatientKeeper, she was sort of tugging at me to come, and the way she pitched it was that I could marry that background that I had with the clinical. I didn’t have to choose anymore because there was always that sort of geek or nerd in the back of my brain that liked how things worked and fit together in the technology side. I ran the website for our social group. I was that person.
Heath: You were the gearhead on the staff.
Karen: Exactly. I was the gearhead on the social work team. I basically followed her over and took a leap of faith after some particularly bad weeks in the hospital. It’s hard work to do to for a long time, direct care and social work, and really had a ball. It was fun to build something, contribute to building something that was so new. It was really cool to be using palm pilots back then. I know, you roll your eyes but it was true. Doctors wanted them. You were making something completely unsexy. You have to do your bills, and putting it on a device that was brand new. It was exciting to them and actually gave them something we never intended, which was a way to make their day more efficient, going up and down the elevator.
Heath: Remind me of the first company where you actually had formally in your title, or formally in your role being product management.
Karen: That was Health Leads. Health Leads is a non-profit organization, a pretty sizable one, that also is in the healthcare space, providing at that point services to help patients get connected with organizations in the community to help with basic need deficits. If a patient and their family is food insecure, we provided services to a primary care clinic that would help them find the resource in the community to get them food, or find the resource to get their heat turned on in the winter time, really basic needs. It was primarily a services organization though. They had a research database that they purposed to organizing cases or patients and a separate system that they entered the community resources into.
Anyway, when they hired me, I was their VP of research and development. One of the first projects was to build some sort of technology, platform to underpin the program. Pull out of this very static, very difficult to manipulate, difficult to report on, and frankly hideous to look at, research database, instill a very commonly used research database. I couldn’t believe how we were basically torturing our volunteers through using it. They were all volunteers, and marry that with a well sourced dictionary of community based resource organizations and tag them, and try to make some sort of algorithm whereby you could match what a patient screens positive for and their need, to know what might be on a bus route near them or what might be in their neighborhood, walking distance or near their work, and try to really triangulate down very closely to one or two, or three at the most, organizations that could help meet their need. That way was completely from scratch, build of the product to do that.
Heath: What was either your biggest product management mistake that you’ve made or that your team has made, or that you have seen made in a company you’ve been, or elsewhere, that you’ve now learned from?
Karen: I would say, actually, that it’s from Health Leads, that first one that I truly owned and oversaw the build from scratch. I think, all those years at PatientKeeper with Jeff Sutherland there initially, that sort of concept of an MVP was so hammered in, and I still actually hold very closely to it, because I think that’s what lets the user feedback really influence your product, but I think I hued a little too closely to it and I, we almost put out a product that had a terrible UI. All the features were there but it was very ugly. I felt like it was an improvement on the research database that they were using, but I didn’t really appreciate the design aspect of putting out a new product when I first took that role. I had a real back and forth with the, my counterpart on the technology side of what it should look like. We were trying to get this product, the base product, the beta product, stood up in six months. I had just started there maybe like two months when we got funded to do this. I was looking at that as a nice to have, not an MVP.
Heath: The design was a nice to have?
Karen: Design, yeah. I wanted the feature set. I wanted the functionality to be there. I wanted the work flows to be supported, but the design of how it looked or how we got them through task A to task B, that kind of stuff, I was really less excited about. I’m grateful for the technology team for talking me out of it, but they really didn’t talk me out of it as much as they decided they were going to be able to deliver that on top of the features, in the same timeframe. I said, “Great, if you want to commit to that and do it, then by all means, let’s go.” They did and I have to say that the way that it looked, I think so engaged to the user base that the adoption was quick, and beyond that, it got the attention of healthcare organizations beyond us, who saw us using it, that it really looked like a real professional product, and iterated on top of that to actually be purchased by outside organizations. It was truly something we incubated and built inside, that had enough value and was engaging enough that other disciplines started to use it, after we had gotten it solid internally for our own use, like large organizations used it.
Heath: The goal of getting all the features and functionality in was satisfying and yet there was this arm or team saying, “Look,” whether they were saying it outwardly or implying it, “That’s great we got that in there but what if they users never get to that, if the experience is so poor, will they even enjoy the fruits of our labor on the functionality side?”
Karen: Will it still feel like a slog to use?
Heath: Right. Companies you mentioned how it looked, as importantly you talked about can they get from step A to step B to step C? Can they actually accomplish what we want them to accomplish and what they want to accomplish in the product because of the way the experience is designed? It’s the way it looks or the UI aspect, it’s the way it’s designed, the action piece of it, and then okay, I can move fluidly through your nice looking product, but can I actually do what I need to do, and there’s the functionality piece. It’s like all three of those things need to work together and that’s why I find some of the better product leaders out there are not, they’re not good because they know how to do all those things, they’re good because they recognize that all three of those things have to be satisfied in the product, and they can work with the different teams who have the expertise to stitch that together to say, “Okay, now we’ve got an MVP or V1, or something like that that is sufficient for us to release into the wild.”
What are some products you admire for whatever reason, because of what they do or the service they perform or the way they look or work?
Karen: There’s a few different types of products, I guess, I would put out there. I’ll tell you one that I use every day, maybe not one you would expect but I use the BBC app almost every day to get my news. The simple things I love about it are it’s surprisingly informal for the BBC. It will say, “This is why you care,” or “This is what it means.” They’ll give you a story and then their summation at the bottom is sort of a distillation of it. British audience is sort of a … Worldwide publication, I guess isn’t the right word, but they’ll … Something else, something will happen here in politics and then it will be, “Here’s why it matters,” or there are some of the investigations that are going on, so “Here’s how it works in American politics, or “Here’s how the process goes,” so you could read the story and then get the infrastructure around it.
I like that about that app so it tends to be where I go to get my news more often than not. That’s one place that I go often for news. I enjoy it for the reason I just stated, but also because it can, just refreshes in the background, and so I could be on a place or in transit and just read it, not be disconnected, while I’m disconnected, which I like.
The other one that I’s sure is a little bit more cliché, that I still use multiple times a day and enjoy, is Facebook. I feel like it’s just a community that’s sort of connected in a way that didn’t exist before that came on the scene, that’s really fun. I think it’s less fun now that most of us are married and kids. It’s like a different kind of fun, but it’s nice to see people in high school that I didn’t know forever, or hadn’t talked to in forever, but still thought fondly of and be able to just see how they’re doing. I just feel like that app, that browser I guess at that point, now I almost only exclusively use it on my cell phone, but it just changed they way we’re connected. To have that kind of impact is so huge. I can’t think of another app that I would have used for that long. This was probably like 2003 or 4, something like that.
Heath: ZappRx, so pretend, I don’t know what ZappRx does, tell me about what ZappRx does.
Karen: My role, as VP of Solutions, I head both the product teams and the client services team. What we do is provide a digital platform for prescribing specialty medications. Specialty medications, despite the fact that I’ve been in healthcare for almost my entire career, I had no idea what those were before I joined ZappRx. They’re sort of the retail side of medication that you can go to your corner CVS or Walgreens, or insert name of chain pharmacy store, and get your medications filled. Then, there’s an entirely different sort of class of pharmacy that handles medications that are either, have special handling requirements to them, maybe there’s temperature requirement or some sort of handling requirement, or frankly that the price tag is just so high that they can’t be stocked at a regular basis at your corner drug store. These specialty pharmacies handle those medications.
Because they’re outside of the regular realm of retail pharmacies or prescriptions, there’s a different way you get access to those medications. It’s less digital today. It’s more chopped up. They’re, frankly, I think more hurdles to them because of complexity of the medication itself or because of the price tag that goes with it. ZappRx, essentially, found this issue where physicians or their staff were still handwriting these prescriptions, but these prescriptions are not traditional prescriptions like you have a prescription pad and can write on or can just send off electronically now. There were multi-page enrollment forms where you had to enroll a specialty pharmacy or you had to enroll in a particular hub that might be sponsored by a pharmaceutical company to facilitate dispensing of that medication.
Essentially, with every different disease area that can be treated with specialty medications, there was a different process through which you could get access to those medications. That is frustrating for the clinicians. It’s confusing for the patients who may have just been diagnosed with a very serious and scary illness. The specialty pharmacies often get blamed for not dispensing quickly enough, but then maybe the payer hasn’t actually authorized it to be dispensed, and there’s a high price tag. Patients are not going to pay out of pocket for these sorts of things. It’s a confusing landscape and almost technology void compared to some of the leaps and bounds in healthcare technology in other realms, that ZappRx has stepped into.
Heath: Users and healthcare, and by that I mean users of software but products in general, have suffered more than in other industries. Curious enough, have you had any thoughts about why you think that is? Is it something with the market? What is it about healthcare you think that makes it so dissatisfying for users of a lot of the technologies?
Karen: I think that most clinicians don’t go into healthcare thinking it’s a business. Somebody still needs to run the business and I think that’s not always healthcare people, and so the business people may make decisions that impact how healthcare is delivered without really understanding what that delivery looks like, and that leads to a big disconnect. One of the nice things about being a start up going into this base is, the bar’s kind of low in terms of the technology out there, so if you can give something that at all feels right, and show that you’re taking in their input and putting it back in pretty quick order, there’s a lot of gratitude out there for that. We are definitely seeing that in our current company.
We just re-wrote the way you prescribe in ZappRx in a pretty fundamental way. We released it about three weeks ago maybe. We had one process to get a prescription out and then a different process to get a prior authorization out for the payer side of this. Now there’s one process that you can travel through ZappRx, at the end of which spits out one or both of those. That’s been kind of novel out there. We did a lot of testing with our current user base before we did this, learned from that mistake of ignoring the design aspect. We spent a lot of time, the technology team, spent a lot of time on how it looked and how we put all of the different actions you can take through the course of doing a prescription or a prior auth on one page before we put it out there.
The fact that that doesn’t exist in another product, sort of co-mingled with one throughout to do something that most clinicians hate doing both of them. They hate doing the PA, the prior auth, and they hate doing the prescription, because it’s just time intensive. We just unified that and in one shot they get both of them now. When we started to demo it, the response has just been great. There would be times before we made this change where someone might say, “Well, you know I always do the prior auth first,” and we didn’t allow them to do that in our product previously. The very first demo I did after we pushed to production, this big fundamental change and how our product works, I got that question. It was over a white x, so they couldn’t see the big grin on my face but I was like, that’s check, validation number one, in the first call, that we were onto the right thing.
Heath: What is your relationship with your users? How do you guys validate the problems that you solve?
Karen: At this point we are doing mock ups so that we could compare to what they’re doing now and show them what we’re thinking about, and get their feedback on it. Sometimes it’s hypothetical, walking through the current product and saying, “What if this happened here,” of if there’s a new feature that we’re pulling in, sort of where in the workflow do we insert it, and so we’ll get feedback on that, just using the current product but for something as large as the redesign, we just did, we actually iterated with all of our users. Our user base is relatively small still, so we can do that, but we went directly to them with mock ups.
The other thing is, we just got a sizeable investment. We just closed a series B, and GV, or formally Google Ventures, is one of our investors, and they bring with them incredible depth in terms of the resources that we have access to as a company. This was less under product management but the product team, the product development team actually did some design sprints with them to get their feedback. They have other healthcare investments and they have a design team that does this. We both use direct user feedback and some external feedback that was available to us through our investor.
Generally it was new for us, so it was really with this new UI project that our head of technology said he wanted to introduce design sprints before the engineers started building, and it was new concept for me too. The Google investment came in, GV investment, excuse me, came in while we were in that early process, and so it plugged in nicely for our head of technology, who’s also our chief designer, basically.
Heath: There are a lot of buzzwords out there, some of which we just use with design sprint, but lean, agile, scrum, design sprints, how do you guys ship product at ZappRx? What do you, what’s your methodology?
Karen: It’s Scrum based. We don’t fully use the methodology but we’re small and there’s only a couple of us on a product team and maybe eight or nine on the technology side, so we are, we do stand up every day. We do two week sprints and have a spring planning and sprint retro, every other week, so we do those basic tenets. We track everything in a bug tracking system, both new features and issues.
Something new to me, in coming to ZappRx, has been that continuous release cycle. We do push new product every two weeks, out into production. That’s also nice to have, even for a small tweaks that we get back from the users or small issues that get found, that we have a fairly quick turnaround time for addressing those, which I’m sure as you know, is highly valued by an end user. We’re not doing anything fancy or crazy around methodology. We’re using, essentially, the bare minimum that gets us to build what we need to into production and as bug free as possible. We do take a little bit more time than the two week interval to do some of the bigger things. Yeah, it’s definitely scrum based and as we grow, I think we’re going to need to think more deeply about how we want to structure that as we add team members, but this is where we are now at this phase of the company.
Heath: How do you guys communicate across teams? You mentioned you’re fairly small. You’re pretty much hyper local. Are there any particular tools or processes you use to communicate across the teams or is it just tap on the window and say, “Hey, come here for a minute.”
Karen: Well, yeah I mean we have, there’s a lot of different tools we use, I guess. We definitely use Google Docs and Google Spreadsheets a lot. We’ll link to those documents into the JIRA task, so we use JIRA. That’s sort of the collaboration with the technology team is mostly through those tools. The design team on the technology side also uses something called, Mock Ups. For example, when we show screen shots or prototypes to our end users, like we did with this redesign work, they came out of that tool. On the sales and marketing side, we use Slack. With the expansion of our sales team, post our Series B close, that’s gotten a lot of life into it. It’s been really fun to have some pretty lively conversations and sharing of information and things that they’re hearing in the field, that I’m no longer at the hip of our one sales person, now there are five or six of them.
It’s been a nice way to get, still that infusion of information of what they’re hearing when they’re taking new calls, back into the system, which has helped me still feel connected to what they’re doing on a regular basis. I guess that’s the other tool that we use on a regular basis, both for what they’re hearing in the field around, really to our product, but also to what potential competitors are doing or what other companies are hearing about in the space that could either be competitors or potential partnership opportunities or collaborators.
Heath: What keeps you up at night? What are the biggest challenges you guys have?
Karen: For us it’s getting physicians on the platform. The revenue model for our company is really around a data play, the physicians don’t have to pay to use us. We’re in a situation where we need to get as many physicians using our system so that we have enough depth on the data side to actually package up and sell, and produce insights back into the market on. I think that’s the number one thing.
Number two is, because this specialty prescription market is so fragmented, there are so many different companies doing either pieces of what we hope to do or who have just different stakes in how the process unfolds, that it’s really about getting good partnerships in place as well. That’s also a very active and energetic initiative right now, is to really get focused on the business development opportunities and challenges that come with putting ourselves in the middle of this process, that there are a lot of competing ideas about how to do it right and a whole lot of dollars tied to it, and a lot of different stakeholders who want claim to those dollars and how they flow.
Figuring out how to get into this market with partnerships that are like-minded and wanting to bring some transparency to how this happens, to make it a lighter burden on the clinicians, to get the patients on therapy that they believe need to be on therapy, and to get the patients on therapy faster and with less stress. It’s been a challenge. It’s starting to be a challenge in the more fun direction than I think it probably was a year ago, where the message is starting to resonate and we’re getting more providers that are talking about us. That helps. I’d say getting more of those providers that are happy with the platform and vocal about it, to these other entities. Then, getting these other entities to actually work with us. Those are like the specialty pharmacies themselves, the health plans and the payers, and then frankly, the pharmaceutical companies that are making the drugs, all of those are different stakeholders with different wants and needs out of this, and not traditionally partners that want to work together in a common direction.
Heath: What, if anything, do you think is missing from the conversation from product leaders right now? You’re a product leader, you’ve been in product management for years, what would you like to hear or read or see more that’s talked about that’s missing?
Karen: There’s just sort of a core tenant of don’t wait and just get it out into the field that I think gets lost sometimes. We spent a lot of time in those design sprints that I just mentioned, and I started to get that itch of, “Yeah, but we just got to put it in front of them,” so that’s sort of a fundamental, I guess, that I hue closely to, that is probably completely unsexy and not exactly the exciting answer you want to hear, but it’s one of the things for me that keeps us going, keeps us doing and stops inaction and second guessing internally. Put things out there for your users and don’t be so whetted to whatever you built. That’s why I think overbuilding is such a waste of time.
Heath: It’s impossible to roll back features and functionality because inevitably there’s that one sales rep that’s sold one deal based on that functionality or maybe there’s that one client for whom you built it and they may not even still be a client anymore, but that’s now lower and you’re stuck with that feature or functionality, even though it may be completely holding you back in terms of supporting a platform that’s out of date or a code base or something.
Karen: I think the other thing is that it’s okay to say no sometimes too. You’re going to get a lot of different feedback from users and you have to sort of go back to what is your core strategy for the product, and if you get feedback that brings you completely away from that, you have to really think before you abandon or shift gears so dramatically. That’s not to say you should only listen to things that validate your strategy, but you have to follow something. Otherwise, you’re just too diffuse in trying to do too many things. You can’t be all things to all people, so there’s got to be some north that you’re headed toward. Some of the mistakes I’ve seen the companies I’ve worked for make, and probably I advocated for lots of them, or too much of saying yes to what particular customers were saying, customers who may have a lot of size or weight, and maybe good for that customer but takes you a little bit away from the overall company strategy. That’s the other thing that I think is hard for people earlier on in their careers, to say no.
Heath: You’re sitting in front of a young or not young social worker who thinks they want to get into product management. What advice would you have for them? Don’t do it.
Karen: No, I’d say great and spend a few years still doing the direct service because somebody needs to. It’s funny because social workers are notoriously not technical. It’s hard to even imagine that scenario, to be honest. I think the thing I would say is that whatever fears you have about making the shift, that fundamentally you know more than you think you do when you make the shift. My joke is often that I have a master’s degree in business meeting facilitation because I learned family therapy.
Heath: That comes in handy when you cross functionally.
Karen: It does cross a little bit. That’s to say that if you want to make a shift into managing a product, don’t discount the knowledge you have doing whatever role you were doing on the clinical side front hand, is tremendously valuable and translates very well into building a managing product.
Heath: That’s all I got.
Karen: Thanks for inviting me.
Heath: Thanks for coming.
Comentarios