The Hotfix Podcast

• #010 w/ Tamer El-Hawari: How products fail when the rest of the business isn't ready for them

  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

  --------  

  44:01
• #009: How much discovery is enough?

  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

  --------  

  34:06
• #008 w/ Carlos González de Villaumbrosia: Why Killing Features is Harder Than Launching Them

  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

  --------  

  32:04
• #007 w/ Mirela Mus: A feature removal that breached customer contracts

  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

  --------  

  49:58
• #006: Does Every Feature Need to Solve a Problem?

  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 and attention. This is true for B2C e-commerce websites, for example, where milliseconds matter to convert customers.As a B2B SaaS PM you should look for real impact in your work. That means influencing business metrics, such as revenue, retention or customer satisfaction. A performance upgrade will only influence these business metrics if one of the above points are true. Incremental performance improvements are rarely noticed by users. So, be careful when prioritizing performance improvements over delivering real customer value.UX DelightersThis type of feature is about incorporating playful elements such as micro-interactions to increase enjoyment. They are usually aimed at creating emotional connections rather than solving actual problems. A good example is the Apple Intelligence Suite. Apple is known for playful micro-interactions on the iPhone, but the latest version has taken these to a new level. You can see them all in action via this link: https://www.apple.com/apple-intelligence/.B2B SaaS companies are traditionally more focussed on efficiency and functionality. But some of them also manage to inspire with their UX. I was recently blown away by the Sidekicks AI function from Miro.You can get AI-generated feedback from a domain expert on your content. UI-wise a cursor will move through your canvas, imitating a real person reading through content, dropping comments. Below is an example for a board i created for writing this article:While this experience doesn’t solve a real problem compared to simply adding the comments without the animation, it’s delightful and made the experience memorable for me.There’s also micro interactions that solve real customer problems. @Nesrine Changuel has some great examples in a recent blogpost: While delight doesn’t solve a problem, it often enhances user retention and emotional connection. For specific features it can be also a strategic element that is important for the features success. It’s important though that you find a good balance of not prioritizing them over solving real customer problems. Foundational InnovationThe last category is Foundational Innovation.By definition, enabling technologies are designed to enable advances and applications in a wide range of problem areas. Examples of enabling technologies include large language models such as GPT-3 and GPT-4 as well as historical innovations such as the steam engine, the printing press and the internet. Although scientists do not intentionally avoid certain problems, the development of enabling technologies often involves an open-ended approach.Companies working on such open problems usually operate under very different financial conditions than traditional SaaS companies. The main objective is not to develop a product and therefore not to solve a specific problem. Only very few commercially-focused organizations can afford to invest in such initiatives. A good example is Google, which have a long-lasting culture of open-ended innovations. A recent example that came out of it and was turned into a product was NotebookLM. NotebookLM is a content-repurposing tool. The most popular usecase is to create a podcast from text-documents. This is not a problem any Google user had. It’s still an incredible innovation, which might be turned into it’s own revenue-generating product soon.The bottomline - How do we build products without a problem?If the majority of your work as a PM is not based on solving problems, you are doing something wrong. Solving problems is still at the centre of product managers' work. But after reading this article, you will have seen that there can also be investments that are not centered around solving a problem. However, these are not usual day-to-day cases for PMs. If you’re a PM in a B2B SaaS company with common financial principles, solving real-life problem is still your best shot to making your organization successful.A clear “Why”Even if the features listed above are not based on a problem, there is still a clear why? behind them. In all of the examples listed, it is obvious why the companies have done them and how they contribute to parts of their strategy.You can’t bypass the Why? part behind a feature.Having a clear problem to solve for your feature has many advantages. It forces you to think user-centric. Features that solve a problem have strong product-market fit in-built. Working on features, that don’t solve a problem have a higher likelihood of failing. And failing is expensive.So, whenever you work on a feature that is not connected to solving a problem, make sure you have a crystal-clear why attached to it.The best way to de-risk features without a problem is to ask the following question to 5 different people working on the feature. Ideally from different teams, such as PMM, UX, Engineering, etc.Why do we, as an organization, need this feature?If you don’t get the same answer 5 times, you can assume it will be risky to work on the feature.Podcast Chapters00:00 The Centrality of Problem Solving in Product Management02:31 Exploring Foundational Innovations and Their Impact10:05 The Role of Product Managers in Foundational Technologies15:46 Strategic Growth: Market Expansion and Visibility Partnerships23:53 Navigating Risks in Market Expansion and Partnerships24:19 Startups vs Established Companies: Distribution Challenges25:54 Brand Positioning: Virality Drivers and Rebranding26:44 Demo Features: The B2B Perspective32:06 Experience Optimization: Performance Upgrades vs UX Delighters34:00 The Value of Rebranding in B2B SaaS35:44 Prioritizing Performance Upgrades: When and Why?38:12 Delighting Users: The Role of UX in B2B Products43:15 The Importance of a Clear 'Why' Behind FeaturesLinksLink 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

  --------  

  40:32

More Technology podcasts

Trending Technology podcasts

About The Hotfix Podcast