The Art of User Story Writing

Ryan: I'm Ryan Harper and I am a product director at Condé Nast Entertainment.

Suzanne: Very cool. I have been doing the necessary research, and looking retrospectively, Ryan, at your career, it does seem from my position that you very deliberately made a point of having every possible job one could ever have related to product management. You've been a researcher, you've been a designer and developer, you've been a project manager, you've been a founder, and then you've been in product for a long, long time. So, was it as tidy as your resume makes it seem, or there's more of a story there?

Ryan: Yeah. Definitely was not premeditated to that extent. I really found myself doing product management before I knew what product management was in many ways. So the way I got into it was I was in grad school for music composition. I was asked to contribute to a multimedia project, as the composer. The project turned out to be this idea of remixing common domain literature to enable students to put their own stamp on the books that they were reading. I just fell in love with this idea. The project eventually became an app, and we got into a startup incubator, DreamIt Ventures with also Startle supporting us, because we were a learning endeavor. Over the course of that summer, I did everything I could to make sure that this app would become a real thing, and so that meant learning how to code a little bit.

Learning how to make sure that the designers assets were in a state that they could be handed off to development, and learning how to work with the CEO at the time to figure out who this app was going to be for and what it was going to enable them to do. So exactly what things we were targeting, how the app was going to be used in the classroom. All of that information, which turns out is called product management. So really my role there was serving as the glue. I fell in love with this idea of creating through this collaborative process. It was very natural in me coming out of music, actually, because I was spending all my time writing music that was then realized by musicians. So that process was also very collaborative. This was just a whole new space where I could build and play in sort of a maker space.

When I went back to USC to finish up my second year, I was finishing my music degree, but then also got involved in the Annenberg Innovation Lab, which had just started at the communication school as a designer/developer. I was helping them create apps for people that were sponsoring the lab. One of them was LACMA, Los Angeles County Museum of Art. Since getting involved with LACMA, I've really never looked back. I have just continued to sort of play in the media space and try to create great products.

Suzanne: Yeah. I mean I love the description of the product manager as being like the glue. I think a lot of folks that I've met in my career who have accidentally found themselves into product management, have acknowledged it through exactly that feeling is that there's an intuitive sense of needing to be near all of the people that are part of the project, and then realizing that that's actually a job.

Ryan: A role. Yeah. No it was a great discovery. I was really stoked when I discovered that this was a real thing.

Suzanne: Yeah. Absolutely. Now, you were in that whole sort of stretch of what sounds like, the timeline presents linear, but it sounds like a lot of these things were kind of happening in and out, but you actually had a founder title. This was a different product? Or, this was the music app that you're describing?

Ryan: Yeah. So I was originally brought on to the music for it, but then very much became a core part of the team.

Suzanne: Yeah, you wouldn't leave basically.

Ryan: Yeah. Exactly. I was like what more can I do?

Suzanne: Like, we asked this guy to compose music and now he's the founder now. I don't know what happened.

Ryan: Yeah. We presented our product at our demo day at the end of the summer. At that point we had actually pivoted, so we had taken the core ebook technology we had built and started to use it to create multimedia apps. At the time, Bjork's Biophilia app had just come out. Jay Z had just come out with a multimedia app, so we were really inspired by this idea of being able to take music, but then also put in the lyrics, the images, the stories around the songs, all of that into one seamless experience. I took that idea and ran with it after the end of the project, end of the summer. That for me was when I really started to take on the CEO role, was when I was taking this final product, which was called E Groove, and taking it to market. Making sure it got into the app store, and then we even ended up taking it to a couple different organizations in the L.A. music space and talking about it with them, and trying to see what we can make happen.

Suzanne: Great. You used the word pivot, but I'm curious, did you know about pivot as a thing outside of basketball then or it's just easy to look back with proper understanding and say, "Yeah that was a pivot." What did it feel like at the time when you were making that change?

Ryan: Sure. Dream it did a wonderful job giving us access to all of the startup literature that, at least my team, hadn't been aware of before coming into the organization. So about halfway through the project, we were basically living and sleeping the product. We had been told that pivoting was a thing. We were trying to figure out the optimal use of the technology. When we were pivoting, we knew that we were pivoting, so it was not an unknown term, but it was definitely a new term.

Suzanne: Right. Thank you. Yeah, I think it is funny. I worked with some startups and I've had some that will come and say, "I think this is our pivot. We're in our pivot." As though it's almost a rite of passage to any company.

Ryan: Yes.

Suzanne: It's like if you get to pivot, you've actually kind of done something right because you realized what wasn't working.

Ryan: Yeah. You've at least been doing your market research.

Suzanne: Talk to us about being a founder in the context of project management, and let me frame this question for you. So part of the reason this show exists is to demystify or bring some common understanding around this idea of what is product management. Mostly, it's for product manager who might be out there listening, and feeling like is that my job? Am I doing this job?

But I think equally, we have a large audience in entrepreneurs and founders, who have heard this term, but don't necessarily understand the role and might not necessarily know when is the right time to bring on a product person. So I'm curious, from your own lived experiences in that role, but also from your subsequent years of working in product, what you could say about that. When is the right time to bring in a product manager, and what is a product manager?

Ryan: Sure. Again, going back to the idea of product manager facilitating, what's going on with the team. I think that once you have a designer, once you have someone who's going to be the spokesperson for your product and once you have someone who's going to help you build this thing, the next sort of piece is how are you going to make sure that all the parts are working together. So I think even if you have a team of four, it's okay to have a product manager there. In the subsequent roles I've taken on, the product manager is typically working within a team of a few engineers, a designer, and in that role, I think, the product manager is also starting to work with different parts of the organization. That's where product management gets more difficult, but also it becomes even more of a sort of outreach role, and trying to make sure that different parts of the organization are functioning together.

Suzanne: So, a lot of people say that somebody on the founding team should be a product manager, whether they actually already come kind of with that mindset and skill set or whether they just recognize that's a role that needs to be sort of filled from day one. I guess, the question is, in my mind, at one point does a founder need to let go of being that product manager role and recognize that, "Hey, we're at a scale enough that I need to put a dedicated person here so that I can be freed up to be the CEO, and work with investors and be the face of the company, or the CTO and be more focused on kind of the innovation and the processes around the product development."

Ryan: Sure. In my mind that time would come when the CEO is no longer able to attend the daily stand ups and make sure that the team is fully aligned on the day to day activities, but it's interesting, I think, that I haven't really done the growth phase. So maybe that's why I'm struggling with this question, because I've done the tiny, tiny start up of four people and then my other roles have been essentially start ups within large organizations, which always has a PM role as part of that because that smaller group needs to have a point person to coordinate what's going on but also to report out to the larger company.

Suzanne: Right? So you don't have the bruises from the “will we he cross the chasm or not, will we get there?”

Ryan: Yeah. The whole growth phase, I think, is a right barrier for exploration for me.

Suzanne: Right. Interesting. So you mentioned LACMA, you talked about USC, you were living in L.A. You're from California?

Ryan: Yeah, I'm from the Bay area originally.

Suzanne: So, you were in L.A., and then you came out to New York, and you've been here a while.

Ryan: Yup.

Suzanne: It's cold here. You know that right?

Ryan: Yeah so ...

Suzanne: Not year round, but mostly.

Ryan: There are seasons. Yeah, so I went to college out here. So I was familiar with the snow. I had gone through that a few times. I really came out here for a role at WebMD. It was my first chance to work in a full product management capacity with an embedded team. Yeah, New York is really great. It's just a really wonderful mix of media and technology. I'm also still composing so it's also a hotbed of new music composition. New York's wonderful. It's got a lot of things going for it.

Suzanne: Very cool. Recognizing, and maybe it’s been some time since you've been involved in technology in Los Angeles, but I'm curious if you have any perspective on how product roles or product management, or just simply the pulse of working professionally in New York is different from your time spent on the west coast in a similar capacity.

Ryan: Yeah. So to me, the technology space within New York has really grown in the last five years. I see it constantly around me now. When I first moved out here, and especially the summer when I was out here with DreamIt, it very much felt like Silicon Alley was the term that was being used. It felt small, and niche, and sort of this tight group of start up people in the big city of New York. Now, very much, it feels like it's just another element of the city's make up.

Suzanne: We couldn't have timed that car horn any better.

Ryan: We are in New York.

Suzanne: We're truly in New York. Yeah. Right. You and I, I don't know if you know this, we have something in common, which is we have both taught product management through General Assembly. You taught it here in New York, which is where the big headquarters is, fairly recently. Are you still there? Are you still teaching?

Ryan: Yeah, yeah. I just finished up my third course there last week.

Suzanne: Congratulations.

Ryan: Oh thanks.

Suzanne: Okay, so you're still doing it. Talk about the difference in your experience between doing product management, which obviously you're very comfortable with and teaching product management.

Ryan: Yeah. So I got into teaching at General Assembly because I took a data science course there. This was when I was at WebMD and I was trying to figure out how I could better leverage the analytics that I was looking at on a day to day basis. I really fell in love with the community. I had been there, actually, during the startup that I had been working on when it was still a co working space. So we had pitch there actually. So I was aware of the space, but hadn't taken a course there until I came back. It's just such an amazing community of people who really want to learn everything there is to know about how to create products and how to create great user experiences. So I finished the course, asked how I could get more involved, and they said we're doing product management classes as well. Would you like to come teach? I've been doing it since last summer. So three classes now.

Suzanne: What was your first moment in that role, in the role of instructor, where you realized, "Oh this is different. This requires a different thing."

Ryan: I think it was when I was explaining how to stress test your hypotheses, and how to attack the problem that you're trying to solve, because I think the initial reaction when people are asked to build something is oh I have this great idea, I have an app idea, and it's essentially a solution. Talking through how to make sure that the problem that you're trying to solve is a problem, and then that there are enough people that have that problem that you can create a viable product and hopefully a viable business solving that problem, I think is sort of a paradigm shift for how people think about creating products. So for me, that's always the interesting part of the course is how you sort of go from yes, Uber is a great app, and it solves a problem. Here's the problem that Uber's solving.

Suzanne: Right. Right. Here's how you can go about learning well in advance if you're even on the right path.

Ryan: Right.

Suzanne: Yeah, no, I mean I think I have a slide that specifically says, "Validated learning is a core methodology in product management."

Ryan: Yeah. Absolutely.

Suzanne: Yeah. For me, what I have noticed is being an instructor has actually made me a better consultant in the product management space. There's one, so you know, in adult learning we have this term checking for understanding, which makes a lot of sense, but when I had first heard that term it wasn't one that was familiar, it really just means to occasionally check in with your audience and ensure that folks are tracking. Especially because this is a one to many relationship, the instructor role, so you've got a lot of folks in the class. You've got a lot of folks that are coming from different backgrounds and you're introducing ideas like validated learning and they may be radically new for some folks, so checking for understanding is a way of seeing if you need to go back and try to explain in a different way of maybe trying to explain it a different way.

I think what's interesting is when we talk about being agile, and we talk about this principle of shared understanding, how important that concept is. Have you noticed any shifts like that for yourself as an instructor where taking what you do in the classroom and then bringing it back to your role, you're a leader now in your current position, has changed how you interact with folks in a room?

Ryan: Yeah. I think that for me, teaching product management is a great way to remember product fundamentals, and to be thinking about the best way to build products. It's a reminder to me to make sure that product fundamentals are part of my day to day job. Whether that's ensuring that you are doing user testing, whether that's making sure that you're validating your market assumptions, all of that is constantly brought to the forefront of what I'm thinking about when I'm teaching. So for me, that's super valuable because it means that I am thinking about the ideal way to solve a problem, and trying not to get caught up in sort of the day to day.

Suzanne: Yeah. I share that sentiment completely, and I think it's a great luxury. If you have an opportunity, listener, dear listener, if you have an opportunity to go and study product management in school, which is a new thing.

Ryan: Yeah. For sure.

Suzanne: It's something that general assembly has certainly made possible, kind of globally. There are, of course, other organizations that are also offering variations on product management training, but I think, you're right, that opportunity to assimilate the information in a relatively controlled or relatively paced environment, and I would agree when I go back out into my world and then I'm managing products for two or three companies, consultatively at a time. Then you look at certain things and you're like, "Do we even have personas? I don't know. Just go. Just put a post it on the wall and quote somebody, and try not to forget them." It is absolutely an important set of checks and balances. I think an important reminder for anybody listening that it's not perfect, and no organization is perfect, and it's kind of like the classic, “our website sucks, but all of our clients websites are great.”

You'll come around and take care of your own stuff eventually, and so I get it. For sure. You also have been building an online product management course for O'Reilly Media. Is that available now?

Ryan: Yeah it is.

Suzanne: Tell us about it. Plug it.

Ryan: It's on writing user stories. When I started at WebMD, my boss was wonderful and realized that I didn't have any formal product management experience in terms of what's the best way to write a user story, or what's the best way to conduct a user test. He really sat me down. He made me actually write my user stories in long hand and he would come through and then correct them all, and say, "Are you actually thinking from the user perspective here? How will the engineers know what you mean in your acceptance criteria?" I always wanted the opportunity to sort of give that knowledge back. The courses is all about the best way to communicate product requirements in an agile environment through user stories, which to me are sort of like the core, writing user stories is the core skill of product management for me, personally, because it forces you to have empathy for your users.

It forces you to have empathy for the organization that you're working with, and it forces you to have empathy for the engineers and designers who you're working with to build the product that you're building. Because of that, it enables you to think about the problem that you're trying to solve from multiple angles, and I think the best product thinking happens when you are keeping in mind all of these various stakeholder groups in addition to your core development team.

Suzanne: Right.

Ryan: And user story writing helps you sort of consolidate that into a written form.

Suzanne: Yeah. Well this is, I mean I didn't realize that you were a resident expert on user stories, but now when I talk about user stories, I feel like it's fine to put you on the spot because you quite literally wrote the course on it. User stories, necessarily simple, goal oriented syntax for describing features. That's the ideas is you're describing feature requirements from the point of view of X user, from the point of view of what they want to accomplish and why. That's the high level. Then the acceptance criteria, which you alluded to, is the place where you frame the specifics. So you might include functional requirements, non functional requirements, performance based requirements. I think one of the places where individual product managers struggle or question is to what extent am I, a single person, responsible and expected to really frame up those specifics, especially if I'm not deeply technical, or I'm not necessarily design oriented.

What can you share, in your mind, about best practices for how to bring acceptance criteria together appropriately?

Ryan: Sure. I always start with the user story statement itself. That's important because it highlights the problem you're trying to solve and who the user story is going to benefit, or who's going to actually use this feature. Then, when I'm writing the acceptance criteria, I structure them as Boolean statements, so they are either true or false, which makes them easier to test, but then also build. I take a first pass at how I understand the requirements, and that's from talking to users, talking to the stakeholders, and talking to the designers is actually my first step. So I will go to the design team, say we're thinking about this problem. How would you think about it, and then we sort of have a back and forth. Then, once I've taken the first pass, the user story will be presented to the development team at our backlog grooming session, which happens once per spring.

At that point, I state the user story. Saying, "Here's what we're trying to do. Here's all the work we put into trying to solve this problem. Here are the acceptance criteria we came up with. What else am I missing essentially? Please help me figure out what I don't know." I've been doing this for five years now, there's always something new that you don't know. So having that moment in time in the sprint where you can have the engineers weigh in, also get buy in from the engineers for the problem you're trying to solve, and that it can be solved, and that there's a potential technical solution to it is very important, I think. Making sure that before the user story gets into the sprint that it’s been validated by the whole team. So that's sort of the process I go through to make sure that by the time the story gets into a sprint, it has all the information it needs to have to be a success.

Suzanne: Great. I think people approach this problem differently, including not actually approaching the problem, and being in this difficult situation of not having good stories or not having enough stories, so you're saying every, how long are your sprints, two weeks?

Ryan: Two weeks. Yeah.

Suzanne: So every two weeks there's a scheduled session in line of that to look at kind of what's teed up in the backlog and make sure that those stories are kind of ready for production, et cetera.

Ryan: Ready to go. Yeah.

Suzanne: What about kind of a more holistic release planning type of process? That sounds like it’s zoomed in pretty close, and it’s serving a purpose of making sure that items in the backlog can be grabbed up off the top and worked on. Do you have another process for, say we're going to do a significant update to our product, or we're going to create a new product that is centered around kind of the story writing, but is bigger than a sprint, if you will?

Ryan: Yeah sure. At Condé Nast we're in a continuous integration environment, so we're constantly pushing out new features. So the backlog grooming session does help to make sure that when we go into a sprint, we're able to pick off the top of the backlog and choose the stories that are going to be able to be accomplished within the sprint, but then they're also the highest priority. For the larger products, and the larger epics, typically we'll have a separate process where we're defining the successment tricks of the epic as a whole.

That will involve, again, user research, market research, making sure that stakeholders are bought into our approach and really defining the scope of it. Whether that's writing all the user stories associated with the epic and then figuring out how much time we have to actually deliver this thing, or finding out how we can define an MVP so that we can test quickly to make sure that this is the right solution before we build out the rest of the features in the epic. So that whole process is something that happens when we're tackling those larger projects.

Suzanne: Right. Why I am going so granular on these questions, this goes back to when we talk about class and kind of the ideal product management environment in the real world, and I think anybody who studies product management formally or informally hears these, or listens to this show, frankly, hears us talk about make sure you get buy in from your stakeholders. Make sure you involve people in the process, so as a mantra that sounds fine. I think where it becomes difficult is when should I do that exactly, and should that be an organized and scheduled session, or is that just me on Slack messaging so and so. I'd like to hear different people share experiences on how they organize those rituals and put structure into these necessary steps of getting by and then involving stakeholders.

Ryan: For sure. So for epics, the large projects or even the themes that we're working on, those will all be reviewed by stakeholders long in advance of the sprint that it actually starts getting built. On the flip side, the shorter features that we're putting out, whether they're bug fixes or small incremental improvements, those are approved during a meeting that we call our roadmap meeting essentially. So with our roadmap meeting, which happens also once per sprint, so the day before the sprint is about to begin ...

Suzanne: You review the roadmap every two weeks?

Ryan: We actually review it every week.

Suzanne: Every week.

Ryan: Yeah. Just to make sure that we're all aligned and that we're all moving in the same direction, and we're all agreed on what direction we're moving in. So, once a week we are going through either the current sprint or the upcoming sprint, going through the stories that are in that sprint, and then at the end of the meeting we'll actually zoom out and talk about where we are with our longer priority goals, and our epics. So we'll talk about any stakeholder, except things that still needs to happen for those larger epics at that time if it needs to happen. So, it's sort of a way for us to, we'll zoom in super narrowly and see what are we building right now, and what roadblocks are there, what obstacles do we have, but then also to talk about from a big picture where we are.

Suzanne: Yeah. No, that's so important. Talk a lot about moving between the resolutions of now, next and later. That is also one of the requirements, I think, of a product manager or a skill of a great product manager is remembering to keep your eye on the bigger picture, but then knowing when it's appropriate to really kind of get down in the, “so how quickly should the database return a response on those queries?” Excellent.

Ryan: No, that's a great way to phrase it too.

Suzanne: You brought up Condé Nast, you are a director of product management. It's a fairly new role. You were working as a product manager, so do you now manage other product managers as a part of this?

Ryan: Yeah. So actually one of the students that took my first general assembly class, I was able to get her to join. She's been with us for a year now.

Suzanne: Amazing.

Ryan: Yeah.

Suzanne: People are going to be lining up to take the class, “I listened to this Ryan guy, and he hires all of his students.” Is it, because the great irony, of course, of the product manager title is you don't manage anybody, but now you do manage people. How has that been different for you, stepping into more of a leadership role while still being a product centric person, of course?

Ryan: Yeah, I think it really ties back to the teaching that I've been doing. Making sure to focus on fundamentals at a certain level, and make sure that the whole team is thinking about product best practices. Finding moments in time when we can talk about those best practices, so maybe during daily stand up is not the best time to be saying, "Oh yeah, we need to do our user research on this before it goes into the next sprint," but finding those teachable moments and that goes for both me and for my direct report. Thinking about how we can improve our process, and how we can make sure that we're being the best product managers we can be.

Suzanne: Now, are you doing the user stories lesson that your former boss did to you? Where you're saying, "You write up all the user stories in long form and I'll come along with the red pen and edit them."

Ryan: We started there. She's doing great, so not doing that.

Suzanne: Amazing. What is the product or products that you manage in this role at Condé?

Ryan: Yeah. So I am part of Condé Nast Entertainment, which is essentially a startup that Condé Nast created a few years ago. So we're focused on everything video. We have a proprietary video player that all of the brands use, so Wired, GQ, New Yorker, Pitchfork, all use the same video player. We also have a CMS where people are uploading the videos, and then we're also syndicating the videos to a bunch of different channels so YouTube, Facebook, AOL, and then we're also responsible for a standalone app and website called The Scene, which is a video first destination for millennial females.

Suzanne: So your customers in this context happen to be some of the publications and the folks working at the publications that are under Condé Nast. So it's kind of like a B to B, to C type of ...

Ryan: Exactly. So it's like how can we make sure that we're delivering features that all of the brands need, and then how can we make sure that all of the users that are consuming all of the brand websites and brand apps are getting the best video experience that we can provide.

Suzanne: Right. I think this is certainly a challenge that has probably presented for product managers who work in B to B space is you get a great client, and then they start leaning on you to do more and more things that will allow them to better leverage the product. If you're not careful that you could find yourself doing a lot for that client and moving away from kind of the core product vision. So that's that tension of balancing, I want to make sure I'm continually delivering value and I also want to make sure that I'm not moving into custom software terrain, or into the modality of pleasing everyone. How do you personally kind of stay centered in, I'm sure, that tension that presents in your role?

Ryan: It's always about finding solutions that will scale across all the different properties. I think that's also why we have roadmap meetings every week is that there are a lot of great opportunities to work on all these different publications and we need to prioritize.

Suzanne: Right. Great. Are there any products, you talked about growth before, are there products that you haven't managed or verticals that you haven't played in, or challenges that you haven't had to solve for that you kind of are like maybe in my next iteration as product manager, I'd love to try and play in that space?

Ryan: So I've always been embedded within the media company, which I think is ...

Suzanne: It's funny that you use the word embedded.

Ryan: Yes. Generally, I have been working with how to enhance media properties, and how to think about new forms of media essentially. I think that there are continually new areas of growth in media, whether that's AR, whether that's VR and so I'm always trying to think about what's next really, and how are people consuming content, and how are those usage patterns varying even. So, for me, the next thing is what's next in media?

Suzanne: Right. So you want to stay in this space? You love it.

Ryan: Yeah, I love the media space. My undergrad degree was in music and literature, so it was very media focused. Thought that I was going to be writing music or writing some form of text, and now I see my role as figuring how to make sure that that media gets distributed to as many people as possible that want to access it, and then can also just sort of reimagine media experiences.

Suzanne: Right. We talked earlier about pivoting, and I like this aspect of your story. It's advice that I've offered to folks looking to get into product is when we talk about a pivot, it's like some things change, or one thing changes, and some things stay constant, and it sounds like your career has been the constant is I just want to be in this industry, and then wherever I go and work, each company will have its own objectives and its own sort of look and feel, and different things going on, but I'm in this space.

Ryan: Yeah. I do love this space.

Suzanne: That's your constant, your North star. All right, we do a segment called "Get the job, learn the job, love the job", what advice would you offer, Ryan, to product managers listening in? What advice do you offer to your students when the 10 weeks is up and they're like, "This has been really great, now how do I get a job," assuming you're not hiring.

Ryan: I think it goes back to what we were just talking about. It's finding a problem that you're super passionate about. That's so important because product is about learning everything you can about your problem and finding solutions from there. My advice is always find a problem or an area that you're super interested in. That you'll do anything you can to either fix this problem or to get involved in, in finding a solution for this problem. Start playing in the space. Start meeting people that are trying to solve this problem, or who are in this space, and start figuring out how you can get involved.

Suzanne: What about the hard parts? What about where you see folks struggle or fail, again we talked about the perfect environment of learning versus the actual environment of doing, so where have you seen that gap go from, "Now that I'm not in the classroom, or in this perfect environment, this is a lot harder," specifically.

Ryan: I think one thing that happens once you're in an organization is that in addition to all of the user goals, there are also the organization's goals. So figuring out that balance of how you make sure that the business needs are met, while making sure that the user needs are met can be difficult, and you have to really iterate your way there often. You have to, again, think about the problem from multiple perspectives. So, I think the sooner people can start getting into an environment where they're thinking about the problem from all these different viewpoints, the better.

Suzanne: What do you love about product management?

Ryan: I love that there's always something else to learn, whether that's a new technology, or a new entry into the space I need to learn about, or a new business problem. I feel like I'm just continually, if you've seen the Matrix, there's that point in the Matrix where he's getting embedded with chips and he's like, "Now I know kung fu." That's how I always think of leveling up in product management. There's always something else you need to level up in, so you're continually growing in that, and I really love that aspect of it, and you're solving problems and making things. So, what's cooler than that?

Suzanne: Absolutely. Agree. Do you have any recommended resources that we can add to our website? Blogs, podcasts, individual thought leaders, just anything that you think is required consumption.

Ryan: Sure. So my go to was Benedict Evans, but I saw Benedict Evans was on your blog, also awesome is Stratechery, which is a blog by Ben Thompson. It is a subscription, but there's also a free tier, and it really looks at the technology industry from a macro perspective. It has a really good take on where the industry is going, and what sort of forces are at play within the industry. So I've always found that to be a really valuable and fascinating resource.

Suzanne: All right, last question, do you have a personal or professional mantra, philosophy, something that guides you through this world, that you want to share with our listeners?

Ryan: Yeah. So I think learning and making sure that you're in a place where you can learn, and also trying to have empathy for everyone around you, and anyone who's interacting with what you're working on. For me, those are kind of the two constants that I try to use in my daily practices. What am I learning, how can I use these learnings to better improve what I'm doing, and then what user group am I not thinking about, and how can we make sure that we're solving that person's problem too.

Suzanne: Beautiful. Ryan Harper, Conde Nast, thank you so much for being part of our show.

Ryan: Thank you.