Transcript

Ruiyan Xu: I don’t love the weeds. Don’t tell my clients, but I don’t love Jira tickets, Gantt charts. Spreadsheets are not my friend.

[POSTLIGHT INTRO MUSIC]

Chris LoSacco: Welcome to the Postlight podcast. I am Chris LoSacco, the president of Postlight. And joining me today on the show, very special guest, Associate Director of Product Management Ruiyan Xiu. How are you, Ruiyan?

Ruiyan: I’m great. How are you, Chris?

Chris: I’m great. So you wrote an article for the Postlight website, our Insights section, a few months back, about the difference between product managers and project managers. And you used an amazing analogy, which I love. I love using analogies in general to describe the landscape of technology and software. But you likened it to two different kinds of ship captains. And so I would love if you would just start by describing the sort of high-level difference, and then we can dive into it here it on this episode.

Ruiyan: I mean, when trying to figure out something confusing, use a metaphor.

Chris: Exactly.

Ruiyan: That’s kind of my rule of thumb. Love figurative language.

Chris: Totally.

Ruiyan: So, product management and project management, frankly, very very confusing. Both are called PMs, and, you know, people even in our line of work, as well as people outside of our line of work, confuse the two constantly. 

Chris: Mhm.

Ruiyan: Which is totally okay. But I think they are, to use my analogy, two different types of captains, but both very important when you are sailing off. For the project manager, I liken that to a captain of a ship that already knows where it’s going and already knows what vessel it’s taking. So, you know, a cruise ship from New York to London. Let’s say the path has been charted out already. You still have to make a lot of decisions as the captain. You have to kind of adapt to the weather, see what’s on the horizon, maximize speed, utilize your crew.

Chris: Yep.

Ruiyan: But you know where you’re going. You know what the basic expected timeline should be, and you just, you have to get there.

Chris: I just want to pause. It’s still a really important job, right?

Ruiyan: Absolutely.

Chris: And I think you’re making a great point that there’s still a lot to deal with, there are still unknowns, there are still challenges, you’re still running a crew. Like, all of the operational needs of fulfilling your voyage, so to speak – you know, getting to your destination safely and on time and all the things that come with going along the path – just because the path is well-defined, you know exactly where you’re going, it doesn’t mean that that’s an easy job, necessarily. There’s still a lot of work to do.

Ruiyan: Absolutely. There’s a ton of value in project management and every project probably needs a project manager. Whether that’s shared between the product manager or there’s two separate roles, that depends very much on the project. But you can’t not have those functions fulfilled. It’s an incredibly important job that helps your crew and your voyage get to where you need to go.

Chris: Okay. So now, contrast that with a product manager and how that’s a different type of captain and a different type of voyage.

Ruiyan: Absolutely. A product manager is a little bit more captaining a voyage into the unknown. So, that route hasn’t been mapped out yet, that route isn’t clear. You don’t exactly know where you’re trying to get to. You have a general sense, but you are sailing on a maiden voyage, let’s say. So you are, you know, even before you show up at the ship you’re doing a lot of preparation about what is it you’re trying to get to, why are you trying to get there? You get to make decisions about, is this a cruise ship or is it a racing yacht? Or is it something in between? You get to decide, how many crew members do you want to bring along? And what do they need to be good at? And that will very much depend on where you’re trying to get to. And then you get to chart the route a little bit by yourself. Are you, you know, sailing… I don’t know, by the Bermuda Triangle, or are you trying to avoid it…

Chris: Yeah, yep, yep, yep.

Ruiyan: To get where you need to go. So it’s kind of a vast-er playing field, but yeah. You are trying to get, again, your crew and your voyage to somewhere that’s a little bit more uncertain.

Chris: It also sounds like it starts much earlier in the process. You’ve gotta have your product manager involved way earlier. Much, much more in the beginning when you’re deciding… I mean, if we play out the analogy, this is when everyone’s at the table trying to decide, where are we going? And you’ve gotta have someone who’s invested in that part of the process and not just saying… ‘cause in order to do the things you’re describing, right? Choose the ship, assemble the crew, be able to react when things come up, these are all things that you need to discuss and be on the same page about well ahead of, you know, actually setting sail and getting out on the open sea.

Ruiyan: Yep. The starting line is much earlier for the product manager on the voyage. They need to have a seat at that table full of stakeholders, and give a lot of input into all the decisions that you’re talking about that need to happen well before you start sailing. Whereas, for the project manager, you can show up much closer to your sale time, and just kind of show up and know that you’re going to execute on the route that’s already mostly laid out.

Chris: Do you feel like there’s a difference in personality type that you need to be these two different kinds of captains?

Ruiyan: I think so, and maybe this is some of my bias, because I’m a product manager rather than a project manager. To me the personality type for a project manager, which again, very necessary, is somebody who is extremely good at details. Just very, very operationally and executionally minded. Someone who likes to be in the weeds, who is kind of constantly understanding – you know, I’m not a sailor, but how many knots you’re going and what the weather in the next 90 minutes is going to be. Whereas, to me, the product manager captain is somebody who’s operating at a higher altitude, and who kind of defaults to see the forest rather than the trees or the weeds. Who has their vision set on the horizon, rather than, you know, the knots per hour.

Chris: Mhm. 

Ruiyan: Or so on. So, those would be the personality types.

Chris: That makes a ton of sense to me. If I’m, you know, the person who is making the decision to charter one of these voyages, what are the things that you would look for, that you would advise as you sort of bring on the right kind of captain? Like, it sounds like you’re saying “Let’s figure out how we ask the right questions about what we want and where we ultimately want to end up, so that we get the right person who’s then going to potentially challenge us to be at the table, to pick the right destination,” versus “We have a very clearly defined thing that we’re aiming for and we just need to go get that thing.” Does that make sense?

Ruiyan: Absolutely. I think you’re exactly right, and I think the level of definition versus the level of ambiguity is really how you can make, like, look for the right person. So if you have a voyage that’s very defined already, and you want someone to just run it smoothly, get it there on time and, frankly, on budget as well, you know… and operate at kind of the right pace but also triage anything that comes up, then you are looking for a project manager. So for software projects that looks like, you know, a well-designed scope of work. You understand what you’re trying to accomplish, you probably have some ideas about the technologies that you’re using, maybe you have a visual design brand that you want to tap into…

Chris: Yep.

Ruiyan: And you have a clear idea of what the product is, why it exists and how to execute it, so you hire a project manager to help you just run it.

Chris: That makes a ton of sense. In your experience, have there been times where a project kicked off and it looked like you needed a project manager, and then partway through you realized “Oh, we were aiming at the wrong thing and we need to now change course”? 

Ruiyan: Absolutely. I mean, I think that happens all the time. Many times stakeholders come into projects very opinionated. And with a very clear sense at the beginning of, for example, what features need to be built.

Chris: Oh yeah.

Ruiyan: But part of our work as a product team is to take several steps back and make sure we are aiming at the right things. Which means really getting clear on what the definition of success for a product is, and what the outcomes you want to be, and how the product is going to impact the business. And so, sometimes it’s the case, you get into a product, you know… the stakeholders want you to build, build, build, and your goal as the product manager is to have those bigger conversations, the higher-altitude conversations to really understand what they’re trying to achieve rather than just execute on schedule. And as you start to have those conversations, some of those questions and, frankly, conflicts between different stakeholders on the same project will start to emerge. When suddenly, you think “Oh, we’re actually sailing to the wrong part of the land. We’re actually, we should be sailing somewhere else.”

Chris: Right.

Ruiyan: And, I mean, those are… those can feel really painful in the moment, because it feels like you’re taking three steps back. But ultimately it’s so important to have those conversations as a product manager. To really understand what you’re trying to achieve and make sure you are aiming at the right thing.

Chris: I wanna break down what you just said, ‘cause I think you said a lot of really good things. The first one was, you talked about outcomes, what someone is trying to accomplish for their business, what impact it’s going to have beyond, like, a list of features, or a set of capabilities that they’re offering. You’re talking about business change. And I think that’s really interesting, because not a lot of people connect the word “product manager” to the word “business outcome.” But that is really what differentiates a product manager, I completely agree with you. And I think the best product managers are thinking, “How am I orienting what my product is doing to some bottom-line change to my company, to my business?” And it’s been said that sometimes the product manager acts as, like, a mini-CEO. And I think it’s very much about this idea, that ultimately you’re thinking about a business outcome. And if that means that the stuff has to change, right? The features or the implementation or the design… as long as you’re thinking about “What outcome are we trying to get at?” that is product strategy, that is product thinking. I think it’s a really good differentiation, versus, like, “I’m executing on a list of features,” which… there’s value in that, but it is different. It is, you know, it’s only part of the pie. You also said something about pain when you have to change, when you realize partway through, and I wanna come back to that. But on this idea of business outcomes, you know… what’s your take on measuring something and evaluating whether or not you’re succeeding at the goal that you wanted to aim at, right? In the ship analogy it’s, how do you measure whether or not you’re on course? And if you have to course-correct, how do you measure, you know, against the new course? ‘Cause I think there’s a lot of different takes on this, right? Some people are very, very into data and analytics, other people are more into, you know, the sort of qualitative measures, or really touching base with their stakeholders. I’m curious what you would say as to, like, how do you judge if you’re on course or not?

Ruiyan: That’s a really good question. That’s a really hard question, especially when you are charting a voyage to a little bit of the unknown.

Chris: Mhm.

Ruiyan: And my answer here is, it’s partly a science and it’s partly an art. There is absolutely room for data. You know, ultimately as a project manager you want to understand that company as kind of like… how it impacts the bottom line, what are the OKRs that you might be aiming for, what is going to make a business impact. So having those defined and prioritized from the top, and really connecting the product to a set of measurable goals, is incredibly important. At the same time, very early on in the product process it’s going to be really hard to connect your kind of MVP version with barely any features to the OKRs for Q3, or something like that.

Chris: Yes.

Ruiyan: And so, as a product manager you have to rely a little bit on your point of view, your instinct, your experience, to know that even though you can’t quite measure it by data just yet because, you know, you’ve got a minimum set of internal users for this thing that’s shipped but doesn’t maybe do anything because you’re eight weeks into the project…

Chris: It’s brand new. Yeah.

Ruiyan: And it’s brand new, exactly. But you’ve gotta have that instinct, which I think you can develop over time, of like “I think ballpark we are going in the right direction.” And then you have to constantly assess and reassess as you go further into the voyage of, are you aiming at the right thing? And eventually you’re going to get to that point where you can see land up ahead, and you can start to measure things. But the measurements aren’t always available for you at every step of the process. 

Chris: That is such a good answer. I do think there’s a time and a place for, you know, taking organization-wide OKRs, right? Objectives and key results that are set at the very high level and then figuring out how to translate them down into quantitative measures that you can take, where you can say “I’m looking at pageviews or time on page or user sessions” or whatever… you know, whatever the thing is that you can ladder up to a larger business goal in a very numbers-based, you know, it’s rows in a spreadsheet kind of a thing. You’re putting it on a dashboard and you’re presenting it to your key stakeholders every quarter. That is… I’ve seen that work. There are times when that is very helpful. Again, I like the way you put it, right? When you can see the land, and then you can start to triangulate, I think that makes a ton of sense. There are also times when you’re out on the open sea. And you’re like, “We just don’t know yet, and so we have to rely on a little bit of opinionated decision making and taste and gut feel.” And this is where, you know, designers are worth their weight in gold, and lead architects are worth their weight in gold, because you bring together really high-functioning teams, and you say “Here’s generally where we want to head, let’s put our brains together as product strategists and designers and engineers and get the boat rowing in the right direction.” Or get the boat sailing in the right direction. And knowing that we’re going to course-correct as we get a little further, you know, down the voyage or whatever.

Ruiyan: Yeah. I mean, I think that’s exactly right. And as you were saying that, it occurred to me that every branding product is a bet. It’s a risk.

Chris: It’s a bet! A hundred percent.

Ruiyan: And there’s no guarantee that that’s going to take off… to completely pay off. It might. It might not. You’re taking a risk, and with risk comes reward, but also with risk comes the possibility of failure, and all you can do is crew your boat with the best people possible, with people that you think are going to help you succeed and get to the right point. But the truth is, you know, as much as we’d like to make everything safe and risk-free, if you’re building a new product, that’s just not possible.

Chris: The world doesn’t work like that. That’s right. When you’re doing something new you are taking risk. And it’s our hypothesis, right, that businesses need to take these kinds of risks, right? Otherwise you’re just making incremental change, at best, to what you already have. And we’ve worked with a lot of organizations, large and small, where they have a lot of, say, legacy technology, or a lot of these old… old habits die hard! The old way of doing things…

Ruiyan: Yes.

Chris: Where yes, you can improve things, maybe 2, 3, 5%, but that’s not going to get you the kind of generational change that you need. Sometimes you need to say “I’m going to set sail for a brand new land, and I know that nothing is assured. But the possibility that we could find, you know, this brand new place…” Maybe the analogy’s breaking down a little bit, but…

Ruiyan: (Laughs)

Chris: You know, you have the opportunity for something that is, you know, much greater. A 50 or 100 or maybe 1000 X improvement over what you’re doing today. And those kinds of changes don’t happen by looking at minor updates to existing platforms where it’s rows in spreadsheets. Like, it just… it’s a different kind of approach, and it requires a different kind of PM. I’m being purposely vague, right? Because a project manager can be really good at saying “I need to eke out 3% more efficiency,” where a product manager’s going to say “I’m going to take you to someplace unknown, and there is a… there’s a chance it doesn’t work. But we’re going to take the risk together, and I’m gonna do everything in my power to make sure that it… we give ourselves the best possibility of this paying off.”

Ruiyan: Yeah, absolutely. And I think those are the kinds of projects that Postlight’s really good at, and that we take on and do everything we can to kind of chart the new courses. It’s not always easy, and I think a good product manager expects resistance, expects things to be hard going sometimes, because change is hard.

Chris: Yeah. Well, say more about that. What do you mean by “expects”… expects resistance where? From whom?

Ruiyan: You know, maybe from some of the crew who are used to sailing on the set path over and over again…

Chris: Mhm. Yeah.

Ruiyan: They know that path well, they… you know, do it well. They know exactly where they’re going. And so when you bring some of the crew, let’s say some of your stakeholders, on to open waters and you say “We don’t really know where we’re going, but we’re gonna do everything we can to get there, but your job function might change, and what you do so well? We might not need that in the long run.”

Chris: Yes.

Ruiyan: So, a good product manager should expect that, and then kind of work to build a vision of what that land in the open waters where you’re going that’s unknown… you should build a vision for what that could look like…

Chris: Absolutely.

Ruiyan: And why it’s so important to bring all the different groups together with you.

Chris: Great point. And I… this idea that the path is going to include resistance, so you should just expect it, and not treat that as a sign of failure, or that you’re going in the wrong direction necessarily. That’s a really great lesson, I think, for product managers to take to heart, which is that there are going to be hurdles along this path, and you’re gonna have to overcome them. And trying to see them as best you can and then build them into your plan is a great piece of advice. I would also… I’m curious to get your take on scope, right? Because there’s an implication here that product managers have to be a little more willing to adjust on the fly, versus a project manager who might say “Well, this is not in my pre-approved list of features and so we can’t do X, Y or Z.” Do you feel like that’s another distinction between the two, is how they deal with changes in scope?

Ruiyan: Yes. I think for project managers, changes in scope tend to be fairly small, and they are looking at this rows in the spreadsheets and saying “Oh, can we expand this a little bit and shrink this a little bit?” But everything sort of has to fit into that journey you’re already on, and you’ve got to get there by the time that is on the timetable. Whereas for product managers, you have more time and you have more room to play, but you also have a lot more ambiguity, in a sense.

Chris: Sure.

Ruiyan: And I think sometimes you do have to make some of those… or try to make some of those really difficult decisions, and say “This feature is actually not helping us towards our ultimate goal.” Or, “This feature that’s really important to two stakeholders? It’s actually just edge cases. We’re not serving the majority of our users, and we’ve gotta get rid of them.” Which is going to be a painful conversation. But hopefully the product manager is empowered to have those conversations and make those decisions and convince everyone of the necessity of making those decisions, because… I’m gonna change my analogy a little bit here.

Chris: Go for it.

Ruiyan: If you’re… if you’re a racing yacht and then you suddenly take on all this extra weight and everyone brings their bags on board, and there’s… you’re bringing more and more bags, like… you can’t sail at the speed that you need to sail at. And eventually your yacht is going to sink. (Laughs)

Chris: (Laughs)

Ruiyan: So you gotta… you gotta throw some of those things overboard, or leave it at the shore…

Chris: Yes.

Ruiyan: To operate at the speed and with the kind of intensity and efficiency that you need to operate at.

Chris: Yeah. Do you feel like you can decide what’s important to you, though, on your voyage? Like, what if time is really the limiting factor, you know? What if you say “I’m okay with not knowing exactly where we’re going to end up, but I really need to limit this to, say, six months. Or three months.” Or whatever the time frame is. Do you feel like that’s a workable structure for a team?

Ruiyan: Absolutely. And I think that’s a really common case, and in some ways I actually think the limiting time can be incredibly productive for a team. And it’s one of the reasons that sometimes it’s very useful to bring in an agency like us, like Postlight, rather than having your in-house team build. Because we are usually on a timed contract, and we need to deliver something by a deadline.

Chris: Mhm.

Ruiyan: And the reason I think that can be productive is that, I think having time be your… be part of your north star can prevent bloat in your software. And can prevent all those features, all those edge cases that, you know, are ultimately not going to help you deliver on your business outcomes. It is time and the need to meet a deadline is something that you can always hold up as a product manager to your stakeholder, to your client, and say “If X then we are not going to meet this timeline. If we include this, then we are not going to meet that timeline.” There is no give there, you have to cut scope, you have to throw the luggage overboard to make the timeline. And if you make that part of your guiding principles, it will get you there faster, and one of the nice things about getting there faster or getting there on time is, then you’ve charted the maiden voyage and then you can go back and forth again. You can go there again.

Chris: Yes.

Ruiyan: You can release future versions, you can keep building on top. But you’ve charted back first, and you know that you’ve gotten there. So I think, actually, building by the timeline is incredibly practical.

Chris: The idea that once you chart the path it gets easier for future iterations, or future times that you have to sail that same course, is totally true. And I think that that plays out in software all the time. Where, getting the first release out there is sometimes the hardest part. And if you embrace your constraints so that you get that first release going, and get that ball rolling down the hill sooner rather than later, all of the subsequent releases get easier. There’s also, there’s a team dynamics part of that too, right? Because the team starts to know how to work together, right? In the ship analogy, the crew starts to get a sense of, not just where you’re going but how you’re getting there. And if the how gets easier, then you get more power and more, you know… you can be more nimble as you go through future releases.

Ruiyan: Yea. Absolutely. The first release is the hardest, and so, cut scope if you must, but get it… get it out there.

Chris: Get it out there. Right.

Ruiyan: Get a ship.

Chris: We are big believers in working software. So… let me ask you this. What if there’s someone listening, and they’re like “We think in a project management mindset. My organization is all about having no unknowns and making sure that everything is really clear, and then having people who make sure every Jira ticket is captured, and all the trains run on time, and as a result they’re not doing anything innovative. They are not taking the risks that they need to take, and they are perhaps saddled with a bunch of aging technology and an older platform that they really can’t get on the other side of.” What advice would you have to make that leap, and to start thinking in a more product-oriented way versus a project-oriented way?

Ruiyan: I mean, I think this is a really common dynamic, and I think this is not something that we should be blaming those existing teams for. They are just fulfilling the mandate they’ve always been given. And I would urge them to listen to a Postlight podcast about, I believe, innovation inside big organizations?

Chris: Mhm.

Ruiyan: Maybe hosted by Chris and Gina? Which I found very helpful. It’s hard. It’s hard when you have a certain job function and when you need to keep the trains running on time, or the ships running on time, to also be thinking about innovation. The short-term payoff of kind of having those things run on time is, in some ways, a blocker for going into another lane and thinking about the possibility of the open seas.

Chris: Totally, totally agree. I don’t mean to interrupt you, but I think that is a fantastic point, that you can trick yourself, actually… and I don’t mean any particular person, I mean an organization can think “Wow, we’re really good, operationally, at getting a lot of things done. And we’re really good at making the list of features that we’re gonna have, and then, you know, by the end of the quarter all those features are checked off, and so let’s pat ourselves on the back, we’re doing really good.” And then sort of wake up one day and feel like “Oh, my competitors are passing me by.” Because we’re just doing what we’ve always done. And the reality is, you can lull yourself into a little bit of a false sense of security, because the reality is, all businesses need to be thinking about what’s next, what’s ahead. And how do I make sure I’m taking those calculated risks that let me experiment with where my market is going, not where we are today and where we have been? And I think you’re a hundred thousand percent right, that you can miss that if you’re thinking too much about making sure every check on the checklist is complete. It was the point you made before about the altitude question, right? If you’ve got a project management altitude where you’re always on the ground, you need to encourage your teams and your organization to come up a little bit and look at it from 10,000 feet, and say “How do I make sure I have the lay of the land here, so that I can make some of those calculated bets?” So I just wanted to emphasize… I thought you said something really great there.

Ruiyan: I think, if you want to do that there’s two levels at which you have to operate. There’s strategically, you have to reset what you’re focused on. By which I mean, your OKRs can’t be about the number of Jira tickets closed, or the fulfillment of the checklist, right? You have to reorient your company goals and OKRs and all the things you measure into different goals that really make an impact on your bottom line, on your high-altitude business outcomes. Rather than the, you know, “Have I checked this off? Are 99% of the ships getting to port on time?” That’s the strategic level, and then there’s a very practical level, how do you get people to do that? And I think you have to identify people within your organizations that are capable of looking at the higher altitude, and you have to relieve them of the day-to-day responsibilities of running the ships on time, and allow them the space to think about the business outcomes, the uncharted waters. Or… you know, sometimes the easier and more efficient way is to hire an outsider to come in and to really provide you that kind of dose of momentum and acceleration that you really need to take some of those risks, and hopefully get rewarded for them.

Chris: I’m reminded again of a point you made in your post, which was “You have to come in with a point of view.” And I think what you’re describing is that, is whether you are redefining someone’s job that you have internally, or you’re bringing in an agency like Postlight, we have to come with a point of view. Or that person has to come with a point of view. So that you are making a decision to go somewhere, to take that bet. Because if you don’t, if you’re coming in saying “I’m just going to throw a dart at the wall,” then it’s not worth it. And you’re not maximizing your chances of doing what you’re about to do. If you’re going in blind, it’s far more risky and far less likely that you’re going to get a return on whatever it is you’re doing. But if you’ve got a particular slant on something and you’re like, you know, “I’m thinking we should go in this direction for these reasons,” it can be so much more impactful, and your chances of success, your chances of a return go dramatically up. That is product thinking. That is internalizing a business need and then figuring out how to go after it by creating software. I think it’s a key differentiator when you think about “What makes a product manager really good and really effective.” I also want to ask the other question, though. What happens when you need good project management help? Because this happens too, right? Sometimes you actually can make a pretty good strategic bet, and say “I think this is where we need to go,” but then it just doesn’t… it doesn’t work effectively, right? And I’m curious to know, like, how would you attack that problem? Making sure that the project management is happening really good?

Ruiyan: Project management is the foundation of everything, whether you’re sailing the course that you know or you’re sailing into the unknown, you cannot have good product management without at least adequate project management.

Chris: Yes.

Ruiyan: And it’s sort of my opinion, speaking of opinionated, that in order to be a good to great product manager, you have to have decent to good project management skills. And this isn’t something that, frankly, has always come easily to me. I don’t love the weeds. Don’t tell my clients.

Chris: (Laughs)

Ruiyan: But I don’t love Jira tickets…

Chris: Wow.

Ruiyan: Gantt charts, spreadsheets are not my friend.

Chris: Okay.

Ruiyan: You know, I haven’t always been somebody who has been super great at the details, in my career. But I have gotten good enough at them. I have learned that this is a skill I need to build up, and I need to care about the details, because the devil is in the details.

Chris: Yep.

Ruiyan: And your stakeholders really care about the details. And you cannot build that sense of trust and assurance in the voyage if you are not getting the details right. So, for a product manager, whether it’s that you scale yourself up in everything from, you know, writing a good ticket to understanding who needs to be in which meetings because they have a say in this decision versus that decision… whether you scale yourself up in that, or you bring… on a large enough project you can bring in a project manager who can support, and the product manager and project manager can work in conjunction to make sure everything has both the vision and the execution, you know, that’s up to the project, that’s up to the person, but you absolutely need good project management skills to run a project well.

Chris: I’m also, I’m hearing a sort of subtextual theme in what you’re saying, which is communication and how critical that is to project management. And while I’ll take you at face value that you don’t love Jira tickets and spreadsheets, I know for a fact ‘cause I’ve seen you do it that you are an exceptional communicator. And so, it seems to me like that is a common thread as we look at great project management and how it’s the foundation, you know, that project strategy’s sort of built on top of. The communication has to be there in any scenario. And if there’s one skill that we can suggest that people make sure is there from the very beginning, it’s really really good communication. Both internally and with your stakeholders.

Ruiyan: Absolutely. I mean, if we go back to the captain analogy, a captain can’t get her crew to be working in sync and in the right direction unless she is communicating clearly and effectively with everyone on board.

Chris: You got it. That’s right. I think that’s a great place to end it. I do wanna put out there, if you are listening to this and you are thinking “Man, I am just… I am not sailing in the right direction. I am going off into a haze and I don’t have a clear sense of where I should go,” or maybe “I’m not meeting my time commitments or my budget commitments and I could really use a helpful ear to listen and help,” we would love to be that ear. Please reach out to us, hello@postlight.com. These are the kinds of conversations we love to have. We love talking about project management and product strategy and how the two come together to make great software. Ruiyan, thank you so much for coming on and chatting about this. We have to do it again soon.

Ruiyan: Thank you, Chris.

Chris: Alright. Bye, y’all.

[POSTLIGHT OUTRO MUSIC]