The Product Experience: a Mind the Product podcast cover art

The Product Experience: a Mind the Product podcast

The Product Experience: a Mind the Product podcast

Written by: Mind the Product
Listen for free

The Product Experience features conversations with the product people of the world, focusing on real insights of how to improve your product practice. Part of the Mind the Product network, hosts Lily Smith (ProductTank organiser and Product Consultant) & Randy Silver (Head of Product and product management trainer) “go deep” with the best speakers from ProductTank meetups all over the globe, Mind the Product conferences, and the wider product community.

© 2026 The Product Experience: a Mind the Product podcast Economics
Episodes
  • Evals, Analytics, and How to escape the feature factory: Francois Lopitaux (SVP Product Management, ThoughtSpot)

    Evals, Analytics, and How to escape the feature factory: Francois Lopitaux (SVP Product Management, ThoughtSpot)
    Oct 6 2026
    Francois Lopitaux is SVP of Product at ThoughtSpot, the analytics company built on the premise that you should be able to search your data like you search Google. He began his product career 18 years ago, when Salesforce acquired his Paris company, and went on to lead customer service, analytics and AI products there before joining two startups and then ThoughtSpot. He joins Randy Silver to explain how building agentic products differs from shipping deterministic software, from designing without control of the user path to keeping an LLM trustworthy when the answer has to be the same every time.Key takeawaysAI has cut the time to prototype and validate, and ThoughtSpot estimates its development is two to three times faster. Productionisation still needs sound architecture, guardrails and experienced engineers.When everyone can vibe code, discipline matters more. Lepiteau compares fast AI-assisted development to driving a Formula One car on a road built for a mini Austin: the speed is only useful if you can control it.Agentic features are probabilistic, so product teams are now building guardrails around an LLM rather than a fixed step-by-step flow. That means more hypotheses and more testing.Keep the end goal fixed and stay flexible on the technology. ThoughtSpot is now revisiting existing features to see where newly released models can replace what it built with LLMs.The eval system is becoming the new PRD. It defines what good looks like and what must be avoided, in a product where the UI is a prompt and the path can't be predicted.For analytics, where "what is my revenue this year?" must always return the same answer, trust comes from using an LLM only where it is needed and supplying a semantic layer. That layer defines how your business works, so the model behaves less like a new intern guessing at your terminology.Adoption and repeat usage are the metric that matters most, backed by anonymised sampling of answer quality and follow-up questions. Enterprise customer interviews supply the qualitative temperature check.Embedded and white-label products raise the bar on trust, because customers ship the product to their own customers and carry the accountability. Features must be rebrandable and opt-in, with flags so each customer can roll out at its own pace.An AI feature is never finished. Evals are only a guess at how people will use the product, so teams must keep observing real usage after general availability. ThoughtSpot organises teams by product track, which makes that follow-up a natural continuation of the work rather than extra load.Pruning matters more now that code is cheap to generate. Lepiteau's own team has built three versions of its conversational agent, and without cutting back old versions he warns of a monster where every addition breaks something else.Lepiteau still hires technical, curious product managers. For a recent associate PM role, he asked candidates for a Git repo and a video explaining why what they built solves a problem.Execution is speeding up, so he expects smaller teams and a falling PM-to-developer ratio. Deciding what is meaningful to customers is the remaining bottleneck.2025 was about proving AI works. Lepiteau expects 2026 and 2027 to be about proving ROI, so teams should be able to switch models easily and pick the cheapest one that does the job.Chapters00:00 Introduction 00:48 Meet François and ThoughtSpot 02:55 How AI is changing the product development lifecycle 05:18 Why discipline matters more in the AI era 08:00 Building probabilistic features 09:43 Why evals are the new PRD 13:57 Building an eval system for agentic analytics 17:15 Creating trust with a semantic layer 19:30 Measuring the success of AI products 22:12 Trust in embedded analytics 24:19 Go-to-market for white-label and OEM products 26:54 Rolling out at your customers' pace 28:37 Why AI features are never finished 31:20 Organising teams by product track 33:42 Pruning and sunsetting features 35:38 What to look for when hiring product managers 37:56 The future of team size 40:41 Managing AI costs and model flexibility 42:49 Wrap-upWe're refreshing The Product Experience and want your input. Take our two-minute survey and help shape where the show goes next! Our HostsLily Smith enjoys working as a consultant product manager with early-stage and growing startups and as a mentor to other product managers. She’s currently Chief Product Officer at BBC Maestro, and has spent 13 years in the tech industry working with startups in the SaaS and mobile space. Randy Silver is a Leadership & Product Coach and Consultant. He gets teams unstuck, helping you to supercharge your results. Randy's held interim CPO and Leadership roles at scale-ups and SMEs, advised start-ups, and been Head of Product at HSBC and Sainsbury’s. He participated in Silicon Valley Product Group’s Coaching the Coaches forum, and speaks frequently at conferences and events. You can join one of communities ...
    Show More Show Less
    43 mins
  • Four questions to ask before building AI into your product — Kendra Vant (Chief Product Officer, Tapi)

    Four questions to ask before building AI into your product — Kendra Vant (Chief Product Officer, Tapi)
    Sep 30 2026

    When you use an AI tool, how much time do you spend correcting it? And would your customers be willing to do the same?

    Kendra Vant, Chief Product Officer at Tapi, joins Randy Silver to explore the “reliability layer”: the people, checks and engineering that make AI products dependable. She explains why enthusiastic AI users often provide that layer themselves, and why product teams can’t assume their customers will.

    Kendra shares four questions to ask before building AI into your product, from who catches mistakes to what reliability costs at scale. They also discuss designing for failure, the technical literacy she expects from product managers, and why faster prototyping makes experienced judgement so valuable.

    Chapters

    00:00 Introducing Kendra Vant
    02:51 The gap between an AI demo and a reliable product
    06:12 Accuracy, consistency and the user as the reliability layer
    13:31 Four questions to ask before building AI into your product
    18:27 Sponsor: Jira Product Discovery
    19:01 Planning for failure and protecting customer trust
    24:06 Customisation, pricing and the cost of scaling
    26:37 Do product managers need to learn to code?
    31:40 How Tapi uses AI to experiment and build
    33:25 Why small teams have an advantage
    35:05 Product judgement and the experience gap
    38:08 Using AI to maintain legacy code
    39:41 Ask better questions, write down answers and test your thinking
    43:11 Where to follow Kendra

    Key takeaways

    • Find the work your users are doing for the AI. Correcting answers, refining prompts and spotting mistakes can make a tool feel more reliable than it is. Consider whether your customers have the time, motivation and expertise to do that work.
    • Make someone responsible for reliability. Establish who specifies, builds and operates the checks around your AI. An impressive demo can conceal the fact that nobody owns this work yet.
    • Price the whole product. Human review, additional models, guardrails and ongoing maintenance all affect the cost of delivery. Check whether your reliability layer remains commercially viable as usage grows.
    • Design for the moments when it fails. Saying a model is wrong 15% of the time prompts a different conversation from saying it is 85% accurate. Identify the consequences for customers and plan how the product will recover.
    • Build your technical literacy. Kendra expects product managers to be comfortable interacting with Git and learning from the codebase. Understanding how software works helps you ask better questions and collaborate with engineers.
    • Recognise the value of experience. Faster tools increase what teams can build, but recognising flawed suggestions still requires judgement. Kendra raises an open question: how will newer practitioners develop that judgement as the work changes?
    • Use writing to sharpen your thinking. Break difficult problems into smaller questions, write down your answers and explain them to a colleague. The gaps often become clearer when you have to articulate your reasoning.

    We're refreshing The Product Experience and want your input. Take our two-minute survey and help shape where the show goes next!

    Our Hosts
    Lily Smith     enjoys working as a consultant product manager with early-stage and growing startups and as a mentor to other product managers. She’s currently Chief Product Officer at BBC Maestro, and has spent 13 years in the tech industry working with startups in the SaaS and mobile space.

    Randy Silver is a Leadership & Product Coach and Consultant. He gets teams unstuck, helping you to supercharge your results. Randy's held interim CPO and Leadership roles at scale-ups and SMEs, advised start-ups, and been Head of Product at HSBC and Sainsbury’s. He participated in Silicon Valley Product Group’s Coaching the Coaches forum, and speaks frequently at conferences and events. You can join one of communities he runs for CPOs (CPO Circles), Product Managers (Product In the {A}ether) and Product Coaches. He’s the author of What Do We Do Now? A Product Manager’s Guide to Strategy in the Time of COVID-19. A recovering music journalist and editor, Randy also launched Amazon’s music stores in the US & UK.
    Show More Show Less
    44 mins
  • How to fix your product roadmap — Matt Feczko (Director of Product Ops, Ocado Technology)

    How to fix your product roadmap — Matt Feczko (Director of Product Ops, Ocado Technology)
    Sep 23 2026
    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 takeawaysOcado's roadmap problem wasn't a lack of roadmaps, it was too many of them, rebuilt 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 wasn't designing the new structure, it was getting roughly 3,000 developers to adopt it. Feczko frames that adoption problem as the actual job of product operations: not producing an artefact, but 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: 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:00) Slides are dead for product planning(00:26) Backstage at MTPcon London(00:49) From computer science nerd 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 ...
    Show More Show Less
    35 mins
adbl_web_anon_alc_button_suppression_t1
No reviews yet