Matt Feczko is director of product operations at Ocado, the UK grocery technology company whose warehouse robots and delivery automation now run for retailers including Kroger in the US and Coles in Australia. He spent the first half of his career as a customer-facing product manager, starting on SharePoint and Office at Microsoft before moving to the UK to join Skype and then four different startups over six years. A LinkedIn recruiter's typo — dropping a comma from his job title — led him to Ocado three and a half years ago, where his remit has since expanded to cover both product and engineering operations. Talking to host Randy Silver backstage at MTPcon London, he explains how he replaced Ocado's roadmap planning process, rebuilt its Jira taxonomy from scratch, and built a product management skills framework that other functions have since copied without being asked.
Key takeaways
- Ocado has way too many roadmaps, the team rebuilt them by hand every quarter. Before Feczko joined, product teams spent two months of every three-month cycle remaking roadmap slides in Google Slides, with no shared document explaining what the company was building or why, and no way for anyone outside the planning meetings to weigh in.
- He traced that chaos to a single root cause: an inconsistent Jira taxonomy. Different teams used "epics" to mean different things, some nesting parent epics inside parent epics, so there was no agreed definition of what a feature or an initiative actually was. Feczko fixed the hierarchy first, using Denise Tilles and Melissa Perri's book Product Operations as his reference, before touching the roadmap process at all — his team nicknamed the project the "Jira Revolution".
- The hard part was getting roughly 3,000 developers to adopt it. Feczko frames that adoption problem as the actual job of product operations: changing how a large organisation works, thinks and describes its own output.
- Two years on, Ocado has replaced its quarterly roadmap slide decks with an internal app, built on top of Jira data, and Feczko is aiming to run the next planning cycle with zero slides. His team also worked with finance to translate operational metrics — such as items added per basket, or driver deliveries per shift — into the financial value each initiative is expected to produce, so planning conversations use the same language as the business case.
- To answer a question Ocado's product managers couldn't answer for themselves, what "good" looks like in the role, Feczko built a 12-skill framework across four themes, including execution, influence and strategy. He combined an existing Reforge framework with his CPO's own view of the job and his own 15 years of experience, then spent six months negotiating the exact wording with the wider team before any of it shipped.
- The skill Feczko insisted on calling "storytelling and evangelising", over his CPO's preferred "effective communication", has become the framework's anchor. His argument is that the ability to tell a clear story about a product is itself evidence of every other skill, because it requires command of the data, a defined strategy and the ability to prioritise.
- The framework's real test came when other functions adopted it unprompted. Engineering, roughly 2,000 people, built its own version, as did design and data — keeping Feczko's four themes but writing skill definitions specific to each craft. That took total usage from around 150 product people to roughly 3,000 across the wider organisation.
- One skill, product adoption, was added specifically because Ocado's product managers didn't see driving adoption as part of their job — they considered their job done once a feature shipped, and expected the business to work out how to use it. Feczko flags this as a gap worth checking for in any company's own skills work, whatever it ends up being called: he expects most will need their own version, along the lines of "value realisation".
- Feczko's rule of thumb for when a company needs a dedicated product operations function is somewhere around 30 to 40 product managers, though he says the pressure shows up earlier: even at 10 people split across teams, a cross-functional roadmap with real dependencies is where the gap first becomes visible.
- Asked what to do first, his advice is to resist fixing everything at once. Product operations, he says, is the "connective tissue" of an organisation: find where there's tension, solve that one problem fully, then move to the next — because switching between half-solved problems just turns the job into whack-a-mole.
Chapters
- (00:49) From computer science to Microsoft PM
- (02:02) The Skype mafia
- (02:58) What Ocado actually builds
- (04:38) How a LinkedIn typo led to Ocado's product ops job
- (07:14) The minimum viable bureaucracy problem
- (08:14) The Jira Revolution
- (11:46) Killing the roadmap slide deck
- (12:58) Translating metrics into value
- (14:43) Building a skills framework for product managers
- (17:52) Do skills differ across platform and customer teams
- (19:40) Storytelling and evangelising as the master skill
- (20:38) Using the framework for promotion and fairness
- (22:29) Scaling the framework to 3,000 people
- (23:43) How universal is the framework beyond Ocado
- (24:53) Vibe-coding the skills tool with AI
- (26:34) When does a company need product ops
- (28:24) Product ops in the age of vibe-coded apps
- (29:58) Product ops as the connective tissue
- (31:37) Proving the value of a thankless job
- (32:46) Bringing Ocado's product community together
- (34:35) Wrap-up
Referenced
- Ocado — https://www.ocadogroup.com
- Product Operations: How Successful Companies Build Better Products at Scale, Melissa Perri and Denise Tilles — https://www.amazon.com/Product-Operations-successful-companies-products-ebook/dp/B0CKFKX94Z
- Reforge — https://www.reforge.com
We're refreshing The Product Experience and want your input. Take our two-minute survey and help shape where the show goes next!
Episode transcript
Matt Feczko: 00:00
I was just really passionate about trying to make it fair for product people and to also convey what I believe and I have learned over the last 15 years are the skills that are important, regardless of AI, right? All these things, AI doesn't change the requirement. AI is just a side bit. You still need to be good at storytelling, still need to understand the data, still have to be good at prioritizing.
Randy Silver: 00:26
Matt, we're backstage live at Mind the Product Conference here in London. It's great to have you here. How are you doing? How's your day been?
Matt Feczko: 00:32
Uh fantastic, actually. It's been a really great day. Some um really wonderful talks from this morning that were super interesting and excited to talk to you. Fantastic.
Randy Silver: 00:41
So for people who don't already know who you are, give us a quick introduction. What are you doing these days and how did you get into this world of product y stuff anyway?
Matt Feczko: 00:49
Yeah, so Matt Fezco, obviously American, uh like yourself. Could be Canadian. Could be Canadian. Secretly Canadian. Secretly Canadian. No, I have so much urgency in my voice. Obviously, I'm from adjacent to New York. Uh no, I'm from Boston. Uh, I've been in the UK for 12 years, and I've been a product manager my entire career uh after graduating from uni.
Randy Silver: 01:10
How did you manage that?
Matt Feczko: 01:11
Uh I mean, uh, that's a very long story, longer than we have now. Um, but I studied computer science. I was uh I'm a nerd at heart. I loved building and making things as a kid. I learned to program when I was 10. Naturally, I went to school for computer science because it just felt like the right thing. And then I was, I don't want to say lucky, but uh fortunate to get a job at Microsoft uh way back in the day working on one of the sexiest products, SharePoint. Ooh, it's the sexiest file explorer. Well, I mean, I did work on Office after that. So, you know, new open and save is a very important feature. Uh so no, I was I worked as a program manager at the time, is what we called them. I worked in SharePoint, Office, and then I moved to the UK to work for Skype, uh, which uh I think is beloved in uh all of our hearts.
Randy Silver: 02:02
And there was a real big Skype culture. There, the people who worked at Skype out of the UK office, there's kind of a mafia of those people that still persists to this day.
Matt Feczko: 02:11
Oh my god. Um I was a bit of the later cohort, so after the acquisition of Microsoft, but I can still like that community is still quite strong. Um, and then when I when I left Microsoft, I had the decision, I had the option to move back to the US uh or stay in the UK. Um, I loved London, I love the access to the rest of the world. Uh this is before Brexit, obviously. I know. And uh, but then I said, you know what, I want to try my luck in startups. I never worked in a startup environment, I've always been in a big company. And I thought, okay, this would be a great place to learn. It'll be interesting. Microsoft was chaotic. Startups would be, I thought, more fun. And uh little did I know that uh very, very, very different space. And I had a lot to learn over the next kind of six years at four different startups.
Randy Silver: 02:59
And now you're back in the world of larger companies, not as big as Microsoft, but Okado is one of those companies that everyone in the UK knows because it was a consumer-facing brand for a while. It's gone back into the B2B world now.
Matt Feczko: 03:13
Just explain to for anyone who doesn't know what Okado is, what what do you guys do? So Okado, I I love saying I work for Okado, especially in like a conference like this. Everyone who is from the UK is has a response of, oh, oh, so nice. Yeah, the vans. Anyone in Europe is uh what? Who are you talking about? But actually, I I work uh and our company is uh around maybe 4,000 employees. I think it was 5,000 a couple years ago. Um, we build the robots and automation hardware for groceries around the world. And so we supply technology to big grocers like Kroger in the US, Kohl's in Australia, but we're also in South Korea, Japan, Europe, Canada, et cetera. And we make basically like little wallies. That's probably the best analogy. If you if you haven't seen it yet, watch the videos. I love the fail videos. Oh, they're so sweet. When when I went up to the uh like the booth to see them for the first time, and there was like one guy or gal or it or they on its side, the other ones were just circling it. It was like the saddest thing. Uh, but no, no, it's really, really impressive technology where it enables grocers to uh deliver groceries uh at a much cheaper cost than doing it in store. But over the years, we have built up our proposition to not just do big robots, but we do delivery from store. Uh we cover the whole journey from the customer experience to shopping online to the last mile to the driver delivering it to the doorstep.
Randy Silver: 04:39
So, Matt, before you joined Okado, you were a customer-facing, business-facing product manager, B2B, B2C product manager. At Okado, you're more on the dark side of product ops.
Matt Feczko: 04:49
I have never heard product ops being called the dark side. I uh I think I'll own that, right? Star Wars themed. Um, so yeah, so I was working at a company called Manual. I was the head of product, operations. So I was responsible for everything from the pick and pack to the account management. And I got a LinkedIn message one day from an Ikado uh recruiter for a role for head of product ops. And basically, the email was all about this role that I had never heard of. I was like, oh, there's like an actual function designed to try to improve the product management experience. I loved Ikato, as everyone who lives in the UK does. Uh so I took the interview just to find out. And it turns out the recruiter just she searched and it just stripped the comma from my title. So head of product comma operations is head of product operations. Uh she told me about the role. She said, okay, you're gonna help the product team, you're gonna help like figure out how to build a roadmap, prioritization. And I said, No, no, that's not me. I ship features, I ship software, I work with customers and users. And she said, Why don't you just have a chat with this guy, Steve? And I said, Fine, fine. Always take the chat. Uh Steve has been working at Akado uh and still there for like 23 years or so. Started out in uh in the ops. Uh, I think I don't know if it was a grad scheme, but he was in the fulfillment center. And he and I just got on like a house on fire. Uh just really respected him. I really respected his commitment to the company, to the problem space, to the evolution of his role changing, him cutting into product. And he convinced me to interview. Uh and then three and a half years later, uh, yeah, still there. And recently my my remit has expanded not just from product, but we've renamed it to product and engineering ops. Because what I'm seeing, and I think this will change in the industry, you're only as effective if it's both halves of the delivery mechanism. Like, what are you doing? Why are you doing it? How are you doing it, and how do we make it actually possible?
Randy Silver: 06:48
So yeah, if we tell people what to build and it doesn't get built, we lose all our credibility and nothing gets done anyway. So and engineering needs some support.
Matt Feczko: 06:57
Yeah. Like they're often said, go and do this, but they have to figure it out. And and having a function that allows them to move faster, to move better, it's exactly the same as product, right? Um, they just didn't have that defined. So, yeah, so that's that's what that's what what I'm what I'm doing now, and it's been quite fun.
Randy Silver: 07:14
Okay, so let's just get into a little bit about product as ops because this is a tough one sometimes because as teams scale, I I work with lots of teams that get to the problems that come with scale. So communication and collaboration and prioritization at scale are really hard things, and they're harder to they're hard to do within the product function alone, let alone communicating out to other people with a common story. And the problem is that we all want to work in the ways that are best for our teams. And AI makes it even worse. Absolutely. But we need a minimum viable bureaucracy. There's certain things that are non-negotiable that we have to do the same way, even though we may constrain our team or it means that we're doing things twice sometimes because we need to be able to communicate at certain levels. But we all use Jira in different ways, we all do roadmaps in different ways, we all prioritize in different ways. How does this actually work? Because how do you avoid product ops just being a PMO for a product?
Matt Feczko: 08:14
Yeah, and it's a it's a big thing. And I can give you the example of like when I joined, like the ask was, hey Matt, can you help us build a roadmap? And I first thought, okay, so there's 350 people in product, like 3,000 developers. You spend hundreds of millions of pounds a year on RD, and you don't have a roadmap? Like, how did we get here? Uh we have lots of roadmaps. They do, they do. And at the time, actually, Icado had roadmaps, and they were all, and I say this to everyone, they were made in slot Google Slides. Every quarter, they would spend two months of every quarter making slides of the roadmap to share out what our strategy and what our roadmap and our and our vision would be. So one month of actually doing stuff. I hope so. I mean, who knows? Maybe they were just like, you know, just skiving off. Um, this is before AI, so who knows what they were doing. And and if you weren't in the meetings, like if you weren't in the product planning meetings, you couldn't actually voice your thoughts on the roadmap. There wasn't a document to describe what we were going to do and why. I mean, it was basic, basic things. And I think at the time CPO had the intention that I would help to, and my team would help to like just operationalize and fix it and make the slides better, right? Or make like not have to redo it. But but the symptom, and I think that's what's interesting about product ops is product ops people are product people. Yes. We are trying to understand the problem, the actual problem. And and I think what's nice is try to determine a solution and then try and implement the solution. And that's actually what has been so fun. I guess I would say being on the dark side, because you kind of have the power to then make it better. Now I think product ops people are different. Um, I am in the insights world extremely yellow and red. So I have all of the uh extroverted energy and kind of decisiveness. But you have other product ops people who are like hands-on on the ground, blue and green, who can actually help individual teams move on. So, with my world, I looked at what they were using with Jira, and it was just a can't swear, what a disaster. Let's just I mean, beyond belief. There was no consistency, there was no, this is what a feature is. Like I said, okay, how do you use epics? Epics had, and if you know Jira nomenclature, epics had parent epics and they had parent epics, and depending upon the team, that team used epics in a certain way. And so, kind of like a dictatorial tyrant, I came in and said, nope, absolutely not, nope. This is the structure we're gonna follow. I fortunately backed it up with um Denise Thiels and Melissa Perry's book, uh Product Operations, which I had to read because I just started the job. It tends to figure out like what do I do? Uh and there was a page that was about the hierarchy. And I was like, oh my God, this is why we have a problem. This this is literally the issue. It just makes sense. Why don't we do this? We don't have a hierarchy. We didn't have a concept for a high-level initiative, we didn't have a concept for what a feature is. And so we worked and we created this side of movement that we called the Jira Revolution. And we worked to try to get the teams to change their ways of working. And so the thing during that journey, it took a long time. The hard part wasn't coming up with a solution, the hard part was adoption, which is what product is. How do I get basically 3,000 people to change how they how they operate, how they work, how they think, how they describe their work, how they share their work, how they prioritize their work. Um, and it's still a journey. I think we're much better than where we were. But I mean, God, back then it was like I mean, it's the third world.
Randy Silver: 11:47
Okay. So you said when you joined, people were spending two months out of three just planning making slides. Making slides. What does it look like now?
Matt Feczko: 11:56
Oh, now. Now, now is so much fun. I mean, we can we can say the buzzword AI, but uh now all Jira data is correct. So we have uh we're still evolving it. I think the important bit about governance is you allow it to change with the way that you need to operate. The key thing for us as a business, ACODO has a goal to get cash flow positive. We've talked about it at our earnings recently. So in order to do that, we need to be clear on the investments that we're making, why we're making them, and what value we think that they'll bring. So we now have clear delineation of initiatives. We know what these things are going to bring and what value we think that they're gonna provide to us. We know how much we've spent on it. Uh, and then we can talk about those on a uh every six months. So my team and a number of other teams have vibe coded apps on top of Jira data. And actually, I'm planning on in the next governance cycle to not have any slides. Slides are dead for product planning. Okay. We have an app. You just walk through the app that shows your data. The data is your source of truth, and it should tell the story of what you're doing and why you're doing it. That's it.
Randy Silver: 12:59
And I'm curious because one of the challenges we want to standardize things at a certain level, but we also want to enable people to work the way that they work, the thing that works best. So is that is AI enabling people to just work however, as long as there's and it it imposes the structure for them?
Matt Feczko: 13:17
Yeah, so you've said it yourself. Like, what's the minimum viable? Right. And that's what we think. The minimum viable are those minimum fields. Let's just go with Injira. You need filled in so that you can tell a story. And I think it's an interesting discourse because ultimately, if the if the standard value is how much is this feature going, value is this going to drive? As product people, we don't think in that terms. We think in how do we think this metric is going to move? Right. How much are we going to move the ability for drivers to deliver, you know, more than just 22 or 20 orders in an eight-hour shift? Or how many customers are going to, how many items are they going to add to their basket? If we show them something new and exciting, this new ice cream flavor, which shout out, I think I had the chocolate Guinness Jude's ice cream. It was out of this world. And I didn't need to, but I added it. How do we then like, how do we translate those metric movements into value to then articulate what we think all of this accrue is going to provide? So my team's been working with finance, which is great, on how we translate metrics to value. You know, what does that metric tree look like? How do we talk about it? So, Product Ops, my job is to make that easier so that we can all speak the same language, and that therefore they spend very little time with bureaucracy and more time talking to developers, talking to customers, figuring out what they're going to do, validating their assumptions, rolling that feature out with new people, doing product.
Randy Silver: 14:43
So you've also developed a set of skills, a framework of skills around this. Tell us a bit about that.
Matt Feczko: 14:50
Yeah, so what I love about my job, and I have saying to you before, what I love about my job is I can solve and I can work on these big problems that I see in the organization. Uh, I am, I would say I'm a cost center, but I think we are very valuable because I am a force multiplier. Uh, we have solved the roadmap problem. Okay. We have solved uh the like the financial uh valuation problem. And one of the things I wanted to solve around two years ago was the skills, the people problem. You know, we would have, we're a big company. At the time, we had 300 product managers. And I came from my early career at Microsoft, we had hundreds of them as well. And what I liked at Microsoft was they had this performance management system where you could self-reflect and you could get feedback. But what they didn't have was as a product manager, what am I supposed to do? And that has been the age-old conversation of what is my job. And I have thought about this, I have been a PM at 10 companies, maybe it's eight, eight, the round up to 10. I've worked with so many different teams. I have worked in different functions geographically in the US and the UK and in Europe. And the key thing for me is trying to articulate to Akado what are the important skills that they need for a PM to be successful. And so I took on a project a year and a half ago. We had a little bit of a work, we were going through some reorg or something. And I thought, you know, now is the perfect time. Let me take a step back and try and solve this problem because everyone deserves to know where their career should take them and what skills that they should work on. And so I took a combination of an existing framework on a platform called Reforge. Um, and I also interviewed our CPO and I said, tell me what you think is important for product manager here to be successful. And this is all kind of without AI. Like I did all of this. I think at the beginning there was like chat. We did used to be able to do these. Yeah, I was like, Oh my God, I actually did my job without this. Is pretty cool. Yeah, I did my job without it. And I overlaid what he said, what I'm hearing from people, my own experience, what I've seen in the market. And I essentially created a framework with 12 skills across four themes. So three skills per theme. They cover everything from like execution, influence, strategy, uh, skills like storytelling and evangelizing, skills like problem solving, prioritization, uh, leading with data. And we created specific definitions. And I created a really high-tech Google spreadsheet where you would be able to track your own perception of your own skill. And then the manager, your manager, would also give you a score. We'd overlay it on a radiograph, and then that would be basically what you can aspire to, what you can do. And it's a the point of this whole thing was so that the manager and the IC had a conversation. At the end of the day, it's about the conversation about how I see myself, how you and my peers see me, and where I want to take my own skills in the future and moving forward. And so, yeah, it's been, we've been running it now for two years, and it's a game changer.
Randy Silver: 17:53
Okay, let's talk to dig into this a little bit because it's not the specific skills and the definitions that I think is the real challenge in most companies. Although I see when I've done this with other people, I find that there's very type A people who fixate on every single word and definition and say this. And the chat, well, actually, let's stick on this for a moment. Yeah. The challenge in that is you've got teams that do fundamentally different things. Yeah. From a topology standpoint, you've got platform and enablement teams and customer-facing teams, and the skills they need are different. So a senior product manager versus a product manager in a platform team will need different skills versus in a customer-facing team.
Matt Feczko: 18:32
Yes, I think if you're a hardware engineer, if you're a hardware, like it's true. We try to make the skills generic enough, something like domain experts. Yeah. Right. So depending upon if you're a growth PM running experiments and trying to like growth hack and see the changes versus you're a hardware PM building robots that take five years and you need to understand the PL of how much you're going to spend from the external costs. Those are two very different things. That said, domain expertise is relevant to both of them. So we tried to take the skills, and to be honest, that took about six months to come up with the agreed language. Fortunately, I'm so relentless and nitpicky that I was not happy until basically everyone in the organization was happy with the skills breakdown. And it could work for our whole split of people.
Randy Silver: 19:20
So the the the secret there though is they are specific in their intent, but not specific in their application. They're interpreted for each team as relevant. Yeah. And that's what I've tried to do in the past is it's more important the philosophy of the skill rather than this is exactly how you demonstrate success at it universally across this company.
Matt Feczko: 19:40
And it's not perfect, right? I think it's pretty good. Um, but like for instance, for me, I personally think my, and this is because this is about my identity, storytelling and evangelizing, which is the skill I think we wanted, they wanted my C E PO wanted to call it effective communication. And I was like, eh, nope, it has to have some flair. So storytelling and evangelizing, I think that is one of the most important skills because it actually summarizes every skill. If you can tell a story, you've led with data, you are a domain expert, you can prioritize, you have vision, you have clarity, you have problem solving because you can explain it in a story. And so, yeah, the the hard bit was not come well, six months of coming up with the list, but then also convincing everyone to do it, to follow it. But I am nothing but not relentless. So I got 150 people in the organization to do it, to just run through the skills assessment and give themselves scores. We had 100% completion.
Randy Silver: 20:38
Fantastic. Yeah. Let's talk about how people use it. As you said, it's the the purpose of this is to have a good conversation between the manager and the the staffer. Yeah. And that is critical, but where I usually see this is it gets turned into something around reward and promotion as well. So how is it used? How do you uh approach that?
Matt Feczko: 21:00
Yeah, it's an interesting one. So my approach originally was let's focus this on not reward and promotion, but we we'll get to that. But the key thing was to have a consistent framework because what I saw, what I didn't mention is when I had interviewed product managers and said, How are you being assessed for your skills? They all showed me a different document type. Miro, Google Doc, Slides. And I was like, this is how do you move between teams if you're asked and expected to do different things? So that was part of the reason was consolidate the way we do things. Um, naturally, once you have this framework, it's useful to use this to understand promotion. And actually, it has been helpful. We have used it about promotion because it makes promotion fairer across the whole organization. Beforehand, the way the promotions would happen is if you had a manager who was just super on it, they would get their people promoted and the other managers who aren't wouldn't. And so you have this disadvantage between the ICs who think that they should be, but then basically their managers. And pushing for them. If you have a consistent framework for how promotions works against a skills matrix that is consistent, then all of a sudden you have so much more fairness and transparency.
Randy Silver: 22:10
Yeah, I can't tell you the stories. Well, I could tell you the stories, but uh around working in large organizations where managers pulled me aside and said, okay, this is the secret. You have to create relationships with all of my peers, because if you don't have those, then I can't win the argument for you in the room. So I know you're good, but you have to help me play this game.
Matt Feczko: 22:29
Yeah, there is, you know what? There's always going to be a bit of a game in some respect. I think the framework helps to make it fairer. And I think the thing that I'm most proud of around this whole thing is that I was just really passionate about trying to make it fair for product people and to also convey what I believe and I have learned over the last 15 years are the skills that are important, regardless of AI, right? All these things, AI doesn't change the requirement. Uh AI is just a side bit. You still need to be good at storytelling, still need to understand the data, still have to be good at prioritizing. But the success of this framework has been the fact that engineering, 2,000 people, they took my framework and they made it their own. Uh data did the same thing. UX did the same thing. So they basically saw what I, we, were doing in product and said, hey, this model works. So we went from a group of 150 people with a framework to 3,000 people, all now have their bespoke frameworks for their craft.
Randy Silver: 23:27
How different are they?
Matt Feczko: 23:28
They're there, you know what we did is the themes, the for the three skills per theme, um, those are the same. So execution, influence, um, but the skills themselves are different and are specific to the crafts, to the disciplines themselves.
Randy Silver: 23:43
Okay, so you're doing this across product and engineering as well as design and really functions. These skills, they don't seem to be very specific to the product development teams. There's, you know, I've long held that good product management is just good management, period. How universal is this to potentially the rest of Ocado and to other companies?
Matt Feczko: 24:05
I think it can be adapted. There are some specifics. So, for instance, we made a deliberate focus on one skill being about product adoption, that being a specific skill we want product managers avocado to focus on. And that's because product managers didn't believe a cado their job was to do product adoption. They thought their job would be to deliver features and the partners would just adopt it themselves.
Randy Silver: 24:29
So get stuff into production and that's it.
Matt Feczko: 24:31
Exactly. Or like I sent an email to Doreen, Doreen now will just do it with her customer. And actually, we want them to be able to use it to track it to see the impact. I believe that that will evolve from there. But this is right now what we saw at Okado was a gap in the skill set.
Randy Silver: 24:47
So you can rename that to value delivery, value realization, or something like that, and interpret it in different to give different context. Exactly.
Matt Feczko: 24:54
And I think that will be the case. But to answer your question, I do think it can be generic. Um, the death we have definitions of each skill, and they are very, we have the specific Akado definitions of what they mean and how we relate to the word partner and our customer. And so we try to apply a slightly bespoke lens so that each product manager can just read it and understand. What I haven't done, and I'll admit, uh, is AI the shit out of it. So, like, you know, I'm gonna probably in the next couple of months take the tool, throw AI onto it, make it into a vibe-coded app, you know, do all that stuff, have history and trends so you can see what the organization is doing, anonymize, and you can kind of work towards that and link out to sources. I think once you have the model and the foundation, all of these extra magic and things has become really quite easy and can be quite fun.
Randy Silver: 25:46
Yeah, the tying data into uh my hypothesis and my manager's observations, even if it takes a while to get there and say, I wonder what are the correlating things, I wonder what are leading and lagging metrics on this. Oh my god. And just helping say these are things that your peers are doing that you might consider, things like that.
Matt Feczko: 26:05
And the power, I think, also with with what big data gives. So, you know, look in Slack and see what people have done. What have I done? Where have I promoted? Yeah. Have I not actually celebrated my own successes and things? The documents that I've written in Google Drive, look at all of them. How is anything missing and should I be sharing that? What skills does this relate to? And based on my own profile, would you give me recommendations? I mean, all of these things now become super interesting uh for the development of product people that I think is, yeah, like if not, it's still super important.
Randy Silver: 26:34
Okay, so you went from Microsoft to startups back into a large company. Small companies probably don't need this function. Not in there's a certain scale that you need to be before this becomes a remote. But about how big do you think you need to be before ops becomes something you need to seriously devote time, uh uh or not just time, actual headcount to yeah, product like product operations, yeah, product and sharing.
Matt Feczko: 27:01
I think it's an interesting one because I think depending upon the personality of who you've hired, they'll play that role. And someone has to figure out how you're doing it. I think when you get to like over 30 product managers, or or if you are geographically distributed or culturally distributed, where things become harder, I think it's interesting to at least invest in some percentage of someone's time on the ways of working and the waste that happens by this like level of inefficiency. I mean, Ocado desperately needed it. Um whenever I am out with coworkers and people have been there for a while and they get a little bit tipsy, they always say, like, oh my God, thank goodness you joined. You know, the chaos before you was ridiculous. Um, so yeah, I think I think around that mark 30, 40 PMs. But even at the 10 person, where you start to split team and split team and split team, when you're trying to build a cross-functional roadmap where you have dependencies and all of a sudden, like you don't know how you're going to build what you're going to build next because you can't figure out the car before the horse. Ask the questions of what's needed for product ops and then implement it yourself.
Randy Silver: 28:13
Yeah, I think that the the difference being with 10 people, 10 teams, you should be able to do it without an external headcount, an extra headcount, but 30 to 40 teams, you're starting to get to a different thing.
Matt Feczko: 28:25
And I'm I I and one thing that's interesting is I don't know how AI is going to change this because one of the talks today talked about, you know, AI slot that is being created. I'm thinking even internally, we have the number of vibe-coded apps. I mean, I have I own three or four apps that I create. Um, the management of those But those are all quality. Oh super high quality. The 5,000 lines of code in App Script that I've read every line of. Um, but but through that, like how product operations actually will become more important because how you manage the builder aspect, now that everyone's a builder, how who helps those builders share, uh, improve? Like, I think that's going to be a very interesting product ops function that is like ripe.
Randy Silver: 29:09
Okay. And you got started in this case mostly with by uh by uh uh playing good cop, bad cop on Jira.
Matt Feczko: 29:16
And to say if I I'm only known I'm like, you're the Jira guy. I'm like, oh my goodness, I'd love to be something more than just Jira guy.
Randy Silver: 29:23
But this was your way into starting to fix the problem. So roadmaps is an issue. This that that's the symptom. The underlying issue was lack of data consistency in Jira. Fix that and things get easier. Yeah. Let's assume that's not going to be the case or the best way in every company. But what's the somebody starting to deal with this in their organization? Uh they're seeing the problems. What's the question that they should be asking first to saying, right, we need to get started, we need to get really serious about this. Which is just a good place to start, aside from yes, obviously Jira consistency.
Matt Feczko: 29:58
You know, okay, there's fundamentals. Uh the book I mentioned, Prop Operations, is quite good because it describes like the different difficulties that functions have. In that book, it described the enterprise problems. The enterprise blew up. So my our business blew up, so the roadmap was confusing. But you might have a different version, which is we don't know how to do analytics well. Or we don't understand how to incorporate customer research into a better way, or we don't have a clear sense of what product is expected to do, which engineering design, et cetera. I think the question to ask is what are we missing? What are our blind spots? And where are there opportunities that we could change the way of working? At the end of the day, product ops or product and engineering ops, I see it as the connective tissue in an organization or an organism. You cannot move without all of your fascia, the plasm that allows the muscles, the bones, the skeleton to stride. So find out where there's tension in that organism and figure out where is that tension coming from. That to me, product ops, finds the tension and solves the tension. And then, like as anything, as you age, this new tension. So you find where that one is. It's a little bit like whack-a-mole, but I actually think that you solve, you do solve each problem as you go. And anyone who is in the field, like my number one advice is don't do everything. Like just good product. Do one thing at a time. And just try to make sure that you've really solved the problem. Because if you just try to keep switching from one to the other, then it literally is wakamon. And you'll never actually get to the finish line.
Randy Silver: 31:37
Matt, this has been great. I think I've got time for one last question. So then you were just talking about how this is you're describing this is almost a thankless task. There's always something else. So, how do you celebrate success? How do you communicate the value of the work you do? As you said, you people get drunk and they say, Thank God. That's not necessarily the thing that you want to uh hang your hat on as the most it's nice, especially if someone else is buying the rounds. But what is the thing that you're doing day to day, you and your team, to say, look at the value of our team?
Matt Feczko: 32:10
So it's an interesting one because the question that you're also not asking is like, how do you prove value for product ops? Because it's often hard to see the metric changes in like what? What is the metric? That we've prioritized the roadmap, that we've built the right thing, that people haven't quit. You know, is it retention? Um, and interestingly, when we post on Slack or we do a thing in a video, the number of emoji reactions might be a certain number. You know, if someone else shares a photo of their cute dog, they're gonna get like four times it. So does that prove our value? I have learned.
Randy Silver: 32:44
So we're crew product managers with cute dogs.
Matt Feczko: 32:46
Well, I have a I have, by the way, I now have a six-month puppy. That is very easy. She is adorable. Um, the way that I've now solved this is that is my my key thing, uh, and I and I tried for three years, I finally was successful a couple weeks ago, was bringing all of product together. When I joined three years ago, we had 300 people, 350, and I said, I think one of the key issues in a cottage product community is that we have grown organically over COVID and we have become isolated in our silos. I want to bring the product community together. Yeah, yeah, yeah. In six months. Six months go by. Yeah, yeah, in a year, six months go by. Yeah, yeah, continue, continue. And my current boss, James, I said to him a year and a half ago, James, it's time, it's time. We're getting together. James, like most of my other requests, he goes, sure, if you figure out how to do it. And uh yeah, we organize, I organized a product day. I brought all product managers from the entire world together, including UX, product and UX, hosted by Amazon, really graciously hosted, and we had an amazing day. And the the question you asked me is, how do I feel that we're our value is there? The Polish product managers who never give me any sense of emotional reaction told me it was the most fun that they had and didn't think that I was gonna be that funny. And I was like, how do you not know me? Of course I was gonna be that funny. But no, in reality, I think it's about bringing the people together and having them learn from each other. It's why I care about the skills, because they can see each other. It's why I care about Jira so we have a very clear roadmap. It's why I care about just clarity uh and sharing. So I think if you can bring your people together and you can have them learn from each other and you can be that that connective tissue, that conduit, it just makes working in your environment and your company just so much more enjoyable. That's fantastic. Thank you so much, Matt. Thank you.
Lily Smith: 34:35
The product experience hosts are me, Lily Smith, host by night, and chief product officer by day.
Randy Silver: 34:42
And me, Randy Silver, also host by night. And I spend my days working with product and leadership teams, helping their teams to do amazing work.
Lily Smith: 34:51
Luron Pratt is our producer, and Luke Smith is our editor.
