Cultivating Momentum (with Paul Ortchanian from Bain Public)

Michael Luchen Momentum is a powerful concept in product management. It can signal the value in investing to create a flywheel, effective output for those cultivating it notably for the product manager. Yep. What goes into cultivating momentum? I'll give you a hint. It's not just well-written user stories and nicely crafted wireframes. It's so much more.

Today, we have an expert CEO and Product Advisor joining us. He's been tackling this concept head-on. Stay tuned. 

This is The Product Manager Podcast, the voices of the community that's writing the playbook for product management, development, and strategy. We're sponsored by Crema, a digital product agency that helps individuals and companies thrive through creativity, technology, and culture. Learn more at crema.us. Keep listening for practical, authentic insights to help you succeed in the world of product management.

All right everyone, you are in for a real treat today as we have

Paul Ortchanian joining us to talk about cultivating momentum at product teams and all of the ingredients that go into fostering that. Paul is exceptionally knowledgeable and well-rounded in all aspects of product management.

He acquired the breadth of his 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, and keynote speaker, and author all wrapped up in one. Paul shares his transition out of the corporate world and into starting his own business, Bain Public. Revealing the extreme challenges of blocking company culture and policies from doing the right thing.

He is a pro in injecting strategies and tactics to monetize his client's business. Paul's company, Bain Public is a product leadership firm that helps companies make informed decisions and deliver superior quality products that appeal to customers and achieve business goals. Their approach, products, and expert advice, and coaching, help untangle complex technology people and roadmap dynamics.

Hey Paul, welcome to the show. 

Paul Ortchanian Hi, thanks for the intro. Quite quite quite a long intro, but yeah. a A lot to say there. 

Michael Luchen You know, and speaking of just so much to say, I'd love to just open up by getting into your background a bit more for the audience. So it's one of, you know, could you maybe start by sharing your journey in product and where it led you to today?

Paul Ortchanian Yeah I mean, it's, I started in the early two thousands as an entrepreneur, but I didn't know I was an entrepreneur. I created my own product and did the go-to-market and everything earned revenue. And but I just didn't see it as such, maybe because in the early two-thousands, the concept of startups was an as you know, mediatizing as it is today.

So I basically ended up moving to San Francisco based on the product that I had built, which at the time was just like a lot of, I guess, an educational website that teach it, teach engineers how to do certain things but also sold the code and the code itself was earning me some good revenue and, and I basically ended up starting as an engineer in San Francisco, worked on a number of companies to quickly realize that my skillset or my superpower wasn't in engineering, but also towards the UX side of things and the business side of things.

And eventually, through the help of some product managers at Adobe, I migrated to product management you know, went through a lot to get my first gig as a product manager. Did every single mistake I could ever do as a product manager and my first product, I ended up getting fired because of it which makes me very proud.

 You know, getting into product management is hard, but you know, the lessons you learned from the first mistakes you make is quite interesting. At which point I moved back to Montreal and within a few years wanted to continue my passion, realized there's a huge lack of product culture here in Montreal in Canada in the, in Northern cities. 

And so I decided to start bain Public to help implement product-led cultures within organizations, and really help the startups here and use the company for a force for good. 

Michael Luchen Very cool. Very cool. So, can you go a little bit deeper into what led you to build Bain Public?

Paul Ortchanian You know, the name itself in French means 'public bath'. And you know, th the idea came from, you know, this lack of cleanliness that's present in most organizations who don't know where their priorities are. There's communication breakdowns there's strategic gridlock, and you know, this lack of strategy in those organizations in their product planning efforts their lack of focus and direction means that things are very messy, especially for employees. 

As an engineer I used to see it when it's messy on top, then your code ends up being very messy. So, you know, I wanted to create a company that can come in and assess, cleanse, and remove the friction from people and the processes they had, making sure everyone is aligned, motivated, and inspired, which is product management in itself.

Naming the company behind the concept of a public bath was, you know, to me, it was an interesting way of just aligning, not only the company name, but the vision of this process that we put together called 'SOAP' which is a process. And we'll get into it later on but it's really a process and a tool that really helps untangle complex technology, people and roadmap dynamics in most organizations.

Michael Luchen That's awesome. I really love just the, kind of the metaphor of cleanliness within an organization. It sounds a lot like you're coming in to remove a lot of maybe organizational cruft so that way people can feel empowered to do their jobs. 

Paul Ortchanian Yeah. I feel that most companies, the it's not that they don't want to empower their product managers.

First of all, some companies don't even know what to do with their product managers or how to, you know, how to really set them up for success. But usually, employees that'd be engineers, sales, marketing, you know, in any department are very much confused on the priorities the companies is following.

And I think that the confusion creates a lot of chaos. And this brings better goes back to the theme that, you know, suddenly you realize the companies lacking momentum can can't release anything is having a hard time articulating what it's releasing to through its marketing and sales efforts.

And that definitely creates an effect that ultimately just, you know, just makes the employees feel that it's just not clean enough, you know, like, you know that feeling you get at a clean room, it's like, you know, everything's organized. So it's a lot easier to get productive than being in an environment that, has that level of dirt in it.

Michael Luchen Yeah. Yeah, absolutely. So I really want to get into the other metaphor of SOAP, but before we do, who does Bain Public serve? 

Paul Ortchanian That's a good question because we actually we have personas and we do know that we're trying to help product managers but we also feel that product managers oftentimes need to be empowered by an executive team or a product leadership team that really understands what product does in their organization and how a roadmap can help their organization thrive and build momentum.

So oftentimes, if we were to approach product managers and say, Hey, we can help you. We feel that, you know, the general attitude within the product management's faces that they run the show. But their peers don't think they run the show as much as product managers think they do. 

So I think it's, we need to cater to both the peers, the, you know, the product leadership team, the C-suite executive more or less as well as the product managers. So we serve both we have two types of leaders. We usually have the founders who basically, they're moving fast. They're obsessed about building a successful business and they're relentless you know, focused, relentlessly focusing on the success of the company and they really want to surround themselves with experts and they bring us in to help them out and help out their product managers. 

But there's also situations where we get into the executives. You know, it could be the CEO, it could be anybody, it could be a C-suite who is basically in very honest very accountable, and realizes what a certain level of humility that there is a problem in their organization.

They don't have the momentum for the organization to continue thriving. They've stagnated and they're willing to do anything to defend the company. And that's where they basically value our inputs to, to come in and set clear goals for the company to have long-term competitive advantage.

I, you know, we can either, you know, there's completely different types of of of you know, who do we serve because the defender type of persona for us is the most valuable one. They realize they have a problem. Whereas founders oftentimes are, you know, they're just going too fast and they really need to have a framework in place.

But ultimately we work with the product managers themselves, who are the sidekicks to the, these the stakeholders. And these are responsible, optimistic people who basically struggled to get their first job in product management and are just, you know, they're not geniuses or visionaries themselves like the founders are, but they just need a framework and a dream. And that framework is missing in their organization. They're having a hard time implementing some, so, you know, we come in and help them. 

Michael Luchen That's awesome. So I got to ask, what is SOAP? 

Paul Ortchanian Oh, SOAP is a framework. There's nothing complicated about it.

It's just a, it's a cocktail of, of best in breed tactics and methodologies that most product managers have read about or learned in books and in articles except that we've basically put them together into a 12-week process, which we work alongside companies, shaping their roadmap narrative through, through this step-by-step process.

So we, we meet with organizations, both the product leadership team, as well as the product management team together for a 12-week period where every single week we're doing what we call edge deployment. We're actually educating the organization as we're working with them. And it, throughout that process, we're untangling the complex technology issues they might have around tangling people problems because having a VP of sales and a VP of marketing in a room with products, oftentimes, basically allow for a lot of issues to be articulated as well as debated. 

And we're also trying to handle the dynamics of understanding what product can do and how engineering can work with product if there are any issues there. So really it's a process that where we co-create a roadmap with this product leadership team making sure that there's team buy-in.

And as we do it, we go through various things that you've seen most probably we do a business model canvas. We'll actually have a parking lot of ideas and we'll start grooming those. We'll basically do a high-level strategic understanding what the strategics tactics and metrics are for an organization.

You know, so we'll do personas. So these are all the you know, the hard things we'll do, but the real priority of SOAP is to really work face-to-face with a group of people, try as trying as much as possible to understand the dynamics that prevent the company from really generating any momentum from the product side and trying to untangle that during those 12 weeks. This way we could get to a prioritization meeting where decisions are made.

These are one-way decisions. And the organization can go out and deliver that value that's been promised in these prioritization meetings within a three months timeframe in which case we just go and restart the SOAP process. And it's an iterative process where every three months there is a roadmap a number of roadmap initiatives that get that gets basically built by the engineering team after prioritization has been done by the product leadership team. 

Michael Luchen Very cool. Very cool. I mean, it sounds like a lot of thought and testing has gone into this. On the whole, has it been pretty successful for your clients? 

Paul Ortchanian It's been. You know, we work with pre-seed startups all the way to you know, series A, series B funded startups or scallops in this case, as well as the organizations who are are pretty mature.

And it's, it seems to work across all of these organizations. Of course, the amount of time we spend with each type of organization is different. I'm working with the founders of a pre-seed startup is great because we're talking about two founders or three founders and a product manager.

When we're working with a scale-up, we usually work with bigger teams. And when you're working with established organizations, you end up having to deal with, you know, VPs and EVPs and C-suites and, you know, communication doesn't flow as well. Everyone's busier. So, you know, the only difference we feel is just the amount of time we need to spend to untangle some of these issues.

But usually the SOAP process is a 12-week process. So it's not as if like we try to stretch it from 12 to 24. We actually just try to say, okay, instead of meeting two hours a week or three hours a week, let's try to meet four or five hours a week. That seems like a lot for executives. But we try to work towards finding a balance where they don't have to be there in every meeting or throughout the entire timeframe.

But we do want them, we do want sales to, to just be able to, you know, Barfield all the emotions they have about some of these, you know, lack of success the company has had with this product. We do want marketing to talk about some of the issues they have or support as well as the engineering team. Just to put it all on the table so we can align. 

Michael Luchen Yeah. And the reality is too he mentioned the value of co-creation like that, that just takes time of humans being on it in a room together or on a zoom call or something. And we see it in our space too, where we're helping our clients build products is it's just we can't work with you unless we have that time.

And I think that's even more crucial in the services that you're providing. 

Paul Ortchanian Yeah, one thing we've done is we try to make it a same bath time, same bath cave approach where it's a, it's committed two hours that the the entire company needs to give us for, you know, let's say every Monday from 12 to two. And so this way it's a lot easier. Everybody has it blocked off in their schedule. And and you know, if there's any, anybody who's not going to be there, then we try to find some times during the, throughout the week to catch them up. 

But, I think most organizations who have committed themselves and it comes from the leadership, but this is where, you know, if the company is serious about empowering their product team is how long the executive team is going to spend in these meetings and which portion of time are they going to be present? 

And usually if they're present a hundred percent of the time, then you're going to have a very good product culture that's going to develop out of it. 

Michael Luchen And I think we also talked a little bit about momentum and I want to dive a little bit into cultivating momentum.

We share a lot of the same perspective on the value of creating momentum for product teams especially if you have the product manager's role. So from your perspective, just 100%, what does it mean to create momentum for a product team? 

Paul Ortchanian Yeah, I think it's like the best reference I could say is like, as a product manager you input money in a bank, and it's money that currency is influence. And every time you have market success with the features that you're building or the products you're building, you basically add money in influence capital into that bank, which basically makes it easier for you as a product manager to push a roadmap along. But not every product manager has the luck I would say, or being at the right place at the right time where you're launching a minimum viable product that has instant market success.

So how do we generate that, that the capital we need as product managers? So this way we could start getting the buy-in from executives and stakeholders to basically give us a chance to move the roadmap forward and not to question it. So, and through the sow process, one thing we do is we fixed timeframes to three months.

So, every three months the engineering team needs to build and deliver on the product roadmap. You know, time is not negotiable. The resources aren't negotiable, but scope is negotiable. So once we've made a roadmap and we know the number of initiatives that we're going to build you know, there's a business case behind each one, but the scope within each is really divided into must-haves, nice-to-haves and wishlist.

So this way we can always, you know, we can commit to delivering the must-haves, but we don't have to deliver the nice-to-haves. So there's a lot of negotiations that's happening, but ultimately if every three months, a, an engineering team can launch product features that have been promised to the company and those initiatives that became features that had metrics behind them start really moving the needle.

Then you get as a product manager, what we call political capital, right? That capital you have where people in the organization cannot ignore that you made a business case. You identified some issues maybe based on customer needs, maybe based on the internal business needs but you've managed to deliver something that basically created value for the organization. 

But that's not momentum. That's just a one-off. You just did it in three months, but if you're able to do that for another three months and another three months and do it over and over again with a pretty good batting average, in terms of the features that you're launching, not only do they, do you gain political capital with sales, support, marketing, CEO and engineering but you start generating customer capital. 

The customer will start noticing that you know, these features that are being launched on a regular basis is actually adding value in their life, adding value to the product. So suddenly customer churn goes down, number of customer support issues go down. 

And once that customer capital adds itself to the political capital that you've just gained and you've managed to do this for a number of quarters in a row, then you've really created the momentum you need as a product manager to succeed. People believe in the roadmap. People believe that the roadmap can ultimately add value. If you have a bad quarter where the features that your team releases are poor or not adopted as much as the customer base, you're not going to be second-guessed. 

You know, you're basically doing the sales marketing team has bought into your vision and they're willing to basically work with you in order to make sure that they don't throw grenades to the roadmap and basically, you know, blow it up into pieces.

And that's what you need as a product manager is just this ability to know that eventually through, through all these product releases that there is this, you know, blind belief in the process that, you know, the roadmap will eventually give us value in success and that's the best place to be as a product manager.

Michael Luchen Yeah. That's awesome. And I can definitely relate to that. You know, especially coming from the agency side of things where we're developing our clients products oftentimes they're coming from the world of fixed scope, waterfall type roadmaps within their organizations. And we're, we don't operate that way.

We operate on time, based on like what your framework is doing. And there's very much at the start of our relationships. A you just have to trust us. You just have to trust us, just give us a couple of sprints and you're going to be able to play with things in ways and show them your stakeholders in ways that you haven't been able to do previously.

And that helps us start to build up that trust capital. And it sounds like that's really what you're saying is that creating a momentum from a product manager really just comes down to an intense focus on cultivating trust. 

Paul Ortchanian It, it is. The hard part is the first time you're doing it in an organization as a product manager.

Let's just assume the product manager doesn't have product processes or principles. It really, it's really important to you as a product manager and in your case as well with customers, first time you're building a product or a feature for a product is to have that, that the company defender persona that we call which is the person who is willing to give the product team a chance.

Helps untangle some of the issues that, you know, the engineering team has had with product or the sales team has had with product because of some under deliveries or some things that you weren't even part of maybe historically, right? And that company defender is so, scared I guess to fail. That's what's really drives them, right?

They're trying to avoid failure at all costs. So they're willing to basically give that initial portion of trust so long as it's basically going to allow you to generate that momentum. And without that, I don't think companies are able to, to have the right product culture. So that's something I'm always looking for.

And I think as a product manager, we have the luxury of interviewing to various companies and we need to be interviewing the interviewers themselves to really understand what product culture, or what company culture am I jumping into. Do I have a product defender here or am I really going to be constrained to a culture that is going to create a lot of issues?

And we notice it a lot. We notice it where we say oftentimes among ourselves that we do not want to have leadership involved as spectators, right? Those who play along, but are not applying to principals. They get into prioritization meetings. They listen to the business cases, the product managers are have built so rigorously.

And, you know, they basically approved, pretending they have buy-in only to go out a week later and have a closed-door meeting and change it, right? That's not empowerment. That simply means that you're there as an executive, pretending that that product management or product leadership meetings are a spectator sport.

And then you ask yourself, why would you even hire a product manager if you, as a CEO or as an executive that are going to make decisions? So it's important for product managers to identify the bait and switch scenario where, you know, is the product, the culture of the company I'm working in going to be one that's going to allow, do I have a defender?

Do I have somebody in the executive team who is willing to defend the product team and empower us? If not, I mean, I often say, you know, you have to evaluate, is it worth changing the culture? Is it worth bringing in some experts help to change the culture if that doesn't work? I mean, oftentimes if you have the best product in the world, but you know, you're not going to generate momentum and that's just not going to be a good output for anyone, right? 

So, or a good outcome. So it's worth basically evaluating where you end up. 

Michael Luchen So, so for our product managers listening in today if I'm in one of those cultures that doesn't have a defender and I'm kind of frankly, a puppet of some of the executives what would you recommend that I do? 

Paul Ortchanian We have a saying it's, it came out spontaneously one day where it says, you can not take orphans and hope they'll have good manners.

And the idea here is the executives of an organization, you know, I mean, if they're orphans, they've basically been orphaned the product management for years and the company has had some success maybe because it was very sales driven. Maybe it was very growth-minded, right? Or maybe it had a and it creates had good timing, right? 

Ultimately you can't expect them to have good manners overnight, right? And so it's important to identify like their willingness to go from orphan to good-mannered executives. And there's no way of finding out other than going through a process of road mapping, prioritizing, and basically seeing what happens after. We've been in a situation where you've gone through the rigorous process of SOAP and we've roadmapped and we basically prioritized. 

And then we, you know, we put out their business cases and put them in one a head-to-head against one another with executives, only to find out that you know, everything got buy-in, everything worked.

Everybody was happy, but eventually, the executives decided not to not to hire the engineering team needed to basically build the features that they agreed upon. Ultimately what we realized is that by not providing the resources we were just accumulating a number of a large number of requirements, a large number of features to be built.

And eventually, that turned the process from this iterative process where it's your build measure learn, and you continuously try to improve a product. It kind of was turning it into well, let's just put all these stack up all these requirements against and eventually, our engineers will do, touch them. 

And to me, that's like, well, wait a second. We've just gone from an iterative approach. Let's say lean iterative approach to waterfall. And waterfall is definitely the last thing you want to do as a product manager. So if you suddenly realized that even though they're bought in, even though they're there, you know, they're there, these orphans maybe have good manners and ultimately you realize that they're really setting you up for a waterfall situation, then it's important for you to recognize it and address it in a manner where they seem to under making them understand what are the drawbacks of basically this type of behavior. 

And if you realize that doesn't change, ultimately you have to repeat in your head. You can not take orphans and hope they have good manners. Maybe it's time for you to look at other products within other companies because you know, it's unfortunate but much about product is about the culture in the company and the trust you have.

So you're right. Trust is important. 

Michael Luchen Yeah, absolutely. Like so much of it is about the culture. And having the privilege to serve many clients through product development. That's something that's become really clear is like, it's easy to tell which clients will often be successful after they leave our services.

And which ones are going to have a rough time. Not necessarily because of product, but because of their product culture or lack thereof. And you know, one of the things I think you're kind of alluding to is like SOAP is, it's a 12-week process. 

How do you ensure that when you were, when you leave a client or a client leaves the nest, so to speak, that they're taking those lessons and embedding them into the culture from working with you so that they have that long-term success and benefits itself?

Paul Ortchanian Well, that's a good question. I've always tell founders that it's their company, it's their product. They can, you know, they can, you know, they can do anything they want, to be honest. So this whole process is there to help them, but it's not a prescriptive process, nor is it like, you know, the end-all.

So I often see organizations take the process and modify it to their needs. Sometimes I feel organizations need six months to a year, just to mature to start using the process. And we've had clients where within a year, they came back and they were extremely happy, but, you know, we were personally disappointed that they hadn't done anything throughout a year, right? 

But to them, it took them that long to basically go from that orphan stage to well-mannered stage. And, you know, so we, we believe that every organization has its own maturity rhythm. But ultimately once they get to creating that momentum and maintaining that momentum, then everyone's going to be happy that ultimately, there is, there was a process that was put in place and it helped us get to this momentum. 

So, I wouldn't count on every organization to be a hundred percent independent and, you know, just use SOAP the way it is. I feel that if there's one thing they learn out of it and they apply that over time and they're happy about it and it generates momentum that's that then you help that client.

Michael Luchen That's awesome. One of the terms that we're using a lot internally this year is the term default. We have a lot of process. We love process. We love nerding out over frameworks and everything. And we love teaching our new hires that as well and our clients and everyone. But we always urge like view this as a default, not like the rule that you have to follow because especially in product. 

And as you said, it's like, there's such a heavy culture focus. You have to have that flexibility, the humans operating on those processes have to have that flexibility. 

Paul Ortchanian Yeah. And you know, you also have to you know, there's the process, there's the company, but you also have to respect the product management and product manager himself or herself, you know. 

They're very, you know, there are people who have a 'me first' attitude, and I'm saying this in the best way possible. They took up the cup of nine to five job, right? To be product managers, but they did take up a nine to five job. They're not, they don't want to be founders, but they do want to progress and they have this pursuit of personal aspiration to manage product at the highest level in some ways, and they're going to be finicky or picky about it, and they will basically use up anything they can in order to better the, you know, the roadmap prioritization process that company takes. 

So you have to respect them. You have to respect how finicky and picky they are. And as optimistic and responsible product managers that they may choose to basically pursue and not use another framework or anything else. And that's fine, you know, that the purpose of SOAP isn't to basically force it down the client's throats.

It's really to basically say there's a framework, but ultimately it's all about empowerment and trust of the product management team. And it's about value degenerate, a momentum degenerate, and you know, you can do it any way you want, as long as you get to the end result, which is momentum. One of the questions we always ask our clients is, you how do you hire and fire your product managers, right? 

What's the, what do you base it off of? And you know, you don't hear a lot of him who basically just say, well, you know, I'm going to evaluate them on a quarterly basis. See how much value they're creating for the company in terms of customer engagement, to us achieving whatever, which comes down to the momentum degenerate through our product.

If that's the answer, that's awesome. They don't need us. But if they were to say, well, we're evaluating them based on the amount of features they're they're outputting then, you know, like, I mean, that's not fair. That's totally not fair. And that's a culture that needs to change. 

Michael Luchen Yeah, very well said. Very well said. So just shifting gears a bit before we start to wrap up. I saw that you recently participated in a startup grind, fireside chat about the future of product management. Where do you believe our craft is heading? 

Paul Ortchanian I mean, Montreal has been a hotbed for artificial intelligence for quite a while now, a few years.

And you know, a lot of product managers are now seeing you know, stakeholders basically ask for artificial intelligent type of features within the product. That doesn't mean the product is itself artificial intelligence, but it could be just like, you know, Google has suggestive replies to your emails and just little features that basically add value to the customer.

And what as a product manager, when you have to shift gears from building products with engineers who basically work on this very targeted approach of, we have this much time to deliver this much scope we could, we control our environments, we control our code, and we know that we could basically deliver high-quality code.

That environment is the one that most product managers are most used to. But when you start talking about projects that, or initiatives or features that are basically going to implement machine learning in order to be able to add value to the product, well, you know, there's a lot of big issues that come up to the product manager.

It's not only the question of how do you sell those ideas to stakeholders? Stakeholders always love AI ideas, but ultimately it's like, well, what assumptions are we making? How accurate is this thing going to be? How do we measure success? Most stakeholders will think that the machines should not be wrong.

That's impossible, right? Like ultimately you have to compare, what are we trying to achieve? If a human being were to do this particular task how much time would it take? How many mistakes would they make? Can we have a machine do it better? But most importantly, as an, as a product manager, when you're working with data scientists and data engineers whose role is to work with data.

And there's a lot of biases in data. There's a lot of structural issues. There's data disruptions. There's also the fact that data needs to be pre-processed and formatted and claimed and send and transformed into things that could be fed into a machine. And then that, that algorithms that we're going to be using in order to create the machine learning needs to be tested, explored and basically we need to pump mish pump data into it in order to see if it's actually going to give us good results. 

And then we realize that those results aren't satisfactory enough. You need to go and reevaluate your algorithm and reevaluate your data in order to improve the results. And ultimately this algorithm tuning doesn't have an ETA.

It's not like an engineer that can say, I can deliver you this particular feature in three weeks. The data scientists will say, I can't tell you how long I need to tune this algorithm because it's dependent on you know, the approaches I take to that and to it. It depends on the data that I feed to it.

Maybe the data is biased. There's a lot of things that can go wrong. So ultimately going back to two executives and saying, look, we're going to be able to deliver features on an AI feature in three months. That doesn't work. You can't do that with AI because AI is most probably is going to give you you know, pretty poor results within three months.

So it's just this idea of how to basically integrate artificial intelligence into product management in some ways telling executives that we're going to start with a very dumb AI engine, maybe one that almost similar, you know, it's just written by engineers without any data which we call feature engineering. 

And then we'll improve it with a version one of our machine learning lab language, but it's not going to be as good, but we're going to use user experience and all kinds of false trappings in order to make sure that the customer experience isn't you know, derailed by it.

And, but it's going to be iterative. It's going to be done over a period of years and we're going to have all this team that's going to be working around it. I think that's the important part is like, how does a product manager who's been used to building software suddenly pivot and manage stakeholders in an environment where there is no security in terms of quality of the output.

There, there is no guarantees. It's just going to be dependent on a bunch of factors that you can't control, nor depth nor does the data or engineering team controls. So it's a different process. It's a different mindset. I've been writing about this for two years now, where I feel that most product managers need to start preparing for that eventuality because we'll all gonna have you know, at least one to two features a year that will have AI and data behind it.

So it's quite important that we as a community prepare for it. 

Michael Luchen Yeah. That's really interesting. I mean, it's it takes the ambiguity that we have today as product managers working in an agile environment. And just like, turns that dial-up to 11 and how do we manage that? Like how do we manage those expectations?

Moving forward, my, my, my personal theory I don't know what you think about this. It's just look back at the agile, the original agile manifesto, and that's the answer maybe to to to managing the ambiguity of the future. 

Paul Ortchanian Yeah. I mean, True. But one thing I've noticed that's worked is, you know, you have to start understanding humans that AI is trying to replace.

So let's say in your software, you're trying to I dunno, try to find defects in doughnuts through a machine webcam that basically it looks at doughnuts and identifies the ones that aren't circular around or doughnut shape, right? I mean, ultimately if a human being were to do that job there's human fatigue that gets involved in, in, you know, in the process.

And then, you know, people can't do that job 24/7, you need training, you know, those employees leave. They can get hit by a bus. You know, there's costs of humans. You know, there's so many factors about humans and when humans make mistakes, I mean, nobody really tends to say, well, he got fired because he made a bunch of mistakes.

Yeah. But what's the impact on the end-user, but your people had to eat donuts that were there, that weren't donut-shaped, right? And I think that like, people tend to forget all of those when we're talking about AI and it's as a product manager, you need to manage stakeholders from that perspective of saying, look, humans are not great at doing this.

And the AI is not going to be great either, but you know what? I just need to make the AI as good as the human plus one, which means the bar is not that high, right? So, so just managing expectations within that and saying, you know, eventually it will be better than a human times 10, but you know, for starters, let's just make sure that this gets, as you know, let's recognize what are the repercussions of humans not doing their jobs correctly. 

And what are the advantages of AI doing it at a cheaper cost 24/7, 365 days a year without having to pay pensions, right? That's what it comes down to. 

Michael Luchen Yeah. All right, Paul, before we wrap up, I'd love to ask some personal lightning round questions if that's okay?

Paul Ortchanian Sure. 

Michael Luchen So first, which of your personal habits has contributed most to your success? 

Paul Ortchanian Ooh. I have, I use Google alerts a lot. Every client that we work with basically gets an alert for their competitors as well as the industry and market. And I find that it's a great pool of articles to read, but we don't have times to read anything as product managers.

So, I use Pocket a lot to save articles. And you know, basically, I end up with this pool of articles that allows me to, you know, on a quarterly basis as a product manager, to get a pulse of the industry, the market, what has changed, competitors, et cetera. And I think that is a, it's a foundation that most product managers need to have is just like, just make sure that you have this automated way of basically being on top of everything that's happening in your industry and market.

Michael Luchen Oh, yeah, absolutely. That's awesome. The second question is, what's your favorite tool that you use regularly? 

Paul Ortchanian Evernote. I think Evernote's a great tool for product managers because a lot of the stuff we do is really about collecting feedback from left and right. And putting our thoughts together.

And Evernote has this ability of just collecting a lot of information all in one place and just allowing you to just make sense of it all. So, I'm a big user of Evernote. 

Michael Luchen Yeah, awesome. I paid for it for about 10 years. I'm a huge fan. And then lastly for someone at the start of their product management journey, what's the one piece of advice that you'd give them?

Paul Ortchanian I'd say, learn to negotiate. Learn to identify crisis situations with stakeholders. Learn to manage those conversations in a way where you're not barfing out your emotions. It's tough to be product manager. You have a lot of headwind, especially from engineers and different various departments, namely sales and marketing.

And I think that you have to learn how to say NO. Conflicts will rise. Having at least a process, a framework of how to engage in those conversations without making them into a negative conversation having a few tricks ready to go and being able to have those conversations within a 30-minute timeframe so this way you can go on doing whatever you need to do.

It's quite important. And I would say that's the softer side of product management, and unfortunately we all learn late. But I would say that would be the first thing to put in your arsenal. 

Michael Luchen Well said, well said. All right, Paul, thank you so much for coming on to the show today.

There was certainly a wealth of information that I was able to take away from our conversation. 

Paul Ortchanian Thanks. Thanks a lot for having us and absolutely loved answering all the questions. 

Michael Luchen Awesome. Awesome. So for everyone listening to it, you can find out more about Paul's work at bainpublic.com, where you can find him on LinkedIn.

Where he has a reference out to over 60 plus articles on Bain Public. They have a newsletter. You can download their ebook all on their website at bainpublic.com. 

Again, thank you so much, Paul for joining today. Thank you everyone for listening in and be sure to leave podcast review. Your feedback definitely helps us take the show in the direction that you'd like us to take it and be sure to follow and join our community over at theproductmanager.com.

Thanks, everyone. Have a great day.