The Lazy Product Manager Approach With Anu Kirk of Osso VR

Anu Kirk

Kayla: Thanks for tuning into Product Chats. On today's episode, I talk with Anu Kirk, who is the VP of product at Osso VR. And we talk about the lazy product manager. And what do you look for when hiring product managers? So hope you enjoy the show and don't forget to leave us a review.

Kayla: Thanks so much for coming on today.

Anu: Oh, it's my pleasure. I'm thrilled to be here. Thank you for having me.

Kayla: Awesome.

Kayla: Well, in a minute or less, can you tell us about yourself?

Anu: Yeah, my name's Anu Kirk. I'm a product manager who has been designing and shipping award-winning products for more than 20 years.

Anu: I'm also a former professional musician who continues to write and record and perform.

Kayla: Awesome. And so have you noticed any overlaps with your music career and product?

Anu: Oh, absolutely. For a couple years I did something called the RPM Project or the RPM Challenge where you're supposed to write and record an entire album in the month of February, starting with nothing.

Anu: And what initially seemed like a crazy impossible challenge once I realized, oh, this is just making and shipping a product. I was able to apply all of those skills and doing that sort of thing made me a much better and more productive musician. And conversely, I think the kind of combination, that unique combination of creativity and the discipline that being a musician requires is a great fit, for product management.

Anu: I had a job interview 18 months ago, two years ago, and I was talking to someone who was like, CPO at some company. And I noticed when the meeting started up, he just had like walls of like walls of guitars behind him. And I was like, is that a background? He's like, oh no, no, no. You know, I have like guitars and he saw that, you know, I had one set up here and he said, you know, I think, I think musicians always make the best product managers.

Anu: I'm a little biased, but I have to say I agree.

Kayla: So with that, when you were creating this album from scratch, what frameworks were you using that are similar to the frameworks that you use when you're building out product.

Anu: One of the most important things in any project is to prevent scope creep, right?

Anu: And to have very defined specifications and to know what you're going after. So one of the things that really helped was planning in advance and deciding what "done" was going to be. So in the case of making one of these records from scratch, it's like, well, I have either a time target that I'm trying to hit of like 35 minutes, minimum, or 10 songs with a definition of a song being, you know, whatever you want it to be.

Anu: And immediately I'm like, okay, well now I have my done criteria and I can start building out a schedule. I'm like, okay, well, if I'm going to, if I'm going to do this and I'm mostly doing it on the weekends, I have to be making like two and a half songs every weekend on average to to hit my deadline and literally use things like Trello for writing out the tasks that I need to do of like, oh, I got to make a drum part for this one song, or I have to make an EQ adjustment, or I want to retract this one guitar part.

Anu: And working through it, just like a backlog treating it like, okay, you know, what's the most important issue I got to do today? Let me check these things off. Am I making progress? What's my burn down looking like, and really treating it also as like, okay, this is good enough to ship, right? It doesn't have to be perfect.

Anu: I just have to get it to a place where it meets the criteria and move on. And that discipline of again, thinking about this enormous project and figuring out how I can break it into manageable chunks, where I can estimate how much it's, how much time it's going to take or how much work it's going to be.

Anu: Timeboxing, defining things, chipping away at it, all of that stuff. It was just like making a feature or a new product.

Kayla: And with that, you mentioned Trello. So, is Trello one of your favorite tools? What other tools are your go-to tools when you're prioritizing or figuring out what to build?

Anu: Oh, yeah. I love Trello and they're not paying me to say that, but they're welcome to if they're listening. Yeah. I, I love Trello.

Kayla: If they want you to write a song about it.

Anu: I love me some Trello. It it's visually appealing and clean, which definitely helps, but I also find that it is simple and flexible and powerful enough to do all the things that you need.

Anu: And you can easily attach images. You can make checklists, you can paste in documents, supports HTML, very easy to add people to it. I've been using Trello for music projects and my own personal life, as well as work stuff for 10 years or something like that. I can't remember when I first started using it, but I was immediately like, this is the thing I have been looking for.

Anu: And I use it. I use it in my job.

Kayla: And it's great to find those products where you're like, this is so vital to my workflow and it's changed the way that I do things. So before you use Trello, right? When you were, I'm guessing, just starting to get into product, what were you using and how did you come into that transition?

Anu: Oh, well, I've been doing product since the 20th century. So I started product back when most often.

Kayla: I'm an ancient product manager.

Anu: I am, but I started doing it back when many offices didn't even have internet. And back in those days I might be doing things. There was a period of time where I was actually using three by five cards.

Anu: Because at the time my boss was like the best product manager I ever knew used three by five cards. And I was like, oh, I'll try that. I had I had various PDAs and things like that. But a lot of times it would just be like a Word document or something where I'm just trying to keep track of the stuff I have to do every day.

Anu: When Google, when G suite got to a point where it was actually usable, I liked using that a lot because it was something I could update from anywhere and easily share with people in a way that, you know, at the time, Microsoft Office documents sitting on a hard drive, weren't quite as flexible. So that, that was something I used for awhile. But it was, it was a lot of, kind of meandering around, I think like a lot of people prior to Trello or G suite, what I really ended up using as task tracking was Outlook.

Anu: Everything had to be an email and you know, it's like, oh look, I got 150 flagged emails to work through right now. So I was very happy to get out of that world and into something that was a little more purpose designed.

Kayla: And so talking about where you started from, how did you actually break into product and what did that look like?

Anu: Back in the 1990s, when I was a professional musician living in Los Angeles, I decided I needed a day job because I had to pay rent and somehow buy groceries and sort of through a friend of a friend, I got introduced to somebody who said, who I met for lunch, and this person said, you know, I'm looking to hire a product manager and I think you have the right mindset for it and you'd be great at it.

Anu: And I didn't even know what a product manager was. I'm like, I've never, what is that? I've never heard of it. And they said, oh, it's the best job. I will teach you how to do it. And I was like okay, well, that sounds better than bagging groceries. And I went to work for an audio technology company where I ended up running their professional audio division.

Anu: And within four years was designing and shipping hardware and software products. So I had this fantastic mentor that basically taught me the ropes and gave me these incredible opportunities where just designing a hardware product. The volume of things that you have to learn to do that. I got to make a lot of mistakes on somebody else's dime with a kind of a safety net.

Anu: And that was, that was really helpful. So I sort of like most of us learned as an apprenticeship, kind of on the job with someone who knew a little bit more and was able to give me enough leash that I could kind of wander around and fumble around and figure things out for myself. I was a pretty quick learner.

Anu: And I did that job for about five years. And by the end of that time was, was reasonably skilled. You know, I had not just managed some features, but been able to make some mistakes, been able to ship some products. And because it was a small company had to do the entire spectrum of potential product management duties.

Anu: And that was everything from, I got an idea for a product to researching, doing a business plan, figuring out a costed bill of materials, working with engineers, writing user manuals, doing technical documentation for testing, figuring out shipping strategies, handling marketing, literally taking the product around and demonstrating it for both professionals and stores.

Anu: Having to do the advertising strategy, including buying ads, designing ads, hiring a graphic designer. Yeah, basically everything you can imagine from, I've got an idea to here is this thing that someone can actually use.

Anu: It was an incredibly valuable experience that the people that I met as part of that journey were what led to sort of my big breakthrough product management role, which was that in 1999, I helped some friends get a little startup going in San Francisco and they got funding and they called me up and they said, hey, yeah, we want to do something with music on the internet.

Anu: And we want you to be the product manager, so please move up here. We'll pay you to move up here. We'll get you set up. It's going to be awesome. So I moved up to San Francisco in 2000 and hung up my professional guitar and that little startup basically created Rhapsody, which was the world's first music subscription service.

Anu: And I was the primary product manager for that. And I did most of the initial product design and wrote the business plan and stuff. And that set me off on a 10 or 12 year career working on a whole bunch of different digital music services.

Anu: That was when I really started kind of laddering up. Cause at that point I had some experience and was in this fast growing, like hip cool hot space where we had a lot of challenges to work through.

Kayla: And something I kind of want to tap back into. As you said, you worked with both hardware and software, so on that, how's it different or similar building a hardware product and a software product?

Anu: What I would say is that hardware sucks and nobody should do it. Hardware is the worst. You know, a lot of the discussion around product management for the last 10 or 15 years has been about sort of the merits of different flavors of Scrum or Agile or Lean or things like that.

Anu: And those things are fantastic for software. Hardware is an entirely different beast. And part of why everyone inherited kind of waterfall processes is because that's sort of what you have to do with hardware. With software, you always have this potential or possibility for like revisions and shipping updates and changing things.

Anu: Hardware doesn't change and making mistakes is really expensive. So as an example, one of the products that I had designed and shipped, I found out as we were getting ready to ship, that somebody, it wasn't me, but somebody had made a mistake and the tolerances between the PCB board and the buttons and the metal case were about an eighth of an inch off.

Anu: And this meant that the buttons wouldn't actuate properly. Well, we'd already made, you know, a thousand PCBs and a thousand metal cases. How are you going to solve this problem? This is, this is a an expensive mistake to fix. And you're sitting there going, well, I do, we like get in there and, and file down the inside of the metal plate so that the board will sit a little bit differently or things like that.

Anu: That is one example of the kind of stuff that you have to deal with with hardware. But then there's also things like you have inventory, all that, all those things have to sit in a warehouse somewhere, and they're literally like losing value and all the components that you buy have to sit in a warehouse somewhere and you have to pay all this money upfront.

Anu: I, my hat goes off to anybody who works in hardware. It is. And that's before you get to like the regulatory stuff, damage in shipping. There's a reason that I have not really worked on hardware products since.

Kayla: So on that subject of building a product and growing and iterating, let's talk about the concept of the lazy product manager.

Kayla: So can you tell us a little bit about that?

Anu: Yeah, sure. So this is sort of a character or framework that I have developed over over my career. And the idea is basically that, you know, most product managers are excited to add new features to products and are constantly looking to do more work.

Anu: Not me. Right. You come into my office or towards my cube all fired up about some new idea and you're like, Hey Anu, I got this great new idea for the product. And you explain it to me. I'm just going to be sort of sitting back on. Yeah, no, I don't. I don't think so. I vote. I vote no and blah, blah, blah.

Anu: Why isn't this a great idea? I'm like, yeah. Yeah, sure. It's fine. Whatever. But this is just more work. First of all, this sounds really difficult. Like we gotta do, we gotta do a whole bunch of things. We gotta do like user research and we got to do some competitive analysis and I've got to go talk to the engineers and then we're going to have to figure out how to market this thing.

Anu: And I'm going to have to write a specification. You know, and then we actually have to get the work done, like putting it into sprints and scheduling and tracking it. And then we got to ship the thing.

Anu: My first question is like, don't we already have like a giant pile of stuff in the backlog. Like, do you not want to do any of that?

Anu: Is this really more important than all of that? Another question is like, well, if this is such a great idea, how come it's not already in the backlog? Why haven't we already planned it? Is this truly strategic and valuable for the business? Or is this just like some new hot, ooh, shiny. We need this temporary thing.

Anu: And we're probably going to screw it up, right? We're going to add bugs when we add this thing to the release and we're going to have to do a whole bunch of testing and then somebody you or me, or someone's going to have to write documentation, internal documentation for developers and for QA. And then we have to have external documentation for customer support or for our user manual.

Anu: There's going to be unintended consequences. I guarantee that as smart as you and I are, we haven't thought this through all the way and something's going to break. Some percentage of users are going to hate this no matter what we do. You know, is this really helping us drive towards our longterm goals?

Anu: Does it really make sense?

Anu: This is, of course this is really a pose, right? And it is a method that I use for setting a really high bar and degree of rigor around the process of adding and implementing new features. It's important to realize that like every feature you add to a product, everything that you do makes the product more difficult to use.

Anu: Right. Even if you think, you think it makes it easier, people already know how to use it the way that it works now. And if you're adding something new, it's one more button or thing that they have to wrangle with that is competing with their attention for all this other stuff. I'm also, you know, part of why I frame this up this way is I'm always extra suspicious of pure visual design refreshes.

Anu: There's a lot of products that love to do this. And visual design refreshes are like all of the work and bad stuff that I just ran through. But you get very little benefit out the other side in terms of actual direct user benefits, unless your visual design really, really is bad. You know, ultimately I kind of set this up this way because I want people to understand the total iceberg of work.

Anu: Most of the time people think about the feature and it's sort of the shiny bit, that's poking up above the water, but there's this huge mass of other things that you have to do that get dragged along with it that few people really think about. And it includes stuff like, oh yeah, documentation. Like, how does this new feature work?

Anu: What's the code? How do we train our internal and external people how to use it?

Anu: I do think that good product managers should capture all kinds of ideas, right? Whether they're solid or wacky or whatever, and throw them in the backlog, but you should set a really high bar for what you're actually going to commit to working on because it is a lot of work and you, unless you're just getting started, you probably already have twenty, fifty, a hundred other things that last week or last month or last year somebody was coming into your office about how this was the cool thing. So just, just be careful of the work that you take on it. Be lazy. And what I mean by that ultimately is like, what does it take to get me from reclining in my chair?

Anu: It has to be killer. It has to be essential. It has to be something that is really going to change the game, unless the only other option is like, yeah, sure. I don't have anything else to do.

Kayla: It's very rare that you would have nothing else to do.

Anu: Well, exactly, but this is kind of my point, right? Like I got all this other stuff I gotta be doing.

Anu: Why is this suddenly more important or can we establish that it's more important? If it is then it's like, okay. Oh, all right, fine.

Kayla: And with that, like, do you have specific, like rubrics that you use to make sure that before people are even coming to you, that they're kind of aligning these ideas and making sure that it's at least a valuable idea to bring to the table?

Anu: Yeah. Yeah, absolutely. And they might vary from company to company, but there are all sorts of strategies you can use. Like if you're the sort of company that has multiple targets, cohorts of users and you might be sitting there and saying, okay, well, does this new feature benefit, just one partner or one of our cohorts of users, or does it benefit them all?

Anu: All right. So that would be something I would push up. Whereas something that is aiming at one group of users probably gets pushed down unless it's like 80, the 80% cohort.

Kayla: Yeah.

Anu: Another great example is like how a question I ask all the time is how risky is this? Right. And there's a couple of dimensions to risk, right?

Anu: One risk is what's our estimate risk? If there's a new piece of technology that we haven't ever built before, and the engineers are like, we are highly confident that we can get this thing working in two to three sprints. I'm like, have you ever done it before? What is the risk? Right? Because that can quickly turn into something where two to three sprints turns into, you know, months because this core piece of something doesn't kick over.

Anu: On the other hand, if they're like, piece of cake, we did something like this, you know, last month. Then that's less risky.

Anu: Another thing is like how, how deep into the product is it touching? Right? So if this thing breaks or it's not working, can we roll it back or pull it out?

Anu: Or how, how much is it going to screw things up if it's not working? Are we like taking the engine out of the car and disassembling it, or are we just wrenching on something that's that's easily visible?

Anu: So risk is a factor.

Anu: You know, our confidence in our, our time estimates, you know, that that's an important factor.

Anu: There's a, I have a whole list of them. There's like 20 different things that I use. And I shared this internally with my current company when I started there helping people understand that good product managers are not little emperors that are just making these decisions by fiat or by what they want.

Anu: But good product managers are almost just kind of machines working through this flow chart of like, well here's the process that I'm using. Here's the criteria that I'm using to evaluate things. And it's all stuff that's really straightforward. If you just sit down and think about it for five minutes.

Anu: It's like, how dangerous is it for us to do this? How many people is it going to benefit? Do our competitors have it? Are our users actually asking for it? Do we think it's aligned with our business direction or where we want to be ultimately? You know, all those sorts of things. If you can't answer those types of questions, even if you think the feature is cool, it's worth sitting down for a second and thinking about it.

Anu: In some cases, it is really better to do nothing than to start throwing features into the product that are pulling you off mission. You know it just wears you down and makes your product more complicated.

Kayla: And I think something you talked about, right, was, does it affect one customer? Does it affect many?

Kayla: And that goes into the concept of listening to customers. And this is something that a lot of product leaders hire for is what are like, are you naturally curious? So I'm curious when you're building different features out or you're trying to grow the product, how are you listening to your customers and making sure you're actually affecting a huge amount of customers or a huge amount of revenue versus just listening to like the loudest customer in the room?

Anu: Yeah, this is, this is a big deal, particularly since sometimes the loudest customer in the room is the CEO or your boss. Who's like, well, I want it. And most of the time, your boss or the CEO, isn't really the customer because they're getting the product for free or at a deep discount. Assuming it's something that they even use.

Anu: I've worked at companies that have done the whole, like let's spend $20,000 and hire this third party firm to recruit users for us and we'll do the police mirror and interview them with cameras and you know, you sit on the other side of the mirror, throwing your hands up in the air and screaming. Why won't they and click the button?

Anu: It's right there. The button's right there. That stuff can be useful. But I think for most people you can do what I sort of refer to as like punk rock user testing, which is basically like grab five. They can even be people that work at your company on the product. You don't have to do fancy camera mock-ups or stuff.

Anu: You can even just literally with a pen and pencil or a very low fidelity paint tool. I like one called Balsamic that I use for mock-ups, but some kind of low resolution thing. And just be like, okay, this is what the interface is going to look like. Where do you think you would click to do X, Y, or Z?

Anu: And even with five people, if one of the five people has a problem with your prototype or your design, that's a pretty significant signal. And if two or more of those five people have a problem with the design, you got something you actually got to deal with. The important thing is I would argue not just to do like one round of testing that's really expensive.

Anu: I don't care how many people you test, but you should be testing a lot. Right? The best places I have worked at, have done something where testing is like, it's sort of a sprint in and of itself where it's like every other Friday or once a month, we spend half the day and we test the product somehow.

Anu: And that might be recruiting random users off the internet and having them do it. It might be just grabbing the newest people at the company and having them do it. But testing frequently is the key. It is how you can actually get better at it, cause you're doing more testing. Right. And we get better at what we do more.

Anu: But you're also going to get this constant stream of data. So you can see if your product is getting better or worse. Doing testing once is almost as useful as doing testing zero times because you just have one data point.

Kayla: And on that, I think it's like the idea of like iterating, right. And being able to iterate quickly because you're constantly listening and constantly getting that feedback.

Kayla: And so I'm assuming when you hire, that's something, you look for someone who can iterate and someone can, who can listen. What other things do you look for when you're hiring?

Anu: Well, as I think you mentioned earlier, I think the best product managers have a kind of a fundamental curiosity about things.

Anu: There is an aspect of creativity that is in there as well. So I try not to be as biased as the person I mentioned previously, where I'm like, oh, musicians make the best product managers. But what I ultimately look for are people who know how to ship stuff. Right. And that means that they understand the process beginning to end.

Anu: They have a curiosity about how stuff works, whether it is, how does this underlying technology work? How does this specific feature work? How does this organization work? Right. Because that's really key to getting those things done.

Anu: I think the best product managers also have an ability to kind of change a level of focus.

Anu: So as a product manager, you have to be able to kind of zoom out and see the 10,000 foot view, the strategic picture. What are we really trying to do with the product? What is the, what is the big goal of this feature? But you also have to be able to zoom in and go, that button looks like garbage, right? Or the delay between when I push the button and this thing happens or transition from this part to this part is unacceptably long.

Anu: Right. That ability to do both of those things, of seeing the big picture, but also getting in and paying attention to the details is also really critical.

Anu: Communication skills are essential for a good product manager. So the people that I think are the best product managers are people who know how to be powerful and persuasive in multiple forms of communication. They should know how to write well with, with clarity and precision.

Anu: They should be good public speakers or have some kind of performance chops because you are going to have to be doing these types of interactions and have to at least be able to fake being confident, you know, and, and sincere. A lot of product management is talking to people in one form, or other, communicating with people one form or another.

Anu: You have to be comfortable with that. You have to be good at it. So those are, those are sort of the basic things. You know, you can teach anybody who's reasonably smart how to do the job, right. It's not that hard, right.

Anu: Ultimately there is some X factor. Like some people are smart and just get it. And they're good at figuring out what people might want for specific things, but the nuts and bolts of it, I think is highly transferable.

Anu: The other thing that I sort of look for as part of that communications package is like people who are agreeable. You know, I can teach someone how to be a product manager. I can't teach them how to not be a jerk. You know, and that is particularly important when you have to be able to tell people no, or yes, but not right now, or, you know, all these types of things is critically important that you have some bare minimum of social or communication skills so that you can deliver bad news or frankly, even just get yelled at sometimes whether it's by your users or your boss or the rest of the team.

Kayla: I think those are some great qualities, right. And that can go in many roles, especially product. And so out of curiosity, are you hiring or growing your team?

Anu: Yeah. I am hiring right now. I'm looking for a product manager. I don't know if I've mentioned yet, but I'm currently working for a company that uses virtual reality to train surgeons.

Anu: It's called Osso VR. And we're looking right now for a product manager to kind of sit on top of the VR side of the business to help day-to-day feature development for the VR parts and also the development pipeline.

Kayla: Awesome. And then if you were to give one piece of advice to someone who wants to be kind of in your role and leading a team in product, what would be that piece of advice?

Anu: Product management these days is still largely taught by apprenticeship. You know, there's not really a lot of places that I'm aware of that you can go to school and get a degree in product management. So when people ask me, like, what can I do to be better? I usually tell them a couple things. Like there's some books you can go and read.

Anu: People will argue about what those are, but I would say work on your writing and become a good writer of documentation of varying forms, a strong communicator in that way. But fundamentally what I tell people is like, go design a feature. You want to be a product manager, go design a feature. Even if you don't even have a product, you could take a product that you like or that you hate and figure out how you could make it better or different.

Anu: And then just work through the standard product management process and like fake it a couple of times. You know, it's no different than if you were saying, oh, I want to break into say film scoring. How do you do that? Well, it's not, no one's going to hire you. So you go and watch a movie with the sound off and you compose your own score for it.

Anu: Then you do that a bunch of times, and then you have a reel of content that you've created. Same thing with product management, right. It's very difficult to get started, but I'll tell you right now, if I was trying to hire someone who'd never done product management before and they said, well, look, here's the specification that I did for this feature for iTunes or something else that I built from scratch and I researched it and here's how it would look and work.

Anu: I'm already like this person has what it takes.

Kayla: So I think it's just comes down to the skillset ,right. Of making sure that you have the right skill set. It's not always about the experience, but rather do you fit kind of the skill set that you're looking for?

Anu: Yeah. And you know, the challenge was sort of apprenticeship type of things is it can be very hard to get your foot in the door. I got extremely lucky in that somebody saw me and said, this guy has the skillset or the mindset, or there's something about him that I think is going to work and then was able to, to mentor me through it.

Anu: But barring that the next best thing to do is to just do the job and get some practice. And it doesn't have to be like a full-time thing, but even doing that exercise of designing a fake feature for a product a couple of times is going to teach you so much and will help you have something to show to people.

Anu: Particularly if they go, well, I don't, I don't see any experience on your resume. And you're like, well, let me show you what I've done.

Kayla: Exactly. So on that note, where can people find you? Where can they connect with you?

Anu: Well, LinkedIn is probably the best thing for business type stuff. Anu Kirk.

Anu: And I think I'm the only Anu Kirk on LinkedIn. So you search for me there. You can find me there and send me some messages there and I will generally respond unless you seem really nuts.

Kayla: Well, thanks so much for coming on today, Anu.

Anu: Oh, it's my pleasure. Thanks for having me.

Kayla: Thanks again to Anu for joining us on the show today.

Kayla: If you want more product management resources, feel free to head to canny.io/blog, and we will see you next week.