The Hotfix Podcast

A few weeks ago, Stefan and I debated whether PMs need to become builders. We agreed. Then we had a heated WhatsApp argument and realized we disagree on something fundamental: Will agents make the PM role obsolete, or will they create the golden age of product management?Stefan believes the 100-person software company will become a one-person company within three to five years. I think the work changes, but the core skill, understanding humans and their problems, stays. We decided to argue it out on the podcast.Here is what we landed on.The case for extinctionStefan joined an AI-first startup three months ago. Everyone there uses AI for 95% of their work. The compounding effect is real: when the entire team operates this way, speed multiplies. When only one person does it, they are bottlenecked by everyone else.His experience with OpenClaw pushed his thinking further. He gave it tasks he assumed it could not complete. It found creative solutions on its own. Research that used to take him hours, such as cross-referencing analytics tools, downloading CSVs, running analysis, now takes a single prompt.His conclusion: if a solo developer can ship a working product from a WhatsApp chat, most of the coordination work PMs do will disappear. Companies that don’t adopt this speed will lose to companies that do. And those fast companies are small by definition.The case for survivalI recently built DocReady, an app that helps Austrian doctors categorize tax documents. I built the entire product solo. Website, iOS app, web app, ads. The code part was impressive, sure. But it solved maybe 5% of the problem.The hard part is acquisition and activation. How do I let doctors know this exists? How do I make them use a tax preparation app regularly (for a task they hate)?One of my beta users told me she didn’t see why she should use DocReady instead of her Google Drive. She already had a system. This single conversation changed my product strategy. I realized I needed to extract structured data from documents, not just store them. That insight opens the door to Excel exports, spending dashboards, reminders, summaries.No agent would have made that strategic observation from a user interview. Not yet.Where we actually agreeThe PM role as defined in 2020 is dead. The person who writes tickets, manages backlogs, and coordinates standups will be replaced. That work is pure overhead in a world where agents handle execution.But the core skill, talking to customers, understanding their real problems, and translating that into product decisions, is more valuable than ever. Execution is cheap now. Context is expensive.We also agree that customer success managers, implementation specialists, and support agents are equally well-equipped for this new world. They’ve had direct customer conversations for years. They just lacked the power to act on what they learned. Agents give them that power.The PM title might survive. The PM job description won’t.The golden age of tiny companiesStefan made a point that stuck with me. If a single person can build and ship a hyper-specialized agent, say, one that handles support for Shopify stores selling sneakers, they could replace a company’s entire support team and their SaaS stack.A company spending 100k a year on humans and tools might happily pay 50k for an agent that handles everything. That is SaaS, just built by one person instead of a hundred.These companies won’t attract VC money. A 10 million ARR ceiling is boring for investors. But for a solo builder, 10 million a year is life-changing. And there will be thousands of these niche opportunities.The interface changes everythingStefan now does half his work through a WhatsApp chat with his agent. He vibe-codes, debugs deployments, and runs research. All from his phone. He took a three-hour bath and felt more productive than any day at his desk.I use multiple AI subscriptions for different tasks. I brainstorm complex strategy through my phone. When I bought a house recently, I resolved hundreds of questions through an LLM. I felt more secure and informed than I ever expected.The medium has changed. The screen-and-keyboard era is ending for many types of knowledge work. Agent monitoring might happen from a chat interface on your phone. People might not need to sit in front of a computer for their entire workday anymore.What PMs should do right nowForget most product frameworks. They were optimized for a world that no longer exists. Rebuilding an entire app was a crazy idea a year ago. Now it’s not anymore.Stay at the frontier. If you know what the latest agent tools can do, you are already ahead of most people in tech. If you tried vibe coding once in early 2024 and gave up, try again. The gap between then and now is enormous.Be the crazy person. Take risks. The likelihood of a positive outcome is higher than it was six months ago. The worst thing you can do is assume that the way you worked for the past ten years will keep working.And most importantly: be curious. This is the first technology shift in years that is not just hype. Everyone can feel how their job is changing. The people who lean into that change will build the next generation of products.It has never been this exciting to be in product. Even if the job title changes.LinksLink to Podcast Episode* 🎥 YouTube* 🎧 Spotify* 🎧 Apple MusicIn case you want to reach out, please do so on LinkedIn:* 🔥 Follow Hotfix: https://pod.link/the-hotfix-podcast* 🔗 Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🔗 Follow Stefan: https://www.linkedin.com/in/stefanpernek/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

A few months ago, we talked about how AI would change the way software gets built, and at the time it still felt like something slightly abstract, interesting to think about but not yet forcing immediate decisions.That has changed.AI-native companies are now shipping faster, with fewer people, and at a fundamentally different cost structure, and they are no longer operating in a separate experimental space but competing head-on with established SaaS companies.The question is no longer whether this matters, but whether existing organizations can adapt fast enough.What AI-native actually meansAI-native does not mean that a company has added AI features to an existing product or sprinkled AI into a few workflows.It means the company could not have been founded before this wave of AI, because the way work gets done would simply not have been possible.In these companies, the first line of code is written by an agent, documentation and contracts start with AI drafts, research and support replies are generated by default, and humans mainly step in to review, correct, and provide direction.Using AI is not a strategic decision anymore; avoiding it requires justification.Why this is hard for legacy companiesMost legacy software companies are not badly run, and the structures they operate with were rational responses to the constraints of the past.They hired large engineering teams because building software was slow and expensive, they introduced product managers to translate customer needs into specifications, and they added layers of coordination because that was the only way to scale delivery reliably.AI changes one thing fundamentally: the cost and speed of translating customer intent into working software.What used to require weeks of alignment, handoffs, and planning now often happens within hours, but organizations are still optimized for the old reality.The people problemAI-native companies hire very differently from traditional SaaS organizations.They delay hiring for as long as possible, prioritize people who can both think and build, and try to avoid roles whose primary purpose is coordination rather than value creation.Legacy companies already have many of those roles in place.As a result, pushing AI adoption often means questioning why certain jobs exist at all, which is uncomfortable, politically difficult, and often avoided, leading transformation efforts to slow down or stall entirely.Distribution isn’t enough anymoreEstablished companies often argue that their main advantage lies in distribution, and historically that has been true.However, AI-native companies operate with a cost structure that allows them to price their products very differently, because a team of ten can now compete with what previously required a team of one hundred.That pricing flexibility itself becomes a powerful distribution mechanism, and it is extremely difficult to out-market a product that is cheaper, improves faster, and is built by a much leaner organization.Product management changes the mostThe role that changes most visibly in AI-native companies is product management.Product managers are no longer primarily facilitators or coordinators, but builders who combine customer understanding with the ability to turn insights directly into working software.They talk to customers in the morning, prototype during the day, and often ship something meaningful by the evening, which causes discovery and delivery to collapse into a single continuous motion.This strongly favors people who deeply understand customers and can act immediately, while it puts pressure on roles that exist mainly to coordinate work between others.Fewer people, more contextAs execution becomes cheaper, context becomes more valuable.The most important assets of future software companies are the codebase itself, rich and ongoing customer conversations, and clearly written strategy, constraints, and decision principles that guide both humans and AI systems.AI systems need this context to act well, and humans do too, which creates a new leadership responsibility focused less on managing output and more on maintaining shared clarity.Can legacy companies win?In theory, legacy companies have everything they need to compete.They have distribution, long-standing customer relationships, and people with deep domain knowledge who understand the problems better than any newcomer.If they manage to radically reduce coordination overhead, turn product managers and engineers into customer-centric builders, and accept smaller, more empowered teams, they can remain competitive.In practice, this is rare, not because leaders are incompetent, but because the organizations they built were optimized for constraints that no longer exist.What stays trueDespite all the change, some fundamentals remain.Customer understanding still compounds over time, clear strategy still matters, and good judgment is still scarce.What disappears is the need to scale through headcount.Software companies will likely become smaller again, not simpler, but leaner, and very different from what most of us are used to. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Seven months ago, we talked about how product management was changing. We focused on discovery over delivery and outcomes over outputs. These topics felt urgent then. Now they’ve faded into the background. AI has taken center stage. And this shift is justified.Canva disrupted design. Shopify disrupted e-commerce. AI is doing the same to product management. The way product management was done six months ago will not exist in the future. At least not in most companies.The PM as builderAI coding agents have become so good that every product manager needs to evolve. The shift goes from facilitator and communicator to builder. Not just building prototypes to validate. Actually touching code and shipping features.This was only enabled in the last two or three months. Before that, AI wasn’t capable of it. Now even semi-technical people can ship features on their own.Six months ago, most PMs used AI for writing and discovery. Bouncing ideas back and forth with ChatGPT. Now we spend hours in tools like Lovable or Claude Code. Creating things that go beyond clickable prototypes.The old way: Sit with designers in Figma. Create linear prototypes where only one button works. A yellow highlight shows which element is clickable. This took three weeks.The new way: Have an idea in the morning. By afternoon, have something that feels like production. Everything is clickable. Actions happen in the background. Hand it to a developer and they can turn it into production code in a fraction of the time.The death of the feature delivery pipelineClaude Code blew me away when I started using it. It feels optimized for product managers. Like working with a senior engineer who checks in at the right time.When planning a new feature, it spends 10-15 minutes exploring the code base. Finding out what needs to be touched. Then it launches a planning agent. Comes up with a comprehensive plan for review.This is exactly how great engineers worked before. They surfaced risks. They surfaced increased costs. They suggested what should be a follow-up feature versus what to build now.The old feature delivery pipeline looked like this: PM talks to customers. Forms an idea. Prioritizes it. Does a first check-in with UX. Works on wireframes for two weeks. Checks feasibility with the tech lead. It doesn’t work. Back to the drawing board. Six weeks of coordination overhead. Then six weeks of implementation.This is already outdated.Rethinking the feature delivery pipeline will be one of the biggest challenges for organizations in 2026.Teams have to changeIn a company with eight engineers per product manager, the PM can only be a facilitator. A communicator. Someone who makes sure everyone works toward the same thing. If engineers get faster with AI tools, this coordination work only increases.Andrew Ng, founder of Coursera, recently suggested his team is moving to two product managers per engineer. More PMs than engineers. Six months ago, this would have sounded insane.But delivery is no longer the bottleneck.Before, there was a clear cut. PMs focused on discovery. Engineers focused on delivery. Sometimes in forward-thinking organizations, engineers did some discovery too. But PMs rarely touched delivery.Now the lines blur. While doing discovery, you can already deliver. Talk to a customer in the morning. Understand an insight. Prototype something during the call. Polish it in the afternoon. Push to production by evening.Discovery and delivery happen in the same motion.The risk of feature soupIf everyone can deliver quickly, the risk of Frankenstein platforms increases. Products that don’t make sense anymore. Features piled on features without a clear thread.Organizations without a clear vision will have a hard time if they enable everyone to be builders. Products need to become more specialized. The old economics didn’t justify building a product with an ICP of 10,000 people. Now it does.But this requires discipline. Stick to a strategy. Don’t pivot every quarter. Otherwise you pile up features that become hard to maintain. Not just technically. Also organizationally, contractually, and when onboarding new people.Feature bloat without strategy is one of the biggest risks ahead.Distribution becomes the differentiatorBefore AI, success required a pyramid. The lowest level: ability to build. You needed engineers or money. This level is completely gone.Second level: having a great product. Simple, solving the right problems, intuitive, accessible.Third level: distribution. This was always there. But it’s becoming the main differentiator.What Shopify did to e-commerce is what AI will do to software. Building a good product is no longer a competitive advantage. It’s the ultimate baseline.A fitness instructor working at 10 different fitness centers has access to 200 potential customers. That’s an unfair advantage. They can test their app. If it’s good, word of mouth spreads.The skills that will matter for product managers: networking, sales, messaging, and marketing. When aligning with engineers about feasibility becomes less relevant, focus shifts to business fundamentals.The ability to create something great is not as valuable anymore. It was very valuable a year ago.What’s nextPredicting the future is hard. Seven months ago, the rate of change felt crazy. It was even crazier than expected. Small improvements compound into fundamental shifts.Prompting was the hot topic six months ago. Now the hottest topic is keeping the most relevant context without having to retype it. In six months, we’ll probably laugh about manually attaching screenshots.People overestimate what can be achieved in the short term. They underestimate what can be achieved in the long term.A lot has changed. But it has never been more exciting to work in product and software.LinksLink to Podcast Episode* 📹 YouTube* 🔊 Spotify* 🔊 Apple MusicIn case you want to reach out, please do so on LinkedIn:* ❤️🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast* 🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Product management has never been an easy job. But the rise of AI has changed the rules and raised the bar.In this post, we unpack what separates good PMs from great ones today, and why AI will amplify that gap even further.The 6 Core Traits of Great PMsWe started the conversation by listing the timeless traits we’ve seen in standout product managers.* They own problems, not features.Great PMs don’t stop when something is shipped. They stop when the underlying problem is solved.* They think in outcomes, not outputs.Great PMs don’t care too much about building the thing right. They care about building the right thing and they know how to measure its impact.* They think beyond the sprint.Strong PMs can zoom out. They hold a strategic roadmap in their head and adjust it as they learn more.* They collaborate across the product trio.They work deeply with UX and engineering to manage the four product risks: value, usability, feasibility, and viability.* They ship.Strategy without execution is just a deck. Great PMs reliably get things into users’ hand.* They’re curious.Curiosity is what drives the best PMs to go beyond the backlog. They explore ideas no one asked for. They chase problems no one sees yet.The Hard Skills That Can’t Be SkippedWe also added some harder skills that separate truly high-performing PMs:* Data literacy.Not just reading dashboards, but understanding bias, false positives, and what your metrics really mean.* Business acumen.Knowing how your company makes money, what gross vs. net revenue retention is, and how to influence key drivers.* Being easy to work with.Saying no without creating drama. Collaborating with sales and CS without becoming a feature factory. This isn’t “fluffy”, it’s critical.So What’s Changing with AI?Here’s the big shift: AI lowers the floor but raises the ceiling.What gets easier:* Writing specs* Generating test cases* Creating dashboards* Synthesizing user interviewsWhat becomes more dangerous:* Jumping to conclusions from data you don’t really understand* Delegating product sense to a prompt* Acting “strategic” without doing the hard thinkingWhat AI can’t do:* Understand the messy reality of your customers* Discover the root of a real problem* Own a business outcome and make it moveAs Stefan put it: “AI won’t replace PMs. But it will replace the ones who were never really doing the job.”Why Thinking in Outcomes Is Still RareOne of our favorite heuristics:If you haven’t thought about something you launched in the past 2 weeks, you’re probably not outcome-driven.Most PMs live in the future and about what’s next on the roadmap, what’s being released. But very few revisit the past.They treat launches as finish lines. Great PMs treat them as checkpoints.The New Bar for Entry (and Why Juniors Will Struggle)One hard truth we discussed: AI may kill the junior PM role.Entry-level PMs often relied on manual tasks writing tickets, transcribing interviews, summarizing feedback. But those can now be done by AI.This raises the bar for getting into product. But it also creates new adjacent roles:* Setting up AI tools for discovery and prototyping* Creating the infrastructure for prompt-driven interfaces* Curating and structuring data that AI can useFinal ThoughtsPMs who want to thrive in this new era need to embrace one big idea:You can’t outsource product sense.AI will accelerate your work. But it won’t do the work for you. In fact, it will expose anyone faking it.If you want to stay great:* Stay close to customers* Learn how your business makes money* Think in problems, not projects* Use AI—but don’t hide behind itAnd most of all: stay curious.LinksLink to Podcast Episode* 📹 YouTube* 🔊 Spotify* 🔊 Apple MusicIn case you want to reach out, please do so on LinkedIn:* ❤️🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast* 🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

In our latest Hotfix episode, Stefan and I explored an uncomfortable question:Are we entering an era where a single person can do the job of an entire product team?Today’s standard setup looks like this:One PM, one Designer, a few Engineers. Clear swim lanes. Frequent alignment.But with AI-native tools like V0, Lovable, and Cursor, the lines are starting to blur. You can build, design, and ship something functional—in days. Without handovers. Without standups. Without a trio.What We’re Seeing:* PMs are suddenly able to prototype full UIs—without Figma.* Designers are writing front-end code.* Engineers are validating ideas with customers—on their own.And maybe most important:The best teams already don’t care whose job something “officially” is.So… What Changes?Stefan believes we’re moving toward “teams of one.” People who ideate, validate, build, and ship solo—with a swarm of AI agents supporting them.I pushed back.Time—not skill—is still the bottleneck. Especially in product roles. Aligning teams, talking to customers, and managing messy orgs isn’t something AI is good at… yet.But we agreed on this:The strongest teams of the future will be generalists—not specialists. People who can think across UX, code, and business. Not deep experts in one swim lane.Who Should Be Worried?🛑 If you only know how to execute what others define—your job is at risk.✅ If you’re curious across disciplines and willing to get your hands dirty—you’ll be fine. Better than fine, actually.Because the bar is rising. Fast.🎧 Full episode: Hotfix 015 – Will PMs, Designers, and Engineers All Merge Into One?Available on Spotify, Apple, and YouTube.LinksLink to Podcast Episode* 📹 YouTube* 🔊 Spotify* 🔊 Apple MusicIn case you want to reach out, please do so on LinkedIn:* ❤️🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast* 🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Roshan is the founder of AmplifyPM. Prev. he served as PM at Meta and as a Group PM at Google.Roshan Gupta had the kind of job most PMs dream of: Group Product Manager at Google, leading a 300-person org. Then, he gave it all up.He moved to Portugal and started a one-person company, betting everything on a single idea: PMs don’t fail because of their strategy—they fail because they can’t tell a compelling story.This episode is about two things:* The slow, painful death of Google Allo (yes, that failed messaging app).* And what Roshan thinks is the #1 skill every PM should master: persuasive storytelling.The Messaging App That Was Doomed From the StartIf you don’t remember Google Allo, you’re not alone. It launched in 2016, promised rich messaging, Google Assistant integration, and sleek features. But it never took off.Roshan, who led Allo’s growth, breaks it down simply:“We had a great product. What we didn’t have was distribution.”Allo was competing with WhatsApp in India—a market where SMS used to cost real money, and WhatsApp had already solved that pain. Meanwhile, Allo had to fight its way into phones one by one, even though Google already had Android Messages pre-installed.They tried everything:* SMS relays from a central number (which confused people)* Bundling with Android manufacturers* Targeting specific markets* Google Assistant baked into the appNone of it worked fast enough. And at Google’s scale, millions of users just isn’t enough.“Our growth outpaced Snapchat’s early years. But for Google, it wasn’t fast enough.”In 2018, the team was told to pause development. In 2019, Allo was shut down.Why Storytelling Is the Most Underrated PM SkillRoshan's biggest takeaway wasn’t about messaging apps. It was about people. Specifically, how PMs fail to communicate the value of their work.“There were amazing PMs at Google who didn’t get promoted—not because they didn’t do great work, but because they couldn’t persuade the org.”Roshan says great storytelling comes down to three things:* Clarity – Say one thing, not ten. “Adding more info is like adding water to wine.”* Compelling – Tie your story to something your audience wants. No one changes unless they want to.* Credibility – If people don’t trust you, your story won’t land. Trust is built over time, not in a single meeting.The Spicy Take: PMs Are Bad at Growing PMsRoshan’s new mission is to coach PMs into leadership. And he’s frustrated by how little companies invest in it:“You wouldn’t question an Olympic athlete hiring a coach. But in product, it’s seen as a weakness if you need one.”He argues we’re doing a terrible job building the next generation of leaders. Why?* Most PM skill matrices are vague or unreadable.* There’s no clear roadmap for how to level up.* And storytelling, stakeholder management, and positioning often go completely uncoached.His fix? Amplify PM, a coaching business that helps ICs step into leadership roles—without fluff.The Final LessonAllo failed. But Roshan didn’t. He moved on to lead Google Messages. Then, he walked away to do something that mattered more to him: teaching others how to lead.And if there’s one thing he hopes more PMs remember, it’s this:“Being comfortable with failure is what lets you take the risks that actually lead to growth.”LinksLink to Podcast Episode* 📹 YouTube* 🔊 Spotify* 🔊 Apple MusicIn case you want to reach out, please do so on LinkedIn:* ❤️🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast* 🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/* This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Nesrine was a Senior PM at Google, Spotify and Microsoft. She’s now a product coach and will be releasing her first book on how to infuse emotional connections into product design by the end of March!In our conversation, Nesrine shared a surprising “failure story” from her time on the Google Meet team.Nesrine’s failure storyNesrine was working on Google Meet as a PM, when COVID broke out. You sure can imagine how intense that time must have been for the team. One day, suddenly a lot of users started complaining. About a new feature that created fireworks and celebratory effects in inappropriate situations. These could have been triggered by raising a thumb for example. In case you’re an Apple user you might have seen them:What wasn’t clear to all users at that time was that this was not a feature from Google Meet.Google didn’t build this fireworks feature. Apple did. Apple’s operating system update enabled these reactions by default, so users naturally blamed Google Meet.The situation sounds like a small thing, but one shouldn’t forget that Google’s products are reaching 100s of millions of users and this impacted core functionality of Google Meet. That means that these reaction were triggered in very inappropriate situations, such as therapy sessions or high-stakes corporate calls. Triggering random fireworks in such situations was anything but delightful.What started as an innocent attempt to introduce delight (from Apple’s side) turned into a big escalation for the Google Meet product team. As soon as the team realized how intrusive and potentially harmful these auto-reactions could be, they tried to explain that this was not a native Google Meet feature and advised users how to turn it off on their Macs.A lesson in how to create product delightCreating product delight is generally a topic that Nesrine cares deeply about. That’s why she also dedicated a full book to it, that will be out soon! Below are a couple of her key takeaways on product delight:* Product delight creates an emotional connection between users and the productProduct delight is created when a product meets its intended purpose (functionality) while exceeding user expectations.* Usually not quantifiableInvesting into delightful features is often not measurable or quantifiable. Integrating playful animations or fun features often doesn’t solve a problem and therefore won’t move any needle in the short term. We btw dedicated a full article + podcast on problem-free product work, in which we also covered UX deligthers: https://thehotfixpodcast.substack.com/p/006-does-every-feature-need-to-solve. Nesrine argues though that emotional features often take longer to show a direct impact on revenue or retention. That means that PMs need to be more patient in measuring usage patterns, and watch loyalty indicators (like referrals and advocacy).* Delight = Joy + SurpriseIn our podcast Nesrine shared a definition of Delight. A truly delightful feature combines surprise and joy. A feature that is only surprising—or only joyful—can end up being distracting or disappointing.* Prioritize with a balanceProduct teams should ideally aim for a balanced combination of Low, Surface, and Deep Delight features in their product roadmap to ensure both functional needs are met and users are emotionally engaged.Nesrine’s arguments on why it makes sense to invest into delighting customers reminded me of this graphic by Casey Winters, that shows why constant UX investments enable companies to keep product-market fit:The gist is that customer expectations keep increasing as the bar for average software is being raised constantly. And competitors also won’t stay still. That means once companies stop investing into UX work they might lose their product-market fit.What Else We Talked About* Functional vs. Emotional FeaturesNesrine explains why some top-performing products (e.g., Spotify Wrapped, Duolingo streaks, Slack’s whimsy) thrive because they provide emotional benefits beyond core functionality.* B2B Can—and Should—DelightEven Jira, the quintessential enterprise tool, invests in delight. Users are humans, regardless of the “B2B” label. Emotional touch points in B2B products can be a massive differentiator.* Motivational InterviewingInstead of directly asking users about “problems,” Nesrine recommends deep, open-ended discovery that uncovers hidden emotional drivers.* Start Small and ScaleYou don’t need to overhaul your product overnight. Dedicate a small percentage of your roadmap each quarter to try simple, delightful additions. Track how your users respond before expanding further.LinksLink to Podcast Episode* 📹 YouTube* 🔊 Spotify* 🔊 Apple MusicIn case you want to reach out, please do so on LinkedIn:* ❤️‍🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast* 🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Trisha is the CPO of Pendo.io, one of the most widely used product experience platforms. Trisha brought us a gem of a failure story.Her team has been working on a powerful machine learning future for a long time.The feature was aimed at answering one question:What are the features that drive user retention?Trisha’s failure storyOver the years, Pendo had gathered mountains of product usage data, such as clicks, sessions, outcomes. They even knew which users stayed and which churned. So the idea was to build a machine learning model that identifies what behaviors drive long-term retention.Early results were promising. Some insights made total sense (“creating shared dashboards” was a big one). Others were… surprisingly boring (“visiting the settings page” meant high retention - obvious for administrators). Still, the team pressed on.They iterated on the interface. They brought in new designers. Even the CEO jumped in. But no matter how much effort they put in, something wasn’t working.“We got it wrong. We got it wrong. We got it wrong again.”—Trisha Price, CPO @ PendoEventually, they launched it. And while some users did get value from the feature, adoption was low. Most PMs loved the idea—they just didn’t come back to use it. Trisha and her team were left scratching their heads.Was it the UI? Was it the model? Was it just… too static?Turns out, just knowing which feature drives retention isn’t enough. It needs to be timely, actionable, and trusted. If the insight changes too often, users don’t believe it. If it doesn’t change at all, it’s not useful beyond the first visit.A few things we loved from the conversation🧠 “AI can’t replace taste.”Trisha talked about what Megan Quinn once called taste—the combination of intuition, signal processing, and experience that defines a great PM. AI can help with execution, but it can’t develop taste. That’s why the best PMs are probably sticking around.🎯 “There is no such thing as product strategy.”Or rather—your product strategy is your company strategy. Especially in product-led SaaS companies, the two are often inseparable. Trisha emphasized that if your company strategy is to sell more to happy customers, your product strategy better be about creating those happy customers.💡 “We don’t believe in fixed innovation percentages.”Instead of saying 20% of R&D goes to new ideas, Trisha prefers a more fluid approach: start small, see what sticks, then double down. That’s how they scaled features like Session Replay. It’s also how they’re thinking about future churn prediction features.What else we talked about* Why junior PMs might not actually be PMs yet—and why that’s okay* The changing PM-to-engineer ratio in the age of AI (some teams run on 1:1:1!)* Why product marketing can’t save a weak product, and how PMs sometimes try to offload differentiationListen to the full episode🎧 Spotify📹 YouTube🍎 Apple Podcasts🧠 Follow Trisha: LinkedIn🎙 Follow Christoph: LinkedIn🎙 Follow Stefan: LinkedIn🔥 Follow Hotfix: Linktree This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Rewrites are the silver bullet that never hits the target.If you’ve ever worked in SaaS, you’ve likely heard it before:"The tech stack is outdated.""We have too much technical debt.""This architecture won’t scale—we need to start fresh!"At first glance, it makes sense. A cleaner, modern, well-architected system should let the team move faster and deliver more, right? Except, that’s rarely what happens.In our latest Hotfix Podcast episode, we sat down with Alex Oprescu, an engineering leader who has witnessed firsthand how rewrites derail companies, drain resources, and create more problems than they solve.Let’s unpack why rewrites are so tempting, why they often fail spectacularly, and what SaaS companies should do instead.Why Do Engineering Teams Push for Rewrites?Rewrites usually start from a real problem—the product has accumulated too much complexity, development is slowing down, and technical debt is piling up. When a company scales, the initial scrappy codebase often starts feeling like a house built on shaky foundations.But rather than fixing what’s there, engineering teams often push for a full rewrite. Why?💡 The Fantasy of a Fresh Start – Engineers love the idea of working with a clean slate. No more legacy issues, no more messy code, just a modern, elegant system.💡 Blame Shifting – It’s easier to say, “Our architecture is bad” than to admit, “We made poor product decisions” or “We don’t fully understand our customers.”💡 Internal Constraints & Skill Biases – Sometimes, companies have a team skilled in a new tech stack and push for a rewrite—not because it’s needed, but because it fits their internal expertise.💡 Chasing a False Hope – There’s a belief that a rewrite will unlock faster development, happier engineers, and better scalability—but it rarely works out that way.The Harsh Reality: Most Rewrites Fail🚨 They take far longer than expected. Rewriting a product isn’t just about rewriting code. It involves migrating data, ensuring feature parity, retraining users, and fixing unforeseen compatibility issues. Most teams underestimate the complexity.🚨 They kill momentum. While engineers are busy rebuilding, the business stands still. New features are deprioritized, customers get frustrated, and competitors move ahead while you're stuck redoing work.🚨 They don’t fix the real issue. Many teams believe rewriting their product will make it more scalable, but they ignore the core business problem—which is often not about tech, but about how the product is evolving.🚨 They ignore customer needs. A rewrite often focuses on internal pain (engineers hating the old codebase) rather than external pain (customers struggling with the product).The Alternative: Refactor Instead of RewriteRather than tearing everything down and starting over, winning teams take a more pragmatic approach.✔️ Assess What’s Really Broken – Is it truly the tech that’s limiting growth, or is the product itself not solving the right customer problems?✔️ Fix in Iterations – Instead of rewriting the entire system, refactor incrementally. Break down monolithic components, optimize bottlenecks, and gradually improve the system without stopping feature development.✔️ Retire Features Aggressively – One of the biggest reasons software becomes unmanageable is feature bloat. If customers aren’t using something, remove it instead of rebuilding it.✔️ Know Your Business Stage – As Alex explained in the episode, teams should identify where their company is:* Exploration phase (testing product-market fit) → Rewrites are deadly here.* Expansion phase (scaling up fast) → You need speed, not perfection. Avoid rewrites.* Extraction phase (optimizing an already successful product) → If you’re here, a rewrite might finally make sense—but only with clear ROI.Rewrites Can Kill Startups—Don’t Fall for the TrapAtlassian, Facebook, and other giants have all faced this problem. The smartest teams recognize that rewriting an average product won’t magically make it great.🚫 If your product isn’t selling well, a rewrite won’t change that.🚫 If your company is slowing down, a rewrite won’t fix your strategy.🚫 If engineers are struggling, a rewrite won’t necessarily make them faster.The next time your team suggests starting from scratch, ask: Are we fixing a real problem, or just running from the mess we created?🎧 Want to hear the full discussion? Listen to our podcast episode with Alex Oprescu:🔊 Spotify: 🔊 Apple: https://podcasts.apple.com/at/podcast...📲 Follow us on LinkedIn for more insights:* Christoph: https://www.linkedin.com/in/christophbodenstein/* Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Tamer is CPO at Project A Ventures.In our latest conversation for the Hotfix Podcast, Stefan and I had a conversation with Tamer El-Hawari. For 12 years, Tamer was CPO at Project A ventures. One of Germany’s most renowned VCs. In this role Tamer has worked for more than 50 companies as a product exec and therefore has a lot of wisdom to share.Tamers failure storyIn his failure story Tamer talked about a time where he worked for an e-commerce company, that had outgrown its legacy platform. The company was profitable and ambitious and planned to expand to more markets.The leadership of the company pushed for a state-of-the-art platform with a wide variety of features: mobile-first design, omnichannel capabilities, personalized experiences, marketplace integrations, etc.Tamer led the product development team to build a custom platform from scratch. Ultimately the project failed to translate into true value for the business. The launch faced a couple of delays, feature roll-outs were incomplete and the company struggled as the rest of the organization simply wasn’t ready for this product.The team underestimated the complexity of integrating with existing systems, especially the ERP system and, at the same time, overestimated the company’s maturity to handle such a transformation.What Tamer described with this failure story is a complex failure. In the Marty Cagan universe we would talk about a Viability risk not being de-risked enough.How to handle viability risks as a PMViability risks are usually the hardest one to de-risk, but also the most fatal ones if shipped. These risks revolve around whether a product will work for the business, not just the customer. To tackle them, PMs need a deep understanding of multiple aspects of the business, including sales, marketing, operations, and finance. Tamer emphasized that it’s not enough to focus on customer needs or building the right features. PMs also need to understand how the product fits into the company's overall strategy, revenue goals, and organizational capabilities.He pointed out that many PMs overlook internal factors like the company's readiness to adopt new technology, existing operational workflows, and financial constraints. To effectively de-risk viability, PMs should proactively seek out information about the business model, P&L statements, and the company's strategic goals.What Else We Talked AboutDo PMs Need Domain Knowledge?Tamer weighed in on the common debate around whether product managers need deep domain expertise to succeed. While some argue that too much domain knowledge can create bias and limit fresh thinking, Tamer believes that having at least a foundational understanding of the industry is essential. He emphasized that PMs can't make effective decisions without understanding the nuances of the market, the users, and the technology. However, he also noted that coming from outside an industry can be an advantage. Newcomers often challenge assumptions and bring innovative ideas that insiders might overlook. The key is balancing curiosity with a systematic approach to quickly ramp up on domain knowledge.How to Empower Yourself as a PMAnother key theme was the idea that empowerment isn’t something PMs should wait for—it’s something they should actively claim. Tamer argued that PMs need to take ownership of their roles by proactively gathering knowledge, building cross-functional relationships, and deeply understanding their business environment. He shared practical ways to do this, like learning the company’s financials, understanding the sales process, and staying ahead on customer insights. By doing so, PMs can position themselves as trusted leaders within their organizations, capable of influencing strategy and driving meaningful impact. Tamer’s advice? Don’t wait for permission—ask questions, challenge assumptions, and demonstrate your value through action.LinksLink to Podcast Episode* 📹 YouTube* 🔊 Spotify* 🔊 Apple MusicIn case you want to reach out, please do so on LinkedIn:* ❤️‍🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast* 🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Please just build it, discovery will only slow us down!A common belief among SaaS executives is that thinking in hypotheses and trying to prove or falsify them ultimately costs too much time and therefore money.This also makes sense. Many successful Silicon Valley founders believe that time to market is one of the most important metrics.A recent example is Mark Zuckerberg's quote ‘Velocity wins’:“If we’re gonna get it out first, have a good feedback loop, we’re gonna learn what people like better than other people.”This is true. Particularly true for consumer apps. Product teams can cut corners on quality, just go for it and see what happens. At the end of the day, software teams also only create value when they deliver features to customers, and proven insights are best gained when something gets into the hands of customers.At the same time, failure is expensive. Especially in B2B SaaS companies. Every product launch requires significant effort from multiple teams: product, UX, engineering, marketing, sales. This means that the launch of a feature is often too significant an event to be used as a point in a feedback loop or as the first step in an experiment. If a feature fails at this stage, it becomes expensive: maintenance, coordination, training, development time and ultimately the termination of the feature require significant amounts of time. The emotional attachment of many colleagues within the company will also be high. Several internal successes (‘yay, we delivered’) have been celebrated and giving up this feature could be demoralising for the team.So how can you best balance the time spent on de-risking (prototype testing, customer interviews, internal discussions, etc.) with actually developing features, writing code and delivering features to customers? 🤷‍♂️How do you do your job as PM best and reduce the risk of failure, but at the same time make your founders happy by keeping velocity high?The Build vs. De-Risk DilemmaThe tricky part here is that both of these statements are true:* Experimentation and de-risking can save up to millions of dollars that would otherwise be spent on developing, releasing, maintaining and discontinuing features that no one wants or needs.* Software teams only create value when they bring new functions into the hands of customers.This means that there has to be a middle ground between these two avenues: you need to spend a reasonable amount of time on de-risking. However, once you have reached a reasonable amount of clarity though you need to start building.The challenge with continuous discovery / deliveryA curious reader of PM literature might say: ‘continuous discovery and delivery is the solution to this problem!’.The ideal setup described in most product management books is for the PMs on the team to continuously discover, the UX designers and engineers to continuously design and code, and together they continuously deliver automatically validated solutions.The double diamond of product management specifies that discovery and delivery do not take place one after the other, but in parallel. There is never a dependency where delivery can only start after discovery:The challenge with continuous development and delivery is that it only works for existing products. Instead of a single, upstream research phase, you conduct discovery in parallel with delivery.But what about situations where your founder asks you to deliver a new feature or product? An idea he or she recently had that simply needs to be built?How to time-box initial product discovery for your big betsFor a new feature area or a new product, Initial Product Discovery comes into play. Initial Product Discovery blocks development efforts. In this case, it is true that discovery delays development.Not doing discovery cannot be an option, especially for big bets. This is also because it will be very difficult to design a feature without ever talking to a customer...A good compromise that often works is time-boxing your discovery. This means that you set an artificial deadline for your discovery efforts.But when is the time reached when you can say: ‘Now we know enough, let's build it’?To do this, we need to answer two important questions about the idea behind the big bet.Where does the idea come from?A crucial piece of information in answering this question is where the idea for the big bet comes from. What is the source of the idea? If we have countless interviews and customer requests asking for this feature, not much research is needed to validate the big bet. If it's just a random idea, we'd better validate it with at least one person outside the organisation.Itamar Gilad's confidence meter is a great framework to quantify the validity of a source:The entire right side of the confidence meter (0.01 - 0.5) is based on internal opinions. It starts with very unsystematic internal opinions, such as self-conviction, and ends with more structured internal opinions such as ‘an investor said so’ or engineers have performed a POC.The entire left-hand side (0.5 - 10) is based on external opinions. It starts with weaker external opinions such as anecdotes (‘a customer once said...’) and goes up to the strongest external opinion: launch data. Launch data means that you have introduced the function and therefore know its effects. This is irrelevant at the moment. We have not yet introduced the function.What's interesting about the Confidence Meter is that the highest score you can achieve before launch is 7. And this is only possible with the highest level of de-risking exercises, such as prototype tests, user studies and A/B tests. A considerable amount of time is already required to get this far. Most companies will only do this for a fraction of their new features.A good score that can always be achieved through product discovery is 1-2, which means that you have spoken to a few (5-10) customers, looked at product data, spoken to sales or conducted a survey.What is interesting about the confidence meter is that even at this stage it indicates that the certainty of not failing the feature is still very low. At this stage, only 2 out of 10 points are still considered reliable.How high is the cost of investing into that idea?The second question you need to answer in relation to the idea is: What is the cost of investing in this idea?Since we are still at the very beginning of a new big bet, the cost may not be clear at this point. We can literally invest any amount of time into something new. A product team should not be done when a deadline is reached, but when a problem is solved. Instead, a good metric is ‘ease of change’. Are you investing in a new, standalone feature that can be deprecated without dependencies if something goes wrong? Or are you touching a core element of your platform's technology? I've categorised them into four categories:* Trivial to Revert (Low Cost)Examples: Minor UI changes, copy updates, or low-impact features.Characteristics: Minimal development time, no dependencies, and can be quickly undone without impacting the product.* Moderate to RevertExamples: Small functionality changes or enhancements that require a bit more effort to remove but don't affect the core system.Characteristics: Slightly longer implementation time, mild team coordination required, reversible without significant disruption.* Challenging to RevertExamples: Features that touch multiple systems or involve backend changes but aren't foundational. This should also include dependency and work from other units. Is it a feature that requires a lot of internal education, documentation, launch activities etc?Characteristics: Higher development effort, dependencies on cross-functional teams, and requires planned removal efforts.* Costly to Revert (High Cost)Examples: Architectural changes, significant new functionality, or features requiring long-term maintenance.Characteristics: High investment in resources, deeply integrated, and extremely complex to roll back.How much time should you make for discovery?By putting both metrics of each idea on a quadrant you will get these four categories:If you have a large bet that has a high level of confidence (more than 10 customers would pay for it), and it's a standalone feature with few dependencies that's easy to set up, then go for it. You probably won't need much additional discovery for these types of bets.The 70% rule by Jeff BezosAnother more simple framework for knowing when enough is enough is the 70% rule by Jeff Bezos.In a 2016 shareholder letter, Jeff Bezos suggested that “most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.”from the book “Working backwards” by Colin Bryar & Bill Carr.This means that you can never falsify or validate all assumptions and that at a certain point you just have to build and deliver to find out.It's a similar approach to the one above. If you start at 60% confidence, you invest another 10% to get to 70%. However, if you start at 5%, make sure you get to 70% by investing in the right discovery. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Carlos is CEO & Founder at Product School.Product school is the world's largest product management training provider. Carlos is also the author of the Amazon bestseller "The Product Book" and the organizer behind #ProductCon, the worlds largest Product Conference.In our most recent episode we had a conversation with Carlos González de Villaumbrosia, CEO & Founder of Product School.Carlos shared a story, where he had to shut down profitable physical locations of product school for strategic purposes, even though they worked & were profitable.The Challenge of Emotional AttachmentProduct School started out with physical campuses. At one point they operated more than 16 campuses! These were also profitable and served students well. Students showed up to their classes. At one point, Carlos and his team started an experiment: online classes. This was way before COVID and it wasn’t that obvious that students would enjoy taking virtual classes. It was initially started to also serve students that do not live close to any physical location. Soon the Product School team noticed though that also students that lived close to physical campuses preferred to take their classes online. As the online campus started growing faster, a hard decision emerged. Keep the physical locations or go all-in on online learning?The team ultimately decided to close all physical locations and focus purely on their online product. This was more scalable and also aligned with a bigger vision. In the podcast Carlos talked about that this was not an easy decision emotionally. All locations were profitable. The team had successful operations built up around them and many people cared about the locations.Killing something is just so hard in product. Especially when it’s working.This reminded me of a couple of situations also I found myself in some times. Why Do Teams Resist Sunsetting?As PMs we often try to act as rationally and data-driven as possible. This means sunsetting features, when we see they don’t work.This is, however, often not that easy. Products aren’t just code. They’re the result of collaboration across teams. This emotional investment makes it hard to let go. Especially engineers have spent weeks or months on solving hard problems and writing code that creates value.A Framework for Letting GoLetting go is important though. As a PM you need to prepare your team mates for situations in which your team needs to delete code and takes things offline again. Here’s a couple of thoughts, that will make communicating the decision to your team much easier:* Anchor Decisions in Strategy: When Carlos moved Product School online, it wasn’t just about cost or convenience. It was about a clear, scalable vision for the future. Make sure to clearly communicate why stopping or sunsetting a feature has strategic value.* Show Data: While emotions run high, use data to tell the story. For Product School, data showed online satisfaction levels were as high as, if not higher than, in-person. For features with low adoption you can show two things: Its low adoption + the cost it incurrs. * Have a Transition Plan: Killing features isn’t a one-day task. Carlos shared how the process took six months, with incremental closures starting with smaller locations. Sunsetting features requires proper project management. Make sure to collaborate cross-functionally to make users aware of the transition plan.What Else We Talked AboutBeyond the failure the podcast with Carlos also covers:Bootstrapping vs. Taking InvestmentsFor seven years, Product School was bootstrapped, allowing Carlos to focus on building the right product without external pressures. However, scaling the business eventually required raising investment to grow faster. He reflected on the trade-offs between staying lean and bringing in funding to accelerate operations.Keeping Up With Industry Trends Is a Constant ChallengeProduct management is evolving rapidly, with new technologies like AI reshaping the role. Carlos discussed how Product School constantly updates its curriculum to reflect the latest industry trends. Staying relevant requires continuous learning and adapting to change.Revenue Accountability Is the Future for PMsModern product teams can no longer focus only on user experience. They need to demonstrate business growth. Carlos argued that product managers who understand and influence revenue will have the strongest career opportunities in the future. Aligning product efforts with financial goals is becoming a necessity.LinksLink to Podcast Episode* 📹 YouTube* 🔊 Spotify* 🔊 Apple MusicIn case you want to reach out, please do so on LinkedIn:* ❤️‍🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast* 🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Mirela is CPO & Founder at Product People.In this week's episode of the Hotfix podcast, we had a chat with Mirela Mus. Mirela is CPO and founder of Product People. Product People is a product management agency that fills temporary product roles, e.g. due to paternity leaves. This type of PM role has given Mirela a wealth of experience. She has over 12 years of experience in product management, including more than 5 years as a product manager. She has worked in more than 20 different companies as a product manager or leader!In her story of failure, she recounted a time when she worked for a large, global B2B2C marketplace. The supply side of the marketplace was B2B customers offering their goods. The other side were the consumers who bought those goods. Most successful marketplace models are B2B2C. Examples are Airbnb, Booking or Fiverr.Mirelas failure storyMirelas failure story, was about a legal risk her team has overlooked. The company Mirela worked for at the time operated a complex platform that served both sides of the market: B2B vendors and B2C customers. Mirela's team was responsible for leading a global initiative that tried to aggregate technical systems and harmonise user experience across different markets. This involved removing features and deleting lines of code. Especially on the B2B side.During this process, a feature was removed that was embedded in certain contractual agreements with B2B customers. Once implemented, the removal triggered a reaction from affected customers. This ultimately resulted in legal threats and intense pressure on the product and support teams.The concept of “Contract debt”Mirela's story reminded me of a number of situations I've experienced myself working in B2B SaaS companies. I've also been in a situation where we've removed or changed features, that were included in some old customer contracts.Just as technical debt accumulates with quick fixes, "contract debt" arises when sales teams introduce custom clauses or features to close deals. Over time, these special cases restrict a product teams' agility. These custom clauses can be wide-spread across multiple contracts and might be protecting certain areas of your product. The product team might not be aware that certain parts are “protected”. It can become difficult to gain an overview of this ‘contract debt’. It will also hinder product teams in designing the best user experience possible. Sometimes it might be necessary to remove features. For example, when the product team has found a better way of solving a problem.Contract debt therefore not only hurts scalability revenue-wise, but also hinders innovation.How to avoid and deal with contract debtIn a healthy SaaS company with a well-established product-market fit, customer contracts should ideally be standardized across the board. This consistency enables the product team to deliver an exceptional user experience and fully realize the scalability advantages of SaaS. When your team is tasked with maintaining unique features for individual customers, it disrupts efficiency and undermines the core benefits of the model.Of course, this is the ideal scenario. In reality, the pressures of B2B sales often lead to customized contract clauses. Sales teams, driven by the urgency to close deals, may prioritize short-term wins over long-term strategic considerations. While these clauses might help secure key accounts, they can accumulate over time, creating "contract debt" that limits the product's flexibility and scalability.Here are actionable steps for product teams to manage customized contracts effectively:* Establish Clear Guidelines for Customizations: Define thresholds for when customizations are allowed (e.g., based on deal size or strategic value). Make it clear that deviations from the standard offering are exceptions, not the rule.* Create a Centralized Repository: Use contract management tools to track and document every contractual obligation tied to specific features. This ensures transparency and prevents surprises during product changes* Conduct Contractual Impact Reviews: Integrate a "contractual impact review" into the product development process. Before removing or modifying features, assess the risk of breaching any agreements.* Communicate Proactively with Customers: If changes are necessary, reach out to affected customers early. Explain the rationale behind the decision, highlight potential benefits, and offer alternatives or compensations to mitigate any negative impact.What else die we talk about in the episode?Fractional Product LeadershipFractional product leaders like Mirela step in during times of change—parental leaves, organizational transformations, or post-merger integrations. Unlike traditional product managers who might spend years embedded in a company’s culture, fractional PMs offer fresh perspectives without getting bogged down by internal politics.One of Mirela’s key points was how fractional PMs avoid "empire building" behaviors. Instead, their focus is on outcomes: solving problems, empowering teams, and creating scalable systems that remain long after their engagement ends.The Shifting Job Market for PMsCompanies today are often looking for experienced professionals who can make an immediate impact. Mirela’s advice? If you’re in a stable job, consider staying put for now.A Call for TransparencyMirela also emphasized a broader leadership challenge: the need for clarity and alignment in goals. Leaders should openly share their company’s strategic direction with their teams. Whether it’s preparing for a funding round, an acquisition, or long-term growth, transparency ensures that every decision supports the company’s ultimate objectives.The Future of Product ManagementAs automation takes over repetitive tasks (like data analysis and basic reporting), product managers will need to lean heavily into strategic thinking and decision-making. The complexity of cross-functional collaboration will increase. PMs must master stakeholder alignment, ensuring that teams across engineering, marketing, sales, and leadership are working toward shared objectives.LinksLink to Podcast Episode* 📹 YouTube* 🔊 Spotify* 🔊 Apple MusicIn case you want to reach out, please do so on LinkedIn:* ❤️‍🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast* 🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Problems are at the centre of everything product managers do⤴️ This is one of the first things every PM will learn at the beginning of their career.This mindset is taught in almost every classic PM literature. A few examples:It is my strong belief, and the central concept driving this book, that behind every great product there is someone - usually someone behind the scenes, working tirelessly - who led the product team to combine technology and design to solve real customer problems in a way that met the needs of the business.The first sentence in Inspired by Marty CaganRunning a lean startup is all about "Minimizing waste and maximizing the creation of value by staying closely aligned with what customers actually want and need.”The Lean Startup by Eric RiesYou need to “fall in love with the problem” that you’re solving. This is the biggest driver of startup success. It will help you deliver value to users, tell a more inspiring story about your company, and recruit a team. “Falling in love” means feeling enough passion about the problem that it can drive you to persist through hard times.Fall in love with the Problem, Not the Solution by Uri LevineHowever, we also know that product management in reality is usually different from what is taught in books. Organizations are made up of people and people make processes messy and often not as easy to control as they are taught in books. In this article I tried to dive into one of the examples, where real life is different compared to literature. The example that we touch on here is, that in reality, not all successful product work starts with a problem.Recent examples of (very) successful features that don't revolve around problems* ChatGPT (Valuated at 128% billion $)* ChatGPT + Canva integration (5M+ conversations)* Spotify Wrapped (Cultural event, Reached 156 million users in 2022)* NotebookLM (80,000 organizations are currently using NotebookLM)You might be thinking now These products solve problems!But let me explain.If you as a PM had to write a PRD for these features today, you would have a hard time writing down a problem statement. Especially not one that you could validate. PMs in these companies didn’t find any problems in data from their user base, that would have validated building these features. It would also be difficult to find any general problem statement that would be solved by these features. ChatGPT, for example, solves so many different problems that we don't yet know what else it will solve. Or Spotify Wrapped is a pure entertainment product, which is not known to solve any problems, but still had to be built by a product team.That got me thinking.Does the obsession with customer problems hinder innovation?Product work without a problem to solveI went in search of other features that are similar to those listed above. Impactful, but not problem-solving. Based on this, I have drawn up the following classification:Strategic GrowthThe first category is strategic growth, usually to grow ARR substantially by reaching new audiences or expanding into new markets.Market ExpansionThese features expand your portfolio of features. Mostly through vertical integration. This means that you build a new range of features that in some way fits in with your current main range of features. You open up new adjacent markets. Of all the features listed here, this is perhaps the one that is closest to solving problems. But still, very often you won’t find the problems you’re solving in your current user base. And it’s still often a very risky type of feature as it usually comes with high effort. Often you might be solving problems from a different company. Or you solve a problem, that has been solved 100 times before already, but you want to do it for the 101st time for strategic reasons.Melissa Perry describes an example from a fictional company called Marquetly in her book ‘Escaping the build trap’. The company is building a marketplace for educational courses. When surveying teachers (one side of the marketplace), the company found that teachers needed better video editing features to upload more content. The amount of content uploaded was one of the company's strategic KPIs. While developing video editing features is outside of Marquetly's core business (Education marketplace), it solves a problem that its own customers have. This would be an example of vertical integration, where you solve problems for your own customers.However, there are also other examples of companies solving other companies' customer problems. Spotify's entry into the podcast sector would be an example of this. I'm sure it wasn't a problem for Spotify users that they couldn't listen to podcasts. When Spotify entered the market, the podcast market was much smaller than it is today and most of their users probably didn't have this form of content on their radar. Spotify, however, saw it as an opportunity to leverage their existing strengths (e.g. a great audio discovery experience) to expand their market by offering podcasts as well. This is an example, where Spotify solved a customer problem from a different company. A problem statement could read as something like I am not able to find great podcast content on my mobile phone.Another example would be the takeover of cron Calendar by Notion and the renaming to Notion Calendar. Notion Calendar does not have superior functionality compared to Google Calendar or any other calendar. There was no problem with Notion users not being able to manage their appointments. They simply managed them in another calendar. Notion made the acquisition anyway because it fits with their vision of building a centralized operating system for corporate information. Notion believes that the information from Calendars is important for this.Visibility PartnershipsVisibility partnerships help you to increase your reach. You do this by listing your application in a directory of another application with a higher reach. Sometimes integrations create synergies and solves problems. An example of this would be the integration of Crunchbase and LinkedIn. It's handy that LinkedIn users can now see reviews and funding rounds directly in LinkedIn. This solves the problem of not having to navigate to another site. It's a weak problem, but it can be articulated.An example of an integration that does not solve any problem is the Canva plugin in ChatGPT. There are countless reviews (e.g. here or here) that the plugin is completely unusable. It also has a bad rating in the ChatGPT store (3.1). About a third of all reviews (>100k in total) are 1/5 stars.But: This is still a very successful feature. Not because it solves a problem, but because it creates reach and awareness. It also positions Canva as an innovative company right on the frontier of AI. In the ChatGPT plugin store it’s visible, that more than 5 million conversations have been triggered to date! Apart from the dev costs, which seemed to be kept low on purpose, that's un-paid reach for Canva! Canva's main goal with this plugin was to reach more people for free and position itself as an innovative company.The main objective of increasing reach is also reflected in the quality of the product. Canva is usually known for high quality features. The ChatGPT plugin is simple. Probably too simple. So simple that users don't find it useful. An indication that functionality was not the main goal to be achieved here.Brand PositioningThe second category is Brand Positioning. This includes initiatives like rebrands or viral campaigns. They can e.g. enhance a product’s cultural relevance or generally strengthen its market presence.Virality Drivers & Demo FeaturesVirality drivers have nothing to do with solving a problem. It's all about delighting customers. And this delight must be big. Very big. Virality drivers work by offering a (usually) fun feature that blows people away so that they share it on social media.A good and recent example of this is Spotify Wrapped. Letting you know how many minutes you listened to an artist or what your musical era was called in May is not a solution to a problem. But it is fun! It gets you to share the stats on social media, and that's free reach for Spotify.In the podcast, Stefan and I also discussed the equivalent for this in the B2B SaaS space, which would be “Demo Features”. Demo Features have the only purpose to impress during a demo . These features can add a "wow" factor, making the product memorable and helping it stand out in competitive pitches.Brand RefreshesMost PMs have had this experience, and it's always a challenge to prioritize this work over other product work that solves customer problems: Rebrandings. Rebrandings solve 0 customer problems. The only reason companies are doing it is for themselves. To position themselves better. For better long-term market positioning, but also to attract better & retain better talent. The majority of work is usually done in the design or marketing team. But there are often parts that need to be delivered by the product team. Changing colors, fonts, padding, logos etc. It's just work that needs to be done.The key is to keep the effort as low as possible. Ideally, you have a design system that allows these changes to be made centrally without distracting the engineers from their actual work.Experience OptimisationCategory #3 are improvements in performance or delightful interactions that elevate user satisfaction and loyalty, even without solving explicit problems.Performance UpgradesPerformance upgrades improve loading times. It may come as a surprise to many that this type of feature is listed here. However, the truth is that performance improvements, such as faster load times, are usually not a solution to a customer problem. Unless there is one of the following three reasons:* Your app is actively perceived as slow by users.* Speed is a key value proposition of your application (e.g. Cloudflare or AWS)* You are competing with distractions an

Malte is CPO & Co-Founder at airfocus.In this week we talked with Malte Scholz about his biggest failure story. Malte is the CPO & Co-Founder of airfocus.com. He shared a story about a time, where they decided to build a mobile app for airfocus.They decided to do that not because of customer requests or business reasons, but simply because it was easy to do.“There was this developer who said, ‘Hey, I can build that for $1,000.’ It sounded amazing—so we just went for it”The app was delivered on budget, but the team quickly learned that the real cost was just beginning:* Maintenance Effort: The app required ongoing updates, bug fixes, and feature compatibility with the core platform. Their CTO spent three months rewriting it—time that could have been spent elsewhere.* Distraction: Every product decision thereafter needed to account for mobile compatibility, slowing down roadmap execution.* Sunsetting Isn’t Cheap: Even when they realized the app was a mistake, killing it took significant effort—arguably as much as building it.A lesson that all software builds create work, regardless of how small something initially seems.Nothing is ever “cheap” or “easy” to build. Every line of code carries the hidden costs of maintenance, iteration, and eventual deprecation.Malte’s team learned to approach new ideas with a key question: Are we building this because it’s strategically valuable—or just because we can?What Else We Talked AboutBeyond the app story, this episode dives into:* The Value of Failure: Why even a misstep like the app helped AirFocus refine their product strategy.* AI in Product Teams: How large language models can help PMs with time-intensive tasks like feedback synthesis—but why trendy integrations often fail.* PMs in 10 Years: Why stakeholder management and strategic thinking make PMs uniquely irreplaceable in the age of AI.🎧 Listen NowCurious about how to avoid similar pitfalls in your product journey? Check out the full episode:Spotify: YouTube: https://www.youtube.com/@hotfix-podcast This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

In this conversation, Stefan Pernek and Christoph Bodenstein discuss the complexities of pushing back in professional settings, particularly in product management. They explore the balance between maintaining relationships and advocating for product integrity, the necessity of context in decision-making, and the importance of strategic insights for effective product management. The dialogue emphasizes the need for clear communication and understanding between product managers and leadership to ensure successful outcomes. In this conversation, Stefan Pernek and Christoph Bodenstein discuss the critical role of product managers in ensuring the success of product development. They emphasize the importance of accountability, risk management, and effective communication in product management. The discussion highlights the need for product managers to validate ideas through customer feedback and to understand the various risks involved in product development. They also stress the significance of empathy and listening in decision-making processes, advocating for a culture that embraces risk identification and validation. 00:00 Navigating Pushback in Professional Relationships Chapters11:11 The Importance of Context in Product Management 22:05 Strategic Insights and Effective Decision Making 30:00 Understanding Risks in Product Development 35:00 The Importance of Validation and Customer Feedback 40:03 Effective Communication and Storytelling in Product Management 45:09 Empathy and Understanding in Decision MakingLinksIn case you want to reach out, please do so on LinkedIn:* ❤️‍🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast* 🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/* 🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

🚀 What happens when you empower your team so effectively that they no longer need you?This week on Hotfix, we sat down with Amy Mitchell, a Product Director at Dell, who shared a story about a journey, that changed her. Over the past two years, Amy led the launch of a new managed service offering at Dell. What started as a hands-on role, driving contracts, securing investment, and assembling the product team, evolved into a situation where her team had outgrown her.In Amy’s words:"I woke up one day and realized—I’m not needed here anymore. My team was managing P&Ls, solving customer escalations, and flagging risks before I even noticed them."While many would see this as a career threat, Amy reframed it as an opportunity:“It’s not about being indispensable. It’s about enabling your team to own the work, and moving on to tackle the next strategic challenge.”Empowerment as a PM SuperpowerAs product managers, we often hear about the importance of empowering our teams. But Amy’s experience takes it to a radical level:✅ Handing over responsibility for business and technical decisions.✅ Documenting critical knowledge to ensure seamless handoffs.✅ Recognizing when it’s time to step away.This isn’t just about delegation. It’s about designing yourself out of a role when the team no longer requires your guidance, allowing them to thrive autonomously.Lessons for Every PMAmy’s story highlights three critical insights:1️⃣ Empowerment Is IntentionalFrom the start, she invested in hiring strong cross-functional leaders, documenting knowledge, and focusing on strategy over micromanagement. The result? A team capable of solving problems independently.2️⃣ Your Value Is in Starting, Not StayingThis shift requires a mindset change. Instead of clinging to your role, focus on creating systems and frameworks that allow others to succeed without you.3️⃣ Don’t Fear Redundancy—Embrace ItWhen Amy’s team said, “We’ve got this,” her first thought was: “Am I about to be laid off?” But instead of succumbing to fear, she sought out new challenges and opportunities within her organization.A Call to ActionWhether you’re a product leader or an individual contributor, Amy’s story is a powerful reminder to prioritize being valuable over being needed. How can you empower your team today so they can thrive without you tomorrow?Listen to Amy’s full story on this week’s episode of Hotfix [insert link]. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

In this episode of Hotfix, Christoph and Stefan engage with Alex Ciorapciu, exploring his extensive experience in AI and product management. They discuss the evolution of AI, the challenges of usability in product design, and the cultural differences in software development between Europe and the US. Alex shares insights from his journey with AutoRetouch, emphasizing the importance of understanding user needs and the potential impact of AI on jobs. The conversation culminates in a critique of the German approach to software development, advocating for a more innovative and user-centric mindset.AI is now mainstream and considered by product teams.Many push for AI adoption without understanding its true benefits.Identifying problems should come before applying technology.AI can solve previously unsolvable problems.Usability is crucial in product design and can lead to failure if neglected.Understanding user needs is essential for product success.Cultural differences affect software development approaches.German companies often apply manufacturing principles to software.Innovation in software requires a shift in mindset.AI's impact on jobs is significant and should be acknowledged.00:00 Introduction to AI and Product Management11:25 The Journey of AutoRetouch and Usability Challenges31:43 Cultural Perspectives on Software Development in Germany❤️‍🩹 Follow Hotfix: https://pal.bio/the-hotfix-podcast👤 Follow Alex: https://www.linkedin.com/in/alex-ciorapciu-1891688/In case you want to reach out, please do so on LinkedIn:🎙️ Follow Christoph: https://www.linkedin.com/in/christophbodenstein/🎙️ Follow Stefan: https://www.linkedin.com/in/stefan-pernek-629901107/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com

Stefan Pernek & I just recently finished a podcast with Nils Stotz. It was our first episode for The Hotfix Podcast and I would not have thought that I would be learning so much.Framework for Types of Failures: Basic, Complex, and IntelligentWhen being asked about his failure story, Nils didn't jump right into a story but shared a framework that shows that failure isn't one dimensional. There's different types of failures. One is unavoidable, one is fatal and one is even desired:* Basic Failures: The “oops” moments—avoidable errors due to oversight or missed details. Nils emphasized using checklists and rituals (inspired by fields like medicine) to keep everyone aligned and minimize these small but costly mistakes.* Complex Failures: These are harder to foresee and often arise from cross-functional misalignment. Regular retros and open communication can help teams recognize and address misalignments before they become major issues.* Intelligent Failures: The valuable failures. These are planned experiments meant to teach us something about our users, products, or markets. Nils shared how these “intelligent failures” have saved resources by identifying what doesn’t work early.Pro Tip: This is a great framework in case you're being asked "Tell me about a time when you failed in a job interview" 💡.Experimentation as a Product MindsetNils generally talks a lot about experimentation. I loved his definition of experimentation:Experimentation is any structured approach to gathering evidence for decision-making.Experimentation is not only about running A/B tests, but in his view, experimentation is about systematically collecting information to support decisions rather than solely relying on intuition or observational data.Itamar Gilad's Confidence MeterThe Confidence Meter (borrowed from Itamar Gilad) is a great tool to evaluate different methods of experimentation against each other..Knowing When to Stop ExperimentingStefan Pernek mentioned a time where he and his team weren't 100% sure when to stop an experiment.For this Nils shared an incredibly helpful framework. He suggests to classify all experiments either under "optimization" or "innovation". Whenever we experiment only in the favour of optimising our product we should also stop it faster. Whenever something is in favour of innovating, the risk of failure is higher, when also the potential return could be higher (if successful). So whenever we experiment in favour of innovation it's ok to keep experiments running for longer.A known framework for balancing these two types is also Small bets vs. Big Swings by Jim Collins:* Small Bets: These are low-risk, incremental experiments or optimizations aimed at refining existing features or processes. They usually involve smaller investments of time and resources but can yield reliable, if modest, improvements. Small bets are often used to test assumptions, validate ideas, or optimize minor elements in the product, like design tweaks or UX flows. They’re practical and help teams make continuous progress without jeopardizing stability.* Big Swings: In contrast, big swings are high-risk, high-reward initiatives that focus on transformative changes or bold innovations. These are substantial commitments that could lead to significant breakthroughs or new product directions. Big swings might involve launching a new product line, entering a new market, or radically rethinking a core feature. While they carry higher risk, the potential payoff is also much greater, offering the chance to redefine value for the customer or even reshape the market.SStefan Pernek created a simple, but powerful visualisation for this in the past:When running experimentation work it's important to know for which of these two types of features we're currently experimenting for.Actionable Tips on Communicating with LeadershipAs a last item we talked about a common PM dilemma:A leader asks us to build something. We don’t get to development right away, though.We want to do what’s right and do some additional validation. Not getting to work right away, can come across as being-hard-to-work-with or, even worse, as unreliable. At the same time it's our job as PMs to avoid building something no one wants or needs.Nils’s advice is to always anchor the conversation in strategic priorities. Rather than pushing back emotionally. How to get your message as a PM across matters. One very practical tip is simply announcing what you're going to do before you do it. E.g. saying "I need to push back here a little...". This clearly states your intention.Stefan pointed out that leaders are often under pressure to hit their numbers—whether that’s user acquisition, retention, revenue, or other key metrics. Because of this, they may sometimes push for quick wins or immediate execution on certain initiatives to meet short-term goals. Stefan noted that if a product manager can demonstrate how their proposed approach (like taking time for validation or experimentation) could help achieve those same targets more effectively, leaders are likely to listen.**📺 📻 Listen or watch the full episode here: https://pal.bio/the-hotfix-podcast.**Subscribe to miss future episodes. We still have epic ones coming up! 👊 This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit thehotfixpodcast.substack.com