Back to Blog

Product Hero: Barbara Dumery, SVP of Product Management at Imprivata

Author

Barbara Dumery Head Shot

Product Hero is our bi-weekly series that highlights 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 Barbara Dumery, Sr. Vice President of Product Management at Imprivata.

Barbara and I met as product managers at Nuance Communications. Since then, she has gone on to lead product teams at several healthcare technology companies including Verisk Health (now Verscend) and Imprivata. She and I talked about how her engineering background contributed to her problem solving skills and has helped her as a woman in technology. We also talked about the importance of staying focused on your customer’s problems above all else. The closer you and your engineering teams are to the customer’s problem, the more innovation you’ll have.

One really cool thing about Barbara (perhaps only to me 😉 is that she’s from Bruges, Belgium, and is a direct descendant of Joris Dumery, who cast the bells (the Dumery carillon of Bruges) that still chime in the Belfry of Bruges. Twenty six of those bells are among the 47 still in use today. I know this because I visited Bruges and The Belfry this summer. Having this (extremely) lose connection to the bells via Barbara added a little extra intrigue to my visit. And if you haven’t visited Bruges, I highly recommend it!

OK, enough history geek from me. I hope you enjoy the podcast. I know I really enjoyed catching up with Barbara!

Listen to the Show:

Show notes:

Podcast Transcript:

Heath: Can you tap your mic? Okay. Cool. Alright, so Barbara, welcome to the dirt.

Barbara: Thank you.

Heath: You and I go back a fair while. We were together at Nuance a couple years ago. That would have been in, gosh, around …

Barbara: 2001, 2002 maybe? Or no, 2006.

Heath: I think it’s more like 2006.

Barbara: Yeah, right.

Heath: Right. You were there for how long now?

Barbara: Seven years.

Heath: Seven years. That was a short time, I was there for just around a year. I left right about the time we acquired eScription. Anyway. Interesting.

Barbara: It was a great ride.

Heath: A little bit on your background. Can you describe to me your path to product management? I notice you’ve got engineering background. What got you into product management?

Barbara: Sure. I had decided in school to study engineering, and it was always because I was really interested in how things worked and really sort of getting into that nitty gritty. But I wouldn’t call myself a 100%, full-time engineer all the time. I didn’t go home at the end of the day and take apart computers. I was always more interested in understanding why people were using technology and not just technology for technology’s sake.

When I got out of grad school, I really was interested in biomedical engineering and trying to use the technology to benefit people in some way, so I went to go work at a medical device company, and I did product development there. I did coding, but pretty quickly started to move into how people were actually using the technology. This was actually a Finnish company from Finland, and they needed folks in the US to help translate what the physicians and the clinicians really needed in their medical patient monitors, so that’s what I started to focus on. I did a lot of usability testing. From there, it was really starting to ask more and more questions about not only how people were using the technology but more about why and the bigger business problem.

And that’s when I really first learned about product management. It’s not a very common thing, at least back in the day, that they really talked about as sort of a field of study or an occupation, but then I really became familiar with it, and I had a couple of great mentors that I worked with. And the rest is history.

Heath: It’s interesting because I’ve asked this question of many people in the podcast before, and you’re right, there is no product management track in college, for example. The one theme that we seem to find that’s woven throughout is an inherent interest in the end user and their experience. Whether you’ve got a hardcore coding background or even a marketing background, or in my case, it was a client support background, what led me to product management originally was asking those questions. I was completely fine with training and supporting our end users. We didn’t have product management. It was just a company that was a precursor to WebMD. But I was the one that seemed to be the most interested in being kind of the internal pain in the butt, asking the questions like, Well, why do we do it that way? Do we know if that’s the right way? And I keep getting asked, Can we do it this way? Why don’t we do it that way? Finally, someone said, Look, if I make you the product manager, will you go away and leave me alone?

Curious if you think that the engineering background was an advantage for you. Or do you think it really doesn’t matter? It’s really just that you’re inquisitive and ask the questions?

Barbara: Yeah. I think there’s two places where it has helped me. One is just problem solving skills, being able to think about things in a linear way and being able to break a problem down in a very logical, not really unemotional, but a very logical, linear, analytical way. I think those skills are really, really helpful. I’ll say in the second way is being a woman in technology, having the engineering background has given me some credibility. It’s pretty often, maybe not so much at my level now, but growing up in my career, that I would get the sense that people were questioning my abilities. Being able to say that I had that engineering background or being able to speak with confidence on that technical aspect was really helpful.

Heath: My wife would be nodding her head right now.

Barbara: Right.

Heath: She was not mechanical, though I think she started out in mechanical… Yours is mechanical, is that right?

Barbara: Electrical.

Heath: Electrical. I can’t remember if she started electrical or mechanical. Anyway, she switched to systems engineering. But I’ve heard her say as much as well that it’s helped her. She’s not … She was a consultant right out of college in healthcare technology, but I think she would agree that it’s helped as a product manager but also as a woman product manager.

Barbara: Yeah. I’ve had a room full of people, and I may be one of two or one woman in the room, and somebody will be talking about something very technical, and then they’ll turn to me and say, Oh, I’m sorry if this is too technical for you.

Heath: Today?!

Barbara: Yeah. A couple months ago, we had a consultant come in and turn around and say that. And I would say, No, it’s good. I got a double-E degree. I’m good.

Heath: I’ll let you know if I need you to slow down or back up. Oh boy.

Barbara: Maybe you need to explain it to that person more, but …

Heath: Jeez. Well, I’ll get into what Imprivata does. But in the meantime, what are some products that aren’t Imprivata’s that you admire? And they could be products you’ve worked on in the past or have nothing to do with your line of work. But what are some products that you use and/or admire today?

Barbara: Yeah. I love this question that you ask, and I gave it some thought, too.

I’m not a big sort of technology just for technology’s sake person, so I’m not going to talk about the iPhone and all that kind of stuff. I use those, and I think they’re really cool, and they’ve been really helpful. But I think the companies that have really had an impact, especially on healthcare, I think are really interesting.

One is Epic. It’s just the way that they approach the market with really being one of the first vendors that brought together the inpatient and outpatient worlds. I wouldn’t say that they’re the best UI, but on a whole, they really do provide that best experience. And I really admire the way that they went to market with that confidence to say … It’s almost that they were picking customers versus customers selecting them. They were always very focused on their mission. If you’ve ever been to Epic, they have their principles up everywhere on the wall, and it’s just that focus. The way that they’ve been successful I think is really admirable.

Another company that I’ve admired a little bit from afar but is a local company, Patients Like Me. I’ve just been really impressed with the way that they’ve been able to give a voice to patients, especially patients that are suffering from these chronic conditions. And some of them might be somewhat rare, but they’ve been able to pool their resources and get a lot more insight into how to manage their condition. I think they’re still sort of in the flux of figuring out how to monetize that, but I think it’s been really admirable.

Then the only other technology where I do really get excited in MRI machines. I did a digital imaging class in grad school, and just the way that that works, I always find it so fascinating. It’s actually lining up the dipoles within our body and how quickly they go back to resting position then sort of says how dense that material is. It’s just fascinating to me that something like that can work and that we can actually get useful information from it.

Heath: You must’ve had a blast at RSNA, then.

Barbara: Yeah, exactly. And I went for many years, fortunately.

Heath: Always the first weekend after Thanksgiving.

Barbara: Exactly. Yep.

Heath: Or Thanksgiving weekend.

Barbara: Yeah. Exactly.

Heath: What would you say are some of the most difficult parts about product management or being a product manager? I know that’s tough to distill down into one or two because there certainly are many challenges today. But any that jump out?

Barbara: Yeah. I think it’s really not being focused enough on the customer problem. I think what you said in the beginning about having empathy about the user and the customer. I think where I see product management starting to fail is when we veer off of that focus. It’s often because there’s an overwriting business goal that we may have that takes us off that focus. Typically, it’s some internal thing where, Oh, we have to have these two products work together. Once, I don’t know if you remember, we had these two products that had to work together. Regardless of whether or not it actually made sense, we wanted to be able to sell them together. We just had to have bytes of information and bits going between these two products. It was sort of an artificial goal that we had, so that’s really where I start to see it fail, is when you really take your eye off the customer problem that you’re solving and being very aware about how important that problem is to the customer to solve and what alternatives they may have.

Heath: You know, I used to think it was mainly a problem with larger companies. It’s easy to say, Oh, they’re getting too far away from their customer, and yet I spent more time in smaller companies because that’s sort of my comfort zone, and my interest lies there. And that may be true that larger companies have to constantly remind themselves to stay closer to the customer, but it’s also one of the quickest ways startups fail. Right? They’re trying to get that next round of funding or trying to create something … It’s a product in search of a problem instead of saying, Hey, look, we got started on this great idea because we saw that there was a pain somewhere that we could meet. Let’s stay focused on that. That could definitely be one of the biggest challenges, whether you’re in a small or a larger company. The further you get away from that, the further you’re getting away from success, no doubt about it.

Is there a mistake that jumps out at either you, your team, or your company in the product management area may have made that you’ve learned from?

Barbara: Yeah. I think the two big ones is certainly one where we weren’t focused on the right customer problem or even a customer problem. It was more that internal driver and that we really veered from a direction. The second is when we were more focused on the technology platform. There are a lot of cases where it’s, Oh, we’re going to do this whole big rebuild, and we’re going to do it in this really great way. And it’s going to be so much better the second time around. And, even when you’re using agile or iterative development processes, just becomes this really big, daunting project that … I’ve had this happen three times already. You never get to the end result. It’s way too big, and it’s just not even really about it being too ambitious, but you lose focus along the way of why you’re doing it and how you’re doing it. It’s much better, I’ve always seen, of either just refactoring pieces of it or saying, We’re going to set our current product aside and go solve this new problem, but not try to rebuild the platform or refactor it to have that be the way that we solve the problem.

Heath: I’ll ask it now since you brought it up. What do you guys here at Imprivata … What is your buzzword method that you follow? Is it waterfall? Is it agile? Is it scrum? Is it scrumfall or whatever?

Barbara: Yeah, right. It’s agile. Now, I’ll say that we’re not 100% agile yet. We’ve made a lot of really good progress.

Heath: You’re moving toward that from a history …?

Barbara: Well, we’re already doing agile today. We’ve got scrum teams and product owners and all that good stuff. But our agile processes could really be tuned up more to really get that efficiency. Part of it is the challenge that we have of being an enterprise software company, mostly being on-prem. The way that we’ve been delivering software, it’s a pretty long lead cycle with it and a lot of regression testing that we do. We want to move more to the cloud, and we already have a number of products in the cloud. We’re going to have more hybrid solutions, but it’s not only that technology that’s going to enable that, but it’s also the way that we QA and get more continuous releases out. That’s going to help free us up and really be able to think more quickly about what the customer wants versus … We still have some artificial things in our process.

Heath: Yeah, it’s interesting. I say buzzword because … It’s less the case now, I think, than it used to be, but people tended to focus on what you called it rather than what you did, and at the end of the day, no matter what you call it or what you do, it’s whichever method keeps you – going back to it – whichever method keeps you closest to the customer and the most agile at getting your code out there in front of your customers, even if it’s to prototype a test or validate or actually to deliver news and live production systems.

Barbara: Right. Another big thing that we do really alongside agile is a lot of lean processes, so we’re big believers in doing a lot of product discovery. I have one of the quotes up on my wall that says you can’t have an idea sit within the company for more than two weeks because you’ll fall in love with it, basically. You got to get it out and talk to customers about that idea and really validate it. It’s that validated learning. That discovery is really important, and there’s a lot of different ways to do that, even with the beat of B-company enterprise software.

Heath: How do you guys get out in front of customers and validate? Do you make use of wireframes, prototypes, that sort of thing? Or …?

Barbara: Yeah, there’s a number of different ways. Certainly, we have initially a lot of voice of the customer discussions to really understand the challenges that they’re facing. I think it’s critically important. Then we do a lot of prototyping. We have a great product design department. Sometimes they’ll just do these InVision mock-ups that are really great and get it out in front of customers and really iterate. Then, certainly do usability testing and such.

Heath: That’s something that I didn’t really appreciate for many years in product was the value … And it seemed like not long ago, at least none of the companies that I was in, made heavy or heavy enough use of prototyping and testing. To be fair, it could be because the prototyping tools were not … You couldn’t just grab Balsamiq or something and mock up a wireframe. You almost had to do some barebones level of coding to get it out there. But gosh, I think back. If I’d had a way to stick something in front of ten users that was a blip on the engineering’s time, or even better, that they never touched it, I’d rather not give them a single thing that hasn’t unless it’s been validated, it would’ve saved an enormous amount of back-and-forth. And you add to that the complexity of the fact that most shops were sort of waterfall, so by the time you validated something that’d been coded, you’d already written the spec. It’d had gone through various versions of review and approval, and you were down the tracks too far to sort of pull back and say, Well, no. We got to do this. It’s now about the tech and not about what the user wants. You’ve got to make it work. You got to sell it.

Barbara: That’s right.

Heath: You got to sell this.

Barbara: I have this view that might be kind of heresy in a way, but what you’re describing of really making sure that the engineers can work on the product and really push it out, and then we got to meet deadlines and that momentum that you have. Part of that is also there can’t be a millisecond when an engineer is idle. That’s just heresy, right? You can never have that. And absolutely, on the general, I agree. We have to always make sure that our people are as effective and efficient as possible. But what you sometimes have with that is a sort of feeding the beast problem. You have to constantly feed that and make sure they have stuff to work on. Well, I think it’s more important to sort of sit back and say, What are the right things for them to work on? Even if an engineer sits there idle, there’s always enough stuff for them to work on anyway. Go do some tech debt or go do QA automation or go fix some defect, right? But really thinking about the right things to solve and testing for that.

Heath: Or go off for a week and try to figure out where our product to be totally different. Just sit in a room, literally or figuratively, and come up with something – crazy idea – about how we can make something better. Right?

Barbara: Yeah.

Heath: Because they’re going to be certainly one of your more creative types from a technical perspective.

Barbara: Yeah. And the closer they are to the customer problem, the more innovation that you’ll have.

Heath: So, Imprivata. What does Imprivata do?

Barbara: Yeah. We help manage clinician identities and patient identities, really to return an ROY to the hospital. On the clinician side, it’s about enabling access easily and being able to assist with all these workflows where today, a clinician has to prove their identity.

The basic example is, today, without our product, when a clinician needs to work in their daily work, they typically have to log into their EMR about 30 to 40 times a day, sometimes even more. Every time, they got to walk up to the workstation, put in their username and password, and that’s for security reasons. Right? You got to make sure you maintain the PHI and access to that. Instead, with our product, they just do a badge tap at that workstation. They can immediately log in. The first time, they can use two factors of authentication, and then they get access to everything they need. And it goes beyond that. That desktop can follow them wherever they go. We work very closely with virtual desktop infrastructure vendors to make it really a seamless experience.

Then we’ve done a number of workflows where, in an exam room, for example, a nurse can start on a screen and take the vital signs when they first meet with the patient. They tap out, then the physician taps in, and they start at that same screen, but they’re the ones logged in. We do a number of different workflows where we work very closely with the EMR vendors. It’s wherever identity helps with the workflow, which is a lot of different places.

On the patient side, it’s really ensuring that you’ve identified the right patient when they enter that healthcare organization. We have this perfect example of one of our hospitals. They have about 20,000 Maria Garcias in their database. It’s a Texas-based hospital. It’s a very common name. Even on the same date of birth, you can have over 230, just by the math of it, of Maria Garcias on the same date of birth. You’re the registrar, and I’m the patient walking up. What are you going to do, right? You’re going to ask me some information, maybe some additional address, other information, and try to find the right one. But you may not-

Heath: Some of these Mary Garcias don’t have addresses they’re willing or able to give you.

Barbara: That’s right. Yeah, it can be a very transient population. So what do you do? You end up creating the 2001 record, and now you have no medical history, which isn’t great for reimbursement and just for the patient’s safety or care. Or, what can happen as well is that you pick the wrong one, and now you’ve got this overlay situation where you have two patients referencing the same medical record.

What our solution does instead is it helps you enroll the biometric, the palm vein biometric of that patient, and associate that with the right medical records. Every subsequent visit that the patient comes in, they get associated with the right medical record. It’s for patient safety and for revenue cycle management. It’s-

Heath: So at intake, the patient basically swipes in, so to speak. Let’s say I’m here for my 3:00 appointment, and-

Barbara: They put their palm down …

Heath: This is who I am. Okay.

Barbara: Yeah.

Heath: Interesting. To me, I don’t know of any other users that are sort of more put-upon or disenfranchised than pretty much any other industry. Why do you think that is in healthcare? You mentioned the signing in 30 times a day. That’s a very good example, frankly, of reasons why physicians have … We used to say at one of my previous companies physicians are not technology Luddites, or they’re not technology-agnostic. One need only look at radiology to see quite the opposite. They’re technology advocates. What they’re resistant to is technology that doesn’t help them in any way or their patients. So why is it, do you think, that it’s been that way for so long in healthcare?

Barbara: Yeah. I mean, we could talk very broadly about sort of the misaligned incentives in healthcare and reimbursement. But more specifically, when you think about clinicians, this is different than financial data. If your credit card gets compromised or stolen, your identity gets stolen, the bank will just make you hold. They’ll put the money back in your account, and you’re fine. Right? For medical information, once the information gets out there … Let’s say you have some condition that you really don’t want other people to know about. It may impact your hiring ability or whatever it may be – really, really sensitive information, mental health or whatever. It’s so important that that information be really protected.

What’s happening now is that, from a cyber security standpoint, there’s a lot of operatives that understand the value of that. It used to just be, Oh, I can get $200, sort of street value, for a medical record, because it can be used for medical insurance fraud. Now, it’s really more from a ransomware. I can lock down a hospital and hold them ransom and lock down all of their medical records – huge, huge impact. So they’re really starting to understand that.

At the same time, two clinicians have constantly needed to do so much documentation just for billing purposes. Right? If they don’t document, then it didn’t happen, and you can’t get reimbursed for it. But at the end of the day, the clinician just wants to take care of patients, right? They want to take care of patients. They have all these barriers in place from a security regulatory standpoint, all these very high bars of requirements for core measures and documentation that they need to do, and all they want to do is take care of patients. That’s the challenge that we have.

Heath: What keeps you up at night in Imprivata? What’s your biggest challenge right now? Or, positive spin, what is it you’re working on that you’re excited about now?

Barbara: There’s a lot that we’re working on that I’m really excited about. What we see happening in healthcare is that there’s a big shift in moving to the cloud and moving to mobile applications. Clinicians are on the go. They need to be able to do their work from wherever they are. And care is becoming more distributed, so understanding how a patient moves between healthcare and delivery organizations, it’s really this distribution that’s happening and the kinds of technologies that are needed. How can you identify somebody regardless of where they are? Making sure that they can easily access the information that they need on any sort of device and endpoint and that you’re talking all about the same patient, as you have all these different people accessing medical record.

What’s also exciting is really thinking about new data entry points. We’ve seen a big shift in the conversation with medical devices. It used to be that those were really managed by biomedical engineering, totally separate than the IT department. Now that people are really understanding the security threat that could come in through a medical device, there’s really much more focus about all of these medical devices across healthcare. And that’s really then shift to the conversation to think about medical IOT. As you look about not just the medical devices within the hospital, but for telehealth and telemonitoring, as well as wearable devices, there’s all this data that we’re collecting. How do you, again, make sure that it’s all about the same patient and that it’s the right clinician accessing that information? It’s sort of the small world within the hospital getting much bigger.

Heath: Product design, marketing, sales, engineering. How do you guys communicate? What tools, if any, do you use to help align yourselves, communicate, be efficient, that sort of thing.

Barbara: Sure. Well, first and foremost, we’re a big believer in really face-to-face conversations.

Heath: What’s that like?

Barbara: Yeah, exactly. Hello? We’re not tweeting?

And that’s really kind of the agile lean model, as well. As much of that can just be done verbally, communicating-

Heath: Are you guys mainly here? Where else are you located?

Barbara: We’re mostly in this office here in Lexington. We also have an office in the UK and in Australia, but the majority of our folks are here. We certainly have a lot of people that do work remotely, not so much in the product delivery part of the organization, but we have implementation in sales and services done from folks who live remotely. It’s a lot of collaborative discussions that we have. We have a number of different mechanisms or processes that really make it easier for people to give input and feedback. For sales, for example, if there’s a particular feature that they need that’s really deal-dependent, there’s a process by which they can put that in. We have a regular review there, really making sure that they’re not blocked in any way.

Customers as well have a way to put in enhancement requests. We use Salesforce a lot, and there’s an ideas portal where customers can put in an idea and then vote on it. And really, the ones that rise to the top, we look at very regularly and take into consideration. Then there’s nothing like having those primary conversations with customers. We always try to do it around an objective of what we’re trying to achieve. We’ve just started really using OKRs, objective and key results, pretty regularly, and been really helpful. It’s really an OKR for the product team, which is that collection of UX, product management and development, and QA together, and that they have a very clear goal then of, We’re going to try to improve deployment and adoption of a particular product. What are the different ways that we can go and do that? And they’ll have conversations around that.

I love the way that the OKRs push critical thinking. It isn’t so much about, Great, we now have goals, look good, pat ourselves on the back, but it’s that critical thinking and especially on that outcomes and how you’re going to measure success, even just asking that question. Often, it goes back to, Wait, what are we trying to measure? And why are we trying to measure that over this other thing? Really, that discussion that happens in that team when they have that, I think it’s phenomenal.

Heath: We try to enforce that as part of our process with our clients, as well, where we try to say early on, How are you going to measure? Let’s just take a web redesign. What is the goal and the purpose of it? And how are you going to know when it’s been successful? Let’s not … We’ll get to the design after we get to the user experience and the research and the persona development, but also, let’s try to establish what are the key outcomes that we’re going to try to achieve so we’ll know whether or not it was a success.

What do you think is missing in the conversation among product leaders right now?

Barbara: Actually, I thought about this a little bit. I think how you can scale the business. There’s a lot of talk about lean and there’s a lot of talk about agile, but what’s often missing in both of those, and in product management, too, is how you can scale. I think some people have also tried scale-to-agile framework, but there’s limits to that, and I don’t think there’s been that much success. But really thinking about all of these things that you’re doing that you know you need to do really well. And the small-scale people I think have understood them and those lean practices, but how do you then have … We have a pretty big development team. How do you scale that? How do you continue that rich learning across team? How do you make sure that there’s alignment and still autonomy? The bigger you get, there is an urgency to have more of a top-down, command and control approach, where then you start to squash some of that innovation and some of that speed.

I don’t think that’s been totally figured out yet.

Heath: Someone says they want to become a product manager, getting the product. What advice would you have for them?

Barbara: Yeah. I’d say go for it because there’s such a shortage of product managers. If you have any interest, definitely go for it. I always look for folks that have sort of four main capabilities. One is that you do need to be thinking strategically, thinking long-term. There’s some people that struggle with that. They tend to think very tactically, so that’s a challenge. You need to really be able to listen, know how to talk to customers, really go in a very open mindset, very humble approach. I think that’s really critical, not going with your own assumptions. Sometimes, what I’ve seen with product managers, especially when they come out of another part of the organization, they’re like, Finally, I get to say what gets to be in the product. And you’re like, Yeah, maybe you’ll get a couple of little things in there that you finally wanted to get in, but you can’t go in with that kind of thinking. Or they’ve been a customer, and then they become a product manager. Really being able to listen and being humble with that.

Certainly being technically adept enough to have I think a really high level of respect for engineering and the complexity of what it takes to really deliver products, but also to know when to push back a little bit and say, You know, this doesn’t seem right, or it may have another approach, or, If we were to think about the problem in this way, could we help accelerate the way that we’re going to deliver that to customers? I think that’s really important. And then just some basic level of multitasking, staying organized, thinking very linearly, very clear thinker, clear communicator. There’s a lot of different stakeholders, especially on that strategic vision piece, that you need to sort of sell your idea on, so that’s really important.

The way that I like to think about it, too, is, when you look across the organization, it’s really product management that’s responsible for the future, and I’m not talking about some big architecture, sort of visionary future role. But day after day, they’re thinking about, Where do we go next with this product? And there’s not a lot of other people in the organization that are directly responsible for that. I like to think of that lens, so also help my product managers stay focused on the right thing. There’s a lot of other people that can help solve problems that we may have today, sort of organizationally, operationally, and we have really good people that do that. But it’s really thinking about, Where are we going with this product, and where does that lead us?

Heath: That was always the biggest challenge I encountered was to be able to lift my head off the proverbial desk and have an eye toward the market and toward the future and not be stuck in the maintenance mode of writing requirements, reviewing testing results, et cetera. It’s like, Hey, I need to think about do we even have a product next year, or is it going to be totally different? And that was the perpetual challenge.

Barbara: Yeah. And it doesn’t even need to be five years out. It can be little-

Heath: It can be two releases hence. Right?

Barbara: Exactly.

Heath: Books you read. Do you read for pleasure, business, both?

Barbara: I buy a lot of books that I would love to read.

Heath: Okay. They look good on the shelf, or …?

Barbara: Exactly. No, it’s not just to look at. I’m like, Oh, this book sounds so interesting. I want to read it. I don’t read enough just because I don’t have enough time.

Heath: I don’t. I don’t make enough time. That’s my issue.

Barbara: Exactly. But I do read for both. I’m in a book club, so then I do have to regularly read books outside of work. But then I’m constantly buying books because I do always want to learn. With any business book, I’ll read the first three chapters, and I’m like, Oh, this is great. I love this. I get what they’re saying. And then after the fourth, I’m like, Okay, I got what they’re saying. Yeah, there’s a couple on my shelf right now that I really wanted to get in a little bit more. One is the Lean Enterprise. I think it’s one of … It’s at home. But I just got that because it had a really scale/lean in the enterprise model, so I’m excited about that. Then another one that I really want to read, but I haven’t had a chance to crack it open, is Good Strategy, Bad Strategy because a lot of strategy ends up being, We got to grow 25%. And I’m like, Yeah, that’s not really a strategy.

Heath: No.

Barbara: And that’s another book that I want to read.

Heath: Cool. Well, thank you for your time.

Barbara: Thank you. This was a lot of fun.

Author Heath Umbach

Heath is an avid cyclist and runner who brings athletic rigor to everything he touches. With over 15 years of experience building and marketing digital products, he has a deep passion for solving our clients’ greatest challenges.

More posts from this author

How we work Process

Product Hero Talin Wadsworth