When it comes to big projects like user onboarding or product roadmapping, you can't just check the box.

It has to be a mindset shift.

But how do you effect that kind of change in your organization? How can you get everyone onboard to move in the same direction together?

We tracked down Janna Bastow, co-founder of ProdPad, to discuss just that. We picked her brain to find out how to align your internal organization to get stuff done, how to inspire coworkers and stakeholders, and how to prioritize change all while handling internal objections.  

Watch the full talk below, or read on for our favorite answers from Janna.

You've done a talk on how to survive the hardest part of product management. What is that hardest part, and why is it so difficult?

Janna: So really, where I started with that talk was thinking about the challenges that product managers actually have. And at the end of the day, it's not some set of hard skills. It's not about whether you're a good coder or a good copywriter or a good seller or any of that. It's about how well you deal with people.

So, I'd actually say that people are the hardest part of product management, and that's because they're unpredictable. They have opinions and attitudes and politics and all these other things that play into it that can't simply be taught from some Medium article or some class that you took in high school. 

It's really about how you empathize with people and how you communicate.

Margaret: It sounds like a lot of people in product are good at their job, but not necessarily haven't practiced people skills as they move into their career.

Janna: Yeah, absolutely. I mean we see a trend looking at how people interact with things that we deal with Mind the Product. 

We run a series of workshops, and we've asked people in the past using surveys, what are your biggest challenges? At the top of that list is stakeholder management. And yet, when we offer a series of classes, things like product psychology, design, data analytics for product people, and stakeholder management, fewer people choose to learn the stakeholder management. 

They seem to think that the hard skills are the ones you can get them the furthest, when at the end of the day, good stakeholder management is at the very core of good product management.

Margaret: Interesting, what do you think that disconnect is?

Janna: I think a lot of product managers suffer from a bit of the imposter syndrome. They feel like everyone around them knows what they're doing, and they're gonna catch this product person for not knowing what they're doing. 

My colleague and co-founder Martin Eriksson talks about this, about how product managers are generalists in a specialist world. You're a single person surrounded by a whole bunch of developers who can code way better than you probably ever will, a whole bunch of marketeers who can write copy and create a campaign better than you ever will, salespeople who can talk their faces off and sell things.

And the product manager is probably okay at a number of these things—maybe pretty good at them. But they are generalists overall. So when you're laying out what you're good at, it's hard to say I'm good with people and have that outweigh your hard skills or what you perceive to be your hard skills.

I think it's actually a confidence thing and a misunderstanding as to what actually makes a good product person.

You mentioned salespeople. You have a background in sales. What are some sales skills that have helped you in product or can help somebody really sell a mindset shift or a process change internally?

Janna: I kind of fell into sales. I fell into product management as well, but when I was going into sales—more than anything—I realized that it wasn't about learning some pitch and being able to recite it verbatim. 

That doesn't work; people's eyes just glaze over. 

Good sales, at the end of the day, is actually just about asking the right sorts of questions, and then taking that potential customer or that person on a journey with you so they can see for themselves how something new in their lives—whatever it is you're offering them—is going to add value or change things for them.

Let's say your team has already worked on a project that you're trying to advocate for—maybe they've tried product roadmapping in the past, and it just didn't work for them. How do you deal with those objections?

Janna: Yeah, I mean just with everything else, diving in and asking why. If you were to ask the five whys on a process change like that, you'd probably get down to some really deep-seated aversions to something—whether it was a previous process or previous boss or something like that.

For example, we just implemented OKRs (objectives and key results) within our company. Before we started, I asked the team, "who here has had OKRs or KPIs at a company and it didn't go well?" 

And a few hands went up. 

So, before I started going into why we're going with it, let's figure out what went wrong the first time and make sure that when we're talking about this new solution—which may or may not be a magic bullet—we should figure out what went wrong before. 

Figure out what the natural aversions are or what are the deep-seated fears that people have, and address those as part of the solution.

Margaret: I did an interview with the company Four Kitchens, and they do pre-mortems, where they talk through all the ways that you could kill a project before it actually begins. Everyone on the team then recognizes what could go wrong and how those behaviors manifest. It sounds like you're doing something similar to figure out what went wrong how to move forward to implement a system that actually works.

Janna: Pre-mortems, I really love that. It reminds me a little bit of—and I'm not sure if this is true or if it's an urban legend in the tech world—but Amazon, before they launch any features, they actually write the press release first. Because if the press release isn't something that the press would take up or if it's not compelling, then there's no point in building it. 

If it doesn't get customers excited, if you're not able to sell this thing that you're going into, then what's the point of building it anyways? 

And that way, they're actually figuring out what is the value that we're really driving here? 

Once they've solved that, then they've got a much clearer idea as whether there's value in going into it.

I like that, the premortem.

For PMs who are brand-new to a particular team—whether they're changing teams internally or coming into a brand-new job role—and the team happens to be dysfunctional. What are decent first steps that they can implement to bring people together and create a more healthy working relationship?

Janna: To anybody in that situation, remember that every team is dysfunctional. It's like a family. 

There is no perfect team that could be fed by a single pizza and looks exactly like what you've read about in different books and articles. Every team has different levels of ability, different backstories, everything else. 

What I find can be really effective is getting people away from their day-to-day work, getting them away from their desks, and getting them to work on something outside of the norm. 

At ProdPad, we do a company-wide team offsite. We just got back from an island in the UK called the Isle of Wight. We rented a big house there, and it had terrible WiFi—there's no point in even trying to get on laptops. And we just spent the time in a mixture of discussion and playtime and just getting to get people away from their desks. It was a really good way to get people to work together that way. 

One of my favorites exercises is something called the Product Tree game. What it allows you to do is pull different people from different areas of the company, someone from sales, someone from marketing, someone from support, someone from development to work together. 

You use a tree-shaped glyph on the wall, where the trunk represents your existing features, and the branches represent the different areas where your product action might go. You use Post-it Notes to prioritize as a group what kind of things live on that roadmap versus not. And out of that, you'll actually start validating and understanding getting the shared understanding of what your vision is, what directions you can go in.

Not only that, but also you also look at what kind of technical infrastructure would it take or what would it actually take as a team to pull this off. Again, it's not a silver bullet; it's a way of just getting people away from their desks talking about something so that you when you come back as a product person saying, right, this is the direction, this is where we're going. It's not you as the product manager's come up with it. It's them as a team who helped create this vision and helped solidify this vision, and you're presenting that back to them.

Let's talk about managing up and getting some executive buy-in. Do you think it's important to get buy-in from the executive team when you're building a product or feature or is just approval fine? 

Janna: So maybe I'm a little bit of a cowboy, but I've always found it is easier to ask for forgiveness than permission. 

So long as you're not throwing massive swaths of cash out or wasting lots of time. That's the whole point of working in small, testable increments and making sure that you're actually working towards something. 

As long as you're able to show that you are keeping your eye on the ball, you understand the company vision, the product vision lines up with that, and your roadmap is able to articulate that these are the problems we think we need to solve. Now, leave it to me as the product person and my team as this inside engine to understand as to how are we going to solve that problem.

We don't know yet. We're not going to make promises on what we're going to deliver you, and as my exec, you shouldn't care how we're going to deliver. 

We're just going to solve this problem, and we're going to keep going at it until the problem is solved. Our method for that is to test, iterate, build, learn. 

It's not to come up and make up a whole bunch of features that we're going to tell you at the beginning of the year we'll build. And then may or may not actually build them. Even if we do, maybe they don't even solve the problem. 

So once you actually get your exec buy in on your process, then it's a lot easier to have that autonomy as long as you can show that you're still pointing towards that same company vision. 

Everyone understands that underlying imperative that you've got.

Hypothetical situation: Let's say you get to the point where you're about to release a feature and something happens that I've heard called the 'executive swoop and poop'. Are there ways to prevent that? 

Janna: I'm not actually familiar with the the executive swoop and poop. I can picture where you're going with this is and sounds like—

Margaret: It sounds like a seagull. I imagine a seagull in a suit for some reason.

Janna: Perfect vision. I picture a HiPPO—you've heard the term Highest Paid Person's Opinion.

Margaret: There you go, a HiPPO then!

Janna: They will always outweigh your own opinion simply because they're higher paid and they've got a bigger title. The only way to defend against the HiPPO and I think it gets the executive swoop and poop is to bring data to the table. Now the thing is with data is that you don't need a fully complete end-to-end conclusive report. 

You won't have that at the ready, but you should be ready to talk about the different points before you start a project. You should understand as to why you're doing it and have points of data that you're planning a measuring. 

These are things that you can do before the executive swoop and poops at all. And that way, when they come in with something, you can say, no, we're not doing that because this is what we're trying to do here, or we have this limited time, or we have this constraint. 

And there's always some constraint that prevents it from being changed, but also listen with an open mind because there's often good ideas that come from everyone, even if they are the pointy-haired boss. More than anything, ask questions. Figure out what it is they're trying to do, right? What's behind this swooping in and changing your specs or ripping it away? 

Are there other ways around, are there ways to solve that problem that they've come up with? 

And usually there are.

How can you get executive buy-in when you're building a product within a company that has a super sales-driven culture?

Janna: Oh, that's such a good question. I hear that one all over the all of the place from all different types of companies. 

The thing with a sales-driven culture is that the company itself, if their imperative, if their process, their way of working is to build things that solve problems for the salespeople and therefore, for the end clients, they're always gonna be limited in their ability to make change because every time you make a promise of Client X is gonna pay us $100,000 to do this by end of the month.

That's great, but that means that you're getting the $100,000 if you do it right, but your month is wiped out. You can't do anything else in that. And in order to hit those dates, you need to add certain amount of buffer, otherwise, you're making really risky promises

Some companies are actually amazing at making money this way—taking in client requests in exchange for money and delivering things. Those companies are called agencies.

And there's nothing wrong with being an agency. You can make a killing doing so, but you won't change the world. You won't become the next Facebook. You won't become the next major product company who's really iterating and figuring out the world's problems, solving for those, you will always just be solving for that next paycheck. Again, no shame in that, but at the end of the day, a sales-driven company cannot be as lean or as effective usually as a company who is perfectly lean. 

Now, the thing is I like to think about companies on this continuum, on one side, you've got the super nimble and lean companies. This is a company who started on Tuesday. They've got a copy of Lean Startup under their arm and they're ready to use it in anger. They can iterate by Thursday 'cause they don't have customers—they don't have tech debt. They can do whatever they want.

On the opposite side of that scale, you've got the super slow moving, risk-averse companies who can't change, possibly because it's even regulated, they're government, banking, healthcare. They can't just remove a feature or change their business plan, because that would be against the law. 

Now most companies find themselves somewhere on this continuum. The best companies are the ones who find ways to push themselves more towards that lean. So perhaps that means having, if you're more sales driven, saying, yes, we're gonna have a sales-driven wing, but we're also gonna have an R&D or a product-driven department that we're gonna carve out and whether they do that using a team of people who are just looking at that next picture and how to disrupt themselves. Whether that's doing hack-a-thons, whether that's creating a lab within the company, the best companies are able to both find ways of funding their business, whether that's being sales driven or however, but also finding ways to build for the future, really, really think about how to be product driven, how to be lean and those things that they're building in that more nimble and lean mindset are often the things that are disrupting their competitors and themselves. 

These are the future products.

Do you have any advice for forcing executives to clarify strategic goals when designing new products? 

Janna: Yeah, that's never a comfortable situation. With any strategic goal that's given, drill that into the few questions, like what are they actually expecting it to look like when it's done, and what does success look like? 

If they can't define that, then there's no point in having a goal for it because you have no idea if you've ever met that goal. So you need to have that level of measurability or at least tangibility so that you know what it is you're going for. 

And with anything, ask the questions as to why. What is actually driving this? 

Because at the end of the day, most execs just want that bottom line to move. They want to make more money or if they're not for profit, they wanna raise more money. 

Most companies are in it to make money. That's the bottom line, and so if you can drill back to that path going, your goal was this and the way that you think that's gonna get us more money is this, this, and this, but actually, if that's your goal, then what about this angle here? And looking at different alternatives and figuring out how you might actually pick that through in a different way. 

So, asking lots of questions, but also getting clarity on what does this actually mean for us and, no, don't tell me build X features. That's not what we're trying to do. 

Tell me to solve which problems and then we can clarify what those problems are and validate those problems, but them giving you a made-up goal with a list of features is not good product management. 

That is much more around, that's waterfall project thinking more than anything else.