Interview: How Product Managers can produce results with UX
When it comes to product design, delivering products that are actually good, appeal to the customers heart and head, are profitable, and continue to optimize, means ensuring the user’s needs are considered along the way.
We sat down with Tomer Ben-Sira to learn how he’s delivered successful products. For over 7 years, he was a Senior Product Manager at McKesson where he managed a portfolio of products generating $50M-$60M in annual revenue. Now he’s helping Orpheus Medical with their product strategy.
During this candid conversation with Tomer, we discuss some of the ways he has enabled and advocated for UX within large and small organizations.
Anita Sedgwick: Alright, everybody. Welcome! Tomer welcome. You’ve had a busy day. Sorry to pull you out of things like this, but we really appreciate your time. A lot of people are joining us actually right now, so the timing is great. Okay, so let me start off. Hello, everybody! Again, thanks for coming and joining our live chat with Tomer Ben-Sira. My name is Anita Sedgwick. I run marketing here at Usability Matters, and I’ll be hosting our session today. Just to cover off a few administrative things before we kick off, this session is being recorded. So absolutely, once the session is done, we will be as speedy as we can and post a recording of it on our website. And feel free to go back in and check out some of those answers in a little bit more detail or share it with friends and colleagues. Also, we will be monitoring Twitter, so if you want to ask any questions via Twitter, please feel free to do so. Alternatively, in that little control panel, for me it’s on the right-hand side, there is a dashboard there for you to be able to ask questions and we will definitely be monitoring that as well.
Anita: That said, we really do wanna keep this session tight. Everyone’s got busy schedules, so we’re gonna really try to keep this session down to 30 minutes. So, Tomer, let’s introduce who you are. Tomer comes with an incredible amount of experience as a Senior Product Manager. He was there at McKesson for seven years, and he managed a portfolio of products that generated revenues of over $50 to $60 million in annual revenue. Now he’s helping Orpheus Medical with their product strategies. Tomer, can you just briefly introduce yourself to us?
Tomer Ben-Sira: Sure. Thanks, Anita. Hi, everybody. Good morning or good afternoon. I’m Tomer Ben-Sira. Today, I’m the VP of product marketing and business development at Orpheus Medical. It’s an Israeli start-up company that develops a solution for a centralized clinical video and visible light documentation and collaboration workflow in hospitals. Like Anita said, prior that, I’ve spent excellent 10 years of my life as a product manager roles in McKesson’s Medical Imaging Group. So, a lot of experience in the healthcare and healthcare IT and workflow solutions.
Anita: Awesome. Okay. Busy guy!
Anita: Alright. So, really, I think one of the goals of this conversation is to see how you have effectively been able to insert user experience design into your process. So, as a product manager, what problems do you typically try to solve for, specifically ones that relate to user issues?
Tomer: Sure. So, specifically and where I’ve worked most of my life is in the healthcare space and anything that has to do, affects patient care, right? And our focus was to solve problems that relate to inefficiencies in workflow while maintaining a high-level of clinical quality and accuracy of work. Also, counter-intuitively in several aspects, you need to think in doing product design how your users actually spend less time using your product in order to free them to focus on patient care delivery, whether it’s real-time or during a procedure or offline. Today, at Orpheus medical we have solutions that are both real-time for collaborations but also offline, so it’s a mixture of that. And that’s the main challenge that we’re trying to solve as product managers in the healthcare space.
Anita: Right. Yeah, that makes a lot of sense. I’m sure context really defines the experience as you use products, doesn’t it?
Tomer: Yeah, it does.
Anita: How have you tried to… Adding user experience design, there’s often a lot of pushback, right? Your dev team says, “You know what? Now we’ve suddenly, there’s more work.” So, how have you been able to insert that effectively, so that they see the benefit to them?
Tomer: That’s a great question and I can only speak for my experience. Looking back 10 years, it was a very long and iterative process that we also learned from each version of our product. And just to shed light, our products used to have between an 18 month and 24 month product life cycle, mainly software, that’s what we did. And for today’s folks I guess it looks, “Oh my god, that’s like eternity!” right? 18 months. But that’s how things are in healthcare. So, the first versions and design of the product were really done by engineers and a clinician with some kind of engineering background. And it was more to me, the immediate needs, and expand our product offering quickly. And when I joined McKesson and specifically the cardiology group, the product management group really started to form and coagulate and slowly gain credibility within the organization. And eventually, we were taking the driver seat or the leadership position to drive the product design and decisions. So, I think, it starts with instilling to the team members with a sense of duty. Especially smaller teams, even engineers understand that they have a certain duty in product design, and the duty is mainly to represent and be the voice of the customer and immerse themselves in clinical workflow, shadowing the workflow as much as possible.
Also, what we did over the years is recruit graduates of biomedical engineering, which we believe is a winning combination. These graduates, and I myself, also, is a graduate of biomedical engineering, they understand the clinical role and can talk to a physician or nurse or any user and understand what they’re doing and what is patient safety all about, but our engineering background gives us the top talented candidates that with an analytic approach and desire to solve problems, ’cause at the end of the day, it’s solving problems through user experience, useability and product design. So, we take a workflow problem, deconstruct it into its bit by bit elements of the problem and then synthesize a solution. So, initially there was some pushback from engineering and as our product design matured and achieved success, this was reduced ’cause they gained confidence in the product management team to really drive it. So, I think to summarize, it’s be professional, show early results to build confidence within the cross functional team, and the rest will follow.
Anita: Have you ever had them sit in on user testing?
Tomer: Well, yes. What we always kept doing, and since we had a cycle of initial ideation, then design and of course testing, beta-testing and then final go live, we made sure that our engineers were involved in each of the steps of the process and also bringing them as much as we could over to customer sites. And mind you Israeli company’s based in Israel, it’s not that easy to disengage an engineer for a week or more, but they would tag along with the product management group to understand. Every time they came back, they made product design much better because they understood the problems that they’re solving and understood our work as product managers of what we mean by being the voice of a customer and trying to… So they did the extra effort to say, “Oh, no, no. We can’t do that.” There’s less pushback eventually.
Anita: Right, right. And I bet some of them came back and shared their experiences with their colleagues?
Tomer: Yeah, so it disseminates, and that’s part of the culture that we instill both at McKesson Israel working on the cardiology products and also we have it here now in my new kind of startup company that I’m working on with only three engineers, basically, so they have to kinda rely on the product and the expertise that we bring to bring it forward.
Anita: Right, right. Awesome. So, this is the question around, and I’m sure some of the folks in our audience come with a very mature product and some are coming at it with just like more nascent product, right? So, typically, a sort of startup attitude versus a mature attitude toward a product. Do you see a major difference between managing these types of products relative to product maturity? And can you share some examples that relate back to how UX fits into that?
Tomer: Yeah, definitely, there is a difference. First and foremost, and that’s something that everybody needs to accept. When working on a new product, you have more freedom and ability to bring your experience and accumulated knowledge on useability and realize it from day one, and actually build it from the ground up with all the knowledge and all the things that you wanna do and cool things that you wanna do. On an existing product, you’re sometimes limited in the scope of changes you can introduce between iterations and versions. And this is especially true in the healthcare environment where a lot of our end users, physicians, are used to existing concepts of UX design and find it hard to handle the change. Imagine, also, if you replace a previous vendor or previous company with its product, you need to minimize the delta because it becomes a change management process and directly affects day-to-day operations of the hospital which affect patient care delivered. Alright?
Now, our company was a late entrant into the market in regards to several of its products, and we had to adhere to pre-existing, I’ll call them useability concepts, so as to be able to replace an existing system that was designed maybe in the ’90s and hasn’t changed since then because of the limitations of technology and also concepts of useability. And physicians were used to these old systems and it was hard to introduce a huge change. So, what we did is we introduced little tweaks and minute changes that made their lives easier. Less clicks, less mouse movements, if they work on a keyboard and some of them are used to keyboard shortcuts or just typing in and bring in things that they’re familiar with from the outside, it’s kind of more advanced world of web technology. That said, and to give the flipside of the coin, when we worked on a mobile application several years ago, which was an extension basically of an existing PC desktop based module, we had much more creative to do so, especially since the target users were already accustomed to UX aspects inherent in mobile, from their tablets and their iPhones or smartphones.
Tomer: Like swipe, pinch zoom, lot of automation and anticipation of the workflow, auto complete of sentences from a predefined list etcetera, etcetera. That’s the freedom that we had and I think we made the right balances between those two and that’s what I’m also trying now to carry over to the development of our next version of the product that we use today at Orpheus Medical.
Anita: Right. Oh, impressive. Awesome. Okay. Just a question as far as user research. It sounds like you mean a lot on your experience, having sort of watched product in the field. Do you still feel like you need to insert user research, ongoing, just to make sure that we’re keeping a pulse on the reality?
Tomer: Oh, yeah. You constantly have to do that, really, because at the end of the day we still need to get that clinical vote. The end user that uses the system day-to-day, they have to be involved every step of the way. And what we do is and keep in mind that our users are almost always very busy, right? Physicians, technicians, technologists, nurses. They’re seeing patients, performing diagnosis for medical interventions as well as administrative tasks. So they have a busy schedule much more than ours. And for some of them, actually, time is really money. If you asked a physician that needs to perform a diagnostic cath procedure, if he does one less he gets less money at the end of the day. So, it’s hard to get them to sit down with you face to face or over even conference calls or WebEx to provide feedback on existing product or exchange ideas on some of the changes that you want to introduce. So, to overcome this, we aim to interact as much face to face as possible in their working environment because you’re there, right? They appreciate, also, the fact that you came over to their little neck of the woods. And sometimes it could be really in the middle of nowhere or three flights away from the Israel office or even some places in the States and see your products or some of their products in use and hear their voice and their desires.
I’ll give you an example, a story, that occurred many, many times with our folks is, a product analyst or a product designer in our team met with this physician and she told her, my employee, that she was very busy, she had to see patients, really running around, phones, beepers whatever, and could only spare five minutes. So, the session started, going over prototypes or the actual product and enticing some feedback. And the session itself lasted for 90 minutes with excellent feedback. So, I think, there’s also a saying that… And there’s an acronym, nothing interesting happens in the office. It’s NIHITO, it’s called in product design. Nothing interesting happens in the office. Just go out there and meet the customer. Meet the user as much as possible. Other venues of course include trade shows, focus customer groups. And another important resource is our internal folks that sometimes, also, come from a clinical background. These are our sales teams that provide a lot of feedback because they’re day in day out with customers facing sales demos and periodic encounters and hear a lot of complaints or ideas. And also, our support groups and services that handle support calls or implement the product, always keep them in the loop ’cause they give you… ‘Cause to some extent they’re also consumers of the product ’cause they need to implement it quickly and properly and teach or train the users on our products.
Anita: Right. I have a question around, as a product manager you’re often hearing from the CEO, “Oh, Tomer, have you thought of this? We really need this to go to market.” And then the sales people have their point of view, as well, and so how do you manage all the different stakeholders and their requirements?
Tomer: That’s like the Rosetta Stone, how do you figure that out? Because what you just asked, it involves a lot of politics, internal organizational politics, which are natural. Whether it’s a 20-employee or a five-people startup or 1000 or 1200 group which I belong to in McKesson, everybody wants to kind of influence. So, what we adopted over the years is we brought a lot of our knowledge, the project management group was the driver of the ideas and the strategy, but, also, brought to the table sales, services, support organizations and others into the mix. And this is what we call like a gate review or depending on the phase of each project and almost like a bidding process. So, you would have $100, right? And here are five or six big ideas or next major tracks of ideas of product enhancement. How much of the $100 would you put on number one, number two, number three? And we try to kind of let everybody, every stakeholder in that sense, say, “Why?” and of course have a vote. Now, what also we would do, is hold these different groups accountable behind their decision or their vote.
For example, sales would say, “Oh, you need to do this and this and that.” So, we would come back and say, “Okay, can you commit now to an additional $1 million or whatever, booking or revenue if we did that?” Right? Or services would say, “Hey, you need to this and this and that and automatically.” So we’d say, “Okay, you know that… ” It comes at prioritizing, right? Deciding what not to do. And we’d come back and say, “Okay, so if you get this… ”
So, with services we would say, “Hey, if we give you this automation process or that automation process will it improve our margins or make your lives easier? You would be able to generate more revenue with the amount of people that we have?” So, that’s the balancing that we would do and there would be, of course, discussions or disagreements, but eventually, once it’s agreed, everybody’s behind the major initiative for the next version, and everybody is committed, then we would check ourselves if we met our business goals.
Anita: Right. That’s a great idea. That’s a really great idea. Have you ever been able to come back and say, “You know what? We prioritize these requirements and we put them into the product, but we’re actually seeing that users [A] struggle with it or aren’t interested in it.” Does that ever happen, and how do you deal with that?
Tomer: Oh, yeah. Oh, yeah, it happens. And eventually, what we started to do, and I have also been a great pusher of that, is learned validation and uses of analytics. So we’d add specific items in the code to actually record what kind of features the customers are actually using or not, so it will also be data-driven as much as possible. And we’ve developed certain features that every once in a while, we kind of do a little check and see whether they’ve been used or not. And we’ve found ourselves sometimes developing stuff, and I’ve designed stuff just because I wanted to imitate one of my competitors, but at the end of the day, because I didn’t understand enough back then, during the design, the actual problem that we’re saving, we found out that nobody was using it, right?
One example is a right click. Now, for us users of Word and Windows or anything, everybody’s computer-savvy and it’s great, “Oh, you’ve got this right click, right… ” Microsoft introduced that years ago, and we’ve seen that a lot of applications also introduced the right click options. What we found, though, especially in healthcare, since you have very short time span, attention span of the physician or clinician to actually learn how to operate the product, you don’t have time to explain all the cool stuff that you can do with right click. At the end of the day, nobody right-clicks in healthcare. And that’s something that now I’m bringing back into the design of our new generation of products is to eliminate right click. It also, I think, brings the whole concepts of mobile, right? Nobody thinks about right click in mobile. Just whatever that is you believe the most common feature or the feature that will be used most, just expose it. That’s it. And make a light and intuitive icon and a tool to them, that’s it. Zero training learning curve. That’s one area where we flopped, basically.
Anita: Interesting. Ah, that’s good. I like when people share stories of “This is where we didn’t do so well and this is what we learned”, ’cause I think it humanizes the reality of product management, for sure.
Anita: Can you show us a couple of examples, I think maybe some of our audience might like to see how you’ve evolved potentially a clunky product to a sort of slightly more user-friendly example?
Tomer: Sure. So, let me know if I’m sharing the, or I’d like to share my desktop.
Anita: Okay. Okay, we’re just getting that going.
Tomer: Oh, there we go. So, I’m gonna do a little, a few minutes just to show you the current design of the product and some wire frames or really basic design ideas of how we now clean and remove clutter. So, what I’m gonna show you has nothing, of course, to do with whoever designed it. They did a great job and this product is being used by dozens of physicians everyday today. Can you see it properly Anita?
Anita: Yeah, that’s great.
Tomer: Okay. ‘Cause I wanna eliminate the whole video thing just to kind of clear things up here. Okay. So, our product’s, like I said earlier, Orpheus Medical designs products for clinical video and visible light documentation and management. And what you see here, maybe, let’s start with the login page. This is a.NET application that we’re in the process of now replacing to be fully web HTML product, browser-based product. So, when you double-click and you have the login, it shows the icon and requests password. But a lot of stuff here at the bottom that come to your, it’s like the noise fatigue, you don’t really read or don’t really need any more, right? So, our idea is to clear up the login and make it more kind of modern and exciting. And this is how it will look now. You see a nice bright picture open on a Chrome application with my login, credentials, I can create accounts. Everything I have to do will be exposed and clean, minimal time spent. Once I log in to this, “clunky application”, the first thing that you do is you search for patients or procedures and you need to review the images or videos and perform actions on those videos. Edit the video, take additional snapshots, complete a report, stuff that our clinicians are doing. And what you see here is a lot of mouse movement.
I wanna search for a patient. I need to type in. And you can see that my eyes will shift down to look at the results. I actually need to move the mouse almost halfway down screen just to click on the search button.
Anita: Right. There’s a search button.
Tomer: Right? And then the results are here. Yeah, that’s the search button so far away. The results, all these columns, some of them are crunched. I need to expand, then change. Maybe some of the information is irrelevant, actually. And the viewer of the video is on the top right, so a lot of movements of the eyes and maybe strain on the neck. So, the idea is to bring everything into on-screen. Here, I click, actually, when I click, here’s the search. I can click on this as advanced search. Just enter a patient ID or a name or whatever, it will bring it up. And all the relevant information like age, gender, ID, department is immediately available with much more real estate. And if I wanna look at pictures or videos, it’s a cleaner design. It’s a different kind of state of mind. Mouse over, hover over will expose the relevant action tools that are needed. No more right clicking. I can do annotations. I can look at movies. Really leveraging the capabilities of the technology available today with bootstrap design and nice animations that’s blending everything onscreen and anticipate. Since our system, for example, provides live broadcasting capabilities that you can actually launch and go into an OR and look at what is happening, we brought all that information into one application instead of two or three today. So, it’s part of cleaning up the design that we’re doing right now.
Anita: Right. Is this mobile friendly?
Tomer: So, this application itself will be designed to have this built in logic. It’s browser-based, so it’s cross-platform. It can be, theoretically, opened on a tablet, an iPad and whatnot or an iPhone. But, the idea is that if you have enough real estate, enough screen resolution, then, yes, you would be able to go into a responsive website and do everything that you need to do. But, if you’re on your iPhone or tablet that doesn’t have enough resolution, we’ll urge you or push you into our mobile application which is a different application, Android versus iOS, but it will have similar tools and capabilities. And that’s also one thing that we’ve learned from my previous work when we examined the option of building a mobile application is that don’t go hybrid. Don’t go, “Okay, let’s do a frame that is a browser and embed stuff or maybe a frame that is a native application but embed webpages.” The user experience is adversely affected and it’s not worth it. Invest in designing something good that makes best use of iOS even at the expense of the overhead of keeping up with iOS seven, nine whatever. And the same with Android.
Anita: Okay, cool. Just a question as far as… There’s a question from the audience on how do you reconcile the significant overlap in responsibilities between product management and user experience design?
Tomer: That’s a great question. I think from my experience, in the way we structured our product management group, actually, we were also responsible for useability and user experience. So we weren’t in this ivory tower only thinking about customer and marketing and sales projections and numbers. The folks in my team worked closely with the engineers and had hands on experience or hands on effect on the useability itself. So, we wouldn’t… It would start with useability or useability would have a clear voice in that sense. And if it didn’t make sense from a useability standpoint, we wouldn’t go ahead and develop it. We would be the pushback to the engineers saying, “Listen, this doesn’t meet certain standards of useability. Don’t bring it to the table” or “Go back to the engineering drawing board and rethink design of the architecture to bring it forward.” So, I don’t remember a lot of conflicts in that sense. ‘Cause we would be the drivers of everything and owners are accountable for a good product. Does that make sense? So, it was rolled up into one team.
Anita: Yeah, that’s a good point. That’s a good point, exactly. Okay. Just a question around designing for competitive advantage. How do you approach that?
Tomer: Well, yeah, competitive advantage is, in the classic sense, at least from the healthcare side of things, is that we were able to add small features maybe that were technically possible but weren’t available previously because of the technology and we may use that as a competitive edge. Sometimes you would also “a me too” kind of approach in order just to say, “Yes”, and check box during a selection process and not lose that edge. I’ll give you an example. In the early 2000s, everybody was using predefined sentences or libraries of clinical sentences in findings and recommendations and can configure that per site or per user, right? But, the user interface for that was really a separate dialogue box that took a lot of real estate and had a hierarchical structure to organize it probably limited because of technology.
Tomer: So in 2007, when we started to design a competitive module, we assumed that everybody by then would be familiar with Google’s auto complete mechanism. When you type in a word there is for searches and it kind of completes based on your previous searches or whatever the profile big brother they have on you. So we incorporated that and users loved it because it saved them a lot of mouse clicks and brought online, or on screen, the relevant sentences that they were looking for and they didn’t have to have print outs of codes stapled on their wall or something to kinda remind them the different codes or shortcuts that they would use. They would just say, “normal ECG” start typing “normal” and it would be brought up like that. And, I think, that feature might not be the deal breaker when you come and sell your product, but it helps to get the physician’s buy in as well, and position the product or approach as user-focused, right? Especially when you talked about future and roadmap, and that creates that competitive edge, I think.
So, like I said, we also learned from a lot of mistakes in early designs like the right click thing that caused a lot of frustration to our people that trained the users and users. And sometimes they’d position that against us if we had a bad design, and like I said, it’s an iterative process to always improve that.
Anita: Right, right, right. Okay, great. Okay, just we’re gonna start wrapping up here. I think we’ve gone over time a little bit. One other question that’s come in is how often or valuable do you find personas or journey maps to help you keep the team focused on taking away subjectivity for example, and ensuring that everyone’s focused on what they need to, and what the user needs?
Tomer: Right. I think what I would take from this question and kinda raise it to a different level to discuss about some of the prototyping and the changes that we did at McKesson and we’re also implementing or using it here in our new startup, is the agile methodology. And, I think, we were one of the first to bring agile methodology to product development that also talks about user stories or personas and fast prototyping into how you design and develop health care oriented products. And in many web-based or mobile industries, that’s probably the norm, but in healthcare it’s really not like that. You could speed up product development and releases of versions but customers may not be able to actually accept those changes. But, it really helped us, also, to stay focused and define the minimally viable product, we adopted that kind of approach or term and interpret it properly and really avoid wasteful energy, let’s call them, on a lot of designs that we don’t know whether they’re applicable or not.
So, what we did, an example of that, is we thought of designing some cool graphics that shows a trend of a certain measurements. You know how you go on Bloomberg or Yahoo Finance and you can see this little chart graph of the stock exchange rate, the stock rate kinda change over time, right? So, we had this wacky or very big design of a lot of sub features in a clinical space. Instead, what I decided to do is say to our products and to our engineers saying, “Let’s start with one thing. Fail fast and adapt”, kind of thing, right? Focused on one user, one use case, one story, one clinical usage just to see the chart, and see if it gets traction. And build also those analytics, those in-app analytics to see whether they spend time and actually gain value from this before we go ahead and implement a lot of other user stories for other personas or the same persona and waste months and months of work for something that may actually fail from day one.
Anita: It’s a very good point, that’s good to hear that, actually. Yep, keep it focused, right?
Tomer: Yes. Minimal viable product, MVP.
Anita: Yes, yep, you’re right. MVP, exactly. Okay, we’ve gone over. Thank you so much Tomer for your time. I really, really appreciate some of the insights. I know they really sort of hit some of the pain points that product managers around the world struggle with, especially as they’re sort of coming into product management and/or changing up into… From a McKesson, for example, like you did to a smaller company like Orpheus for example. So, thank you very, very much for your insights. Also, shout out to Louise McCulloch, our marketing coordinator who’s been working furiously in the background to make sure all this came together seamlessly. And thanks to the fantastic audience, we’ve loved all the questions that you’ve sent us. We’ll be sure you follow up with the answers. And of course, the continued curiosity from our community on all things user experience. Thanks again Tomer, hope you have an excellent… What time is it over there right now? It’s like…
Tomer: It’s 05:36 in the afternoon, or evening.
Anita: So your day is done. [chuckle]
Tomer: Yeah, it’s just started actually. I’m going back home and now starts the real fun.
Anita: Right, right, fair enough. Alright Tomer, thanks again and we’ll chat…
Tomer: It’s my pleasure.