Overview
Sean O'Neill talks about why product teams stall even when the company has a clear vision. His main point is that strategy fails in practice when most capacity gets swallowed by one-off customer work, internal dependencies, and too many parallel initiatives.
He also reflects on what he took from Amazon, how those ideas translate into older companies, and why leaders need to be honest about whether they are building a repeatable product business or a bespoke software business.
Key Takeaways
O'Neill's top principle is to "solve real user needs." He argues that the worst waste of capacity is building something nobody actually wants. Close behind that is releasing value in small slices so teams get feedback early, instead of disappearing for months and emerging with a big launch based on wishful thinking.
A third theme is simplification. He says teams regularly overestimate how manageable dependencies will be, then get blocked by one missing piece from another team. That makes simplification less about elegance and more about survival: cut scope, reduce dependencies, and ship what matters.
On strategy, his sharpest point is about capacity allocation. A company may say it believes in long-term bets, but if only a small share of engineering time goes to them and the rest goes to customer-specific commitments, the strategy will lose by default. He describes those one-customer features as a sinkhole that drains the time needed for real progress.
He also makes a useful distinction between two valid business types. Some firms win through repeatable product propositions. Others win through relationships and custom delivery. Either can work, but leaders need to know which one they are running. If you are effectively a consulting and bespoke software shop, you should not expect product-style scale or economics from that work.
Another strong idea is that product-market fit is only the start. O'Neill says companies also need "business model fit" and some form of defensibility. A product that customers like can still be exposed if rivals can copy it easily or outspend you.
Practical Steps
- Audit where capacity goes today. Count how many teams are spending time on strategic bets, migrations, internal support, and customer-specific requests.
- Put the current portfolio on one page. If you cannot explain the work simply, you probably have too much in flight.
- Tag customer requests by expected reuse. Ask whether a feature is likely to serve one customer or many, and decide accordingly.
- Ship in smaller increments. Create earlier feedback points for desirability, feasibility, and commercial value.
- Remove dependencies before launch planning. For each initiative, ask what can be cut or changed so another team does not hold the whole release hostage.
- Run a long-range trend exercise. O'Neill describes working backward from changes that may hit in 10 to 20 years, then asking what the company should invest in now to be ready.
- Review org design as if it were a product. He argues structures drift over time, so leaders should regularly ask whether the current setup still matches the business problem.
Notable Quotes
- "There is no greater crime of wasting capacity than to build something that the universe has no need for." - Sean O'Neill
- "Product-market fit is not the finish line." - Sean O'Neill
- "That is the sinkhole that steals your precious capacity from strategic progress." - Sean O'Neill
Full Transcript
If you've got a poor strategy, are you going to succeed as a business just by doing the tactical feature requests as they come in along the way? You’re probably going to get outmaneuvered by a competitor, because I see companies with good vision and a good business strategy, but they wonder why they don't make enough progress. They are funding usually some of their strategic investments, but maybe that's only 15% of their capacity, and how much of their time is spent on customer commitments that only one customer might be using. That is the sinkhole that steals your precious capacity from strategic progress. Hello, welcome to CPO Stories, where I speak to the UK's biggest and best executive product leaders, as well as some of the up-and-coming stars of the future. If that sounds up your street, don't forget to dive into the back catalogue on your favorite podcast app or on YouTube. And of course, follow, share or drop me a comment or review. It all helps keep the lights on. And if you're a CPO or want to nominate your CPO, do get in touch because I'd love to have a chat. My guest tonight is Sean O'Neill. Now, it's funny because Sean actually used to be CPO back at German research juggernaut GFK, a company I spent 19 years at, although you wouldn't think it to look at me. Now, I left before he started, but all I heard from former colleagues were whispered rumors of a mysterious man in a fancy hat with big ideas walking the corridors and trying to bring some of his ex-Amazon magic to a global market research company. Well, he's since copied me and left that place and is now the CPTO at Synchron and is here tonight to talk about all the things he's learned along the way. Sean, thanks for coming and welcome to the show. Well, thanks for having me. Delighted to be here. The delight is all mine, or maybe it's mutual. I don't know. Well, we'll work it out as the, you know, maybe we'd like a delight. Remember like back in the market research days, you could have a little dial that you could turn as you were watching a show or something. Maybe we'll get one of those and we can see how the delight varies. The pie is growing. It is not zero sum. Now that's a product person, but let's talk about first things first. We, as mentioned in the intro, both worked at GFK, big company. Although as I said, we did miss each other. We've both been gone for a bit now. Obviously GFK has been acquired by an even bigger juggernaut since we were there. But I guess the most important question on my mind is, who do you think our former colleagues are cursing most these days, you or me? Well, it has to be me because I was there more recently. Ah, recency bias, but in reverse, right? Yeah. Yeah, no, I, I sometimes like the sort of sit and think, and well, I wonder how much of the stuff that, that I worked on when I was there is still actually running even in this new world. Oh yeah. Well, you'd be, well, you wouldn't be surprised, but others might be of how did the product that, oh, this is just a band-aid for 12 months might still be running 12 years later. Yeah. Well, one day at the, at the end of all times and the heat death of the universe, there'll still be some batch file running somewhere that's ticking away. That's right. But, uh, and that's just the way it should be. But like I said, we kind of, we missed each other whilst I was at GFK, but actually we did speak a little bit before you left, which was when I was being lined up to talk at that Greek internal tech conference, which was big fun. You were gone by then. But one of the things that we chatted about then, and you've also got it on your LinkedIn profile as well, uh, what you've kind of labeled as Sean's product development principles, which was definitely an interesting thing to go through at the time. And I want to talk about where they came from in a minute, but there were, there were 10 of them and I want to go through them super quick, but we're not going to talk about all of them, but I am going to ask you a product management question at the end. So there's solve the right user need, measure accountability to outcomes, release value in slices, put data in the hands of decision makers, build once, run everywhere, make it cheap to be wrong, build it fast and proper, extreme focus on top priorities, simplify, simplify, simplify, and be credible. So my product management game for you, I'm not going to ask you to talk about all 10 of those things, but I would like you on the fly to kind of force rank and choose your top three most important of those 10 principles and why. Well, probably the first one is the first in the list, solve real user needs. Too many, too many teams are building something the universe doesn't want. And that, there is no greater crime of wasting capacity than to build something that the universe has no need for. So that's a fundamental one. I also think releasing value in slices is another. Too often teams work on things for a long time with no feedback loop and you get in your own confidence bubble that, oh, everyone's going to love this. But if the feedback loop is so vital on whether it's feasibility, viability, or desirability using that IDEO famous diagram, you need the feedback loop to course correct. And then the third one I would pick out of all of that is simplify, simplify, simplify. Too many teams are optimists around dependencies on other teams they might need. They get surprised when that one little story that needs to be delivered by some other team didn't make the cut. And now their entire launch is stalled. Beware of dependencies. Think hard about simplifying. What do you really need to do for this release? Excellent. And we'll get people to sign up to the paid newsletter to hear the justification for the other seven as well in the kind of product-led growth world that we live in. But you obviously spent a chunk of your time back at Amazon starting back relatively early in the Amazon journey a few years after it started. And obviously Amazon these days has almost a mythic quality to it. All these people talking about working backwards and pre-mortems and two pizza teams and all the other things that have come out of all of the thought pieces about Amazon over time. How much does that Amazon history actually, well, how much did it contribute, but also how much does it contribute on an ongoing basis to kind of your product management ethos that you live by these days? Amazon had quite a huge impact on me. So I joined in 1999 and I was at Amazon for 11 years in two stints with a startup in the middle. So a 15-year span from my first start to when I left at the end. And it really did a lot to help guide me and shape who I am as a product manager. In fact, funny story, I was interviewing with Amazon in 1999 coming out of business school with my MBA from Kellogg in Northwestern. And I was interviewing for a couple of different roles and I eventually got an offer from Amazon. And in the offer letter, it said my title would be product manager. I'd never heard of a product manager. And I had to call the recruiter and I was like, what's a product manager? And she's like, oh, you'll be great. It's business. It's tech. It's operations. It's getting stuff done. You're going to love it. And here I am 25 years later, still loving the product side. A big piece of the Amazon background, though, was really being data driven and data focused and get the evidence. Too often teams are optimistic about what they're doing and is it working? When the information might be all around you, you just have to look and check for that. And even those 10 principles that you had read at the beginning that you could find on my LinkedIn page, I wrote those when I arrived in 2014 at Tesco. And I was vice president of product design and analytics for all of Tesco's e-commerce websites and apps around the world. And we needed to figure out, how do we help our teams make better decisions? And a big piece of those principles are how can you help a team in place know how to make a good decision to move forward rather than being blocked and putting down their tools until they find some chance to get into a governance session and ask the right questions. So that's a good principles allow people to make decisions without asking. Which is all very, you know, you kind of think back to some of the stuff that we've all, I mean, I've never worked at Amazon, but, you know, I know yourself and others that have worked at Amazon. Very common from the kind of the thought pieces around Amazon as well. And there's somewhat of a common retort in some circles in product these days that, you know, for example, that all sounds wonderful, but actually that's something that Amazon has had, you know, more or less from the start. There was, I mean, again, we've all read the same books. You were there. And that perhaps you couldn't really take like a big tech or an Amazon, for example, in your case, product leader and just sort of take them out of Amazon and put them into like a non-big tech legacy company that's got loads of tech and organizational debt. And they just magically succeed because there are so many things that Amazon had kind of baked into its culture that actually, if you don't have those things that it would almost be like, you know, trying to run a car without an engine. Is that unfair Well, yeah, but you know, surviving is the first stage, right? I've also seen companies that have strategies that didn't survive. So kind of feels like that there's there's some, there's some kind of linchpin in there somewhere. I don't know if we even know what that linchpin is, but something that kind of, well, I guess almost to try and persuade people in companies that are surviving to, you know, to use your phrase that they could be doing a lot better if they actually just did some of this stuff and focused on, on a proper strategy and a proper vision. Like, have you found a way to sort of square that circle and try and persuade maybe more opportunistic leaders that there's a different way? It's an important question because there are plenty of businesses that have actually been, let's call it persisting. Maybe they haven't been growing as much as they should, but they've been persisting. And perhaps, perhaps that business doesn't depend on product proposition. Maybe that business's real value is customer relations and, you know, having a great access to a buying office and then building that trust on the commercial side. Maybe that is the definition of what that company really needs to do. And they should just build whatever those buying offices, clients need. That actually can be okay, but in that sense, you should understand that you are a consulting and bespoke software company. You're probably not a product proposition company. Both can succeed, but you need to understand which one you are to know how should you price it. And should you expect this feature you built to sell a thousand times or once? That's going to change your return on effort and your return on investment. Yeah, I guess it's that whole thing like you can be one or you can be the other, but don't expect the results of one if you're, if you are the other, right? Because, you know, that's that way madness lies. Well, so I'm a big fan of books and I always sort of book clubs in every organization I'm in. And one of my favorite strategy books is called Seven Powers by Hamilton Helmer. You're checking your bookshelf to see if you've got it there. Yeah, I'm pretty sure I've got it, but, but it's just, it's just buried amongst all the other books. So the usefulness of this book is that many, many people can build propositions and find product market fit. And they think they're done. They've made an important first step, but product market fit is not the finish line. It merely validates that there is a need you have found a way to solve for a segment, but that doesn't mean you can defend that business. You need to also think about business model fit and are you actually able to create some stickiness, some moat around your business that allows you to persist and grow and succeed because you can be plodding along and doing okay, but you are at risk. You are at risk if you don't understand what is happening in your industry. And one additional workshop that I sometimes do with companies is a mega trend workshop. There's a great famous computer scientist out of the Xerox Park research labs, Dr. Alan Kay. And he actually was a mentor of one of my previous CTOs at Tesco, Edmund Mizrobyan. And so I got a chance to meet Dr. Alan Kay. And he did a whole talk for us when we had Tesco. And he had this great way of saying, what is going to be happening in 15 years? What is going to be happening in 20 or 30 years? What major trends are going to disrupt? And then you can start to anticipate, well, if this major societal trend or regulation or privacy or compute or data availability or trade barriers, you do all sorts of projections. And then these major trends, you can ask if this is going to dramatically affect our industry sector or our customer base or our competitive set, what should we be, if this is where it's going to be in 20 years, what does that trend look like in 10 years? And then you kind of work it backwards a bit. And then if that's where it's going to be in 10 years, what should we be doing in five years to be in a position to capitalize on that in 10? And if we want to be in that position in five years, what should we be investing in now to have progress a year from now that will actually put us on the curve? And what's useful about this is you're working backwards from a major disruption rather than waiting until that tsunami swamps you. Well, plus one for the bingo card on working backwards, the Amazon bingo card, right? But, you know, I think it's always important to, to use, use your terminology. But no, I think that that, you know, that whole thing about like, as some people might call that horizon scanners, right? Like what's coming and how do we respond to that threat? And then people start to trot out the Netflix or the, the blockbuster, you know, Netflix blockbuster or the Kodak kind of stories and start to say how they failed to do that and et cetera, et cetera. But, you know, I think you also called out that kind of explore and exploit kind of figure of eight and like just kind of identifying the points where you need to start to, to invest more in certain areas or double down on others. So it kind of feels like having that lens sounds like a good workshop as well, but like just having that lens and, and trying to scenario plan a little bit could, could probably be helpful for quite a lot of companies. In fact, one interesting example that came out of this. So back in at Tesco, this might've been 2017, probably in 2017, I ran this workshop across a wide, probably 25 people across various Tesco functional areas, commercial operations, finance, technology, the online shop, the in-store experience. And we were trying to look at what major trends are there. And a couple of interesting things came out of this workshop. One is everything is being digitized and everything is measurable combined with the rise of privacy of, do you have rights and access to it? And this was specific for grocery, but we had already in 2017, seen quite a lot of what we'd call fragmentation of your shopping basket, where the highest margin items somebody buys were being direct to consumer. So batteries, razor blades, like the, I can't remember the razor blade company that was acquired by Gillette for a billion dollars in 2014 or 2015. So there was a lot of examples of high margin products from a grocery basket that were being broken out for direct to consumer, direct ship to customers. And that is a problem if you're a grocery store like Tesco, because the remaining margin is less to pay for everything else. And out of that workshop, we identified that it would, in fact, one of the great ways to phrase it is it would be ridiculous if in 20 years, we did not have X where at least 20% of the population was doing it. And so we said, 2017, it would be ridiculous if in 20 years, we did not have for consumers, a digital household smart agent. We didn't have anything about Gen AI at that time, but we just said a smart agent who understands all your shopping history, your preferences, what brands substitute you're willing to take, your budget, your price sensitivity, and for your basics, your inventory. And it will never let you run out of coffee or diapers or beer. It will all be surfing out to the market of fulfillers, not necessarily retailers, but fulfillers in some programmatic network to constantly see what the bid and the ask is for who wants my coffee and my diaper and my beer order. And things just show up to the house when I'm about to run out. So you now actually think where we are now, I don't think we're that far away from something like that. But there's also this interesting point of that's not really Tesco's business model. So even though we identified that, there is also a sense of who's got the right proposition because whoever runs a business like that, you really can't be a retailer. You have to be all heartedly the customer's agent so that they completely trust with all of their budget and their willingness to pay and their brand. Now, interesting stuff could probably talk about that for hours, but we're not going to because we have other things to talk about as well. But you recommend again, back to the article, aiming for a small set of active initiatives so you can fit the entire portfolio on one page, which obviously even people from smaller companies might sit there and laugh when they see some of their, you know, 500, you know, 500 page decks or whatever. But obviously generally speaking, there's no kind of controversy over the fact that product people generally like to think that less is more. You put some proper effort into the right things rather than not enough effort into a lot of things. But when you start to talk about the actual size of the buckets, like how many percentage of, again, let's say resource or capital allocation that you put into each bucket, like how are you actually deciding that specifically or what models can you use to basically decide how big each bucket should be or how much you should be putting into each one? Because it's all very well to call out the buckets, but you need to actually decide what goes in there in a way that you can get support for as well. That's right. So let me see if I can break this down into a couple sections. So first, many of these initiatives are already in flight. You're already funding them. So you could just start with, well, what are we doing today? How many teams today are working on some system migration? How many teams today support, you know, our subsidiary business XYZ? So you already have a lot of these in flight. Work is there. People are busy. What you need to do Your company and look at the org and say, why on the world is this team reporting in over here? I assure you, at some point of time, those teams weren't talking enough. And somebody said, I'll fix that, and they just moved them in. So you need to think about an org as a product. It's got a mission. It needs to serve the business to achieve their vision, their strategy, their goals, their outcomes. And over time, organizations should change. They should evolve. When the business question changes, you need to ask, is the org still appropriate? This is a team topology piece. I worked in many different setups. In some cases, there were a CPO, and then there's a CTO and that works fine. In other cases, it might be a CPTO, and that might be appropriate as well for the situation. It all depends. So early on at Amazon, all these business units in Amazon generally were led by someone who either emerged from the engineering organization to be a GM of the business or emerged from the products side to be a GM. And nobody ever really said, Oh, wait, you can't run it all because you're an engineer or you can't run it all because you're a product and not an engineer. Nobody said that because there are so many examples all around you of good, successful Amazon businesses. So what really matters is, do you have all the right resources available to get the right job done? And how can you make sure that everyone is aligned? And some companies over time, it can change. In some cases, the CEO may not be very technical. And if you have a CPO and a CTO and they disagree, who resolves it? Well, you go up to a non-technical CEO. That might not be as efficient. They may not know what the right decision is, but they've got a break tie there. So you need some level of the tie is going to be broken there. Can be a CPTO. Over time, it might not be a CPTO. So the businesses evolve and you've just got to ask, are we set up today for where we need to go? Sounds like there's another strong It Depends in there as well then. I always, and I find it funny when people say, Oh, product people always say it depends. If you went into a doctor and you said, I'm not feeling good. Give me some medicine. What should I take? And the doctor said, it depends. Would you be shocked if they wanted to do some diagnostic tests? No. So it depends what problem you want solved. No, absolutely. Well, obviously plenty to chew on there. I normally like to finish up these interviews with a couple of lighthearted lightning round questions. I needed some questions from members of your team, but I've actually got a couple of listener submitted questions for mutual acquaintance of ours, up and coming associate product manager at mentoring company, Bloom. And their first question is this. Dad, when I told you I wanted to go into product, what was your first thought? Ah, so I think I could recognize the mystery caller is my amazing daughter, Sterling O'Neill, in her first product management job and with a master's of computer science first class from Lancaster University. So Sterling's a rock star. If you're out there, you should, everyone should know that. So initially, when early on, before Sterling decided what she wanted to do for her career, each of these different jobs, I would ask, okay, well, let's think about whether that job is going to be around in 10 years. And we just kind of worked through it until she got to, she'll do a computer science degree. And I said, that sounds great. Because understanding how things are built is a super valuable skill. And even in today's world where generative AI is potentially transforming the way software development happens, the most important question is not how to build it, but what to build. And I think that product question is always so fundamental because there's nothing worse than building something the universe doesn't care for. So you really need to make sure that you have that curiosity and inquiry of what is needed. And I do think product managers, really you could evolve into many different career paths from that around running business units. You could go into commercial paths, customer facing, but understanding how everything is really technology and only going to be more so, understanding how things get built is a valuable skill. So sounds like your first thought was, that's a pretty good idea then. It's a great idea. I love it. Okay, one more question from the same mystery caller. Did you ever see your product management skills show up in how you parented me? Huh, interesting. Well, she does have a younger brother. And I will say maybe we had a controlled experiment between the two to see how they're developing. I will not tell which one is in control and which one is in treatment, but the experiment continues. Well, that's definitely an interesting one for me as a parent myself and as a parent of two children as well. So maybe I should start doing that as well. It's always good to put your A-B testing skills and start to try and tease out some results and see what happens, I guess. Right, well, plenty to think about there and I'm sure that we could talk about these things for hours. But in the meantime, if people want to come and find you and find out more about portfolio programs or portfolio planning, executive product leadership, or come and check out your collection of hats, where can they come and find you? You can find me on LinkedIn. There you go. And there's a bunch of articles on there as well. I'll make sure to link that into the show notes. But hopefully after I've done that, a few people will come running in your general direction and try and find out more. Well, Sean, it's always a pleasure to chat. So obviously, thanks for coming on and sharing your wisdom. Obviously, it's good to hear your stories from Amazon and elsewhere, including even GFK from our mutual past as well. And obviously, we'll keep in touch. But yeah, for now, thanks for taking the time. All right. Glad to be here. It was a lot of fun. Thank you.