Today, I talk to Kelly Taylor, a Product Manager in the Federal Government. Kelly is a Product Manager at the United States Digital Service (USDS), founded by President Obama in August of 2014 to bring together the best technology, design, and government talent. USDS employees work with other agencies to help them better leverage technology.
Kelly began his "digital tour of duty" nearly a year ago working with the department of Health and Human Services on improving the Quality Payments Program, a provider reporting system that creates open data sets to improve care and efficiency. Over the past few months he has worked on Blue Button 2.0, a developer-friendly, standards-based API that enables Medicare beneficiaries to connect their claims data to the applications, services and research programs they trust.
Hi Kelly, Super excited to talk! First let me ask, how did you come into product management at USDS?
Absolutely. Well, I began my career as a software engineer. Throughout the various software engineering products I worked on, I, like many who do Product Management after software engineering, found myself doing a lot of feature design and being interested in why we’re doing what we do, in addition to how we’re implementing it. That lead me into roles like technical lead and I straddled engineering and other roles, which morphed into product management over time.
In the last ten years or so the career has been all over the place, I did a startup called PivotDesk which was an office-sharing marketplace and in that experience there was a lot of marketplace dynamics, no healthcare. After that I went over to AlchemyAPI. I had used the technology and was friends with the founder and ended up working on natural language processing and computer vision. Then, we were acquired by IBM.
I ended up working on the Watson team at IBM, where they have a huge healthcare group. I had built websites for hospitals and health systems before as well as physician lookups and other technology but didn’t consider myself as working in healthcare. I grew up in a healthcare family, though: my wife’s a Physician Assistant working in Pediatrics and my Dad’s a radiologist. But I had not worked hardcare healthcare and this was my first experience doing that.
Over the last few years at IBM, I worked a lot with healthcare companies and a lot with life sciences companies. And that’s where I began in the healthcare industry and learned what it’s like building technology in the healthcare industry.
How was that transition into healthcare? Was there any salient differences from other types of software development?
I actually wrote a post called The First 90 days for a Product Manager in Healthcare. It’s super interesting because, more than other things I’ve done, getting into healthcare like this takes a lot of work. I see it here at USDS because there’s a lot of folks who are great designers or engineers or product managers, but when they join HHS the learning curve is massive. But it really comes down to what you’re doing in healthcare
If you’re doing things like computer vision, it’s generally the same in every industry. If you’re a PM who’s a little bit more on the business side or the policy side, like at IBM, you really need to understand how all the parts of the healthcare system link together
Yeah right. And along the way I’ve found that really looking into how the money flows is a really great way to look at things because there’s a lot of incentives and things like that that dictate how things are put together.
Actually, I was just going to tell you that I’m working on a small health data project proposal found myself scouring the Quality Payment Program (QPP) website to find good health care open data. That’s your site, isn’t it?
Yep! That’s so funny; it’s great seeing people just casually review the QPP website. Actually QPP is a great example because prior to working here I actually never worked on anything related to payments. I was like ‘Yeah I understand healthcare’, but then I sat down on the first day with the QPP team and I ended up having weeks of reading to catch up. I still have a massive amount of notes in evernote. It’s very much a learning curve.
I’m curious how you really work to allot your time between all these various needs and what strategies do you use to make sure everything gets done?
So I have been a long time follower of the Getting Things Done (GTD) methodology. There’s a lot of software that’s based on it, like the Mac App ‘Things’ or Omnifocus and there are other products based on the methodology to process things and organize. But anyways, that’s my personal project management system.
For team management, I rely on agile cadences. I’ve noticed that, both at IBM, and here in the government (there are a lot of parallels), you have to bring on a good delivery manager, a term I had never heard before IBM. You just don’t have it at a lot of these smaller startups, and their job is to keep everything on track, akin to a scrum master on an agile team. They deal with a lot of the project management for building the software which gets quite burdensome on the product manager in a larger organization.
So our team right now is 30-40 people on what we’re working on and most people are matrixed, so their working on multiple projects which is a huge problem in enterprise and government. So, the delivery manager has been a huge piece of the puzzle that’s helped.
In terms of my time, I tend to split it by days, and so here on Friday I’m wearing a hoodie and jeans at the USDS office right down the street from the White House. Today is all about demos for the team, doing a team retrospective and preparing for a team sprint on Monday. So it’s all about building software today.
But, yesterday I had a suit on and was over at the digital studio one of our vendors, and so I have a bunch of stuff like that going on, where it was way more like a business day.
So, as a product manager you physically look different on days when you’re doing different things - kind of a very extreme version of wearing multiple hats. That’s how I try to approach it, I try to avoid mixing software and business on the same way.
Interesting - so I know at most companies, like PivotDesk you’re really appealing to your customer trying to provide the most value to acquire customers. But when you have a product like QPP, customers (doctors) HAVE to use it by regulation. How does that change things. Does it?
Great question - at PivotDesk the hunger for acquiring customers was so strong. Given that PivotDesk was a very physical business with office space and locations in the physical world, we were always out and about doing things to meet with customers and talk to them. But at IBM and in the government, customers are coming to you so the dynamics are different. Especially in government where regulation may be dictating customers engage with you. It’s super important to give them a great experience.
At IBM too?!
Yeah because IBM has the world’s best sales force, so in both cultures - whether it’s IBM or the government - there’s very much the build it and they will come mindset. It’s all about ‘Hey we’ll make it and customers will just use it’.
You have to be careful as a Product Manager in this situations to not lose empathy for your customers. . So one of the things that happened with QPP was that, even though people have to use it, we’ve really been pushing for feedback in webinars, user feedback sessions and more.
QPP has a monthly webinar that people have to attend. We also have an API that’s new this year, so a community of developers formed around using the API. The QPP team really wanted people to move from the web-based system and manually submitting information to using the API to submit data, so there was incentive for that switch. So, even though there wasn’t incentive for gaining new customers, there very much was for switching customer behavior which still requires communication.
When it comes to being a PM in government, you might be given a new piece of legislation and have to execute on that, how does that fit in or allow for a product strategy?
I was actually just on a Podcast called This is Product Management and we did an episode of where policy meets product management and we talked about two different approaches
My view is, with the policy in place, how do you understand it and build stuff for it? And, as a PM, how do you keep up with policy, and this very much relates to what I talked about earlier about being a PM in health care?
In terms of a PM job, that means, how do you keep up with policy? Where do you go to consume it? What’s a good way to stay on top of it?
Natalie, my coworker who joined me on the podcast, took the view about how data and feeding that back into crafting policy. Right - so it’s two very different things: executing on policy with software and using that software to circle back to change it. With QPP, for example, you could imagine how the analytics that the QPP is capturing could feed into future policy decisions around payments. If product decisions are being made to capture the right data it’s going to impact the policy down the road
So, here policy has been extremely important and as I’ve reflected back on other things in my career I’ve really realized what a big role policy really does play, even in the commercial sector.
From my rather small lense on the world I think policy is a weakness most PM’s do have. They think about building things, how customers buy things, but they’re not positioned to make a move in the market based on some policy that just gets passed. I know that’s heightened here in DC of course but other places it really isn’t
That makes sense. Well, to finish off, what do you think aspiring health-tech PM’s need to learn?
When I talk with new health PM’s I talk about a couple of things.
One is the difference between healthcare and life sciences. They’re really two different industries, with two different types of compliance, and I really think it’s important to separate those.
Another thing I talk about is policy. Things like HIPPA and the 21st Century Cures Act and MIPS and MACRA and to help them understand that. I think those are the two really good basics for a healthcare PM to have.
And the last piece of advice that comes to mind recently is to really get out of your office. Everyone in healthcare has stories and they’re so valuable when it comes to Product Management, but diversity there is really important.
For me we’re working on Medicare stuff so I keep referring to my Mother-in-law and parents and they’re like normal demographics with iPhones and stuff.
But you get used to that and so you realize it’s important to go to other places. We recently went the other day to the Georgetown hospital in Downtown DC where it’s majority low income. It’s striking how different that is and you realize you’ve been making some false assumptions. So I think it’s really essential to visit different places like that to get a diversity of opinion and not just rely on stories from family and friends.
Well thanks for talking to me Kelly!
Learn more about Kelly’s work at USDS here, and get ready for the next few articles in the Health Product Manager series!