The Paul Ortchanian Hypothesis: Informal Conversations are Key to Building Influence

Paul works as a consultant, coach, keynote speaker, and author with extensive experience in the world of product. Through his leadership, numerous businesses have been successful ranging from startups to high growth companies alike. He is the creator of a number of product management methodologies including the SOAP™ planning and prioritization framework.

In this episode of the Product Science Podcast, we cover how to clean a product roadmap of bad ideas, how to increase team collaboration, how to help new ideas gain support, and how to leverage informal socializing to better connect with other teams.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, and more. Love what you hear? Leave us a review, it means a lot.

Resources

• Follow Paul on Twitter
• Follow Paul on LinkedIn
• Bain Public
• Follow Holly on Twitter
• Follow Holly on LinkedIn

Questions We Explore in This Episode

How did Bain Public get started? How does Bain Public help smaller companies grow? How often should a product manager be road mapping? What is the S.O.A.P. method of cleansing a product road map? How can much can a market change in only 3 months? What communications and insights do teams develop when practicing the S.O.A.P. method once a quarter?

What happens when a product is lead by sales and marketing? How can being sales lead complicate the product roadmap? How do product teams validate feature requests and ideas? Why are so many founders driven to growth at all costs? How can being sales driven cost your business more in the end? How can introducing process help ensure consistent deliverables? How do feature releases affect sales, marketing, and customer support before the release is truly ready?

Who makes up the product leadership team? How do you show the executive team that the problem is with strategy and not personnel? How can you get buy in from different members of product leadership? How does a product manager decide between competing ideas and interests from different teams? How can repeated process help align teams behind a shared strategy? How is getting the leadership team’s consent more important than getting their consensus?

During a company’s growth stage, when should a product manager get involved? How does being founder driven change as a company grows? Why are sales and marketing usually the first teams driving growth strategies?

How do you improve collaboration between teams? How has remote work and the pandemic affected communication between teams? How can pre-wiring an idea before a meeting help reduce resistance to it? How can informal communication help promote collaboration between teams?

What is the human element that product managers can bring? How can being the smartest person in the room hurt your ability to collaborate? How do product managers better relate with other teams? What kinds of questions should you ask other teams? How can utilizing other teams to source your data help promote accurate strategies? How can a product manager help unify a high level strategy?

How has software development changed over the years? How did product management develop into a discipline? How was ECommerce utilized in the early 2000’s? What was it like working on the Palm Pre ? What were the final days at Palm Inc like before HP acquired the company? How much support should a product manager expect to get from leadership?

On average, how long do product managers stay with a company? What signs should you look for to know if a company is a bad fit for product? How do you challenge a company’s history to retry a failed strategy? How do you change a company’s practices to help them scale? Why are startups able to pivot faster than older businesses? How is being a product manager like being a therapist? How can socializing at work events help create social clout? What strategies are there for socializing at work? How can you tell if you’re being successful as a product manager? What metrics can you measure your success by?

Quotes from Paul Ortchanian in this episode

Those features that aren't important or necessary cost a lot to the company because that's actually time and energy that you're not going to recuperate.

Product managers are oftentimes set up to fail when there is no high-level strategy.

If you're using your ears twice as much as your mouth, you will be able to ask the right questions and use that listening to influence them to try something new.

Transcription

Holly:

This week on the Product Science Podcast, I'm interviewing Paul Ortchanian. Paul is the President and CEO and founder of Bain Public, which was sold to X Machina. Paul is an exceptionally knowledgeable and well rounded in all aspects of product management. He acquired the breadth of experience to find common denominators to make businesses successful through his leadership roles at San Francisco Bay Area startups and high growth companies.

A true consultant coach, keynote speaker and author all wrapped up in one, Paul is a pro in injecting strategies and tactics to monetize his client's businesses. He writes a popular product management blog and is the creator of a number of product management methodologies, including SOAP planning and prioritization framework. Welcome, Paul.

Paul Ortchanian:

Hi, nice to have me at your podcast.

Holly:

Yeah, thank you. So you mentioned in the pre-chat that Bain Public has an interesting story behind it. So I'd love to hear a little bit about that.

Paul Ortchanian:

Yeah, a lot of people ask me if I'm part of Bain Consulting Group and actually it's pronounced bain public which is a French word for public bath. And originally when I started the company, I always saw roadmap as a cleansing experience as a product manager's role is to basically take all of those bad ideas, good ideas, and basically work with the leadership team on identifying which ones are going to add the most value to the business and which ones are going to add the most value and growth to the customers that we have.

So in some ways, road mapping is something that you do just like hygiene, you do it quite regularly and you need to basically cleanse yourself from the dirt, all those bad ideas, and eventually move with things that actually make the most sense for the organization.

So the idea of Bain Public started from there was cleansing exercise. And since we were on the theme of hygiene, we decided to create a framework, the methodology that we use and we called it SOAP since it's just the way anybody should cleanse their roadmap.

Holly:

Ah, interesting. Can you tell us a little more about that methodology? How does it work?

Paul Ortchanian:

Yeah, it's nothing extraordinary. It's just the best in breed of product management put together. The biggest issues we see, and I basically focused all of my effort in Montreal first because the Canadian product ecosystem is broken based on what I solve coming by from Silicon Valley where there is no understanding of what a product manager does and what the difference is between them or a project manager, et cetera.

And oftentimes we realize that product manager gets hired in an organization and they don't know what they need to do any given day, any given week. And there should be particular process for a product manager. If you were to just look at it within a three-month timeframe, a quarter, a lot of things can happen within a quarter. The industry can change, the market can change, the consumers can change, the competitors can come up with new features. So it's important for product managers to at least get into this habit of basically just looking at what has changed and going back and grooming their backlog and developed this consistent, stable and familiar routines that basically not only he or she knows how to accomplish, but also the leadership team, as well as all the other teams that are working around the product and engineering team can get accustomed too.

So the SOAP framework is basically what do you need to do every week, what do you need to accomplish as a product manager every single week in order to move your roadmap forward? So the first three to four weeks of any given quarter are really focused on strategy. Just making sure that you're rebaselining things if things have changed drastically, if there's a pivot or persevere decision that needs to be with the CEO. And then from week number four to eight, I would say you're really looking at your backlog or your parking lot of ideas, your galaxy of ideas, grooming them, understanding them, trying to find the problems and collecting them from different departments.

And then there's the prioritization process with the leadership team, which includes a lot of engineering scope discussions and definitions, and ultimately the enablement of that strategy or those roadmap decisions to the marketing team, to the support team, to the sales team so this way that outbound communication could be done.

So I call that 4Es. So it's evaluate the market, execute on your evaluation of the market. You got to enable with your team in order to get that roadmap out. So if that process, if we were to encapsulate everything a product manager should do in a three months timeframe, let's put it all together and call it SOAP. That's basically what we do at Bain Public is we work with organizations on putting those processes in place, both from product manager perspective, but also from the leadership perspective so this routine of doing this on a regular basis every three months, we're doing the same things get reinforced the repetition and communication and eventually the entire product is being led by the product team rather than being led by sales and marketing.

Holly:

It's interesting what you just said there about product team is being led by the product team itself versus being led by sales and marketing. Can you tell me a little more about the [antipater 00:04:57] there, about the bad version?

Paul Ortchanian:

The bad version is, there's a lot of founders of organizations who believe that their organization can grow by increasing their footprints. Like the footprint expansion is a very, very tempting and easy thing to do. You can increase your footprint by marketing or by deploying a sales team across industries, across countries. And there's no bounds to the amount of closing you can do as a sales team.

Ultimately, though, what happens is when the sales team collects all of those needs of the various industries, various geographies that they're closing deals on, they can basically create a backlog of things that don't really exist with the product, but nonetheless, they sold it. So now the engineering team is whiplash by all these sales requests. We need to make sure this works for left to right languages. We need to make sure that this actually works with euros versus pounds versus compliance, regulatory, all these issues prop up and the product team is not involved because they're just basically being taken over by this expansion that's very aggressive.

So founders who usually try to balance things out by saying, okay, we're going to do expand our footprint at a pace of our innovation, and we're also going in the meantime start looking at the optimization that we can do in our workflows in order to increase our margin. So if a company's basically looking at how they could basically grow and scale at a pace where it's not just being driven by sales, then the product team can empower itself and allow for all these problems that are coming from all these various departments, let it be innovation needs, let it be a footprint expansion needs, or optimization needs basically all together to be able to provide value for the organization.

So it's too often that founders, maybe they have this growth at all cost that comes from venture capital injections where product might not be mature enough, but the growth at our cost basically creates this fake it till you make it culture where the product manager is told simply to make it happen. And if it's manual, if it doesn't create efficiencies, so let it be because we just want to serve our customers. And eventually what happens is that you end up with a problem where for every 80 cents that the customer's paying, it's costing the company a dollar because every feature that was implemented by the engineering team without the knowledge of the product team because they didn't define the what's really, it was just basically the customer needs X and we need to implement X.

So that basically comes with increased cost of support, increase cost of general administrative because from high churn that can come with increased cost of rework from the engineering team and loss of trust from the marketing team who doesn't want to promote a product that's broken. So eventually that cost is something that burdens the company. And there's more companies that die from indigestion than from starvation. So I feel that being sales-driven can really lead to just carrying extra for nothing. And that's usually what I use when we are talking about what's the benefit of a product manager.

Holly:

So tell me more about how you help a company that is struggling with too much sales leading the product? How do you help them to transition?

Paul Ortchanian:

Yeah, eventually you have to come face-to-face with the problem. And the problem is a human problem. This lack of prioritization that's happening and the internal politics that it's creating because it's being driven by sales, but their sales teams in different countries, different geographies. So oftentimes it creates this loss of direction where the company are spinning constantly and people can't find the north, or the sales team can come in with more requests faster than any other department of a company.

As soon as the prospects mentions something, it's definitely go straight to the backlog. So the product team is really set up to fail. And even though they're trying to work very hard, as well as the engineering team is trying to work very hard, you have a lot of employee burns and you get less done in some ways.

So we basically approach it from a behavior discipline people issue perspective. Ultimately it's all about acknowledging the wasted resources. Engineering time or engineering energy is constantly being wasted by releasing features that don't get used, aren't getting communicated adequately by the sales or marketing department or basically are failing to meet the needs of the customers.

So those features that aren't important or necessary cost a lot to the company because that's actually time and energy that you're not going to recuperate. And so it's just acknowledging the burden of these unneeded features, and then how can we basically come in and help? So what comes down to putting a process in place that is collaborative. It's about a collaborative discovery. It's not just a sales team or marketing teams. At least it so has to be the CEO. The CFO, CFOs have a lot of information, the CIOs.

So the C-suite together, which basically we create, we call those the product leadership team. So that's basically the executives or the VPs and directors who basically have a say in the evolution of the product. So the question is like if we were to establish this team and this team is supposed to empowered a product team and basically nurture them and give them tools and processes, the question is, if you have a role to play, the first element that we need to align on is this high level strategy, this base lining of what are we trying to accomplish with this product? In other words, what's the mission or the vision of this product? What are the various strategies that we're going to use in order to get wherever we're trying to get to? What are the tactics that are we going to use within these strategy and what metrics are we supposed to move, so this way we can always identify if we're actually moving the right direction?

So by collectively working with the leadership team, the product team is able to go back and forth and figure out this strategy, these tactics, these metrics, and eventually propose in that align themselves to these strategies, tactics, and metrics. And once these initiatives have been presented, then collectively the product leadership team's role is to, if you have six initiatives and you only have resources to accomplish two, then how do you choose the two?

So it comes down to collaborative decision making and a product manager needs to be able at that point to maneuver through these humans, which are the various directors and leaders to make sure that these conversations have a beginning, a middle and an end and not just end up being full of grenades and potholes and tangents that basically lead to nowhere. Ultimately you want to make a decision.

So I think that ultimately one of the things that we like to do is talk about what's whose responsibility? So leadership team is really about hiring and developing a very strong product management team. It's the design to nurture, to build. These are very important things, but it also involves offering guidance, direction, but not really telling them what to do. They're there to empower and foster collaboration.

So how do you basically create cross-functional trust by bringing in a product manager or a product management team into culture where the sales team, the marketing team, the CFO, the CEO, as well as the customer support team, VP or directors can collaboratively discuss the future of the product, the roadmap that's being proposed and collectively gets to give the green light on particular features or initiatives that are going to move forward?

So there's this difference between consent and a consensus. So ultimately a product manager role isn't to build consensus amongst this leadership team and nor should they basically all get alignment and full agreement on everything. It's hard enough in a normal organization to get two people to agree to something. Imagine having a bunch of C-suites agree to everything.

So I basically just try to get to consensus is not something that we're going to get to, but when a product manager comes to you with three or four initiatives and they all align with the tactics and strategies that you guys baseline, and ultimately you can only choose one or two, I just need consent, which means you do not agree, but you give me the green light to move this forward because ultimately it's for the good for the company.

Holly:

Yeah, that's like the Amazon saying about disagree and commit.

Paul Ortchanian:

Exactly. I always call it the fortitude, the constitutional fortitude to say that we're actually going to do this and we're going to be honest about it. We're going to do it and we're now going to go and start doing something else. As long as that honesty is there, and usually the commitment that I try to get from the leadership team is, give us three months to figure this out and deliver it. And if anybody asks, when is this going to be delivered? It's going to be delivered at the end of the quarter.

And if the engineers have it ready by, let's say two months, then the sales team still needs to prepare itself. They need collateral. There's pricing decisions. The marketing team needs to update it on the website and they need to plan a campaigns, press releases, et cetera. The support team needs to create how-tos videos and talk to prospects and customers. So there's a lot of work to be done.

So ultimately it's not really about the date of when the engineers can deliver it. It's really about when us collectively as a team can basically be ready to bring this product to market. So dates ultimately end up being end of quarter releases rather than 17th of January and the 13th of June. Those are usually like those hasty fast releases where the marketing team or the sales team isn't even aware that a feature got released and that's the feature they asked for three months ago, but unfortunately they're not even aware of it and it just ends up fighting everyone.

Holly:

Yeah, so what you're describing is that there's a problem in the industry of, there not being enough collaboration between product and marketing and sales and support where there's so much pressure to ship, that people are shipping products without even having all those things in place for them.

Paul Ortchanian:

I agree. And usually what happens is, when it's a small startup and let's say they're in pre-seed stage or seed stage. Now, the founder makes all the decisions because they founded the company based on some gray zone they identify in the market and they have the knowledge of the industry. So they're able to make those calls. But as they start getting into financing discussions and fundraising and HR and establishing company cultures and hiring new people, they get really busy. So this gridlock develops where everybody's expecting these founders to make the decisions, but they just don't have the time or the data to make the decision. So ultimately marketing and sales step in. And it's very normal because they're a profit center. Sales closes deals and they get a lot of clients and a lot of requests come from clients, the same with marketing.

So it's important to, at that point for leadership team, to put in the right process. Do I need a product manager? And if I need a product manager, what should I expect from that person or that team within a quarter? And do I tell them what the strategy is? Do they challenge me regularly on the strategy and collectively we make a decision?

It's getting harder and harder to do it since we've been working more in these distributed teams like COVID is one reason. But a lot of companies are also trying to work with engineers in a different department and various executives in different cities, working on Zoom, really isolates the product manager from having to get into this collaborative discussions. And it's hard to basically grab all six of them together.

So one of the things that we try to tell product managers is, try to pre-wire. Pre-wire is a word that came from McKenzie where they basically describe it as the meeting before the meeting where you try to synchronously, you try to go talk to every single leader from your organization five to 10 minutes informal, just validate something, just get their perspective and make sure that they're sympathized with what you're trying to present. And eventually bring them into a meeting and to discuss it rather than just waiting for the meeting and just bringing your ideas forward in isolation, which ultimately is going to create a lot of naysayers who basically just gets shocked or taking aback by whatever you're proposing. Even though you spend six months on it, that doesn't mean that they've heard of it.

So I think the jerk reaction is to say I'm against it or I don't agree. And that basically creates more trouble than anything to the product team. So I think it's important for the leadership team to initially invest in this collaborative culture. Let it be in-person or let it be virtual, allowing a product manager to go and talk to the VP of marketing, to have a discussion informally with the VP of sales and not to basically create silos between these departments and just say, "You guys work with engineers. We tell you what to do and just bring it downstream." That's a project manager as far as I'm concerned.

Holly:

Yeah. So do you have any stories from your career of this collaboration working out really well or conversely stories of it working out really poorly?

Paul Ortchanian:

Yeah, absolutely. My first job as a product manager in San Francisco, I got fired. I love to talk about that story. And it's because I was the guy with the chip on his shoulder who knew everything about the customer, who knew everything about the data, who knew everything about the industry and market because that's what they tell you that you should do as a product manager. You should be knowledgeable about everything.

So I just went out there and started the industry in isolation and I studied the market in isolation and I spoke to customers in isolation and I look at the analytics in isolation and the competitors in isolation. And when I got into a meeting room with the marketing team, their competitors studied didn't align with mine, their perspective didn't align with mine. And instead of just listening and taking that in and really using that to truly understand, I was just making a case, you're wrong, I'm right.

I did the same with the sales team and did the same with the engineering team and I did the same with other departments and eventually everybody caught onto the fact that I just was the smartest guy in the room and that they just didn't want that guy in the room because he talks too much. He might be right, he might be wrong, but product manager is a human game? Ultimately, if you want to collaborate with others, then you should be open to collaboration. And I wasn't. I was simply fearful of not being perceived as the person who comes prepared. So maybe I was overdoing it, but by overdoing it and sucking all the oxygen in the room, I ended up not creating the collaborative environment for the product to succeed. And despite the fact that the product did well, I think that it was more of a can't stand you, but the product is doing well at relationship.

And eventually led me to being fired just for not being the right fit. That was the only reason I got. My personal interpretation of that is we just don't like working with you. And that's the worst thing a product manager can hear. And I think these days, because we're working these distributed virtual spaces, it's too easy for a product of manager to make the same mistake.

The luxury of working alongside one another coworking in the same workplace is that we should be able to listen to one another, also be the nonverbal cues are more obvious. And as a product manager, you could start working the human aspect of making sure people are aware that you are listening to their needs and their problems and product evolution, but you're able also to say no in order to prevent some bad ideas from moving forward.

An example of where it worked, I could say with most of our clients right now, we try to make sure the product manager is playing dumb. By that I mean you just show up unprepared. Now, that's what I tell most of them show up unprepared to me meetings. So you're going to meet with VP of marketing, just show up and ask what and how questions like what do you think about our competitors and how do you think they're doing? And do you think their features are working? And same with the sales team, what are you hearing from prospects? And what do you think the deals are closing, et cetera?

Try to elicit from them the information you need, the problems they're having. And it's more important to maintain human relationships with these people than to basically try to prove to them that you know better than them. But usually nowadays everything seems to be working fine. And then despite the two years at COVID, the company has grown based on great organic growth because one customer that's the other customer knows that, hey, there's this process that's basically working. And my product manager that I hired has really created a great bond with the rest of my other department. The trust is high, the collaboration is high and we're making decisions collaboratively. And that's really leading the company down a great direction, but I can't take the credit for the companies themselves mainly because luck has a lot to do with it. Timing has a lot to do with it. So if they manage to raise and become successful, I think product management has something to do with it. But again, there's a lot of factors as well.

Holly:

Yeah, that makes sense. So I know that you worked in Silicon Valley for a while and you mentioned the first company that you worked for as a product manager. What are some of the other steps in your journey that were good learning grounds for you?

Paul Ortchanian:

It's funny cause I started it as an engineer doing a lot of flash work. I don't know if you guys remember that Adobe Flash days, but back then-

Holly:

I sure do.

Paul Ortchanian:

What was really interesting in those days was as an engineer, you were also a creative, you were also a product manager. These days, software development is something that's being done by teams who work collaboratively together on GitHub or something like whereas in those days everything was done on one file and one computer with one guy who also had to animate create and design and make sure the interfaces look good, but also make sure that it worked.

So it was a great time where I think that I look learned a lot about various aspects of product management, the definition of the want, the figuring out how to do it. And then basically the trial and error with the customer in order to make sure that things are working.

So we ended up doing... When I moved to San Francisco, it was all marketing gimmicky websites, but then we started going more and more into e-commerce. I worked with Palm and Starbucks and Seagate on delivering their corporate websites that had eCommerce components and stuff. And those were big projects. I remember when the Palm Pre was coming out, which was their iPhone killer just working on the operating system there was a lot of fun and it was just an opportunity to work in bigger organizations that have big structure and product management is lost in all of that.

And how you make decisions and the VPs and the SVPs and the EVPs that are involved in decision making and how do you basically bring a roadmap down that, it gets a little bit harder, but especially like the Palm was quite an interesting situation because we were launching a brand new phone with a brand new operating system, with a brand new website, with a complete like rip and replace from the old and it was just make it or break it. And they ended up basically being sold to HP right after that.

But it was just like this moment in time where we're just striving for that iPhone market. And I realized how hard it is to bring an entire company together. Like in startups, you're working with five or six people, then that grows to 20 and 30 and 40, but it's completely different than hundreds of people. So you need to be a motivator. You need to be able to anchor yourself on this big hairy ambitious goal you're trying to do as an organization. So this way, whoever you meet from any department, let it be engineering, let it be support, we're talking about departments of hundreds of people with various people working in different countries. And how do you basically anchor yourself to this unique goal, this objective that you're all collectively trying to get to?

Product management of those organizations was pretty hard. And I think that's important for our product manager to ask the question straight out from the executives and the leadership team is like, okay, can you tell me what this high-level motivating one liner I can use to basically get all these people lined? What is the big, hairy, ambitious goal here? If you can articulate it, then I'll use it. But if you can't articulate it, then I think it's fair for a product manager to work with them on finding it out because once you find out what it is, it's a lot easier for you to do your job.

Holly:

Yeah, that's one of the things I often find myself coaching earlier career PMs on is that if you're not getting that guidance, if you're not getting that clearer vision from leadership, then you need to push for it. You need to work on building it. You need to have an opinion on what it might be and drive that forward.

Paul Ortchanian:

I think there's two aspects of product managers responsible. I don't think we talk about it a lot, but there's the baselining of the high-level strategy. That's something that can be done with the leaders ship team and revise on a regular basis, which is the motivating reasons behind the product, as well as the reasons why you should say no to people on features because it doesn't align with the strategy or et cetera.

That's one aspect. And then there's a road mapping, which is a completely different thing. You can't roadmap without that high-level strategy, but whose job is it to do this high level? I ultimately feel the product leadership needs to give it to the product team and up to the product team to review it, revise it, and keep it updated and challenge it back to the leadership team on a regular basis, asking them pivot or persevere questions on various strategies and tactics.

Oftentimes we find that product managers are set up to fail where there is no high-level strategy, they're being told what to do, and they just need to bring the roadmap downstream. And I don't know what it takes for a product manager and organization to say, "No, this is not good. And I'm basically going to approach the leadership team. I'm going to ask them to collaboratively figure out what the high-level strategy is." It really depends if they're open to it. And if a product manager figures out that they're not into defining or articulating that high-level strategy, then I think as a product manager, you should actually ask yourself what you're doing in that company.

Holly:

Yeah, I agree. That's definitely an element that a lot of product managers face, especially earlier in their career before they've had a chance to really see a lot of different environments and know what a good environment for a product person to succeed in looks like. It can be hard to know.

Paul Ortchanian:

Well, I think that most product managers spend about a year on average per company they work in. And I find that's very, very telling of how much churn there is, not because the product manager is not good at their job, but mainly if I'm going to spend a year in one company to figure out, no, this is a bait and switch. This company does not have a high-level strategy in, they're not interested in having me collaborate on it, moving on to another one and then doing it five companies in a row for over five years, a lot of people look at that resume and say, 'Well, this guy is no good. He just moved on for five companies. What can he do?"

But ultimately if you didn't find that environment, why should you stick around? And I think it's important for us as a community to acknowledge there are some companies that are doing it right and some companies that aren't doing it at all. I don't think we should build a website to say this company's right and this company's wrong. But it might be interesting too at least identify what are the signs of an environment that doesn't really empower product. At the end of the day, it's a huge difference in if you are being empowered versus if you're not. And I think that if there is a way of identifying that at an interview, it saves people a lot more time.

Holly:

Yeah, if you're able to get that picture in an interview, one of my favorite questions to ask interviewers is, how do you make prioritization decisions here? And I'm hoping to hear from them that there's a big picture strategy and vision that they're working under the confines of, but sometimes it's very clear that's not the case.

Paul Ortchanian:

Yeah, I agree with you that it's sometimes it's clear. Sometimes what you hear from HR or from the hiring manager is one thing. Once you get into an organization and quickly realize that there is a problem that usually takes you six months to figure it out.

I hate that bait and switch situation where you're constantly having to face. But I think the more and more leaders are understanding the value of being product-led, I think it's now become a buzzword, which is great and everybody's seeking to be product-led. And now the question is, what do you need to do to become product-led? Do you expect your product managers to intrinsically start bringing that culture in and fight the big sales team with their rainmakers, or bring in these third-party organizations who can come in and help? And that's where we position being public.

Holly:

So how long has Bain Public been around?

Paul Ortchanian:

We've been around for four years. And within that four years, we've worked mainly with startups, how those startups become scale up, which is great. But we also realized that a lot of SMB organizations, especially brick and mortar organizations who have products and are trying to get into this digital world, have this need of being product-led. These are like older companies that have a serious, good products, but aren't in the digital space. And every time they try to bring their product or innovate through new products, digitally fail. They don't understand why.

And then you suddenly realize that they have everything figured out and they're just hiring some third-party company to basically build it. Basically it's like, "Well, can I have you guys thought about doing this in a build-measure-learn approach and you know, minimum viable product and figure out a roadmap and try to iteratively get to the promised line rather than nailing it the first time around."

Holly:

And what have you been finding when you bring that methodology forward? What is their response like?

Paul Ortchanian:

I think it depends on the company and the culture that's been established. I find that most organizations, like in this case, we're talking about a small and medium organizations, I find that they have stories. Everybody has stories. We tried that 30 years ago, we tried that 20 years ago and you get... As a product manager, you have to spend a lot of time listening to these backs stories they have. Every department has one of why it failed, why it should not work, et cetera.

And then opening them up to the realities of the new world. It doesn't mean it failed three years ago or five years ago that it's not a good idea. You know, sometimes it was just the execution. Sometimes it was just circumstances. Sometimes it was just bad timing. But I do find that there's collaborative discussions, but I find there isn't firm decision making because of the history that company has had in the past.

So it takes a lot to bring in that culture. And usually they suffer from a CEO or a founder who's basically, call it the Moses syndrome where he comes in with these 10 commandments and that's why the company has survived for the last 30 years. And it's very hard to get them to buy-in. It takes a lot of influencing to get those companies to move forward. But it's a great challenge because there's the richness in their products that just if interpreted the right way could work. But there's a lot of also a lot of busy work to be removed. Sometimes like you suddenly get into digital transformation where you realize that the marketing team is working a particular area. The customer support team is operating via email. And you're like, "Well guys, we can't build a company this way."

So there's a lot of efficiencies you need to focus yourself on. And quickly their product management and the roadmap turns from innovation to just efficiencies. How do we basically create process power to continuously improve the company's processes for that company to be ready for a digital product? And do I think that's product management? In some ways it is. Does implementing ZenHub over email product manager? No, but it's a build versus buy decision that needs to be done over a roadmap prioritization process.

And ultimately they go with ZenHub and yeah, it's a SaaS and it's plug-in play, it's easy to go, but it's still the evolution. I don't think a regular startup will do the same thing any ways. They would have to go and implement various tools in various departments. It just so happens that it's done organically because the startup has starting from scratch that they don't have to deal with 30 years of history of managing customers over the phone and eventually over email.

Holly:

Yeah, it strikes me as a product manager and spending so much time in startups hearing the idea that there's two 20 or 30 years of history at a company is an unusual experience. I've worked with clients that are either big e-commerce firms or something like that. And those companies have that kind of history that they've been around since before the internet. But it's also so common for us to work on companies that are less than five years old.

Paul Ortchanian:

Yeah.

Holly:

Navigating that culture of 20, 30 years of decision making must be different.

Paul Ortchanian:

It takes a lot of listening I find. It's like you almost feel you're a shrink having to listen to every department and their stories. But I think once you use your listening powers, I call them powers. If you're using your ears twice as much as your mouth, you actually being able to ask the right questions and basically use that listening to influence them to try something new.

If you don't take the time to listen, you just end up just telling them what to do. And that's usually not going to work because you're dealing with 30 years history of doing things particular ways. You can't change it overnight. So for you to get that influence collateral, let's just say, you need to enter a lot of listening into that bank account. And the question really is, if you're given like six months or one year to turn a company around, how much listening do you need to do before you get there and everybody going the right direction? And at which point can people from the outside looking at you say all I see him doing is just listening? He just gets in meetings and talks, or he is always having coffee with people or having informal discussions, but I'm trying to understand what he's really doing?

And ultimately, you're just trying to... Influence, I feel like is like a back account. You keep adding these brownie points after every long conversation where 80% of conversation was listening and 20% was asking questions. And if you do that over time, you end up with a lot of influence in the bank and then you can start using it. But the people perceive that as being a contributor to productivity, I don't know. So a lot of product measure can end up in those situations and being perceived negatively within three months because they're like, "Well, I don't think things are moving forward." And in some ways you are doing it. You're just being a shrink. And I think product manager is in some ways being a shrink as well. Right?

Holly:

Yeah. I think so too. I often find myself feeling like I'm spending time as a therapist.

Paul Ortchanian:

Yeah, and we need to have those skills, but we also need to be aware of how people are perceiving us and the actions that we do. So the only trick I can say is the using informal conversations rather than formal ones. Instead of getting inside a meeting room and talking to an executive, try have the conversation around coffee or water cooler or outside informally over beers or something. But use the nine-to-five to actually groom the backlog and work on strategy, et cetera. And then do the listening afterwards, which means that you have to commit a lot more time to the job. That's the part where you really start balancing your mental health as well. It's a burden.

Holly:

I like what you just said too about using the nine-to-five for some of the backlog grooming and other things. And then listening after. I think it made a change in my career when I started treating work socialization as work and saying I'm going to show up to that happy hour because there might be an opportunity for me to move forward something that I care about and because I want to build relationships with my coworkers. Is that something that you've found in your career as well?

Paul Ortchanian:

Yeah, I'm a big fan of trying to add to your bank of influence using these informal. So it could just be cigarettes outside. Here in Montreal, people still smoke. So just grabbing the cigarette, even though you're not a smoker, just going outside and spending some time with them. Try to identify by those spaces, especially with the engineering team, that's the engineers usually don't want to speak. They rather speak to compilers all day.

So now the question is, how do I basically get them to listen? And then morphing yourself into whatever culture you're in, I think that ultimately if you don't do it, you're pretty much at risk. It's funny once I interview a product manager who gave me all these soft answers exactly what I'm just saying and I said, "This guy is unhireable." Product management is about hard things like grooming backlogs and MoSCoW method versus et cetera. We like these buzzwords in product and this guy his entire interview was about the human side of things. And I thought it was so soft, but years later I realized how important it is.

Holly:

Yeah, it really is. So we're getting up to the end of our time. And I want to ask you what advice you would give to a product manager who is in this position that you've described where maybe they don't have the right things around them, the right vision and the strategy and things that set them up to succeed? How would they recognize that? And what should they do?

Paul Ortchanian:

I think that, I always say like using the baseball reference that Hank Aaron who's in the Baseball Hall of Fame has a 305 lifetime batting average, that means he failed seven out of 10 times. And I think as a product manager, you shouldn't strive to basically nail every single feature and have it basically contribute to the growth of the company. You just need to get three out of 10 correctly. And if you just take a look at your company, like if the company is maybe hedging 10 bets and two out of those 10 are good one and the other eight fail. And all you need to do is work collaboratively with the leadership team on just increasing that two out of 10 to three out of 10, and your batting average is going to be 300 just like Hank Aaron. So it's not that big of a leap.

Most organizations are doing one thing right. They have some kind of a product market fit. So even though it's not collaborative, even though there's some smart people in the back and they're doing something right. So it's just a question of like, can you identify the diamond in the rough here? And what are the odds of success without a roadmap? It's two out of 10. Imagine if it was three out of 10, the odds of success would be hall of fame [inaudible 00:37:15].

So how can you basically just infiltrate this organization and just have an input of one? I think it's worth a shot for every product manager to try to infiltrate the leadership team and say, "I want trust. I want collaboration, I want empowerment. I want you guys to nurture us. So let's work together." Use the influence skill, the listening skills to be able to at least do an attempt of baselining the high-level strategy of the organization. Giving himself the tools to say no as well as to motivate others. And if that fails and it fails miserably, then it's time to move on. And if it succeeds, then that gives you the foundation for a roadmap and then you can just anchor yourself on that. And then eventually you'll get three out of 10 right and you'll be doing pretty well for yourself.

Holly:

Yeah, I like that analogy. So if people want to learn more about you and Bain Public, where should they go?

Paul Ortchanian:

You can go to bainpublic.com. We have an ebook. We have about 60 articles that we've been published over the years on the topic of product management. A lot of the stuff that we discussed is available there on our blog. We have a medium page. We have Instagram page and LinkedIn page. You can find us anywhere.

Holly:

Wonderful. Well, thank you so much for your time today, Paul. It's been a pleasure.

Paul Ortchanian:

Thank you very much. This was a lot of fun.

‍