Podcast: Play in new window | Download

Sean [00:00:18] Hi, welcome to the Product Momentum Podcast, a podcast about how to use technology to solve challenging technology problems for your organization.

Sean [00:00:28] Hey, Paul, how are you doing today?

Paul [00:00:30] I’m great. Sean, how are you?

Sean [00:00:31] Good. I’m super excited to get in and hear from Josh to find out what makes him tick in terms of product leadership. He’s a smart dude.

Paul [00:00:40] Josh Anon has had a fantastic career. I’m a little bit jealous and I’m actually really excited for our audience to hear how he’s gone and transformed himself from opportunity to opportunity. I think it’s going to be a really great conversation.

Sean [00:00:52] Yeah, and about his journey from, like, hardcore hardware geek to, when you asked him the question, a more empathetic, storytelling product leader. So there’s a lot to learn there.

Paul [00:01:02] Indeed.

Sean [00:01:02] Let’s get after it.

Paul [00:01:03] Let’s get after it.

Paul [00:01:07] Well hello and welcome to the podcast. Today we are excited to be joined by Josh Anon. Josh is a product manager at Roblox in charge of 3D creation and studio. He started his career at Pixar as an intern in Finding Nemo and was a software developer, cinematographer, and more on every show through Monsters University. After Pixar, he switched full-time to tech as a product manager and worked on bringing sci-fi to life with light-field cameras at Lytro, AR glasses at Magic Leap, and socially assisted robotics at Embodied. He’s the author of the best-selling book for new PM’s, The Product Book: How to Become a Great Product Manager, and when not social distancing, Josh can be found photographing at the North and South Poles and you can see his photos at joshanon.com. Josh, thanks for joining us today. Welcome.

Josh [00:01:50] Thank you so much for having me.

Paul [00:01:51] So we’ve been excited to chat. Just to jump right in, you know, we’ve talked about scale and looking at your role in product, going from startup all the way through where you are now at the large enterprise scale, what are some of the best lessons that you’ve picked up along the way that you can share with PMs starting out in their careers?

Josh [00:02:13] So it’s funny. I don’t think there’s one lesson where it’s like, “you must always do this thing.” I think what I’ve really found valuable is to take stock of the situation you’re in, have a bunch of things in your toolkit, and figure out what the best tool is for the current situation. Fundamentally, though, no matter where you are, product is about being the voice of the customer. But if you think about an early-stage startup for a second, it’s like, chances are you don’t have a product yet. If you don’t have a product, you definitely don’t have customers. If you have a product, there’s a good chance you don’t have product-market fit. So a lot of times things really boil down to opinion versus opinion. So being able to deal with that and understand how to work in a very ambiguous situation is critically important. When you’re at a large company, you know who the customers are and chances are you have access to them. So the tools are going to take where you can go talk to them directly and they have a good frame of reference are going to be very different.

Josh [00:03:08] I think it’s also important, though, to keep in mind the difference between the solutions that matter for the situation. If you’re at a startup, you have to take risk. It is part of the nature of it. If you have something that is 10 percent better than what they are doing now or saves them like a minute, they’re not going to care. Whereas at a big company, when you have millions and millions of customers, saving one minute for every customer adds up really quickly. At a big company, it can be tougher to take a big risk because you don’t want to cannibalize some of what you’re doing. That does also lead to the classic innovator’s dilemma, which is why there’s room for startups to get in there. So I guess just taking it back together, it’s like, I’m not sure there are particular lessons that I’ve learned that apply broadly beyond just the general, stay focused on the customer, make sure you’re delivering a solution that’s actually valuable to them, and do whatever you can to really validate and make sure you’re doing that. Ultimately, I guess it boils down to, be willing to adapt to the situation.

Paul [00:04:09] That’s great. Yeah, customer feedback scales, right?

Sean [00:04:12] The longer your product’s been out there, the more you have to lose from your mistakes. The more people are out there using it, the more you have to lose. So it’s just a different risk game that you’re playing.

Josh [00:04:22] Now, I will say, though, I’ve always been a fan of, expect that you’re going to be disrupted. So it’s a good thing to keep that in mind and think about how to disrupt yourself.

Sean [00:04:30] Yeah, I like that advice. And your book is a testament to a lot of these tools. There is a diverse toolset that you need to have as a product leader, and the tools that you pull out are going to be different depending on all sorts of context: your product, your leadership, how strong your team is, right?

Josh [00:04:47] Definitely.

Sean [00:04:48] So I think the key learning there, from what you just said, Josh, is that the more flexible you are as a product leader, the more successful you’ll probably be.

Josh [00:04:55] Yeah, it’s funny, when I read through my book now, I mean, it’s been a few years since I’ve written it. I’m sure there’s some things that I’d change. But in many ways, it is kind of about the ideal situation. Like a lot of these things are easy to write down on paper and it’s easy to keep in your head. But the actual implementation is always going to vary based on the company, the timeframe, the people involved, just every possible real-world factor.

Paul [00:05:19] So I want to go back to a thing that you mentioned when talking about customer feedback, and especially at the scale you’re operating on, one hundred and fifty million monthly active users, and you’ve got in front of you this almost unlimited opportunity to gain feedback and learn. And I love the things that you’ve written and spoken about in terms of goals and goal setting. And I wondered if you could talk for a minute about this scientific approach that you bring to goals, in how you learn and how you target goals, but also how you pivot and respond reactively to the goals that you’ve set for yourself.

Josh [00:05:52] I think it’s really reasonable when you’re working on different goals to start off with a hypothesis. And that’s whether you’re in a big company or in a small company. It’s like, you have this idea that you think is true. It’s the scientific method, right, and then the thing is, how do you go seek out evidence to prove whether or not it’s going to be true or you’re wrong? It’s funny, when I was working with a data scientist at Roblox, he commented to me that he hates when product comes to him and says, “Hey, I want to make this case, can you help me find numbers to support it?” Because that’s adding bias to everything you do. And really we can develop intuition and we can develop good instincts over time. And the more experience you get, the better you can put yourself into a customer’s shoes, I think the more that happens, but you can still be wrong.

Josh [00:06:36] And especially when your scale increases and there’s real dollar signs attached or when you’re talking about like a big foundational thing related to a core risk at an early stage startup, the cost of being wrong is very high. So what can you do to help eliminate that? So I think one fundamental thing, just getting back to goal setting, is I actually think it’s more valuable, rather than focusing on like, “oh, if I do this thing, then I can move this metric one percent,” by focusing on, “OK, I have a goal of wanting to address this customer pain, now let me go assess and see if that’s a real pain that’s actually worth solving and that I’m going to be able to solve it in a way that’s going to pay off for the customer.” And of course then the toolkit you bring to that can be wildly varied from maybe at quantitative metrics, maybe I can go actually reach out to people who are doing this thing right now in the product and ask them. Or if it’s, again, like an early-stage startup that might even be, “let me go find proxy behavior for this and try to see if people are actually solving this pain point right now.” So that’s my attempt anyway, is to start adding some science to this, where it’s, “let’s have the thing that we think is true, let’s state it explicitly, and then let’s assess what tools we have to go see if it’s true or not.”

Sean [00:07:51] So I’ve been excited to talk to you and to learn from you. You have a pretty impressive resume that any product leader would be jealous of, from Magic Leap to Pixar to Roblox. And the extremes! I can imagine the environments and the people that you’ve had to work with in those environments have been incredibly varied. So from hardware and software to AR and VR, to working with a startup, to working with much more established firms, you’ve seen a broad diversity of product management environments. What are the common threads in terms of both problems and success factors across all those environments?

Josh [00:08:27] So first of all, thank you. I do feel very fortunate to have always kind of worked at that intersection of art and technology and just tried to take a career path of, “I think this thing is interesting, let me keep pursuing that.” And it’s paid off. It’s created challenges at times, but it’s paid off.

Sean [00:08:43] I’m sure.

Josh [00:08:43] So it’s funny because the commonality, in many ways, it really feels like it just boils down to PM 101: keep in mind who is the customer, what problem you’re solving for them, and can you actually do it in a way where a customer will accept the trade-offs and the technology can deliver a solution with the trade-offs the technology has that the customer will accept. Some of the challenges actually come in to the way that that varies. Like it’s really easy to say and sometimes very tough to do in practice.

Josh [00:09:10] Something that I found a lot, especially when you’re at an early-stage startup, is that as a PM, you can have that in mind. But if you don’t have a product and you don’t have any customers, then, at the end of the day, it boils down to the founder’s opinion versus what you’re stating as an opinion. And both of your opinions are going to be somewhat informed based on whatever you bring to the table, but it creates this power differential and that can be very frustrating for a PM, especially when you think things might be going off the rails or maybe the company’s making a bad decision. And it’s actually frustrating sometimes when you see the product and you feel like it’s not the decision you would have made, and then the product ships and maybe it’s not really well received. And on one hand, as a product manager, you’re like, you want to step up and say, “well I own this thing,” and take responsibility for the failure. On the other hand, it’s like, “OK, yes, this is some validation that I was right in terms of my opinion here,” but there’s nothing you can do about it. It’s like for the good of the company, it hasn’t worked out and you need to figure out how to move forward.

Josh [00:10:14] A very concrete example of that that I’m thinking about was at Magic Leap. So Rony, the Founder and CEO, is an amazing visionary. The guy is just really wild about thinking about, “what’s the world going to be like in 10 years and what can we do to help get there?” I mean, he built a surgical robot before anybody else was really thinking about this or doing this. He founded Magic Leap, which essentially started as writing a script, and turned it into a company building an AR headset. But his belief was that this was going to be a consumer product and millions of people were going to buy it, like very close to day one. Now, as a product person, I think myself and my team didn’t agree with that. We thought that the first product should have been positioned more as a developer kit, very much an early adopter-type product. It would take a while before you get to a mass-market consumer product.

Josh [00:11:00] But it was Rony’s company. He had raised billions of dollars in the view that it was going to be a consumer product. So we built products, kind of baking decisions in that said, “assume you have a large user base very quickly, what are the choices you make to serve that user base?” I think when the product shipped, unfortunately, that didn’t pay off. It’s an amazing product in many ways. Like, it’s a great headset. It shipped. I still think it’s the best AR device in the market, even with HoloLens 2 out there. But, as a product person, it’s frustrating to look at that situation and know that, because it was opinion versus opinion, it was tough for me to serve the customer truly.

Josh [00:11:35] I feel more fortunate now at Roblox. I have customers in spades. I can talk to them on our developer forums. Heck, they don’t hesitate to let me know what their pains are. So it’s really easy to get a sense of, what are the challenges our devs have? What are the things that I can actually do that are going to benefit the customers? To have even designs that we reach out and have feedback sessions for and get input, even if that input is just simply, “thank you guys for addressing this; this is going to save me so much time.” It’s a very different world to operate in. But really what it all comes back to is just, who is the customer we’re solving for, what problem are we solving, is it a real problem, and can we solve that problem with whatever trade-off in a way that the customer can accept and afford?

Paul [00:12:19] Yeah, this goes back to a three-part series on your blog that I really appreciated in sort of the startup decision-making process and looking at these four critical skills of learning, researching, writing, and experimentation. And I’m going to ask a very tactical question, admittedly tactical, but I’m very curious about it because you were a very vocal proponent of PRDs in one of the sections of your writing. And my reptilian brain reacted very strongly when I read that because of a lot of waterfall experiences that I’ve had that didn’t necessarily feel like high value-add in hindsight. But I think the way that you framed PRDs, and more broadly, the concept of writing as a product manager, I think is important because we tend to avoid documentation in Agile. Documentation is almost seen as a necessary evil. But the way that you framed a product manager’s PRD, in a sense, is really a living document. And I wondered if you could just share a few insights on, how can we embrace documentation in a way that is valuable in our current state of the industry, where agility is upheld as a value?

Josh [00:13:27] So stepping back, at a high level, I came to see a waterfall as being putting a stake in the ground and saying, “this is the thing that we’re going to do and we’ve all agreed how we’re going to do it, and no matter what, it’s not going to change; we’re just going to execute to that path.” And I think there is some value in there, right, writing down and saying, “this is where I want to go.” Now, the thing that I think Agile really brings to the table is looking and saying, “the way we get there, we don’t know for sure, we’re going to learn.” You think about it for a second. It’s like, I don’t need to know what roads I’m going to take to know that I want to take a vacation in the mountains instead of the beach. But if we agree that we want to go to the mountains, we can figure out the best way to go there.

Josh [00:14:06] Now in terms of documentation, I have to admit that, like many PMs, I kind of stumbled into the career not realizing what it was. And what I was doing that at Lytro the first time with that being my title, I found that people would come to me and expect me to have all the answers and that I knew what we were going to do to help really serve the customer well and what we were going to take the company onto next. But the problem was that often this would end up in games of telephone.

Josh [00:14:30] So let me give you the specific story that convinced me why I really like writing PRDs. So for those of you who don’t know, Lytro made these special cameras that let you capture what we called Living Pictures. So rather than capturing how bright and what color pixel a is, it would actually capture three-dimensional rays of light. And this let us do things like refocus an image or change the perspective afterward. It also let us get a 3D image with one single photo. And 3D was hot at the time; this was like 2012 or so. Early on before I joined the company, some folks had talked about doing 3D and providing that as a benefit to our customers, and they kind of quickly got into the ultimate thing of, “well, you really want to see it on your TV and TVs have all these different standards and we can’t make it work automatically, so we’re just going to punt on this.”. And I instead was looking at this and thinking, “OK, short-term roadmap, what can we really do to give customers something new, especially as we’re building towards the next hardware?” And I realized we could do something really cool where we ship our customers red-blue glasses, like a little Christmas promo or something, and then we’d just have a mode in the software that lets you put these images up on the screen in red and blue. So very lightweight, simple 3D that is just fun. And I think fun and delight are really important for products that we like.

Josh [00:15:43] So this is what I started talking to folks about. But because there had been those scars before where people thought that 3D meant this like full, big, giant scope thing, this was suddenly controversial in the company. So I took maybe an hour and I just wrote down like a page and a half. And it was essentially, “here’s the thing we’re going to do, here’s the customer we’re addressing, here’s how we measure success, here’s a user narrative about how a customer is going to use it and some key requirements baked out of that.” And all of a sudden, it was much less controversial because there was something that I could point to and share with people. I have consistently found some of those same results to be useful everywhere else I’ve done. This notion that something is written down that captures those key product things you want to answer that maybe has captured actually discussion you’ve had: questions, answers you’ve come to, comments in a Google Doc showing what somebody asked and then the discussion and where you arrived at, putting all this stuff down. It doesn’t have to be big. To be fair, I’ve written docs that are like 60 pages when I’m working on big hardware things and that actually had to be spec’d out that way because there was hardware that had specific requirements, like, the camera must work in this level of light, that affected choices we made that we wouldn’t see the impact for for years later. Hardware does tend to be a little bit more waterfall, unfortunately.

Josh [00:16:58] But I’ve also written docs, like I said, that were a single page that was just, “here’s the stuff about the project written down.” So bringing this back together, for me, I’ve really found this documentation valuable, not in the sense of like, “this is a massive, static thing that’s not going to change and we’re going to build this come heck or high water,” but rather a, “here is where we want to go and the key things we want to make sure we don’t lose as we execute towards it.”

Sean [00:17:23] Right. So to summarize, the PRD concept is team- and context-dependent. It may require a page, it may require voluminous text describing exactly what features are going to do what. That leads me to another thread that comes from some of your writing about storytelling. So I’d like to unravel that story. What are your thoughts on storytelling as a skill set for product leadership?

Josh [00:17:46] I consistently think that is one of the most valuable skills a PM can ever develop. So if you step back for a second, what is storytelling at its core? It is really defining characters in conflict, the situation they’re in, and the resolution that gets them out of that, and then how they change as a result of it. And if you think about good stories, they tend to have the details that matter in them. The extraneous detail isn’t there. And if there’s something really awkward when you’re hearing the story or reading a story, it’s usually pretty easy to parse it. It’s like, chances are it’s not probably authentic. So if you step back as a PM, like I kind of mentioned earlier, one of the biggest challenges we have and something that keeps me up at night is, what if I’m wrong about my hypothesis? And I think writing or telling a story is a very quick way to do sort of a gut check about, “is my solution going to fit into the customer’s life in a useful, meaningful way?” So if you write a story about, here’s the problem the customer is facing, here’s how they come across this product, here’s how they adopt this product, here’s how they use the product, here’s a realistic assessment of what it takes to use it… It’s like, if your product involves a step where the customer has to wait for an hour, you probably put in there that, like, the user went for lunch while this thing was happening because it’s unrealistic if you’re like, “oh, immediately it returns,” or something like that. And it’s just a really good way to assess, does your product fit?

Josh [00:19:11] Going back to my point about the details that matter, the second thing that I found matters: how often have you heard somebody start a story, “last Tuesday… Oh, no, last Wednesday. No, it was actually Tuesday.” It’s like, it doesn’t friggin matter. It was just some time in the past this thing happened. So the right level of detail can actually help you realize, what are the features on your product that really are critically important, and what’s the stuff that just doesn’t matter? So just by spending a little bit of time writing an actual prosaic narrative, I found that I can pretty quickly boil down, is this product legit? Is it something that seems like a customer is actually going to use it? If I talk about the trade-offs my product has, does it seem real that it’s going to fit into the customer’s life, and then what are the key things that actually matter that I need to build that are going to help them adopt and use this product? Now, to be fair, it’s not perfect. The story can’t replace, like, making sure you test and validate in other ways. But I found that it is a great starting point to communicate what you’re building.

Sean [00:20:13] Yeah, and I think another thing to point out here is that, and you talked about it in answering the last question, is, who’s going to be reading that story? Who’s going to be reading that PRD? And really knowing your team and the level of depth that they already have around the product and the technology and what they’re there to do is a really important skill and a really important piece of knowledge for the product leader to have.

Josh [00:20:35] Definitely. It’s funny, I’m sure it’s no surprise to you, but different people read PRDs looking for different things. Like, in some of the biggest PRDs I’ve written, there’s a one-page executive summary that maybe like the CEO reads to make sure we’re on the same page. There’s the longer, sort of overview, background, context, all the relevant information here that maybe somebody new to the company reads to get a sense of what’s going on. And then there’s the back half where it’s, here’s the narrative that people who are maybe more design-focused and really just thinking high-level read, and then there’s the requirements tables that the engineers care about deeply and program managers and that can be turned into things that you track in Jira and so forth. So it’s funny because I think put together, you kind of need all of that to make a good PRD that’s really useful. And of course, then it’s a lot of work as PM always keeping that up to date with everything that you learn.

Sean [00:21:26] For sure. So, Paul, you’re in these details pretty much day in and day out. What are your thoughts on this concept?

Paul [00:21:32] Yeah, I love the place that Josh just took us because I think storytelling has the humility of what he just talked about keeping him up at night, “what if I’m wrong?” But it also encompasses that swagger that every product manager sort of has inside of us. We all have that inner Steve Jobs that wants to walk out on stage having ripped a keyboard out of a phone to show the world, “hey, this is what you’re going to be using for the next couple of decades,” in having that confidence of vision, but also that “what’s keeping me up at night?” And I think storytelling is right at the center of that. I think it’s a really great approach. And I wanted to ask Josh a follow-up question: how do you cultivate some of those storytelling skills? We’ve talked about what storytelling is and what it does, but I think there’s some aspects of building context and building that emotional impact that you started to give us a peek at. And I’m curious, how did you go from a hardware geek to an empathetic storyteller? That transition intrigues me.

Josh [00:22:30] Well I do think I was really fortunate to work amongst some of the master storytellers for a long time at Pixar. I mean, at the end of the day, people don’t go see the movies because we have the most beautiful global illumination rendering technique, they go to see him because they have a great story. In fact, just to tell you a couple of stories about Pixar, and this was way before my time, one of the first shorts the company did was Luxo, Jr., the animated jumping lamp. And apparently, when that debuted at SIGGRAPH, they hadn’t finished rendering the whole thing. So part of it was actually still in storyboards and they were worried, like, “how is the audience going to react to this?” And afterward, nobody realized that it just switched to storyboards because they were so engrossed in the story. Apparently, the question they were asking afterward was, “was that a daddy lamp or a mommy lamp?” So there is a lot to be said about emotion is what matters.

Josh [00:23:17] And we used to have this mantra at Pixar in the software group that we make movies, not software. At the end of the day, the technology is in service of something bigger. That’s funny as you referenced Steve and sort of the big debut and reveal on stage. There’s a lot of work that leads up to that. And it’s not like Steve wakes up one night and was like, “I have this vision of having a phone without a keyboard and we’re going to go build that,” right. There’s identifying the problem and then really thinking about, who is the customer and being empathetic to what you actually want to see in the product and want to make happen, and then building that no matter what it takes. Now that also means that you have to have a strong ability to say no to things. Like it’s better to do less that’s better as opposed to doing every single feature possible and delivering it poorly. Sort of along those lines, sometimes I’m actually more proud of the things that I have fought against or tried to kill or successfully not get shipped than some of the things that I have shipped just because I think that I want to be able to tell a good story to my customer and have something where they love everything about it, and they’re just really happy using it and that we’re not spending time building things that just don’t move the needle or that they’re not going to care about.

Josh [00:24:32] To give you a concrete example of some of this, there is a project that I’m working on right now. We’re really fortunate, one of Roblox’s cultural values is taking the long view and as a PM, I love that. I can really step back for a second and say, “what is the ideal thing that we want to do for the customer?” And I’m doing that right now with the system and I’ve actually kind of written a narrative and it’s a few pages about, what is it going to be like to do these critical tasks with the system? Now, to your question about like hardware geek to empathetic person, I think really what’s happened in there is I’ve come to the understanding that the technology doesn’t exist because we’ve managed to figure out how to build a feature, the value in it is focusing on, what is it that a customer is trying to achieve? And now let me tell you the story about how I want them to be able to achieve it, let me consider how they’re going to do this part of their workflow with the feature, and let’s write that. And the next step of this process, just so you know for the project I’m working on, is going to be the design team actually takes it and starts fleshing out storyboards. We’re going to cut those together and actually use that for alignment. In these storyboards, the challenge is finding the right fidelity of information where it’s detailed enough and has taken a stand so that now we can show to other people in the company, “this is what we want the system to be,” and actually really get alignment about where we want to go and hopefully even show it to customers and be like, “are you going to want this thing?”

Sean [00:25:58] That dovetails into my next question here for you: how do you know when you have an innovation? How would you define innovation?

Josh [00:26:04] It’s funny. It’s just having this discussion the other day, discussion might not even be the right word for the actual conversation. Maybe debate is a better word. There was an article recently that came out in the Harvard Business Review about Apple and their organizational structure and how they stay innovative, and a number of folks were pounding on Apple and saying, “oh, they’re not at all innovative,” or “they haven’t been innovative since the iPhone.” “Oh, their innovation is just marketing.” It’s interesting, having worked at many companies, just small startups, where I think we were very inventive, but nobody cared, and nobody bought the thing, and nobody used it. So it’s hard for me to make the argument that we were innovative. So innovation, in my mind has become a mix of, how do you have a novel solution to a problem that is way better than what people are doing now to solve it, and you’ve made it available in an accessible way that has minimal tradeoffs for the customer.

Josh [00:27:00] I think the way that you know you’ve achieved innovation is when you actually see it out there and you see it being adopted. It’s not just you’ve done the inventive process of that. The really cliche example that I think everybody knows is, the original iPhone, I mean, it was incredibly inventive and innovative in many ways, but I actually think it was the pricing model that happened and the subsidization of the phone with the 3GS, where now instead of costing like five hundred dollars, you could get the phone for two hundred dollars, that made it just skyrocket and take off. And then of course things like the App Store opening up new possibilities with it. So to me, it’s really a combination of those pieces and I think you start to see when you have it when all those things come together and like you see your product in the wild. If you’ve never seen it, I highly recommend you watch the documentary about General Magic. It’s really well done. In case you don’t know, General Magic is sometimes referred to as, “the most important startup that nobody’s ever heard of.” They invented a smartphone years before people had even had the idea of it, before there is any decent connectivity, just as the web was starting to become a thing. But because those other forces weren’t at play, the invention didn’t matter and is largely forgotten. But the people they brought together took everything that they learned and went and built some of the coolest stuff that we use every single day, from eBay to the iPod to Android to more.

Sean [00:28:21] What your question challenges is, is it really an innovation if no one cares?

Josh [00:28:25] Yeah, and it’s really frustrating having worked on some of those products. And I will tell you, one of the weirdest things for me, so being at Pixar, where the stories that we made affected culture that people referenced, that everybody knew about and had seen and we’re talking about, and then going to Lytro where, being camera a nerd, I thought this was really cool. I was paying attention to it. I have a device, and sure, there were quirks, but it was fun to shoot with, and being in a company meeting for the first time where they showed our sales number and just looking at the slide and going, “is there a multiplier there that I’m not seeing?” It’s like, it was so small, it was practically irrelevant. And now it’s frustrating because I mean, so many people don’t even know what Lytro did. And to me, it’s almost, “well, was that time in my life valuable?” And to be fair, like, the connections I’ve made and the people that I’ve stayed in touch with and the things that we’ve all gone on to do since there and the learnings that we’ve taken, yes, all that matters. So it did pay off. I don’t regret it for a second. But still, like, the Lytro camera, was it an innovative product if nobody bought into or used it?

Paul [00:29:29] Super interesting. There’s some gold in there. I really like the perspective that you just shared. In closing, I wanted to ask one last question. In addition to your own book, I was curious what you’d recommend any product manager have on their shelves?

Josh [00:29:44] One of my absolute favorite books that I think all PMs should have read is Insanely Simple and it is a book kind of about Apple and Steve especially. It was written, if I remember right, by a former marketing executive. But the key takeaway in this is that customers care about simplicity. They want just like the one-button thing that just solves their problem. And it doesn’t matter if you have to go through great complexity to achieve that. Another example the author uses is Ben and Jerry’s. You want ice cream that has big chunks of stuff in it, like it’s just so much more satisfying. But Ben and Jerry’s actually had to invent completely new machinery to make that ice cream. The book gives a whole bunch of different case studies talking about the approach Apple took to really slice through the noise and find the simplicity and I think that’s incredibly valuable from a product perspective. I will also say, though, I tell PMs that they should really read science fiction. Because every day, especially if we’re thinking about user narratives, we’re imagining a future that doesn’t exist. Sometimes it’s really far out there if the project’s going to take years, other times it’s just like a month or two. But science fiction is all about, what is a future-state world that extrapolates where technology could go and the implications that that might have? And I think that it’s really friggin important to anybody that’s trying to be inventive and innovative, to be able to extrapolate trends in technology and think about, where could this go and what are you actually going to want out of it?

Sean [00:31:12] Well, you’re not going to hear Paul or I disagree with that statement.

Josh [00:31:15] If you have good sci-fi book recommendations, please send them to me. I will say my favorite thing I’ve read in the past couple of years is still The Three-Body Problem. I haven’t found anything that comes quite close to that. So if you find better, please tell me.

Paul [00:31:28] It is a genre-defining book for sure. I think that is our new Dune. Josh, it has been a pleasure. Thank you so much for taking the time to chat with us today. We’re really excited to get this out to our listeners and share your storytelling with the world.

Josh [00:31:40] Thank you so much for having me. It was a pleasure talking with you all, too.

Paul [00:31:46] Well, that’s it for today. In line with our goals of transparency in listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get. So please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.