Give Your Colleagues Better Feedback (with Ryan Schaefer from Viget)

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Ben Aston: Welcome to the DPM podcast where we go beyond the theory to give advice that works for leading better digital projects. Thanks for tuning in. I’m Ben Aston, founder of the Digital Project Manager.

So, how do you deal with giving feedback to the people on your team? Do you embrace it because well, you know, you’re right, you’re a PM, or do you avoid it because you’re worried you’re not going to be taken seriously? Maybe you get feedback and you think no one really understands or perhaps even heard what you said, but as project managers, we are responsible for delivering success, but doing that is hard when our teams so often seem to be barking up the wrong tree.

So find out in today’s podcast some simple ways you can give feedback that will help your teams deliver better work and keep your projects on track.

Today, I’m joined by Ryan Schaefer. Ryan’s moved from designing and building websites to now managing their development, and he’s in DC at an agency called Viget. Hello, Ryan.

Ryan Schaefer: Hi Ben. Thanks for having me.

Ben Aston: Cool. So Ryan, tell us a bit about your role right now, and what I’m really interested in is how you made that transition from design dev to PM. It’s a question we often get asked. So what do you do right now? Is it pure play PM-ing or are you also kind of getting in the weeds a bit as well?

Ryan Schaefer: I would say it leans more towards pure-play PM-ing, but certainly, I think one of the things that made it easier for me to transition from being down in the weeds and executing upon design and development into PM was having an understanding of all the thoughts and the processes that went into the design and the development aspects.

And so that allows me to talk to the very talented designers we have here and developers we have here on kind of a level playing field in that I don’t have to ask what the acronyms mean, I don’t have to ask what the tools are, and stuff like that.

I think my background at a previous PR firm where I was at, I kind of had a dual role in accounts and in the execution, and so that prepped me a little bit to think about how I would convey things to a client and how we would work with other team members, stuff like that. So it was a pretty natural transition for me, fortunately, into full-scale PMing.

Ben Aston: But how did it happen? What was the trigger moment where you said, “Okay, that’s it? I’m going to be a PM”?

Ryan Schaefer: It had a little bit to do with wanting to manage things from a 30,000-foot view as opposed to doing things more in a silo, but I would say the primary reason is because I wanted to join a firm where everybody was passionate about digital and was digital and forward-thinking because it obviously is changing the way we live as a civilization, certainly as a country, and that being surrounded by people who saw that and valued it and who were also very skilled in their respective disciplines as it relates to digital was something that I wanted to be a part of, and then ultimately, that was going to help me grow professionally.

Ben Aston: Cool. So tell us a bit about what you’re doing right now. At Viget, what does that PM role look like?

Ryan Schaefer: Yeah, I would say first it’s Viget. We get that a lot.

Ben Aston: Vid-get? Vig-et?

Ryan Schaefer: Viget, yeah.

Ben Aston: You know, I even went onto the website and clicked on a cat that said it’s Viget.

Ryan Schaefer: Yeah, there’s like a say hi button. That’s Viget.

Ben Aston: Well, that’s what you have when you have a funny name. What does it even mean?

Ryan Schaefer: “Together we flourish” in Latin.

Ben Aston: Oh, of course.

Ryan Schaefer: Something like that.

Ben Aston: My mum would be ashamed of me. Mum, I’m sorry. She’s a Latin teacher. I should know things like that.

Ryan Schaefer: Latin was my least favorite subject in high school. We had to take it. I can’t believe we had to take it, but.

Ben Aston: Well, it’s prepared you so well for all the languages you now speak, right?

Ryan Schaefer: Yes, exactly. But yeah, so my role at Viget as a PM encompasses a lot of different things. So certainly, there are the core PM responsibilities, like timeline, budget, scheduling, staffing, and resourcing; and then we also have things that are more specific to product management. So we don’t have specific product managers here, so PMs are responsible for a lot of user journeys, and feature definition, quality assurance testing, really understanding the businesses that you’re working with and the products that you are working to build inside and out.

Ben Aston: Cool. So it’s project and product management?

Ryan Schaefer: Yeah, it’s a-

Ben Aston: Kind of a mix of both.

Ryan Schaefer: Yeah. And you know, they kind of go hand in hand, and it’s beneficial to do them together, but I also think that they’re different enough that it’s a nice change of pace when you want to shift gears into something that’s more working on the project versus running the project.

Ben Aston: Yeah, cool. So can you tell us a bit about any projects you’re working on right now?

Ryan Schaefer: Sure. Yeah. I actually just switched over a couple of weeks ago to full-time on one single project, which is the first time that’s ever happened to me, and that is working on a big marketing site and then a portal of sorts for a different audience groups that can log in and different data is fetched for each of these different audience groups.

So we’re essentially redoing the ecosystem, updating the design for all their forward-facing digital materials, and then working on a roadmap for future products, like maybe an app or something like that. It’s very involved and I’m excited to dive into one project, and really get to know it, and to learn more about it.

Ben Aston: Yeah. Talking about a native app build, I know you have an upcoming Lightning Talk at the DPM Summit where you’ll be giving tips for managing a native app build. Can you give us the Coles Notes version of your talk? What are you discovering about native app builds?

Ryan Schaefer: Yeah, so my talk is going to be centered around … Well, it’s drawing off what I learned during the biggest project I’ve been on here, which was an Android app design and development project.

I’ll be talking about what I’ve learned, and then primarily, the differences between managing a native app build and a more common web build, the best practices for doing that. And also, I want to talk about the specific technical requirements that, as a PM, you need to be aware of.

There’s a couple of examples. the cost of failure is very high for an app because the app will crash versus a website, if it has an error, usually it’s just command-R or whatever and reload. And then also, the languages you use to write in native apps are not like JavaScript, which you’d use for web apps, in that you do need to come up with 90% of a solution to a problem, as opposed to 30 to 40% for web apps in which JavaScript will make up that difference.

And there are also system controls and other constraints, like offline constraints, for apps that you need to be aware of: how does an app function when it’s offline? What do the menu buttons on your phone, how do they interact with the app, and where does it lead you? Things like that.

Ben Aston: Right. You’ve done web apps and obviously native apps, and the trend that I had been saying was that everyone’s doing web apps because they’re easier to build and quick to build. What’s your view on the web versus native app and the way that that’s heading?

Ryan Schaefer: Yeah, I think one of the interesting things that we’re seeing and we’re navigating as a company is the rise of things like Squarespace, and Beams within WordPress, and Weebly, and all that. Those are very utilitarian services that allow people with limited tech technical knowledge to spin up a really good-looking website.

So because of the low cost, and the accessibility of those things, it is harder to find traditional marketing site web builds. Native has not really opened up to anything like that yet, and so we’re finding a lot of potential in that area. And also, it’s just kind of cool to say we have an app, you know?

Ben Aston: Yeah.

Ryan Schaefer: But I think the other part of it too is there’s a lot of software and product that is still undiscovered yet. Like the thing I’m working on now, like a portal for your users or behind a logged in wall, what you see is different than what you can build on Squarespace or whatever.

There’s a lot of ability for customization, which is exciting for designers and developers, but there’s also a lot of things that we can work to chart in this area to make it a more exciting field in terms of creating products for companies.

Ben Aston: Yeah, cool. So tell me, you’re doing app builds, you’re doing big marketing kind of site builds; what’s in your PM toolkit? How do you manage the products and the projects that you’re working on? What’s in your PM toolkit that you always like to get set up with at the beginning of a project?

Ryan Schaefer: Yeah, yeah. It’s obviously important to start off strong, so I like to facilitate a discussion focus client kickoffs; a visioning call is a really good thing where you talk about what their organization is doing now, what their product is doing and not doing, and then where they want to be; I also like to do problems, and goals, and objectives workshops; stakeholder interviews, stuff like that.

That’s a lot of things that you can’t suss out in the sales process no matter how detailed you try to be. And then once you really understand all of those things, which is an important phase to scope for because it can take a couple of weeks or even longer, then you’re going into it armed with all this knowledge that allows you to start quicker, and build more efficiently, and ultimately, deliver a better end product.

The tools used to wrangle all that can be pretty expansive. Airtable’s a really good, certainly GitHub Projects, Zen Hub is another thing you can use with GitHub, Trello. We’ve used all of those based on the preferences of clients and our own recommendations.

Ben Aston: Cool. Are there any particular PM tools that you’ve found recently that are making your life awesome, like good hacks or shortcuts, anything that you’ve just discovered?

Ryan Schaefer: Yeah, I’d say two things. One is I spend a while looking at the shortcuts for my computer because there are so many more and that has really cut off … I mean, it cuts off like seconds, but seconds hundreds of times a day.

The other thing is-

Ben Aston: What’s your favorite shortcut recently that you’ve discovered?

Ryan Schaefer: Oh, command-shift-T, which opens the most recently closed tab.

Ben Aston: Oh, nice one.

Ryan Schaefer: Yeah, it’s a good one.

Ben Aston: My favorite recent one, which I used to have an app dedicated to this, but I’m on Windows. So Windows-V in Windows 10 now gives you your copy and paste history.

Ryan Schaefer: Oh wow.

Ben Aston: For forever, I think. I don’t know, I haven’t gone back to check, but I’m the kind of person who likes to play that high-risk game of type something in notepad, copy it, and then start doing something else, and then forget to paste it. And so my copy and paste history, which includes images, I’m finding really useful. So Windows-V and command-shift-T, is that what you said? There you go. There’s your shortcuts of the week.

Ryan Schaefer: That is a really good one.

Ben Aston: Anything else?

Ryan Schaefer: The new tool that I’m using that has really opened things up for me is Notion. Have you heard of that?

Ben Aston: Yeah.

Ryan Schaefer: Yeah. It’s kind of like a workspace app. You can use it for notes, you can use it for collaboration, it has offline stuff, it has a really clean UI. It allows you to embed, and do toggles, and nest pages within sub-pages within sub-pages within sub-pages endlessly. And then it has a web and mobile app as well, so you can use it anywhere and everywhere, and it’s very customizable.

That allows me to, if I’m in a call, just fire it up real quick, and I can type something I need to, and then go back and make it look pretty really easily afterwards or during.

Ben Aston: So Ryan, tell me with all the projects you’re working in, and even with the tools that we’ve just been talking about, what do you find tough? In your role, what are some of the day-to-day challenges? What’s the most tricky thing about doing what you do right now?

Ryan Schaefer: Lots of things. One is not having enough time. But I think the trickiest thing is, well, one of the tricky things is context switching.

You know, you normally have capacity as a PM for multiple projects, and then you tend to have a lot of meetings on your calendar, and so you’re often jumping from one meeting to the next at one minute and having to like kind of cache everything for that project on the walk to your next meeting room or whatever. I find that a really difficult thing and I think the way that I overcome that is to just take really diligent notes with things that I can reference right away. Certainly, doing agendas for every meeting. I also like to take some time at the beginning of the day to just sit there and think about, with some coffee, the status of each project that I’m on, and where it’s at at the beginning of the day and where it should be at the end of the day. That’s one of the things that I am continuously trying to improve in.

The other thing is just trying to find a good way to facilitate collaboration and kickoff I think between the handoff from designers to developers. You often get this really beautiful mock that your designer put together. They worked in conjunction with a UXer and everything looks great, and then you want that period where a developer looks at it and they want them to sign off before you show it to a client. It’s often not obvious how to document and define all the different front-end features and how everything is controlled in the admin, just on a static comp.

So we’re exploring some ways with Airtable, things like that, to do content structure in a way that cross-references each of the elements of the comps, and then that helps a developer go in and say, “Okay, this is how this will work, and this is how that’ll work. Because of that, it’s gonna take a week or whatever, so we can do it in time and budget.”

That can be a kind of laborious process, and that’s something that is very much fluid, but hopefully that’s one that will pay dividends.

Ben Aston: Yeah. So tell me about that because Airtable is basically, it was a spreadsheet come database thing.

Ryan Schaefer: Yeah.

Ben Aston: Is there some like integration with InVision, or Sketch, or whatever you’re using for your mock and Airtable? Is that how it’s working?

Ryan Schaefer: It has integrations, but we use Figma primarily. I don’t think it has any integrations with that.

We’ve tried a couple of different things, just in a Google sheet in links and stuff like that. I don’t know if we’re quite at the point where we could integrate it in a way that makes sense with a tool that we would use, whether we would choose a tool because it integrates with Airtable. I think the biggest draw of it is it’s a relational database, and so cross-linking things within that database is very, very easy, and it’s very scalable as well, and the readability is great, and the UI is clean and all that too.

Ben Aston: For those people who’ve never used Airtable, if you basically got a different sheet for … How do you structure the Airtable? Can you give us any insight into that?

Ryan Schaefer: I can give you a little. If we’re starting with UI explorations, we’ll document where every navigation item goes using a site map, something like that, and then you can create another … They’re not called tabs. I’m blanking on the right word for it, but they effectively look like tabs, and then you can reconcile what you currently have by linking to it on the other tab, and then add new areas, and delineating between what the new areas are in a couple of different ways, whether that’s simple things just like adding tags and categories, distinguishing it with different blocks, which each have specific headers or colors or whatever.

And so that gives you kind of a clean, easily digestible thing for everyone to look at throughout the project and serve as kind of the source of truth for everything.

Ben Aston: Yeah, that’s cool. Because I think a lot of the time, this is often such a big challenge. It’s like how do you go from UX design through to dev and retain the requirements?

Ryan Schaefer: Right.

Ben Aston: How do you codify that? And I think using Airtable’s a really … I haven’t heard of that before, but I like the fact there’s so much stuff that’s, “Oh, you know, yes, this is the same menu as you use over there” kind of thing. And if you’re doing this in Word or Google sheets, you’ll just be repeating, copying and pasting, and then change it in one place, forget to change it in another. But doing it as a database means we can just reference the menu item or whatever from the database, so that’s a really cool idea.

Cool. Well, let’s talk about your post, and for those who haven’t read the post yet, it’s all about giving feedback, giving feedback in such a way that is going to benefit the project and deliver a better product or project at the end of it.

But for those people you haven’t read the post yet, can you give us your take on giving feedback, a toll? Because it’s something that, as PMs, I think we can often be afraid of doing, but I’m curious as to your perspective on why you think that we do hold back, and what is it that you think perhaps we’re afraid of? What’s your take on that?

Ryan Schaefer: Yeah. I think there are a couple of reasons we hold back.

The first one is more a human reason in that we don’t want to offend our teammates or trot on the work they’ve done. And the other part is we might not feel confident enough in our opinion, given that we’re giving feedback to the subject matter experts, the designers and the developers.

They’re reasonable concerns certainly, but ultimately, you as a PM are the closest to the client, and you are a fresher set of eyes than somebody who has been working in the weeds on everything, that you can simulate the end user’s perspective best. So you are providing a different perspective on the work than somebody who is actually making it is.

So you should feel comfortable in that level of expertise, and in that viewpoint, to provide feedback that is like, “Okay, I as a PM, I’m just seeing this for the first time. The user’s seeing this for the first time. Does it clearly convey what the organization does? Does it appeal to their audiences? Is it obvious that this is a drop-down menu or what have you?” I think that kind of reaction that you have to this helps people step back and match those things to expected user behavior or the business objectives and whether we’re hitting them.

Ben Aston: Cool. I buy this perspective as the, “We can be the guardians of success and guardians of the user experience in terms of that fresh pair of eyes.”

In the post, you give 10 pointers on giving good feedback and the first of those is setting yourself up and in an informed position and that’s from a business success perspective. You talked about getting a client project deep dive. You mentioned you’re starting a new project and you’re doing this deep dive. So, how do you know when you’re informed or not? What’s your kind of process of getting that deep dive so you truly understand things properly and aren’t just thinking you know stuff when you don’t actually know?

Ryan Schaefer: Yeah. A great question. I think you never really know that you’re all the way informed, which is okay.

Ben Aston: Yeah.

Ryan Schaefer: But I think I mentioned like visioning calls, which I think is a good starting point because you can learn about how the company views themselves and then where they want to go, which is like, “Okay, this is something our CEO decides upon. Are we going to acquire this company? Are we going to merge? Are we going to go public?” Whatever it is.

And then if you have conversations with executive stakeholders and something like that, you get an idea of how they plan to execute upon that. That, again, feeds into the the higher point of view. And then once you start a discussion-based kickoff with people who are going to be directly involved in the project, you get a sense for how the project ties into what the higher level executives are going to do, which ties into the higher level business goals. All that stuff should be communicated and should shine through, ultimately, in what you’re trying to achieve.

You should get enough, and you should get enough specific information certainly, on all those conversations to help understand what they want to do. And if you understand what they want to do, you are the medium for helping them get there, whether that’s refining their communication, whether it’s conveying their brand by redoing their aesthetic, or fixing their messaging, or just recommending that we extend this product, we build them an app and here’s what we’re going to put in it, and all that.

It’s an evolving process. It’s something that does require a lot of investment at the beginning. We’ve been focusing a lot on these discovery phases, which is meant to answer the questions that you just asked. Again, like I said, it’s very useful, it goes a long way to streamlining the process, and ultimately results in a better end product.

Ben Aston: Yeah. Part of this is in order to be informed, understanding our clients; it’s understanding what success looks like for them from a business perspective; it’s understanding the users, and their needs, and what’s going to resonate with them in order to drive that business success. But the other thing that you mentioned was all about being informed in terms of best practice, and actually, the way that you described it is leaning into a few disciplines.

Now obviously, you come from a development background and design, and so you’ve got experience in that. What does leaning into disciplines look like for you? How do you acquaint yourself with QA or, I don’t know, UX, things that you’re not entirely familiar but some kind of basic knowledge sets you up for success in giving that feedback?

Ryan Schaefer: Sure. Yeah. So hopefully, when you are becoming more familiar with this to the point where you feel like you can provide more granular feedback to your team members, it’s done in a diplomatic and objective way, so it’s not subjective.

But the way to become familiar with those things, I’d say it’s, again, you need to talk to as many people on your team as possible, and being vulnerable with the gaps in your knowledge. So if I came from a development perspective, I’m not as familiar with the user experience there; I should not be afraid to shadow or look over a UXer’s shoulder as they’re going through some sort of big audit.

And the other thing, I think, is just do those things. There are a multitude of resources out there if you want to start coding, also to start designing. You can get a lot of inspiration from projects that your team has done. Start to notice trends and things like that and just read some articles. I try to spend five hours a week stumbling my way through designing something, or trying to keep my coding skills intact, and reading articles. I think the other part of that is the more meetings you’re in, the longer you work in digital, you just organically absorb that kind of stuff.

Ben Aston: Yeah. What are your go-tos for … Yeah, what sites do you go to to stay up to date with stuff that’s going on?

Ryan Schaefer: Thedigitalprojectmanager.com. It’s a good one.

Also, a Girl’s Guide to Project Management is another good one. Ad Week is a good one to see where the creative space is headed. In development, it’s not a news site, but W3Schools has resources for trying any single effect you want, whether it’s CSS, JavaScript, or more backend stuff. Those are good places to get started.

Ben Aston: Cool. You talked about honing your own skills and I’m a big believer in that, in hack projects and side projects of your own to get familiar with that. You can have so much more of an informed discussion with a developer if you’ve got even just a basic understanding of how things fit together and how things work.

So yeah, start making something. Make your own portfolio site or whatever it might be. It’s one thing to read it, it’s another thing to actually do it yourself and try and see what happens. When you tell the designer to just do something, having a go at just doing it yourself will help you understand how much or how little effort that is, which I think can really help when we’re giving people feedback.

But I’m curious if you’ve got any stories of how or if this has backfired for you at all because I think there’s that element in which, when we’re giving feedback to people, we might think we’re informed, but it’s their job, they’re the professionals. So I don’t know if you’ve ever had people say, “Shut up Ryan. You’re not the designer. I am. This is what I’m being paid to do. I don’t value your feedback here.”

How do you navigate your way around that, people not taking your opinion seriously because you’re just the PM?

Ryan Schaefer: Yeah, so that has not happened to me yet, fortunately. I think part of that is because of the great people I work with, but another part of it is if you really focus on coming at it from the client’s perspective, that is a view that your team has to and will respect. And particularly, how the decisions they’ve made, the logic they created, this systems they established directly relate to the objectives that we have defined and agreed upon at the beginning of the phase.

So it’s less like, “I don’t like that color,” but it’s more like, “Well, we know that their brand guidelines use this as a tertiary color. It’s taking up a lot of real estate. Is that something that’s going to be off-putting to them?” And then your designer has probably thought about that, and they will have a rationale, and if it makes sense to you, it’ll make sense to the client. And if they haven’t thought about that, then it’s good that they know, and then they can either step through that process for coming to that decision, or they can make the necessary adjustments if needed.

Ben Aston: Cool. And I think one of the things that I think’s really helpful that you mentioned in your post is remembering the fact that it’s not just down to you. So yes, we can provide that client perspective, but you mentioned bringing in the right people to have some of the tricky conversations. So if the designer is using the wrong color, remember it’s not just down to you; you can bring in the creative director and say, “Hey, do you think it’s okay to use this other color?” And get other people’s perspectives as well and not just carry this burden of having to be the guardian of everything that’s right and true to yourself.

But one of the things you mentioned in your post as well is planning for different responses from your team. You talk about different people respond to feedback in different ways, and you talk about giving some tough love, and also motivational interactions, but making sure you’re not muddying the message.

I think this is a really challenging thing because we want to be nice to people, we don’t want to hurt their feelings, but how do you strike that balance of the tough love and not muddying the message, but also still trying to be constructive? This is another thing you actually talked about is giving constructive praise. How do you give that constructive praise whilst making sure you’re not muddying the message in your feedback? It sounds pretty complicated.

Ryan Schaefer: Yeah, and it’s not a science, and I wish I had a good like, “Here’s steps one, two, and three.” I think a lot of it is, as the PM, you probably have a degree of emotional intelligence and that will allow you to read and react to how people are taking your feedback on the spot.

But I think the primary thing that helps mitigate any sort of negative reaction, and how to discern whether somebody needs motivation, or whether somebody is discouraged, or whether somebody needs tough love is to just be specific. So you, as a PM, you’re not advocating for subjective things because it’s probably not your place to do that. You’re advocating for objective decisions, like I mentioned, as they tie back to the goals of the project.

And then another thing you should always try to do, and this goes a long way no matter how people respond, is to subtly convey that you have confidence in their ability to execute upon the thing that they’re doing. So it’s encouraging to people, again, no matter if they take constructive criticism personally, or if they’re really indifferent to that, and that they’ll just use it as things to grow upon.

But I found those … I like to hear good things about myself in almost any context as long as it’s not patronizing, and if you’re specific in your feedback, that’s ultimately not a patronizing thing.

Ben Aston: Yeah. So just as we close and we think about if people have listened to this podcast and are thinking, “Man, giving feedback to my UX team or design team, I don’t think they’ll ever listen to me or listen to what I’ve got to say because they just think of me as an admin kind of person,” if there was one first step, one important thing to remember for people who are feeling like their voice doesn’t count or matter, what would you say to them?

Ryan Schaefer: I would say the first time you see something that looks off, or something that looks wrong, whether it’s a prototype, a design, or whatever, you don’t have to voice your opinion right away, especially if it’s the first time. Just take some time, go back to your desk, look at it, and make some notes. Come up with where you think the design, the artifact is missing the mark, and importantly, suggestions for improvement.

This gives you time to go through the exercises that they go through, and it also helps you come prepared to have a lot of, I wouldn’t call it research, but certainly helps you make the case for some of the things that you’re suggesting. And again, the more time you take, the more thorough and comprehensive you can be, the more your team member will respect it and the more open they will be to incorporating that in their next iteration.

Ben Aston: Awesome. Yeah, I think that’s really sound advice. I think people can sometimes get their backs up when we just say, “Hey, I really don’t like that. I don’t think it’s very nice,” or something, or, “I don’t think that works very well.”

But yeah, taking the time, particularly if you’re not sure about your opinion, taking some time to really evaluate why is it that I think this isn’t right, and having a rationale for, “Okay, well I don’t like …” Well, you don’t need to say that. “I can say I don’t feel this is quite right and the reason I don’t think it’s quite right is because of x, Y, and z, and the client’s told us that it needs to do this, and I’m not sure how that’s going to happen. Can you help me understand how you think it’s going to do whatever it’s supposed to do?” And we can ask, we can dig into this and ask questions to the person who did the work, and then we can say, “Well, here’s what I was thinking could be a way that we could deliver on that need that we’re trying to achieve.”

Yeah, having a rationale, asking them why or not the rationale they’ve come up with kind of aligns with that, and then proposing some solutions, I think is really important. Just doing things on a whiteboard, if you can. I always sketch things out in a book or do it on a whiteboard just so it feels, you know, you’re not taking over the design or anything, you’re just coming up with some ideas. It might help them be more effective to what you’ve got to say.

But Ryan, thank you so much for joining us. It’s been great having you with us.

Ryan Schaefer: Thank you so much, man. Appreciate it.

Ben Aston: So I wonder what you think, if you’ve ever tried giving feedback, and how was it received? Was the team mad or were they happy that you’d pointed something out that they hadn’t thought about?

Tell us what you think. Comment on the post, and head to thedigitalprojectmanager.com to join our Slack team, and you’ll find all kinds of interesting conversations going on there about all things project delivery.

And if you liked what you heard today, please subscribe and take a couple of minutes to leave an honest review for the DPM podcast on Apple Podcasts. We really value your ratings and reviews, so thank you very much for doing that.

But until next time, thanks for listening.