Get in touch

Postlight joins Launch by NTT DATA! Learn more.

This week Chris and Gina sit down with Nathan Henry and Vicky Volvovski of Postlight’s PM leadership to talk all things product management at a client services firm. Nathan and Vicky share ideas on building lasting client relationships and break down how to structure client workshops to get at the root of the problems you’re trying to solve. Then, they discuss what questions you should be asking to gain trust and encourage your clients to open up.


Nathan Henry On one of our accounts that we have now, there’s a lot of acronyms. There’s a lot of internal words and there were things that sound really bad. And so they mentioned this one particular phrase, and I’m like ‘portal burning’ sounds really awful. Like, please tell me how we don’t do that. [Gina laughs] And they looked and like, ‘No, no, you we want that. We want the portal on fire.’ And I’m like ohhh that’s a good thing!

Gina Trapani That’s a good thing! [music ramps up, plays alone, fades out] Hello!

Chris LoSacco Hi!

GT This is the Postlight Podcast!

CL Yes it is!

GT We’re not Rich and Paul. 

CL We’re not. [Chris & Gina chuckle]

GT I’m Gina Trapani. And I’m joined by—

CL Chris LoSacco.

GT And we thrown Rich and Paul out of this room.

CL Unceremoniously. 

GT Yes, we’ve taken over the recording studio. There’s a lot of throwing Rich and Paul out of the room going on in last few months. 

CL That’s true. 

GT And we’re taking over the show today. I’m very, very excited to have this conversation, because we’ve got two fantastic guests, right from our very own team in the room here with us. 

CL Would you like to introduce yourselves? 

NH Sure. Nathan Henry, Associate Director of Product Management, first time joiner, longtime listener.

GT Welcome to the podcast, Nathan. So glad you’re here. 

Vicky Volvovski Hey, everybody, Vicky Volvovski here, the Senior Director of Product here at Postlight. I think this is—or I shouldn’t say I think —I know, this is my second appearance on the podcast, but still feels weird.

GT It’s so good. We’re all here in the same room together, which is very exciting. I’m also a little bit intimidated, because I have all the leaders or product management past and presence at the table here. I don’t know anything on product management. So I’m gonna play dumb. I’m gonna ask a bunch of questions about what this is here, especially at Postlight, which is a kind of a different setup for products.

CL It really yeah, I mean, we are, we’re a client services company, which means we work for clients. And I think that has a lot of benefits. And some kind sort of interesting things you’ve got to consider when you were working on client work versus working on product work. And, you know, maybe we can start there. I’d love to hear from both of you. What do you think about when you’re thinking about agency work to start and you know, what’s good and what’s bad?

NH I think the for me, the thing that I’ve gotten my head around really quickly, in sort of my eight or nine months here is, the first thing that we deliver a product management is the relationship like that is the deliverable. And then we maintain that throughout the course of it, it isn’t just the software, it’s the actual building trust and relationship with the client and the client team. And really hearing their goals and their needs and figuring out how we can best support them. Sometimes the work is a little bit ambiguous on purpose, because we need to find the best way to make the fit. And that has to come from developing quick, long lasting strategic relationships to really understand the needs, the challenges and how we can best support what they’re looking for. So for me, that is the biggest first difference that I would say in terms of product here at Postlight, it isn’t just the work. It’s how you get the work and how you build that relationship to build that very good product that’s the right thing.

CL How do you do it, Nathan? Like you said, understanding the goals, yes. But is it you know, exercises that you’re running? Or questions that you’re asking? Or like how do you get to the root of what the client needs?

NH Sure. So for me, I don’t think there’s a dumb question. I think you just have to start from ‘I don’t understand, please explain it to me’ and cut through sort of any business jargon, any sort of internal politics that you might be hearing from the client side, and really just focus on what are you trying to do and tell me what you’ve done to try to get there before. Sometimes they’ve made efforts. That’s why they’ve maybe called Postlight is they weren’t successful. So what did you try? Why did it fail? Like, tell me a little bit about that? Like, how did how far did you get? What were your stumbling blocks? And really understand did they lose sight of the goal? Or did they just not—were they not able to fulfill it with their own team or their own strategy? Like why did we get the call? I kind of want to understand that without asking that question. Like, why did they pick up the phone—or I guess I’m old. Why did they email and to understand how we can best help. So really understanding that comes with just a lot of questions and making partnerships and just showing that you’re not here to like step on their toes, you’re here to help. And really just making friends like up and down the entire—every time you meet someone, your goal for that call is to make them trust you and believe that you are there to help by leading with honest truth and questioning, like, you know, understanding what their business is.

GT Every PM in the world has stakeholders, right and has to build relationships with those stakeholders and deliver and show the work and what’s happening. And that client relationship is similar but also really different than an in house stakeholder. What are the biggest differences for a client working with post live versus you know, your PM in house and your stakeholders are like the CFO and other folks in house that you’re all employed by the same company.

NH I think time and access, you have to maximize your time. You might get an hour a week maybe you get an hour a month, but it depends on you know, schedules. I spent a lot of time strategizing what that meeting could look like. I also spent a lot of time of what the meeting could look like from a negative lens like what if these particular things happen in the meeting is going poorly. It really role playing do my very best work on the computer and thinking around like, if this happens, how do I approach it? If this conversation turns south, like how do I save it, it really just prepare for all sides. And just so you’re not surprised. I always want my goal is when I ask a question, I know the next question I’m already going to ask, depending on that and an AB test almost, have your flowchart of which way the question goes. [Gina laughs]

GT If yes, then…

VV Yeah, now I feel very underprepared. Because I definitely don’t do that level of kind of thinking through the direction it’s going to go. I mean, I think a lot of what you said Nathan resonates. For me, the question that I always kind of come back or try to start with client is, what does success look like? It’s kind of a silly question worded that way but I think as you kind of build the relationship understanding, like, what is it that this person or this organization or this team or whatever level you’re at, what is it that they’re looking for? And then you kind of start digging in, digging in and the product strategy evolves and kind of comes to life from understanding that. It’s often the first answer often isn’t the actual answer. And so that ability to keep digging and understanding, usually uncovers some really interesting insights. But I don’t always know what the next question I’m going to ask is.

NH I’m not always right, I just have a bank of what i what i i don’t like to be unprepared, I am super prepared. And like such a creature of habit that I have to know like, what’s possible. So I’m not taken off guard. That’s just something I do. Not everyone certainly can be, as, you know, OCD, maybe as I am, but that’s what I lean into to help especially when it’s challenging. Sometimes, you know, the answer is clear, sometimes the meeting isn’t so tricky, you have an idea, or the product you’ve worked with before our company you’ve got experience with but if it’s completely new and new territory, I really want to make sure that I’m asking the right questions. And I get out of that meeting, the insights that I need, again, that 60 minutes flies fast, you’ve got to do intros, you have to be kind, you have to allow people to speak, there’s always interruption. So you have to make sure that you can front load for targeted questions that really uncover at least the next person you could talk to you or someone else who might have an hour for you, you have to be very strategic. And I’m kind of going I’m really focusing on like kickoff and really understanding like, what the problem is that we’re trying to solve, the early days of those meetings.

CL Yeah, I mean, I want to go back to some things that Nathan, you know, if it’s new, we need to prepare a little more, we need to dive a little deeper. That’s really interesting when you think about an agency PM versus a product PM, because an in house Product Manager is thinking about just their domain. And when you are an agency PM, you may get staffed on, you know, a gaming project or a new publishing platform or an insurance company website. Like it’s just very, very different. So when you are getting up to speed like where do you start? How do you—especially if you’re going into a new industry, where you’re not familiar with something, like how do you walk into that room prepared with your questions, as you were saying?

NH Yeah, so to develop some user based knowledge. So I’m working currently on a migratory bird platform, and I’m not a birder. I appreciate birds very much, but I don’t know. But I knew people who were active birders, you know, weekend kind of warriors with binoculars, I thought, well, let me just ask them, like, what’s important to you? Tell me a little bit about this culture, I wanted to understand their mindset of tell me the passion. Tell me why did you enjoy this, I want to learn, I want to understand from the user’s lens, you know, kind of go to this user persona, like, why is this interesting to you? How did you get involved? And it really didn’t even focus that on, like, the work that we were going to do is really understanding, like, why is this cool? Tell me about this thing.

VV I think that you just made a point that I think is really important, which is step away from the tool, like step one is understand the users understand kind of the market that’s out there understand those like bigger level things before you even start talking about the tool. Because once you start talking about tools and features and stuff, you’ve already narrowed the scope so far, that you’re going to get answers that are related to that narrow set of questioning. And so this sort of very broad, like, tell me about why you got into birding is a really interesting place to start. Because that’s going to take a direction that if you said, we’re building a migratory bird platform, and we’re thinking about these features, which sounds good to you, you’re going to get a very different answer.

CL Cast a wider net to start.

VV Absolutely.

GT There’s users, but there’s also in building the relationship with the client, the business, the desired business outcome, and it feels like the altitude of our contacts on the other side, like a CFO or CEO is kind of, you know, might start the relationship by being like, let me give you our, you know, strategic, our company’s strategic initiatives for 2021. And like, here’s this, we’re on slide 42. Like, that’s where this project lands and like that, that’s really nice. And you’re like, oh, okay, I see now, why the business made this decision and why we’re moving that way. But that’s not always the case. Right? I’m sure that the kickoff questions and who can I talk to next and why are you doing this? What is the outcome we’re trying to get to right? Because a big part of our job is not only to deliver a product that users love, but also to achieve some sort of outcome or objective for the business. And it’s tricky because you’re really getting into The Big Business plan with your client, and they’re like, oh, no, you’re just over here. We need to build a thing. But why are we building the thing? What does success look like? I think that’s a really good question to frame up that conversation.

VV Yeah, I think the combo of like user market and business goals is, you know, those three, we’ll just call it a trifecta. I don’t know why. Those three, if you can get that high level, then it tells you where to dig in, because maybe they have thought like they’ve already done that work. And now they’ve narrowed in and that’s fine. Like it, you don’t have to rehash every every decision that they’ve made, it might be appropriate for us to just slot in there. But I think that first conversation starting higher level is really interesting. One thing I will mention an anecdote with one of the clients that I’m working on is they’re a brand new, brand new publishing business, they’re in stealth mode, they haven’t launched yet. And when we did the kickoff, like they have a pretty clear vision of what their brand is and what their media company is. On the product side, they’re much more you know, they didn’t really have super strong opinions. And one of the activities that we did during the kickoff was, we went through a workshop of what is the successful launch look like right? And half the conversation, or part of the conversation was about the product. But a big part of the conversation had nothing to do with the product. But it was really insightful for us to think about, what are we kind of building towards? How does the product meet their wider organizational goals of launching this business? And how do we set them up for success to have that successful launch? We also did do to circle back to Nathan’s, like, prepare for the worst. We also said like what goes wrong at launch that, you know, we should be thinking about right now. It’s real. It is real. So yeah, and that was that was really insightful as well as to hear like, Oh, these are like the biggest risks that we should start thinking about early on versus, you know, things that we probably wouldn’t have identified until later in the project otherwise.

GT Yeah, definitely a very useful exercise. 

CL Yeah. Vicky, can we talk tactics for a second? Like, sounds great, what you just described? How did you do it? What was your setup? How much client participation was there? What did you walk into the room with? Like, how did you structure this whole thing?

VV Yeah, so we structured it, it was a workshop. So we treated it, it was part of a bigger kickoff, but we treat this particular part as a workshop. And I think I came with a few questions, perhaps that was like, what are you doing on launch day, right? When this business launches, what are you doing? And we had a whimsical board that we had up and as they were talking, we were capturing notes. And we I think one of the questions is like, what sort of reaction does your user base have, when this thing launches? There’s a series of questions that we kind of walk them through.

CL And everybody’s throwing out ideas?

VV Everyone on their team is throwing at ideas, we’re capturing those, it’s leading down other paths, right, like we went off script quite a bit, because the conversation kind of took us in a direction we didn’t, you know, this is our first, you know, meeting with them. So we didn’t know all of the kind of nuance there. So prepared set of questions with live capture. And I think the goal for me, or what one thing was really important was to make it a discussion between us and between them. Because with them, in particular, their new business, they’re still figuring things out. And so it was really interesting for us to see where they were like, oh, I didn’t think about that. You know, I disagree. I think those sorts of things are really healthy to surface early on. And we were very much in listening mode. And we took that and we use it to inform our, our product strategy and plan. 

CL Who’s we? Why not just the PM? 

VV Oh, wow, this is great topic. 

CL I teed it up for you.

GT We’re gonna need a series on this.

VV Yeah, great question. I think the best products are built by cross functional teams, I think having designers and engineers in the room listening to firsthand user and stakeholder information, they’re going to hear different things than you hear, they’re going to have different perspectives. And that is such a healthy conversation to come back as a product team and have. And I think the worst run projects I’ve seen are ones where the PM has all the first hand user knowledge, then they translate that into design requirements handed over to the designer, the designer designed some screens, hands that over to the engineer. And it’s like nobody is problem solving. At that point, we’re just checking boxes. And so you probably end up with a product that doesn’t, that’s like so disconnected from the original goal. But if everybody’s in the room together, then everyone feels you know, invested, and everyone’s bringing their best ideas forward. And ultimately, you’re going to just build a better product.

NH Postlight disclaimer, that bad story did not happen here, that was somewhere else. [Vicky & Chris laugh]

GT Good job, Nathan.

NH You’re welcome.

CL It’s such an important point. I think you nailed it. I think that’s exactly right. I think we’ve seen it play out time and time again, on our projects, that when you get different perspectives in the room, you get a much more holistic appreciation. And I love your framing that you’re solving problems together. And I think that’s where the best work happens.

NH One slight bill to that is even just in like the mechanics of the tooling, one of the projects I’m on now, we’ve sort of crowd sourced our note taking for those meetings. And it’s really interesting for me to go back into that note after that meeting—and so it’s all captured in the same document. And it’s really interesting for me to see what were my notes versus the engineering notes versus the design notes. Everyone has had very different they index differently on different topics that makes important. That is also really good insight to bring to an internal meeting to get clarity. Why is this important? Why did you circle this? Like, why is this in bold? Tell me about this. And to really understand why that’s important from engineer or why design thinks that thing is, needs more questions around that, that there was something that was left on the table. So even that, like getting the questions crowdsource together, a hearing the knowledge is great, but then also taking that knowledge and like synthesizing in some way, sometimes adults are pretty straightforward. Sometimes it’s the same things because you hear the same thing. But sometimes there’s nuance and that nuance, I think, for me, is where you need to explore, did I hear it wrong, is our opportunity here, what’s going on with this thing that’s a little bit different?

VV Yeah, one of this isn’t on a team that I’m working on. But you know, I check in on Slack chatter in different channels. And one of our teams working with a really big client with tons and tons of stakeholders and moving parts. One thing I’ve noticed them doing is after they get off a stakeholder interview, they start a thread in Slack that says top three takeaways. And everybody who was on the call, puts in the three takeaways they took from that conversation. And then it spawns a really interesting discussion. To Nathan’s point, sometimes the takeaways are aligned, and it’s very clear, but oftentimes, there’s a lot of interesting nuances that are worth digging into.

GT I love comparing notes like that when you’re like, oh, I didn’t hear that at all. Or I interpreted that completely differently. Like, let’s talk that through, what did you hear? And why did you—and it’s like, oh, we have follow up questions here. I missed that bit, or whatever. I mean, it’s just, it’s so and to have everyone actively listening, that everyone’s taking notes versus having the designated note taker, and everyone sort of leans back and is like, oh, so and so’s taking notes. You know—

CL I’m off the hook. 

GT I’m off the hook, yeah, exactly.

VV Yeah. One interesting thing you said, I think sometimes it’s, we heard things differently, we need to follow up and ask clarifying questions. But sometimes it’s like, oh, these things put together like it’s an insight that we wouldn’t have gotten to otherwise that actually allow us to put forth something that like we hadn’t talked about, because we’ve kind of connected all these dots that felt disperate, or, you know, whatever. And now we have a solution or a proposal or something to put forward that the customer never even or the client never even thought of. And those are like the most satisfying moments. 

GT Yeah. And also playing back to the client. Like what we heard last time was this, even if you’re rewarding, you know, around your takeaways, like that’s a very powerful relationship building tool. And clarity building tool. Because also just makes the client be like, Oh, you were listening. You were listening so closely, that you you know, asked a question that I didn’t realize, right, assume you knew. There’s a superpower coming in as a partner who isn’t an employee of the company who, especially when you’re like new to an industry and new to a company, meaning like, your client looks at you as a subject matter expert, but also you can ask anything. There’s just you can just say, look, look, I’m new here, I’m gonna ask a couple dumb questions. I’ve even no question is dumb. But I will often say to clients, I’m gonna ask them dumb questions here, because I just want to make sure I’m not making you know, the wrong assumptions. And you have people start to talk about, like, the basics. I think there’s some assumptions internally, you know, on the client side, like everybody knows this, it’s like, do they? You know, you make people say things aloud that maybe that they were just taking for granted. I mean, that’s a, that’s a very good position for us to be in to, to build trust and understanding. But also, you know, to just get that clarity. I think when there’s, it’s kind of mushy on the client side.

VV Yeah. I saw an article recently that I haven’t tried this exercise myself, but it made me laugh, because I’ve seen this the kind of like fumble of this so many times. Which is, if a team is struggling to communicate, have everybody write down the words or phrases that they’re like, does everybody understand this? And then upvote the things that you want to talk about and define. It’s like, sometimes it’s acronyms that get thrown around that you’re like, but does everybody know what this means? Or I don’t know what this means. But it’s used all the time. Or sometimes it’s like really vague terms. Like, our onboarding is bad. It’s like, okay, but what does that mean, right? What is onboarding mean in this context? And so you kind of, it’s like a crowdsource team building activity, where you end up with more clarity on what some of this language means, because words are hard. And they’re so important, and that like, kind of shared understanding, especially about things that get brought up constantly. It’s amazing how often you think there’s clarity, and there’s not especially as the teams get bigger. 

CL Totally agree. This reminds me of the MTA glossary. When when we started working with the MTA, we literally had a document shared amongst the team that was called MTA glossary. And every time we learned a new thing, oh, RCC, that means Rail Control Center, like put it in the glossary, let’s make sure we’ve got really clear shared understanding around these things.

NH This is like the most like one on one tip, ask your client if they have a glossary. A lot of times they have it, they’ll just send it to you. I just got one today, because I asked. It’s that simple.

VV Yeah, yeah. But I think that there’s like the acronym piece. And then there’s the like, these kind of more just standard boards that take on their own meaning, but is everybody clear on what that actually means? And I feel like those conversations are always enlightening.

CL I had a client once who when we would ask about the ‘nav’ the navigation, it meant different things to different people. And so we just need to get clear on like, what are you actually saying, to exactly your point. 

NH So the headers everything above the fold, is that what you’re saying?

CL Right. Exactly.

GT Like you know, I think I used the word hamburger once and you know, to refer to the hamburger and the client was like, I don’t—what are you talking about? Like you know, so it was like assumptions in our part too about what things are.

VV Absolutely. 

NH So important like getting a, you know, a deck ready for a client presentation, making sure that the Postlight words are clear, we also have our own internal dialogue and breaking through those barriers. So that’s a lens to look through as well, that I think is important that we’re not sort of, you know, two sided here. 

VV Yep. Discovery, I feel like that’s one that’s always like, people have so many different interpretations of what that means and have seen it done different ways. And it’s like, we’re gonna go into Discovery phase. It’s like, cool, cool. What does that mean?

GT That is very much an agency term, too. Like, so if especially if you have an inexperienced buyer or someone hasn’t work with an agency before. It’s like, what does that mean?

CL So I want to go back and question something. So Nathan, when you started, you were talking about how we, you know, we come in, we can define these very ambiguous projects, especially when there’s not a lot of definition, when we’re going into the room. What happens when the opposite happens? Right? A lot of people go to agencies, because they’re like, I know what I need. And we’ve already done the prep work, we’ve got the thing, it’s very well defined. I’ve got the bullet points, maybe it’s a long requirements, hopefully not a long requirements. But we you know, we know what we need. How do you approach that? How is it different from something that’s a little more open ended?

NH I would say, in some ways, those are even more challenging, because there’s been already a bunch of work done on the client side, they have assumptions, they’ve made decisions that you don’t know, right? You don’t know how they got where they got. So I think you have to take a little bit more time to even understand, generally, they have research, they might have prototypes, they may have actually paid agencies to do X amount of this work. It’s really understanding all of the run up to their to understand where are those decisions came from the mistakes that were made along the way, because you can’t make those mistakes, you can’t make those assumptions, you have to have a better baseline to jump from. So in some ways, I think those are actually more challenging, because you have to really do a lot more legwork upfront, ask different questions. How did you get here, explain why this is important. I want to understand this decision. That may also seem jarring to clients, because they’ve already been through that, they don’t have time maybe or the desire to want to talk to you about that. But it’s very important for you to understand where that came from, how important is this? Was it an assumption, did they end up with this because they didn’t know how they got there? Like, we need to understand a little bit more about that. Just to not rubber stamp something, we would never just take something wholesale and just move on it. 

VV Yeah, I mean, I think even in those types of projects, what does success look like still comes first. And again, they might have it more fully defined, which is great. And then with that lens, I think you look at kind of the decisions that have been made. I agree with Nathan asked questions, understand, like the why behind stuff, but then think about like, maybe a little bit more of the like critical lens on things where you’re like, what doesn’t make sense here and of the things that don’t make sense, which feel high risk? Sometimes there’s, you know, things that they’ve decided that you’re like, I don’t know that this makes a ton of sense. But also, it’s minor, who cares? Like it’s not worth spending our time on, we should just do it. And it’s easy to undo if we learn later that it was wrong. So that’s fine. So but if you question, if you kind of take that lens of which of these are high risk, and question those, then I think it’s a much more kind of targeted assessment of this, you know, requirements or whatever that you’ve been given. And you can get at the root of some of the bigger decisions that they’ve made in a much more targeted way. 

GT What’s high risk? High effort? Low pay? Like walk me through that.

VV I think there’s different kind of like axis of risks, I think super high effort without validation is definitely a high risk. So we’re not sure if this is what users need, and it’s going to take us six months to build it, it’s like love, let’s get more clarity and de-risk that a bit more. I kind of call this like the one way door where it’s like, you launch a brand with a big, you know, hora, that is like very hard to come back from if you do wrong. So those are kind of, you know, high risk things, things, I think that are gonna leave a lasting impact on a user’s perspective, or a perception of the product, the company, the brand, are probably high risk. Whether a button is here versus there versus you know, blah, like, whatever those things, you’re gonna they’re low risk to implement, and they’re changeable. And you might frustrate a user, but in the end, it’s not going to have a meaningful impact on their experience. 

NH I think it’s anything that goes counter to what you want that users action or experience to be if you can define on this particular view, or this page, what’s the number one thing that users should do, if you’re putting a counter pattern to that action, that’s high risk. Because that user should sign up or buy or whatever that action is. And so if you’re doing something to change the intended outcome, like web design has been around for a long time, a lot of patterns have been defined. If you’re going to reinvent the wheel, you should have a really good reason why your business or your company needs to do that. Other than it looks cool. Sometimes it does look cool, you know, to Vicki saying, if you put something out there and that user doesn’t take that action, you’ve lost them. They’re not coming back and people move quick. Now people make decisions and they’re gonna either become brand loyalists, or they’re gonna forget about you based on that possibly on that counter pattern.

VV Yeah, there’s definitely the death by a million papercuts problems I’ve seen where you know, like, not one of these things is you know, how risk but put together you’re like, no, this product that we’ve built is like super forgettable or it’s frustrating or whatever. And so you definitely need to watch out for for that. But I think that’s why it’s important to evaluate them kind of individually the requirements, right, individually and as a whole, and always tie it back to what does success look like here? What are we aiming for? And are these things helping us get there?

CL Something that both of you do that I think is another less apparent maybe risk, but it’s still a risk nonetheless, is trying to do too much too soon. Which is something we see a lot when someone comes to us and they say we want X, Y, and Z. And they all have to be an MVP, and they’re all critical. Knowing how to lean on a product manager to say actually, you probably don’t.

VV God, I love cutting scopes so much. 

GT How do you explain MVP to someone who’s never—like I had a client be like ‘So MVP, it’s a minimum what? What what does that mean, exactly? What is it an MVP?’

NH We hope it’s minimum viable. But sometimes it’s valuable, depending on the decisions that you make. [Gina laughs]

GT Right. Is it viable? It’s viable. Isn’t it? 

VV I say viable, but I think both are used. I mean, it depends on the project. But to me, the key thing that I like to cut scope on is if we’re talking about a thing, and we can’t, we don’t have any user data to point back to you that says like, this is a specific problem that we’re solving for a user, we’re like, this would be cool. This would be nice. So easy example, this is personalization, like people want to build personalization into their products. I get it, personalization is important. A lot of big products have invested, you know, tons of engineering effort into personalization. And it’s very, it has led to a lot of success. I think personalization at the wrong time is such a huge distraction. And so you know, if we don’t know, if we’re like launching a new product, you have no idea how people are going to use this thing, right. And so focusing on personalization, when you’re standing up something brand new, to me just feels like a clear, this is out of MVP, let’s get this live in the world. Let’s see how people use it. And then we can be really smart about how we build personalization into the product. 

GT I mean, this makes a ton of sense to me. But it puts you in a position as a PM or as a project leader where you become a little bit of a dream killer. What you’re really doing is advocating for the product and for the client and for the eventual users. But it can feel when you’re having this conversation like this just isn’t important now, like we can do it later. I also love to cut scope, but it’s not because I don’t want to do the work. It’s because like it’s important, the order in which you do it and then getting to release. And I think it’s such a delicate conversation to not be seen as like, oh, we’re just, you know, it’s just a no, you know, MVP means no.

VV I mean, not 100% success rate. But I feel like what I’ve had the most success with is let’s get this in front of users and then see like, yep, and then see what we learn something and then come back to this because then we’ll make a much more informed decision. If you’re like spinning your wheels, and just throwing out opinions about something that you probably don’t have enough information to build it right. And so you either have to, you know, maybe it shouldn’t be part of the MVP, you just need to do your research. Or maybe you just need to get this thing live. And then you’ll figure that next part out.

CL Yeah, you should have a reason for everything you’re doing. And that reason can be database, sometimes you need to take a leap. 

VV Sure. 

CL And if you decide I’m going to take a leap, that can be the reason, but it shouldn’t be, you know, why not? Why not include this? That’s not enough of a reason, you got to have a higher bar and sometimes gonna kill the dreams.

GT Yeah, sometimes you do have to kill the dreams. It does feel a little bit like I’m telling my kid she can’t watch Netflix until she’s done her homework. 

CL Sometimes your kid can’t watch Netflix, you know? [Gina laughs]

GT Every day, ideally. Except for the days I’ve just given up. But that’s a whole different podcast. [Vicky & gina laughs] Can you invite me on that one too?

BL What about advice for clients? Right? So we’ve talked a lot about the various ways that we approach a project when it gets kicked off. What if someone’s looking to buy they’re shopping for an agency, they’re saying, I’ve got this thing, I want to make sure that I give enough, you know, definition to get someone started, but maybe not too much to your points earlier, where we still want to have a clear way to sort of move forward with a project team. What would you say in the ideal scenario, someone’s coming to the table with? What’s not too much, and not too little?

VV I’m gonna half answer your question, because you kind of got me started on what advice would I give clients and the advice I would give clients is let the agency in, right? Like you’re bringing these people in to help you solve a problem. And the more you can kind of bring them into the fold, invite them to, you know, to understand the business and understand the problems and the real risks and things that they’re internally grappling with. I think the more information we have, the better we can solve it. And I’ve kind of, I’ve seen both sides of this with different clients where, you know, one client really letting us in, we’re part of we feel like we’re part of the internal team and another client, we ask questions, they answer the question, we ask a question, they answer the question. And that’s fine. Like we’re getting what we need. But I would love that kind of deeper insight. I feel like we could do a better job. 

CL That’s a great answer. Nathan, anything?

NH Yeah. I think also with that, just knowing that we’re here to be trusted, and we’re going to ask questions, because we need to understand something. So I’ve noticed in engagements, there’s always this, well, hopefully, there’s always this place where you become trusted. And so the guard comes down. Like how can we get that guard down quicker? How can we just we’re humans, I’m going to ask you questions you should ask questions of us, if you don’t understand something, we’re gonna make assumptions on either part, and sometimes just approaching those conversations very directly and honestly, of like, hey, how can we best support you? I would take feedback I, you know, sat with a client a couple days ago, I was like, hey, just quick question. I would just love to get your feedback. How are we doing here? Are we meeting your mark? Are we doing what we’re doing? How are we approaching us? Are we meeting your goals? Are we communicating the right way? And just having that real world conversation. You know, it was a couple of things I learned that were small, but important enough to be surfaced. So like, that’s useful information. So again, it goes that building that partnership, and really making sure that that’s what we’re doing, I think to get to those conversations, you have to have either two things, one a killer sense of humor, which clearly I have. [Gina laughs] Or you don’t, I do not, or you have to reference it around something that everyone can gravitate to. And so one of my clients in every single meeting, we talked about doughnuts, because that’s just a shared language that we have. It shows up in decks, we talked about that. It dials a temperature down. I know it sounds silly—

CL Doughnuts, like the ones you eat?

NH Oh, for sure. 

CL Okay. I didn’t know if doughnuts was—I don’t have a glossary for all of our terms. [Gina laughs]

NH Yeah, yeah, just the wonderfully beautifully fried dough. Yes. But yeah, you can send around something as silly as that or sports metaphor, whatever.

VV Definitely not sports metaphors. Oh God. [Nathan laughs] I’ve had a couple clients with sports metaphors. And I’m just like, thank you.

GT Yes, yes, that.

NH I just want somebody to invite me to a Yankees game or a Dodgers game if I’m in LA, that’d be fine. That’s that’s my angle. But to get into that trust is that I think the most important part so you can have those honest conversations around, well, what are your goals here? And are we meeting those, sometimes things change in the middle of the work, you know, goals change, the business change, maybe they’ve got acquired or they’ve lost users, and they’ve pivoted their business goals. If you’re not constantly taking the temperature, you won’t know what that is/

VV I think, something we’re grappling with with a few clients right now, which is sometimes scope of our engagement changes, because we’re doing a good job, and they’re letting us deeper in. And so that’s been an interesting discovery for our teams of, okay, like we kind of we had this sort of guardrails on the work that we were doing, had these edges and made sense. And then because they’re seeing the path that we’re on, and that we’re doing a good job. Now they’re like, okay, but can we go a little bit wider, and they kind of let you into that broader thing. And that can be hard as a product manager, because you know, your instinct is to cut scope. But sometimes you’re like, oh, now that we know that, and we kind of see this broader picture, like, it might make sense to change things up. That happens so often internally at product companies or in companies in general. But I feel like in an agency, it’s less because you know, you’re kind of like you’ve put some bounds on on a contract. But I feel like I post like, that’s something unique that we we build such strong partnerships with our clients that we go deeper, and we have, you know, longer relationships than on average, I’d say.

GT Definitely, yeah, I mean, this is a really tricky part of the job, because you’re in this delivery mode, we made a commitment, we’re going to deliver the thing to you by this time, right. But we see the roadmap ahead, and we see where you’re going, we see that where the momentum is, and it’s a part of what we try to do is deliver the thing we committed to but also like, here’s your roadmap, like here’s what what the next thing is, whether that’s with us or internally or with someone else, but that’s a really tricky, to operate in those two different altitudes, particularly when you’re running up to a launch at the end of an engagement, it’s really tough.

VV Yeah. And I feel like we’re actually, a PM tool we’re introducing is like, what is the framework, we can help our teams communicate those sorts of like trade offs that, you know, basically, we’re asking the client to help us make and I’ve seen this on two projects recently, where yeah, there was like, kind of a big pivot moment, or potential pivot moment where we had to say, should we go down the path of kind of the original delivery? We’re like in it or given these other circumstances? Does it make sense to make a change? And I feel like just the more clearly, the more clearly, you understand what success looks, like a broken record, the more clearly you lay out the options and the trade offs and our confidence in those different options. I think the more honest conversation you can have with a client, and sometimes you, you know, make a call to like, let’s stay on the path we’re on and come back to this. Sometimes you make another call. And again, it’s about that partnership, right? Like you, you’re solving problems together. And so the more you can add clarity to that discussion, the better it is, you can’t avoid it.

NH Together. That is such a good word of those decisions. And all of that has to be done together. Like maybe we’re doing the work, but the client team is just as involved in that has to be done together. Everyone needs to understand what we’re doing, where we’re going, what success looks like there.

CL I’m curious if this conversation is resonating with people who are listening. Are we looking—oh, well, yeah. Okay. What do you look for in someone who might fit in this role of an agency PM?

NH I think for a couple things to pick up on. Yes, we’re looking go to There’s a whole bunch of postings there to check out or if you’re just casual and you want to learn a little bit more, Vicky’s on LinkedIn. I’m on LinkedIn. You can find us. We’re out there. We’re happy to take conversations, maybe answer some more questions. So, no, it doesn’t have to be as rigid as just applying, we’ll figure it out. Like we’ll have a conversation. If you’re a good product thinker, we can riff on all kinds of products all day long. We’ve just done that here. So in terms of what we’re looking for, I kind of come back to, how did you solve problems like, how did you understand a problem that that existed in the world? How did you become familiar with that problem? The edges around it, what it meant, how you could poke at it? And then how did you go about solving it? And I don’t mean the solution. How did you go about solving it? What did you try? What did you evaluate? How did you think? Sometimes it’s a clear path to success. Sometimes it The answer is easy. Sometimes you have this epiphany moment and it delivers. Sometimes you have to really think about it, you have to do some research, you have to explore maybe you try a competitor or you brainstorm a little bit, but how did you kind of go from understanding why is this important to oh, wait, this thing could work. If I do X thing over here, really understanding that in talking that through if you can demonstrate that you can be successful here. Understanding problems and solutions that aren’t telegraphed to you like you have to do the work to understand both edges of that, I think sets you up really well to be successful PM at Postlight. We move fast, but we solve really cool hard problems sometimes are clear, sometimes are really ginormous, and scary and terrifying, and fun and rewarding. And we get all sizes of those. So if any of that resonates, like reach out, we’re here.

VV Yeah, the only thing I’ll add is, you know, we’ve been talking about this, and we’re very product management perspective. But we’ve got partners in design and engineering and our digital strategy team. And I think that collaboration with those different disciplines and the ability to bring people in, work as a team, I think we had a thread on, you know, the importance of having everybody in the room together. And I think that that is such an important skill for product managers, because they’re often kind of at the heart of the team. And so connecting everybody and being a strong collaborator, I will add that to the list. [music fades in]

NH And you also have to like doughnuts, I’m gonna bring this full circle. [Vicky laughs] Like that’s just a thing. Like that was my litmus test. I brought in donuts today and I saw who ate the doughnuts and who didn’t. 

GT I mean I saw you were taking notes about who took a bite of that—that cruler was amazing. It was really good. 

NH I want to find problems that we can solve for that company in particular. So if you’re listening—

GT Well, this has been great. I mean, and Vicky’s point is real. We are growing across all of our groups. We’re very much product shop and lead by product, but we’re hiring and design and engineering and digital strategy. Check out If you want to learn more. I really enjoyed this discussion. And I wish we had more time.

CL This was fun.

GT This was a lot of fun. Thank you both Nathan and Vicky, for joining us today. 

VV Thanks for having us.

GT A lot of fun. Thank you for listening to the Postlight Podcast, we are Postlight, we are at, you should reach out, send us a note. We’d love to hear from you. You can find us on Twitter @Postlight and Instagram and all those other places. And we’re also at 101 5th Avenue in Manhattan if you’re around. We’re in and out right now in the office. We’re figuring out how things are gonna go but we’re here. Get in touch. We’d love to hear from you. Thank you, Chris. This is a lot of fun.

CL Thank you, Gina.

GT Talk to you soon. Bye.

[music ramps up, plays alone, ends]