Episode 180: Aligning Product Goals with Business Outcomes: Insights from Sean O'Neill of Syncron
Sean O’Neill is currently the Chief Product & Technology Officer at Syncron but he has held senior product roles at a number of big organizations spanning Europe and the USA, including Amazon and Tesco.
He understands the importance of adaptability for a product manager, but he also has a lot of strong principles surrounding product management that he rarely veers from. These include the value-creation moments and financial literacy. I spoke to him recently on the newest episode of the Product Thinking podcast about the difference between product development in the US compared to Europe and he explained the subtleties in how he measures success, looking predominantly at renewals more than initial user sign-ups.
Read on to hear more of what he had to say.
You’ll hear them talk about:
09:39 - Identifying Value Creation Moments
Identifying where you can create and add value is a vital part of your role as a product manager. The ‘value-creation moments’ that you should be looking for are instances where significant value is created for either the customer or the business, or even both! Being able to recognize and understand these moments is key for figuring out how much investment into certain areas is needed. To be able to do this effectively, product managers need a deep understanding of their company’s business model, cost structure, and revenue streams. By thinking like an entrepreneur and educating yourself on these elements, you can become a better product manager.
13.55 - Thin Slicing and Making it Cheap to Be Wrong
If you want to grow and develop fast, you need to take risks and nurture a culture of experimentation. You can maintain this culture by actively pursuing segmentation in the development process as you scale. By ‘thin slicing’ you tackle manageable parts of the process one at a time, allowing for fast feedback and rectification of errors. This mitigates the risk of investing in changes that could be a failure. This is all in aid of Sean’s overarching point that you need to be trying to make it “cheap to be wrong”. This is one of the only ways you can keep buy-in for experiments when the bets start to get bigger.
39.56 - Differences in Product Management Between the US and Europe
Sean reflects on his experiences in both American and European organizations, and he notes that the European product management ecosystem is about 10 to 15 years behind the US. He observes that European product managers often become rigid in their approach, adhering strictly to the first methodology they learn. In contrast, successful US product managers adopt a more entrepreneurial mindset using the right tools for the job at hand and maintaining a holistic view of the business. Sean uses this comparison to stress the importance of adaptability, focusing on impact more than methodology.
Episode Resources:
Other Resources:
Follow/Subscribe Now:
Facebook | Instagram | Twitter | LinkedIn
Intro - 00:00:01: Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary-pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perri.
Melissa - 00:00:37: Hello, and welcome to another episode of the Product Thinking Podcast. Product management, as we all know, is all about delivering value, but how we go about that can take many forms. Sometimes it's better to buy a product than build it. Oftentimes, we have to realize value by thin-slicing the product to get it out the door faster. At the end of the day, all of these decisions are driven by aligning back to the business model and strategy. We're digging into all of these topics today with Sean O'Neill, a powerhouse of product who's been working in the field for more than 25 years. He's currently the Chief Product and Technology Officer at Synchron in London, a customer service experience platform centralizing the management of aftermarket sales and service processes through AI. Before that, he was leading product at Tesco through their transformation, and even before that, he worked at Amazon. I'm really excited to talk to Sean on this episode, but before we dive in with him, it's time for Dear Melissa. So this is a segment of our show where you can ask me any of your burning product management questions, and I answer them every single week. Go to dearmelissa.com, and drop me a line about what you wanna know. Let's read this week's question.
Dear Melissa, I've read your book, Escaping the Build Trap, and I've learned a lot from it. However, I have this question in which I know there's no silver bullet answer, but needs to be asked anyhow. What is your approach to handling pressure from a sales team when they have their own quotas or objectives to meet, and you just can't give them hard dates on when you're going to ship their most awaited version? I've tried to introduce an alternative approach to roadmap, meaning provide visibility on the outcomes we're going to work on in the next year or so, and only really give some specifics as to a release plan up to three months ahead. As we work on three-month increments each time, I even propose to invite them along as we progress during demos before each release, so they can be as close to our process and see if our work really does respond to the problems we're solving. We do discovery work with our users, but I think it's the connection of this work that needs to be communicated clearly to the sales team. Do you have another approach which could enlighten them on not being distracted with traditional roadmaps?
So it's always hard with product managers to really go against sales expectations. But that tension is what drives our business forward. So I want you to think about this too as what do they need and what do our customers need? A lot of times if you're working in a B2B business, customers do need to know when certain features are going to be out. And sales needs to know this because that's how they close deals. That doesn't mean that we have to commit to super hard dates. No, it's not like, hey, March 22nd, we're going to release this. But we should be thinking about quarters or years. Which quarter are we planning this for is a pretty reasonable high-level ask from a salesperson. Now, if that's like four years out, that's not reasonable. But if we're talking yearly planning, that is reasonable. So if you're only focused on three months of roadmapping and not connecting things to a longer strategy for your product, that is an issue. And that's what it sounds like to me right here. So you should be having actually a big product division that spans multiple years. And you should be breaking that down into the high-level problems you want to solve for customers. This is after doing a lot of discovery work and trying to figure out how to position this. And then you're going to want to figure out the sequence for getting that out. What's the first level of value that you can release? What's the second level? You can be breaking these down into things that you want to focus on in quarter one, quarter two, quarter three, and quarter four. Something like that. It should be high-level. It shouldn't be just a list of feature sets. But you can kind of see when certain things are going to come out versus not. What's worrying me about the way that you're writing this is it sounds like you're prioritizing what you're going to work on, not towards a bigger vision or initiatives.
So in my book that you read, we talked about strategy canvas, right? And we said we had strategic intents, we have product initiatives, and then we have the options that you're working on, breaking those down so that we figure out what to release. The options are the solutions. Those product initiatives are usually broken down into many different options that contribute to reaching that goal. They're tied back to a product vision. So you need to have a long-reaching product vision. Then you need to think about what we're prioritizing now versus later. And that doesn't mean that you have to commit to a list of features every single quarter for two years out. It's more like, hey, we're going to be prioritizing these features in this quarter. Then we think maybe next quarter, we're going to be solving these problems. And then the quarter after that, we're going to be solving these types of problems. So it's probably going to be sometime towards the end of the year that we might get around to releasing that thing that your customer is looking at. That's a reasonable conversation to have with a salesperson. I don't think they're asking for a lot in that situation. Now, if they're asking for extremely hard dates on a Gantt chart about when you're going to be releasing stuff, that's not okay. You do have to push back there and say, I can't promise that. We are making sure that we're measuring this and that we're getting the right results before we can commit to that. But I can tell you that that's where we're going to focus. Also turn this into a conversation with the salesperson to ask them, what are you hearing from the market? Can you tell me which customers have this problem that you're asking for? You're going to want to take that information and figure out if you should be reprioritizing your roadmap to get to that version.
They might be hearing things that you're not aware of. When you break things down from a big company's financial perspective of what we're trying to achieve with our customers and our goals from a business perspective, and you marry that with the customer problems that you have with discovery, that's how you build a business case. So you don't want to be just thinking every three months without having a longer term plan. You want to have a longer term view of where the product is heading, what the vision is going to be, who would solve the problems for? And you want to back that up with some good financial data or customer data and make sure that it's going to make an impact on your business. Because we have to remember that as product managers, we're not just beholden to customer needs, which is what we should be solving. We're also beholden to the business problems as well. So we need to marry both of these things and see ourselves as stewards of the business. So if sales is coming to you and saying, hey, I can't close these deals with these personas because this version is not coming out, quantify that, right? Figure out, figure out what that would mean for the business if you were to reprioritize that over the work that you have. That's going to tell you if you're going to help them reach business goals. You should be having a collaboration and a lot of conversations with sales to figure out what they're hearing. Now, there are salespeople who are just trying to hit objectives and they're trying to sell and promise whatever it is. That happens all the time. But sometimes they're coming to you for a reason. You should really figure out what that reason is. You should really figure out who's telling them they need these things. Get curious about it and dive into that data because that could help you be a better product manager.
So that's what I would really look at. I don't know if it's the roadmap format that you're really struggling with here. I think you have to come back and start to think a little more longer term and then break that down into what it's going to look like for these next three months and then the next three months afterwards when you get into the planning for the quarter. We're not saying that you should look at every single little tiny thing you're doing each quarter up front, but you should be getting a bird's eye view of how this is going to manifest over time. I think that's the connection that you're missing here. So I really hope that helps. And I hope you do collaborate with sales and talk to them about that because that's where you're going to learn a lot. All right. Now, let's go talk to Sean. Are you eager to dive into the world of angel investing? I was too, but I wasn't sure how to get started. I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side. This is why I joined Hustle Fund's Angel Squad. They don't just bring you opportunities to invest in early stage companies, they provide an entire education on how professional investors think about which companies to fund. Product leaders make fantastic angel investors. And if you're interested in joining me at Angel Squad, you can learn more at hustlefund.vc/mp. Find the link in our show notes. Hey, Sean, welcome to the podcast. It's great to have you.
Sean - 00:08:19: Hi, Melissa. Thanks for having me.
Melissa - 00:08:21: So I've been reading a lot of your work on LinkedIn, all about your product career and your ideas about what great product management looks like. You've written some fantastic articles on build versus buy decisions, which we're going to get into today. But I think this key theme of what it takes to create a, what you call a value creation moment as a product manager and how to hone in on it is really interesting. Can you tell us a little bit about your career so far and what led you to your thoughts around value creation moments?
Sean - 00:08:49: I've been really fortunate that I've worked with some really talented people and really interesting companies at pivotal points in those companies' lives. And that has taught me so much over the years. I got my first product management job in 1999 at a small upstart bookseller in Seattle called Amazon.com. I've done startups with two founders in a garage trying to build the next new, new thing. I've led 200-person product design and science orgs at Tesco, the world's largest grocery home shopping delivery company and I've been a CPO through private equity transformations and exits. So I've really had this benefit across multiple continents of seeing the evolution of product as a function and the evolution of product's impact on business. And that's really helped shape for me this thought about where's the value creation moment happening? And how do I teach our teams to find it?
Melissa - 00:09:39: So what is a value creation moment? Like, how would you define it? How do you actually identify what it is?
Sean - 00:09:45: So a value creation moment is something that creates value for a customer worth paying for or for a business that generates value and cash flow for a business. And it could be either or both. And it can happen at a micro level. I've been chatting with Jeff Gothelf and Josh Seidel on their new book about OKRs and who does what by how much, very much in the same vein but it also could be a macro business model question of does this business create value? Don't just build something that costs a lot of money. How do we think about should we put this idea? One developer, 10 developers, 100, 1,000. As a product leader, you have to think about how much should I invest relative to the opportunity?
Melissa - 00:10:26: I think that's important, that investment piece. Sometimes people aren't doing the math on there to actually figure out what does this cost? How does it go in hand in hand? When you're teaching people to identify a value creation moment, what are you teaching your product managers about identifying that opportunity, trying to figure out what's going to do for either the business or the customers? And then how do you educate them about the cost piece too? How do you do the financial side of that?
Sean - 00:10:49: Well, the cost piece can be a little bit trickier. Let me first start with the revenue side and the benefit. To be a successful product manager, you really need to be an entrepreneur. And you need to think about and understand your business's business model. How do you make money? What business are you in? What do you charge? What's fixed costs? What's variable costs? Just having a basic level of financial acumen gives you an advantage as a product manager and leader. Because the reality is product managers speak a foreign language and we forget it all the time. We'll go into an executive stakeholder meeting and we'll say, well, we're going to do this in an agile way. And I'm going to throw in the words AI and ML a couple times and that will really impress the execs. And they're going to walk out of there having no idea what we're working on or when it lands. But we need to translate. And we translate into the stakeholder language of our customers, our executives, and our shareholders by speaking in terms of the P&L of a business. How do we generate renewals? How do we generate customer-based growth? How do we generate net promoter score that translate into something of value and by understanding the business, you then can say as a team, how do your team's goals align to the outcomes and key results of the overall business? If you don't understand that, you should stop listening to this podcast and go figure that out and then come back and continue. It's fundamental for you to earn the respect of your stakeholders, to understand their concerns, and how your work lines up with the business. So once you have that high level of understanding of here's how our business works. Here's our cost structure. Here's what we can afford. Here's what we can't afford.
You then can say, what's the next step of my value creation for my product or my system I'm working on? And as an example, I joined Synchron five months ago. Fantastic products, fantastic teams. In one area, we're building this whole data mesh, really advancing our knowledge and our capabilities about how do we take advantage of this? But if you ask a team to build a data lake and fill it with data, you will end up with a data lake full of data with the AWS meter running constantly. So I'm asking, where's the value creation moment? Where's the moment that a customer benefits enough that they will pay for some service that will actually fund and underwrite the entire system? How do we think about the business model of the system? And then we can sequence it. How do we slice this into releasing value with slices instead of these real long arc investments that have a very slow feedback loop? This is a lot of what lean startup and Eric Ries is teaching us all these years ago. So by finding that thin slice, you then can figure out instead of serving the universe in step one, that might be two years or three years out. How do I find a meaningful segment of our customer base that has a real problem we can solve, that has a clear job to be done, that if we provide this service to them, we validate they'll pay for it? And then how do we do instead of a push all data forward and see who wants it, do a pull model where we're solving a meaningful problem end to end and gaining the learning of all the other side tasks that need to be done to make the whole thing work in production at scale. That's an example of finding a value creation model.
Melissa - 00:13:55: So that's thin slicing piece that you're talking about. To me, that's been really, really hard to teach new product managers. And a lot of people misunderstand what a thin slice is. They go back to terminology about MVPs and different pieces. I think when you start to talk about that, there's this fear that we're going to be putting out super incomplete products that are broken or don't work correctly. But to me, that is how we think of how do we use our tools and how do we use our technology around us and what can we do to start creating value faster? What do you do to thin slice? How should product managers think about thin slicing? And can you give us an example of how you did thin slicing in the past at any one of these companies?
Sean - 00:14:38: I've got a number of principles I posted up on LinkedIn. And two of them that come together here are release value and slices that we're talking about. And the other is make it cheap to be wrong. Let's not fail fast. In a B2B world, clients don't want you to fail fast. But we can make it cheap to be wrong. And if you think about this learning cycle, it's like tuition. How much tuition do you want to pay to learn something before you put an entire squad or five squads on some problem space? And in my last business, GFK, we broke this down in a couple of ways. Initially, GFK is a big data and analytics business. We served 60 different countries around the world, the world's largest consumer electronics, manufacturers and retailers about all the information of their market, who bought what for how much, geolocations, all this granular data of their markets and consumer insights. And the initial plan was we're going to launch everywhere and everything all the time at once.
And that's a high-risk plan. So instead, we start narrowing it down. Pick five to 10 different industry subsegments that we'll tackle first. Then by the personas, there's 15 personas and our clients that would buy our data. Pick one. We picked the sales manager. We had five or 10 product categories across six or eight countries. And that combination formed our initial launch site. And then we bounded the scope. This is the real meat. You've got to bound the problem space where there's value inside it of some job to be done by a client with a willingness to pay but you're not trying to solve the universe's problems in one step because you'll not solve anyone's problems completely. So this sort of segmentation breakdown is really important. Think about your personas and be able to rank the pain of your persona segments. Think about industry segments. Think about country segments. You will find a fracture plane somewhere in there that you could go in and bound it and solve that problem first.
Melissa - 00:16:27: What I see organizations do as well is lose what you're talking about as they start to scale. And I worked with a company recently that was super experimental, fantastic when they were launching. And now 15 years later, they're huge. It's great. But the experimental mindset is kind of not there. The whole starting small is not there. So they're putting out really big things, which were failing because they weren't going back and thinking about the thin slicing or the testing or how do we do this or just taking very big bets, but launching them in very big ways when you are trying to build like a culture of an organization, that's not, let's say a startup, right? Not something that we're just launching first off. How do you make sure that the mindset of the organization stays experimental and that the product managers start thinking small as well before they go big, even on new feature releases or new product lines or anything that they're doing there?
Sean - 00:17:17: There's two different ways to approach this. There's a danger of so much success, your executive team thinks everything works all the time. So one, you want to be a little bit more transparent of how the sausage is made in the factory that it takes time for validation before you're ready to build scale. So at GFK, and one of the ways we did this was going back to paper prototypes with clients. Rather than trying to build something pixel perfect from the start, we would literally have a paper prototype and sketch it up in the interviews with users and talk through, tell us about your problem. Hey, would this solve it? What if we did this? And then we would go to real data prototypes, but they're still pretty cheap. We'd use Google Data Studio, load up a file of real data, and then we could do a very basic UI that allows somebody to say, would this help you do your job? Because at that moment of time, we need to know what's the riskiest hypothesis to this proposition. This was for new pricing tools so that brand manufacturers of electronics could improve their yield and figure out by elasticity of what to promote or not to promote. And the question was not, can we build a user interface to sit on top? We already had other modules in our SaaS platform that did that. So don't waste any time trying to build a UI for a demo. Instead, can we help them get to better outcomes? And by focusing on your riskiest hypothesis, you know what not to do in stage one.
And then you can make it cheap to be wrong. I had a different example when I was at Tesco. We had the world's largest grocery home shopping business. And at that point, just our mobile apps was over a billion pounds of revenue a year of grocery home shopping e-commerce. And we were rebuilding the entire app. This was back in 2015 or 2016. We were very inspired by a lot of the cutting edge designs at the time of Facebook and other feeds and how to do inspiration. But the problem that I failed to do and my team failed to do is we didn't time box it. We didn't time box it to say, go do some discovery cycles and then come up for air and show us what you've done. And instead, we ended up continuing to do research and research and research on just the homepage and the feeds. And we got so deep in that, it were six, seven months along, we still did not have any of the other parts of the app functionally built or solved for it. So we had nothing we could put in the user's hands to say, does this reduce friction in your life? Does this help you? We had nothing we could test end to end. And that was my mistake. So I've learned from that, time box your discoveries. That's another way to make it cheap to be wrong. Because you may have engineers waiting for feed to sprint. We're still in discovery. You got to be able to come up for air and make a decision.
Melissa - 00:19:45: That thread too about timeboxing. I've seen people do this the wrong way where they go, okay, you have one week for discovery every quarter. Go do that discovery thing and then get building. How do you think about adjusting timelines for the type of discovery you're doing, whether it's launching a new product or a smaller feature or iterating on UX? Do you have general guidelines that you think about with how much of a timebox you should do?
Sean - 00:20:10: Part of it depends on how well do we know the domain space? How well have we validated existing customer pain points and needs? You know, if this is an existing space that we've got four other propositions customers already use in it, and we're thinking about doing an add-on to fill a gap, probably have a lot more confidence of the need because it's probably come through maybe in your customer service tickets for customers complaining of some lack. If it's a brand new product in a brand new space with a customer base that you have not interacted a lot with, you've got to be realistic. That's going to take a little bit more time. And don't just look at what your competition is doing. This is one of the great lessons that Jeff Bezos and the Amazon leadership team brought along. Obsess over your customers, not your competitors. Pay attention to your competitors. And Amazon will steal with pride if someone's doing something amazing that customers really like. But don't just blindly copy your competitors. There's one example at Tesco. We were doing so many A-B tests across the grocery home shopping experience and really improving it. And we had a feature that we were running as an A-B test over a couple months that ultimately we realized was underperforming and wasn't worth its real estate. So as we were turning it off, one of our competitors launched a copy of it. They didn't know it didn't work. They didn't know it was negative. But they saw Tesco was doing it, and we're a market leader, so let's follow the leader. Beware.
Melissa - 00:21:28: I think that's such a true story for so many people probably listening to this, where everybody goes, oh, it's your competitor. Now, on the flip side, I do get this question from people a lot. And I have my own way. I'm thinking about it, but I would love to hear yours. In a B2B scenario, sometimes whoever's doing procurement or who is evaluating products, they'll go down almost like a checklist where you go, oh, you don't have this feature, but they have this feature. And I've seen product managers try to follow up and say, hey, why do you need it, blah, blah, blah. Sometimes they're just trying to check a box. How do you balance those people wanting to go out there and they're looking for these features, but they can't really explain why with actually concentrating on stuff that you know produces customer value? What's the trade-off there?
Sean - 00:22:12: Come on, isn't this escaping the build trap? The real challenge is when you can't articulate the value proposition and some meaningful impact on your users' life for their business. So it's a slippery losing slope when you get into feature-by-feature parity against competitors. Because even if you copy some feature, maybe they're already three years ahead, even if it's an important one, and your first one's going to be probably mediocre in comparison. I think it's more important for product managers to think about what is your positioning. You don't have to do every single thing best-in-class in that space. You need to do the most important job to be done needs best-in-class in that space. And that can make the difference. Sometimes even on the feature side, lack of measurement can be a problem for you. So when we were at Tesco, we were migrating our huge e-commerce business off of this old legacy stack and moving it on to a modern service-oriented architecture with Node React. And some of the merchandising team, we're adamant we couldn't migrate without this long list of features, which is kind of comparable to that. You have to do all these features. We had not yet fully instrumented the existing legacy grocery home shopping site. So I put some basic tagging on it. And that revealed that the feature that they were saying is a must-launch critical feature was used like 0.1% of sessions touched it. And it was insignificant for revenue. As soon as I had real data, the debate went away. And we were able to focus on what's launch version one versus not launch critical and any sort of these legacy migrations, this is a super important step. Do some basic instrumentation. You think it's going to slow you down, but it will bring clarity to the whole organization of what features are most critical to migrate over, and which ones should you just leave behind.
Melissa - 00:23:54: I like that story. I had a similar one at a company where the CEO kept saying, oh, we need to build dashboards because so many people frequent our homepage every day. I'm watching them. They're logging in every single day using our product. We need to create these dashboards for them. We got to show more activity, more insights. And we went out and we did user research and it turns out that they weren't necessarily logging in every day. It was that every time they opened their browser, it was up there and it recorded the session on the browser. But we only refreshed our data, this is over 10 years ago, only once a week. So they were checking it once a week when we refreshed our data, but they just had it open in their browser in the background because they never changed tabs and they kept everything open all the time and they'd flip through it. So when we went back and told the CEO, we're like, I don't think we should be prioritizing this right now because our biggest issue is actually the data. They said, if you can refresh the data every day, then they would go check it. But the fact that we can't do that, it doesn't make sense to do dashboards right now. It makes more sense to actually fix the data problem.
Sean - 00:24:49: And I think that goes right back to understanding the business model and the value proposition of once a week was partially but not fully meeting the job to be done. There was more opportunity. There's another interesting parallel about finding the value creation moment. And this happens whenever you have a large, complicated subscription service and you have a product team that add a new feature into it. And everybody asks, did it add value? Did it make a difference? And this is a real important problem for product leaders to decide what's worth funding and how much did you put into it? And did you create enough value that someone will pay for it on the other side? So at GFK, the way we tackled this problem, we had good implementation with amplitude so that we had good tagging. And I started requiring every product manager before a major feature launch to come back with two estimations before we launched. In the first four weeks, what percentage of eligible subscribers will use your feature? And four weeks after they first touch it, what percentage will repeat? Those are the only two numbers I asked. How many will try it and how many will repeat? And this really opened up a lot of eyes and minds, especially if you've got a commercial team that's really trying to bang the drum on the next feature and the next feature and the next feature.
Because our job as product managers is not to launch features. That's a radical statement. Our job is to launch features so valuable customers will pay for them and renew them. And that's different than just launching features. And so the way we were measuring this, if we had 50% of users in the first four weeks, try it. And 5% repeat, we've got a proposition problem. We're not solving their need. Nobody's going to pay for that at renewal. Not enough people to justify the investment in it. So that also allowed us with the commercial team to say, we're not pulling the next epic into our backlog. We're not done on this one. Now, you'd hope we would have discovered some of this earlier, but sometimes this is the situation we're in. So how do we work through and improve the value users are getting from it, especially the profile of values that's for? Now, in the reverse sense, what if you had 5% of eligible users tried it and 50% of those repeated? Well, that's an awareness problem. Easier to solve. Maybe we are product marketing isn't good enough yet. Maybe we put it so far down in navigation people can't find it. Maybe we gave it a confusing label that people don't understand what's there. But either way, you now have diagnosed what do I need to do that's to create value that people will pay for.
Melissa - 00:27:11: That modeling piece that you're talking about too, trying to project how many people are going to use it with the subscription, that I find is very hard for product managers to wrap their heads around sometimes. In some companies, it is actually hard to get that data. In other ones, you do have the data, they just don't know how to do the modeling. How do you get product managers that you've coached comfortable with modeling? And what would you suggest to the ones listening who want to do those types of analysis? Where do they start? How do they start learning about that?
Sean - 00:27:38: Well, we made it actually simpler than it sounds. For GFK, it's business-to-business software-as-a-service application. Client base are the 1,000 largest consumer brand manufacturers, electronics around the world. So this isn't 10 million customers. We have a large user base for each of our clients around the world. But we did a basic profile. We asked people to tell us, what's your job title, which includes what's your job level. So are you an executive? Are you a director? Are you a manager of operations? What functional area do you work in? And where do you sit in the corporate hierarchy? Are you at global headquarters? Are you in a regional headquarters? Or are you locally based in the country? And based off those, we could then do all sorts of interesting profiles of, are you relevant to this proposition we're creating? So as we found, this was a very simple estimation. If we built a pricing tool that was geared towards channel managers, we expected at least 50% of users to use it on a weekly basis. Because we had enough other baseline data through our amplitude implementation. If you are a secondary persona for it, then maybe we'd only expect 15%. But we could calibrate over time, what do we think the audience for this is? Now, the earlier question you asked, how do you know how much to invest in it? We suddenly can start thinking through, do we think this is a key proposition pillar for a persona type and how large is that persona type and how much value can we create? Then you start with the total addressable market, and then you get to your service addressable market and then you get to the current captive, you could start to get a sense of, should I put one developer on it, 10 or a hundred? And you'll start over time to be able to make better allocations of your precious capacity to the opportunities.
Melissa - 00:29:20: Did you know I have a course for product managers that you could take? It's called Product Institute. Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school. We have an ever-growing list of courses to help you work through your current product dilemma. Visit productinstitute.com and learn to think like a great product manager. Use code THINKING to save $200 at checkout on our premier course, Product Management Foundations. On the topic of the value creation moments too, you did write this great article on build versus buy. And when you should think about buying software, right, that maybe is not your core value proposition or when you should actually build it. Can you walk us through what your model looks like and how that relates back to how you think about value creation moments?
Sean - 00:30:09: And it's so important because so many people spend precious development cycles building things they could have bought off the shelf. Like back when I was in the startup, we at the time needed to have a refer a friend functionality. This was back in the 2000s when people actually did refer a friend all the time. And so we needed a way for people to be able to upload their email contacts or other contacts into our system and then choose who do they want to send a refer a friend link to. And I looked at us building it and the complexity of maintaining for 15 or 20 different email systems, a linkage. Which could be very fragile and break all the time, sometimes just scraping. And I eventually found a third party developer who had built that and I licensed it from him. He maintained all of it for different companies. And we were pitching at that time to angel investors and we had an angel investor we were pitching to and he started to get really angry when I was telling him this. And he was getting mad and I'm wondering why is this guy so angry? He said he has another investment of another company where that team just spent three months building this exact capability. And it costs. I think it was like $25,000 of development costs to build this themselves.
I licensed it for $75 a year for the whole library. $75. And you just think about the build versus buy trade-off there. Now, as you think about what should I build versus buy? To me, it always starts with strategy. What is your core proposition? What do you need to be the best in the world on to win? Because it is dangerous to outsource what should be your competitive advantage. Because if you outsource it to a third party vendor, any other competitor could come along license, the same source and now they're parity with you. So you've really got to be clear on your proposition and what has to happen for you to continue to innovate and lead that. You then have to ask, if we build this functionality, will it make us best in the world and will it make a difference on our win rate? If not, then you can consider going through the decision tree I put on LinkedIn about, can I license it? Do I need to acquire it? There's a number of different options, but it's always got to start with strategy. Will it help you win?
Melissa - 00:32:15: I went through a very similar exercise. I was an interim CPO for this healthcare company. And to me, this really solidified just watching build versus buy decisions play out in really big ways. The markets that they were targeting is they had really small one-person therapists that they would target, or they would do two-person therapists, or they would do slightly bigger mid-sized groups versus enterprises. And when I came into the company after it was invested in, they had a product for everything that they built their own and had a small development team. And we had to try to figure out where we were going to invest. And for them, the reason that people were buying them was more of their billing capabilities and the way that the therapists interface with their patients, right? How they took care of them. Yet we had people working on these like HR capabilities and payroll and all these other things. And when we looked at the strategy and said, like, where should we double down? Where should we win? Where should we put our dollars? It made a lot of sense that like payroll's already been solved. All these other things have been solved. And when we looked into licensing it, it was actually pretty cheap. We even scrapped it. Like we scrapped our own roll your own products. And I feel like people. Love doing that. They don't like sunsetting stuff they already have. But for us, putting everybody 50-50 on the billing and the interfaces that people were using, that grew the company like crazy. And I feel like everybody's scared to just stop work on what they're currently building and not looking at where are you going to get from it at the end of the day? How much is this actually going to cost? Everybody thinks developers are free because they're on payroll.
Sean - 00:33:44: Yes. Well, and the sunk cost fallacy. They think how much they've spent in it. But the reality is, imagine you stepped into that team today and you have a job to create value. You're a product manager. That's your job to create value for the business. What's the best path forward? And how should you apply your capacity? And you have to ignore all the investments in the path. Now, if something's 80% done, is it worth getting it the last 20% to get a mediocre value versus licensing? You could do the analysis, but don't get trapped in a sunk cost.
Melissa - 00:34:13: When you are a product manager on a team, I have heard from a lot of leaders saying they want people to evaluate the costs and start to think through that. I actually heard some leaders talking about this the other day because they were mad that their team was completely ignoring AWS costs for what they were trying to build with AI. That takes power, right? That takes compute. Sometimes we forget about that. Let's say you're a product manager on a team. You're coaching them. You're their manager. How would you tell them when it's important to start evaluating costs and what types of things should they look at for costs? I know it's not just developer hours, right? There's a lot more that goes into that. What types of things should you think through?
Sean - 00:34:49: So I'm literally going through this topic this week with my own leadership team and extended leadership and going through a mini MBA program that I've set up for our teams. And this next topic is FinOps and financial literacy. And fundamentally, it's far more valuable to build innovation than to cut costs. That is clear. But our goal is to build a meaningful business. And you need to know the difference between a fixed cost that every customer you get, you can spread those fixed costs across them, which brings scale margins and a variable cost that every new customer you get has the same cost. And you need to know the difference between those because software is a fixed cost business. You write the code once, you create the model once. How many customer events can you pass through it is where you get scale economies out. And so it's important to know when you're about to make a decision on a technology or an infrastructure. Is this a fixed cost or a variable cost is an important one?
And is it meaningful? It might be insignificant, in which case I wouldn't worry about it. When you think about the costs that are fixed costs, they may be very high at the start. Payroll is a fixed cost. You've got a lot of teams working on something. But you need to be able to understand your total addressable market. How big is it? And what would a reasonable scale look like? Because it depends if you're public or private. Private shareholders actually get a scale model. And if you could say, look, we are not going to hit break-even until we get X number of clients at X subscriptions or revenue, they'll understand that. And then they could debate, will that come in 12 months, 18, or 24? But they're not afraid of you spending money to make money. The problem is if you start with this high fixed cost, and then you've got no path to grow out of it. That would be a bad business and our job as product leaders is to be able to tell the difference. And that's where this financial acumen really is important.
Melissa - 00:36:41: I think it's important to know as well, like this is becoming really important with AI and with open AI models, right? Because they are a volume play and you pay per volume. And of course, again, cheaper and cheaper. It's going to, I think it's going to go close to zero one day, but it's not there yet. So I think a lot of product managers and leaders, honestly, and organizations are really excited about OpenAI and let's see a GPT and let's do this. But if you have a lot of customers pinging that repeatedly, right, that's going to be a very different cost model than what you did with just AWS. And I see a lot of people not modeling that out yet.
Sean - 00:37:16: That is certainly true. You need to be considering in your subscriptions to tell the difference between a base level of usage, heavy users or super heavy users. We build shiny red buttons and we put them in front of customers. Do they push it once a month, once a week, once a day, every 15 minutes? We've got to be able to make sure that you've got a commercial construct that aligns your cost structure to your revenue. And AWS at the last reInvent in the fall had a great speech that Werner Vogels, the CTO of Amazon, did on the frugal architect. And he has a website, thefrugalarchitect.com that lays out these basic principles. And we're bringing those into my company as well. How do we think about the choices we make so that we don't get surprised in a negative way when customers love our product so much that we lose money on it?
Melissa - 00:38:05: Are you doing types of high and low models with that? Like what kind of models are you looking at specifically? And how do you evaluate that risk, right? Because there might be something where you do use AI or you put these components in and it's so much more valuable than it was before, right? So maybe it changes the pricing structure or things like that. What are all those factors that you're looking at now as you go through that? And how do you think about modeling those things out?
Sean - 00:38:30: So we're still early days in this, but there's a couple of factors. One is, is it embedded in your core proposition already that you need to be best in class across your industry? And will that give you a win rate advantage? You may want to put it into the core product then. If the cost to run them from our modeling is going to be so much different than the base business, you may not just be able to add it into the core product and have that part of existing subscriptions. So you may want to do it as an add-on. And it's an interesting space in time when customers come asking for AIML. AIML is a tool. And it's ironic to have somebody, like you don't go to an automaker and say, could you put more pistons in for me? And I'd like them hydraulic. That's not a conversation a customer has. You just want the car to be better handling performance. And how it works is the magic underneath. We've got customers asking for AIML. It's a thing in the market now. So you've got to make sure that you are able to understand the cost, but also it better do something meaningful for your customers. Don't just throw models out because you think we've got them because your customers are going to be able to tell. They're going to figure out if it did not add value to them or not. So make sure you solve real problems.
Melissa - 00:39:40: I think this gets into the whole as well, like don't necessarily build exactly what your customers ask for. It's not their job to like solve their own problems. It's your job to solve their problems. And definitely in this age of everybody asking for AI, ML, all that stuff, I think we have to remember that more and more as product managers these days. So you've also been working in Europe for the past 10 years, and you're based in London. You have worked at Tesco and a lot of other European companies. But before that, you were in the U.S. For quite a while. Can you tell us a little bit about what you've observed about product management in Europe versus the U.S.?
Sean - 00:40:13: It's a very interesting space, and I've had many folks across my teams that have been in multiple continents. And the European and U.K. Product management ecosystem is about 10 to 15 years behind where the U.S. Was in its development. It really just started about 10 years ago in the U.K., really scaling up of companies understanding the role of a product manager and actually funding and recruiting headcount into their works. So relatively recent. And so many folks I've worked with in my teams are so passionate about product, which is amazing. The one challenge I've seen is that whatever the first book they read on product management becomes their Bible. And that is the only way to do product management. And for a job family that by definition is supposed to be adapted and flexible, they become the most rigid in process of this is the only way to do product management. But what I learned from Amazon and a lot of the other FANG, big US tech product management approaches is that the most successful product managers at their hearts, they're entrepreneurs. And as an entrepreneur, you use the right tool for the job in the moment. And you have a big picture view of the whole business. You're taking a holistic view. You're not just thinking of my feature. You're thinking about how will the whole thing work. Sometimes as product managers are called mini CEOs, it's not because they have all the authority because they're responsible for how the whole business should work. And so that's been one of these interesting and a lot of my coaching for my product teams is how to think in an outcome-based way, in an entrepreneurial way, and don't be precious about the method. Be precious about the impact.
Melissa - 00:41:58: I've always found product management too is going to change depending on what context you're in. But for me, like I've always thought about it as the basics are the same, right? Like we still sit in this intersection of business, technology, and customers. And we have to identify problems and opportunities and figure out if they're going to work for that. And then we have to figure out if they're the right solution that involves experimentation. We got to launch it. We got to iterate. We got to track success. But the way that you might do that changes depending on if you're a B2C company or a B2B or you're a bank, right? Going through a transformation versus a SaaS company. People, when they're starting off learning product management, I do see them getting attached to their processes a lot. What they're not reading is keeping the bill trap and using that as like a hammer. But I have seen people do that too. I thought it was funny.
I have a friend who's a chief product officer and he went into this new company and people started yelling at him that Melissa Perri doesn't say how to do this this way in her book. And he was like, I know Melissa Perri. You want me to text her right now and ask her? So he texted me and said, my product managers are all yelling at me because they said that you don't do X, Y, and Z. And I was like, no, that's dumb. And I was like, tell them this, this, and this. And he just shows them the text message. And they're like, oh, okay. But I do see people use those processes as a hammer. And a lot of conversations I think we get into these days are about like, are we doing the process right versus are we actually building the right thing? And to me, that's not necessarily healthy like we do need a healthy amount of process to make things work, but it's all about adapting, right? That's the Agile principles at the end of the day, too. And I do see that more in Europe that we're still on a little bit more of the process train than we are in the US.
Sean - 00:43:36: Again, I wrote an article on this topic on LinkedIn, so folks can look up this very topic. But what's interesting is you think about the example of the product managers saying this is the only way to do it. Think on the stakeholder side. I've come into companies in Europe where the stakeholders have been so tainted by what agile product teams have done that they have come to think agile means unfocused and no direction. And we don't know what we're working on and we'll tell you when it wins. And this is why we really need to bring, well, one, the process should work for you. You don't work for the process. So you should know when to deviate or change it because you know what outcome you want. But I'm going to come back to this business, commercial savviness. It is so fundamental that if as a product manager and leader, you understand the business you're in and you can translate the stakeholders' words and your language and make that bridge between them, you're going to build a lot more confidence and trust in what you're doing.
And you're also going to adapt to the moment. I mean, I've run ad tech businesses at Amazon where very tiny team, $100 million revenue business, and we did so much so fast. I've worked in cutting edge e-commerce B2C, but I've also worked for Tesco managing product management for warehouse management systems where you've got thousands of employees who need to be trained. You can't just randomly change the interface. You can't do A-B tests on the interface when people haven't been trained of an hourly worker or how they're going to work it. I've worked in B2B SaaS systems where we're mission critical for our clients. They don't take kindly to failing no matter fast or slow. So depending on the context, you need to use the right tool for the job. And you have to focus and read the room, read your stakeholders, read your clients, understand their tolerance for pain versus gain, and then you're going to make better decisions.
Melissa - 00:45:28: So Sean, if you were to give some advice for product managers out there, whether they're in the EU or in the US and they're saying, sounds like me or my people, where do you suggest they start when it comes to learning how to get better about the business and understanding that better? Some people always ask, like, should we do MBA? Should we do that? What could you do today to start getting smarter on that?
Sean - 00:45:49: So the first thing I'd recommend is pay attention to your internal sessions from the exec. If you're a publicly traded company, you have a wealth of information that is published that says, here's our strategy. These are our goals. Read the cover letter to shareholders in your manual report. What are the first five things mentioned on page one? You're going to start to get a very quick sense from the senior execs of what matters as outcomes. And then you can ask, okay, how does my team contribute to any of these? Do we contribute to anything at all? Maybe we have that in a different way, but I ask that. If it's a privately held company, think about your town halls that the exec may share on hopefully a quarterly basis at least. And what are the first few slides when they say, how's the business doing? Are they talking about customer growth? Are they talking about net promoter score? Are they talking about cash flow? Are they talking about churn? What are the language and words they're doing? Because that's what's top of mind to the CEO, the CFO, the COO. And then you can... You can ask, how do we connect to it? So the first is to be curious about your own business. Second thing that might help, whenever I join a new place, I like to get people, back when we used to meet in person, a piece of paper and a pen. I'd say, draw from your business. How do we make money? Starts with customers and then pain and then this team and this team and then this and this. And they'll put themselves on there somewhere. By the way, no matter who you talk to, they always put themselves in the center of any of these diagrams. But get a sense of how do we make money? And if you're unsure, be curious and ask. Ask people to draw for you to business.
Melissa - 00:47:20: I think that's such great advice for our product managers listening out there. Thank you so much, Sean, for sharing your experience and all your thoughts with us. If people want to go learn more about you and read all your fabulous articles, where can they go?
Sean - 00:47:32: LinkedIn is the best place to find me.
Melissa - 00:47:33: Okay, we're going to definitely put all those links to Sean and where you can read all of his blog posts. On our website. So go to productthinkingpodcast.com and we will have them all linked there. Thank you so much for listening to the Product Thinking Podcast. We will be back next Wednesday. If you like this episode, please hit subscribe. Make sure that you never miss an episode on another Wednesday. You can also find us on YouTube, Spotify, wherever you listen to podcasts. If you have any questions for me too about product management, go to dearmelissa.com and let me know what you're thinking. I'll answer them on an upcoming episode. Thanks again, and we will see you next week.