Cogent Conversations: Episode 22

The Value of Product Managers

Welcome to the third episode in Season 3 of Cogent Conversations, where we’ll be taking a deeper dive into the 2021 Australia & New Zealand Product Teams Report.

This is the second year we’ve published the report, featuring insights from 100 tech companies across Australia and New Zealand, and helping us answer the question we get asked most at Cogent: “how do other people do it?” when it comes to the way product teams best work together.

In this episode Adam Murray, a Product Principal here at Cogent, digs a little deeper into how high performing teams work together. Hear him interview two highly experienced experts on the topic from Cogent about their experience, opinions and recommendations.

Lead Product Manager

Managing Principal

“When it comes to deciding a team’s goals and objectives, and what’s being included in product releases, Product Managers are seen to be the most influential, with 85% of respondents reporting this in their teams.”

Access your own copy of the 2021 Product Teams Report here for more insights and recommendations.  To keep up to date with what is happening with Cogent, including when new episodes of this podcast are released, you can subscribe via email or follow us on Twitter


Listen to the Episodes

Subscribe and download now via:

Apple Podcasts


RSS Feed

Download the full 50-page report

Full Episode Transcript

Adam: Welcome to season 3 of the Cogent Conversations podcast, in which we take a deeper dive into our 2021 Australia and New Zealand product teams report. This is the second year we’ve published the report, featuring insights from 100 tech companies across Australia and New Zealand, and helping us answer the question we get asked the most: how do other people do it when it comes to the way product teams work best together?

I’m Adam Murray, a Principal here at Cogent. In each episode, I’ll be digging a little deeper into a key theme of the report, gaining further insights and recommendations from some of our experts here at Cogent. You can download the free 50-page report by visiting Let’s get into it.

Welcome to the third episode in this season of the Cogent Conversations podcast, where we are looking to understand in more detail what’s behind the product teams report, which has just come out. As I’ve mentioned in the other episodes, it’s really exciting to be talking to people from Cogent. I’ll introduce our two guests for today in a second. My name’s Adam Murray, one of the principles here at Cogent with a focus on strategy. In this episode, I am talking with Eadaoin Doherty, who’s a Lead Product Manager here, and Craig Ambrose, who’s a Managing Principal in the area of partnerships.

Today we’re going to talk about the value of product managers. One of the good things about having Craig and Eadaoin here is that they have worked on a project before. Eadaoin is a product manager and Craig a developer, so we can understand a little bit of the nuances of those two roles working together on a project. 

My first question is for you, Eadaoin. It seems everyone has quite a different and nuanced journey to becoming a product manager. Can you tell us a little bit about your journey?

Eadaoin: Yeah, sure. My background is actually in engineering. I have a Master’s Degree in Electronic Engineering and I initially worked in hardware. I was working in IC development for about 10 years before I moved into software. My first taste of product management was in hardware, and that was for microphone ICs, the kind that are used in smartphones today. Since moving over to software, I’ve worked in quite a wide range of products. I’ve worked with hearing aid software, software for the energy industry and for electric vehicle chargers. I’ve also had the opportunity to work with a number of startups within Melbourne. It’s really quite a change from where I started.

Adam: Yeah. I imagine it’s also super-valuable to have that background that you’ve got in the role that you’re playing now also.

Eadaoin: Yeah. I think it’s good to have a technical element so you can understand what the developers are working on and some of the problems that they’re facing. I have an analytical background. I have an engineering brain, so I’m pretty analytical when it comes to problem-solving.

Adam: Good to have you here Eadaoin. Welcome to you, Craig, as well. You’ve had a long career in tech and I’m interested to understand where you came across, maybe not necessarily explicitly somebody called a product manager, but the role of somebody playing that role. And then maybe also, when you first heard this term, as well.

Craig: Thanks Adam. I started in computer games, because that’s all I ever wanted to do as a kid: make computer games. I did that for the first five years or so. Many computer games companies still follow that triumvirate you still see in a lot of companies, which is a technical, engineering manager of some sort, a business-focused project manager with Gantt charts and budgets, and then reportable to the CEO. The role that is a bit like we might see a designer and/or product manager play in web app development, which is the game designer, who’s got this vision for what the product is going to be. That game designer maybe is the closest thing that we saw to a product manager in computer games, and certainly they would be the one who would be having to flex scope of their grand vision in order to hit the deadlines and the budgets. But in practice, it didn’t work as well as when you see somebody across those three disciplines of tech, design and business.

Maybe the first time I saw that would’ve been in digital startups, either Melbourne or New Zealand, where I worked for a decade. I’ve worked for a number of startups. And really small startups, you get that situation where the founder is that jack all trades, whether they’re good at it or not, they’re forced to do that. Then early on, and particularly once they’re funded and big enough to hire a tech team with people like me, one of their early hires is often that role of product manager. In a few cases, we saw that role not explicitly labeled “product manager”, there was something else, but in practice, they did that bridge between all those disciplines. As soon as those startups got a little bit bigger, or when we got hired into the larger digital businesses, that product manager role appeared, and I’m not sure — I couldn’t put a year on it — but could be as early as, oh five or six that I started seeing at Melbourne and New Zealand.

Adam: Yeah. Great. Thanks for that, Craig. I’m a product manager myself and that’s around about the time that I came into it too, and followed a little bit of an interesting path as well, which I might not get into today, ‘cause you’re the guest and I’m the host. One of the reasons why we’re having a whole episode on product managers in this series of the podcast, and the value that they bring, is because the product report really brought out the importance of product managers, and it seems product managers are really having a moment right now. One of the stats that was indicative of this is that 85 percent of team members see product managers as being the most influential in regard to what gets included in product releases. This is quite a big increase from the last report that we saw. But let’s go back to basics and Eadaoin, what do product managers do, anyway?

Eadaoin: That’s a very good question. It’s a really wide and varied role. The day-to-day tasks of a product manager can really change depending on the size of the company, but ultimately we’re all trying to make sure that our company is building the right thing. I always think of product managers constantly absorbing information. We’re out talking to customers and understanding their problems, and working out how our product can solve those problems. We work really closely with our designers on that type of work. We’re talking to the business leaders in our company to understand their vision for the company and the business goals. Then we’re thinking about how we can ensure our product is aligned with those goals and is contributing to them. We’re also always looking at what’s happening out there in the market, and who are we competing against?

We bring all that information together to create a vision for our product and to help us prioritise what we need to build. We bring that into our team. We also work really, really closely with our delivery teams. That would be our developers and our designers, and we help them understand the vision of our product and bring all that external information into the team, so they understand the why behind the product, and who we’re building it for and what problems we’re solving.

At a day-to-day level, we’re working out, how do we prioritise that work? We’re working really closely with our delivery team on that, thinking about what happens in this iteration, the next iteration next quarter, six months’ time and, and our varying degrees of certainty across those timelines. But we’re very much thinking strategically about where do we want our product to go and what do we need to do next? But we’re also reflective. We define what success looks like for our product. We gather data on that, we gather metrics and we review those metrics to determine whether we are being successful in the way we want to be successful, and if we’re not, we think about how we course-correct. So a very wide, varying role, and very much thinking past, present and future all the time.

Adam: I love some of those things that you brought out there around alignment and making sure there’s alignment around absorbing that information and synthesising it, and creating some succinct articulation around a vision that everyone can get behind. There’s a strong communication component to what product managers do, isn’t there?

Eadaoin: Massively. Massive amounts of communication. We are always talking, we’re always talking to somebody, we’re talking to our clients, or we’re talking to our business leaders, or we’re talking to our delivery team, or we’re talking to the various groups and departments within our company. It really is our role to communicate that vision of our product and help people believe in that vision and understand, why should the company invest in this product and what problem are we solving for our customers? It’s really important that we can communicate that clearly to all those different people across the company. Everyone absorbs information and understands information differently, so you need to be able to communicate to each of those groups successfully.

Adam: Craig, it’s great to have you here with a developer perspective on this as well. One of the things that might occur in some teams is that there could be a bit of concern amongst developers when a product manager comes in, that it might take away some of their ability to make decisions or even a founder, say, handing over the reins to a product manager for the first time. But can you talk a little bit about what the emergence of product managers has enabled specifically for developers and the team?

Craig: Yeah. I think that nervousness resonates. Developers typically don’t want to just be handed detailed specifications and just churn out features, or at least it hasn’t been true for a long time. Most of the small businesses I’ve worked in, developers have been a really passionate part of being very attached to the business vision and wanting to get their mark on the page. Early on, I got into Agile software development, maybe about 2002 or 2003. We were using extreme programming where we have this notion of the customer in the room. That customer is maybe more synonymous with the product owner than a product manager.

Early on for us, it was quite a passive role where the developers were just asking them questions: here’s two things we could do: pick the top priority. But even having somebody who could understand the big picture, and enough to know what the priorities were, in the room with us was quite empowering — quite different to this notion that the goals of the project, the high-level strategic goals were somewhere else: some management team elsewhere in the building, not us, would make those decisions. The bad end of product management from the point of view of a software engineer is perhaps when a product manager sees their job as writing an old-fashioned waterfall-style software requirement specification in a just-in-time way, giving us a page at a time: here is the API method to call, make sure you pass in these three parameters.

That’s really a business analyst/project manager approach. What’s much more empowering is when the presence of a product manager actually moves some of the locus of decision-making into the team itself. That actually creates the opportunity for developers to be more product-thinking, not less. Some of the projects I’ve worked on that have had product managers on them, I’ve actually gotten to do things that are way outside my traditional role — go out in the street and do gorilla user interviews, which is traditionally a design job. Or present a totally new concept to management compared to what they’ve asked for, because our team thinks it’s better, and we have enough context to make a solid argument for that being the case. Having that product manager there allows us to do that.

There’s something about the way that product management is carried out. The way that it is effectively a multi-stakeholder engagement position means that, at least, all the product managers I work with at Cogent have a very strong facilitator background, or hat that they can wear. There’s something about that facilitator-y style of communication that I find increases democracy in the team, increases the ability of developers to actually participate. Whereas again, more traditional forms of management are much more sort of “broadcast”: information is transmitted to us. We receive it and we code-monkey away until it’s done. Anyone who’s concerned about this idea that a product manager’s going to make decisions for them and that they as developers are going to have to be less product-thinking would be pleasantly surprised to find that there’ll be probably more opportunity to be a product-thinking developer with a product manager on the team.

Adam: Eadaoin, from a product manager point of view, and just elaborating what Craig was saying there, in coming into a team that’s, maybe, having for the first time a product manager on their team or a founder that’s slowly handing over those reins, what things can the product manager do to ease that transition and make it as smooth as possible?

Eadaoin: A lot of it is to do with, again, it comes back to that facilitation role of a product manager. We run a lot of workshops and we run a lot of meetings, so we really have the opportunity to facilitate how the team works and how the team runs, the feeling within the team, the culture within the team. A product manager can really encourage the team to contribute to that. The product manager is not there to define everything that happens, and how retros are run and stand ups are run. It’s really about facilitating a collaborative environment within the team and helping the team try new things. Encourage a safe space for people, try out different types of processes, play around with things, figure out what happens for the team.

That idea, as Craig said, of coming in and writing really specific specifications and handing those over to the developers, that is not how you are going to get the best product. How you get the best product is to come to your team and say, this is the problem that our customers have. This is the most important problem for us to solve at this time. How are we going to solve that, and let the whole team contribute to that discussion. As a product manager, you don’t have all the answers, but you can encourage your team in a way that helps them find the answers. Create a culture that is safe and experimental, and you’ll come up with the best product, and your team environment will be a happy place to be.

Craig: Yeah. Can I jump on that thought Eadaoin? Maybe as well, senior management in software has taken a bit of time to realise that software engineers and designers are actually making micro decisions all throughout the day. Even back in the day in a waterfall project, you would be handed a 200-page software requirements specification document. It couldn’t even then have enough information to make all the decisions that you needed on day-to day-basis. Having someone like you there, Eadaoin, on the team, constantly communicating the why of what we’re building, not just the what, allows delivery staff to make those decisions every minute that are part of the job.

Eadaoin: Yeah. I always think that product managers bring the why and the developers and designers, they bring the how, how are we going to do this?

Adam: Yeah. That’s a great framing of it, Eadaoin, the why and the how. Another thing that was interesting in the report that jumped out, was that leaders might be viewing things a little bit differently to, say, team members, with 85 percent of them believing that developers are still the key influencers and product managers perhaps being less influential. Eadaoin, maybe this speaks to your communication part of it, and perhaps something where product managers still have a bit of work to do in communicating their value outside of the team, to other parts of the organisation. But let’s start with, what value do product managers bring to an organisation and a business anyway?

Eadaoin: I mentioned this earlier, we are always focused on making sure that we’re building the right thing. We are out gathering lots of information and making sure that we are not just building any product, but we’re building the right product. We do that by really focusing on four risks. You’ll often hear product managers talk about the four risks that they think about, and they then balance these four risks to try and find the right decision for the product. The four risks that we think about are: desirability. Do people want this product? If we build this, do they want it, and will it solve the problems that they have? The second risk that we think about is viability. Does our company want to do this? We work with our business leaders to make sure, is this the right market for us to be working in? Is this product going to bring us the profit that we need for the company?

We also think about the feasibility risk. Can we build this? That’s where we work really closely with our developers to understand technically, is this something we can actually do? We also think about the usability risk, and this is where we work really closely with our designers to understand, can people use this? How do we design this in a way that people can use it successfully? We take those four risks and we’re always balancing them. There are other people across the company that are thinking about one or two of those risks, but it’s the product manager who’s really thinking about all four of those and making a balanced decision for the product based on those.

Often a CEO or a founder initially is thinking about those four risks when a company starts and they’re working at product level, they’re thinking about those four risks. But over time as a company grows, a CEO needs to start thinking at company level rather than product level. That’s a great point at which the founder or CEO brings in a product manager to start being really focused on those four risks at a product level while a CEO can move up to thinking about company level.

Adam: Yeah. Craig, do you have any thoughts on that as well?

Craig: Yeah. One of the ways in which that affects us as developers is particularly the way that it brings that desirability and usability into the equation. We’re often asked by managers about feasibility. Can you build this? Will it work? Can you build it in time? What are the technical risks? But there’s a huge amount of my career, certainly, that I’ve spent on software that really didn’t get used very much. A lot of features that we build turn out to not be the right things, and sometimes entire projects don’t really get used. It’s so frustrating to developers. 

Early on, Cogent adopted a value of usefulness, which really spoke to the fact that our developers wanted to build things that people used. A lot of that value has now evolved into the larger concept of meaning. That’s why we want people to use our software to bring meaning to our work. I don’t know what the stats are globally, it’s something like 30 percent of all software doesn’t get used. If a product manager can even have that number for us, that has a dramatic effect on the meaningfulness of our work. When you’re at the last minute, busting your gut to finish some feature and ship it out in the wild and put it in the hands of real users, that’s a really good feeling if you know that they’re actually going to get a lot of value out of it.

Adam: Yeah. There is a sense that we all want, that the work that we do is contributing to something, and that can be a super-important role that product managers can play. Eadaoin, back to the way that perhaps leaders might be perceiving the value of product managers a little bit differently, what can product managers do to help enhance that perception?

Eadaoin: As I talked about before, product managers communicate with people across the whole company. We’re working with the business leaders, with the customer service team, the finance team, the marketing team. We really have an opportunity to promote what our team is doing and to create better visibility of our team. Taking the opportunity to talk about your product, to explain the benefits of your product to the user whenever you get that opportunity, and to talk about the value that your delivery team is bringing to the company, is a really big part of that. 

With regards to helping leaders understand products in more detail, again, it’s very often about creating empathy with your user, and to help the leaders understand what problems your users are experiencing and how your product is solving those. It’s taking your user from just being somebody else, to somebody that your business leaders really have empathy for, and they really feel for. And then they can see that you are solving those problems, and they really understand that journey of why you are creating your product the way you are, and why your team is spending time on the things they’re spending time on. And then of course, business leaders always like to see the bottom line. If possible, show them the financial benefit of your product and that’s what’s going to stay with them.

Adam: We need to start to wrap up actually. I’ve just got maybe one or two questions left for both of you. Craig, we’ve got a range of different people, no doubt, listening to this podcast. Some that are very familiar with product managers, have been using them for a long time, and others that perhaps are quite new to the concept and may not yet be convinced about them. For those types of organisations who are not yet convinced, what’s a safe way for them to start to experiment, to understand if it might be a good fit and understand the value that product managers could bring?

Craig: There’s probably a number of different ways, but one thing that I’ve quite enjoyed is doing short time-limited projects in a different way of working. Eadaoin and I have done at least one Google Design Sprint-type process together: that week-long, rapidly iterating mission to get something actually in the hands of users. And having, particularly when you take software developers who have been working on a well-known line of work for the last six to 12 months, the chance to work on something like that with a different way of working, where they can actually be involved with the product manager and designer in what the outcomes will be, and it’s not predetermined. It can be very uplifting, can really help morale.

It’s not dissimilar to what some companies do with hack days and things like that, which are often the shorter version of that. But I think doing it a bit more intentionally, and having a product manager hold the process, and really tie it to the business outcomes, not just have it about the team doing whatever they want, I think is a really great way to experiment. I know we do that sometimes as part of our Clarify service at Cogent, where we’re figuring out what a new project can look like. We probably spend three to four weeks on that with a product manager, designer and a developer. I’ve certainly participated in that a number of times as the developer and it’s quite a good experience to really get outside of our comfort zone, get out of the source code editor a little bit and participate in that process. And you can absolutely see in a process like that, what a product manager brings. 

In your existing business, if you can expose a few of your technologists to that experience, then you’ll have a lot of allies in the business when it comes to introducing product managers for other things.

Adam: Yeah. Awesome. It sounds like a really small thing that people can do, it’s safe to fail. Even if it doesn’t go well — it’s most likely it will — the impacts aren’t that big. Eadaoin, for you. At the other end of the spectrum, for those organizations that are very familiar with product managers and perhaps are seeing the value and maybe have multiple product managers across the organisation, what things can they be looking to do to take things to the next level?

Eadaoin: Promoting products across the company and helping everyone in the company understand the value of the product is a really worthwhile thing for product people to spend time on. Kind of goes back to that previous stat about people within a team really can see the value of a product, but sometimes people outside the team don’t understand that value as much. But we know, as product managers, that we bring a huge amount of value to a team and to a company. It’s really worthwhile spending time educating other people within the company that are outside the delivery team, what product does and the value that product’s bringing, so that they can be supportive of the product managers as well.

Adam: Yeah. That’s great as well. Ideally can start to talk about, or enable some of those things that we did talk about, where more of the software that is built is actually delivered and used and valuable for the people that are using it.

Eadaoin: Absolutely.

Adam: Is there any final words that either of you would like to say, something that you didn’t quite get to cover, or I didn’t ask, didn’t give you the chance to talk about any of those questions, Craig or Eadaoin?

Craig: I hope a lot of this is actually already obvious to some of our listeners. It’s certainly interesting when I’m thinking of a project that I might like to work on, or it’s part of the conversations with a new client, one of the big green flags for me is seeing that they have a clear understanding of the product. If they’ve got a product manager already working on the concept that they want built, or they would like coaching to supply one or something, customers valuing that says to me, they’re invested in the success of this team. That’s something that every company can look out for. It’s something that as a software developer I know is going to give me the experience that I want to have in terms of meaning.

Eadaoin: For me it’s, don’t underestimate the value of communication. You can never promote your product and what your team is doing enough within a company. The more people understand what your team is doing, the more support you’ll get from those people.

Adam: Awesome. Thank you so much, Craig and Eadaoin. Thanks to you all for listening as well. If you’d like to learn more about how teams across Australia and New Zealand are doing things, you can download the free 50-page report by visiting Until next time.