An interview with Paul Ortchanian 

Today we're speaking with Paul Ortchanian, who runs Bain Public, a Montreal-based product consultancy that helps businesses of all sizes develop and implement strong product management practices.

Thanks for joining us, Paul! First, can you tell us a little bit about your journey? How’d you get started, and how’d you end up where you are today running Bain Public?

Sure! I started off as an engineer. I did about 10 years of engineering, mainly on the front-end side of things. I was very close to UX, too, and eventually ended up managing scope on bigger projects. And when you’re working on big products, you really start to realize how important the management of scope and expectation are to creating clarity.

Because I loved UX as well as working on the business side of things, I made a leap of faith and became a Product Manager in San Francisco. I joined a startup and learned things the way many product managers do — the hard way.

Eventually I came to Montreal and realized we had a nice little startup ecosystem, but most of the companies here didn’t have a culture that was product-led. It was the same old story of, “do what the boss says.” These business weren’t really solving customer problems, but instead trying to build as many features as they could without really asking themselves the question: is this adding value?

So I decided to start a company that focuses mainly on evangelizing product management to the Montreal community. I try to bring some of my key learnings from San Francisco to Montreal, and implement product-led thinking.

We have a mix of companies here, both early startups and later-stage ones. Regardless of stage, many are in denial for awhile, and eventually realize that product is important. But they’re not sure how to go about improving things. And that’s become our niche.

That’s great. Thinking about organizational transformation, let’s say you have a bigger company that doesn’t have a very effective product culture. What are some things you’ve seen that are signs a company needs help, or needs to be thinking about product in a different way?

First up, defining what a product manager does is quite important. So if I were to ask the company’s product managers, what do you do every day? How do you define your role in your company? Ideally, the answer is “we’re taking ownership of a portion of the company’s growth, through the features that we’re launching, and we’re able to help the business achieve its next financial milestone.”

There needs to be some acknowledgement that sales or marketing are not the primary drivers of business growth. And that the product itself is going to contribute positively, by increasing revenue through upselling, preventing customers from leaving, finding ways to charge more for certain things, adding ways to acquire new customers, and so on.

We’ll ask the product team, “what’s the strategy? Are you making large bets on unproven markets? Are you competitively launching new features? Are you extending a product functionality to an established market? Or are you simply shipping with little discussion about impact?” If it’s the latter — simply shipping, with little discussion about impact — that’s a project manager, not a product manager. Because they’re being told what to do.

So then I go to the product leadership team, usually the C-suite, and take a reverse lens. I’ll ask them, “what do you expect out of a product manager?”

And you can tell based on their answers if it’s an organization that celebrates shipping features more than it celebrates solving customer problems, or business problems. That’s the starting point.

I like that framing. So let’s say someone is in a culture like that, and they want to implement better product-led thinking. But they’re not in the C-suite. What are some things they can do?

Usually I try to define the strategy with the product leadership team before defining product management. It’s a question for the founders, the top-level decision makers. Usually that includes sales and marketing, operations, the CTO, and so on. And the question really is, “is this plane being built as it’s flying off the cliff, or is there a plan? How do you empower your product management team through processes and tools?”

It just comes down to asking some pretty tough questions. The best question I’ve been able to ask is, “do you know which features in your product are contributing toward revenue? And directly or indirectly, which are the largest customers that are using those features?” Take a very metrics-driven approach.

And if they’re unable to answer that, and they say “well, the product sells itself,” or, “we have no clue, because we have an amazing sales team and they’re able to sell anything,” or “our marketing team works really hard to bring in new customers,” — then, they really don’t know.

I recently had a startup founder email me his monthly report, outlining an increase in the number of commits to his main code repository. He was celebrating that as a win. And he was really happy about a questionnaire they sent out that had a lot of responses. I wrote him back and said, “you know, those are very shallow KPIs.”

You can’t run a business focused on shallow KPIs. You need to know how much growth each feature is generating, and how each feature is contributing to achieving your next financial milestone. If you can’t answer that question, then you don’t have a product-led culture.

But once people see how that type of thinking can contribute to the business, it can start to infiltrate the company. On our end, we come in to help define that step-by-step process, as long as the leadership team is willing to make the change.

What are some challenges you’re facing right now in your role, running Bain Public?

First of all, doing what we do, coming in and saying to a company, “you’re gonna have to make all this change,” — that’s a pretty tough sell. You need a lot of credibility. People want to know your background, and they want to know you know about their industry. Oftentimes I hear, “what do you know about the [healthcare / fintech / etc.] space?” But it’s not about that. The reality is, our job is to come in, interview the team, get to know their product culture, and help them put in place a process to empower product managers and inject this type of thinking in their company. They’ll always be the experts at what they do. We’re just there to organize priorities, help work through the roadmap to make sure it’s contributing to the growth of the organization. So this is an ongoing challenge, creating the organic word of mouth and the pedigree to allow us to be credible.

The second challenge we face is the product management culture within organizations. Oftentimes you’ll get someone who wasn’t hired as a product manager — maybe they came in as a business analyst, a UX designer, a marketer, or something like that — and they’ve been effectively given the role of product manager.

In many cases, they’re extremely busy, they’re running the show without any work-life balance, and they’re just unwilling to stop and make changes.

I read a Reddit thread recently that talked about how the role of a PM is a lot less glorious than what you see portrayed. And that’s true. A lot of it is a grind. You’ve got to drop something to jump into a customer support call, and then you run to a sales meeting to make sure the sales team doesn’t sell stuff that doesn’t exist, and then you head over to marketing to explain the features you’re actually shipping, and help them with website copy to make sure it’s accurate. It’s a grind.

People get caught up in it and think, there’s no way to progress here. External people can’t come in and coach me. It’s denial, really. Because there’s so much growing and learning that needs to be done in this space.

They might be busy debating whether to use Kanban or Agile, but ignoring the fact that every day their boss, who suffers from Shiny Object Syndrome, comes in and whiplashes the team with a new feature. So which problem do they really want to solve: Kanban vs. Agile, or the fact that their boss doesn’t let them have a roadmap?

Willingness to be challenged needs to come from the leadership team and PMs alike.

By definition, you must be dealing almost exclusively with clients that are suffering from these challenges but at least looking to resolve them.

Yes, though I’d say there’s a large percentage of clients we work with that don’t even know what product management is.

That’s another problem. Maybe they’re brand new companies, they might even be pre-seed or at the ideation stage. Ideally, they’re looking to implement a product-led culture from the get-go, because the longer they delay, the more problems they’re going to have in terms of communication and culture down the road.

You just mentioned Shiny Object Syndrome. I think sometimes people are resistant to having a data-led approach to product decisions, because they think they know best, or their solution is new and they think the customer doesn’t know what they want. So they’re just going to be the visionary that drives this product.

How can a PM help facilitate a more rigorous approach to decision making?

We do SOAP, which is our framework. We bring in the entire product leadership team plus the PM. So that’s usually 4-5 people — CEO, CFO, CMO, etc., plus the PM. And we basically conduct interviews. We allow them to express what they think the priorities are from every angle.

Sometimes it’s not about making the right decision, it’s about making sure you have the right process, which is this collaborative discussion. This quest for learning together. So if you’re a PM, you’re in a position where you can get everyone together and help them learn. What are the constraints the sales team is facing? What about the marketing team? What’s customer support hearing?

And then the goal is to come face-to-face with the really hard problems, together. That way, there’s no one-sided bias from the sales team, or the marketing team, or the engineering team.

It’s all about asking the right questions, too. When they say they need something, follow up with a question: “how is this going to help the business? How is this going to allow us to achieve our financial targets? If this is a great idea, who’s the user that’s going to use it?”

This process of collective learning helps create trust in the PM, because people can see that the PM isn’t just dictating things. There are no egos in the room.

You might not bat for a thousand, but at least you’ll be able to hit, say, a 60% average in shipping the right features. And over the long run, that’s probably good enough.

Great advice. So how can you balance short, medium and long term goals when setting a roadmap?

It’s like wearing glasses — the closer things are, the sharper they get. The further out you look, the more blurry it gets. The crucial thing is always getting the next three months right, facing your immediate decisions.

Beyond that, your customers might change. Your competitors might change. Your market might change. You’ve got to be able to reevaluate every three months or so. That’s why we called our company Bain Public, because in French, bain public is a public bath. It’s a place where you go to clean up on a regular basis.

So the idea is, every three months a company cleans up their roadmap. Reevaluates what’s happening. It’s not about having full clarity on a 6 to 12 month roadmap. It’s mainly about having a high level mission.

You can have long term goals, but know that they’re blurry.

And in terms of setting top priorities, it’s best to come face to face with the worst problems. Often the company’s worst problems are the customer’s worst problems. Maybe something is broken and it’s creating a ton of support tickets. And you’re stuck with one resource who’s managing 600 tickets a day, which is humiliating. When you think about it that way — what’s humiliating? That gives you a good idea where to start.

What about a new startup that’s just launching for the first time? How can they think about prioritization?

Well I guess that’s your biggest problem, no one is using the product yet. First up you want to create your whole ecosystem. How does somebody buy your product? What happens post-purchase? Map out every step you want a customer to take from sale, to regular usage, and the output the product provides.

Then you ask yourself, “where are we faking it till we make it?”

When you look at your process, what you’ve built and what you’re faking, where are there gaps that could create problems for the customer? If something important isn’t yet automated, or data is being stored somewhere it could easily be lost, you probably want to start there.

What about PMs early in their career? What’s something you wish you’d known earlier?

I would’ve loved to be coached from the get-go. I used to be the guy who came into the room with the data, the numbers. Everything you read about product management, people are telling you to be an expert in the data, the market, your competitors, your industry. So you’ve spent time with the CTO and the engineering team. You’re an expert in the product and the database structure. You’re in sales and marketing meetings. And you think, “okay, I guess I’m an expert on everything and I’m here to tell everyone what the facts are.”

The thing is, product managers also need to be able to influence people. You need to be able to hear them out, hear their concerns, and frame the features you’re proposing within the context of their problems. And if you’re not listening, and you’re just the guy who’s coming in with the facts, you’re going to get challenged or pushed aside. And that was my biggest issue, originally. In my first PM role, I was fired. Not because I was a bad PM, but because I had a big mouth.

Once you lose credibility, you lose the room. It’s like being a hockey coach. It’s not because you’re bad, it’s because the players don’t want to play for you anymore.

The average lifespan of a PM within a company is often a year. It’s ridiculously short. I think a lot of it has to do with the fact that PMs have so much to assimilate in a short amount of time.

I talk a lot, and I had to learn the hard way to be a good listener. Maybe it’s not a good idea to go out there presenting a list of 10 Reasons Why We Shouldn’t Build This Feature, because the sales team is going to just go around you to the CEO and get their feature built.

That’s good advice, and very true. Last couple questions! What’s a product that you’re obsessed with right now?

One that I’ve always liked — I’ve been using it for about 10 years now, I think — is Things. It’s basically just a big to-do list. But the way the user experience has been thought out is great. Every feature adds value. I can’t get out of it, it’s just so much part of my day-to-day.

Any recent podcasts or books you’ve discovered that you’d recommend?

I love Todd Olson’s book, The Product Led Organization. It’s basically Product Management 101. I find the industry is becoming more mature, and I’m really happy that there are books like this that are the real deal.

For more from Paul on product management, dive into the Bain Public blog. And make sure you never miss a Product Thinking interview — sign up for our newsletter below.