Robbie Allan

Episode 22
Brave UX

Influencing Without Authority in Product Management

In this episode of Brave UX, Robbie Allan gives a frank account of the self-awareness, discipline and insight it takes to succeed as a product manager at some of the world’s best product-led companies.

Highlights include:

Why did you create virtual unicorns at Zynga?
What do you do when you’re having difficulty aligning people?
How do you decide which “fires” to let burn and which to put out?
What does a world-class product organisation look like?
Why is it important to be certain what the customer problem is?

May 11, 202101:28:30

Listen on:

Who is Robbie Allan?

Robbie is currently a Product Manager at Meta. Previously he has been a Sr. Director of Product at JumpCloud, a Group Product Manager at Intercom, and a Sr. Product Manager at SurveyMonkey.

At Intercom, the world’s leading business conversation platform, he was responsible for a product portfolio worth over $100 million in ARR.

Robbie holds an MBA from UC Berkley and his writing on Product Management has been featured in Forbes, Fortune, AdWeek, USA Today, and on the front-page of Reddit.

Transcript

Brendan Jarvis:
Hello and welcome to another episode of Brave UX. I'm Brendan Jarvis, Managing Founder of The Space InBetween, and it's my job to help you to put the pieces of the product puzzle together. I do that by unpacking the stories, learnings, and expert advice of world class UX design and product management professionals. My guest today is Robbie Allan. Until recently, Robbie was a group product manager at Intercom, the world's leading business conversation platform, best known for its friendly, almost omnipresent live chat icon. At Intercom, Robbie was focused on product-led growth and responsible for onboarding and first use experiences. To put that in perspective, that's a product portfolio worth over 100 million US dollars in annual recurring revenue. Prior to joining Intercom, Robbie led the mobile product team at SurveyMonkey where his team doubled product usage and increased core user retention. Robbie was also part of the founding team of Carnival.io, a New Zealand and New York based mobile marketing automation startup.
There he was responsible for all things products, including the go to market roadmaps for sales and marketing. Carnival was sold to Sailthru in 2015 for an undisclosed sum. Before leaving New Zealand for the USA, Robbie received the Prime Minister's business scholarship where he then went on to earn an MBA from UC Berkeley in 2013. He also received the outstanding graduate student instructor award. During his time there, Robbie's writing on product management has been featured in Forbes, Fortune, AdWeek, USA Today, and on the front page of Reddit. He's also generously shared his knowledge by speaking at ProductLed, Mind The Product and Product School. And today he's here to share that knowledge with me on Brave UX. Robbie, welcome to the show.
Robbie Allan:
Great to be here Brendan.
Brendan Jarvis:
It's great to have you here. Robbie and I always like to start off as people know on a serious note and that serious note is that I understand that you learned to fly in recent years. And that's interesting because just the other week I was speaking to Benjamin Humphrey who's the CEO of Dovetail, and he told me a joke about pilots. Are you ready?
Robbie Allan:
I'm ready. What is this?
Brendan Jarvis:
How do you know someone's a pilot,
Robbie Allan:
Presumably because they tell you
Brendan Jarvis:
That is a hundred percent correct. And to be fair, you didn't tell me, but I did spot it on your Twitter bio. Why flying?
Robbie Allan:
So this was actually a client of ours at Carnival on Time took us flying and a lot of people that had thought flying was interesting. If you had to have a superpower, that would absolutely be my choice over invisibility or super strength or anything like that, [laugh]. And I was just blown away the experience of flying down Long Island over Jones Beach, super low in the middle of summer. It was so beautiful and we felt so free and I just didn't realize it was a thing that kind of normal people could do. I assumed it was either very expensive or very difficult or esoteric and mm-hmm [affirmative] like it's neither particularly cheap nor particularly easy. But as a skills acquisition thing, I really love learning new things. It's both a beautiful thing and to be able to do and unlocks a whole lot of stuff plus you, there's a lot of learning involved in it and I just find that intrinsically fun.
Brendan Jarvis:
And it's interesting looking at your background and actually knowing you personally, learning is definitely something that you value and you've spent a lot of time doing. I mentioned your MBA there at uc, Berkeley but I also remember that you graduated and went to work for McKinsey but you didn't stay in the consulting world. Instead you made your way to Silicon Valley and into product. Tell us about that.
Robbie Allan:
Yeah, I'd love to say it was a thoroughly studied decision but it's one of those things that makes a lot of sense in retrospect. But at the time I was just following my nose I really enjoyed management consulting. I liked the idea of working with large businesses on some of their hardest problems. I loved working with some really interesting and extremely smart colleagues but ultimately I didn't like constantly being an advisor. There's only so much you can do if you are from the outside and many times you'd see what we thought were great recommendations given to clients and they wouldn't kind implement them. And I figured I'd just rather be on the other side of the table. I'd rather be the person in the chair making those decisions. And so the kind of arc in my career has been just closer and close to actually being an operator.
And I found that really fulfilling product management itself was again a bit of luck. So it was actually a former McKinsey colleague who connected me with the other team at Zinger, didn't really know what product management was and didn't really think that a Facebook game would be the thing for me. So I actually worked on Farmville, which was that Facebook game that was super popular maybe five or six years ago with the Lonely Cow and they totally had hacked newsfeed and got a lot of the traffic from that. Just didn't see how that would be relevant to me. I wasn't interested in that. But what I was exposed to during my time there was just how digital products is this beautiful blend of creativity and solving customer problems. There was this real qualitative element to it but also you can measure everything that people do.
And so they're highly, highly analytical and it felt very similar in some ways to what I'd love most about the work at McKinsey, which was trying to understand a problem, get to the bottom of it. And it's not just a spreadsheet, it's also about the qualitative. Is this fun? Does this work? Does this make sense? Why are people doing this? Here's three items that are frequently purchased, but what's the common denominator among them? So really sort of similar problem solving thinking but with just much more data, so much more information, we could really rapidly understand so much about how our customers were behaving to get a better picture of them. And also the ability to iterates are rapidly. So at McKinsey you do a bunch of research over six or eight weeks, you come up with a strategy, you'd implement it over two years and then either the stock price went up or it didn't.
It was a very slow iteration cycle. Whereas at zinger you'd have some insight, you'd spend a day doing research, you'd put together a feature that maybe built in about a week or so, a couple weeks you'd ship it. And basically that morning, in many cases you'd know, hey, I'm onto something or I'm not. And if you weren't onto something, at least you'd understand where in the funnel people were falling off or have just a lot of information to kind of iterate. And so that whole idea of just come out with hypotheses and testing and learning that was all sort of fun about consulting was just large at a digital product company, whether that's B2B software, which is where I find myself now or a very large consumer game.
Brendan Jarvis:
You mentioned the analytical training that you had and the experiences at McKinsey and how you loved that side of that and you could bring that forward into the experience at Zinger, but there was more of an immediacy in seeing the results of the changes that you're able to affect and that sounds like that would be quite addictive. You also touched on the qualitative and quantitative aspects of informing design or product decisions there. When you first started at Zenga, what way did you lean, if any, between the sort of qualitative techniques and the quantitative techniques?
Robbie Allan:
Oh like 100% quant. I think that was definitely a gap, but zinger was very, very analytical and if you look at the company, it was very good at taking existing games and managing them very well, kind something that's already working and then really kind of optimizing that core loop. There's very few games they were able to start themselves and be very successful. And so in the core creative game design, I don't think Zzi was strong, but in terms of managing an existing thing by the numbers they were world class and probably still are. And so that was a great sort of introduction to that world, being able to lean on my analytical skills but at also made it very clear that there were certain item or there was this kind of element of creativity which was hard to see in numbers. So for example, certain virtual goods, if you had a bunch of items, whether it's this is sort of Farmville, so trees or sheep or dragons or whatever, certain ones would just sell more because just the art looked good.
There was this real inherent taste aspect to the whole thing. And over time you started to get good at understanding your customer and having a sense, you start to build this sort of intuition of I think this will sell well or this feels like this sort of other thing. And I think I've been really fascinated over the last few years about how you blend those things together because I think the quant and the qual are often seen as two different lenses. We're increasingly, I actually think they're just sort of the same thing. It's actually all information, it's all data about our customers and it just comes in different formats. And so the sort of distinction should one be Qualit, should one be I think is the wrong question at this point.
Brendan Jarvis:
[affirmative], yeah, there's definitely a need and a role for both. And in order to fully understand what that user experience is like and how to evolve it, I'm interested in speaking with you in more detail about quant and qu further on in the conversation. But before we do that and we move off zinger, I understand that your cla of fame there, you came up with virtual unicorns. Tell me about that.
Robbie Allan:
Yeah, the unicorns features. So that was really fun. We sold half a million dollars of imaginary virtual unicorns in a couple of weeks and the feature sounds super creative. There was the fire Pega corn and the Rainbow Pony, Pega corn and kinda unicorn and all this sort of stuff. A Pega is a other combination of a Pegasus and Unicorn, which I don't think I knew until I worked at Zer. but the clue isn't the title so it seems really fun, really whimsical. It's actually a microeconomics experiment at its core. So where that came from is, I was just idly curious about pricing elasticity at one point. So pricing elasticity basically is the trade off between when you change a price, what's the relative percentage change in kind of purchase volume relative percentage change in price because the way that you maximize revenue is you want those two things to be equal.
So intuitively it's like if something's really price sensitive, you can decrease the price just a little bit and maybe double sales, which obviously is a really good result. Or in some cases if our customers are pretty price andel elastic, you can increase maybe double the price and only 10% fewer people purchase it. And so overall you've kind of made more revenue. And so I was really curious about this at z and so was just trying to look at what is the price LSD look like for these sort of virtual goods. And what we saw is very high levels of price L elasticity at low prices. So that means as you go from a dollar to a dollar 10 to a dollar 20 for a virtual good, you see really significant drop off and the number of people that are buying it. But after about four or $5 extremely priced andel elastic.
And so same number of people roughly speaking would buy something for five bucks as would for 10 bucks. And so to cut to the chase the right answer there is to have a lot of really cheap items. So you'll sell a huge amount of them at a very low price and a number of very expensive items cause you know bleed a lot of people off increasing from $1 to $5. But if you're pricing at five, you might as well price it at 10 or 20 and at the time all the items were of priced in the middle at two or $3, which is the worst price basically. And so unicorns were essentially largely copy of the dragons feature, but just with a new set of pricing laid on top to really understand, hey, does this theory hold true If we price it cheaper and much higher, can we drive more revenue?
And I think we got about 30% a third more revenue out of a similar feature just by optimizing the price in that way. And so the of bringing the, while it was fundamentally a microeconomics experiment, there were actually some really fun kind of creative aspects because certain items what was one, the robot unicorn I think was priced really hard because the art was kind of weird and it didn't really sort resonate with customers, which you didn't sell that many of them. So there was some aspect in which the actual, just the art and the coolness of these items was this kind of noise that was put across the core economic experiment. They weren't quite the same things, but overall it was a pretty good pretty fun little experiment.
Brendan Jarvis:
And what was it, how did it feel when you realized that you were able to adjust the price and achieve, I think you mentioned 30% increase in sales or revenue? What was that moment?
Robbie Allan:
That's a good way to focus on it was to this day I still find this right when you actually get the data back and it works, I'm always a little bit amazed it have so many conversations about this and you draw the chart and ra ra, but there's just something about being able to take a chart or an insight or whatever and make a change and see that actually reflected in human behavior. This sort of incredible sense of, wow, I actually understand this and we can actually move the levers of this business. I still think it's a fairly intoxicating kind of experience. Even shipping features today
Brendan Jarvis:
[affirmative]. Yeah I can understand how that might be. There are a lot of smart people working in product and what you've just talked about clearly comes from your training and finance and economics and you've applied that to a very large scale game in this case in order to see what works. And and you mentioned that it was quite intoxicating but as I said when I first started the question, there's a lot of smart people working in product and that can often mean that there are a few egos at play. How do you manage an environment Ziga other product companies where you've been in, where there are a lot of well paid and highly intelligent people.
Robbie Allan:
So I think ego and product management is a really interesting one cause increasingly it's a role that's sort of smart, capable, ambitious people get attracted to. But it's also a role that has a lot of influence without authority. If you're an individual contributor PM you don't have a team you know need to have you engineering team, your designer, your researcher, your analyst. And even when I say your, it's not actually really yours in any sense, your partners you've gotta kind of believe and trust you don't have that kind of implicit stick of do this or you are fired. That kind of typifies a command and control structure for a traditional organization. These people can go to their bosses and say you're not doing a good job. And that's even more true with your kind of more cross-functional partners, marketing, sales, analytics, all that sort of stuff.
So it's a role in which I think it's easy to make mistakes And I know certainly early on in my career and this is typified of MBAs and consultants and stuff and I think I was no exception where I'd sort try and win people over through pure force of argument that doesn't make sense. Always appealing to rationality and in many cases coming down really quickly on people and meetings and it just didn't work very well. [affirmative], there's a whole set of skills of influencing that are really important to learn in product. And one of the ways I think about it now is actually this is something that our CEO at Intercom, Karen Peacock said a lot, if you wanna go far, go alone. No if you wanna go fast, go alone. But if you wanna go far, go together, which has gotta read this digestive feel to it. But I think getting the whole organization on board with something is extremely, it's really, really important. And if there's a choice between just do it yourself and slide it through, don't talk to the analytics team, do the analytics yourself, sneak in there.
Whatever happens is people don't just don't really believe the results and it's really hard to get support And so much of your role as a product manager is building understanding and consensus and sometimes the way to do that is do what you think is the wrong thing. Product management really is a influence without authority type role and that really takes them getting used to. So it's not your designer, it's not your engineering manager, your engineers, these people are your peers and certainly you play a leadership role on the team but it really is that sort of classic style of servant leadership where you need to earn the trust of people because you don't kind of carry that stick of do what I say or you'll get fired that ultimately underpins your sort of traditional chain of. And so it really requires a lot more leadership and a lot more humility and a lot more time and storytelling.
And I was really lucky at one point in my career to be taken aside by one of the leaders and who sat me down and said, look, you know you're smart, you're doing but you know, come across too forcefully and you're not really building the trust and support of people around you. And looking back at that time, I would really rely on, well this seems like the right thing to do and would really kind of push for that and would try and win every sort of single argument because it was sort of good for the company or right for the company or in some cases just right for me. And I think what I've learned and what I coach and the product managers that I worked with work with is that it's really, really important to build the trust and support of your engineering and design partners of UX, of analytics, of marketing, of sales, all those folks.
And what that means is you won't always do exactly what you think the sort of right answer is. I think a classic early product manager mistake to say, well this is my product and this reflects me and anything we do that I don't love is wrong. Ultimately it's a team exercise and it's your job to influence and build the team and that may mean doing things that you may not necessarily agree with all the time and you're far better to disagree and commit and learn quickly. And I know I can think of many instances when I shipped staff that I didn't necessarily sort, if I were solely in charge I don't think I would've done but it was really important cause someone on our team was passionate or partner was passionate or there was some sort of other reason that this was really important that we do that and sometimes it doesn't work as I expected and I didn't think it would work and it doesn't work.
So you know, don't quite get that I told you. But what we have done at that point is we've built the kind of understanding and support. I had looked at data and talked to customers and believed something was true but other people weren't happy with that evidence. And so it was important that to get everyone aligned, we go and build something. And other times I've been adamant something wouldn't work and it totally worked really well and I've been able to update my kind of view of the world and say, wow, I'm really, really pleased we did that because if it's just my call, we totally wouldn't have. And so yeah, I think bringing that sense of humility is really important. And I think to an understanding that a team that's highly aligned and shipping frequently, even if they ship the wrong things, maybe as much as half the time will actually learn very quickly. And I think what I've certainly seen is organizations that were sales and product and agree or kind marketing had a different view and were selling something different to what was being built you're much better being highly aligned and exploring a few different directions, learning quickly and course correcting then you are spending a huge amount of time trying to make sure that you make the right decision for everything that you ship. The idea of building shipping, learning is really, really important.
Brendan Jarvis:
So how do you give away what sounds like some of the control over what ships and what doesn't but still maintain is the product manager the overall direction that's gonna work for both the business and the user?
Robbie Allan:
Well I think as product manager you actually never control what's being shipped. You don't design it, you're not gonna build it. And so ultimately you need to convince other people to design the product and build the product. And so I think that the, that's the sort of fun fundamental misunderstanding. Just like, oh you know, are the CEO of the product, everyone has to do what you say that was never true to begin with. And so really it's like
Brendan Jarvis:
Where did that come from?
Robbie Allan:
I don't know exactly where it came from. And I think some aspects of it are really kind of important in the sense of thinking holistically about the product and being able to really take extreme ownership of everything that's happening and slot into places where you're needed. And in some sense that's kind of exactly what a CEO does. I think when we think CEO of the product, we think that kind of gross old version of large commodity control companies with the sort of private jets and executive bathrooms and everyone cowering in fear. Whereas I think you can think of modern CEOs that I've worked with, they really do the way that they work with their executives, they'll do things that maybe wouldn't be their call, but they absolutely support their executives and understand that they've gotta give them the freedom to run their organizations and they'll learn quickly if in fact they do things that maybe don't pan out. So I think it's sort rooted in the wrong idea of what a CEO does or how in fact really good CEOs do lead and then that just gets of transferred to product.
Brendan Jarvis:
What's a more helpful or contemporary way of looking at the role of product manager or a metaphor to think about what you can do to be effective in that role?
Robbie Allan:
I think it's that your, it's almost more like I wish I had had a nice off the shelf metaphor. The thing I think about is when you're organizing a group of your friends to go on holiday, that's kind of the metaphor. You have a sense of it'd be fun to go somewhere beachy on a holiday over the Easter break or over New Year's day or something and you've got some kind of a vision. And so it's really helpful and really important to have a vision of, hey, I'm thinking we'll be like, it'll pretty chill. We might have a couple of nights of partying, but mostly it's gonna be really relaxing and restorative [affirmative] and we're gonna get a house that we sort optimize for location to the beach and maybe it's not quite as nice or it's a bit smaller. There's some sort of a vision that you're pitching to people which can really help to align someone, kind of align everyone and not have these very divergent like, ah, let's go and have a crazy party trip.
Or oh I wanna go and get work done or oh let's go with the kids or whatever it is. It's important to have some sort of vision but ultimately these people have to choose to go with you and you know are gonna have things that's not quite what you would expected or something like that. But ultimately your job is to facilitate these group of people, this group of people to a decision and you can have some influence but ultimately everyone's gotta sit down and say, yes, we agree with this and this is what we want to do. And you're there in service of the larger group. You can make suggestions and pitches but ultimately if they wanna do it or don't wanna do it, it's up to them. So I think that kind of model where you have to really lead through inspiration and vision and hey, here's how I'm thinking about things and here's why I think it might make sense for us to organize events in this way. Or I think cards would be fun for this reason or whatever it is. And also realizing that you're always gonna be right, your perfect, our taste vision is not gonna be realized and ultimately the goal is a holiday that everyone enjoyed and not the realization of your perfect vision.
Brendan Jarvis:
It sounds like a very difficult role in the sense that you don't have a lot of control you've gotta bring people along as you said for the journey, make it feel like they've decided to do things and in reality they probably will have decided to do a bunch of stuff on the product, but you ultimately don't control them. How does that play out in terms of your wellbeing as someone who's been in a senior product management role or roles before? How do you look after yourself and make sure that you're able to articulate that vision and bring the energy that you need to in order to bring the product and the team to greater success?
Robbie Allan:
I think it is a great way to frame it. Energy from a PM is really important and I've often seen this from just the day to day of the scrum team coming in, being excited and being able to remind the team that okay, we're not just making bricks, we're contributing to building a cathedral here. And I think that I'm definitely down that chain of have, I have a meditation practice and I know that if I can get out and exercise at least four days a week, I'm kind of much better and much happier. And also that I think also there was a realization for me that a little bit like we talked about previously, I don't actually control everything and so when I put on myself I have to make these people do this thing, I certainly found that very stressful versus reframing of that that I've taken recently is look, I'm gonna show up and really just do my best and I'm gonna kind of help nudge people and in the right direction as much as possible and as long as we go broadly in the right direction and we may do some things that I didn't agree with or kind boss I'm, I'm gonna be able to get my boss on board or something that's actually really, really important.
Okay. As long as we're just, we're continually learning and as long as we're aligning and as long as we're moving forward that's actually progress. Not this kind of, this product is my baby and represents myself and I need to actualize myself through it. That's the stuff that gets you in trouble I think. So it's a combination of just the basic of knowing the stuff that sort of helps you and also I think framing what it is that you're doing as yeah this, you're in the middle of the way the sausage gets made and it's a bunch of trade offs. And as a New Zealand politician that talked about politics as the art of the possible and I think it's the same thing for organizations. I've certainly had things that I've pitched for many months and won no support and you then slowly got maybe a little proof of concept and then eventually these things were built out into whole product lines in some cases. But it just took a lot of slowly persuading, convincing and just being willing to offer this idea and continually refine how I pitch this because ultimately if someone doesn't understand something that's on me as the communicator it's not for me to say, well they're dumb or why don't they get it? That's not helpful if I want to understand something that's on me to find new ways to that.
Brendan Jarvis:
Yeah, that's actually a really insightful point and it's something that if you're listening to this episode, you should really take away. I think you get a lot of value out of applying that into your own life if you're not already. Now Robbie, you've worked at a several large well known product organizations, you mentioned Zenga, I mentioned in your introduction Survey Monkey and Intercom, you also have worked in New Zealand and in the US since you've seen a bunch of different cultures and ways of doing things. Thinking about those experiences, what does a world class product organization look like?
Robbie Allan:
That's a great question. I think what are the characteristics of a world craft product organization? I think highly aligned is certainly one characteristic. So I've worked at organizations where there was a very much decentralized, you know, own this piece of the product, you figure out the strategy and people would be going in a million different sort of directions and optimizing for their own metrics. I think really good product leadership stand sort of steps up and really good company leadership will have quite a clear strategy and not a strategy in the sense of our strategy is to grow margins, but a really sense, a real story. I think of strategy as a term that can be thrown around a lot but ultimately it's a story about how you're gonna achieve what it is you think you're gonna do, right? Amazon strategy being to have a really wide range of items available and make them get to customers really quickly.
And so just have really great customer experiences throughout and always take the view that hey, if the customer's upset, that's their fault for not messaging it correctly or not setting expectations or whatever else. And that was, that's the qualitative story. Now there's other ways you could have done that. You could have had a one on one concierge kind of system or hey we're gonna create great margins by selling lots of items at really high prices through because they're hard to find items. There's tons of different stories you can imagine, but that was nuclear and I think as a company you wanna make sure your company has that and certainly a product organization needs to have that of how is it that we are gonna create value, what do we do for customers? Truly compared to that I think is an understanding at the level of the job that you do.
And so not we build an SMS system but we help direct consumer retailers to communicate with their customers. That's the job that we're doing and we're agnostic about whether it's SMS or it's push notifications or it's email or carrier pigeon or whatever. But if you understand the job then you're able to understand different pots around the problem and what you really compete with that job. Understanding I found is a really, really, really rich one for organizations to have. And it's really important that a world class product team has a sense of what problem they're solving for customers and what the job they're doing is I think a real focus on problems. I know we've sort of chatted about this before but focusing on the customer problem, what is it that someone's trying to do? What's the progress they're trying to make in their lives Rather than being feature focused, we need to build notifications.
Ultimately, I think one of the biggest sources of value you can create as a PM is just really clearly defining the problem that you wanna work on and being able to identify that requires an understanding of your customer a really deep understanding of your customer and likely requires more research. So a kind of real problem focus I think is extremely important. Really strong connections with stakeholders and so a sense of the product is being really attached to the rest of the organization. Often you'll hear product throwing stuff over the wall to sales or maybe they're the kind of pale that is just constantly trying to organize sales requests together into one place, a really good understanding in a partnership. And that's where the company strategy comes in to make sure that marketing's selling what product's building and same thing with sales and everyone's aligned about hey these are the customers we're really going after and these are the ones we're sort of going after opportunistically.
What else? I think a clear and really well understood process. And so I think having, and this ultimately helps for alignment within that triad of product design and engineering to say that probably needs to step up and say these are the ways, the stages that each project is gonna go through. And I think being quite prescriptive about the stage but quite open about the form that it takes. And so this is less a series of templates to be filled out or spreadsheets or forms and much more like hey this is the so maybe validation every time we define a problem we take some validation step and that could be look at a couple support tickets, it could be three months of formative research and the form can really chAllange but each step qualitatively you, you've kind of undertaken that step of validating that the problem exists.
Brendan Jarvis:
[affirmative],
Robbie Allan:
Those are things that are top of mind right now but I'm sure there's much more as well that would characterize a world class product org.
Brendan Jarvis:
And those are some great things I think if people are looking for their next role in product to consider when they're interviewing and to ask about and try and get a sense of as they move into their next role.
Robbie Allan:
Maybe actually one thing, sorry Brendan, just to add in here actually as well, I'm just thinking about what are the things which can go wrong and you know should look out for ultimately it's a focus on results products about making something people want and so a good product is one that people use, they use a lot and that grows. And so I think that your product org has to have a real focus on top level results and not just like, hey we shipped a lot of features not just focused on output but it's gotta be, hey look we solve these problems for these customers and that drove revenue for our organization. I think really great product organizations have a clear focus on that as well.
Brendan Jarvis:
Yeah, it sounds like that's a mindset and it also plays out from the way that you've described that and the language people use to talk about and describe what it is that they do.
Robbie Allan:
I think that's fair.
Brendan Jarvis:
Robbie, you also yeah mentioned in what you were just describing there that there are often problems in product and that lends to this notion of prioritization and the product manager seems to be the role where that responsibility falls on the most. I've heard you speak about this idea that in product that everything is on fire so it really becomes a question of what fire to let burn. In your experience, how have you approached that decision of what fires to let burn and what ones to try and put out?
Robbie Allan:
I mean I think this comes back to just a really good understanding of your customer and a really clear strategy. And so the fires that you can't let burn are those things that your customers come to you for because if you're a new product, likely there's lots of features that you don't have. And the whole way that products get started is because they're so much better in one area and they solve something that's such a pressing problem, their customers are willing to give up everything else. They're not sort worried about the other things that you don't do cause you do that one or two things really well. And generally it's the case that in products only a couple of things that you do that make the difference. There's lots of things that help or they sort of me too but don't really make a large difference.
And so I think the core of prioritization is a really clear understanding of what actually matters here. Does the beauty of and how visually arresting the site is, does that matter and what parts or is it like look we can get a B there. Obviously it's got bar but we don't get extra points but winning does sight speed, does it really really matter or is some just gotta be not bad on some products, site speed, super important. Others it's like yeah it shouldn't be super laggy but you're not gonna win by sitting on those dimensions. And so if you've got a really good understanding of those things then I think the prioritization starts to become a little bit simpler. And [affirmative] to our discussion. Earlier you mentioned that the PMs often responsible for prioritizing program managers don't like it's not a thing you go and train for.
And so program managers don't inherently have any more skill at this necessarily or insight than anyone else does. And so I'd almost think of them more as the chairman of the board or they're just the sort of chair of this meeting. They could include a pretty wide range of stakeholders, all of whom need to be bought into the way the prioritization happens. And so if PMs find themselves sort of putting their business card on the table and going, well we're gonna do X because I'm the PM and I say that it's my job to decide that I'm a little bit if you know hear design saying, well I want it to be purple because I'm the designer and I get to choose that something's gone pretty wrong. Really what PMM should be doing is working with all these different stakeholders and ideally everyone should agree or at least pretty much understand. They may not completely agree but broadly they can get behind, I understand what we're prioritizing and why. And I think also being willing to hold it lightly because what's really important is I think is the sort of top two or three things that you're focused on that you need to get and focusing on those.
And it's really important that you do those three things and that you don't do something that's not on that list. But within that list should that something be the second priority or the first priority, I don't think anyone really knows. And so being willing to hold that lightly and go, what this is an important thing, I think we should do it but sales really already want it right now. And so we're gonna bring that up the roadmap a little bit to make them happy and build good will. That's exactly what PM should be doing. And that's really a really positive step or design's really passionate about this and I've kinda had a bit of a tough quarter and we'll sort of bump this project up sort reorganizing within that circle of things that all of which are probably pretty good to do is totally fine.
But the job really is making sure that stuff doesn't creep on that actually isn't important or isn't gonna take us in the direction and build the product that we want to and help you better solve the customer problems that we decide that we're going after. So yeah, that's hard to think about prioritization, I think it's more about the story more than it is. I'm actually a big whatever the opposite of a proponent is of these kind of impact and confidence and weight, short job first prioritization frameworks. Cause what you always find is that the sort of potential impact of a feature, you're always just guessing it or making up. And so this is rated as a seven versus a six.
That's a very sort squishy step in that whole process [affirmative]. And so qualitatively having an area in which hey it's really important people are gonna choose our product cause it's the fastest. And so this project may or may not work, but ultimately it's working towards side speed. And so we know if we do enough of these we'll be doing good things versus doing a redesign of the site, which looking into the day doesn't how the site is. If it's not quick, we like we're and people will still it, it's so that understanding is more important. Some sort of,
Brendan Jarvis:
That makes a lot of sense. So you really have to know what those things are that are gonna make the products successful. Those core things are hold those front of mind and also be comfortable. You've mentioned this a couple of times now and this sort of notion of trade off, be comfortable with trading things off sometimes for softer reasons. The good of the team as opposed to what you may want as the product manager.
Robbie Allan:
And I think the key point part there is trading off within the kind of circle of acceptable. So there's 50 ideas and all of them are probably good on some level, but there's five that are really important within that five. The order can be kind of whatever but it's really important that you know, don't go doing other stuff within that. Got it. So realize that often locally, a few equally important things and you probably won't know the answer anyway and so let's just sort of try come to some agreement around that. But it's super important that you don't get distracted.
Brendan Jarvis:
You just can't know. That's something that people are generally not that comfortable with, so sometimes you just have to try. Yeah. Robbie, you're a bit of an expert on product management for onboarding experiences. That's been a large part of your role at Intercom. You've written a lot about this and given several talks about this as well, just for the people listening in case there's any ambiguity about this, what is product onboarding?
Robbie Allan:
So product onboarding I think of is taking someone that's come to your website and it's clicked try there. Especially in my world, b2b SAS probably got some sort of a problem that your product can solve cause it would be a pretty twist is the wrong word, but it would be unusual for someone to just be trying out software as a service. Products that are aimed at business is just for fun. Generally if they walk on the lot, they have a problem that you can solve. And so taking that person all the way from someone who's interested in the promises of your website to someone that's actually experiencing the value of the product on your website. And so that's someone that's fully using your product to the best of its abilities for the problems that customer has. So it's not just of that a sub-component is the first use experience, which is maybe the first one or two sessions but I think of onboarding as taking someone from the promises of the website to really getting the most they can for the problems they have out of your product.
Brendan Jarvis:
And there are thousands if not more products, particularly in b2b, SAS out there at the moment, what separates those that have a great onboarding experience from ones that have an average one.
Robbie Allan:
So I think the secret to a really good onboarding experience is just understanding what customers want at that point. And in many cases it's about helping the customer either experience the value of the product really quickly or it's about helping them understand what that might be. And so the difference there is that for consumer products like Pinterest or Facebook rather than telling people a lot about how it can help, the best way to experience Facebook is just sort sign up at a few people and you'll get it pretty quickly. Stuffle sharp in your news feed, you'll get messages, you'll understand the value and you'll kind of know if it's for you or not. You'll get that magic moment of interacting with friends. One of the unique things about B2B products is that they're often pretty complicated. And so there may be a large sort of setup process or some quite complicated installation process.
I like to think of the Airbnb host experience as a really good kind of relatable example of this. So if you wanted to host your space on Airbnb, there's actually a lot you've gotta do. It's not like we can go, oh cool, it's just we'll get someone in to sleep in your house tonight, that'll be cool. Well we can't do that. It's not possible. And so what a really good Airbnb host onboarding has to have is be able to help someone understand and make it really real. Here's the benefit. Or help them see how they could realize that benefit of monetizing an empty space in their house and help them see how they could overcome all those kind of fears and things that are holding them back like, well, is it gonna be safe? And what do I get to vet who comes through this process?
All that. And so a really good first use experience for Airbnb host would help someone really quickly understand, here's much money you could make with your space and here's how easy it's gonna be to manage it and whatever other kind of the top five questions someone has when they click that button, like a good onboarding experience there, it's gonna really ask, kind of convince someone that this experience will actually do what it promises. And so therefore they're willing to do all the work of wrangling with a calendar and writing a blurb and uploading the photos and having a back and forth chat with randoms. It's about building that kind of conviction which usually is about helping show the product in really specific ways and make it real for those people.
Brendan Jarvis:
So that makes a lot of sense. You've spoken about, and we read a lot about and product, this notion that it's important to understand what the customer is trying to achieve, what their problems are, and it's really important to do that during the onboarding experience in order to deliver value during that critical moment. But let's get really practical. How as the product manager do you go about trying to understand what those problems are? How do you frame this? How do you put it in terms that's meaningful and actionable for the team in order to try things out and deliver on that?
Robbie Allan:
Yeah, that's a great question. So I think the first thing to understand is that the new user experience and the problems we solve for a new user may be quite different to the actual core problem that's being solved. So if we go back to the Airbnb experience, the job to be done there is probably when I've got a spare space in the house, I want to easily and safely make money outta that space and that's probably the job to be done, or I wanna supplement my income, something like that [affirmative]. Whereas by contrast, when you are shopping for something like Airbnb, maybe a range of other sort of questions you might have where it's like, oh I need to delegate with my partner that it's okay that we do this. And so I have to essentially pitch to them and get their agreement to do this.
And I want to know what happens if something goes wrong. And there's always concerns and fears and anxieties and things like that. And the first thing is that the needs of a first time user are often quite different and unique to someone that's already using the product. And so it may just not be explaining what it does when you are using it day to day, but there may be a range of set up specific kind needs. And the classic one for b2b, and this being often if you're thinking about adopting a new product product, someone may investigate it and they'll sort pitch it to maybe a decision committee who then make a decision, then negotiate a contract and only you then go and implement the product. And so your onboarding needs to help people get through that decision making process. Here's a little calculator to help you understand how much value you could get with this product, or here's how it would look on your website or whatever. It would be stuff that isn't sort necessarily just about, let's set up our product right now and get going. That actually is helping with the problems in that actual buying process really.
Brendan Jarvis:
So how do you frame those problems? So how do you go about defining those? I suppose it's somewhat easy to look at an existing product and kind of tease those out, but when you're in the trenches building the product, you actually get from what they are assumed to be to actually what they are and iterate on top of those.
Robbie Allan:
So it's really critical not to guess at this point. And talking to customers is absolutely critical here. Mm-hmm. [affirmative], the process I really like for this is the switch script interview, which is I think well characterized by Bob Moister and the rewired group who are some of the early proponents of jobs to be done. And what a switch script interview will do is it kind of takes a customer often someone that's sort newly signed up and will really dig deeply into, well, when did you first think about finding a solution to this? And then what did you do? How did you go about casting around particular alternatives? And what was the progress in your life that you were trying to make? This idea that people don't wanna drill, they want poles in their wall or whatever it is, and that the drill is a thing, they may choose to solve that particular problem.
But really getting into the nitty gritty of that process. And if you think about the B2B buying process, it might be, well actually often, usually there's some sort of failure within the company or some big event, someone missed a quarter and they're like, Hey, we've already gotta improve here. And then that set in motion some sort of process. And so understanding that helps you rely on your marketing, helps align on your product, all these sorts of things when you understand what is that someone comes to you for and what's the progress they're looking to make, what's the job to be done [affirmative] when they're buying? And also what are the various steps? Who are all the different people involved in the process and what information do they want at each stage? Cause I think that's a classic mistake of many kind of complex product lead companies will be like when you click that start trial button or something like that, they'll have you set up the actual product.
And in many cases what people want is something more akin to a demo than actually setting up the product. I mean, I guess in some ways a trial always is a demo. It's just that someone setting up the product themselves may not be the most effective way to demo at that point. It may be that they want sort a slightly more detailed explanation or something they can play with a little bit more than the marketing side, but they don't actually want to necessarily get started. And I think that's what, if you look at a lot of onboarding flows, it's almost like that team is assuming that the person has already made a purchase decision. And so they'll often have lots of API keys to install, which is hard, difficult work that doesn't actually prove value upfront. And that's really the wrong way to think about it. When someone, modern companies are all about a light marketing site. They're trying to get you into the product as soon as possible. And what that means is that person hasn't decided to buy at that point. They're just a prospect, they're interested. And so your goal is to really, really easily and quickly help make the progress that your product could help that person make in their lives feel as real as possible with as little work as possible. And only
Brendan Jarvis:
Now there's a great takeaway. There is a great takeaway for people listening. That's a huge point.
Robbie Allan:
I think that's a really big one. And I think of all the things in onboarding, really trying to help make that progress real and can an easy audit for yourself is at every stage, does this make me more confident that your product will do the thing that was on your marketing website? And if it doesn't, like do you really need that step? Because early on people haven't invested a whole lot. Maybe the first page is create an account. Why do you really need to create an account? Could we not do this stuff logged out? And it doesn't need to be a lot. It could be three or four tasks to help you make some decisions about how you might configure this thing and help you get your mindset in the fact that, oh, this product could really help me, this is what I want. And maybe then it's like, Hey, do you wanna save your progress? Let's create an account. And so you can come back to this, or maybe you can show it to someone else if you know there's not person involved in the buying process. But just really thinking hard about how would I show someone that this is gonna work for them with as little effort as possible on their part In the early days. It certainly should be doing that for the first of five minutes. The experience, let's say.
Brendan Jarvis:
Yeah, I mean, this sounds like you need to have a really strong qualitative and rich insight into what the jobs to be done are of the customer or the users that you're trying to onboard. But how do you quantify once you've understood that or you believe you've understood that and you put it out there into the product, how do you quantify whether or not you've been successful in those assumptions that you're now testing?
Robbie Allan:
Yeah, I mean ultimately it's like is it driving more revenue? If you're a commercial product, it's fundamentally the bottom line. Sometimes you be working on intermediate steps to that. So if you're doing something that involves churn or retention, that's almost impossible to measure that. It's just very, very hard. And you're looking for very small changes. And so [affirmative], the way I think about that is basically working through that kind of backwards through that chain of logic, which is to say, if we were trying to onboarding, if we're trying to onboard someone, we're in the process, will we focus? Maybe it was getting more people who had met definition of activate or activated to then convert. And so that's the little number you'd be looking at. Or maybe it's what you're trying to do is get more people activated. And so you're focused on that when you're evaluating the stuff.
It's really important to make sure that the problem that you're solving is pretty well tied to your metrics that you're measuring. So for example, let's say you're working on the first use experience and what you found is that there was certain people in the, I don't know e-commerce industry, really struggled to see how your product could be relevant to them A bad way to measure that. And your goal was of activation. Those people were just bouncing, they weren't even kind of activating. Mm-hmm. [affirmative] a bad way to measure that would say, did the overall activation rate go up? The reason that's bad is lots of things that could affect the activation rate and who you were targeting was really specifically eCommerce companies. And so what you want to do is of look at, okay, if we had some new feature that explained things better for eCommerce companies, did we see a change in activation rate for those eCommerce companies?
It's really important to drill into that level of detail so you don't get lost in of random fluctuations or anything like that. And that can apply to maybe you're trying to work on one specific step, getting people that have installed your product to, or they've used it once to use it multiple times, really wanna focus on who is that kind of targeted group, rather than relying on these high level numbers and anything with the largest products, global Facebook scale that can be very, very hard to get significant results on these measures. And so really trying to look at, hone in on your target group and say, can we move things for those for them?
Brendan Jarvis:
So you really have to tightly define who that is and tightly define the experiment in order to get any sort of validity out of the metrics that may result.
Robbie Allan:
Yeah. And that's where focusing on the customer problem becomes important. We've talked so much about the job to be done and what do people want in the step and having a clear hypothesis. But on the ground a lot of these things will look like we're gonna redo the nav because the NAB's confusing on our marketing side and that'll have impact. And that could be the right answer. But really what you want do is have an understanding, ah is a particular sort of customer that finds these two buttons kind of confusing or they're looking for case studies but we call them resources and they don't understand that case studies go into resources and so we're gonna rename resources, case studies, I dunno what but then
Brendan Jarvis:
This is classic Steve Crew. Steve Crew talks about when you identify a usability issue, you should be thinking about what's the smallest possible thing we can do to resolve that issue rather than redesign.
Robbie Allan:
Yeah. Oh absolutely. A thousand percent a redesign should be the sort of thing of last resort. But more generally projects that are just redesign sort in specific. Cause what you actually wanna start with is here are the problems that we want to solve. And really it's only when you get to design should you come to the conclusion and it should be pretty easy to agree, Hey we actually can't solve this with our existing design. We do need to abstract up and solve it at a higher level. And at that point there should be no arguments about the redesign. It's when you're sort pitching our marking site's just super broken. What's broken about it? What are people trying to find and what can't they find? Because
Brendan Jarvis:
Be spec specific.
Robbie Allan:
Yeah, because the specificity actually allows you to then evaluate the success of it and it's when you say, oh we're gonna build better onboard or make it shorter or something like that. That's sort of a vague solution without any real clear problem. Who's it for? What's the progress that we're trying to make and what's the problem with the status quo? If you've got those parts then it's quite easy to, or in many cases it's much easier to define metrics for how you would see Yes. These of people are, maybe it's visitors from visitors from Quora tended to have this problem and so you can look at all your traffic being referred from Quora and say like, Hey, are they actually able to get to case studies at a much higher rate than they were previously? I dunno what this is, but it's like if you actually understand the kind of qualitative specifics then kind of designing metrics that would quite easily allow you to see this stuff is much easier. Rather than saying, well we're gonna redesign the and try and see an increase iny conversion, it just doesn't happen. It's just so hard to measure that.
Brendan Jarvis:
This sounds a lot, it's aeration as opposed to innovation. Is there a role at all for innovation in something like onboarding?
Robbie Allan:
Look, absolutely. I think the way to think about it there's a great blog post by Scott Beski who I think was the chief product officer at Adobe called the first mile of product that talks a lot about these kind of pieces that I highly recommend to your watches or listeners or whatever they might be. But a really good frame from Scott was the idea that familiarity helps adoption and innovation is really great at doing things in a new and different way. And so if you wanna make people adopt something, make it familiar. And so I think in that sense what onboarding should do is bridge your new world and what people know. So it absolutely has to start at the frames of reference and terms that the general population or whoever it is that's coming to your product, understand and help them rather than using the sort of terms and definitions that is unique to your product.
As an example, at Intercom we call the way that Salesforce and Intercom interact and an app, an application. Now most people think about that as an integration. Integration is the word that kind. Do you have a HubSpot integration? Do you whatever, [affirmative] and so on. In onboarding we have this whole a debate about, well should we call them apps? Cause they actually helps build a better mental model for how our product works or should we call 'em integrations? And essentially the question we asked ourselves was, is it important when someone's starting out with Intercom and is just really trying to get a sense of will this give me value? Does explain to them that we're actually, in fact what you thinks an integration we call an app, our terms and definitions is not an important thing to land. We can land that further down the track once they've signed the deal, they've had the trial, we can go, oh actually if you're using this, by the way, integrations live in this kind of apps thing. But I'd much rather have someone understand and be able to use our product rather than and be a little bit confused about where to find integrations later on. That's a problem I'd much rather have than someone not become a customer
Brendan Jarvis:
That's kind catching and catching that ego of the wider organization before it's met loose on of the general public.
Robbie Allan:
Yeah, a thousand percent. It's really about meeting people where they are and also remembering that and this is true of products in general I think innovation for its own sake is probably not helpful in general. Ideally a great product of works and is familiar to people and works in all the same ways that they're sort used to but because it's new it it's gotta in some way be different. And so if mm-hmm [affirmative] completely different, if the Mac computer had a devoid keyboard, that layout that's supposed to be more efficient or whatever it wouldn't have taken off. I'm off because it's just one more thing that makes it hard to adopt. They don't wanna learn to reuse a keyboard, that kind of thing. Even though technically it might be a better product if you go back and say what is it that makes a Mac different? Typing speed is not it. It's not central to that value prop and so they haven't done it. And so I think in general, whether it's onboarding or your product in general those core things that you do different and that you do better make them different if you can be, and then make everything else as standard and familiar as you possibly can because it just reduces the amount of barriers to new people understanding your product use standard ui, like don't innovate and that kind of stuff unless you have to for some reason.
Yeah,
Brendan Jarvis:
Google doesn't muck around very often with how they present the core results and for a reason I was just doing an evaluation of a website recently and search was part of that, the search feature and the design team had done something quite different to what people are used to and one user just didn't even realize that what they were seeing was the results that had been returned from their search input. Wow. I mean that to most people you might think that's crazy, but for this person it was real. They had to really think about it and then eventually they got it but it was just unnecessary friction. Something else that you've spoke about Robbie that I thought was really interesting when I was preparing for today's talk was that there's this notion that there are jobs that are outside of the core job of the product that your users are trying to achieve and that if you pay attention to those you can unlock a lot of mutual value. And this is in the context of onboarding. Can you tell me about that?
Robbie Allan:
Yes. The idea of jobs that are not central to your product is the fact that a lot of products will describe them or if you actually look at the way that people use products, most products are actually a pretty limited sort of solution to the problem and there'll be one tiny piece of workflow. So you think a Survey Monkey, which is a pretty fully featured survey product, it's actually a pretty small part of the actual process of gaining insight over something. So let's say you wanted to send a survey to someone or you know wanted to understand something about your customers and you decided that a survey was the option there you've gotta figure out, you gotta figure out who to send it to. You've gotta figure out who's gonna use those results. You've gotta figure out what information you wanna learn from those people.
You've gotta figure out which questions you should ask in order to get those results. You've gotta figure out who to send it to. You've gotta get the email addresses, so any of that stuff, it will allow you to, yes, you can build questions and you can send it to people and they will collect the results and we'll put them in charts for you. But even then from the charts often that goes then you've gotta kind of take the input, you gotta synthesize it, make sense of it, you gotta distribute it and share it with people. There's all the sort of staff that's adjacent to it. You've gotta remind people to take the survey that haven't responded quite yet. This is all the staff that will actually be part of the sort of regular workflow which your product often today doesn't really sort solve. And so thinking about as you're trying to move people to adopt it helping people do that is often really important.
So templates a really common kind of answer to this sort of problem. Typically most things allow to do something which products allow to do something, but you've gotta put something, there'll be some kind of enter some text or create something and send it to someone type thing. And so helping giving people ideas of like, well here's what you might want to write and here's who you might like to send it to you. And by the way, here's where you can get that information from. As a super practical example Intercom where I work, if people aren't familiar with it, it's a, most people know it as that little chat bubble in the bottom right corner of websites on the internet. And really we view that as a way to, for businesses to talk to their customers for sales, marketing support all the ways you can talk to your customers.
One of the things that'll happen is like how does your customer's information wind up in there? Because from the very start we've had this kind of chat bubble which exists as a JavaScript snippet on your website that most people don't install it at the very beginning of their business. And so people were having some existing customers who aren't in Intercom and the only way to get those people in was to sort somehow force them to visit your website and then capture information and you could message them. And so one of the best things we ever did for onboarding was provide a CSV upload button where you could upload a list of existing kinda users and we deju it against people that we've already seen. And so you could actually have a comprehensive user list. This is an example, something that's sort of outside the product and it's easy to overlook and think, well we need this feature or that feature, but in actual fact, which is this really basic problem is we say we're one place to see users but our customers couldn't get all the users into Intercom. And so that's an example of the sort of thing that's about understanding what's outside the product and how do we help people overcome those gaps, which can seem pretty pedestrian but often really, really important to overcome.
Brendan Jarvis:
And that's not something that I get the sense that your product analytics would tell you.
Robbie Allan:
Well no, I mean this is the thing, this goes back to our discussion. So product analytics tell you what people do and they're really good at that. It doesn't tell you why people do a particular thing and both those things are really important. Just knowing that there's some people that want to do a certain thing or these jobs to be done, it's kind of helpful but you may not know how many people have that particular job or whatever else. Or even equally interviewing people and trying to understand which part of the product they got stuck on may not be particularly reliable. Analytics are really good at telling you who's seen what screen but they just really won't tell you why they didn't go any further or what happened at that point or what was confusing to them about that screen.
Brendan Jarvis:
Well what they're doing in other products and trying to make exactly make whatever they're trying to do work on your product, it's outside of the bounds of that analytics
Robbie Allan:
Completely. And if you're just looking at product analytics, you often end up in guessing land, you'll get in a room and go like, well why might people not be completing this form? And the answer's always just change something in the product. Let's redesign the page and it's like, I don't know, redesign the page. It's sort throwing all the Lego bricks up and just putting 'em in a different place. How do you redesign it? I don't know, just even thing that's not what it is right now would be a redesign and they're like may or may not work, you just happen to on the thing that was confusing. Whereas if actually go and talk to customers and they go, people were really confused because they wanted to select a certain thing in this dropdown and they couldn't find it or people couldn't find this button or whatever it is. If you have really specific feedback for what should this redesign achieve today, what happens is people conflate these two ideas and a really successful redesign would help people see this and that these things are two separate ideas and the points they miss or they understand they're missing is abc. That again backs the real specificity of what is that people find is confusing versus let's remove friction. What is friction for, let's get very specific and not just imagine it, but talk to customers, understand to them what was hard here
Brendan Jarvis:
Robbie, this all sounds like a lot of hard work,
Robbie Allan:
[laugh], I mean
Brendan Jarvis:
It's so much easier just to jump to conclusions and do things right and learn in production. How do you help people to operate and adopt this mindset?
Robbie Allan:
Yeah, I mean it, it's actually much harder to work, harder work to learn in product because you've actually gotta put fingers on keyboards and build something and people use it and then it's like, oh, no one uses it. It's a super expensive way to learn versus actually talking to your customers and saying, well, to use our onboarding example, talking to a few of them and saying, well if I explain X, Y, and Z, does that help you? Like, oh yeah, great, I'm ready to move to the next step. Okay, cool. You now have really high confidence that if you built the product thing or the screens that did whatever I just explained then that will work. Versus going, oh, people don't move from screen A to screen B. Let's imagine what could the problem be? Whiteboard bunch of ideas. That sounds fun. Build a thing, ship it. Oh it hasn't. We've moved people one screen further but now they drop off at the next screen. We haven't achieved much at all. And so that's why talking to customers is can be a pain, but it's the cheapest way to learn rather than actually building stuff.
If you're trying to find out what problem to solve, you have to talk to your customers. If you want to evaluate whether the solution works, then you've gotta either design it or build it. And so it's important to figure out are we trying to do we know, do know why people aren't activating or why they're churning? And if we don't do that, you've gotta talk to people. If we know that and we are just trying to say, well how do we integrate with Salesforce so that large customers don't churn and you've talked to them to understand what they want out of Salesforce integration or what is they're trying to achieve then at some point you have to build that thing to understand does it actually do what I thought it would? But that's sort of further on the track and you already should be had a fair amount of confidence that this problem is worth solving.
Brendan Jarvis:
It reminds me of my chat a couple of weeks ago with Marty Kagan and he told me this story about Mark Andreen when he was working for him at Netscape [affirmative] and he considers Mark Andreen to be one of the, well, the smartest person he's ever worked for. And he said that the penny dropped for him when Mark said to him, you've got to know in product what you can't know. And I think that is exactly what you've just described there and you've got to decide what to do when you realize that you don't know something and how to respond. Yes. Now Robbie, I'm just mindful of time. I would love to have spoken to you today about growth and measuring growth, but instead are you up for a few scenario based questions out there that may be useful for people in product that are experiencing a relevant situation?
Robbie Allan:
Let's do it.
Brendan Jarvis:
All right, excellent. The first scenario is you're arising star in your company and this has given you a sense of self-confidence and some quite strong opinions. Others don't always share your opinion and you've noticed that you've start to started to experience difficulty achieving the outcomes that you want. What do you do?
Robbie Allan:
That's a really good one. That's a very real one. I think the trick there is just spending some time on relationship. So really diagnose why you aren't achieving those outcomes. And most likely if it's products, cause you're not getting people to buy into your ideas or come along with that. And if you're fairly convinced that you have the sort of right answer and you've done the work, it's probably about the non-doing work stuff and it's actually much more about the relationship you have with people. And so I think a few casual coffees seeing how you can help others of understanding where they're coming from. Most likely if you're in this place you'll find, oh, I actually haven't spoken to many people without asking them for something for quite a while. And so I think I'd be really trying to think about the relationship and of understand where people were like, did they truly believe in the stuff that I was doing and how could I help them with what they were concerned about, I think would be probably pretty important.
Brendan Jarvis:
That makes a lot of sense and does sound pretty important. You ready for another?
Robbie Allan:
Yeah.
Brendan Jarvis:
All right, number two, here we go. You've just been promoted to look after onboarding for your company's flagship product. You're a competent product manager, but it's your first time working in this area. What do you need to do or understand before you change anything?
Robbie Allan:
What'll happen here? I've been through this and I've seen this a few times the sort of theoretical answer is you need to understand your customers better. And so you want to ideally you do a bunch of research to understand, do a bunch of switch script interviews like I talked about, trying to understand the progress [affirmative] that people are trying to make through the onboarding process. Almost certainly that won't be available, you'll be in a new product area haven't got a lot of credibility, there's no sort of research resource available. And so that's where what I'd do is I'd work with the team and be trying to really scrap, try and be really scrappy. And so I'd recruit design, I'd recruit engineering, I'd get the whole team on board about let's really understand what's going on here so that we don't ship stuff that no one uses and go do your own interviews and maybe it's not as comprehensive as possible and maybe you get some research support.
But yeah, just try and just talk to a few customers and it actually almost doesn't need to be that sophisticated. And you'll start to hear some common themes about what's frustrating the payment process or installation is kinda hard. And really try and refine that yourselves. And even if you're making it up being very explicit about what you assume is wrong. And so again, we think that nav is broken. It's like, well, what do you think is broken about the na? And then just even if it's just a hypothesis that's not validated, at least note it down and write it down and then build and ship some stuff, build a little bit of credibility. And then once you've got a few wins on the board, you'll kind of be able to say, cuz in the early days, often the onboarding stuff's super obvious. There'll be huge things that you know could read online reviews or reviews in the app store or talk to just a couple of random customers you can harang and they'll be like, oh, the pricing's confusing, or I don't really wanna install.
Or you don't actually just read basic interviewing, basic script interviewing on the internet and you'll make a ton of progress pretty quickly. And so yeah, it's important to understand your customers. You probably won't get the resource to do that initially, and so just doing your own job and trying to prove some progress will, then you'll make some progress, ship some cool stuff and then you can get by and just say, Hey look, this was great but we just did these interviews ourselves and here's the three areas that we're still not really sure. And so mm-hmm [affirmative] love further investment to get some really research to go deep here and then that's gonna be much more compelling versus going, Hey, I can't do my job until I've done tons and tons and tons of research. The most stuff actually isn't that complicated and it tends to be pretty clear pretty quickly. And so just talking to a few customers five 10 honestly is plenty, as long as they're the right people. Write your own sequel, dig them out, send them emails from your own email address, honestly that's fine. You'll start to understand some patterns.
Brendan Jarvis:
So it sounds like get scrappy and also get out of the building, whether that's virtually or physically
Robbie Allan:
Thousand percent outta the building, all the answers are outside the building.
Brendan Jarvis:
[laugh], are you ready for the final one?
Robbie Allan:
Yeah, what you got?
Brendan Jarvis:
All right. Since you took over managing the onboarding product, you've come up against several different and competing agendas from sales, marketing and other product teams as to what that experience should be like. How do you align those agendas?
Robbie Allan:
Yeah, this is also not uncommon. So I think there's a couple bits here. So one part is that the often the agendas will be like you should build x. And with those, I'd really try and push the conversation back to what do you think the problem we should solve is? You'll never get a straight answer to that cause normal people aren't trained to think in problems. But basically I'd sort sit down and work with them and they'd say, oh, we think we need notifications. And just sort of test them. Okay, cool. Why do you think that? Or how would that help? Or what is it that isn't working today that notifications would solve? And if you really sort sit with people and understand them, that for a start is just gonna build a ton of rapport and people feeling heard is actually probably half the battle in the product development process. [affirmative]
Mean certainly internally, just making people feel heard. Even if you don't do what they then recommended, they'll at least go, yeah, at least you of understood what I was talking about. So first bit is trying to get to the problems that the different kind of groups think are out there and how they've come to that is that I think it'd be cool or I have three customers that tell this to me and actually if you'd like to talk to them, I'd be glad to refer you. That's what you want hear. What you don't want hear is, I'm pretty sure we're losing deals because of ex, but I can't really point to any specific one, but it's kind of the vibe. What you're looking for is, oh yeah, here's three customers I could tell you off the top of my head and I, I'd be glad to of you to them.
So get to the problems, the underlying problems and see if there's sort similarities there. And then ultimately it's a job of trying to align priorities around this. So hopefully, you know, could work with leadership. And this is literally the role of product directors is to kind of do this alignment at the sort of functional level around, well [affirmative] is sales, what's the priority? Winning more deals or reducing our support costs or is as a company, is it really important that we have the slickest experience or the fastest? What is the kind of product direction from the company level? And then within that you'll be able to say, here's how we think we can help. We're primarily a sales sold company and so we think that the job of onboarding is really to do a great job of the demo and that the, once you've actually bought that experience gonna be a little bit janky, but there'll be a support manager with you anyway and you're pretty brought up to the company by that point.
And so we're not gonna get a lot of extra points for having that be really slick. But if we can help people online really well or just as an example or it's like, look, actually our sales team don't want people on the product they wanna be, they're really focused on very large enterprise deals that are sold outbound. And so we're totally focused on helping sell to our kinda customers or as an example from Intercom, either a really close relationship with our support team and they're always eager to have me do things that would reduce support ticket load, but just relative to other stuff that was happening, it just was hard to make an impact. We were a very revenue focused team and so if you look at almost the cost saving of support, it just didn't really sort stack up. And so it was on that basis that I was able to say to them, look I'd love to help and I think it's important and we'll do it when we can.
If there's other stuff we're doing that we can slip this in for almost no cost, we'll absolutely help you out. But we can both agree that our job is revenue here and here's the bucket of money I see with your problem, here's the bucket of money I see somewhere else and we can probably both agree that I shouldn't work on your problem even though I know it's important to you. And so that kind of goes back to the building understanding and common being the chair of the decision making committee around prioritization rather than saying just computer says no,
Brendan Jarvis:
[affirmative], it sounds like a yes and type approach.
Robbie Allan:
Yeah, I mean it, it's validating because I think the thing is everyone likes being creative. Everyone wants to be innovative, everyone likes building stuff and often these ideas are good. It's very rare that I've had people come here with blatantly stupid stuff often it might be a really misguided solution to a problem that's pretty real or it might be mm-hmm [affirmative] something that's a really interesting idea but just not a priority right now or it's pretty far off our target customer, but there is someone for whom it could be useful. There's always some kernel of truth in this. And so really trying to acknowledge that with people. Hey it sounds like a really neat idea. We're not actually focused on Intercom for dogs right now, but if we were selling to canines, that makes a lot of sense to translate the whole thing into wolff's or send people dog biscuits or what, I mean everything makes sense in some context saying you're a massive idiot, you understand our target segment, that's not gonna you your friends.
So yeah, I think product is shiny and people wanna have an impact and so just validating what people have said and how I understand it. I see where you're going and maybe even giving some light feedback of, to be honest, those people aren't our target customer and that's not me from a company level, you can see that. Or if you ask your boss or the head of sales, they will also say that that's not a priority or whatever else but interesting fun innovation thing and if we have a little wiggle week or hackathon, maybe we could work on that. That can be a kinda solution to that sort of stuff.
Brendan Jarvis:
So it really sounds like having a really clear product strategy is incredibly important in making those conversations much more productive and much easier.
Robbie Allan:
It's just a chain of logic from here's who we're selling to, here's we think's important for them and so therefore pretty obviously it's important that we make and build these sort of things and that does or doesn't fit into that. Ultimately.
Brendan Jarvis:
That's your consultant coming out loud and strong there, Robbie
Robbie Allan:
[laugh]. Yeah, I mean it's kind of consulting, but ultimately it's just about making decisions within a business and it's a qualitative understanding of how you have impact for your customers.
Brendan Jarvis:
What should a product manager never do?
Robbie Allan:
What should a product manager never do? Definitely never put your business card on the table and go, I'm a product manager, therefore I know x [laugh].
I always hate that term product sense. I, you know, may have experience with a particular customer and the types of problems, but I think you just look at a website and go, oh, you could make it better in this way maybe, but that's just sort trying to be a UX expert or hey, this is more conventional or often you'll find that people do this or that. That's just some weird sort of experience. I think that ultimately it's about, hey, here's the information I have or here's the assumptions I'm making about our particular customers and I believe it. My evidence base for it is all these conversations I've had or here's the thing that you assert, it's a problem that never once has come up or I've never heard of before and if I search our support tickets, I can never find it being there. Maybe it's a problem, but usually it'll show up somewhere or some competitor will have done something that speaks to that sort of problem existing. So yeah, just trying to put your business card on the table is certainly a thing you should do. The other one is just building anything that is based on a judgment word. X, Y Z is broken, X, Y, Z needs to be redesigned, XYZ is bad cause you're confusing [affirmative].
Just don't sort start projects based on that or on solutions. Always start with, here is the progress our customer are trying to make and here's wrong about the status quo and if you can't answer that, you just dunno enough to get started because your design team is gonna try and design some solution and it's gonna be different in some way. And if it's not different in the way that solves whatever it is actual problem is, then you're just kind of rearranging the different puzzle pieces, which is a very expensive way to waste time.
Brendan Jarvis:
This is a great point to bring us down to. My final question for you today, Robbie, which is thinking about where product management is today, what's your greatest hope for the profession over the coming years?
Robbie Allan:
So I think getting better at aligning whole companies around jobs to be done. I think so mean product management itself needs to do I think a much better job of really clearly articulating the problem to be solved, to empower the design team to do good, do a good job in bringing engineering along with that, but also this is as applicable to sales and to marketing. And so I think in the future what we'll see is this sort of idea of the jobs and the progress we're trying to make will actually be aligned throughout the organization. So our marketing side will speak to those sort of problems. Our sales team will be speaking about those problems and those scripts and everyone will be iterating and trying to update and if they find the sales team find there's a different pitch that resonates, then we should service that back to marketing, back to product. Say, Hey, I think we're now selling someone slightly different and so maybe we need features to deal with that, or kind of collateral to support that. But kind of viewing the whole organization as an entity to sort understand and solve sort problems. I think elevating that to the sort of exec level will certainly be something that I hope is something that we see more of in the future.
Brendan Jarvis:
Yeah, makes sense. Robbie, thank you. This has been such a great conversation, packed with awesome stories and some really practical insights. Thank you for so generously sharing your knowledge and your experiences today.
Robbie Allan:
This was a blast. Thanks so much Brendan.
Brendan Jarvis:
Look, I've got no doubt, Robbie, that people that have listened today will get a lot of value, especially product managers from what you've shared, if people are interested in learning more about you and following your career and what you're up to, what is the best way for them to do that?
Robbie Allan:
I'm on Twitter @RobbieDigi or, and a bunch of my writing is on the Intercom blog. If you sort of go to the Intercom blog and search by author, you can check some of the stuff I've written there about jobs we've done about problem statements, about onboarding, about a bunch of growth work, churn, better attention messagings and stuff like that. We'd love to hear from you.
Brendan Jarvis:
Great. Thanks Robbie. Yeah, there was a lot of stuff that we didn't get to today, so we'll have to do around two at some point. To everyone that's listening, it's been great having you here as well. Everything that I've covered with Robbie today will be in the show notes, including where you can find it and also all the resources that we've touched on. If you enjoyed the show and you want to hear more great conversations like this from world class leaders in UX, product and design, don't forget to leave us a review and subscribe to the podcast. And until next time, keep being brave.

Robbie Allan

Influencing Without Authority in Product Management

Subscribe

Who is Robbie Allan?

Transcript