In March 2018, Rich Mironov visited Australia and presented to the Product Talks Sydney Meetup Group on building and scaling Product teams. This blog is a transcript of part of that meetup, focusing on how to structure Product Management.
Rich Mironov presenting on why we need Product Management
Let’s talk about product organisations. We’re gonna have a bunch of folks now. I’m gonna put a theory forward because I’m brave. I’m gonna put a theory forward, okay, and the theory basically says, “Hand offs are the enemy of insight. The distance, the number of conversational hops between the folks who build product and your users is the most important function about whether we’re gonna succeed or not.” I’ll draw the picture for us and I’ll call it distance, but I’m really talking about conversational distance.
Rich Mironov: reducing conversation hops in Product Management
Reducing distance. I’m gonna have like the dumb one, and then it’ll get a little better. So the dumbest one: I have a development team on your left. I have a product person. Notice I haven’t labelled anything behind product because I’m gonna knock down some titles in a little bit. On the far side I’ve got the Gartner report, or your favourite bit of market research that wasn’t built for you, and whoever they talked to to get that 2 years ago because that’s how long the publishing cycle is. So you could have a company that chooses what to build based on a bunch of market research interviews with some random set of people, no context, and whatever’s in the report. Okay? Can’t recommend it that strongly. Right?
So let’s do a little better. Let’s put the sales and marketing team and our customers, and all we do is we listen to or read the notes from Salesforce on what our sales team wrote down at the end of their customer meetings. Right? Anybody been in that company? Anybody still in that company? Okay. Notice we’re a little closer. At least we’re talking to our own customers, but the gap is huge because sales people never really ask the questions the product folks ask, and they’re always trying to get to yes, and it’s always about who in the organisation can approve stuff and what their budget is. And they take down key phrases, but they don’t actually know or care in detail what those key phrases mean. Okay. Not so good. Better than the previous one. Let’s go to the next one.
I’m carefully writing in the word product owner here, and apologies in advance if I offend anybody, but I’m gonna jump into the frey. Business product manager or business requester on one side. This is the business unit, and that’s generally the IT or development shop. A little better. Not much. Notice that there’s somebody on the business side who talks to users and customers but doesn’t actually know how anything’s built or what it costs or how hard it is. And there’s a product owner who is following only and exactly what the scrum book says. Somebody tell me what the scrum book says product owners do. What do they do?
Audience: Prioritise the backlog.
Rich Mironov: The prioritise the backlog. What else do they do?
Audience: Write user stories.
Rich Mironov: They write user stories. That’s right. And they also accept user stories. Did you get one of these? Okay. Good.
So, if you open the scrum book here’s what you’re gonna find out. Product owners must sit with their teams 24 by 7 and always be available. Right? That’s stressed in bold type. They write user stories. They accept user stories, and they prioritise the backlog. On what basis do they prioritise the backlog? How do they decide what’s important?
They talk to these folks over here, and if you remember these folks don’t know how systems are built and they’re mostly writing down what their customers told them because they don’t really have a deep understanding of how the systems work. So this is not the ideal thing, right? Because the narrow definition of product owner means I never ever ever am allowed to leave my chair, go out in the field, and meet customers in their native land, and I have no reward structure that forces me to talk directly with end users. Now, some product owners are doing a great job and doing that anyway, but they’re mostly not in a reward system that encourages it. Right? So narrow definition of product owner. Narrow definition of business unit something or other. Big gap. Okay.
So let’s draw better. Better looks like this. I have a product manager, and I’m gonna do some careful definition here. For me a product manager is somebody who is in their own single person both talking with users and working with their team. They’re probably spending 50% of their time with the team and 30% of their time directly with end users, customers, and buyers, prospects. Right? They’re not delegating it on the 2 sides where one does 100% of one and the other does 100% of the other. Fail mode. I’m putting in a single person now. Now we’ve reduced the hops by one. Still not the best one, but at least we have one person who both talks to users and works with the team.
There’s one more step, looks like this, where I co-locate the product manager with the development team, and then I do something else really special. I’m gonna embarrass Elizabeth here. Is that okay if I do that?
Rich Mironov: Alright. So Elizabeth Griffiths is a product manager here at Campaign Monitor, and she interviewed me. I’m a Campaign Monitor user. I’m a customer. And she and her team interviewed me 3 weeks ago?
Rich Mironov: Over a video link about how I’m using it and what I like and I don’t like, and in the room, in the conference room with the video was a designer and two developers. So rather than Elizabeth being the person who takes all the notes and decides what she heard by herself and communicates it, we had in the room members of the development and design team who could hear for themselves, and some of them got to ask questions, so that we could get the smart kids in the room together, all of us, and hear what customers say and learn what the problems are and ask hard questions of me and get it direct from the source. That’s how the good kids in Silicon Valley get this done.
By the way, did we talk about motivation already? So the number one motivational thing for our team is that they get to see and hear and listen to real end customers say, “I liked it. I didn’t like it. I use it. Here’s why.” Whatever.
That’s the number 1 driver of productivity and joy on your development team. It’s having no mediation between them and the user other than when I do these I tell my developers they’re not actually allowed to speak until I know how it’s gonna go. They can write questions on post it notes because we get in trouble. But side by side here. We do the discovery together so we can all hear it. Designers hear different things than product folks, hear different things than engineering and development folks. Let’s not have a pipeline problem. If I’m gonna design a team structure that’s really gonna work that’s what I’m gonna do.
So now let’s finally draw some org charts because org charts are how HR folks think. So, here’s the product structure I like. I’m gonna tell you that there’s some value stream that’s part of my product suite, whatever it is. It’s some piece of the product where I can both have a focus team that’s stable and long term. I don’t swap them out. I don’t borrow. This is a real team. And I can identify who the users of this part of the value stream are. If it’s a debt collection module then I know who the debt collectors are and I know who’s building it. If it’s an admin and reporting module I know who the admin users are and I know who’s building it.
So the product manager is instantiating frequent in depth conversations, and they’re not sales conversations. Somebody tell me how you know you’re in a sales conversation.
Audience: Can we close the deal?
Rich Mironov: Can we close the deal? Right. How did this conversation start? A sales person called you up and said, “Can you get on the call?” That’s a really good hint that it’s a sales call. What’s your job in a sales call?
To help close, right? Because if you don’t do that you don’t ever get invited back. But there’s usually one issue that the sales team wants you to address and it’s technical and whatever. Address it and get off the call. You’re not there to ask long open ended questions. You’re not there to fish for futures. You’re not there to compare with competitors. You’re not there to mess up the sale. Sales calls are great, but they’re no way to learn anything. You’re welcome to be on sales calls, as you should, but let’s not count them as learning.
My product managers have frequent in depth non-sales learning conversations with users, buyers if those are different from users, prospects, lost deals, all the time. 3 times a week, 4 times a week, you tell me. Because if my product managers don’t know enough, if they’re not the primary source of intelligence, they lose the right to write user stories. Because mostly those are the wrong things. And they lose the right to prioritise the backlog because they have no judgement of their own and they’re listening to some random stake holders.
Rich Mironov: product structure I like
In my software companies we have no product owners. We have product managers. By the way, we pay them better and we promote them. So if you’re a product owner go back and ask for more money and a better title. And the product managers own a piece of the value stream that includes development and users. If you’re not doing that I don’t know what a product manager is. But usually there’s more of these because remember we’re scaling our team. So let’s get 4 of these.
You got 3, 4, 5 of these you’re gonna need a director of development because the development teams need to report somewhere. A director of product, maybe, or a product line manager because they need to report somewhere. But notice that each of the product managers owns the direct customer relationship and therefore the judgement about what’s important.
So, again, I love product owners individually, but I never have product owners in my organisation. You’re either able to do this job and I promote you to product manager and give you more money and more stock options and whatever else. In San Francisco you’re allowed to bring your dog to work if you want. If you’re an engineer you can demand special snacks in the kitchen because we think engineers are better than anything. Value is striped across left to right. We don’t do column title divisions where we have product owner here and business unit there because it doesn’t lead to good results. I love the scrum folks, but I don’t think that any of them understood how products are built for the market.
Rich Mironov: product structure I don’t like
Let’s look at a few other ones. Here’s a structure I don’t like. We have that same picture, but the product line manager does all the customer interviews and filters all the stuff and has all the opinions and represents all of the pieces of value. We’ve added a hop. We’ve added a hand off. We’ve reduced all the veracity or truth or content or flavour. We’ve washed out all the good stuff, and that’s the, “I want to be the boss of you,” story. In Silicon Valley where we pay people astronomical amounts to be way smart the, “I’m the boss of you,” is a pretty lousy answer.
Rich Mironov: product structure I don’t like
Some more that I don’t like, and you won’t be surprised. This is the classic inside and outside product thing. Again, so here’s the business unit on one side where the folks who face customers who are really … They often get captured by sales and marketing and they’re pushing for more deals, and they go light on content and expertise because they work for folks who don’t care about deep feature function stuff. And on this side, and again whether you call them product manager or product owner, or maybe the team picks somebody, whatever, they are isolated from the real stuff. And what we’re shipping across is requirements. Let me back up. If what you’re shipping across is requirements what mistake did we already make?
Audience: Wants instead of needs.
Rich Mironov: That’s right. The folks on this side decided what the problems were, decided what the solutions were, and wrote a bunch of requirements. By the way they have no clue how our systems work. Okay? The folks on this side are gonna do what they’re told. Recipe for success? Not in my valley. That gap where we ship requirements over instead of problem descriptions and group context is a great way to get things into a schedule and to demand results and output, but it’s a lousy way to get products built.
Okay. Some more ones I don’t like. Let me do the product owner thing, again with apologies to anybody who’s currently a product owner. This isn’t personal, but here’s our fail well. I believe that the scrum defined product owner job as written in every scrum book you’ve ever picked up is an entirely failed model if you’re in the product business. Now, if you’re in the IT shop business, which means you’re a captive group that works for some bank or airline or government agency or telco then IT is all about reducing costs and giving the business unit whatever they want and delivering it on time. If that’s the business you’re in then product owner is actually an exact match because you take your little spec to the head of financing and you say, “Are these the reports you want?” And the head of finance says, “Yes,” even if nobody else in finance would have approved those or used those. And you meet your obligations and you ship those reports.
Again, I’m over simplifying, but the product owner job assumes somebody else knows enough to do the right thing, and I observe in the product world that’s just not true. Product owners write and accept the prioritised story. They’re available to the teams at all times, which means I know they don’t talk with very many customers, and since I know that all the joy and love and good product design comes from talking with customers, I know that until they break their bonds of their job description, they can’t succeed. The things I see, we’re always talking about proxies. You guys know about proxies? This is a curse word for me. Proxy means talking to somebody who’s not a user who has an opinion. Bad bad bad.
We may want our product owners to talk with customers, but we don’t actually make time for them to do that or train them how to do that or coach them how to do that or reward them for doing that, and so you know what? Most of them don’t do it because their bosses don’t care. We focus on productivity. Everybody talks about story points. Story points are great. Customers don’t pay us for story points. Customers pay us for delivering products that work better than the competition and solve their problems and deliver customer value. All of the sort of intermediate we’ve assigned customer value point things, forgive me, I think they’re mostly worthless.
Most importantly, and this is an organisational problem. Again, it’s not about you as a product owner, but product owners are almost always assigned after we’ve made all of the hard decisions about what to invest in. So first we decide to do a whole major rewrite and refactor of our entire system, and then we assign 22 teams, and then we figure out who the product owners are. By the way, that’s a failed project even before it starts, and the product owners are stuck with it. As a product manager, I want to be at the very front of validation because if it’s a bad idea … By the way, most of the ideas are bad. I really wanna shoot it down in those first 6 weeks because I don’t wanna spend the next 5 years working on a bad idea. I wanna kill it dead right away and move onto something that the market cares about and that I can love.
So if I put people onto a product or project after the hard decisions are made they are stuck with whatever we gave them. It’s not that product owners are bad. It’s that we put product owners in a little box where it’s really hard to succeed at what product companies need to do. It’s not about judgement . It’s about organisational structure.
I will tell you that product owner is a role. In my shops it’s a role that every one of my product managers spends about half their time doing. It’s not a job. My product managers spend about 50% of their time facing their teams, who they love and protect and bring joy and t-shirts and pizza to, and they spend about 30-35% of their time working with end users and prospects and folks who are really gonna use this stuff, and the last 15% is managing up to the executive team and keeping them from helping.
But the product owner is a role that my product managers do part time. If you’re doing the product owner thing full time I don’t understand how you’re actually creating stories and setting priorities because you’re getting it from somewhere else. And mostly the people you get it from are clue free.
Rich Mironov: product structure I hate
No surprise, here’s a product structure I hate, because I see that organisations that split IT, we build stuff on demand, from the business rarely build anything useful in the software process. It’s already broken even before we put anyone in any of the jobs because IT is rewarded for reducing costs and IT is rewarded for delivering on time whatever these idiots over here in the business wanted who don’t understand the choices we have to make. So, I’ll just fill it in for fun.
So, on this side you’ve got all kinds of people who are demanding things, and there’s some political process where somebody important makes a list. We don’t know why. But somebody important makes a list. On this side we’ve got a CIO or something, and we almost always have pools of resources. Anybody wanna go to work because they’re a resource? Pools of resources is demonstrably the worst way to build software. We’re gonna borrow people. They’re not gonna own the things that they had before. We’re gonna have … Pools of resources is a sin in my book, although it’s legal in some countries. I don’t care if you’re a product owner, a tech pm, a BA. I don’t care what you are. If you’re working with a bunch of borrowed folks for the short term trust is missing. Everything is missing.
Of course across the top what we’re gonna flow is technical requirements on the assumption that the people on your right actually know what they wanted, and dates. And by the way, they never line up. The dates are always..
In March 2018, Rich Mironov visited Australia and presented to the Product Talks Sydney Meetup Group on building and scaling Product teams. This blog is a transcript of part of that meetup, focusing on how to hire the first Product Manager at a startup.
Rich Mironov presenting on why we need Product Management
Let’s talk about your very first product manger.
Somebody’s gonna do this stuff, and the org chart for a start up usually looks like this. The CEO, by the way, does everything except tech. I’ve been the CEO. I had a couple of really really short painful turns on that, and I won’t ever do it again. CTO, VP Engineering, whatever, and those folks build stuff because until we have something to sell we don’t actually need sales people because they’ll just go out and sell something else. If you look at the job description you’ll see that the CEO does pitching, does funding, does HR, does real estate, does hiring, does legal. Right, all things. The CTO or the VP Engineering is usually owns architecture and code, but also is in on all the customer pitches and maybe the investor pitches, and you hope between the two of them they have some experience maybe. And the other 3 folks are doing whatever. They’re doing front end, back end, code, whatever.
Lots of shared titles. Notice there’s nobody here who could price and package a piece of software if you held a gun to their head, which you guys have less of down here than we have back our way. We’re gonna make a tremendous number of product mistakes in this first phase, which is gonna drive the need for a really good product manager.
We’re gonna hit some scale. Scale for me is usually between 12 and 20 something employees where there’s enough people and enough confusion and enough promising and probably their first or second sales person that we’re in trouble. We’re gonna find that there’s n squared employee conversations. Everybody’s talking to everybody, which is fine when you have 6 people. At 18 this is a problem. We’re gonna find that customer commitments start to appear in ways that we didn’t anticipate.
Costly sales one offs. Yeah, but this really really really big customer’s gonna open up this huge market for us that we didn’t know we were in and make it possible for us to bring in billions of dollars that we don’t understand, so can’t we just build this one thing for them. It’s not gonna take much engineering. I bet it’s only 10 lines of code. Right?
Pricing and packaging. It would be really handy if we knew what features were in the software we’re currently shipping, what the unit of pricing was and how much we expect to get, even if we give a big discount. Engineers are bad at this. Sales people are bad at this. Nobody’s doing it. And then here’s money. You guys know this phrase? This is what every sales person in every situation says about all things. My one customer says they need it, and I didn’t actually dig very far to understand what they meant, but I bet hundreds of customers want it so we should build it. Welcome to the product management vacuum.
I think the time to hire your first product manager: 12, 18, 25’s on the outside. Somewhere in here you must have one. The complexity’s outgrowing the ability of the founders to remember. Promises made that weren’t written down or on a post-it note that isn’t sticking to the wall anymore. Sales pressure is starting to zap our ability to say “no” to things. You need to be able to add lots more customers with less work instead of fewer customers with more special cool stuff that’s just for them. And then what kills every start up is massive numbers of opportunities and no choice among which things are important. Right? So, focus focus focus focus focus.
Here’s my stake in the ground. My point of view. My particular bug bear about hiring your first product manager. The most important thing is you have somebody who can actually do product management as demonstrated by having done it before. This would seem obvious, but it’s never obvious. If you were hiring your very fist VP of sales the very first questions you’d ask that person are, your candidates. What would you ask them?
Audience: How many sales you did?
Rich Mironov: Have you ever sold before would be a good start, right? Do you know what quota is. Did you meet quote at your last couple of companies. Right? If you’ve gonna hire a chief financial officer what’s the fist couple of questions you might ask?
Audience: What’s the biggest company you’ve managed?
What’s the biggest company you’ve managed? Do you know what finances are? Assets, debits, do you know what the tax laws are? How about HR policy around payroll? There’s things you must know as the CFO, and everyone assumes that before hiring a CFO you would ask them about those things. If you were gonna hire a software architect … Do you guys have software architects down here? I hope so? Right. What kind of questions would you ask? Tell me about the last 5 or 10 big pieces of software you built and how they survived in the market and how the architected. You wouldn’t hire somebody out with a 2-day scrum master course and say, “Okay, we can make you a software architect.”
Yet, everywhere I go in the world we find that the first product manger in the door is somebody who has a different set of qualifications. Here’s a few that I won’t agree to, but here they are. They’re a subject expert. We’re doing 3 factor authentication. Nobody can really understand 3 factor authentication unless they have a doctorate, 9 years building it, so we’re gonna hire an engineer who’s an expert at building 3 factor authentication. Also the challenge with experts is they are so expert that when they interview users they spend their time telling the user what the user needs …
[It can also be an] eager volunteer. You know I’m not a very good developer or project manager or sales engineer or whatever. The product management thing can’t be that hard. Pick me. Now you might do that if you’ve got a team and you’re ready to mentor somebody and you have time and cycles, but your first product manager in the door, not so much. I think scrum masters and project managers do something really really really important that’s different from product. So just because you’ve done those jobs, thank you very much. Okay.
Anybody have a CPSO? Certified Scrum Product Owner certificate? I think that’s great. A good friend of mine, Scott Sehlhorst in Austin taught me that a weekend at the dude ranch doesn’t make you a cowboy. It’s great that you got a 2 day class. The thing we’re doing is life or death for my company. I’m not sure I wanna bring you in after 2 days of training. Sorry.
I’ve interviewed thousands of people over the years. I’ve looked at thousands of resumes, and everyone’s done something just like this. Well, no, they haven’t. If you haven’t been a product manager you don’t know how hard the job is. You haven’t spent the last 2 years saying no to people for things they want. You haven’t had to manage upward in an organisation where you have no authority. It’s hard. This is hard.
Let’s talk about the number 1 failure mode. If you’ve been able to hire a senior or an experienced product person into your company, what’s the number 1 failure mode where those folks don’t thrive or don’t succeed or quit? Anybody? We spent a lot of today talking about it.
Rich Mironov: Micromanagement. Yes. Or, other things?
Rich Mironov: Stakeholder management. Yes… The CEO and the head of sales insist that they are the person who represents what customers want, and you the product person are welcome to do implementation. Thank you. Take notes. Here’s the post its.
If you brought somebody in who’s senior enough to do product management and that’s how you treat them, and if every single day you come to them … We talked at length today about the word just. Any time you use the word “just” in a sentence like, “Can’t we just slip this into next week’s print? Can’t we just bang out those 2 features? It can’t be that hard.” The word “just” is the hint that the person talking to you has no clue how to do this. If you’re a senior product person and you’re at a company where they give you no responsibility to speak for customers and figure out what’s important it’s pretty frustrating.
So what I see is product management lobbying for broad segments instead of customers. Outcomes: here’s where our users care and what they’re gonna do with it. Low friction repeatable products instead of one offs. Clear commitments. How do we decide if there’s a special on the contract? Your product manager will lobby endlessly for these things because they’re necessary. If they turn out not to be possible, well time to hire another product manager because your good one’s out the door. I see this endlessly all day long at start ups where the CEO micromanages and won’t give much ground.
In March 2018, Rich Mironov visited Australia and presented to the Product Talks Sydney Meetup Group on building and scaling Product teams. This blog is a transcript of part of that meetup, focusing on why we need Product Management.
Rich Mironov presenting on why we need Product Management
Why do we need a product management team?
Let me back up and say I’m 30 years in Silicon Valley product management. It’s not a new thing. Some of you may not have been born when I first picked up software product management. Good for you. But it hasn’t arrived every place at the same rate. So if it’s new here, great. I know that we’re growing it up.
Part of my journey was 6 start ups. Four of those are what we call good life learning and character building. And what I do a lot of the time is I parachute into San Francisco area companies as the interim or temporary head of product. So, either the head of product walked out the door for good reason or they forgot to have one or they don’t know how to spell it, whatever it is. And they’ve tried everything else. So then they call me and I come in for a couple of quarters to get everything running again. So my experience is a little more at the small end, and I tend to the enterprise.
I observe, certainly in start ups but also in really big companies and everything in between, most of the folks are incentivised to think about the current quarter. Right. But especially in start ups, you know your investors are gonna have a really sharp talk with you at the end of the quarter if you miss your numbers. So there’s tremendous incentive to think about the next 31 days or however many are left in the quarter. So, short term revenue, short path. How do we get the next thing done?
I think of product management as the folks who want to balance that enthusiasm, that wonderful enthusiasm, with a little bit of market honesty. Things like, “Do we actually have market fit? I know you’d like to tell the board we have market fit, but do we have any evidence?” Are we shipping whole product that actually works and solves somebody’s problem, or we’ve got some fractional things out?
[There are] a lot of fist fights about segments. Are we really in a segment or have we just drawn a line around our first 4 live customers and anybody else who can fog a mirror and has revenue and will sign a purchase order?
Start ups as well as big companies tend to focus on individual customers, individual accounts. Do they have money? Product management has to be the organisation that thinks about segments and groups and overall success, or we end up in a pure sales driven place that ends up really badly. Right?
I think it’s our job as product folks to represent the customers as opposed to the internal stakeholders. The customers pay our company money. The stakeholders are internal folks. Who gets value? Who pays us money? Who rewards us for doing a good job in the market? So, we have to think about company level things and product level success rather than the enterprise sales team that gets to go to club in Fiji if they close that one big deal. I know we’ve all been there. Okay.
This is an input output chart. I’m gonna rush through it. Product management in the middle. I built this a decade ago for engineers because engineers need input output diagrams to understand things. Product management in the middle, not at the top, because nobody works for us. We have responsibility but no authority.
Rich Mironov: What does a Product Manager do?
What’s the stuff? What’s the important things that flow from the product management group to development? And by development I think everybody who does real work: designers, dev ops, tech pubs, development teams, whatever. The folks who actually build stuff. What are we going to supply to them? What are they looking for?
Rich Mironov: Priorities are good. What else?
Audience: Problems to be solved.
Rich Mironov: Problems to be solved. I think that’s the winner for a book here. Problems to be solved, excellent. What else?
Rich Mironov: Direction, yeah, not so much. We may give them direction, but they’re not excited about taking it.
So here’s my list. I’m gonna start with context and conversation. We as product folks have to provide a really clear sense to our teams of why we’re working on stuff, why it matters, who it’s for, how it’s gonna derive value, and why they should care. This is really important for everyone in a product management job to remember that your development team … Well, first of all, they’re all smarter than you. How do we know this? Because we ask them. Right? All developers believe they are smarter than their product managers. It’s a fact.
What they need, what they want from us more than anything else, because they may be sort of introverted, but they’re deeply emotional about what they do. More than anything else in life they want to be building products or work that other people are gonna use, that’s gonna lead to value, that they are gonna see in the market place, and it’s gonna give them feedback that their work was not wasted.
There’s nothing worse than being on the engineering and development side, doing your best, and have the silence in the market be deafening. So we as product folks must must must must share the love and the care for our users, set the context, share the problem that they have. We don’t have to actually come up with the best solution, because if you remember, they’re all smarter than we are. So we need to get the smart folks together to find the solution, but we need to communicate context, market view, priorities, problem statements, ethics and user stores if that’s what we’re using. I don’t actually care. Typing into Jira is not how we add value, although sometimes we do it.
What do we get back from the development side of the house? Anybody?
Rich Mironov: Questions, yes. But that’s not what we’re looking for.
Rich Mironov: Solutions. On a good day.
Audience: Trade offs.
Rich Mironov: Trade offs, yeah, no we do those. Here’s what I was looking for. I’m gonna call the product bits. This is the part of the product that’s the actual technology or software. Your engineers actually believe it is the product. It’s a part of the product. Not the whole thing. And we know this because what’s the marketing and sales side of the house actually looking for us to deliver to them?
Rich Mironov: Leads. Great, but no.
Audience: The prototype?
Rich Mironov: Yeah, the prototype, maybe. They don’t care.
Audience: Market awareness.
Rich Mironov: Market awareness. No, they don’t care. Well, marketing cares. Sales doesn’t.
Audience: Customer value.
Rich Mironov: Customer value, yes. Blah blah blah. So we’ll just keep rolling.
Rich Mironov: I’m here to tell you that what sales wants more than anything in the world is a story that they can repeat to users or prospects that will cause the users and prospects to fill out a purchase order or send money. They want the high level. They want the message. They want the benefits. They don’t actually care at all about the features. Pricing because we shouldn’t ever let our sales team set pricing or bad things happen. Segmentation because it would be nice to know who this is for: small business, big business, solo entrepreneurs, consumers at home.
Rich Mironov: What do we get back?
Rich Mironov: Dollars. The dollars don’t come back to us. What do we get back? Go.
Audience: User feedback.
Rich Mironov: We get feedback. What do we get feedback about?
Rich Mironov: Problems. I’m gonna call it input and feedback, but what I mean specifically is here’s why we didn’t close the sale. So if I survey your sales force, and I’m thinking again enterprise, the number one reason we closed deals this quarter is … Every sales force in the world. What’s the number one reason we closed deals this quarter?
Audience: Because the sales people are so good.
Rich Mironov: That’s right. Because we have an awesome sales force. All of our sales people are above average. We are terrific. Coffee is for closers, right? If you survey your sales force about why we won deals you will get one answer right away, which is that they are great, great, great sales people. Very useful. And the 2 reasons we lost deals this quarter?
Audience: The product.
Rich Mironov: The product. What about the product.
Audience: It wasn’t something we could sell.
Rich Mironov: Yeah. We’ll find out that we were missing just a couple of hundred features, right? And what’s the other reason?
Rich Mironov: Price. What about the price?
Audience: Too high.
Rich Mironov: Too high. Right.
Rich Mironov: So, if you survey your sales force to figure out how to improve your product you’re gonna learn these 3 things, I guarantee: They’re a great sales force. We’re missing just a boat load of features, randomly, and we should lower the price by 2/3. All sales forces will teach you this.
So that’s why it’s really really really really important that we draw this other line between you the product folks and actual users, actual buyers, actual win/loss folks, actual prospects, where you are talking directly to the people who use the stuff or would like to use the stuff because they’ll actually tell you something as long as you’re not on a sales call. They will tell you about their problems and their issues and what other things they tried. I will tell you that if you don’t talk to those folks you don’t know enough. You don’t earn the right to deal with the folks on this side because they’re smarter than you and you don’t have any more data than them.
When I parachute into a company as the interim or temporary head of product I get an hour each with all the folks who are now on my staff and I ask them a bunch of questions. One of the important ones is, “How many customers did you talk to in the last 2 weeks?” Some of them will give me a good positive number, and some of them will tell me about a barrier with the sales team where they’re not allowed, and I can help remove that. And the third group who don’t talk to customers and don’t have a good reason for it, I look for a way to promote them in the first 2 weeks to some other department in the company because they’re not product people. Sorry. Thanks for playing. Last thing. The executive team wants the stuff that the executive team wants from us?
Rich Mironov: Roadmaps. They don’t actually care about roadmaps, but yeah.
Audience: Results and forecast.
Rich Mironov: Results and forecast. And what are they denominated in?
Rich Mironov: Revenue, right. And here we would say dollars.
Rich Mironov: So, what they’re really looking for is a revenue forecast and maybe some commitments and roadmaps. I observe that executive teams mostly can’t hear anything you say other than when it’s denominated in revenue and dollars. Don’t waste your time.
Rich Mironov: What do we get back from the executive team?
Rich Mironov: Funding. For?
Rich Mironov: Funding for development. That’s you right? Okay good. Three. One down. One to go. Here you go.
We don’t get money for more product management. We get money for more development because in every company it’s true that your development team isn’t as big as your dreams. And we have more things to build, so we are always always always pitching for more development team so we can get more products built. So what we get back is a budget for development or staff for your left side. And, by the way, the target that was on my little forecast is what comes back, but it’s been moved forward 2 quarters. Right? Good, okay.
And if I sit in that grey bubble, what’s really really important is that I have to be trilingual. I have to speak enough development that they don’t dis-invite me from the stand ups, lock me out of the room, look at my button down shirt and get scared. I have to speak enough end customer user that I can empathise and understand their problem set, and I have to speak enough thumbnail finance on the back of an envelope that I could put a number or two that has a dollar sign on it in front of the things we need to do. Right? Very strange odd intersection of skills. Nobody is born doing this. There aren’t a lot of 6 and 7 year old kids who go to their parents and say, “Mom, dad, I’d like to grow up to be a product manager.”
Alex Osterwalder. Anybody know Alex or his very famous books about the business canvas and the value canvas? I coach his product team in Toronto. Really really smart folks. Alex teaches something which we all knew but didn’t really get clear on which is when we talk to customers, users, everybody, they will always describe solutions to us. And it’s our job to dig through that because the solutions they describe are almost always wrong. And we have to figure out what the problem was that caused them to create a solution for us because they don’t understand our systems and they’re not software folks and whatever. They have the wrong view.
But people always come forward with, “Here’s what I need you to do.” And they’re almost always wrong. But underneath it is a problem that they want or need solved, and they’re almost always right about the pain that they’re experiencing. So it’s our job to rip the solutioning off the top and dig deep to figure out what the pain or the problem is and reframe that up. Really, really important. Because if we don’t do that … If we do what they ask us to do, tell us to do, we almost always deliver something useless.
Let’s talk about product leverage and a little history because I’m old enough to remember this stuff. In the 80s when I first joined the ranks of product managers having a business case was actually an advantage. It was above average. It was a differentiator and a distinguisher, but that was in the 80s and that’s over. Everybody’s gotta have enough of a business case to justify the thing they’re doing. Not a differentiator.
Rich Mironov: Where’s our Product leverage?
In the 90s we discovered, or maybe already knew, that whole cross-functional teams where we have some devs and some test automation engineers and some tech writers and whatever else we need, right, dev ops, on the same team in a stable configuration that we don’t borrow from project to project is how we get a whole lot more joy and throughput and better product build. So in 1992 if you were doing that you got bonus points and maybe some advantage in the market. Anybody who’s not doing that today? Didn’t get the telegram we sent out in 1993 from Silicon Valley to the rest of the world. Okay.
Agile Development. I’ve been working at Agile since maybe 2005. By the way, it was not new in 2001, but we didn’t know what to call it before then. When NASA put the first folks on the moon it turned out they were doing a bunch of agile development on some very old computers, but whatever. In the early 2000s you could claim some advantage by having a really good agile team that turned over and had good velocity and got stuff done faster.
So, the thing that’s left, and this is also not new, but I will tell you it’s not uniformly distributed yet, is really understanding problems and then framing good solutions to those problems. You can call it jobs to be done. You can call it customer development. You can call it validation, design thinking, whatever you want. They’re all synonyms for me.
We on the product and design side still have a chance to get advantage versus our competitors by really understanding the problems that customers have instead of the solutions they want and then getting our teams together to really think as a team about the best ways to solve those problems.
The idea that we as product folks go out into the field and gather requirements as if we have a basket and they are daisies. Right? You plucked ’em; you put them in the basket. You press them and you make user stories out of them. No no no no no no no! If we take what our customers ask us to do on face value we mostly build the wrong thing. Even worse, if we take what our internal corporate stakeholders ask us to do on the assumption that they have thoughtfully talked to real customers, we’re almost assured of building something worthless.
So, we don’t gather requirements. We gather thoughtful analysis of problems, and when we bring it back to our teams … Because if you remember our teams are smarter than we are. So how do we get our whole team together to work on solutions if we’ve correctly framed the problem? We want to frame the problem. We want to get some good solutions, and then we have to earn our real customers’ love and trust by delivering real good products that do the thing and deliver value over time.
By the way, I believe we have an obligation of trust and honesty with our end customers. As a product manager, and anybody on my team, if you lie to a customer and I find out about it you’re turfed. You’re out. There’s the door. Don’t let it hit you on the way out. Okay? I don’t care what anybody else in the company does. Actually, I do, but it’s not my job. Product managers are the people at corporate who represent their products and protect their products like their children because somebody has to, and we never lie to customers.
Alright, so that’s why we need product mangers. Somebody’s honest. Somebody thinks long term. Somebody thinks about customer value and segments as a whole and building the right thing and validation.
Product Talks Meetup: Product Management Art or Science
“To be a repeatable practise, we’ll be exploring the unknown over and over again, it has to be a scientific method,” said Nick Coster, Head of Training and Co-founder at Brainmates.
“We talk about test and learn, test and learn, and that’s not really what you do in art. So, if you wanna test and learn, you have to have a methodology and an approach that will deliver better results over time, and to me, that’s a science,” he added.
“I don’t think you can have innovation without creativity and imagination, you need to be able to invent new possibilities with creativity and imagination and individual artistic input. But then, you need to take those ideas that come through that artistic/creative process, through a scientific method, in order to understand whether you should continue to invest in that idea or that artistic product.”
“Having been a scientist, and having left, maybe my opinion is already known,” started Liz Blink, Digital Customer Experience Manager at DELWP Victoria.
“But, I think for me, I think the scientific practise, and having a hypothesis and testing and learning, is fundamentally got to be a core part of product management,” Liz said.
“I’m gonna say Art,” said Richard Linstead, Entrepreneur-in-Residence at Westpac Group.
“I think everyone else was reasonably equivocal, and that’s because it is a trick question… of course, it’s both an art and a science… [But] you can’t be a great artist and come up with new and innovative ways if you haven’t also already learnt all the disciplines that went before it. So there’s an awful lot of discipline that goes to becoming a great artist,” he added.
Things became really interesting when the debate was applied to the practice of prioritisation in Product Management.
“A significant part of the product management role is prioritisation, and picking the right problems to solve. And I think that that ‘picking’ process… there’s an art to it, because there is a lot of unknown factors until you start an experiment,” said Katherine Santer.
“To be honest, actually, I’m really promoting the scientific method as a way to prioritise. So, as much as possible, we want to get as much quantitative data to influence our prioritisation, but there is a limit to how much quant you can get for a particular problem, and so at that point, I think that’s where the art comes in to prioritising,” Katherine added.
“I think in terms of prioritisation, you wanna have a set of consistent factors that you’re using to measure it. Sometimes they need to be some level of gut feel, because you can’t wait for perfect information all the time in a marketplace. But, at the same time, you want that to be as transparent to the rest of the business as possible, so that if you had to make the same decision a second time, it wouldn’t just be because of the opinions in the room that swayed it one way or the other,” said Richard Linstead.
Liz Blink held a strong view: “[It’s] the gift that we bring to the organisation. We’re bold enough to say ‘We’re gonna try this,’ and we’ll be accountable to it afterwards, and we’ll talk about why it worked or didn’t work, and what we would do next. But really, if someone’s asking you to rank it for them, then they’re not willing to put any thought into it, they’re just avoiding the decision-making.”
“The expression or application of human creative skill and imagination, typically in a visual form such as painting or sculpture, producing works to be appreciated primarily for their beauty or emotional power.
And interestingly also:
“A skill at doing a specified thing, typically one acquired through practice.”
“The intellectual and practical activity encompassing the systematic study of the structure and behaviour of the physical and natural world through observation and experiment.”
And interestingly also:
“A systematically organized body of knowledge on a particular subject.”
This blog post was based on the transcript from a Product Talks Sydney Meetup, hosted by Data61 and Brainmates. If your organisation would like to host a Product Talks, or if you have an idea for a presentation, please contact firstname.lastname@example.org
I’ve often seen jobs advertising for an agile product manager, and it drives me nuts! What is an agile product manager? For me it indicates a profound misunderstanding by businesses of the role that Product has to play. In this post we’re going to explore the relationship between Product and Engineering; how the product process differs from the engineering process; and how that impacts how we work with them.
The Product-Engineering trap
I’ve been guilty of focusing on the number of stories that I’ve completed because that felt like an achievement. It is, in a manner of speaking but it isn’t my achievement as a Product Manager, it’s engineering’s achievement. The measurement of Product Management should be based around the product process of delivering value: have I found an unmet need and what am I doing about it? How is a feature/product that we released performing and are the metrics improving? The problem is that often the metrics of a product or feature are not immediate, and take time to resolve into concrete results. So in the meantime, what do we do? We get busy and report engineering outcomes in the interim. Over time, that becomes our default mindset: to report engineering metrics.
Product process vs Engineering process
The product process and the engineering process have very different goals and very different metrics. Product processes focus on delivering customer value, essentially the WHAT and the WHY of a product. How we measure that value is primarily through the P/L. Engineering processes on the other hand focus on efficiency, the HOW if you will.
The engineering process is all about building efficiency. If you examine the metrics that it upholds, you’ll notice a similar theme – how units of work are delivered.
We shouldn’t be measuring product teams by the number of stories they’ve written; how much activity they are doing; or by how many features they’ve released. Rather, they should be measured in accordance to the metrics that align with clearly defined Customer Value KPIs. From experience as a Product Manager at eBay, I am well aware of the pressure of having to deliver something, anything in a release cycle as a means of proving that we’re doing our jobs.
Engineering is a stakeholder
We often think about product and engineering being closely intertwined. Reporting lines, org structures and engagement levels confuse the issue, but I’d argue that there is no overlap between product and engineering. Yes, we spend a large portion of our time with engineering however they remain a stakeholder and very much distinct from product. Once we are comfortable with this separation, we can disentangle ourselves from engineering processes.
Now I’m certainly not suggesting that we are ignorant of how engineering works – the better we understand it, the more empowered we are to influence it. What I am saying is that as Product people, we should be looking at what the right customer value to deliver is and not getting our hands dirty in the day to day process of building feature that enables that value.
There is no such thing as an agile product manager, just product managers who know about agile processes. A strong product manager will be able to work with any engineering process because they have determined that their function and value is delivered through different means and measures. Consequently, it is important that Product must take ownership of its processes and not use engineering processes as a proxy because of the reportable nature of it. We must be disciplined in reporting on how our product processes are delivering customer value, rather than engineering’s executional activities, which is a much richer and more interesting story.
Over the past year a growing trend has emerged. Demand for strategic Product Marketing in Australia is increasing, at an increasing rate. It’s emerging as a highly influential role in modern business structures, matching the punching power of Product Management. But, why is the role becoming more important and what has this increased popularity in the role done to the supply/demand balance?
We decided to investigate the matter further. Representatives from three prominent businesses in the region were interviewed to get their take on the situation. They were chosen because they all are, or were recruiting Product Marketing positions. Say hi to:
We discussed the role of Product Marketing and current role recruitment with each of the interviewees. The opinions shared in those discussions have been used to form a state of play for 2018 in Australia. First, we will review the emerging interpretation of the role, why the role is important and then, what it is like to recruit for the position.
What is Product Marketing?
This is an interesting question. You’ll get a different answer every time you ask. The role is not particularly new. However, the responsibility it holds to ensure effective market engagement is growing substantially.
Historically, Product Marketing was the process of promoting a product to a target audience. This would explain why many Product Marketers are found performing campaign management, content writing, sales enablement and lead management tasks. However, we see the role as more important than that – more strategic. Indications are that more and more businesses see the role as being more strategic also. Here is a summary of the key responsibilities for a modern, strategic Product Marketer:
Messenger of the Market
At the highest level the Product Marketer is the messenger of the market within a business. They gather the market research to accurately define the target market or target market segments. They know the market and the buyers in market better than anyone in the business. They uncover market problems and the impact of those market problems. When coupled with a solid understanding of their products, they then are responsible for driving a compelling fit between product and market.
“Our business strategy relies on getting our product to market quickly and into the hands of customers. Our development velocity has increased substantially in recent times. It is more critical than ever that we have a champion of product – market fit to ensure our latest developments are communicated quickly and meaningfully.” Robbie Morris, CMO Ansarada.
Product Marketers enable organisations. This is not new, but the internal audiences are growing. It is not enough to enable sales teams. Now, Product Marketing plays a critical role providing clear, digestible intelligence across all parts of the business, about value and needs in the market. This addresses a common problem in larger firms where information is often complex, granular, silo’d and dated, which causes poor company alignment and myriad of inefficiency. With clear, transparent, meaningful messaging being shared across a company, everyone can understand the markets being addressed and the value being delivered to them.
The Definer of Value
Everyone interviewed agreed – Product Marketing defines the value of a product, or bundle of products offered a market. Value comes from solving important market problems with the core capabilities within the business. This is typically a combination of product features and services offered.
Everyone interviewed was satisfied with their team’s ability to develop rapidly, meet user requirements with agility and maintain a high quality service. Needing improvement is the determination of value in the market from these product advancements and then communicating that to the market to create demand.
Value can be communicated a number of ways, but the best way to start is to compile value propositions. These are statements of value a customer can enjoy by solving a problem with your product/service. It can be used as a baseline for internal communications and external communications. But, importantly, it standardises messaging and resolves fragmented messaging and product ‘feature-speak’.
We like this definition of a Value Proposition – ‘a positioning statement that explains what benefit you provide for who and how you do it uniquely well.’ Michael Skok
A Value Proposition, framed using language from the customer, helps everyone concerned understand what the market gets out of using your product(s). This is critical. Without a discipline of communicating with a market-centric frame of reference the risk is we communicate in terms of what our products can functionally perform. If that occurs then it is up to the market to decipher what value they may get from using a set of product features. What if they cannot decipher it? No deal? Does that make your product feature-rich and worthless?
One Plus One Equals Three
There is no disputing that the Product Manager is the master of user requirements. They intimately understand what the user of the product needs and why. But, that does not always translate into what a market or market segment needs.
Market needs can be influenced by macro-economic forces, cyclical trends, emerging technology, etc. There is a need to maintain a strong understanding of what ongoing and emerging market-level needs are. These do not always present themselves at the user requirement level until it is too late.
In many organisations Product Management performs the function of Product Marketing. Certainly, when firms are smaller, and the level of product complexity is low, this is a pragmatic strategy. However, as complexity increases and the customer base grows, it becomes very difficult for a Product Manager to continually switch perspectives between user needs and market needs. There is a point where the Product Manager will be spread too thin.
Agile product development teams can churn out enhancements to their products on almost a daily basis. Much of the prioritisation is based on a rich stream of requirements from the existing user base. But, who is communicating this constant stream of innovation back out to the market? Early adopter customers will know how to exploit new capabilities, but most other customers are so focused on solving their own problems that they don’t know of the potential value building up in that product that matures week to week. Someone needs to paint a clear picture to the market how their painful problems and costly inefficiencies can be addressed with ease.
Product Marketing gives the business skills and bandwidth to focus on continually communicating outwards to the market the value potential being created in a product or suite of products. This frees up the Product Manager to stay focused on user requirements and ensuring production has a roadmap to follow and is performing against that roadmap.
Drivers for Change
So, when does a business decide a Product Marketer is an important role within the business? Again, there would be a different answer each time you ask this question. But, feedback from our interviewees suggests there are two triggers that drive a decision to establish Product Marketing specialisation. These are:
Product portfolio complexity
As products mature and as a business grows, complexity grows. New product development, product acquisitions, business acquisitions – these all add complexity to a business. It becomes more difficult for a business to internally align when team sizes double, then triple, then triple again. It becomes more difficult for the market to understand how a business can offer value when product choices increase and change. What new value can be tapped by a target market by combining some new developments with a product acquisition?
“We have enjoyed substantial growth in recent years. There are more products, more complexity in products, more teams to align, but also more scale to service more markets. We need consistent, validated, transparent messaging across the business, based on market needs and an understanding of the value our emerging capability offers these markets. Specifically, we need champions that understand the value of our products combined in different ways for different markets. Product Marketers are those champions.” Laura Cardinal, GM Product Development, Xero.
Growing Beyond One Product
Many businesses start with one product. The product is the business; the business is the product. But, many businesses grow and expand their product portfolio to more than one product. The businesses position shifts away from being just that of one product.
When talking to our interviewees this event was a clear trigger point that drove the need for Product Marketing as a core competency within the business. Marketing teams could no longer represent product value nuances in their messaging. Now, there is a need to position brand independently from product value.
Product Marketing Supply/Demand
To cut to the chase, when it comes to recruiting Product Marketers in Australia, there is one common theme clearly felt by all of our interviewees – it is very difficult to find appropriate candidates.
Unfortunately, the number of candidates applying for roles, that have experience as a ‘Product Marketer’ is low. Most candidates applying have more field marketing experience – campaign management, lead management, content creation. There are distinct skill gaps being found – those being market research, Vale Proposition creation, multi-stakeholder communication skills and collaborating with product teams.
Some organisations have been on the hunt for a good fitting candidate for more than six months and have had to broaden their search offshore.
“From our perspective Product Marketing in the Australian tech ecosystem is still emerging. Finding people with the right skills and appropriate experience is a challenge, with fewer tech companies head quartered here. We see Product Marketing as a senior role with critical responsibility and find the talent pool is significantly larger in overseas markets such as Silicon Valley. We’re eager to see the growth of this skillset here in Australia.” Alex Wayt, Talent Acquisition Manager, Ansarada
For anyone considering a career move into Product Marketing, now is a great time to skill up and make the change. The market demand for quality operators is high and growing. The opportunity to be highly influential in modern Australian businesses is there for the creative and collaborative. If the local market doesn’t meet the demand now then unfortunately Australian-based businesses will need to secure Product Marketing talent offshore.
Why is it that some products are so much more successful than others? (hint: it’s neither luck or a good marketing budget!)
Kathy Sierra addresses that very question in her book Badass: Making Users Awesome, and we read it for our first book club of the year. Brainmates once again provided delicious drinks, snacks and conversation as we discussed it well into the night.
What’s the book about?
At the centre of this deceptively easy-to-read book Kathy offers one main lesson: most users don’t care so much about how awesome your product is. They do, however, care about how awesome they are when they use your product. And when they’re awesome using product, they’ll tell everyone about it.
Thankfully there is a science to it. It starts by shifting your thinking from creating an engaging product (the tool) to helping users of the product be Badass at what it helps them to do (the compelling context).
Creating a compelling context
In explaining the idea of a compelling context, Kathy follows the story of a person buying a new camera. Ultimately they want to become a better photographer and the camera is just the tool to get them there.
Good marketing sells the dream of the camera leading to better photography. But when the budding photographer brings the camera home they hit a steep learning curve. Equipped with no more than an instruction manual they suddenly face a deluge of complex buttons, dials, and new features to learn about.
Anyone new to photography will tell you they can stick the camera to auto and worry about the rest later. But, the true test of them becoming awesome photographers is how soon they move away from the auto button and learn to use the camera properly.
As product managers we agreed we should design products that effectively set them on a learning path. That way they can achieve the dream that marketing has sold so well.
There was a lot more to learn from Badass than figuring out a compelling context. Kathy takes the reader on a journey of understanding human behaviour and what motivates people to keep learning and being the best at what they do.
The insights about human behaviour resonated with each of us in different ways, prompting these takeaways:
Julian spoke to the enduring value of mastery and deliberate practice. People don’t become experts at something by how much they practice, but how focused they are when they practice.
Arthur was curious about ways to guide users through his product and help them level up so they get a sense of progress. Designing a motivating path with a clear sense of direction mapping what users do not what they learn.
Remove cognitive leaks so that users spend their limited time on the right things. Corinne pointed out that this extends the phrase “don’t make me think” to “don’t make me think about the wrong things”
Nick brought the book’s teachings back to finding the core user problem and the context for which it exists. That’s what product management is all about, right?
For Bruce the concept of guiding users out of the ‘suck zone’ was compelling. Acknowledging to users that things won’t be easy at first is more likely to keep them engaged longer.
What about software?
A general criticism of the book is a lack of examples or case studies related to the software world. This is, after all, a book written for digital product creators. We come from different workplaces and manage a bunch of diverse products, so we spent a bit of time unpacking what Kathy’s teaching means to each of us.
In the software world customers and users can afford to be more fickle. Ivy reminded us that there is a smaller investment on their behalf so we have to work hard to keep them engaged with an ongoing approach. The advantage of working in digital is we have access to a bunch of tools to analyse, measure, and engage with customers like never before.
On the topic of mastery, it wasn’t clear whether it was an achievable or desirable goal for users of all digital products. For example, how would a transactional product like a banking app or 3rd party booking system help a user become Badass at life?
The answer to that question perhaps relates to designing your product to be as simple as possible for the user, minimising their cognitive load.
In wrapping up, Sarah reminded us of something we all agreed: we could easily apply the principles from Badass to our own lives.
We find out at the end of the book the clever way that Kathy has written it. The beauty of her use of imagery, layout and casual language use the very approaches she’s teaching to drive home the core messages.
When it comes to the future of Product Management, there is great focus on the Product Management career.
In October 2017, Brainmates hosted a round-table discussion with six accomplished Product Leaders in Melbourne.
When asked about what’s on the horizon for the profession, the conversation turned to how Product Management is viewed as career and how that’s evolving.
Product Leaders talk Product Management Career
The growth of the Product Management Career
Without doubt, the digital era has been a key contributor to the boom in Product Management.
“We’re seeing businesses now starting to see more and more of a need for product management because they hadn’t considered themselves digital companies before, and now they are. I think there’s just going to be more and more opportunities to really make a difference and professionalise,” said Paul Greenwell, Head of Product, Partners at MYOB.
Nick Coster, Founder and Head of Training at Brainmates agreed: “We’re seeing product managers become a hot commodity.”
How to create more Product Managers to meet demand
There was much discussion about how to make great Product Managers, since many hiring managers report good talent is hard to find.
Nick Coster thinks Product Management makes a great second career.
“They almost had to have done something else before you can have the chops to go product management role. Not because it’s particularly different, but because you almost need that real world experience,” he said.
“Someone coming completely green from university will lack that experience until he’s been burned a few times… Until you’ve dealt with failure and fallen on your face a few times, you’re almost not quite ready to be a product manager.”
Jarod Pickering, Digital Program Manager at Cricket Australia, sees a place for more formalised education.
“Potentially a university course, that could be created… a Bachelor of Product Management. And it becomes recognised as a desired profession,” he said.
Internships and apprenticeships were another suggested solution to help build the right talent.
“The concept of internships that are safe for the organisation, yet are a place of growth for people who are interested in product management… I think that’s an interesting space,” said Nick Coster.
“I’m not quite sure how to crack that yet, but I think that’s something that I’m definitely interested in seeing how that could play out,” he added.
What can people expect from a Product Management career
Product Management has often been characterised as the intersection between the business, technology and design.
This description captures the leadership and collaboration roles Product Managers play, but it’s worthwhile expanding on the purpose of Product Management.
“The focus is very much on solving the problems. I think that’s really rewarding. That getting out there and solving problems, and focusing on that, rather than just technology,” said Paul Greenwell, Head of Product, Partners at MYOB.
Nicole Brolan, Product Director at Seek says Product Management is increasingly about customer contact and research.
She says we’ll “continue to see a huge amount of experimentation going on… emphasis on time with customer, and product really being out in market.”
“People are going to get more and more creative about how they go about doing that, which is exciting,” Nicole added.
Adam Fry, Head of Product Management, Melbourne IT Group, agrees the practice of Product Management will evolve quickly.
“The tools at our disposal – prototyping, A/B testing, data, analytics and AI etc are speeding up the ability of product managers to identify opportunities and really nail the solution much better and more quickly than before,” he said.
What’s the trajectory of a Product Management Career?
Experience in Product Management opens many doors.
“I think it’s a position of influencing, and those who can influence, can be anything in your company,” said Erica Wass, Director of Product at Zendesk.
“They can be the heads of, they can run the whole organisation. They can be on the board… The product experience, because it’s well-rounded, gives you opportunity. You’re going to see former product people doing super interesting things,” Erica added.
How can we develop the Product Management career?
While Product Managers understand Product Management, there are plenty in business who are yet to be exposed to Product Management thinking, according to Amelia Crook, Product Principal at Cogent.
“I think we’re just at the start of the wave of understanding of what product manager is. I think engineers sort of led the way in what was really important for them. Designs had a big wave of design thinking, and understanding, and the training. I think product management is the next wave,” she said.
And along with understanding, will come a greater focus on building the Product Management craft and toolset.
“If we compare ourselves to service designers and UX practitioners, they are very well read. They practise. They’ve got lots of tools and techniques in their toolbox. I think that product managers are getting to that point,” said Adrienne Tan, Founder and Principal Consultant at Brainmates.
Retail is more complex than ever before. Customers are shopping any brand, everywhere on any device on multiple platforms. As if that weren’t enough pandemonium for retailers, the digital age has ushered in entirely new models that never existed before, like selling on social media, or buying online and picking up in-store.
In a retail world with this much choice and this much freedom for a consumer, it’s hard to recreate who your customers are. And, between in-store associates, merchandisers, marketers, digital content creators, social media managers, there are tons of people who need and can benefit from that information.
But you need a single vision of your customers for everything from sales to streamlining your digital experience. That means powerful systems that offer you the ability to track customers, centralise their information, and move their data internally to make this happen.
A cornerstone of this is your identity management system. Here are three key ways that your CIAM fuels your cross-channel retail strategy.
This calls for Customer Identity Access Management (CIAM) – a system that can handle logins from any device and funnel information on customers directly to their profile.
For retailers, Auth0 creates a single profile for every user in your system, and it can store information on their logins, their devices, their history, and centralise other data you want available on customers. You can link accounts back together, so if a user uses Facebook login one time and Google the next, their info still gets back to one profile.
You’re creating the base for the single vision of your customers by using a single profile as the determining source of information for each user.
For customers, this helps make the experience of engaging with your brand consistent. Any preferences they set and any information they give you can be used across all your channels.
To scale your centralised identity management with your business, Auth0 has a flexible user store directory model, so you can host your directory in the highly secure Auth0 server. You can also choose to use your own existing directory. If you ever want to migrate to the Auth0 database, you can do so without requiring a password reset. No matter what your retail size or needs, there’s a way to get that must-have centralised CIAM.
Must-have #2: Omnichannel Customer Experience
Once you’ve centralised your customer in your own database, you can move on to presenting an “omnichannel” experience for your customers.
In essence, this means that consumers are getting a seamless brand experience from you no matter where they’re engaging. With all of the channels available to consumers today, it’s important that people are getting the same brand message, the same options no matter how they engage with you.
Login through a CIAM is a great way to streamline your customers’ first interactions with your brand. When you have a sophisticated identity management system, it can also facilitate branded interaction outside of login as well. Let’s look at some of the ways you can do this with your CIAM:
Enable single sign-on for every brand, on every channel. Regardless of the channel or identity provider the customer uses, there should be a quick, consistent option for them every time they have to log in. That should include in-store access to their account.
Give people a social login option, every time. The benefits of social login are twofold. Customers can easily access their account without having to make a new username and password. They will also benefit from the ease of personal devices where they are virtually never logged out of social, making social login functionally a one-click option. Retailers can benefit from the additional data available from social providers and use that to better connect with their customers.
Use your user profile as a starting point throughout your company. Since your CIAM is now a central store for information from multiple channels, it should be used as a source of information company-wide. That means that in-store associates can bring up their profile to help them and that your marketers can show them ads for products they actually like.
Although the back-end of “omnichannel” retail is moving towards unified retail, consumers will expect that seamless, “omnichannel” experience to stay with them going forward.
Must-Have #3: Integrations
Once you have started to develop a single view of your customer, and your customers have a seamless experience with your brand across channels, the next step is to customise the base you’ve built. This will help you build a robust view of your customers.
That means sharing all the data and insight you’ve stored up in your user profiles with the systems where they’ll be the most useful. Certainly, you’re going to want integrations with your marketing platforms and advertising networks to allow for better-targeted campaigns and in-app advertisements.
That means checking to see what solutions are available out of the box, and how flexible your CIAM is. Getting your profile data into your existing software is worth the effort it can take to streamline your SaaS tools. With Auth0, you can customise integrations for any CMS, CRM, ecommerce, or analytics platform. So whatever CRM or ecommerce system works best for you, you will be able to benefit from your data.
Of course, you also want to check out what features your platforms are offering you individually, not just how you can integrate all your different platforms. Any integrations that will help you get the most out of your identity management are going to strengthen the vision you have of your customer.
When you know your customers, you’ll connect with them
From marketing to sales to product, knowing your customers is a key part of building and maintaining your business. As the digital world offers consumers more and more possibility, forging that personalised connection is more important than ever before.
Building and enriching the single view of a customer is a great way to get to know your customers. Don’t be intimidated, use your CIAM to your full advantage to put yourself ahead, especially in ecommerce and retail.
So you want to be a good Product Manager… what are the skills, traits, and behaviours that will set you apart from the rest?
It turns out that soft skills are highly valued.
In October 2017, Brainmates hosted six senior Product leaders at a round table discussion in Melbourne to talk about the State of Product Management in Australia.
They shared four skills and traits they’ve seen in the best Product Managers: collaboration, storytelling, composure and lifelong learning.
Melbourne Product Leaders talking about what makes a good Product Manager
A Good Product Manager is an awesome collaborator
Product Managers are acknowledged as leaders, but it was clear from the discussion that command-and-control style management is out and servant leadership is in.
“I think a lot of people misinterpret the CEO of product thing as, ‘I have complete autonomy over this thing, and I can do whatever I like,’ which is in my experience, has absolutely been not the case,” said Amelia Crook, Product Principal at Cogent.
“I think a good listener is an excellent start to being product manager because you don’t need to know everything, but you do need to understand the different challenges different teams are facing… and how to bring that together into a whole,” she added.
For Adam Fry, Head of Product Management, Melbourne IT Group: “The drive to ‘find a way’ needs to be partnered with an understanding of how to recognise and navigate different stakeholder situations… and how to influence tactfully.”
“The thing that makes you a super product manager is that you can manage conversations with different kinds of people, with different objectives,” added Adrienne Tan, Founder and Principal Consultant at Brainmates.
Nicole Brolan, Product Director at Seek uses case study exercises during the hiring process to test how candidates engage with others.
Partway through the activity, Nicole reveals that one of the given assumptions is incorrect, to see how the candidate reacts in a pressure situation.
“A massive part of product management is engaging with so many people around the business. To watch them engage with other product managers or leaders when they’re being challenged is really, really helpful,” Nicole said.
A Good Product Manager is an effective storyteller
Closely linked to collaboration and influence, is the ability to tell a compelling story about the future of the Product and what you understand about your Product today.
“I mentioned influencing tactfully, someone who is an authentic communicator and can understand their audience has a massive head start on this. The ability to construct and tell a story is essential,” said Adam Fry.
“You need to create a vision… Communicate that well to your team. Get them onboard with what you’re doing. Get the business across what the data is showing. Make a story out of the data so you can communicate to your audience,” said Erica Wass, Director of Product at Zendesk
Paul Greenwell, Head of Product, Partners at MYOB agreed Product Managers need to make sense of mountains of data.
“Definitely being able to craft a story is key. I think you’re dealing with a whole lot of facts, and figures, and numbers, and information. You really need to be able to pull that together.”
A Good Product Manager is composed under pressure
Paul Greenwell believes good Product Managers are unflappable. They have to be composed as they face infinite demands from the organisation around them.
“[As a Product Manager] you’re always disappointing people because you’ll have five different stakeholders… sales, support, your customers. They all want five different things, and so someone’s going to be number five on the list,” Paul said.
“It can be quite stressful sometimes, and so you want someone who doesn’t get too stressed by that, and can just take it in stride, be methodical, communicate, give people the facts, not get too emotional about it.”
A Good Product Manager is a lifelong learner
Jarod Pickering, Digital Program Manager at Cricket Australia, thinks good Product Managers take control of their personal development.
“Thirst for learning is always up there. Certainly in digital, it’s always evolving, and so they’re keeping up with the trends and really actively pursuing their own professional development,” he said.
Your next job interview
So if you’re looking for your next job in Product Management, think about how you stack up on the soft skills.
If you come across one of the Product Leaders who participated in this discussion, they’ll likely be testing you on key capabilities like collaboration and storytelling.
“I’m not looking for someone who’s technically brilliant, or can do PowerPoint in the most beautiful formatting,”said Amelia Crook.
“I look for people who… connect with people, and connect with users, and communicate effectively, and bring people together, and set a vision, and get people to move in that direction.”
“These are skills that I think are undervalued on product management skills charts,” Amelia said.