================================================================================ ALEXANDER HIPP - COMPLETE SITE CONTENT Generated: 2026-04-29T20:12:02.063Z ================================================================================ This document contains the complete content of www.alexhipp.com optimized for LLM consumption. Table of Contents: 1. STATIC PAGES - Core website pages 2. BLOG POSTS - All published articles ================================================================================ PART 1: STATIC PAGES ================================================================================ ------------------------------------------------------------ PAGE: HOME ------------------------------------------------------------ URL: https://www.alexhipp.com/ Summary: Alexander Hipp is a Product Lead at Miro focused on AI. For over 15 years he has built digital products, primarily as a product leader, with hands-on experience in design, engineering, and research. He approaches problems from first principles to deliver clear, practical impact, and writes about product management, AI, and related topics on his blog. Key Points: 1. Product Lead at Miro focused on AI 2. 15+ years building digital products, primarily as a product leader 3. Hands-on experience in design, engineering, and research 4. First principles thinking; clear, practical solutions with real impact 5. Writes about product management, AI, and related topics on his blog Topics: product leadership, product management, Miro, digital products Audience: Product professionals, designers, and those interested in product leadership Intent: Introduce Alexander Hipp and his work at Miro ------------------------------------------------------------ PAGE: ARCHIVE ------------------------------------------------------------ URL: https://www.alexhipp.com/archive Summary: Archive of Alexander Hipp's past work, projects, and writings organized chronologically. Key Points: 1. Historical projects and work 2. Past writings and publications 3. Organized by year Topics: archive, history, projects, portfolio Audience: Those researching Alexander's complete body of work Intent: Preserve and organize past work for reference ------------------------------------------------------------ PAGE: BLOG ------------------------------------------------------------ URL: https://www.alexhipp.com/blog Summary: Thoughts, ideas, and reflections on technology, AI, design, and personal growth from Alexander Hipp, a Product Lead at Miro based in Barcelona. Key Points: 1. Articles on product management and leadership 2. Insights on AI and technology trends 3. Reflections on personal growth and learning 4. Practical advice for product professionals Topics: blog, product management, AI, technology, personal growth, design Audience: Product professionals, technologists, and curious readers Intent: Provide index of blog articles for discovery ------------------------------------------------------------ PAGE: COLOPHON ------------------------------------------------------------ URL: https://www.alexhipp.com/colophon Summary: Technical and design details about Alexander Hipp's website, built with Next.js 15, TypeScript, Tailwind CSS, and Sanity CMS, following principles of minimalism and functional design. Key Points: 1. Built with Next.js 15 App Router, React 19, and TypeScript 2. Styled with Tailwind CSS and shadcn/ui components 3. Content managed via Sanity CMS 4. Deployed on Vercel 5. Inspired by Dieter Rams design principles Topics: web development, design, technology, Next.js, Tailwind CSS, colophon Audience: Developers and designers curious about the site's technical implementation Intent: Document the technical stack and design philosophy ------------------------------------------------------------ PAGE: EXPERIENCES ------------------------------------------------------------ URL: https://www.alexhipp.com/experiences Summary: Alexander Hipp's professional timeline including his current role as Product Lead at Miro, and past experiences across product leadership, investing, and building products. Key Points: 1. Currently Product Lead at Miro 2. Product leadership positions at various companies 3. Investment and advisory experience 4. Company founding and startup building Topics: career, experience, product leadership, startups, professional history Audience: Recruiters, potential clients, and professional connections Intent: Provide detailed professional background and career history ------------------------------------------------------------ PAGE: IMPRINT ------------------------------------------------------------ URL: https://www.alexhipp.com/imprint Summary: Legal notice and privacy information for Alexander Hipp's website, including contact details and GDPR compliance information. Key Points: 1. Legal notice and contact information 2. GDPR privacy policy details 3. Cookie and tracking information 4. Terms of use Topics: legal, privacy, GDPR, imprint, contact Audience: Visitors seeking legal and privacy information Intent: Provide required legal disclosures and contact information ------------------------------------------------------------ PAGE: LOG ------------------------------------------------------------ URL: https://www.alexhipp.com/log Summary: A personal log where Alexander Hipp tracks daily thoughts, interesting links, and quick notes. Key Points: 1. Daily thoughts and reflections 2. Curated interesting links 3. Quick notes and observations Topics: log, notes, thoughts, links, personal Audience: Readers interested in Alexander's daily observations Intent: Share informal thoughts and discoveries ------------------------------------------------------------ PAGE: MOOD ------------------------------------------------------------ URL: https://www.alexhipp.com/mood Summary: A visual mood wall showcasing images that inspire and set the tone for Alexander Hipp's creative work. Key Points: 1. Curated visual inspiration gallery 2. Images that influence creative direction 3. Visual representation of aesthetic preferences Topics: mood board, inspiration, visual, design, aesthetics Audience: Designers, creatives, and those interested in visual inspiration Intent: Share visual influences and aesthetic preferences ------------------------------------------------------------ PAGE: NOW PLAYING ------------------------------------------------------------ URL: https://www.alexhipp.com/now-playing Summary: Real-time display of what Alexander Hipp is currently listening to on Spotify, showing track name, artist, and album art. Key Points: 1. Live Spotify now playing integration 2. Shows current track, artist, and album artwork 3. Direct link to open track in Spotify 4. Updates every 30 seconds Topics: music, spotify, now playing, personal Audience: Visitors curious about Alexander's music taste Intent: Share current listening activity in real-time ------------------------------------------------------------ PAGE: PRODUCT LEADERSHIP ------------------------------------------------------------ URL: https://www.alexhipp.com/product-leadership Summary: Alexander Hipp's professional background as a product leader, including his experience, certifications, and approach to product management. Key Points: 1. 15+ years of product leadership experience 2. Founded multiple companies including a VC-backed startup 3. Reforge-certified product strategist 4. Based in Barcelona, working globally Topics: product leadership, career, experience, product management, biography Audience: Potential clients and collaborators researching Alexander's background Intent: Provide professional background and credibility ------------------------------------------------------------ PAGE: SHELF ------------------------------------------------------------ URL: https://www.alexhipp.com/shelf Summary: A curated collection of Alexander Hipp's favorite things - books, tools, music, and objects that inspire his work and life. Key Points: 1. Curated collection of favorite items 2. Books and reading recommendations 3. Tools and products used daily 4. Personal inspiration and influences Topics: recommendations, books, tools, inspiration, curation Audience: Curious readers interested in Alexander's personal recommendations and influences Intent: Share personal favorites and recommendations ------------------------------------------------------------ PAGE: SPOTLIGHT ------------------------------------------------------------ URL: https://www.alexhipp.com/spotlight Summary: Alexander Hipp has shared thoughts on product leadership, strategy, and building meaningful products through speaking engagements, podcasts, and book contributions across global ProductTank events and industry podcasts. Key Points: 1. Featured in books on Digital Product Management including works by Sascha Hoffmann and Etienne Garbugli 2. Regular speaker at ProductTank events globally (Bern, Stockholm, Nairobi) 3. Podcast guest on product and startup topics including Product People and Product Academy 4. Speaks about product discovery, continuous discovery, and leadership Topics: speaking, podcasts, product leadership, product discovery, ProductTank Audience: Event organizers, podcast hosts, and those interested in Alexander's public appearances Intent: Showcase speaking engagements and invite new speaking opportunities ------------------------------------------------------------ PAGE: WORK ------------------------------------------------------------ URL: https://www.alexhipp.com/work Summary: Alexander Hipp offers product leadership and advisory services for VCs, Seed and Series A/B startups to turn ideas into impactful products, make confident product decisions, and drive rapid growth. Key Points: 1. 15+ years building digital products, including founding three companies and scaling a VC-backed startup 2. 4+ years guiding startups and product teams through the 0 to 1 journey 3. Diverse industry expertise in B2B SaaS, Fintech, Crypto, Marketplaces, Social Networks 4. Reforge-certified in Product Strategy, Monetization, and PM Leadership 5. Helps with product-market fit, prioritization, roadmaps, and team building Topics: product leadership, advisory, startups, product management, consulting, fractional CPO Audience: VCs, Seed and Series A/B startups without product leadership Intent: Explain product leadership services and encourage contact ================================================================================ PART 2: BLOG POSTS Total: 43 articles ================================================================================ ------------------------------------------------------------ ARTICLE: HOW ATOMICO EVALUATES AI STARTUPS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/how-atomico-evaluates-ai-startups Date: 2026-03-25 Author: Sarah Guemouri Categories: Perspectives, AI Summary: Sarah Guemouri sits at an unusual vantage point. As Head of Insights at Atomico, she sees how hundreds of companies are being built, pitched, and evaluated in real time. Her perspective is less about any single product trend and more about the deeper shift underneath: in the AI era, advantage is moving away from features and toward judgment, adaptability, trust, and distribution. Content: #### Main Takeaways - In AI, shipping fast is no longer a signal. It’s a hygiene factor. - Product differentiation is getting weaker, so founder quality matters more than ever. - AI is great at compressing work, but it still struggles with the most important judgment calls. - The winners won’t just add AI. They’ll use it to create operational leverage and more human connection. - As products get easier to copy, brand, trust, and distribution get harder to ignore. #### Venture is becoming more human, not less I lead insights at Atomico, and my job is basically to help the firm make better decisions based on data rather than feelings. In practice, that can mean anything from a broad strategic question about the future of venture to a very tactical diligence on a company we’re evaluating. It’s varied, which I love. No two days look the same. I use frameworks a lot, but honestly, I also make them up on the go. There’s a lot of creativity in the work. What’s interesting is that venture has always had this boutique core to it. You have partners with deep networks, real pattern recognition, strong instincts. That still matters. But data, and now AI, let you scale some of those superpowers. You can consolidate more information, narrow an opportunity set faster, and give more people access to insights that used to live with a few insiders. That sounds like progress, and it is. But it also creates a different problem. As access to information gets democratized, venture gets more consensus-driven. More people are looking at the same signals, chasing the same companies, and reaching similar conclusions. So the question becomes: where does edge come from when everyone has access to the same machine? #### The founder profile is getting cleaner. I’m not sure that’s a good thing. One thing I keep coming back to is how much the founder archetype has changed. Especially in Europe, being a founder used to feel like a strange choice. It was risky. It wasn’t the obvious high-status path. The people who did it often had a slightly irrational level of conviction. Now it’s different. Founder has become a status job. More people want it, which is great on one level. But it also means more people are learning how to game the system. They know what investors want to hear. They know how to present the perfect profile. They know how to tick every box. So now you have this cohort of founders who look amazing on paper. But I’m not sure they’re always the archetype you need to build a moonshot company. Sometimes it feels like they want the upside of being a founder without really taking on the downside. And that changes the texture of what we’re underwriting. #### In early-stage AI, the product matters less than it used to At seed and Series A, you used to look at the team, the product, and the market. The product was still a real signal. You looked at velocity. You asked how fast they shipped. You wanted proof that they could execute. Now, in AI, shipping fast is table stakes. It’s a hygiene factor. Everyone is shipping fast. And because companies like Anthropic keep releasing something mind-blowing every week, the benchmark keeps moving. So even teams that are objectively moving much faster than startups did a few years ago can still look slow by comparison. At the same time, product differentiation is weaker. You look at a space and there are ten companies doing roughly the same thing, plus incumbents, plus the foundation models themselves pushing down into the stack. So it’s genuinely harder to know which product is going to win. That pushes much more weight onto the team. Their adaptability. Their judgment. Their ability to learn faster than everyone else. I think founding team assessment has never been more important. And that’s the part AI doesn’t really solve. It can help consolidate intel. It can summarize the market. It can surface patterns. But at the end of the day, the bet is still deeply human. #### The growth is real. The defensibility often isn’t. The other thing we’re all looking at is this crazy adoption curve. You see companies going from zero to $100 million in revenue in what feels like no time. That changes the psychology of the whole market. Suddenly, everyone is asking why this company has done it and another one hasn’t. But when you drill into some of those businesses, the picture can feel fragile. The revenue is there. The usage is more brittle as the actual workflow differentiation often isn’t quite there. A lot of it still looks like a wrapper around a large language model. The vision is much bigger, of course. Everyone wants to be the copilot for some vertical or function. But in practice, many of these products are still mostly chat. They’re not yet changing the day-to-day job in a way that feels structurally different from what a general-purpose model can do. That doesn’t mean there won’t be great companies built here. There will be. We already see the shift from wrapper to harness, and the step-up in output quality despite running on the same underlying model. But the bar is much higher than people think. #### The real question is: what job does this tool actually own? This is something I think about a lot, both as an investor and as a user. We use tools like Claude internally and the productivity gain is obvious. It’s real. People love it. But I’ve found it surprisingly hard to define what the tool actually is in the stack. What job does it own? What does it replace? Where does it really sit in the workflow? That’s where a lot of AI products still feel unresolved to me. They’re powerful, but the surface area isn't quite right. They help you do many things a bit faster, but they don’t always own a clear, durable job. Right now, tools like Claude often feel like a kickstarter for thinking and doing. A launchpad. They help with research, drafting, synthesis, shaping an idea and creating outputs. But then you still end up in Docs. You still end up in Sheets. You still go back to the tools that anchor the workflow. So the gain is real, but the displacement is slow. And that’s why I think a lot of AI companies are going to struggle. It’s not enough to have a nice set of capabilities that gets you 80% there. You need to solve a deep enough problem end-to-end so that someone will keep paying for your product even when general-purpose models keep getting better. #### We are still designing for today’s workflow, not tomorrow’s What feels unfinished right now is that most AI tools compress steps. They don’t remove them. They help you do the same job faster. They help you get a better first draft, produce a quick prototype, generate a brief, summarize a meeting, structure a memo. All of that is valuable. But it still assumes the old workflow is the right workflow. I’m not convinced it is. The more interesting question is not how I do my current job faster. It’s how the job itself changes. Do I still need the same sequence of steps? Do I still need the same tools? Do I still need the same role boundaries? If you push it to the extreme, right now it feels like the human is doing more of the mechanical work. Moving output from one place to another. Passing context between stages. Acting like the API between systems that don’t quite connect yet. That can’t be the end state. I think the next shift is that we stop optimizing each step and start redesigning the whole flow. The winners will be the teams that rethink the system, not just the task. And then maybe we can start talking about a "platform shift". #### AI is a consensus machine, so proprietary insight matters more One thing I worry about, especially in venture, is that AI can flatten thinking if you let it. It’s very good at giving you the plausible view. The market map. The summary. The rational case. But investing is not about reproducing consensus. It’s about deciding when consensus is wrong. So you need proprietary data. You need differentiated insight. You need judgment. You need to actively challenge the machine rather than let it close the loop for you. That’s true for investors, but honestly it’s true for product teams too. If everyone uses the same models, the same prompts, the same public information, then a lot of output starts to feel similar. The thing that matters is what you bring to it. Your taste. Your weightings. Your perspective. What you decide is important that others don’t. That’s where non-consensus decisions still come from. #### Competitive advantage is shifting toward trust, distribution, and resilience If products are easier to copy, then advantage has to come from somewhere else. I still think the strongest companies are the ones that can articulate value clearly and get customers to it faster than competitors. Execution still matters. Getting to better outcomes still matters. But in AI, I think there are a few things becoming even more important. The first is trust. Especially in regulated markets, trust is not a soft thing. It’s a barrier to entry. It’s why we spend time looking at industries where credibility, compliance, and reliability really matter. The second is distribution. I think this only gets harder. There is more noise, more competition, more products promising the same thing. The ability to establish a brand, build relationships, and earn attention will matter even more. And that too will look very different in the agentic era. The third is resilience. Not just whether the product works today, but whether it still has relevance in future workflows. Does it sit somewhere meaningful in the stack? Does it have switching costs, network effects, proprietary data, real depth? Or is it just a neat layer that gets absorbed as the stack consolidates? That’s the scrutiny now. #### The best use of AI might be to make companies feel more human I actually think one of the biggest mistakes companies can make right now is to assume customers want more AI in every visible interaction. A lot of people are uneasy about it. Some are actively resisting it. So when companies market AI in a way that feels deceptive or cold, I think they’re underestimating the backlash. For me, the better story is the opposite. AI should help companies create a more high-love experience. It should remove admin, reduce friction, and give people more time to care. Some of the most thoughtful founders I’ve spoken to are saying exactly that. They’re not planning to hire huge engineering teams because AI covers part of that. They want to invest more in support and success teams, because that human layer is what will differentiate them. I find that really compelling. We think about AI in a similar way internally. If it can reduce administrative burden, then our team has more time to spend with founders, with companies, with people. That’s where the value is. The brand becomes a reflection of how you show up, how responsive you are, how much trust you build. If you use AI to deepen relationships, it strengthens the company. If you use it to hide from customers, it weakens it. #### There are still businesses you simply can’t fake your way into For all the talk about how easy it is to build now, there are still categories where depth really matters. If you’re building in an industry that is highly regulated, operationally complex, and hard to access, you can’t just spin up a product over the weekend and compete. You need domain expertise. You need the right relationships. You need to understand workflows at a painful level of detail. You need trust. That’s why I’m still drawn to companies where AI is not the product story on its own. It’s a tool that gives operational leverage inside a business that is already solving a serious problem. In those cases, AI can be incredibly powerful. It can improve the revenue line, the cost line, the service quality, the speed. But it’s not the whole moat. It’s an amplifier. That feels more durable to me than a product whose entire proposition is just access to intelligence. #### My own job has already changed On a personal level, AI has absolutely changed how I work. I now have this very dynamic workforce on demand. A researcher, a writer, an analyst, a thought partner. I can use it as a context agent, brief generator, presentation builder, speech writer. That part is real, and I use it all the time. Recently, I used it to help amplify some of our content work. We do a lot around the State of European Tech, and I found I could basically turn the material into presentations and event prep with very little lift. It was kind of wild. It made me realize that the mechanics of producing polished output are getting easier very quickly. Which brings me back to brand. If anyone can generate the polished output, then what people are really buying is not just the content. They’re buying the person, the perspective, the credibility, the signal attached to it. The messenger matters more. I think that’s true for funds. I think it’s true for founders. And I think it’s true for product leaders too. #### What matters now is still what mattered before, just under more pressure I don’t think AI changes everything. But I do think it exposes what was already true. Good companies still need to learn faster than others. They still need to build trust. They still need to understand what job they own. They still need clear positioning, real distribution, strong judgment, and the ability to say no to things that look impressive but won’t last. What’s changed is the pressure. The market moves faster. Product edges erode faster. Consensus forms faster. Noise compounds faster. So the work now is to get clearer, not louder. The teams that win won’t be the ones with the most features. They’ll be the ones that know what matters, what doesn’t, and what still feels true when everyone else is reacting to the latest wave. Perspectives: Honest conversations on crafting great products over a cup of coffee. I sit down with friends across design, data, engineering, ops, and more—people who work closely with product leaders, from PMs to CPOs. We talk about how teams really work, where things break down, and how AI and new ways of working are reshaping the future of product. ------------------------------------------------------------ ARTICLE: WHEN AI STOPS BEING A TOY ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/when-ai-stops-being-a-toy Date: 2026-03-19 Author: Alexander Hipp Categories: Product Management, AI Summary: AI is everywhere. LLMs can draft, predict, recommend and respond faster than any human. Demos look magical, adoption curves spike, and yet P&L statements remain stubbornly flat. We have the technology; what’s missing is the impact. Content: If you’ve worked with AI, you’ve probably felt this gap too. Budgets are crazy high, dashboards get damn pretty, we celebrate AI usage metrics, but the impactful business metrics barely move. Adoption is not the same as impact. The hard question for me isn’t “can it do this?” but “does it change what matters?” According to the State of AI in Business 2025 report by MIT NANDA, 95% of businesses that invest in AI fail to generate measurable business value in return. That's crazy! Below are the five conditions I’ve found essential when looking at AI features. Miss one and you may still ship a clever feature, but get them all right and the work can become leverage and impact. #### Start with a costly, specific problem (always) Most AI projects within established organizations begin with a capability looking for a problem. Someone says, “We should use AI to summarise calls” or “Let’s bolt on a chatbot because everyone else has one.” Or my favorite: “Let the user only do stuff via chat + agent.” Then a product team ships a prototype, pats themselves on the back, and nothing happens. Too hard to implement in the end. Flip the script. Start with a user (or business) problem that hurts a lot. Where exactly are you bleeding cash or time? What is the most important unsolved problem of your user? Is there a manual compliance check that drags on for days? Do reps spend hours stitching information across systems just to respond to a ticket? That is your starting point. Ask yourself: What does this cost us today? How often does it happen? What’s at risk if we don’t fix it? If you can’t answer those questions, you don’t have a problem worth solving. When you do have them, every model choice and data decision ties back to a clear outcome. You might think this is true for every new feature or initiative, but when it comes to AI, most product managers ignore the basics—so that’s our starting point. #### Embed AI into the flow of work Too many tools sit beside the real work of your end users. They generate outputs but don’t change how decisions are made. An assistant drafts replies, but the agent still rewrites everything manually. A model scores leads, but the salesperson ignores it because it’s not part of their CRM. Go back to the drawing board and deeply understand the job of your users and the job map to perfectly understand where AI can 10× or 100× the process—and where it might hinder what is actually working. In the end, the dots have to connect; otherwise, real adoption is never happening. To drive impact, AI must live where the work happens. For example: - The model runs automatically as part of the process. - The output directly shapes what happens next. - There’s no way to bypass it without noticing. Mapping this out can be uncomfortable. It forces questions and decisions about trust, accountability, and error handling. It also creates the space for feedback loops, which is how the system gets better instead of just being impressive once. #### Measure outcomes, not activity My personal favorite. Activity metrics are seductive. DAU goes up, queries explode, automation increases. None of that matters if customer satisfaction stagnates, support costs stay flat, or revenue doesn’t budge. Think about the second-order effects of what you are introducing. To properly track this, you need a deep understanding of how your users and the business define a positive output and outcome from your service. Then define your inputs and strategy from there. Hold every change accountable to those metrics. If the numbers don’t move, the AI is a toy. Clear metrics expose hard trade-offs. You’ll cut features that feel cool but don’t move the needle, and double down on those that do. #### Go where the returns are, not where the applause is Shiny AI gets clicks and applause: flashy dashboards, generative assistants, chatbots with personality. They’re fun to show on stage, but they rarely affect the business at scale. The highest returns often hide in boring processes—invoice reconciliation, contract review, supply chain matching. They consume headcount and introduce delays. Automating them frees people to do higher-order work and drops costs immediately. If you’re tempted by something that is not obviously a painkiller, ask yourself: how much money does this save? How much time does it free up? If the answer is “not much,” resist the urge. #### Redesign roles and accountability Add AI to a workflow without looking at the roles that your users and the business need to play, and you’ll just create friction. If the system makes a recommendation, who’s responsible if it’s wrong? If AI reduces someone’s workload, what happens to their role? Without a clear answer here, you might run into bigger problems and users lose trust. You basically treat AI as a new team member. The goal isn’t to replace people. It’s to pair them with systems in ways that amplify each other. That takes deliberate (service) design. #### Pulling it all together Most AI initiatives fail because they’re treated as features bolted onto existing structures. The ones that succeed treat AI (like agents) as part of the system: - They solve a real, costly problem - They embed the solution into the workflow - They measure success in outcomes, not activity - They invest where the returns are highest - They redefine roles to support the new way of working If you’re serious about creating impact, start there. Otherwise, be honest: you’re doing AI theatre. ------------------------------------------------------------ ARTICLE: WHEN BUILDING GETS CHEAP ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/when-building-gets-cheap Date: 2026-02-17 Author: Alexander Hipp Categories: AI, Product Management Summary: As building becomes faster and easier, the real challenge moves upstream. The hard part is no longer implementation, but judgment. Content: For most of my career, building was the constraint. Discussions about scope were the norm because engineering time was limited. We debated priorities because every feature had a real cost attached to it. Also iOS, Android and web had their own dedicated engineers. Shipping something meant committing resources, attention, and future complexity. You didn’t build lightly. That reality is about to change. With AI tools, better abstractions, and agents that can generate actual working code, building is getting dramatically cheaper and faster. Prototypes and work that used to take weeks now takes hours. Sometimes minutes. Engineers can explore multiple directions in a single afternoon without needing a full planning cycle first. That’s absolutely exciting. It unlocks creativity and speed in a way we’ve never seen before. But it also shifts the center of gravity. When building gets cheap, judgment becomes expensive. #### The bottleneck shifts If almost anything can be built at the same time, the hard question is no longer “can we build it?” It’s “should we build it?” (Actually, in product organizations that has been the case before, but different topic) It sounds obvious, but it changes everything. The biggest risk is no longer moving too slowly. The biggest risk is moving extremely fast in the wrong direction. You can now scale the wrong idea 20x faster than before. You can ship ten features that technically work and still make the product worse. I see teams celebrating velocity while quietly drifting away from the outcome that actually matters. More releases. More output. But not more impact. Shipping is not strategy. Output is not progress. When building gets cheap, measuring success by features shipped becomes almost meaningless. What starts to matter instead is clarity, coherence, and taste. What you decide to pursue. What you deliberately ignore. What survives after serious scrutiny. In other words, judgment is the new bottleneck. #### Roadmap becomes a portfolio When execution speeds up, fixed long-term roadmaps as we still see them a lot these days start to feel more wrong then ever before. If you can test an idea this week, why commit to a detailed monthly plan based on assumptions that may be outdated in a week? The roadmap circus finally becomes less about locking in a sequence of features and more about managing a portfolio of bets. Some small and incremental. Some medium-sized with clear upside. A few bigger bets that could redefine the direction if they work. You run several in parallel. You learn quickly. You rebalance often. (Completely new challenges here on running so many experiments in parallel, also different topic, but one to watch out for.) This shift is subtle in some companies but extreme in others and it changes how all teams need to plan and operate. Planning becomes more dynamic. Less ceremonial. More continuous. Finally! #### Too many changes for humans Today, AI helps to synthesize research, cluster feedback, generate prototypes, and simulate edge cases at a pace that feels almost unfair. Discovery cycles therefore shrink dramatically. But customers do not suddenly think 20x faster. Sales teams do not suddenly adapt 20x faster. Support teams do not suddenly absorb change 20x faster. Humans still need time. If you push too many changes too quickly, you create confusion instead of value. You increase cognitive load. You erode trust. In some B2B contexts, customers may even prefer fewer releases, not more. So restraint becomes a real skill. Just because something can be built and deployed instantly does not mean it should be exposed instantly. Continuous deployment makes sense at a technical level. Continuous release needs to be handled more carefully. Feature flags, gradual rollouts, controlled exposure. These become super critical tools. Move fast internally. Move deliberately externally. #### The PM role shifts If engineers can spin up a first version in a few minutes, then writing perfectly detailed tickets is no longer required. The role shifts. Less translator of requirements. More editor of direction. The value is not in specifying every detail upfront. The value is in defining the problem clearly, sharing the relevant context, articulating what good looks like, and setting boundaries. Then you let the team explore. If what comes back is not good enough, you say so. You refine. You try again. When rebuilding takes minutes instead of weeks, the cost of iteration drops dramatically. That allows the quality bar to rise. But there is one important tension here. If all the customer empathy, research insights, and strategic context live only in the PM’s head, the PM becomes the bottleneck. Even if engineers can build 20x faster, the overall system might only move slightly faster because everyone is waiting for clarity. So context has to be externalized. Strategy, decisions, insights, raw research. Written down. Structured. Accessible. So engineers can move with autonomy instead of constantly asking for permission. The goal is not to control every move. It is to seed direction and then step aside. In that sense, the PM becomes more of a custodian of product quality than the author of features. #### Choosing what not to build When building gets cheap, adding becomes incredibly easy. Removing does not. But the real work increasingly becomes saying no. Not because something is technically impossible, but because it does not align. Because it distracts from the core outcome. Because it adds complexity that will compound in the wrong direction. It becomes easier than ever to justify “just one more feature.” It becomes harder than ever to protect simplicity. The job shifts from pushing for more output to protecting focus and coherence over time. In a world where almost anything can be built, the product is no longer constrained by engineering capacity. It is constrained by judgment. That’s uncomfortable, because judgment is harder to measure than velocity. It is harder to optimize than throughput. It requires taste, pattern recognition, and the courage to say no. But it is also where the leverage now lives. When building gets cheap, thinking well becomes the competitive advantage. ------------------------------------------------------------ ARTICLE: STAYING CLEAR UNDER PRESSURE ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/staying-clear-under-pressure Date: 2026-02-09 Author: Alexander Hipp Categories: Product Management Summary: This is what I have come to believe great product management really looks like when things start to fall apart. Content: Right now, I’m in a lot of interviews while searching for a job, and they often make me reflect on the hardest phases of my career. One question always comes up: What does great product management look like when everything feels unstable? In my opinion, it is not about clever frameworks or perfect plans. In those moments, it's about the basics. Staying clear. Cutting everything that does not matter. Protecting direction. I learned this the hard way during a phase of rapid company growth. We were adding tens of thousands of customers per day, entering new markets, and hiring quickly. I onboarded new people in my second week. It was chaos. Priorities changed constantly. The loudest voice could easily shape decisions, and I noticed how easy it was to add noise instead of making progress. After a while, I started to see patterns in the product people who handled this well. Three traits stood out. I adopted them as principles to follow. #### Choose clarity, not consensus When teams disagree, the instinct is to align. Run another workshop. Create another deck. Find a middle ground. Don’t. I used to do that too. It often led to compromise, not progress. What works better is simpler. Go back to the problem. Anchor the discussion in real customer behavior and a small number of meaningful metrics. Lay out the trade-offs clearly. Once the consequences are visible, weak options usually eliminate themselves. Decisions made this way rarely come back. They stick because they are grounded in reality, not opinion. Today, I see product direction as something you have to design deliberately. My job is to make the problem and constraints so clear that the right path becomes obvious. Storytelling is not only for selling ideas. It is for testing and eliminating them. #### Make sense of messy feedback Feedback is rarely clean. Customers contradict each other. Data points in different directions. Sales and support highlight different issues. Earlier in my career, I tended to react to the loudest signal or tried to fix everything. Both approaches created churn. What works better is slowing down. Lay all signals next to each other. Complaints. Metrics. Edge cases. Look for the structure underneath. Ideally, do this visually. At one point, we were looking at three separate complaints that seemed unrelated. When viewed together on the same canvas, they pointed to the same issue: users did not trust what the product was doing. Instead of shipping three small fixes, we addressed the underlying trust gap. That single move solved multiple symptoms. Now, when feedback feels confusing, I pause. I map the signals before acting. Most surface problems share a deeper cause. #### Be willing to remove Adding is easy. Removing is hard. A feature performs well. The numbers look strong. The team feels proud. The natural move is to keep it. But in fast-moving environments, it becomes even more important to ask a different question: Does this build toward the system-level goal, or does it distract from it? When building is fast and cheap, we need to revisit existing functionality more often than ever. I remember a feature that users loved, but it drove engagement away from the core outcome we cared about. We removed it. There was short-term friction and a few complaints, but long-term retention improved. Now, I evaluate work not just by local performance, but by whether it compounds toward the whole. Is this feature impactful enough for the bigger goal? If not, it may not justify staying. #### What I’ve learned Under pressure, great product management is not loud. It is not about complex processes. It is about clarity, pattern recognition, and restraint. Clarity over consensus. Root causes over surface fixes. System goals over local wins. These traits are easy to overlook because they are quiet. They do not show up in feature lists or sprint reports. And they definitely do not show up easily in interview stories about past successes. ------------------------------------------------------------ ARTICLE: NOTES ON USING AI IN PRODUCT WORK ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/notes-on-using-ai-in-product-work Date: 2026-01-29 Author: Alexander Hipp Categories: AI, Product Management Summary: Generative AI did not only change what product managers are responsible for, it fundamentally changed how much they can own and how much judgment the role now requires. Content: The biggest shift for me is that AI expanded what I can own end to end. Before, my role was mainly bound to framing problems, prioritization, and alignment. Execution across design, engineering, and research mostly happened in coordination with others. Today, those boundaries are looser. I still own the core product questions, but I also prototype, explore technical directions, and test ideas directly. AI did not just make me faster. It changed where I spend my time. #### Research became continuous The clearest change for me is in research. Understanding markets, industry dynamics, and incentives used to take days of manual work. Now it happens in minutes. I still decide what questions matter and how to interpret signals, but the mechanical work is largely gone. Research is no longer a phase. It became continuous and mostly automated. #### Solution exploration shifted The second major shift for me is in solution exploration. I use Figma less and write more. I prototype directly in code using tools like Cursor and Claude Code to explore directions and options early. This is powerful but also risky. When building is cheap, volume increases, not necessarily quality. Judgment and taste become the constraint. #### What did not change One area has not changed much for me. Qualitative research. Talking to real users remains irreplaceable. If anything, it has become more important, because AI increases the risk of making fast decisions without real understanding. #### What I hope changes for the PM profession Fewer PMs will be mainly focused on orchestration. The role should become more selective, not more diluted, as it has been in recent years. There should be more focus on strategy, judgment, and long-term direction. When information and execution are cheap, decision quality becomes the main constraint. This raises the bar for accountability. AI removes friction, but it does not remove responsibility. Someone still has to decide what matters, what to ignore, and what to commit to. Those decisions compound over time. I also expect fewer PMs per product. Not because the work disappears, but because leverage per PM increases. One strong PM, supported by AI, can own more surface area than before. PMs will need to be more generalist. Not by doing everything, but by being literate across disciplines. Understanding incentives, user psychology, and financial mechanics matters more when AI amplifies both good and bad decisions. In that world, activity is no longer a good proxy for impact. The profession matures when PMs are evaluated on decision quality and long-term outcomes, not throughput. ------------------------------------------------------------ ARTICLE: HOW AI CONNECTS SALES AND PRODUCT MANAGEMENT ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/how-ai-connects-sales-and-product-management Date: 2025-11-06 Author: Joel Reimer-Eiglmeier Categories: Perspectives Summary: Joel Eiglmeier is Strategic Account Executive for enterprise sales for financial services and insurance at GitLab in Germany. With over fifteen years in software sales, he’s learned that how sales and product teams work together determines whether a company scales or stalls. In this conversation, Joel shares how GitLab’s radical transparency connects both functions, how AI can be used in sales conversations to drive it towards product direction, and why empathy still drives the most meaningful enterprise relationships. Content: From feature factory to strategic partnership The software industry has changed completely in how products are built. I started my career at a thirty-person software company in Hamburg after studying sociology and philosophy, selling knowledge management systems to large German organizations. Back then, the process was simple but flawed. Sales would return from meetings where customers had seen something elsewhere they absolutely needed. Whether it made sense for the product or the market didn’t matter. Every big deal triggered new feature demands. Product teams scrambled, engineering dropped planned work, and technical debt piled up. The loudest customer dictated the roadmap — a pattern that still exists in many places today. The shift toward a real partnership between sales and product took years. In smaller companies, product teams focused on core functionality and reacted to customer RFPs. In larger ones like GitLab, product and sales now shape the market together. At GitLab, I manage enterprise accounts in financial services and insurance, where deal cycles are long and complex. In large software companies, collaboration between sales and product is structured, not reactive. Product shapes direction based on insight, while sales brings context from the field. Both rely on data, not escalation. Building products in public At GitLab, I found that the approach to product development is built on transparency, which is also one of GitLab’s core values. Any GitLab customer can write a feature request, describe what they need, and open an GitLab issue. These issues live in the same environment we use internally. Sales teams can link all relevant customers anonymously to specific issues, adding context about the segment or industry while keeping discussions public. The result is a living record of market needs that both validates and challenges assumptions. Having a clear view on overlapping requests and problems from customers in banking or insurance, we see clear demand. When an issue sits untouched for years, it might not be as critical as it first appeared. This public workflow builds trust. Product managers don’t rely on filtered summaries — they can read real customer input, comment, and follow progress from idea to release. Some issues have been open for a couple of years, others move quickly from concept to production. The key is that everything is visible. That transparency can create the foundation for something powerful: AI can now work on top of structured, open data to connect feedback, context, and action. Challenging customers is part of the job Over the years, I’ve learned that saying yes to everything is the fastest way to destroy focus. You have to learn to challenge customers. That feature might seem essential right now, but does it really fit into their process? Have they thought through how it would actually work? In my early days, the companies I’ve worked at have built many features that customers swore were dealbreakers. We shipped them, and they were never used. They lived in the product, added maintenance costs, but created no value. That taught me that good salespeople don’t just pass requests along — they interpret them. When a customer asks for something, the real question is: what problem are they trying to solve? Is it unique or something others struggle with too? Could we solve it in a broader way that helps the entire segment? Every company tends to believe to be special. Every FinServ says it operates differently. But the truth is, most share very similar challenges — compliance, reporting, data security. The job is to find patterns, not exceptions. That’s how sales insights become product direction. Product transparency meets sales pressure In Sales, revenue is foremost how we’re measured. It also reflects customer satisfaction, market fit, and business health. That pressure is constant, and it’s easy to fall into short-term thinking. But over time, I’ve developed deep empathy for the product side. In many companies, engineering is “rebuilding the helicopter while flying.” If we keep stacking on new features, we’ll never fix the fundamentals. Product teams need protected time to improve reliability, scalability, and user experience. GitLab’s transparency helps manage this balance. The open issue tracker, public roadmap, and regular releases give everyone visibility. Product leaders meet customers directly, while solution architects bridge technical and commercial conversations. Service Pings then close the loop — we can see which features deliver value and which should be retired. Ideally, when a salesperson pushes for a feature and product shows data proving it doesn’t work, that’s no longer a debate. Evidence should replace opinion. It’s collaboration, not confrontation. AI as the connective tissue between sales and product At GitLab, AI isn’t a separate initiative — it’s also an integral part of the product and a part of how we work. From structured notes to shared issue tracking, AI bridges the communication gaps that can slow us down. Enterprise sales is still a people business and I don’t think AI will replace that. Deals can take twelve to thirty-six months, with many stakeholders and decisions. Empathy and judgment matter more than automation. But AI can help to handle everything that gets in the way of those human moments. How we at GitLab use AI tools like Claude to manage documentation and context is kept very transparently in our handbook. When I talk to a customer, I always summarize our discussion so my colleague knows exactly what happened — the customers never has to repeat themselves. That simple step keeps continuity across accounts and ensures product has the right context when new issues or opportunities come up. AI can help turning fragmented human communication into structured knowledge. It connects conversations, documents, and product data — the glue between what’s said in meetings and what gets built later. AI can ensure continuity without replacing relationships. The biggest limitation today is integration. In enterprise sales, you typically use twenty or thirty tools from different vendors. They need to connect so information can flow freely. That’s when AI becomes truly powerful. The future isn’t AI closing deals — it’s AI coordinating the details. Systems that surface relevant documents, next steps, and feature discussions automatically. The bridge between sales and product will be as much technological as human. Size and stage define collaboration The relationship between sales and product depends entirely on company maturity. The basics are the same everywhere, but how they play out changes with scale. In startups, when you’re chasing your first customers, product must listen closely to sales. Every deal provides vital market intelligence. In mature companies like GitLab, product has a broader perspective — usage data across thousands of customers. Product knows what drives adoption and what causes friction. At that stage, sales needs to trust product’s judgment while continuing to surface fresh signals from the field. Whenever I join a new company, I spend the first few weeks simply understanding where it sits on that spectrum. I have coffee chats with both sides. You can’t fix collaboration before you understand context. The human element in digital transformation Despite everything technology can do, enterprise sales will always depend on people. In the not too distant past working for other companies, I’ve seen colleagues walk into meetings without laptops, just to talk. It might sound old-fashioned, but the point stands: relationships drive business. The best sellers blend tech fluency with empathy. I use digital tools for structure but stay present in the room. I still carry a notebook, but often sometimes it’s better not to stare at a screen while someone’s talking. The future is hybrid. AI will take notes, summarize meetings, and manage reminders. Humans will focus on creativity, negotiation, and trust. What matters most is technology openness — staying curious and willing to learn new tools, even when they’re imperfect. That’s how you stay relevant. You adapt, you experiment, and you let technology amplify your judgment, not replace it. Shared lessons For product teams: - Join at least one real sales call each week. - Use shared issue systems instead of private feedback lists. - Publish rolling roadmaps with clear disclaimers. - Protect engineering time for fundamentals. - Base prioritization on data, not opinions. For sales teams: - Document every meeting consistently. - Link customer requests to context and segment. - Review patterns with product regularly. - Use AI for structure and recall, not shortcuts. - Manage customer expectations transparently. Both sides want the same outcome: products that solve real problems and relationships that last. The bridge is trust built on shared context — strengthened by AI. At GitLab I experience what great things can happen, when transparency and technology meet empathy. AI doesn’t replace the connection between sales and product — it deepens it. Open systems, shared knowledge, and structured context make collaboration faster and more grounded. As AI becomes more integrated, the most valuable skills will still be human: listening, judgment, and curiosity. The future belongs to teams that use technology to connect understanding, not replace it. Perspectives: Honest conversations on crafting great products over a cup of coffee. I sit down with friends across design, data, engineering, ops, and more—people who work closely with product leaders, from PMs to CPOs. We talk about how teams really work, where things break down, and how AI and new ways of working are reshaping the future of product. Coffee of the day 1000. Cups · Muhehewe · Madrid [Image] ------------------------------------------------------------ ARTICLE: CONTEXT MATTERS MORE THAN CODE ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/context-matters-more-than-code Date: 2025-10-09 Author: Alexander Hipp Categories: AI Summary: We started with a small test, make the logout button work, and ended up rethinking how we build our side projects with AI. This is the first part of a series documenting what I'm learning while experimenting with coding agents, from writing PRDs for machines to designing the "teams" they work in. Content: #### When code writes itself While looking for my next product role, I’ve been working on side projects with a close friend. We’re building a few tools (more on that soon) and experimenting with AI agents to see how far we can push them—not the “build an app in 10 minutes” type, but ones that could actually grow into real micro-SaaS products. We mostly use Claude Code and Cursor to build features, but lately the output quality has been awful. So we jumped on a call to rethink our workflow and ran a simple test: make the logout button work. Easy, right? Within minutes, Claude spun up a new route, added Zustand for state management, and rewrote unrelated parts of the app. Technically impressive. Practically a disaster. That’s when it clicked. The agent wasn’t wrong—it was just too unconstrained. We had agents.md and claude.md files and some basic setup, but we hadn’t explained how the system worked, what mattered, or what to leave alone. It did exactly what we asked, not what we meant. So we started thinking: how do we make AI build the way we would? How do we get structure, context, and control, without killing the speed? #### Our plan We need to stop to "only" prompt the AI and start specifying and giving more context. Less chat, more structure. The idea is to build a framework inside the repo that gives agents the same kind of context a human teammate would have. We talked about starting with two simple files: /CLAUDE.md or /AGENTS.md — the operating manual A clear guide that explains how the system works and what not to touch. - Overall architecture and folder structure - Non-negotiables and coding standards - Key dependencies and conventions - Deployment and environment details But most importantly, the db schema That’s the foundation. The schema defines the real shape of the data, the relations between entities, and the single source of truth the AI should never override. If the agent understands the schema, it understands the product. It can reason about data flow, relationships, and constraints before touching a line of code. We want the schema to act as the anchor for every decision the agent makes — the bridge between how the system is modeled and how the AI interprets it. /context.md — the running memory A lightweight changelog the agent can read before doing anything. - New routes, components, or configs - Edge cases and gotchas - Known limitations - Design or architectural notes worth remembering Once the schema and context live side by side, the agent has both a map and a memory; the two things it’s been missing all along. [Image] #### From prompts to PRDs After seeing the agents go rogue a few times, we realized that simple prompts and loose context don’t scale. They’re too vague, too easy to misread, and too inconsistent. That’s when we started putting more focus on PRDs. I heard something in a podcast recently that stuck with me: code is cheap, the real value is in the PRD. It’s where clarity lives and where the real debates should happen. If we want consistent results, we need to give the AI the same level of clarity we’d give a human developer, clear, structured specs that explain what to build, why it matters, and what to leave out. Instead of conversational nudges, we want explicit intent: rules, constraints, and definitions that can be reused and refined over time. This shifts AI development from ad-hoc prompting to a repeatable process. We’ll keep them simple at first, probably one PRD per feature, living in a /prds folder. Each one should capture: - Goal and scope - Inputs and data contracts - UI states and empty states - API requests and responses - Out-of-scope notes - Done criteria In practice, these docs become our contract with the agent. They front-load all the context, what matters, what’s fixed, and what success looks like, before execution starts. We can review each PRD together, tweak the wording, and then see how even small phrasing changes affect the agent’s output. The goal isn’t just better prompts. It’s to build a shared language between us and the AI, one that’s precise enough to guide the work, and structured enough to learn from #### Thinking like an organization Halfway through the call, we realized we were talking less about code and more about team design. If one agent can ship a feature, what happens when we run ten in parallel? They’ll need boundaries, just like people. We started imagining small “agent teams,” each with a clear domain: - A frontend agent that owns React components and UI logic - A backend agent that handles routes and data models - A platform agent that maintains shared utils and standards - A spec agent that reviews PRDs before implementation And then each agent team has a specific purpose like being responsible for the onboarding flow or the core functionality. Each one would have its own rules file and coordinate through shared context, not long prompts. It’s basically Conway’s Law for machines: your system architecture will mirror your agent structure, whether you plan for it or not. #### Our first iteration Our first goal is to make this loop work: 1. Review current context and schema 1. Write or update a PRD 1. Run the agent to generate code 1. Review, fix, or rerun 1. Update context.md We want to see if this cycle can self-improve. If the output is off, we fix the PRD or rules instead of rewriting prompts. The workflow should learn as we go. We’ll probably start with two parallel work streams: - Hygiene: small, low-risk things like login, logout, invites - Core product: the more complex logic around our boards, data translation, and audience views The hygiene stream lets us experiment fast. The core stream keeps us focused on the product we actually want to build. #### Where we want to go next We also threw around some bigger ideas we want to test later: - PRD diffing: when one spec changes, downstream PRDs get auto-checked for updates - Visual PRD graphs: nodes as features, edges as dependencies - PRD pipeline: break every task into repeatable steps: plan, build, test, update - Self-updating context: after each PR, the agent logs what it changed - PRD sequencing: Sounds like a roadmap topic. We’re not there yet. But it already feels like the right direction or at least a super interesting one to learn more. Designing systems that teach AI how and why to build, not just what to build. We ended the call talking about how strange this feels. We’re not managing only code anymore; we’re designing a lightweight organization where humans set intent and AI handles execution. That’s where we’ll pick things up next. Exploring what it means to design for synthetic teams, how to structure roles and rules for agents, and what new kinds of product organizations might emerge when the code starts writing itself. Stay tuned for the learnings. ------------------------------------------------------------ ARTICLE: THE WATERFALL TRAP IS BACK ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/the-waterfall-workflow-trap-is-back Date: 2025-08-06 Author: Alexander Hipp Categories: AI, Product Management Summary: You describe what you want in plain English: “a shared calendar app with Slack notifications.” You press enter, and a few minutes later, the AI hands you a working codebase. It runs. It looks polished. It feels like the future. Content: This speed really feels transformative. Yet beneath the surface, a familiar old pattern lies. The workflow is linear, brittle, and quite resistant to change. Vibe coding has reintroduced the very problems that drove software engineering away from waterfall development two decades ago (or a little bit more recent based on the company you work for :D). The technology is new. The trap for product teams is not. #### Same old waterfall, shiny new package Going back a few years, waterfall development followed a tidy, stage‑based sequence: requirements, design, implementation, testing, and release. I still remember the very first product I've built back in the day pretending to know how mySQL and PHP worked while learning it from a book, using waterfall. On paper it looked efficient. In practice, it collapsed under its own weight. Any fundamental change discovered late in the process was expensive and demoralizing. Plus almost impossible to revert. Agile methodologies rose in response, favoring incremental delivery and continuous feedback. Product teams learned to ship smaller increments, validate with real users, and adjust quickly before a wrong assumption lead to technical debt. This was luckily my day-to-day in my first full-time role. But here is what is happening with vibe coding these days and where I see similarities: - Waterfall had big spec documents → Vibe coding has giant AI prompts (PRDs) - Waterfall meant months of coding → AI often generates everything at once The timeline is compressed. The structure is the same. You get great velocity without adaptability (ever tried to easily change stuff without AI after the initial creation?), which honestly feels worse because it tricks you into thinking you are being agile. Here is why this matters. I read about three different startups in the same week that failed this way. They showed beautiful demos to investors, didn't have a technical co-founder because "everyone can code now" and got funding, then spend months stuck when users wanted something slightly different. One team rewrote their entire app four times because they could not adapt the AI‑generated foundation. #### Speed without comprehension Part of vibe coding’s allure lies in its immediate productivity. We feel a surge of progress as entire applications materialize in minutes. This early success, however, conceals the erosion of understanding that underpins sustainable development. AI‑generated code often arrives with minimal inline documentation and little architectural context. Decisions about structure, dependencies, and scalability are embedded in the model’s output rather than the team’s collective reasoning. Prompts and commits serve as the only record of intent. Similar to waterfall. where teams got buried under documentation that quickly became obsolete, vibe coding swings to the opposite extreme: functional code with almost no shared comprehension. In both cases, teams lose the confidence to change what they do not fully understand. #### Feedback loops that fail to loop Agile succeeded by insisting that feedback must not only exist but must shape the work in short, observable cycles. Build, measure, learn, adjust—repeat. Vibe coding creates the appearance of iteration while often denying its substance. Generating new features is trivial, yet the moment feedback demands a fundamental change—a different data model, a shift in architecture, a new user journey—the linearity of the workflow asserts itself. Rewrites become more appealing than true adaptation. This is the essence of velocity without learning. Products evolve through accumulation rather than insight, and technical debt accrues invisibly until it becomes unavoidable. #### The human role in an AI‑driven workflow AI does not remove the need for human oversight; it intensifies it. Without guidance, vibe coding drifts toward a fragile, one‑way process that accelerates short‑term output at the expense of long‑term adaptability. Product managers and technical leads can mitigate this by insisting on a hybrid approach: 1. Treat prompts as exploratory tools rather than specifications. 1. Deliver in small, testable increments. 1. Maintain shared understanding through light documentation and team ownership. 1. Prioritize learning velocity over shipping speed -> sustainable pace comes from knowing why a feature works, not just that it does. #### A sustainable approach to AI‑assisted development The most effective teams treat AI as an accelerant, not an autopilot. They pair the raw speed of generation with deliberate, human‑driven iteration. They maintain tight feedback loops and protect the collective comprehension that enables true agility. This hybrid AI development approach preserves the benefits of modern workflows while avoiding the quiet reintroduction of waterfall’s failures. It ensures that products remain flexible, comprehensible, and capable of evolving as user needs shift. The conclusion: speed is not enough Waterfall was not abandoned because it was slow. It was abandoned because it could not adapt. Vibe coding risks repeating that failure at ten times the speed. Teams that allow AI to dictate the workflow will produce code quickly but understanding slowly. They will generate demos that impress, then stumble when the second or third iteration demands structural change. The organizations that succeed will use AI as leverage, not as a replacement for thinking. They will pair generation with judgment, speed with reflection, and output with ownership. AI can write the code. Humans still make it a product. ------------------------------------------------------------ ARTICLE: HOW FLODESK DESIGNS FOR QUALITY IN THE AGE OF AI ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/how-flodesk-designs-for-quality-in-the-age-of-ai Date: 2025-07-20 Author: Yuri Martins Categories: Perspectives Summary: Yuri leads the product design team at Flodesk. In this piece, he shares how stepping into a new role changed how he thinks about quality, how the team is using AI to prototype smarter, and why taste still sets great products apart, especially when everyone can build something fast. Content: #### Main Takeaways - Scaling design means codifying what used to be intuitive. - Everyone can build now, taste is what sets you apart. - AI speeds up the how, but you still need to care about the why. I joined Flodesk as a principal designer, working side by side with Rebecca, our CDO and one of the founders. We were just two people on the product design team, figuring things out together. I designed across the product. Feedback loops were tight. We made fast calls. Now we’re six designers, the company has tripled in size, and my role looks very different. I still pair with designers, but most of my time is about enabling others, making sure the team is set up to succeed, and that we’re all designing with the same core mindset. #### From individual decisions to shared principles When it was just two of us, we didn’t need to write anything down. We talked, we iterated, we shipped. But with a bigger team, we realized how much lived only in our heads. What does “good” mean here? What’s the right level of craft? What trade-offs are okay? We started writing things down. We talked as a team about what we value, how we design, and what principles we want to guide us. Not just design principles, but product principles. Something everyone could use: PMs, engineers, support, marketing. Because otherwise, we’d all design and build in different directions. And we started seeing that: people solving the same problem in very different ways, because we hadn’t taken time to get aligned on the problem in the first place. So now we spend more time in discovery. Talking to our members. Looking at real feedback. Doing competitive research. Getting clear, not just on the problem, but on how we, as Flodesk, want to solve it in our very own way. #### Quality means more than polish I used to think quality was in the details like the spacing, the rhythm, the animations. And it definitely is. But I’ve also come to see it’s in much more than that: how fast something loads, how clearly it’s written, how well it performs overall. Design doesn’t ship a product on its own. You need engineers who care about how things feel. PMs who care about clarity. Copywriters who care about tone. Customer Support who keep the service quality high. When quality is shared, it shows. #### How we’re using AI We started experimenting with tools like Lovable, v0, and Figma Make. Every Monday, the design team meets for an hour. We each bring a small prototype and explain how we built it, just to learn together. What worked? What didn’t? What did you try? If it’s a multi-screen flow, we still use Figma’s native prototyping. But for a focused interaction, something small, specific, high-fidelity, these tools are great. Faster than Figma. More real. Easier to test. We’re still early, but it’s helping. The whole point is to reduce the gap between idea and something you can actually look at and react to. These tools do that. #### Everyone prototypes now, and that’s good PMs share Lovable prototypes with us. Founders too. Some are rough, some are surprisingly good. It’s never about ego. If someone shares a better version of what I was trying to do, great. We learn from each other. The product gets better. That’s what matters. There’s less “imagine this” and more “look at this.” That clarity helps. It also raises the bar, not just for design, but for how we work as a team, between product, design, and engineering. #### What still makes the difference? Taste. Taste is how you show what you care about. It’s how you make decisions when the tools don’t tell you what to do. It’s what makes your product feel like yours — not like something the internet built. > “The product is a reflection of who you are.” That line from Jony Ive at a podcast with one of the Stripe founders from a few weeks ago stuck with me. And I think it’s more true now than ever. AI isn’t something to be afraid of. Whether you’re scared or excited, it’s coming. So you might as well be curious. Keep learning. Try things. Don’t let fear freeze you. But most importantly stay true to yourself and develop your personal taste. Curate and collect things you like. We still need people who care. Who think in systems. Who pay attention to the little things. Who see the bigger picture. That hasn’t changed. It’s just gotten faster. And that’s exciting. #### Perspectives: Honest conversations on crafting great products over a cup of coffee. I sit down with friends across design, data, engineering, ops, and more—people who work closely with product leaders, from PMs to CPOs. We talk about how teams really work, where things break down, and how AI and new ways of working are reshaping the future of product. #### Coffee of the day Playground Coffee Roasters · Single Origin Coffee Huila · Hamburg [Image] ------------------------------------------------------------ ARTICLE: YOU’RE NOT THE USER ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/you-re-not-the-user Date: 2025-07-16 Author: Alexander Hipp Categories: Product Management Summary: Why product teams drift from reality and how to stay anchored in it. In product, we love to talk about being “user-centric.” But staying user-centric, especially in the messiness of building, scaling, and shipping, is much harder than it sounds. Content: I've wanted to write this article for years. Every organization I worked for or talked to over the years is guilty in its own way. Every team I’ve worked with truly wants to build the right thing for their users. Why wouldn't they? They’re smart, fast-moving, and care deeply. But then, when digging deeper into how we decide what to build and where our work comes from, a familiar and dangerous pattern shows up over and over. Somewhere along the way, we start operating more from assumption than reality. Not because we're sloppy or arrogant, but because we're deep in it. Juggling sprint commitments, internal expectations, fire drills, bonuses, analyses, prestige. The world inside a company is loud and opinionated and the world outside gets more blurry. It starts small. A roadmap gets shaped around technical feasibility. A feature is prioritized because a big customer shouted loud enough. A new initiative launches based on gut feel. Nobody stops and asks: Is this what most of our users actually need right now? Is this the most important thing to do? And slowly, the gap opens up between the version of the user we have in our heads, and their real experiences out there. #### A core issue This isn’t just a UX or research problem. It’s a deeper issue in my opinion: > We build based on internal narratives, not external truths. And once we start building for the internal picture of reality, the downstream effects compound: - We prioritize features that don’t get used. - We polish flows that users rarely reach. - We ignore core flows because they are not fancy at the moment. - We measure success by shipping, not by solving. When you zoom out, you realize: this isn’t about effort, it’s about orientation and structure. #### Inside vs. Outside Internally, everything is being prepared to feel coherent. The roadmap is structured. The personas are polished and make sense. The team is aligned around clear metrics and milestones. Externally, reality is way messier: - Users interact with your product sporadically, often under stress, often with half attention. - Their needs shift depending on their company size, their team maturity, the season. - They drop off silently, abandon features without explanation, or churn for reasons that never show up in your analytics. We design and make decisions for a rational, linear user, when the real users are emotional, unpredictable, context-bound. And the further these two worlds drift from each other, the harder it becomes to reconnect. Markets can change overnight but most organizations are too slow to react this fast. #### Why it happens This drift is never intentional but almost all organizations have some kind of gap between their internal and external view of the users. Mostly because it’s baked into the way most companies operate. - Internal urgency wins: There’s always something pressing: the next launch, the sales commitment, the quarterly OKR. These internal forces are loud, visible, and measurable while real user needs are often quiet, invisible, and ambiguous. - Assumptions harden into “facts”: Personas from a past research sprint. Anecdotes from sales calls. That one big customer with very specific edge-case needs. Over time, these fragments become the foundation for big product decisions without anyone double-checking whether they still hold true. - Metrics create false certainty: A spike in clicks is interpreted as engagement. A slight uptick in retention is seen as validation. But metrics without context can mislead. A confused user clicking around desperately might look exactly like a curious one exploring value. - The feedback loop breaks: In many teams, real user input only shows up at the beginning of a project, if at all. After that, it’s silence. And silence gets filled with assumptions. The result? We optimize for what we can control and forget to stay curious about what we can’t see. One problem I have experienced myself over and over. What happens if new information shakes up past decisions significantly? Do you stop doing what you are working on and pivot? Do you change at all? #### And then the system reinforces itself Once the team starts drifting from reality, the system tends to reward staying that way. We celebrate launches instead of outcomes. We reference personas instead of actual users. We default to what feels familiar and manageable, not necessarily what’s real or right. I’ve heard variations of the same phrases too many times: - “Users just don’t get it.” - “This is a critical feature” (based on one stakeholder). - “We already know what they need” (even if that knowledge is outdated). - "I'm in the ICP myself" And in the absence of fresh insight, those narratives harden. The gap widens even more. #### So what helps? There’s no silver bullet. But there are habits, both for individuals and for the organization that I’ve seen can make a real difference. #### What you can do as a PM or founder - Talk to real users, regularly: Not in sprints, but as a rhythm. One short call a week can surface something your dashboards missed entirely. Don’t just ask what they think of your latest feature. Ask what they’re trying to get done, how they work, what frustrates them, what they reach for when they’re stuck. - Dig into behavior, not just numbers: Go beyond the headlines. What are users actually doing? Where do they drop off? Which parts of the product are completely ignored? Segment your data. Patterns often don’t show up until you look at specific cohorts or behaviors. - Make what you learn visible: Don’t let insights die in Notion. Share quotes in Slack. Bring real user stories into team meetings. Make the user feel present in the room — even if they’re not physically there. - Build discovery into your normal week: Not as an extra thing, but as part of how you work. One light usability test. A quick follow-up survey. Ten minutes reviewing heatmaps. The best PMs I know treat user understanding the same way they treat backlog grooming — ongoing, expected, non-negotiable. #### What product orgs should embed - Create space for continuous discovery: Don’t make research something that needs special permission. Give teams recurring access to users. Lightweight, regular, and cross-functional. Make sure it’s easy to listen and even easier to learn. - Validate before, during, and after: Don’t wait until after launch to find out if something works. Validate the problem early. Test the prototype. Follow up post-launch. Make user validation a standard part of your team’s “definition of done.” - Make user insights available: Create a shared library of research findings, support themes, call notes, analytics breakdowns. Make it searchable and accessible not just for researchers, but for everyone making product decisions. - Shift focus from output to outcome: Don’t just celebrate that something shipped. Celebrate when it actually helped users. Track real progress. What’s your version of “7 friends in 10 days” or “2,000 messages sent”? - Build a culture that values evidence: Normalize the question: What do we know about users here? Encourage teams to change course when new insight emerges and celebrate them when they do. #### Final thoughts Staying close to users doesn’t mean running interviews every day or second-guessing every move. It means building habits that keep your team grounded in reality and close to real user's experiences, especially when pressure mounts. The teams that do this well don’t just move fast -> they move with clarity. They don’t chase outputs --> they create outcomes. They don’t just build what they believe --> they build what’s needed. It doesn’t need to be more complicated than that. But it does need to be consistent. ------------------------------------------------------------ ARTICLE: HOW SUPER.WORK BUILDS AI PRODUCTS WITHOUT PMS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/how-super-work-builds-ai-products-without-pms Date: 2025-07-08 Author: Fadeelah Al-horaibi Categories: Perspectives Summary: Fadeelah is COO at Slite (the company behind Super.work), where she helps shape both the product and the business. In this conversation, she shares how stepping out of product management and into a new role gave her a broader lens on what really drives impact and how building AI products has changed how her team works, decides, and ships. Content: #### Main Takeaways - Building AI products means exploring what works, not starting with a fixed plan. - At Slite, there are no product managers, but the team still builds fast and stays product-led. - Moving from product to operations changes perspective: clearer decisions come from understanding the whole business. I’ve worked in product for about ten years now. PM, then Head of Product, and over the last year, COO at Slite. The title still feels a bit weird to be honest as I'm still a Product person but we played around with the title and stuck with COO. When I joined Slite, I was helping build our knowledge base. Later, I helped kick off our second product, Super.work, which started as an AI search layer and has slowly grown into something more workflow-oriented. #### From product specs to business decisions I still do product work—just from a different angle. I’m not as precious about every detail in the interface anymore. I care more about: how do we position this? Will people understand it? How does this help us grow? Back when I was a PM, I sometimes overlooked that part. We built features that looked great, but then sales couldn’t pitch them. I didn’t pay enough attention. These days, I think more like a bridge. I know what marketing is trying to do. I know what’s happening in sales. I watch our costs. That context changed how I make decisions. If I could go back, I think I’d write fewer product specs and more business cases. Ask earlier: how do we explain this to customers? Why would someone actually pay for this? And maybe even more important—I over-engineer a lot less now. Not sure if it’s because I’ve grown, or because I just don’t have the time. But I’ve started making faster, clearer decisions. And I probably have more impact because of that. #### Building AI products is different When we started working on Super.work, it became clear fast that the way we’d built before wouldn’t work. In traditional product, you usually start with a problem. You define the solution, then build toward it. With AI, it’s often the opposite. We explore what’s possible, then figure out if it’s useful. One of our engineers, Antoine, was developing our AI Assistants and realized that we could automate and schedule them. That wasn’t planned—it just emerged. I sometimes write a press release or a short concept doc to give direction. Then someone prototypes something. Then we talk. Then we ship. There’s no long discovery phase. The devs lead with exploration. Designers jump in once there’s something real to shape. And I help frame it all so customers understand it. We’re not solving problems—we’re exploring opportunities. And that’s a big mindset shift. You also can’t design AI features in Figma and expect them to work. You need to see the real thing in action. Without a prototype, it’s impossible to understand what the model is actually doing. And you can’t really QA an AI product in the traditional sense either. You don’t know what summaries your customers are getting. The quality depends on the inputs—often messy docs and unpredictable tools. That’s why we’ve been working on a kind of query planner, so answers become a little more predictable. Still, you can’t control everything. All our paying users are in Slack with us, which helps a lot. We see what people try, where things break, and what surprises them. That feedback loop is gold. #### No PMs, but still product-led We don’t have any product managers at Slite or Super. But we’re still very much product-led. That says a lot. Chris and I split product responsibilities between us. And honestly, I don’t think I’d hire a PM right now unless they were technical and could build themselves. But then that’s what a good product engineer does anyway. That might sound harsh, but I think the product role is changing fast. I didn’t move into operations to leave product behind. If anything, I want to get back to it. But I also saw where things were heading and wanted to broaden my perspective. #### Smaller, faster, more technical teams Looking ahead, I think teams will get smaller and more technical. One person might do the job of what used to be three. We move quickly. Antoine ships a feature in a few days. We announce it. Then we move on to the next thing. I don’t know if we’ll still need big product teams, or agile coaches, or even PMs in the traditional sense. If you’re working in product, you’ll need to be closer to the tech. You’ll need to understand how models behave, what’s possible, and what’s not. The bar is going up. And for companies building in this space—especially in Europe—I hope we see more visibility around who’s doing what. There’s a lot happening, but not many places to actually see it. #### What won’t change Even with AI, some things stay the same. You still need people you trust. You still need clear communication. You still need a good culture. Otherwise, what’s the point? I don’t think we’ll all become robots—or want to. Tools change. Workflows shift. But the human side matters just as much. The idea of going on an offsite with ten AI agents and no humans sounds… deeply boring. #### Final thoughts I’m still learning. I don’t have it all figured out. But working across the business gave me a different kind of clarity. I used to spend a lot of time making beautiful product specs. Now, I spend more time making things happen. I see the bigger picture. And I probably ship faster because of that. For now, it feels like the right place to be. #### Perspectives: Honest conversations on crafting great products over a cup of coffee. I sit down with friends across design, data, engineering, ops, and more—people who work closely with product leaders, from PMs to CPOs. We talk about how teams really work, where things break down, and how AI and new ways of working are reshaping the future of product. #### Coffee of the day Playground Coffee · King Kongo · Hamburg [Image] ------------------------------------------------------------ ARTICLE: QUO VADIS, PRODUCT LEADERSHIP? ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/quo-vadis-product-leadership Date: 2025-07-05 Author: Alexander Hipp Categories: Product Management Summary: In my conversations with PMs and leaders, I keep noticing the same disconnect. This article is an honest reflection on that pattern. Content: Over the years, I’ve seen both inspiring and frustrating examples of product leadership. A few leaders shaped how I think, not through flashy frameworks, but by being clear, grounded, and present. Others made product feel less like a craft and more like a checklist to keep the engine running. While building Beyond, I’ve had the chance to speak with hundreds of product leaders, CPOs, VPs, group leads, founders and ICs. These conversations have given me a wider lens on what product leadership looks like across companies and contexts. No one approach stood out as universally right. But one recurring tension came up again and again. The higher someone sits in the org, the more confident they often are about how they approach strategy and product management. > “We empower our teams.” “We’ve built strong product practices.” But when I talk to PMs in those same orgs, the tone was often more cautious. They describe direction that feels unclear, or decisions made far away without enough context. They don’t always feel led in the way that supports great product work. #### The core disconnect In many organizations I spoke to, the gap between product leadership and product reality is wider than it appears. A common pattern I’ve seen and heard repeatedly from PMs and leaders is this: many senior product leaders haven’t actually been PMs themselves. They’ve come from adjacent roles like design, engineering, growth, or operations. They’ve worked closely with PMs, sometimes even led them. But proximity to the work is not the same as doing the work. It’s easy to underestimate how much context, judgment, and repetition real product work requires. On the other side, I’ve talked to deeply capable PMs, staff, lead, principal, who have done the work. They’ve aligned teams, made tough calls without perfect data, held uncertainty under pressure. They’re ready to lead. But the path from IC to leadership is steep. Often, it’s not a question of skill, but of opportunity and whether the organization knows how to nurture that shift. That’s not to say product leaders from adjacent backgrounds can’t thrive, many absolutely do. But the pattern I kept hearing was hard to ignore. Here’s where things break down: - Leaders who haven’t done the job themselves - Practitioners who have, but can’t step up to lead - And a middle layer slowly losing trust in both directions #### How this manifests A PM sits between a leader who talks about “customer love” and engineers who need answers about APIs for example. They end up translating all day up, down, across. They’re not shipping or working on product; they’re managing misalignment in multiple directions. Shreyas Doshi put it well: Good PMs work hard and feel overwhelmed. Great PMs work hard and don’t. In my opinion, the difference is often the context in which they operate. When PMs have to bridge gaps that shouldn’t exist, they lose the space to do their actual job. Instead of doing discovery for users, they’re doing discovery for leadership. Instead of learning about the market, they’re figuring out what their own execs really mean. They spend more time managing up than moving forward. It drains energy and kills momentum. In my conversations I could clearly see their frustration. I’ve seen great PMs being burned out. Not because product is too complex, but because they’re constantly interpreting unclear strategy, filling in the blanks left by leadership. What often fills this gap? Process. More docs. More check-ins. More alignment theater. But process doesn’t fix a broken understanding of what product work actually takes. Even industry veterans like Marty Cagan and Petra Wille, who mainly focused on the importance of empowered teams, have recently shifted emphasis toward better product leadership. That pivot says something. Maybe the real issue isn’t the PMs. It’s how we select and support the people leading them. Paul Adams, Intercom’s CPO, also pointed to this in his writing several times: real product sense comes not from proximity to the work or formal process, but from deep customer understanding, rich context, and hands-on experience. The industry doesn’t lack tools. I've learned this the hard way trying to build and selling a tool for product leadership. It lacks leaders who guide with context, not control. Who prioritize coherence over consensus. Who’ve done the real work and still remember how hard it is. #### The root causes - Underestimating the craft: Product management requires context, judgment, and repetition. You can’t shortcut those by watching from the sidelines. Leaders who’ve never held the role often lack the intuition needed to guide teams through messy trade-offs. - Narrow promotion pipelines: Many orgs struggle to recognize leadership potential in ICs. Instead of supporting their growth, they look for ready-made leaders, often from outside the craft. - Misplaced trust in process: When context is missing, companies try to fill the gap with process, docs, check-ins, alignment theater. But process doesn’t compensate for lack of real understanding. - Oversimplifying the spectrum: Not all non-PM leaders are disconnected. Some make exceptional product leaders. And not all ex-PMs make good execs. It’s not about background, it’s about whether you truly understand and support the work. #### So what does good product leadership look like? In my opinion, it comes down to three core things: - Clarity – Helping teams make sense of complexity and direction - Judgment – Supporting sound decisions without micromanaging - Product Thinking – Building a shared understanding of what good looks like Simple. Good leaders stay micro-informed without being micro-managing. They show up to user interviews. They sit in team critiques. They follow the trade-offs behind decisions. They stay close enough to understand what’s happening, and far enough to let teams own it. This isn’t about org charts or new titles. It’s about reconnecting product leadership with the actual work, the craft of product management. In most sports, the best coaches and trainers are former players. People who’ve lived the game. They earn trust because they’ve felt the pressure, made the plays, and know what it takes to win. Product should be no different. Leading well means understanding the work from the inside. #### What you can do - If you’re in leadership: Stay close. Not to micromanage, but to understand. Watch user interviews. Sit in team critiques. Follow the reasoning behind technical trade-offs. Know what your teams are navigating, not just what they’re delivering. - If you’re a PM aiming to lead: Don’t wait for a title. Lead by how you work. Help others find clarity. My personal favorite: Visualize and create understanding. Build alignment where it’s missing. Influence without needing authority. In my opinion leadership is always a skill, not a fancy title or promotion. Product management is a craft. When leaders forget that, the work gets harder for everyone. Support and advocate for the people doing it well. Build organizations where good product work can happen. In the end, it doesn’t matter where you came from, what matters is your commitment to becoming a great product person, wherever you are in the journey. ------------------------------------------------------------ ARTICLE: HOW MIRO RUNS STRATEGIC USER RESEARCH ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/evidence-beats-opinion-how-miro-runs-strategic-user-research Date: 2025-05-23 Author: Josh Morales Categories: Perspectives Summary: Josh leads user research at Miro, where they turn real user insights into strategic decisions. Here, he shares how they've turned user research from something nice to have into a critical strategic function that helps them to make smarter decisions every day. Content: #### Main Takeaways - Evidence from actual conversations shapes truly valuable decisions. - Collecting more data isn’t useful unless it clearly impacts your product choices. - Three short conversations can reveal big opportunities and quickly convince leaders of research’s value. [Image] #### User research as a strategic advantage At Miro, we strongly believe that listening to real people is critical to our survival. It's not enough just to build features; we have to ensure these features genuinely solve real problems for our users. The first thing I emphasize is that talking to even a single user is better than not talking to any. Teams that rely on evidence rather than opinions consistently lead their markets, and that's exactly what we're striving for at Miro. User engagement today isn't just best practice—it's essential for being competitive. I often compare user research to chess: If you can't see the board clearly, you can't make strategic moves. Research gives us this clarity, helping us understand precisely what users need and how Miro fits into their workflows. Without research, building a product roadmap is merely guesswork. #### Quality of insights over quantity It’s not about conducting more research; more doesn’t necessarily mean better. The key is ensuring every insight leads to meaningful actions. The real challenge isn’t collecting data; it’s turning findings into decisions that directly improve our products. To quickly demonstrate research value to leadership, we’ve adopted a practical approach—simple yet impactful studies. For example, just three user conversations, each around 30 minutes, recently uncovered why users struggled to find a key feature, directly prompting a redesign. These quick demonstrations clearly show leaders how immediate and valuable user insights can be. #### Structuring the research team A critical decision for us was how to structure our research team. We considered two options: an agency model, with researchers joining temporarily as needed, and an embedded model, where researchers integrate deeply into product teams. At Miro, we chose the embedded model because continuous involvement and deeper context consistently lead to richer insights and better product decisions. When building our team, we prioritize researchers with strong domain expertise and match seniority to the complexity of their projects. This ensures our research remains effective and meaningful, avoiding overwhelming junior researchers. #### Bridging analytics and qualitative research Another essential part of our approach is fostering close collaboration between researchers and our data analytics teams. Data analytics show us what users do, but research helps us understand why. By combining quantitative data with qualitative research, we gain comprehensive insights that significantly inform our product decisions. We actively encourage this collaboration because it doesn't just happen on its own—it's intentionally cultivated. #### Turning insights into actions with AI We use an AI-powered repository that organizes past research insights, making them easily accessible. However, documentation alone isn't enough to drive action. Real impact comes from regular rituals—team meetings, backlog discussions, and roadmap planning sessions—that keep insights at the forefront of decision-making. AI helps us handle data quickly, transcribing interviews and summarizing initial patterns, but it remains just a starting point. Human interpretation provides the essential nuance and emotional depth needed for truly valuable insights. #### Looking ahead: The future of user research We're excited about continually evolving our research methods. Our future focus includes maintaining continuous user engagement through always-on participant pools and positioning researchers as strategic facilitators who guide teams in asking the right questions. We aim to prioritize powerful research questions over merely gathering data. For teams looking to enhance their research practices, our advice is straightforward: - Start small with targeted studies to quickly prove value. - Decide early on the appropriate research model. - Strengthen collaboration between researchers and data analysts. - Actively track insights and their impact on decisions. - Utilize AI tools effectively but rely on human judgment for deeper insights. At Miro, we firmly believe great products start by asking bold questions, actively listening to users, and swiftly turning insights into actions. This approach has transformed our user research from a supporting function into a central strategic driver of our ongoing product success. #### How product managers and researchers work best together I've learned that the best outcomes can happen when product managers and researchers actively collaborate. Researchers aren’t just data collectors; they're strategic partners who help spot assumptions, challenge biases, and uncover overlooked insights. We encourage frequent joint participation in planning and roadmap sessions, ensuring insights directly shape product decisions. By turning research into an ongoing, dynamic conversation—not just occasional reports—we keep user insights consistently integrated into our decision-making process, ultimately leading to better, more successful products. #### Perspectives: Honest conversations on crafting great products over a cup of coffee. I sit down with friends across design, data, engineering, ops, and more—people who work closely with product leaders, from PMs to CPOs. We talk about how teams really work, where things break down, and how AI and new ways of working are reshaping the future of product. Coffee of the day SlowMov · Alexis Ramirez · Barcelona [Image] ------------------------------------------------------------ ARTICLE: OWNING THE OUTCOME ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/owning-the-outcome Date: 2025-04-24 Author: Sebastien Phlix Categories: 1% Collective Summary: Seb is a product person who doesn’t just think like a founder, he operates like one. Leading product at Alan Spain, he brings a grounded, high-ownership mindset to everything he does. In this piece, he shares how he thinks about strategic decision-making, staying close to customers, and building conviction, not through decks or processes, but through action and impact. Content: #### Main Takeaways - Impact matters most. It’s not about how you get there, but whether it made a difference. - Stay close to the problem: talk to people, pitch ideas early, and listen with empathy. - Align teams through shared ownership and clarity, not over-polished artifacts. - Think like a founder: measure success with business outcomes, not vanity metrics. - Avoid using experimentation as an excuse for poor execution. #### Who are you in a nutshell? What do you do, and why do you do it? I’m a product manager and I’ve been leading the product team at Alan Spain for four years, after previous roles at N26 and Typeform. I’ve always gravitated toward products that are well-designed, opinionated, and genuinely improve people’s lives, whether that’s in health care, banking, or even how we fill out forms. I do this work because I care about creating experiences that are both delightful and meaningful. #### What’s your setup? What tools and products do you use? I like to keep things simple. I work a few days a week from a coworking space and the rest from home. I have a simple home office setup with a standing desk, but nothing fancy. It's pretty much a MacBook and good headphones. #### What’s your biggest challenge at the moment? The challenge is to choose between different potential directions, as well as deciding how much to invest into different areas of opportunity, balancing stakeholders and time horizons. The hard part isn’t the frameworks, it’s finding the time and mental space to actually think deeply while still executing. #### In your opinion, what defines a top 1% PM? It’s simple: impact. Not credentials, not frameworks. Just, did you actually make a difference? Too many organizations are filled with smart people who ship products & features that don’t matter. What matters is that what you worked on moved the needle for real people or for the business. #### How do you rapidly validate ideas with minimal resources? Start by talking to people. Really talking to them, understanding workflows, listening deeply. That’s how I build conviction. Once I have that, we put something in people’s hands and see how they use it. For example, we launched a flexible benefits product by having deep conversations with experienced HR managers. That context shaped almost everything about the product, together with a solid financial analysis of the unit economics. #### Can you share an example of using Opportunity Solution Trees? I’ve used them several times, especially when the problem space is broad or unfamiliar. They’re great for mapping out complex spaces, like improving product differentiation or reducing claim costs in health insurance. They help you visualize trade-offs and guide team conversations. I’ve also used them as a coaching tool with other PMs. #### How do you make confident decisions with incomplete data? First, know whether it’s a one-way or two-way door. Most decisions are reversible, so just make the call and move. For the big ones, I try to break the decision down, mitigate risk, and lean on my intuition, which is only trustworthy if I’ve spent enough time close to the problem. That means talking to customers, staying in context, and understanding the system deeply. Alan has a strong bias toward speed: make the call at 70% confidence and learn through action. That mindset, plus staying on the same scope for four years, has helped me build sharper instincts and better pattern recognition. #### How do you balance quantitative and qualitative data? They’re not trade-offs, they complement each other. Quant tells you what, qual tells you why. Relying only on numbers leads to blind optimization. Relying only on anecdotes leads to noise. I stay close enough to the problem to sense when a number doesn’t tell the full story, or when a quote is just one person’s view. #### What systems do you use to keep discovery continuous? I don’t force a weekly cadence. Instead, I stay embedded in the work: in Q1 alone, I joined 75+ sales calls and now I’m helping with renewals. That keeps me close to the customers without needing a separate discovery process. When big decisions come up, I front-load conversations and learn fast. #### How do you go beyond surface-level feedback? It’s empathy and people skills. Listen closely, not just to what’s said, but what’s not. Look for honesty. Build trust. If someone’s holding back, find someone else. You’re looking for real transparency, and that only comes with the right people and the right environment. #### How do you present your vision and maintain alignment? The key is clarity, why does this matter, and how does it make the world better? The best format is visual and customer-facing: not a dense document, but something like a landing page or an ad. Show the product. Make it tangible. Once people understand the why and can rally behind it, momentum will start to build. Keep the story simple & consistent, iterate on execution, and only revisit when alignment starts to drift or the context changes. #### What non-traditional metrics do you use? At Alan, I’m measured on business impact, things like ARR. It goes against the common advice that PMs shouldn’t own metrics they can’t fully control. But it pushes me to think like a founder. I don’t just care if a feature gets adopted, I care if it helps us grow. That mindset fosters collaboration across sales, marketing, and product. We’re all in it together. #### How do you build a culture of experimentation? From what I've seen, the biggest risk isn’t that people don’t experiment, it’s that they call bad execution an experiment. “We’re just learning” becomes an excuse. I push for rigor: clear learning goals, thoughtful design, and respect for the user’s experience. In B2B with long sales cycles, we don’t A/B test everything. Instead, we pitch ideas early, get feedback before we write code, and only ship when it’s polished enough to be valuable, even if scoped down. #### Can you describe a time when new information made you pivot? It happens regularly. We revisit product strategy every 6–12 months. The challenge is knowing what’s signal and what’s noise. The key is to communicate clearly: here’s what happened, here's what we're doing about it, and here's why Sometimes you change course. Sometimes you double down. But the narrative has to make sense. For your customers, your team, your stakeholders, and for yourself. ------------------------------------------------------------ ARTICLE: BRINGING STRUCTURE TO CURIOSITY ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/bringing-structure-to-curiosity Date: 2025-04-14 Author: Hernán Garcia Categories: 1% Collective Summary: Hernán brings two decades of experience and an unshakable curiosity to his role as Head of Product at rebuy. From web design beginnings in Argentina to leading cross-functional teams in Berlin, his journey is defined by transformation: from creator to connector, from building things to building value. Content: In this article, Hernán shares how he fosters experimentation, balances discovery and delivery, and measures success in ways that truly reflect customer value. #### Main Takeaways - Great PMs are consistent: structure enables speed, clarity, and better decisions. - Empower teams by lowering the cost of experimentation and questioning your own assumptions. - Use sentiment trends alongside classic metrics to speed up learning in lower-traffic environments. - Continuous discovery needs to be logistically and emotionally easy for teams—not just a mandate from leadership. - Your environment shapes your performance; success is rarely a solo act. #### Who are you in a nutshell? What do you do, and why do you do it? I could go metaphysical and say that who we are is not necessarily what we are — but let’s skip that. I’m a product person who stumbled into this path after realizing I wasn’t a very good designer. I started in web design over 15 years ago, then discovered marketing, and eventually found product management, which to me is just marketing in disguise: solving customer problems while delivering value to the business. I love building things—but more importantly, I love building things that people love. And in recent years, I’ve added a strong business lens to that mix. It’s this blend of curiosity, empathy, and pragmatism that keeps me excited about product work. #### What’s your setup? What tools, frameworks, and products do you use? I’m pretty minimal. I work on a 13-inch 2020 MacBook Pro, and when I’m in the office, I upgrade slightly with an external monitor. That’s about it. Tool-wise, I’m heavy on Google Docs for writing and basic analysis, and I use Miro when I need to organize thoughts visually or collaborate on discovery work. We don’t follow frameworks religiously, but we’re definitely influenced by Teresa Torres and the continuous discovery mindset, especially things like assumption testing and continuous interviewing. At rebuy, we’re flexible with our hours, so I generally work Monday to Thursday, 9 to 6, but I adapt based on life and those wonderful random sparks of inspiration. #### What’s the biggest challenge for you at the moment? I’m working on a product that people use infrequently—think second-hand phones or laptops. On top of that, the fact that it’s refurbished adds a layer of hesitation for many buyers. So growing this product isn’t straightforward. What’s been crucial is building the right team: people who are naturally curious about our customers, who have an experimentation mindset, and who collaborate well. That foundation is helping us make real progress, even if the challenge is far from solved. #### In your opinion, what defines a top 1% product management professional? It might be unpopular, but I think environment plays a massive role in someone’s performance. You can have all the skills and mindset, but you’ll only shine in the right context, with the right people around you. That said, if I had to name one trait, it’s consistency. The best PMs I’ve worked with don’t reinvent the wheel every time. They have systems. They’re predictable in a good way. That structure lets them move faster and deliver more value. #### How do you consistently identify high-impact opportunities and validate ideas quickly? We usually start by estimating the potential impact—rough calculations, nothing fancy. Sometimes, you realize a small amount of engagement can already move the needle. That’s worth exploring. Then we move into lightweight validation: maybe we add tracking, maybe we run a fake door test. If the data looks promising, we build something scrappy that delivers real value to customers and gets us feedback in a live environment. The goal is always to learn fast, not build perfect. #### How do you make confident decisions when data is incomplete? In practice, every product decision is about balancing value for the customer and value for the business. That’s the north star. Our engineers are deeply involved in the discovery process—they help frame hypotheses, join research calls, and build early concepts we can test. Sometimes we push horrible code into production, learn something important, and either kill it or refactor it properly. It only works because we’ve built trust between functions. #### What does continuous discovery look like for your teams? We’re not quite at “textbook continuous,” but we’ve made it a lot easier for teams to talk to customers. Every PM and PD has access to tooling: in-app surveys, a database of research-friendly customers, and platforms like UserTesting. We also partnered with user research to upskill the team so they can run their own interviews and usability sessions. It’s not about perfection—it’s about making discovery a low-friction habit. #### What metrics do you use beyond the usual suspects? Most of my work is in e-commerce, so the defaults are things like add-to-cart and conversion rate. But if you only focus on those, you avoid working on things that don’t directly move them, or you run A/B tests that never reach significance. So we started using sentiment metrics. We ask customers how valuable they find something we built and track the trend over time. It’s not about the exact number—it’s about the direction. It speeds up learning, even if we can’t always put a business number on the impact. We mix these with traditional metrics to get a fuller picture. #### How do you foster a culture of experimentation? We experiment even when we’re skeptical. Sometimes the team suggests ideas I personally don’t believe in—but I tell them, “You don’t need to agree with me. You’re allowed to try it.” The only red line is anything that might harm the business. Otherwise, we keep the bar low for testing. One thing I emphasize is that A/B tests are the most expensive way to experiment. We use assumption testing, break down solutions into small, testable parts, and aim to fail fast. That’s unlocked a lot more innovation because we can test more ideas with fewer resources. #### Can you share a time when new information made you pivot? The economic climate of the past few years has been characterized by uncertainty and increased costs. Many companies, including ours, had to shift their focus from growth to profitability. This meant halting some of our plans and concentrating on short-term strategies to improve monetization.Initially, these changes were met with skepticism from some team members. Our environment typically fosters bottom-up initiatives, but the need for rapid execution necessitated a top-down approach. To facilitate understanding and acceptance, I held Q&A sessions with the team, explaining the situation transparently and providing data-driven reasoning behind the decisions. Ultimately, the team embraced the initiatives, took ownership, and successfully iterated upon them. This experience provided a valuable lesson for the team: top-down initiatives, while sometimes met with resistance, can be effective in achieving rapid results. ------------------------------------------------------------ ARTICLE: LINDY EFFECT ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/lindy-effect Date: 2025-04-01 Author: Alexander Hipp Categories: Product Management, Mental Models Summary: Timeless product principles often outlast the latest trends and buzzwords. Content: Most product managers (myself included) are constantly tempted by the newest trends and emerging technologies. The Lindy Effect reminds us that longevity itself is often the best predictor of future success. This mental model prompts us to consider: - What enduring principles underlie successful products? - Are we building for temporary hype or lasting value? #### The Theory The Lindy Effect posits that the longevity of an idea, technology, or principle predicts its future endurance. Popularized by Nassim Nicholas Taleb, it suggests that things that have stood the test of time are more likely to continue lasting. For example, classic technologies like bicycles or foundational principles like simplicity have demonstrated remarkable staying power, often surpassing the latest tech fads. #### Product Management Applications Embracing the Lindy Effect helps product managers build lasting value: - Identify Timeless Principles: Prioritize enduring customer needs like convenience, reliability, simplicity, and human connection. - Strategic Planning: Focus on what won't change—consistent user needs—rather than chasing fleeting trends. - Resilient Technologies: Adopt technologies that have consistently solved fundamental problems over time. Jeff Bezos famously employed Lindy thinking by building Amazon around customer desires that remain stable over decades, such as low prices, fast delivery, and wide selection. This strategic anchor has fueled Amazon’s sustained growth and dominance. #### My Personal Extension: Fostering Long-Term Product Vision The Lindy Effect isn't just about product strategy—it transforms organizational culture by encouraging long-term thinking and resilience. Great product leaders leverage the Lindy Effect by: - Regularly challenging teams with the question, “What won't change for our customers in the next decade?” - Ensuring strategic bets align with enduring principles, reducing reactionary pivots to short-lived trends. Adopting this mindset fosters a culture focused on stable foundations and continuous improvement, rather than constant pivots. Companies like Apple exemplify this by continuously emphasizing simplicity and intuitive design, principles which have reliably guided their success through decades of technological evolution. ------------------------------------------------------------ ARTICLE: WHY MAKING CONFIDENT PRODUCT DECISIONS MATTERS MORE THAN EVER ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/why-making-confident-product-decisions-matters-more-than-ever Date: 2025-03-18 Author: Alexander Hipp Categories: Product Management Summary: Making great product decisions has never been more important - or more challenging. With increasing pressure to deliver impact, teams can easily fall into a cycle of rushed, low-confidence choices that weaken their products. This article explores why confident decision-making matters, why it’s harder than ever, and how to build a process that leads to stronger, more reliable outcomes. Content: #### The Cost of Bad Decisions Bad product decisions can trigger a vicious cycle. One poor choice leads to weak results, which in turn increases pressure on the team and produces an even weaker product. This Decision Doom Loop traps teams into churning out low-value features under stress, often transforming the team into a “feature factory” instead of a value driver. The more pressure mounts, the more the product suffers, leading to further bad decisions. It’s a downward spiral that many teams struggle to escape. [Image] The business impact of this doom loop is severe. If a typical product team costs around €1M per year, a large portion of that investment can go to waste when 50–70% of product ideas fail. In fact, Leah Tharin notes in her newsletter that you need about €2M in successful outcomes just to break even, and on the order of €3–5M in returns to truly be worthwhile. In other words, a weak stream of product decisions is financially unsustainable. As Tharin bluntly puts it, if your product team isn’t generating roughly 3–5× its cost, it’s effectively operating at a loss. This high cost of bad decisions means organizations simply can’t afford to stay stuck in the doom loop. > €2M in successful outcomes just to break even #### Why It’s Harder Than Ever to Make the Right Decisions Building great products has never been easy, but it’s arguably harder now than ever before. Over the past few decades, product decision-making has evolved dramatically. In the 1990s, decisions were largely business-driven, dictated by top-down business goals. By the 2000s, teams became more user-centric, prioritizing user research and UX. The 2010s brought a data-driven era, where A/B tests and analytics guided choices. And today, in the 2020s, product teams are expected to be impact-focused, tying every feature to outcomes and ROI. Each layer—business needs, user experience, data evidence, and impact accountability—adds complexity. A modern product manager must juggle all these factors, which raises the stakes on every decision. [Image] Our recent JTBD study for Beyond confirms how complex prioritization and decision-making have become. The top challenges reported were quantifying the actual impact of their decisions, providing clear visibility into the “why” behind each decision, and supporting decisions with solid data and evidence. Teams also struggle to gather relevant data without slowing down progress. In other words, not only do PMs have to make the right call – they have to constantly prove and communicate that it’s the right call. It’s no surprise that experts often say prioritization is the number one challenge in product management today. When you’re balancing impact, transparency, and evidence all at once, making confident decisions can feel like walking a tightrope. > Prioritization is the number one challenge in product management #### How to Build Confidence in Product Decisions The good news is that the same loop dynamics can work in your favor. By deliberately improving how you choose what to build, you can create a Confident Decision Loop – a virtuous cycle that is the opposite of the doom loop. When a team makes the right decisions, it sees great results, which boosts confidence and morale. [Image] That increased confidence means less panic and pressure, leading to a stronger product and better subsequent decisions. Each success effectively reinforces the next success. So how can product teams foster this positive momentum? Here are a few key steps to build confidence in product decisions: Set the right conditions for good decisions Ensure the team has an environment that balances desired impact, continuous learning, and reliable execution (delivering output) before diving into solutions. This might involve clearly defining success metrics, running quick experiments, or aligning on strategy, so that decisions are made with context and focus. Good decisions rarely happen in a vacuum; they stem from the right prep work and mindset. Trust your instincts but verify with data Great product leaders develop strong intuition over time, but they always check the facts. Use real user data and signals to validate assumptions. If your gut says an idea will solve a problem, back it up by looking at customer feedback or experiment results. Act when you have meaningful insight, not just a hunch. This blend of gut feeling and evidence ensures you’re not flying blind. Communicate decisions clearly Confidence grows when everyone understands the rationale behind a choice. Be transparent about what you don’t know yet and any assumptions you’re making. Explain your decisions in clear, simple terms so stakeholders and team members grasp the “why.” By openly admitting uncertainties and sharing the reasoning, you build trust. Even if a decision is bold or risky, people are more likely to rally behind it when they see the logic and honesty behind your thinking. By closing the feedback loops and following these practices, product teams can escape the doom loop and reinforce a culture of confident decision-making. In an age where every feature investment counts, building this confidence isn’t just nice-to-have – it’s become a critical ingredient for product success. Each smart decision today paves the way for even better decisions tomorrow, creating a resilient product that can thrive under any market pressure. ------------------------------------------------------------ ARTICLE: BUILDING PRODUCTS USERS LOVE THROUGH EMPATHY, RIGOR, AND DEEP CUSTOMER INSIGHT ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/building-products-users-love-through-empathy-rigor-and-deep-customer-insight Date: 2025-03-17 Author: Meagan Entoft Categories: 1% Collective Summary: Meagan combines empathetic leadership with rigorous attention to detail to shape intuitive product experiences. As a product leader at Flodesk, she keeps users at the heart of every decision, deeply invested in empowering small business owners through thoughtful and beautiful design. From her home base in the Pacific Northwest, Meagan shares insights on maintaining simplicity amidst complexity, building deep customer understanding, and why true product success always comes down to people. Content: #### Main Takeaways - Great product experiences start from genuinely understanding user problems, not competitor checklists. - Maintain simplicity while evolving sophisticated features through rigorous design iteration. - Deep, consistent customer listening uncovers high-impact opportunities others might miss. - Balance quantitative metrics with the irreplaceable value of customer sentiment. - Cultivate alignment and buy-in through clear communication and structured processes. #### Who are you in a nutshell? What do you do, and why do you do it? I’m a mom, wife, sister, aunt, daughter, manager, peer, and friend. Personally, I do my best to live intentionally and adventurously alongside my husband to give our daughter the best life we possibly can. Professionally, I’m a product leader at Flodesk who’s deeply invested in helping small business owners understand and utilize the power of email marketing. [Image] #### What’s your setup? What tools, frameworks, products do you use? Where do you work, how is your work schedule? It wasn’t always this way, but my husband and I both work from home and have spent nearly every day together since March 2020. After my home office turned into a nursery in 2023, my workstation moved to our den. My desk is a DropTop (super sweet UK-based company) which can be folded up when I’m done for the day. On it, you’ll find AirPods for meetings, Bose headphones or Loop earplugs for focus time, coffee, ergo mouse and keyboard, and my Ugmonk Analog to-do list cards. That last item is my favorite. I love writing things down and having a consistent reason to look away from my screens. Flodesk is a truly global team, and because of that, my schedule is pretty flexible, with a lot of work happening asynchronously. I usually start my day coordinating with my design partner (shoutout to David!) in Spain, have flexibility throughout the afternoon, and check back in with our engineers in Vietnam in the evening. This schedule probably isn’t for everyone, but I love being able to easily take the time I need for personal care and appointments during the day. [Image] #### What’s the biggest challenge for you at the moment, and how do you plan to overcome it? Two of the most important tenets of Flodesk are great design and ease of use. One of our biggest challenges is maintaining the ease and simplicity that has made Flodesk so loved and successful while continuously iterating and releasing the more sophisticated features our members crave. We attempt to overcome this in two ways. First, we make sure we have a deep understanding of the problems our members are trying to solve. We don’t build features just because our competitors have them, but because we truly believe our members would benefit from them. We conduct regular interviews and user testing to ensure the features we release are intuitive and aligned with their needs. Second, we’re absolutely rigorous in our product design process. We take our time mulling over potential solutions to ensure we land on the right one. Explore. Iterate. Explore. Repeat. We don’t release features that we’re not extremely proud of. While I believe there is power in aligning on a direction and sticking to it, I also believe there is courage in admitting when something still isn’t quite right and spending the extra time to get it there. You only have one chance to make that first impression. #### In your opinion, what defines a top 1% product management professional? Top product leaders recognize that the customers they’re serving aren’t just numbers or conversion metrics, but complex, nuanced people. They recognize their cross-functional partners aren’t there simply to do their bidding but are partners in collaboration who carry valid and unique perspectives that should be respected. The power is in people, both internally and externally. I really believe that a product manager who has an incredible sense for their customer, but isn’t a shining star in their technical or analytical skills, can build a great product. I wouldn’t say the reverse is true. #### How do you consistently identify high-impact opportunities that others might overlook? You’ll start to see a common thread throughout most of my responses. But my answer here, and in most cases, is listening to the customer wherever they are and learning to read between the lines. I keep a pulse on what our members are saying on socials, in community forums and support groups, on our public feature request board, across user research interviews and surveys, or on blogs that compare us to competitors. The list goes on and on. If you spend time every single week reading or listening to how customers (or potential customers) talk, you become intimately familiar with the challenges they encounter day to day, and you can identify solutions to build a product that will be invaluable for them. #### What systems or habits do you use to ensure that product discovery remains continuous? I love to keep a pulse on the landscape by signing up for the email lists of best-in-class companies and our competitors. I regularly speak with customers, through interviews, user testing, community forums, or surveys. We also created a venue where our customers can share their product feature requests. It is chock-full of creative ideas and allows for upvoting so we can get a sense of what our customers care about most. I also love reading through the comments to hear how the feature would benefit others in the community. Paying close attention to the other tools our members are using and the integrations they’re requesting provides a great window into the current gaps of the product and potential to create more value. #### How do you go beyond surface-level feedback to dig deeper into user needs? I spend time actually talking with our members (surprise, surprise!) regularly. I ask them to walk me through their workflows, what they’re hoping to achieve, and what they’re currently struggling with. We have a really active Facebook group where I regularly browse posts and conversations, and speak directly with members about issues they’re encountering. Between the Facebook group, a large group of partners and members who’ve opted in to give early feedback on product ideas, and a great program to incentivize members to complete our surveys, we’ve established processes to get quick feedback across different channels. Putting in the time and resources to create those channels and processes will benefit you so much down the line. ------------------------------------------------------------ ARTICLE: THE MAP IS NOT THE TERRITORY ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/the-map-is-not-the-territory Date: 2025-03-12 Author: Alexander Hipp Categories: Mental Models, Product Management Summary: Roadmaps and metrics are useful guides, but reality often diverges from neat plans. Content: Most product managers (myself included) rely heavily on roadmaps, metrics, and frameworks. But the mental model "The Map Is Not the Territory" reminds us these tools are simplifications, not exact reflections of reality. This model challenges us to ask: - Are we mistaking our models and metrics for the actual user experience? - Where might our roadmap be misleading us? #### The Theory "The Map Is Not the Territory" highlights that representations of reality (maps) simplify, distort, or omit aspects of the real world (the territory). Roadmaps, user personas, and competitive analyses are valuable, but incomplete. Relying on them without validation can mislead your decisions. For example, a user persona might perfectly align with your intended customer but fail to capture shifting behaviors or unexpected needs, leading you astray. #### Product Management Applications Embracing this model improves product management: - Constant Validation: Regularly challenge assumptions in your roadmap by gathering direct user feedback and usage data. - Flexible Planning: Maintain adaptable roadmaps that allow rapid adjustments as new information emerges. - Reality Checks: Institutionalize processes like pre-mortems or red-team exercises to reveal blind spots. A notable example is Netflix. Instead of rigidly adhering to initial assumptions about user preferences, Netflix consistently validates their assumptions through continuous experimentation and real-time data, adjusting their content strategy to better reflect actual viewer behavior. #### My Personal Extension: Systematic Skepticism in Leadership Understanding that “The Map Is Not the Territory” can profoundly shape your organizational culture. Great product leaders embed skepticism and humility into decision-making: - Regularly ask: "What if our core assumptions are wrong?" - Require teams to present disconfirming evidence during product reviews to challenge prevailing biases. This mindset cultivates an organization where it’s safe, and expected, to question plans and strategies, especially when frontline feedback contradicts established beliefs. Leaders who embrace reality checks ensure their teams remain agile, informed, and responsive to actual user needs ------------------------------------------------------------ ARTICLE: CAPTURE AUTHENTIC CUSTOMER VOICES FROM THE WEB WITH AI ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/capture-authentic-customer-voices-from-the-web-with-ai Date: 2025-03-04 Author: Alexander Hipp Categories: AI, Product Management Summary: Understanding your customers isn’t just helpful, it’s essential for building successful products. But with feedback spread across countless platforms, keeping up has become increasingly difficult. Content: This is a clear, actionable guide to capturing real customer voices and turning them into useful input for product opportunities. It shows how to structure research and give you an idea on how to set up a system to get regular user feedback easily. The examples are real prompts I used for Beyond, but you can adjust them to fit your needs. Before using AI for research, I set the stage and let it determine the core problems and ideal customer profile (ICP) on its own. I do this to reduce my own bias. First-principles thinking helps here. - #### Step 1: Set the scene and context for ChatGPT I begin by giving ChatGPT context to lay the groundwork before diving into specifics. This has consistently helped me get high-quality, focused responses. Don’t skip this step. To check if ChatGPT understands my goal, I often have it generate something, like a new approach. Most of the time, the output isn’t particularly useful for the end results but it helps to put the AI into the zone. Model ChatGPT o1 Pro + Deep research Time This step usually takes around 20 minutes Prompt You are a startup founder looking to invent a completely new way for product managers to create decision trees. Before jumping into solutions, start with ground research: - How product managers currently use decision trees - Common pain points and limitations - Existing tools and their drawbacks - Relevant insights from decision-making science Once you have a clear picture, propose a new approach. Focus on what would make decision trees more effective, intuitive, and valuable for product managers. Go! [Image] - #### Step 2: Define ideal customer profile (ICP) To ensure objectivity, I avoid focusing on specific products or solutions at this stage. Instead, I define the characteristics of the ideal customer profile (ICP). Model ChatGPT 4.5 + web Time This step usually takes a few seconds Prompt Browse the web and understand how the ideal ICP for this should look like. - Who currently uses similar solutions - Their roles, challenges, and needs - Industry trends and common pain points - Any existing insights from research or discussions Summarize the key characteristics of the ideal ICP based on your findings. [Image] - #### Step 3: Clarify core customer problems and how they solve it today Model ChatGPT o1 Pro Time This step usually takes a few seconds Prompt Great, now focus on the niche ICP: product managers who use decision trees in their daily work. Summarize briefly in bullet points: - ICP: Who they are (role, company type, experience level, etc.) - Core problem: What they’re trying to solve with decision trees (e.g., OST, impact mapping) - Current solutions: How they approach it today and the limitations they face - #### Step 4: Capture authentic customer Voices from the Web Model ChatGPT o1 Pro + Deep research Time This step usually takes a while. You can run it multiple times as well. Prompt Research real customer feedback on tools used today to solve this core problem. Focus on where current tools fall short. Specifically, look into Vistaly, Miro, FigJam, DoubleLoop, and similar tools. Key requirements: - Only use direct user quotes, don’t invent anything - Provide a link to each quote for full context - Capture both product managers’ perspectives and stakeholder complaints (e.g., Head of Product) - Cast a wide net but stay focused on the ICP - Take as much time as needed. I need extensive user feedback Format the findings as bullet points with user quotes and links. Go! [Image] - #### Step 5: Analyze & identify competitive gaps to inform opportunities Model ChatGPT 4.5 Time This step usually takes a few seconds Prompt Based on the collected user feedback, identify potential opportunities for my product. Key focus areas: - Gaps and pain points in existing tools - Unmet needs mentioned by users - Recurring frustrations that could be solved differently - Any workflow inefficiencies or stakeholder challenges Keep it directly tied to the user feedback, no assumptions or invented insights. [Image] #### Next steps The result should be a list of real customer voices. You might need to refine the approach a few times to get it in the right format. You can also include extras like a “relevance score” or “authenticity” rating. This was my first time testing deep research, and I think a few more iterations could improve the output even further. Listening to customers isn’t a one-time effort, it’s an ongoing process that drives lasting success. Automating this is the next step. Ideally, you’ll reach out to some of these people for real interviews to dig deeper. This is just the starting point to get a broad view of how your ICP sees the problem, their current solutions, and where they struggle. ------------------------------------------------------------ ARTICLE: ALIGNING STRATEGIC GOALS AND TACTICAL EXECUTION FOR PRODUCT EXCELLENCE ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/aligning-strategic-goals-and-tactical-execution-for-product-excellence Date: 2025-03-04 Author: Olivier Maître Categories: 1% Collective Summary: Olivier is a seasoned product leader with a knack for blending strategic foresight with tactical execution. Currently spearheading a new initiative at J.P. Morgan, he combines his analytical roots in strategy consulting with hands-on experience in fintech startups. Olivier believes product success emerges not from singular ideas but from creating systems that empower teams to innovate, validate efficiently, and execute confidently. Content: #### Main Takeaways - Cultivate a team culture where every member contributes ideas freely, preventing bottlenecks and enriching product development. - Maintain a clear balance between long-term planning and daily tasks, ensuring both visionary goals and immediate progress. - Adopt iterative decision-making by testing ideas quickly and making informed bets even when full data is unavailable. - Communicate product vision in simple, measurable terms that align with business outcomes and build trust with sceptical stakeholders. - Continuously review user feedback and performance data to identify opportunities, refine strategies, and change direction quickly when market trends shift. #### Who are you in a nutshell? What do you do, and why do you do it? I’m Olivier, a Product Director based in London, currently leading a new product initiative at J.P. Morgan. My career began in strategy consulting, tackling problems analytically but rarely seeing the solutions through. I craved ownership, seeing ideas become real products that deliver real outcomes. In 2014, I transitioned into product management, initially with Cisco and later at fintechs like Verse and Cash App. My drive has always been curiosity, understanding how things function, and continuously improving real-world user experiences. #### What’s your setup? What tools, frameworks, and products do you use? Where do you work, and how is your schedule? I currently split my work between home and the office. At home, I have a dedicated workspace with a large Dell monitor, a MacBook in clamshell mode, and external peripherals. In the office, flexible desks equipped with dual monitors simplify the transition. With three kids at home, my days are dynamic. I structure mornings and late afternoons for deep focus work, reserving midday for meetings. Mondays anchor the week with one-on-ones, while Thursdays are no-meeting days for deeper thinking. At work, it's a combination of Google Workspace and Microsoft Office. Personally, I value simplicity and therefore rely heavily on Apple’s native productivity suite. I use frameworks like opportunity solution trees to align discovery and prioritization with strategic goals, reviewing them quarterly to stay on track. #### What’s the biggest challenge for you at the moment, and how do you plan to overcome it? The primary challenge now is balancing strategic vision with daily execution. I am one of the leads of a small team building a new product from scratch at J.P. Morgan. This involves defining long-term goals while actively driving day-to-day progress, establishing workflows and processes, writing specifications, and ensuring clarity on immediate milestones. The solution lies in clearly communicated roadmaps, which teams can then take to drive their work how they best see fit. #### How do you consistently identify high-impact opportunities that others might overlook? To begin with, it’s not so much about coming up with ideas that others overlook, but about how they are executed. If 100 product managers were given the same opportunity space, the span outcomes would be very wide Also, I don’t see my role as simply coming up with ideas. Instead, I focus on creating a system where good ideas can come from anywhere in the team. If the team relies on me for all the insights, we risk bottlenecks and missed opportunities. My job is to build an environment where everyone feels confident to bring ideas forward and where we can validate those ideas efficiently. For live products, the one thing I always ensure I do is know the product’s user journeys and their conversion rates by heart. This helps spot issues or opportunities quickly. At Verse, I learned this habit well, regularly reviewing user flows to discover areas needing improvement. It's about systematically noticing what's underperforming rather than searching for elusive, completely new ideas. #### How do you make confident decisions when faced with incomplete or unclear data? Absolute confidence is not possible without clear data. Instead, I move quickly, testing hypotheses to gather better information. Itamar Gilad’s confidence scale helps manage uncertainty by explicitly acknowledging what we know versus what we assume. However, frameworks alone aren’t foolproof because people can always tweak scores to justify already-made decisions. Context and judgement matter enormously and, sometimes, you simply need to make informed bets, then adjust based on outcomes. #### How do you present your product vision to skeptical stakeholders, and what do you do to maintain alignment over time? I found it quite effective to align the product vision directly with business outcomes. If you work for a for-profit organisation, ultimately every decision must either increase revenue or reduce costs. So attempt to explain how your product vision, which should have a broad scope (i.e., it’s not a feature tweak) impacts both. In doing so, the discussion with skeptical stakeholders then revolves around the evidence that underpin your analysis of the product vision’s impact.. For more subjective challenges—like stakeholders not liking a design choice—I focus on having clear reasoning behind my decisions. During my time at frog, client stakeholders sometimes fixate on minor details, like colors (really), and it could derail the discussion. In those situations, even a basic rationale like “we chose green because it aligns with user expectations in this context” can help move things forward. #### What systems or habits do you use to ensure that product discovery remains continuous? Continuous discovery means regularly monitoring the basics, like core conversion metrics and customer support themes. At N26, I saw the value of frequent qualitative interactions, and informal ‘research coffees’ with users surfaced unexpected insights. Additionally, maintaining an opportunity solution tree, updated quarterly, ensures ongoing alignment with strategic priorities, constantly refreshing our focus on the right opportunities. #### What non-traditional metrics do you use to measure product success, and how do these metrics influence your strategy? Beyond standard activation and retention metrics, I pay close attention to user support trends and qualitative feedback. Unexpected spikes in support tickets or recurrent user questions frequently indicate significant but solvable problems. These signals directly influence prioritization, guiding small but impactful improvements. #### Can you describe a time when new information made you pivot your product strategy? At Verse, we initially pursued Bitcoin trading integration, following market trends. Mid-project, user research revealed crypto trading wasn’t a priority for our customers, and broader market adoption was weak. Despite the difficulty, I decided to halt the project, reallocating resources to more impactful areas like regulatory projects and key product improvements. Reflecting afterward, we refined our process to validate ideas more thoroughly upfront, embedding adaptability into our strategic approach. ------------------------------------------------------------ ARTICLE: INVERSION ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/inversion Date: 2025-03-02 Author: Alexander Hipp Categories: Product Management, Mental Models Summary: Instead of asking how to succeed, first identify all the ways you could fail. Content: Most product managers (myself included) naturally focus on achieving success. But inversion, thinking backward, can often be even more powerful. Rather than asking how to win, first ask how to guarantee failure. Inversion challenges us to pause and ask: - What would definitely cause users to abandon our product? - What actions would guarantee failure in this initiative? #### The Theory Inversion means approaching problems from the opposite end, asking reverse questions to reveal hidden risks. Popularized by Charlie Munger, inversion helps uncover overlooked blind spots by focusing on what to avoid rather than just on what to do. For example, instead of only thinking "How can we retain customers?" start with "What would drive our customers away?" It’s surprisingly easier to spot what to avoid than to define precisely how to succeed. #### Product Management applications Inversion can dramatically improve product management. We did this extensively when I worked at a fintech to mitigate potential risks: - Conduct Pre-Mortems: Imagine your project failed. Work backward to identify what caused it, then take steps to mitigate those risks upfront. - Expose Hidden Risks: By listing worst-case scenarios, your team becomes proactive rather than reactive, addressing potential pitfalls before they happen. - Clarify Priorities: Identifying clear failure points helps teams prioritize the most impactful actions to prevent them. #### My personal extension: Creating a culture that learns from failure Inversion doesn't just mitigate risk, it reshapes organizational culture around continuous learning. Great product leaders leverage inversion by: - Rewarding teams for identifying critical flaws early rather than punishing mistakes. - Promoting safe-to-fail experiments, allowing quick learning with minimal downside. This approach transforms failure from something feared into an asset. A real world example is Google’s “moonshot factory” (X) where they celebrate teams discovering major flaws early, recognizing these moments as breakthroughs rather than setbacks. This mindset shift encourages bold decisions and accelerates innovation, helping teams outperform more cautious competitors. #### Great Resources on Inversion - Harvard Business Review - Performing a Project Premortem: Introduces pre-mortems as practical inversion exercises to spot risks before project launch. - Tedx Talk - Invert, Always Invert: Engaging talk highlighting real-world examples of inversion across various fields. - Using Inversion as a Mental Model for Product Management Explains inversion with a clear, practical example of improving user retention. - Mental Models for Product Managers: The Inversion Principle Provides a simple three-step framework (define, invert, avoid) with a product conversion case study. - Seeking Wisdom Episode #147 – “Invert, Always Invert” Short episode demonstrating practical uses of inversion in business and product challenges. - Moonshots Podcast Episode 138 (Shane Parrish: Mental Models) Discusses inversion as a creative tool for solving tough product problems. ------------------------------------------------------------ ARTICLE: OCCAM’S RAZOR ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/occam-s-razor Date: 2025-02-28 Author: Alexander Hipp Categories: Product Management, Mental Models Summary: Your engagement dropped? Start by assuming the simplest reason before diving into complex analytics. Content: Most product managers (including myself, previously) tend to complicate issues by default. We see declining metrics and jump straight into elaborate theories, maybe competitors are stealing users, or perhaps it's a subtle algorithm change. Occam’s Razor challenges us to pause and ask: - What's the simplest possible explanation? - Could a basic issue be hiding in plain sight? #### The Theory Occam’s Razor is about simplicity. When faced with multiple explanations or solutions, choose the one with the fewest assumptions and least complexity. It doesn’t guarantee correctness, but it cuts noise, preventing unnecessary complexity from obscuring your clarity. For example, if your user engagement drops, the simplest reason could be a recent UI change confusing users, not a sophisticated competitor strategy or hidden technical glitch. #### Product Management applications Occam’s Razor has practical, immediate applications in product decisions: - Diagnosing Problems Quickly: Rather than overanalyzing data, first check basics. Did you recently change something obvious, pricing, onboarding flow, or UI? - Prioritizing Features: When teams propose complex new features, challenge them: "Could we solve this with fewer steps or less complexity?" - Communicating Clearly: Simplify complex strategies into clear, concise explanations. If your roadmap or feature plan can’t fit on one slide, you’re probably overcomplicating it. #### My personal extension: The power of simplicity in leadership Occam’s Razor isn’t just about products, it transforms leadership and team culture. Great product leaders simplify decision-making: - Distill strategic decisions down to core factors (user value, cost, technical feasibility). - Push teams to articulate ideas in simple language. If they can't, it's likely the idea isn't fully thought through. Using Occam’s Razor as a leadership tool helps avoid "complexity bias," where complicated solutions seem smarter. Simplicity becomes a sign of clarity, not superficiality. Over time, teams internalize simplicity, creating a culture focused on elegant solutions rather than unnecessary complexity. #### Great Resources on Occam’s Razor - Farnam Street - Occam’s Razor: Straightforward explanation and practical examples of applying simplicity to everyday decisions. - UnTools - Occam’s Razor: Clear guide showing how simplifying your choices enhances decision-making effectiveness. - The Decision Lab - Occam’s Razor: Deep dive into how simplicity improves cognitive clarity and reduces errors. - Nassim Taleb’s “Antifragile”: Highlights Occam’s Razor within complex risk decisions, advocating simplicity in uncertainty. - TED Talk by Alan Siegel - Why Simplicity Wins: Demonstrates the real-world power of simplicity in communication and decision-making. ------------------------------------------------------------ ARTICLE: HOW TO AVOID ONE-DIMENSIONAL ROADMAPS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/how-to-avoid-one-dimensional-roadmaps Date: 2025-02-22 Author: Alexander Hipp Categories: Product Management Summary: Product teams often fall into the trap of weighing only one factor when choosing what to build next. Maybe they listen to the loudest customer requests, bow to an executive’s pet idea, prioritize whatever sales says will close the next deal, or tinker with technology for technology’s sake. The result is a roadmap that leans on a single input and misses the bigger picture. Content: #### Why teams fixate on a single dimension Many teams struggle to compare ideas from different sources in a structured way. Without a clear system to evaluate opportunities, decisions often go to whoever speaks the loudest or whatever feels most urgent. If there's no framework to weigh a customer request against an idea from leadership, the highest-ranking person's opinion usually wins by default. This is a classic authority bias, where decisions favor hierarchy instead of evidence. Without an agreed way to balance different factors like user data, business impact, and technical feasibility, prioritization becomes random. If you don't take a balanced approach, you clearly risk working on the wrong things. Teams are often distracted by high-profile ideas or trendy technology. An executive hears a buzzword like "AI" or "blockchain," and suddenly, the roadmap must include it. We can observe this at the moment every day with another company. This "shiny object syndrome" creates constant distractions, leading teams to chase the latest fad at the expense of solid plans. A flashy feature or a competitor’s new launch can distort priorities, sending resources toward the "idea of the week" instead of improvements that actually matter, like fixing usability issues or addressing technical debt. The urgent tends to overpower the important. [Image] #### Personal biases and Internal politics Human nature plays a huge role in product decisions. Everyone has personal preferences, biases, and agendas that influence priorities: - Confirmation & Ownership Bias: It’s easy to become attached to our own ideas. A product manager might push for a feature simply because they came up with it, losing sight of whether it's actually valuable for users or the business. Without realizing it, they might argue for an idea just because they want it to be right. - Availability Bias: People tend to prioritize what they hear most often, rather than what’s actually representative. If a few vocal customers keep asking for the same thing, it might seem like a major demand, even if most users don’t care about it. The loudest voices don’t always reflect the biggest opportunities. - Company Politics & Seniority Influence: Power dynamics matter. An influential executive can force a pet project onto the roadmap, regardless of its impact. Sales might demand a specific feature to close a deal, even if it’s not part of the long-term strategy. Internal politics often lead to decisions based on influence rather than merit. #### The consequences of one-dimensional priorities When teams rely too much on a single factor, whether it’s customer feedback, executive opinion, or a trendy new technology, the product suffers. Here’s how: - Missed Opportunities: Saying yes to one loud request often means saying no to several valuable but less obvious ones. Focusing on one big customer’s demand might help short-term revenue but delay a feature that would benefit a much larger group of users. - Product Drift: A company that constantly chases new trends or bends to internal politics risks losing its core identity. The product becomes a patchwork of unrelated features rather than a cohesive solution. - Team Morale and Credibility: When priorities keep shifting based on personal opinions rather than clear reasoning, product teams lose confidence. It becomes harder to justify decisions, making it seem like the roadmap is driven by favoritism or random whims rather than strategy. #### Moving toward balanced decision-making Escaping this trap requires a shift in how teams evaluate opportunities. Instead of relying on gut feelings or reacting to the loudest voices, here are some principles for better decision-making: 1. Always evaluate opportunities from multiple angles Every idea should be judged using consistent criteria, such as: - Does it solve a real user problem? - How does it support business goals? - What’s the expected impact versus the effort required? - Does it align with the long-term product vision? By asking these questions consistently, teams can compare different types of opportunities fairly. A customer request and an executive's idea can be weighed side by side using the same logic. 2. Balance your opportunity portfolio Think about product priorities the way investors think about portfolios, spread your bets across different types of opportunities. For example: - Incremental Improvements: Small usability fixes and refinements based on direct user feedback. - Emerging Opportunities: Medium-risk bets based on industry trends or competitive gaps. - Transformational Bets: Higher-risk, visionary projects that could redefine the product. Maintaining a mix prevents overcommitting to one type of opportunity and ensures sustainable growth. I wrote more about this here: https://blog.beyond.so/rethinking-product-prioritization-with-the-opportunity-spectrum 3. Encourage cross-functional input and transparency Decisions improve when multiple perspectives are considered. Bring in input from sales, customer support, engineering, and design when evaluating priorities. Different teams see different problems and opportunities, and diverse perspectives help prevent blind spots. Additionally, making prioritization processes more transparent builds trust. Open roadmap reviews, visible opportunity lists, or structured discussion tools help ensure that decisions are made based on clear reasoning rather than personal influence. 4. Use data to inform (but not replace) decisions A well-rounded decision process relies on a mix of quantitative and qualitative data. That might include: - User research and feedback trends - Product usage analytics - Market research and competitor insights - Financial impact projections Rather than making decisions purely from instinct or hearsay, gathering relevant data helps teams see the bigger picture and make more informed choices. #### Philosophy over frameworks There’s no single framework that will magically fix prioritization. Instead, it’s about adopting a philosophy that values balanced decision-making. The best product strategies don’t come from just listening to customers, just following the CEO’s vision, or just chasing market trends. Instead, great decisions come from weighing multiple perspectives and making deliberate, well-reasoned trade-offs. > Great decisions come from weighing multiple perspectives and making deliberate, well-reasoned trade-offs By avoiding one-dimensional thinking and evaluating opportunities through multiple lenses, teams make better choices, ones that serve users, align with business goals, and contribute to long-term success. The companies that consistently make thoughtful prioritization decisions are the ones that build truly impactful products. ------------------------------------------------------------ ARTICLE: SECOND-ORDER THINKING ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/second-order-thinking Date: 2025-02-20 Author: Alexander Hipp Categories: Product Management, Mental Models Summary: A new feature can drive engagement but also adds complexity, increasing cognitive load and making onboarding harder for new users. Content: Most product people (me included in the past) stop at first-order consequences (e.g, “If we launch this feature, users will engage more”). Second-order thinking goes further by asking: - What happens next? - How will this decision create unintended effects? #### The Theory Second-order thinking helps you anticipate ripple effects beyond immediate outcomes. Instead of stopping at “What happens next?”, you keep asking, “And then what?” For example, a pricing change might boost short-term revenue but drive away your most loyal customers over time. A new feature could increase engagement but also complicate onboarding, leading to churn. By looking ahead, you can uncover both positive and negative long-term consequences. My personal extension: How decisions tipple through organizations Second-order effects don’t just impact users or metrics, they often also shape team dynamics and company culture. A great product leader stress-tests decisions by asking: - If this succeeds, who gains power or workload? - Could short-term incentives create unintended long-term consequences? By mapping these second-order effects, you can align decisions with long-term success. As Ray Dalio notes, first-order benefits often come with second-order costs, ignoring them is a recipe for mistakes. #### Top 10 Resources on Second-Order Thinking (from Theory to Product Applications) General Decision-Making Frameworks 1. Second-Order Thinking: What Smart People Use to Outperform – Farnam Street – Classic introduction to second-order thinking, explaining how looking beyond immediate outcomes helps avoid solving one problem only to create worse ones, emphasizing that the best way to assess long-term consequences is by asking “and then what?”​ articles.data.blog. 1. Second-Order Thinking – UnTools – A practical guide that introduces second-order thinking as a decision-making tool, showing how asking “And then what?” and using 10-minute/10-month/10-year time frames can reveal the long-term effects of choices and ensure decisions “stand the test of time” ​untools.co​untools.co. 1. Second Order Thinking: Thinking Practice To Make Better Decisions – TechTello – In-depth article on applying second-order thinking to everyday decisions and policies, highlighting frameworks to unravel the future implications of choices and avoid the kind of “unintentional and unforeseen outcomes” that result from first-order thinking (e.g. short-term incentives backfiring over time)​ techtello.com​ 1. Second Order Thinking: Unintended Consequences – Howie Mann – A concise 3-minute read outlining why it pays to anticipate second-order effects, with four actionable tips (like remembering “there’s no free lunch” and using Chesterton’s fence) to stress-test decisions so you don’t later regret hidden consequences ​mannhowie.com​ 1. Howard Marks on Second-Level Thinking (YouTube) – A short video in which famed investor Howard Marks illustrates second-level thinking in action – for example, noting that a “great company” might be a bad stock to buy if everyone else has already bid up the price – driving home that you must dig deeper than the obvious and ask more nuanced questions to outperform​ acquirersmultiple.com. Applying Second-Order Thinking in Product Management 1. Mental Models & Second-Order Thinking for PMs – Just Another PM (Sid Arora) – Explores how product managers can use second-order thinking in roadmap decisions, using an Uber feature case study (showing peak demand to drivers) to demonstrate unintended effects – an oversupply of drivers at “peak” times ultimately meant drivers earned less, not more​ justanotherpm.com, underscoring the need to always ask what happens next. 1. The Unintended Consequences of Products that Work Too Well – Pragmatic Institute – A product case study (YouTube’s “Up Next” algorithm) showing how a feature optimized for one metric caused harmful side effects, and asking “What if an ultra-personalized experience is actually a bad thing?” – a real-world lesson that product teams must consider ethics and second-order impacts, not just immediate engagement gains pragmaticinstitute.com. 1. “Stop ‘Protecting Your Team’” – Mind the Product (Amanda White) – Article by a product manager highlighting the unintended consequences of a well-intentioned practice (shielding a dev team from interruptions); it shows that first-order thinking in team management can hurt autonomy and balance, and argues for a more nuanced approach after weighing long-term effects on team health ​mindtheproduct.com. 1. Second-Order Thinking — A Product Super Power – Medium (Blaine Holt) – Persuasive piece that makes the case for product managers to be the constant “voice of second-order thinking” in their organizations – even if it means pushing back on popular ideas – so that the team doesn’t pursue short-sighted wins at the cost of bigger future pitfalls​ blaineholt.medium.com. 1. Podcast: The Black Mirror Test – The Product Experience – A podcast episode (Mind the Product) where product leader Roisi Proven discusses anticipating worst-case scenarios and “Black Mirror”-style outcomes; it’s a practical exercise for product managers to consider all the bad things that could happen with a new product or feature​ podcasts.apple.com, helping teams identify second-order effects and prevent ethical or strategic blunders before they happen. ------------------------------------------------------------ ARTICLE: FINDING THE BALANCE BETWEEN SPEED, FUTURE-PROOFING, AND EMPATHY ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/finding-the-balance-between-speed-future-proofing-and-empathy Date: 2025-02-10 Author: Nick Schweitzer Categories: 1% Collective Summary: Nick blends years of entrepreneurial drive with an unwavering focus on real user needs. Staff Product Manager at Strava, he leads the Maps team with the belief that success lies in getting people outdoors, not glued to screens. In this article, he shares how he balances speedy execution with long-term vision, stays close to user problems, and nurtures a culture of experimentation that turns bold ideas into practical, impactful solutions. Content: #### Main Takeaways - Blend a passion for the user’s real-world context with a methodical approach to problem-solving. - Embrace the tension between short-term delivery and long-term vision by “thinking big, building small.” - Keep product discovery continuous with a mix of automated feedback monitoring and deeper qualitative research. - Bring skeptics on board by visually articulating your vision and pre-empting potential objections with clear data. - Foster a culture of experimentation by lowering the pressure on ideas: “Let’s just try it and learn what happens.” #### Who are you in a nutshell? What do you do, and why do you do it? I’m Nick Schweitzer, Staff PM at Strava. I started my tech journey about 8 years ago when I founded Metadrift, a visual search engine for video archives. This morphed into Klydo, a machine learning tool for user researchers to automate the analysis of user feedback, unfortunately before LLMs were a thing. We raised venture capital, grew the team, and acquired some big customers. After five years of running my own company, I decided to broaden my experience, which is when I started my official PM career. I worked at Slite and then at Intercom before landing my dream job at Strava. At Strava, I lead the Maps team. We’re responsible for every map you see in the Strava product. I took this role because it aligns with my love of the outdoors, exploration, and being active. Strava’s mission is to motivate people to get out there and be active. It’s refreshing to work on a product that benefits when people go outside to run, ride, or hike, not when they spend time glued to their screens. #### What’s your setup? What tools, frameworks, and products do you use? Where do you work, and how is your schedule? I’m fully remote, working from my home in Oxford. Strava has an office in London, so I often go in to socialize and go for runs with the team. As you’d expect, there’s a big running culture here. With much of Strava in San Francisco, my day typically starts later and stretches into the early evening to accommodate calls. The upside is that my early mornings are protected time for trail running in the muddy hills around Oxford. I’m a huge Notion fan for my notes and to-dos, and I love Excalidraw for brainstorming. A PM’s job is all about distilling complex ideas into simple diagrams, and forcing myself to draw them is a great way to clarify my thinking. [Image] #### What’s the biggest challenge for you at the moment, and how do you plan to overcome it? A big challenge I’ve faced in every organization is finding the right balance between shipping quickly and building for the future. Interestingly, this tension exists at all company sizes. Everyone feels pressure to deliver short-term value. There’s no silver bullet, but a product principle from a previous company, “Think big, build small”, really helped. At the design stage (where work is cheap), you go wild with your vision of how to holistically solve the user problems. Then, when it comes to actually building (where work is expensive), you only implement the smallest standalone piece. This means defining scope after doing the design, not before. #### In your opinion, what defines a top 1% product management professional? The best PMs are amazing storytellers. They can articulate a user problem in a crisp, visual, and emotive way, then craft a vision for solving it. Their storytelling secures buy-in from the team and leadership. At the end of the day, a PM doesn’t create Figma prototypes or write code. Their job is to inspire others to do that work, and telling a compelling story is the best way to make it happen. #### How do you consistently identify high-impact opportunities that others might overlook? It sounds obvious, but you have to live and breathe your users’ problems. This means making them as real as possible. Any interview where a user simply talks about their issues is almost useless. The real insights come when they show you what they do, ideally in as real a context as possible. Screen sharing is your friend here. When users demonstrate their real-life workflow or workaround, you uncover the pain points that truly matter. #### How do you approach balancing speed and agility in product development with thorough research and validation? I’ve realized speed and thorough validation don’t have to conflict. One tactic I used a lot at previous B2B companies was co-building. Pick a small number of customers in your ideal profile and iterate quickly with them from problem definition to prototyping. Upfront research points you in the right direction, but no amount of research can truly validate your solution until you put a working prototype in their hands to see if it actually helps. #### What systems or habits do you use to ensure that product discovery remains continuous? Tools for monitoring user feedback are pretty good these days (I would know, I spent five years building one). They collect app reviews, support tickets, Reddit posts, and more, synthesizing them into themes. But even with advanced ML, it remains relatively surface-level. You still need deeper qualitative feedback: actually chatting with users. That’s how you get to the real underlying insights. #### How do you present your product vision to skeptical stakeholders, and what do you do to maintain alignment over time? This is where Excalidraw shines. I force myself to draw my vision first, not just write it down. People can’t buy into something they don’t understand. A good test is whether a stakeholder can sum up your vision to someone else and land the same points. Then, I pre-empt pushback by focusing on how we’ll overcome potential challenges, often with data or evidence. Alignment over time comes from setting clear goals that flow from the vision. Whether you use OKRs or another framework, there should be a direct link between your strategy and your goals. Tracking these goals keeps everyone on board and aligned. #### How do you cultivate a culture of experimentation in your team, and what practices have been most effective in driving innovation? Whether you’re proposing a new product idea or a new way of working, the best approach is: “Let’s just try it and learn what happens. We can always revert or change to something else.” This removes the pressure for the idea to be perfect from the start, and you don’t need to convince everyone it will definitely work. You simply let the trial reveal whether it’s a good idea. That mindset significantly reduces friction and fosters innovation. ------------------------------------------------------------ ARTICLE: A DEEP DIVE INTO VALUE DIMENSIONS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/a-deep-dive-into-value-dimensions Date: 2025-02-02 Author: Alexander Hipp Categories: Product Management Summary: We often find ourselves at the intersection of business goals and user needs. And don’t get me wrong, we’re all happy about that. But while this is a crucial starting point, there’s much more to the story when it comes to creating real value. Content: In this article, I'm going to dive deeper into the concept of value exploration, uncovering its different dimensions and why understanding these facets is key to long-lasting product success. #### More than user and business needs Value exploration isn’t just about finding ways to align business objectives with user desires, though that’s an essential part of it. Instead, it’s about taking a broader, more dynamic view of the entire value chain across the lifecycle of your product. This process should start long before the first product concepts and continues well after launch, informing pivots and the evolution of the product and organizaiton. > Dynamic view of the entire value chain across the lifecycle of your product While we’ve touched on the overarching themes of value exploration and value creation before, this article aims to give you a deeper understanding of the various aspects of value that play into your product’s success. The goal is to help you build a shared understanding within your team of what value truly means, not just in terms of what customers want, but also from a business perspective, operational efficiency, and strategic alignment. So, let’s dive in and explore the Value Universe, a dynamic space where business goals, user needs, market opportunities, and organizational efficiency intersect to create impactful, sustainable value. #### The Value Universe We’re all familiar with the classic Venn diagram model of product management: business, UX, and technology. This model has served its purpose in helping us think about the relationships between key elements of a product’s success. But as product development accelerates and the stakes rise, this framework no longer fully captures the complexity of today’s product landscape. To truly create value, product managers need to think beyond this traditional triad and consider the broader system in which their product exists. That means acknowledging that the relationship between business goals, user needs, and technology is only a part of a larger picture. In today’s fast-moving environment, product managers need to map out the entire system, including elements like market opportunities, operational efficiency, and strategic alignment. [Image] Here’s how these dimensions break down: Business Value It’s the fuel that keeps the engine running, guiding decisions on pricing, revenue streams, cost structures, and more. But business value isn’t just about generating revenue, it’s also about maintaining financial sustainability and managing costs effectively. - How does the business make money? - What pricing models and monetization strategies do we employ? - How do our customer acquisition costs compare to customer lifetime value? - How do our financial metrics compare to industry benchmarks? - How do we spend money to build and maintain the product? - How do our investments align with expected returns and profitability? Customer Value Understand why customers choose your product, what needs it solves, and how it fits into their daily lives. But customer value goes beyond simple satisfaction. It’s about solving real, pressing problems and providing an experience that users feel is worth their time, money, and attention. - Why do users spend money on our product? - What drives users to choose our solution over competitors? - What do users actually do when interacting with our product? - How effectively does our product solve user problems (problem-solution fit)? - How does our product occupy the customer’s cognitive space? Market Opportunity No product exists in a vacuum. Market opportunity is the external factor that can make or break a product’s success. To identify and capture these opportunities, you need to understand your market size, growth potential, competitive landscape, and external factors that can influence your strategy. - How large is our target market, and what is its current growth rate? - What trends indicate that the market is expanding or evolving? - Who are our key competitors, and what differentiates us from them? - Which market segments are under-served or ripe for innovation? Operational Efficiency Operational inefficiencies can eat into profits, slow down delivery, and create friction within teams. We need to be able to optimize processes, automate where possible, and ensure resources are being used effectively. - How efficient are our development, maintenance, and operational processes? - How scalable is our current technology and infrastructure? - How can process improvements or automation yield better returns on our spending? I wrote an article about this and how not every improvements is product-related. Strategic Value It’s about ensuring that the work you’re doing today is positioning the company for long-term success. This includes managing risks, fostering innovation, and maintaining a clear long-term vision for the entire product’s evolution. - How does our product fit within the broader business portfolio and overall strategy? - How are we prioritizing resource allocation across our product portfolio? - What strategic risks are associated with our product’s market and technology trends? - How do we foster a culture that balances short-term execution with long-term strategic planning? #### Interconnectedness of Value Dimensions To create true value, we need to understand how each dimension interacts with the others. These aren’t isolated areas; they are deeply interconnected. Decisions made in one area (like customer value) will ripple across others (like operational efficiency and business value). Understanding these relationships ensures that your product is balanced, efficient, and aligned with both market needs and company goals. > Dimensions are deeply interconnected #### Conclusion Value exploration is an ongoing, dynamic process that requires a holistic understanding of multiple dimensions. By exploring these areas in depth and asking the right questions, we can better prioritize initiatives, create more sustainable products, and position ourselves for long-term success. In the next article, we’ll dive deeper into the specific steps and frameworks that can help you explore each of these value dimensions in more detail and communicate them effectively across your teams. ------------------------------------------------------------ ARTICLE: BUILDING PRODUCTS WITH CONFIDENCE AT THE INTERSECTION OF CLARITY, PURPOSE AND IMPACT ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/building-products-with-confidence-at-the-intersection-of-clarity-purpose-and-impact Date: 2025-01-23 Author: Megan Murphy Categories: 1% Collective Summary: Megan Murphy brings over a decade of product leadership experience to her role as VP of Product at Circuit, where she shapes the future of last-mile delivery management. From her early tech career in San Francisco to leadership roles across Brazil and Spain, Megan's journey offers valuable insights into effective product leadership, decision-making, and staying true to your mission. Content: #### Main Takeaways - Use clear product principles to guide rapid, consistent decision-making - Look beyond surface-level feedback to understand true customer needs - Create alignment through early stakeholder involvement and transparent communication - Focus on metrics that matter to customers, not just internal assumptions #### What's your setup? What tools, frameworks, products do you use? Circuit is fully remote-native, which I think for me, if I'm gonna work remotely, I want it to be with a company that does that very intentionally. It creates a better experience for everyone when it's not like you're forgotten about at home. At least 2-3 days a week, I work from my home office. The other 2-3 days, I go to Juno House in Barcelona, which is a private social club for women with a co-working area. I usually go for half a day and then come back home, or vice versa. I like having a bit of structure and getting out of the house to be somewhere social where I can have a coffee. I do this on days where I don't have any meetings. In my home office, I use a standing desk and dual monitors. Something unique to my setup is that every Sunday, I make a bouquet of fresh flowers for my desk. I also keep an aromatherapy diffuser on with different essential oils throughout the day, depending on my energy and what I need. #### What's the biggest challenge for you at the moment and how do you plan to overcome it? The biggest challenge for me right now is also the thing I'm most excited about. I joined Circuit 9 months ago, put together our product strategy when I was 3-4 months in, and now, in partnership with my CEO, I'm working on a category strategy. This means zooming out of the product itself and defining what space we're playing in. For example, I work on the B2B product, and it's a lot earlier on an adoption curve. It's earlier in its lifecycle as a product. I look at other players in the market offering something similar as us creating this category together. This is probably the most exciting but biggest challenge because it's not just about what should the product do - it's about positioning, brand promise, and our most efficient acquisition channels. It's a lot broader of a remit than the product itself. #### In your opinion, what defines a top 1% product management professional? I think product people who are just inherently curious and who really recognize that it's not all about the product. It's a huge part - hopefully, you take pride in what you're building and that's shared across the team who builds it. But at the end of the day, there's a bunch of other things that come together to make something go from "oh, that product is cool" to "oh, this is a resilient part of my needs." > I think you have to be curious. I've been that person in the past who thought it was all about the product, and now I'm much humbler after my own startup experience and lots of things along the way. Top product managers know that it's not all about them or their roadmap. It's about working in concert with other disciplines. #### How do you go beyond surface-level customer feedback to dig deeper into user needs? Taking anything at face value is a short path. For example, with our product, we do route optimization. If you put in a bunch of delivery stops, we'll show you the best sequence to do those stops. We have customers who ask us all the time, "I want to manually reorder the stops." Historically, our product hasn't supported that. If you took it at face value, you'd just hear people say, "Oh, I don't know. That's just how I'm used to it. That's just what I like." So you have to dig and ask, and then you learn things like "package 6 needs to be picked up here and then dropped off there, so I need to make sure the pickup comes before the drop-off in the route." That helps us understand that maybe we need to have it like an object, which is a package, not just a stop, which is a destination. #### What non-traditional metrics do you use to measure product success? Honestly, we follow pretty standard SaaS basics. The free-to-paid conversion is obviously make-or-break. But what's interesting is that before I joined, our founder had an assumption that for our line of business, the cost per delivery for a courier was the most important metric. That sounds reasonable - I would assume couriers want to know that. But we're not seeing that messaging in itself be the hook that gets people. Instead, we're seeing that the first delivery attempt being successful is one of the most important metrics to our customers. So now when I'm trying to decide what to build, that's a question on my mind: Will this solution improve successful first attempted deliveries? #### Can you describe a time when new information made you pivot your product strategy? My own startup experience is probably the most relevant example here. We were aiming to basically make organizational design easy and modern, making it something that's not a painful reorg every time a company realizes they're not organized in a way that supports their direction. I started this when the market was booming, or at least in the last days of the boom. When the market came crashing down, people didn't really want to do that anymore. I pivoted the product to try to frame it as something that could help during a reorg, but what I failed to see was that in a time of crisis, nobody says, "let me go use this new product." The market wanted to drag us toward being an integration tool between HR systems and Notion, but I woke up one day and realized - I don't want to be some integration tool. That's not the problem I care about. I think there are founders who know in their heart they're meant to be a founder, and they'll solve a thousand problems until one works. Then there are founders who care a lot about a very specific problem and don't want to go through the founder experience for anything other than that problem. That was me. ------------------------------------------------------------ ARTICLE: VALUE OF PRODUCT MANAGEMENT ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/value-of-product-management Date: 2025-01-22 Author: Alexander Hipp Categories: Product Management Summary: Most product managers don’t deserve the title because they focus more on project management. It’s not entirely their fault, they’ve never experienced real product management. They were sold the wrong idea of what it should be. Content: Marty Cagan sums this up pretty nicely in the podcast episode: Product Management Theater. Over the years, I’ve spoken with hundreds of product managers through my work at Beyond. I care deeply about the industry, so I decided to create content to help product managers who feel stuck or don’t know where to start. My goal is to share practical ideas on what product management should truly be: bringing value to users and companies. This article is an introduction to what value looks like and how to discover and create it in modern organizations. I’m not reinventing the wheel, but I aim to make this topic clear and actionable. So, what value should product managers bring? It’s not about delivering features. Features are just potential solutions for creating value, but their delivery (= output) shouldn’t be the main focus. The focus should be on solving real customer problems that lead to changes in behavior, e.g., more visits, actions, or retention. These changes build stronger customer connections and drive sales (= outcome). Cagan highlights a major issue: teams often prioritize output over outcomes, wasting effort on things that don’t matter. Why? It’s easier to design, code, and release something. The process is linear and gives a sense of accomplishment. It feels good to showcase shiny new features in updates and move on. However, if these features don’t solve real problems or deliver results, they’re useless. Weeks of effort end up wasted, even though it feels productive. [Image] #### Value Exploration How can you avoid the “trap of building”? What should a product manager do to make an impact? Let’s break it down. First, understand what value means for the business. Every company, industry, and stage has different priorities. These may change over time with strategy shifts. If your company lacks direction (which is common), explore how success is measured. If the focus is only on making money, find out what users value when they buy your service. Then, learn how your company gains value from happy users. This understanding is critical. Once you know your customers, market, and how the company creates value, you can focus on your team’s responsibilities. Too many PMs jump straight into features or solutions without considering the big picture. This limits their ability to create meaningful impact. To summarize - Understand your customers and market deeply. - Learn what value means for the business beyond revenue. - Study how the business currently creates value. - Find out what happy customers value and why they return. - Validate problems of current and potential customers. - Identify opportunities to solve these problems and create value. - Prioritize opportunities aligned with business goals and customer impact. Let’s call these steps “value exploration.” In future posts, I’ll dive deeper into effective ways to explore potential value. If you’re curious now, search for “continuous product discovery” or “product kata.” #### Product Discovery vs. Value Exploration Seasoned PMs might think, “This sounds a lot like product discovery.” That’s partly true, but I believe calling it product discovery limits its scope. Here’s why: product discovery often implies focusing only on the product, finding the next feature for users. Value exploration goes beyond that. It’s about understanding the broader landscape: the business model, market dynamics, go-to-market strategy, metrics, and flywheels. These are critical for creating value. To master value exploration, you need experience with different companies, models, strategies, and experiments. Learn from case studies and develop pattern recognition skills. Understanding the big picture is essential, even if your current role doesn’t require it. Sit with sales reps, read user forums, and talk to your CFO about value creation. These steps will broaden your perspective and improve your skills as a PM. I’ll share more tips in future articles. #### Value Creation Once you understand value in your context, use your team’s abilities to create it for both the business and customers. This is often called product delivery, but I think it’s more than that. Value creation means maximizing value for the company and customers with the resources you have. It’s about serving the needs of both as quickly and effectively as possible. By understanding the company’s needs, how it works, and who its customers are, you can make informed predictions about the future. In many companies, this is where you’re handed a list of features to build. These lists are essentially hypotheses: “Build X, and Y will happen.” The issue is that this assumes leadership has done its homework, talked to users, understood the business, and found the best solution. If that’s the case, you don’t need a PM, just a project manager to execute. But in companies that empower product teams, you’re given clear direction, a problem to solve, and success criteria. This is where the real work starts. Value creation isn’t about checking off tasks or quickly shipping features. It’s about what changes as a result. Do customers complete tasks faster? Does the company save money or resources? Your product is part of a larger system. Changes have ripple effects. These effects are often more important than individual features for creating lasting value. Focus on outcomes. Delivery is just one way to achieve them. If you can create the same or better outcome without shipping code, don’t ship code. #### Empowered Teams How well you perform as a PM depends on how your organization values your contributions. We often talk about feature teams vs. empowered teams, but it’s more nuanced. It’s about knowing what you’re responsible for and what leadership handles. Trust and communication are key. Leadership must develop good strategies and communicate them effectively. Otherwise, they’re no better than handing down feature lists. Both PMs and leaders need accountability. Ideally, you work in a learning culture where outcomes and failures are openly discussed. In reality, though, organizations rarely allow many mistakes or pivots. Future articles will explore how PMs can foster healthy cultures through better communication. The approach will vary based on your organization’s challenges, customers, and market. But in the end, creating value is always a team effort. ------------------------------------------------------------ ARTICLE: HOW MISLABELING FEATURES HURTS PRODUCT PRIORITIZATION ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/how-mislabeling-features-hurts-product-prioritization Date: 2025-01-11 Author: Alexander Hipp Categories: Product Management Summary: What if the primary barrier to your product’s success isn’t your backlog or roadmap, but the terminology you use to describe your work? Labels can subtly yet powerfully influence your strategic direction. Content: Throughout my career, I’ve observed that the labels we assign, such as “backend optimization,” “core banking,” “nice-to-have,” or “engagement driver”, can either amplify a feature’s importance or bury its potential. Here’s how I think about the hidden power of labeling opportunities and feature today and how product leaders can use labels to improve their product strategies. #### How labels can undermine value Early on, I noticed that features tagged as “technical improvements” or "tech debt" often slipped down the priority list. Meanwhile, features labeled “engagement drivers” shot to the top. This was no coincidence. Our roadmap labels sent the message that one set of features was purely operational, while the other was essential for growth. When a technical improvement "accidentally" ended up boosting user activation by 15 percent, it became obvious that we were missing great opportunities due to how we were categorizing our work. In a neobank where I worked, similar issues emerged. Features classified as purely “user delight” were sidelined, even though they were the number one requested feature for a very long time. By rethinking these labels and viewing them as part of our “retention and activation initiative,” we changed the conversation and gained support for bringing the feature (dark mode for the mobile apps) to life. #### Challenging your labels To avoid these labeling pitfalls, I have a few recommendations that you could apply today to discover real value behind opportunities and communicate it better. - Question your assumptions. Take a fresh look at your categories. Are you labeling potentially game-changing features as “technical tasks” or “nice-to-have” add-ons? - Map feature value end-to-end. Connect each opportunity to user impact and business goals. E.g. for AI-enabled recommendations, instead of saying “algorithm optimization,” show how it leads to better content matching, higher engagement, and long-term retention. - Test for clarity. Ask if a newcomer, someone unfamiliar with your product, could read the label and instantly see why it matters. If not, rewrite it. The main point here is not to tweak or sell features, but to ensure each feature is categorized in a way that highlights its true value. You could also encourage your team to perform a “labeling audit” and share insights about how different labels influence their sense of priority or urgency. - When was the last time you reviewed your labels? - Are your “engagement” or “delight” labels accidentally diminishing real business impact? - Are you using words that resonate with stakeholders, or are you obscuring strategic potential with vague jargon? Labels aren’t just words on a roadmap. They shape the way people think and talk about features, request resources, and measure success. A few examples: At the social network, my team worked on a feature we labeled as “similarity matching algorithms”. We had a very hard time selling it, but once we called it a “contact recommendation enhancement,” we saw a shift. Teams became excited to see how it would improve first visit engagement and overall retention, and stakeholders understood it was more than a background tweak. At the neobank, my team were slow to champion an experimentation series for the onboarding experience until we reframed it as essentially saving millions of dollars to the business. This one change sparked interest and discussions about how those experiments could be run and supported by multiple teams. Words matter. #### Constantly work on the way you label and communicate The best product leaders I’ve worked with never stopped iterating on how they classify and communicate what their team is working on or trying to achieve. A label can rally a team, secure funding, or move a feature to the top of the backlog. They continually ask, “Is our labeling system, the way we describe features, still helping us or is it holding us back?” Labels can be powerful tools for clarity, alignment, and momentum, or they can quietly stifle innovation. It’s up to you to decide how to wield them. Review your way of thinking and how the people around you label and talk, challenge your and their assumptions, and watch how reframing a few simple words can reshape the way you think. ------------------------------------------------------------ ARTICLE: EXPERIMENTATION AS A CATALYST FOR TRANSFORMATIONAL PRODUCT SUCCESS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/experimentation-as-a-catalyst-for-transformational-product-success Date: 2025-01-10 Author: Luis Trindade Categories: 1% Collective Summary: Luis is a passionate advocate for experimentation, blending his diverse experiences as a computer engineer, UX consultant, startup founder, and product manager into a singular focus: helping teams learn, iterate, and grow. From sunny Lisbon, Portugal, Luis shares his insights into building better products, fostering a culture of experimentation, and navigating the challenges of organizational change—all with the curiosity and precision of a scientific mindset. Content: #### Main Takeaways - Repetition and consistency are key to cultivating a culture of experimentation and driving organizational change. - Experimentation is not just a tool but a mindset that can apply to everything - Success requires adaptability: treating organizational shifts as opportunities to learn and iterate, just as you would with a product. #### Who are you in a nutshell? What do you do, and why do you do it? Hi, I’m Luis Trindade, and I love experimentation. I started as a computer engineer but quickly realized my passion was at the intersection of technology, user experience, and business. Over the years, I’ve worn many hats—developer, UX consultant, founder, and now product manager—but the common thread has always been curiosity and a drive to learn. My journey into experimentation came from observing how digital products were designed and delivered. I noticed how small decisions, like a button color or copy change, could impact user behavior. I’ve seen how simple translation errors could cost millions, but testing avoided catastrophe. Through these experiences, I learned that the true value lies not just in delivering products but in fostering an iterative mindset. I work to share this passion with others—whether through talks, workshops, or helping organize meetups. At Farfetch, I’ve embraced a role as a teacher, helping teams adopt experimentation to set better goals, mitigate risks, and share knowledge across the organization. Ultimately, the collective learning we gain from testing hypotheses and improving user experiences is a company’s most valuable asset. [Image] #### What’s your setup? What tools, frameworks, and products do you use? I work mostly from home in a city just outside Lisbon, which allows me to spend more time with my 9-month-old daughter. I visit the Lisbon office when I can, even just for lunch with colleagues—those in-person moments are irreplaceable for building real connections. My workstation is a Mac Mini M1 with a 27” Dell monitor, a light bar, and an OBSBOT Tiny 2 camera for clear communication during calls. My desk and chair are ergonomic, and I can switch between sitting and standing with the click of a button. Most importantly, my desk is next to a window with a view of my daughter’s kindergarten. For work tools, I rely on Zoom, Slack, and the Google Workspace suite for communication and documentation. For discovery and brainstorming, I use Miro or Zoom’s whiteboard functionality. #### What’s the biggest challenge for you at the moment, and how do you plan to overcome it? Four years ago, I helped create a Center of Excellence for Test & Learn at Farfetch. The goal was to instill an experimentation mindset across the company. While we’ve made significant progress, recent organizational shifts have created new challenges. Changes in leadership, scaling down teams, and redefining priorities forced us to adapt our roadmap. Instead of seeing this as a setback, I view it as an opportunity. Just as we apply experimentation principles to product development, we’re iterating on our internal practices. We’ve refocused on stability and self-service capabilities, automating tasks like error reporting and analytics deep dives to free up resources. At the same time, we’ve retrained team members and introduced new tools to empower others to experiment. The challenge remains the same—teaching the organization how to “fish” through experimentation—but the goals and approaches have evolved. It’s a moving target, and that’s what makes it exciting. [Image] #### In your opinion, what defines a top 1% product management professional? A top product manager is someone I can learn from, someone who challenges my perspective and deepens my understanding. It’s less about being the “best” in every domain and more about becoming a reference point for others in a specific area of expertise. #### How do you cultivate a culture of experimentation in your team, and what practices have been most effective? Repetition and consistency are the keys to building habits. At Farfetch, we’ve embedded experimentation into our regular processes through weekly ceremonies where teams discuss hypotheses, test designs, and results. We also host monthly company-wide Test & Learn sessions to share insights and maintain a centralized knowledge base, LEAR (from “Learning”). Each hypothesis, iteration, and result is documented with a sharable link, making it easy to access and build upon collective knowledge. By creating regular touchpoints and ensuring learnings are shared consistently, we’ve made experimentation an integral part of our culture. #### How do you handle major shifts in strategy due to new information? One example comes from my role as the product manager for Farfetch’s in-house experimentation platform. Years ago, the platform struggled with adoption because it required developers to hard-code logic for tests, which was time-consuming and messy. When I joined, I pivoted the roadmap to focus on building a feature toggle system, a “Trojan horse” that gave developers full control over deployments with zero extra effort. [Image] This change eliminated resistance to experimentation. Within six months, over 30 squads adopted the system without any formal training because it made their lives easier. Developers began advocating for experimentation themselves, creating a turning point for the platform’s success. #### How do you balance quantitative data with qualitative insights in decision-making? A recent example involved testing a new standardized size scale on our e-commerce platform. Initial A/B tests showed positive engagement metrics but detrimental checkout metrics, which didn’t make sense. After triple-checking the quantitative data, we added a contextual feedback survey to the test. This qualitative insight revealed the issue: users were confused by inconsistent size displays across different pages. The test was stopped, learnings were shared, and the feedback informed the next iteration. This reinforced an important lesson: A/B testing isn’t the only tool in your experimentation toolkit—qualitative insights can be just as valuable. [Image] ------------------------------------------------------------ ARTICLE: A PM'S GUIDE TO SMARTER ROI DECISIONS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/a-pm-s-guide-to-smarter-roi-decisions Date: 2024-12-30 Author: Alexander Hipp Categories: Product Management Summary: Product ROI isn't just about numbers - it's about making decisions that create immediate value today while building a stronger product portfolio for tomorrow. Here's what I've learned about balancing both. Content: Let me share something I’ve noticed several times throughout my career, something that only recently clicked for me as a pattern. It’s about competing opportunities and the challenge of deciding how to invest our time and resources to maximize outcomes, whether for the next month, quarter, or the year ahead. Here’s the thing: as product managers, we often create a false choice and debate the wrong issue, short-term results versus long-term value. I’ve wrestled with this for years, and I’ve come to realize that the real skill isn’t just picking one over the other. It’s about deeply understanding the ROI and broader implications of both. #### The problem with how we think about ROI We’ve all been taught to focus on outcomes over output. Success is defined by numbers going up and to the right: more users, more revenue, more features shipped. But blindly chasing this mindset can be a huge mistake. Some types of ROI are difficult to see and even harder to measure using frameworks like RICE. For example, how do you evaluate the branding and UX impact of adding dark mode? Or decide whether to prioritize features that exist solely to secure your next funding round? Let’s be honest, these aren’t ideal scenarios, but they’re often the reality handed down by leadership. “Build this tiny feature, and something magical will happen.” I’ve heard this pitch countless times in interviews. We build what someone assumes will have a big impact without requiring proof or validation. New features often feel more exciting and are easier to sell internally and externally. But what if the highest ROI lies in fixing a half-baked feature from two years ago that 60% of customers use regularly? The truth is, some of the most valuable work won’t show up in next quarter’s metrics. But we still need to create space for uncovering opportunities that deliver long-term ROI. How do we do that? #### Simple questions to uncover the best opportunities After seeing too many teams struggle with these decisions, I developed a straightforward approach. It’s based on using decision tree templates (see here), thinking about opportunities as part of a spectrum (more here), and asking a few key questions to evaluate both immediate and long-term impact. Start with immediate impact - What problem are we solving right now? - Who benefits in the next few weeks, and how? - Which metrics will improve? Then, consider the long-term view - Are we solving a long-term problem, or is this just about short-term impact? - How will this decision affect our ability to improve the product later? - Can we reverse course if things don’t go as planned? - Does this align with where we want to be in three years? - How will this influence our brand and positioning? By weighing both perspectives, we often end up prioritizing entirely different opportunities. Decisions become less reactive and more grounded in the bigger picture. #### A better approach to ROI decisions Even if you’re in the middle of the quarter and everything seems clear, building a few habits now will prepare you for your next prioritization session: 1. Write Down and Visualize Assumptions Document both short-term and long-term impacts. Make your assumptions clear and explicit. 1. Regularly Review Outcomes Set up recurring reviews with stakeholders to check whether your decisions are delivering the expected value. 1. Create Space for Strategic Thinking In every planning session, separate urgent tasks from long-term strategic improvements. Most importantly, avoid the trap of thinking you must choose between short-term wins and long-term health. The best product leaders don’t settle for one, they deliver both. They ensure today’s work solves immediate problems in a way that supports sustainable growth and future success. #### Final thoughts This article is rooted in real experiences from building and scaling products across industries. The lessons might seem simple, but they’re often the hardest to practice consistently. Start small. Build habits. Be intentional. The payoff? Better decisions, stronger outcomes, and a more resilient product in the long run. Start small. Build habits. Be intentional. The payoff? Better decisions, stronger outcomes, and a more resilient product in the long run. ------------------------------------------------------------ ARTICLE: FEATURE FACTORIES VS. REAL SOLUTIONS. NOT EVERY IMPROVEMENT NEEDS CODE. ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/feature-factories-vs-real-solutions-not-every-improvement-needs-code Date: 2024-12-17 Author: Alexander Hipp Categories: Product Management Summary: We Product Managers have fallen into a dangerous trap: we mostly believe that every problem requires a code-driven solution. This mindset isn't just inefficient, it's fundamentally breaking how organisations solve challenges. Content: #### Code as the default solution Imagine a typical scenario which I have encountered multiple times throughout my career: a team encounters a business or problem challenge, and the immediate response is to mobilise developers. More meetings, more specifications, more lines of code. But what if the best solution isn't a new feature or application? What if it's something far simpler? Most organisations have developed a reflexive habit of turning to software as their primary problem-solving tool. Developers become the default solution for every challenge, creating a cycle of unnecessary complexity and delayed impact. #### The delivery bias The root cause is what I would describe as "delivery bias." Companies invest heavily in technical talent, so there's immense pressure to keep developers constantly producing. The metric becomes outputs, features shipped, rather than meaningful outcomes or true impact creation. This creates a perverse incentive: teams would rather build something complicated than admit a problem might be solved through a simple process adjustment or communication improvement. Giving an update to the organisation about a shiny feature feels incredible. #### Code-first thinking The consequences of this are significant in my opinion: - Slower time to real value: Lightweight, immediate solutions get overlooked while teams spend weeks or months building complex software. - Wasted developer capacity: Talented engineers get bogged down in projects that could be resolved through simpler means, draining their creativity and potential. - Organisational tunnel vision: By defaulting to code, teams exclude crucial perspectives from non-technical teams who often have the best understanding of operational challenges and the customer. - Wrong or bad solutions: When we create features without deeply understanding the problem, we risk developing solutions that fundamentally miss the mark. [Image] #### Real-world examples Let me share some practical scenarios to outline what I mean with these no- or low-code solutions that illustrate alternative approaches: - Communication fix: A Customer Success team improves onboarding by redesigning communication templates and creating clearer handoff protocols. No new features required—just thoughtful restructuring. - Tool optimisation: A Business Ops team reconfigured CRM workflows, eliminating redundant steps and improving data capture. Their solution? Strategic reconfiguration, not a new software project. #### The broader challenge The fundamental issue runs deeper than technical solutions. Problem discovery too often happens in isolation, with product teams working in a vacuum. Critical insights from Sales, Support, Customer Success, and Operations are routinely overlooked. > How can we solve this without code? This simple question can revolutionize your approach to problem-solving. It shifts the conversation from building to solving. It challenges product teams together with their stakeholder counterparts to explore creative, lightweight solutions that deliver immediate value. #### A needed mindset shift to problem-first Before writing a development ticket or requirements, ask: - What's the simplest way to address this challenge? - What are the first principles of this problem? - Who else in the organization might have insights or solutions? - Can we solve this through communication, process redesign, or existing tools? #### Practical steps for a better solution development Over the years I collected a few recommendations on how to focus on impactful, simple and the best solutions. It’s spending more time on understanding the problem because you need to involve more people and do more research. But this always has paid off every time in the long run. 1. Broaden discovery: Invite representatives from Operations, Sales, Customer Success, and other departments into problem-solving discussions. 1. Celebrate non-code solutions: Create organisational recognition for elegant, low-effort problem resolution. 1. Redefine success metrics: Measure impact, not feature delivery. 1. Cultivate curiosity: Encourage teams to explore multiple solution paths before committing to software development. #### Conclusion: Solve problems, not just writing software Product development isn't about generating code, it's about solving real challenges with the least possible friction. By challenging our default assumptions and embracing a more holistic approach, organizations can unlock faster, more innovative solutions. Not every solution needs code. Sometimes, the most powerful improvements come from seeing problems with fresh eyes and embracing simplicity. Remember: Great product development is about solving problems, not just shipping features. ------------------------------------------------------------ ARTICLE: WHY STRATEGIC VISIBILITY MATTERS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/why-strategic-visibility-matters Date: 2024-12-11 Author: Alexander Hipp Categories: Product Management Summary: Are you focused on the right things, or just staying busy? Strategic visibility helps uncover whether your efforts truly align with your product’s purpose. What would change if you could clearly see the bigger picture? Content: Let’s be honest, Product Management sometimes feels like a never-ending to-do list. You’re in back-to-back meetings, rushing through sprints, and juggling feature requests. It’s easy to feel productive. But are you actually making meaningful progress? I’ve been there, working hard, communicating, making plans, shipping features, and feeling like every task was a win. Until I realized some of those “wins” didn’t matter at all. Like spending weeks on a feature that looked like a high potential candidate and then no one wanted it or it didn’t deliver the impact we hoped. It happens more than we’d like to admit. The issue wasn't my skills or your skills, or your team’s hard work. We did all the things by the book. Talking to users, looking at numbers but still. It’s a lack of strategic visibility. #### What Is Strategic Visibility? It’s about seeing the bigger picture and making sure your work fits into it. Think of it as a map for your product or area. Without one, you’re just wandering from one thing to the next. With one, you know where you’re going and why every step matters. Sometimes it already helps to visualize where your team gets their work from and what metrics hopefully change if you are successful. What It Looks Like - Every task should connect to your company’s goals. No more “busy work” that doesn’t lead anywhere. - Focus on real problems and don’t just build for the sake of building. Solve problems your users care about. - Show your thinking and be clear about why some things are prioritized and why others aren’t. It builds trust and alignment. This is probably the highest-level example of what such a map could look like. The closer to the real situation this overview is the more helpful it becomes. [Image] Try this: - Create a monthly Strategic Snapshot. This can be as fast as 30 minutes. - Show how your projects tie to company goals. - Highlight what problems you’re solving for users. - Call out what you’re not doing and why. There are several frameworks that can help you to have a good starting point. Just the other day, one of our customers sent me a video of him starting to visualize what they were trying to accomplish. It was eye-opening for both of us to be prompted with the questions "Why do we do this?" and "Where does it come from?" #### Frameworks for quick starts Opportunity Solution Trees Opportunity Solution Trees help visualize how your product’s outcomes connect to opportunities, solutions, and experiments. They break down complex decisions into a clear path, ensuring every effort aligns with the desired impact. [Image] Impact Maps Impact Maps link business goals to user behaviors and features, providing a clear view of how tasks drive meaningful outcomes. They help teams prioritize the most effective paths to success. [Image] User Story Mapping Story Mapping organizes features along the user journey, prioritizing what’s most critical to deliver end-to-end value. It ensures your team focuses on solving user problems holistically, not just building features in isolation. [Image] Wardley Maps Wardley Maps visualize the landscape of your product or market by mapping components along their evolution and value chain. They help teams identify strategic opportunities and invest resources where it matters most. [Image] #### The power of saying “No” Most of us hate saying no. It's just natural. But it’s essential to protect your team’s time, energy and focus. With strategic visibility, saying no isn’t about shutting things down, it’s about showing why your focus matters and where you focus. When people see the bigger picture, they get it. They stop seeing “no” as a block and start seeing it as smart decision-making. #### How to get started with your team 1. Start super small, create a one-page visual that links your work to company goals. That's it for the beginning. 1. Share it with your team—keep it simple and clear. Discuss it and refine it. 1. Keep it alive—update it every month so it stays relevant. 1. Use it actively in conversations with your team and stakeholders. Strategic visibility can change the whole perception of work. It turns product management into more than just task execution. It makes you a true leader, helping your team see why their work matters and creating strategic clarity around objectives.. ------------------------------------------------------------ ARTICLE: SOLVING PRODUCT PROBLEMS AT THE INTERSECTION OF STRATEGY, DATA AND INSIGHTS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/solving-product-problems-at-the-intersection-of-strategy-data-and-insights Date: 2024-12-10 Author: Yana Michukova Categories: 1% Collective Summary: Yana combines over a decade of product management experience with a unique blend of analytical rigor and creativity. Having led impactful initiatives at Stripe and Lyft, her career showcases her ability to tackle high-stakes challenges, from building “zero-to-one” products to scaling them for millions of users. She brings a data-informed, user-centered approach to her work, empowering her teams to create solutions that not only meet business and technical goals but also genuinely serve user needs. Content: #### Main Takeaways - Leverage structured thinking to navigate ambiguity and break down complex problems into actionable steps. - Use deep user research to uncover underlying motivations and create products that solve real-world problems. - Build alignment with stakeholders through early relationship-building and ongoing communication. - Introduce simple, memorable metrics to align cross-functional teams on shared goals. #### Who are you in a nutshell? What do you do, and why do you do it? I’m Yana, a Product Manager at Stripe and formerly at Lyft. My work revolves around solving complex, high-impact problems at the intersection of strategy, data, and user insights. I thrive on blending creativity with analytical rigor to build products that not only meet technical and business goals but also serve real user needs. One of my most fulfilling experiences was leading teams at Lyft to create an in-house mapping system. This involved data collection, machine learning, and map updates—delivering a critical solution for the company. I’ve also worked on scaling products to reach millions of users, which requires balancing technical excellence with a deep understanding of the market and user priorities. For me, product management is about collaboration and continuous learning. I’m driven by the opportunity to tackle unsolved challenges, and I find joy in the process of turning ideas into impactful solutions. #### What’s your setup? What tools, frameworks, and products do you use? Where do you work, and what is your schedule like? My setup is minimal but effective. I work with a MacBook Pro, a mouse, and classic wired headphones—they’re reliable and don’t require troubleshooting like AirPods. I’m also a big fan of pen and paper for notes and to-do lists. There’s something uniquely satisfying about physically crossing items off a list. Most of my day is spent on Zoom calls, writing strategy documents, or diving into pricing and monetization calculations. My core tools are Google Docs, Google Sheets, and Apple Notes, with occasional use of Figma for quick prototyping and deck illustrations. [Image] I’m a morning person, so my day starts at 6:00 a.m. with a walk with my dog. By 8:30 a.m., I’m at my desk, and I protect my mornings for focused, strategic work before the flood of Slack messages and emails begins. #### What’s your biggest challenge at the moment, and how do you plan to overcome it? Professionally, my biggest challenge is defining the next big chapter in my career. I’m naturally drawn to problem-solving and thrive on tackling unique challenges, like when I led the creation of Lyft’s proprietary mapping stack. Now, I’m at a point where I want to reflect on where to grow next—whether it’s deepening technical expertise, advancing in people management, or exploring new technologies. On a personal level, I’m trying to obtain an Irish driving license. Despite driving for over a decade, Irish law requires a national license, so I’ve had to put my road trips on hold temporarily. It’s an unexpected challenge, but I’m determined to solve it! #### In your opinion, what defines a top 1% product management professional? Three skills stand out: structured thinking, communication, and the ability to set the right metrics. Structured Thinking Product management often involves navigating ambiguity. Great PMs can break down complex problems into tangible milestones and connect the dots between product, business, and market goals. Communication Skills Strong communication is essential for articulating vision, securing leadership buy-in, and fostering collaboration. It accelerates all other skills and amplifies impact. Metrics Mastery Setting meaningful, actionable metrics is a surprisingly rare skill. Metrics guide decisions and ensure that initiatives drive real progress. Yet, many PMs struggle to define metrics that align with their product’s success. #### How do you go beyond surface-level feedback to dig deeper into user needs? Users often come to me with specific requests or questions. Instead of jumping to solutions, I step back to understand the underlying business problem they’re trying to solve. Honest, humble conversations are invaluable. I conduct at least one user interview per week, often more, to uncover deeper insights. In these conversations, I focus on understanding their priorities, budget allocations, and resource constraints. Key questions I ask include: - What are their main business goals? - What are the primary roadblocks? - And why? These questions help me open up a deeper level of user motivations and design solutions that genuinely address their needs. #### How do you present your product vision to skeptical stakeholders and maintain alignment over time? This is one of my strengths! Misalignment is natural in large organizations where teams have varying priorities. I make it a point to understand their focus areas and main priorities, share my own goals, and explore how we can collaborate effectively. Questions like, - Where is your focus right now? - What are your main priorities? - Here’s what my goals are. - How can we work together on this? "Here are the benefits for you" framing help lay the groundwork for alignment. This groundwork ensures that my vision incorporates their input, creating a stronger, shared strategy. Maintaining alignment requires consistent communication. Regular touchpoints and updates help adapt to shifting priorities while keeping everyone on the same page. #### What non-traditional metrics do you use to measure product success, and how do these metrics influence your strategy? At Lyft, I worked on building our in-house maps—a highly technical product. We used data coverage and freshness as primary metrics, but these were hard to communicate broadly. To address this, I introduced a tiered system: cities were ranked gold, silver, or bronze based on specific criteria. This simplified our metrics and aligned stakeholders on clear, actionable goals. It also helped leadership prioritize investments and measure progress. #### How do you rapidly validate ideas with minimal resources? I’m a big fan of quick testing and rapid prototyping. I use Figma to create prototypes for iteration and conduct lean user research, speaking with 5-10 users to validate core hypotheses. For more complex situations, I rely on data modeling based on historical data to test assumptions without significant upfront investment. ------------------------------------------------------------ ARTICLE: RETHINKING PRODUCT PRIORITIZATION WITH THE OPPORTUNITY SPECTRUM ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/rethinking-product-prioritization-with-the-opportunity-spectrum Date: 2024-12-03 Author: Alexander Hipp Categories: Product Management Summary: We’ve become prisoners of our own frameworks—RICE, ICE, and other scoring methods that promise clarity but fail to account for the full spectrum of opportunities. These tools, once innovative, now limit our thinking and block our best ideas. Content: #### The hidden cost of comfortable prioritization Traditional prioritization methods are appealing because they seem simple. A scoring system that ranks ideas objectively? Sounds great. But here’s the hard truth: these methods often protect the status quo instead of sparking meaningful innovation. How most teams approach prioritization - They carefully score opportunities using set metrics. - They lean toward small, safe improvements with predictable results. - They unintentionally create a culture where bold ideas are discouraged. This doesn’t just limit innovation; it creates what could be called “opportunity debt.” Every missed breakthrough and every cautious decision is a step away from a potentially better product. #### Three strategies to rethink prioritization 1. Think in Portfolios, Not Lists Stop viewing opportunities as a simple ranked list. Your product strategy should be more like an investment portfolio, diversified, adaptable, and resilient. This is probably the most common strategy being communicated by people like Gibson Biddle for years. Organize opportunities into three categories - Incremental improvements: Small, steady enhancements that deliver consistent value. - Emerging opportunities: Promising ideas with moderate risk. - Transformational bets: Big, bold ideas that could change everything. This kind of intentional distribution reduces the risk of stagnation while ensuring there’s room for big ideas to flourish. If you want to use tools. Think of opportunity maps or heatmaps. They can help visualize this portfolio approach and identify gaps. Don't start with the tool but with a blank canvas. 2. Focus on first principles Frameworks can be useful, but they often add unnecessary complexity. Instead of diving straight into scoring, take a step back and ask yourself: - What do our customers truly need right now? - Does this opportunity align with our main goals? - What’s the simplest way to create meaningful value? These straightforward questions cut through the noise and reveal opportunities that might initially seem less attractive. For example, an overlooked feature request might actually address a deeper customer pain point than a flashy new initiative. To help facilitate this thinking, always work in cross-functional teams to gather diverse perspectives when defining opportunities. It's a false belief that these opportunities need to come from Product all the time. There is so much opportunity debt happening in companies because other functions don't get the chance to be part of the discussion. This collaborative process often uncovers insights that scoring frameworks might miss. (Further reading on why Product Managers or in this case UX are not the center of the universe) 3. Prioritize open and transparent Decisions made in isolation can stifle innovation. When prioritization happens behind closed doors, great ideas often don’t get a fair chance. Instead, involve your team and stakeholders in the decision-making process. Use tools like Opportunity Solution Trees (yes a tool but a good one because it doesn't automatically tell you which opportunity is better than the other) or collaborative whiteboards to make decisions visible and open for discussion. For instance, a bold idea from a junior team member could spark the kind of transformation your product needs, if it’s given the chance to breathe. This transparency doesn’t just build trust; it fosters a culture where the best ideas, no matter their source, can rise to the top. #### View options as a spectrum Think of your initiatives not as a rigid ranked list but as a spectrum, a dynamic range of possibilities that span different levels of impact, risk, and timeline. This shift in perspective and thinking reframes prioritization from a narrow, linear exercise to a broader, strategic approach. On one end of the spectrum are immediate-value initiatives, such as incremental improvements that enhance existing features, address customer pain points, or optimize processes. These deliver quick wins and keep your product competitive in the short term. At the other end are long-term transformational bets, bold, high-risk ideas that may take time to pay off but have the potential to reshape your product, disrupt your market, or create entirely new categories. In between, you have emerging opportunities, initiatives that balance moderate risk with promising returns, often serving as bridges between today’s needs and tomorrow’s possibilities. [Image] 1. Immediate-Value Initiatives - Examples: Bug fixes, UI tweaks, small feature enhancements. - Purpose: Maintain user satisfaction, address urgent needs, and keep the product running smoothly. - Risk/Reward: Low risk with predictable, but limited, impact. These are your bread and butter, the foundation of day-to-day product management. They ensure your product stays relevant and your customers feel heard, but over-reliance on this category can lead to stagnation. 2. Emerging Opportunities - Examples: Features that tap into adjacent markets, integrations with other platforms, or experimental designs backed by early customer insights. - Purpose: Explore new directions without overcommitting resources. These should be the average new value adds. - Risk/Reward: Moderate risk with scalable potential. These initiatives act as your exploration zone. They’re more ambitious than immediate-value projects but less speculative than transformational bets. Think of them as pilot projects that help you test the waters before diving in. 3. Transformational Bets - Examples: Groundbreaking new features, innovative technologies, or entirely new product lines. - Purpose: Push the boundaries of what your product can achieve, with the potential to redefine your market. - Risk/Reward: High risk with the possibility of exponential rewards. While these initiatives can be costly and uncertain, they’re the ones that lead to breakthroughs. They require courage, vision, and often a longer timeline to realize their impact. #### How to balance the spectrum The key to leveraging the opportunity spectrum is balance. Over-indexing on immediate-value initiatives can make your product feel stagnant, while focusing solely on transformational bets can leave your team overstretched and customers underserved. Here’s a practical way to approach it - Allocate 50% of resources to immediate-value initiatives to keep your current customers happy and engaged. Build a product your users love! - Dedicate 30% to emerging opportunities to explore new directions and keep your product evolving. Build a competitive product! - Reserve 20% for transformational bets that could redefine your product or market. Build an innovative product! Regularly review and adjust this balance based on your team’s capacity, market conditions, and strategic goals. #### The power of spectrum thinking The spectrum approach acknowledges that different types of opportunities serve different purposes. Immediate-value projects keep the lights on, emerging opportunities drive incremental growth, and transformational bets create the breakthroughs that move industries forward. By viewing prioritization as a spectrum, you give yourself permission to embrace uncertainty and diversity in your roadmap. Instead of asking, What’s the safest choice? you begin asking, > What mix of opportunities will make our product resilient, innovative, and impactful? This mindset shift also aligns teams more effectively. It helps stakeholders understand that not every initiative will deliver immediate results, but each has a role in the bigger picture. Visualizing opportunities on a spectrum can also foster more productive discussions, with teams evaluating trade-offs collaboratively instead of fixating on rigid rankings. #### Using the spectrum in practice Visualize the spectrum Use tools like Opportunity Maps or Impact/Effort matrices to plot your initiatives across the spectrum. Seeing everything in one view can highlight gaps or over-investments in a particular area. Track metrics across categories Define success metrics for each type of opportunity. For example, immediate-value projects might focus on retention, emerging opportunities on adoption rates, and transformational bets on long-term ROI. Revisit and rebalance Treat the spectrum as a living document. Reevaluate your distribution of resources quarterly or after major product milestones to ensure alignment with your strategy. #### A dynamic, balanced future The opportunity spectrum transforms prioritization from a rigid ranking exercise into a flexible, dynamic system that adapts to your product’s evolving needs. It acknowledges that every opportunity, big or small, has value when viewed in the right context. > Every opportunity, big or small, has value when viewed in the right context. By adopting this mindset, you empower your team to think more strategically, act more collaboratively, and embrace the full range of possibilities that drive both short-term wins and long-term innovation. As a product leader, your job isn’t just to pick the safest option, it’s to balance the ecosystem of opportunities. Your strategy should evolve as your product and market grow, with the flexibility to embrace unexpected discoveries. Be prepared to have opportunities that are pretty vague the more into the future you look. That's ok! Accept uncertainty. Create space for bold, unconventional ideas. ------------------------------------------------------------ ARTICLE: HOW TO BUILD TRUST IN A COMPLEX ECOSYSTEM AND DRIVE PRODUCT SUCCESS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/how-to-build-trust-in-a-complex-ecosystem-and-drive-product-success Date: 2024-11-29 Author: Daniel Thomason Categories: 1% Collective Summary: Daniel Thomason brings a diverse background to his role as a fintech product expert leading payments at Google Wallet. Originally from Australia, Daniel has worn many hats, from central bank economist to escape room founder to product leader. Now based in San Francisco, Daniel combines his technical understanding with a people-first approach to make confident, impactful decisions in a high-stakes, global ecosystem. Content: #### Main takeaways - Balance patience with momentum when working in complex ecosystems with external dependencies. - Cultivate a broad curiosity and surface familiarity with diverse domains to uncover high-impact opportunities. - Differentiate between reversible and irreversible decisions to act confidently even with incomplete data. - Foster alignment through overcommunication and relationship-building with stakeholders. #### Who are you in a nutshell? What do you do, and why do you do it? I’m Daniel, a husband, father, gamer, reader, weightlifter, yogi, and, of course, product manager. My current role is with Google Wallet, where I lead a team focused on making it safe and easy for customers to add their credit and debit cards. This role is the broadest scope I’ve had as a PM, requiring collaboration across engineering, design, business development, and marketing teams. A significant part of my work involves engaging directly with partners like banks, payment networks, and merchants to scale the product globally. Before joining Google, I worked with startups worldwide, including founding an escape room company in Sydney. I’ve always been drawn to complex, high-impact problems, and product management gives me the opportunity to work on those challenges in meaningful ways. #### What's your setup? What tools, frameworks, and products do you use? Where do you work, and what is your work schedule like? I subscribe to the “tidy desk, tidy mind” philosophy, keeping my workspaces, at home and in the office, organized. My setup includes a clean desk, a monitor surrounded by a few photos and toys, and tools like Figma and Google’s suite of internal software. [Image] One unique aspect of working at Google is relying on homegrown tools for most tasks, with Figma being the rare third-party exception. I also have templates I use heavily: a lightweight Product Requirements Document and a beautifully crafted Google Slides deck for presentations. I work four days a week at Google’s office on the Embarcadero in San Francisco and spend Fridays working from home, often keeping it meeting-free to catch up on emails and tasks. Mornings are my most productive time, and I aim to finish by 5 p.m. to catch an early train home and spend time with my daughter before bed. #### What’s the biggest challenge for you at the moment, and how do you plan to overcome it? The most significant challenge for me in payments is navigating the dependencies between the many players involved, merchants, consumers, banks, payment networks, and more. These relationships are a double-edged sword. They allow for solutions that address complex, real-world problems but can also slow innovation. Balancing completeness and scale with speed is tough. While startups can optimize for speed, they often struggle with distribution, whereas in my role, the challenge lies in maintaining momentum across a vast ecosystem. To overcome this, I focus on relationship-building. Success hinges on trust and creating win-win situations. This involves understanding each stakeholder’s perspective, aligning incentives, and consistently proving value through collaboration. #### In your opinion, what defines a top 1% product management professional? There’s no single archetype for a great product manager. Some excel in technical depth, pushing their engineering teams to think differently and build robust infrastructure. Others shine in market positioning, knowing exactly how to communicate the product’s value to customers. Then there are PMs with deep business acumen, who intuitively understand their industry and company, and can align their products with strategic goals. A top-tier PM knows which type they are (or want to be) and focuses on mastering the skills and attributes that matter most for their role. That said, there are certain pitfalls to avoid. One is excessive ego: thinking your ideas are always best, taking too much credit for team efforts, or dismissing other people’s goals and time. Another is having no opinion of your own, acting as a passive conduit for requests without a clear vision for the product. Lastly, being silent and invisible as a PM can severely limit your impact. A PM’s job is to keep information flowing, communicating what the team is doing, what they need, and where they’re going. Great PMs are constantly talking, asking questions, sharing insights, and keeping everyone aligned. As I like to say, “If a PM is working incredibly hard but doesn’t make a sound, are they really having an impact?” The answer is, probably not as much as they could. [Image] #### How do you consistently identify high-impact opportunities that others might overlook? One approach I’ve found invaluable is being T-shaped: having deep expertise in a couple of areas while maintaining a broad understanding of many others. This breadth allows me to draw inspiration from unexpected places, whether it’s reading about evolutionary biology, participating in local politics, or playing board games, and apply those insights to professional challenges. I also prioritize engaging conversations with a wide range of people. When you take a genuine interest in others, whether it’s their work, hobbies, or lives, they often share perspectives or ideas that spark new connections. These conversations aren’t just enlightening; they’re fun and provide a steady stream of fresh ideas to consider. #### How do you make confident decisions with incomplete data and reduce risks in those situations? I love the one-way vs. two-way door analogy popularized by Jeff Bezos. One-way doors are decisions that are hard or impossible to reverse. These require thorough analysis, risk mitigation, and clear communication about what is known versus what is assumed. The goal here is to minimize regret by ensuring the decision-making process itself is sound, even if the outcome isn’t ideal. Most decisions, however, are two-way doors: reversible and easier to adjust if needed. For these, waiting for perfect information can lead to wasted time. Instead, I encourage my team to take calculated risks and treat decisions as opportunities to learn. Communicating this approach is key: “We don’t know with 100% certainty if launching feature X will improve conversions, but based on [data points], we believe it has a good chance. If it doesn’t work, we’ll disable it and document our learnings.” As a leader, I also aim to turn one-way doors into two-way doors wherever possible. This reduces pressure and allows for faster, more confident decision-making. #### How do you ensure continuous product discovery? I think of product work as a diversified portfolio that includes shipping features, reflecting on launches, and planning future efforts. Teams should allocate time for all three activities to ensure they’re building insight into customer needs, not just shipping features in isolation. This practice is fractal: it applies at the yearly, quarterly, and weekly levels. Maintaining this balance keeps discovery continuous, enabling teams to align past learnings with future opportunities. #### How do you present your product vision to skeptical stakeholders and maintain alignment? Skeptical stakeholders are allies you haven’t won over yet. Building alignment requires ongoing communication: meeting regularly, sharing updates, and involving them in the process early. Nobody likes surprises, so keeping stakeholders informed reduces skepticism. In my team, I emphasize understanding stakeholders’ goals and priorities. Regular touchpoints, launch updates, and inclusive demos foster trust and ensure everyone feels invested in the product’s success. #### How do you cultivate a culture of experimentation and drive innovation? Experimentation requires both technical and cultural foundations. Without the infrastructure to run experiments efficiently, teams won’t prioritize them. If approvals for experiments are as arduous as those for a full launch, teams won’t bother. I advocate for investment in experimentation infrastructure and process changes that reduce barriers. This includes making it easier to set up tests and securing leadership buy-in to accept higher risk for faster iteration. When experimentation is frictionless, it becomes a natural part of the team’s workflow, fostering innovation and enabling more ambitious bets. ------------------------------------------------------------ ARTICLE: BALANCING SHORT-TERM GOALS WITH LONG-TERM PRODUCT SUCCESS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/balancing-short-term-goals-with-long-term-product-success Date: 2024-11-17 Author: Alexander Hipp Categories: Product Management Summary: The push for quick wins makes it hard for product teams to focus on lasting impact—how can we find the right balance? Content: The other day, I came across Francesca Cortesi’s article, “The Importance of Discovering Solutions Beyond Opportunities.” I was curious to see her take on Opportunity Solution Trees (OSTs) and their limitations. But what stuck with me wasn’t about the mechanics of OSTs—it was this part: “I honestly never saw a behavioral change [in users] that was executed and brought results within a quarter. Yet, putting quarterly goals on a product team will push them to have an even higher pressure on focusing on short-term wins and a lower inclination on dedicating a lot of time on discovering different solutions.” That hit home. As product managers, we constantly operate between delivering immediate results and building for the long term. Francesca’s article reminded me of the times I’ve had to justify why I wanted to stick to working on the same opportunity for longer. I watched countless teams move on from promising opportunities too quickly—settling for “good enough” because the next quarter’s priorities were already around the corner. But the truth is, meaningful change rarely fits neatly into three-month cycles. Impactful solutions demand patience, iteration, and a willingness to go deeper. And yet, most organizations don’t make it easy. This tension isn’t just theoretical. It’s a constant battle, and it plays out like this: - Teams abandon opportunities prematurely. Quarterly goals encourage quick fixes or favoring easy solutions over deep exploration. - Pressure for quick wins stifles creativity. Deliverables take precedence over outcomes. - Iteration gets deprioritized. Once a solution ships, the focus shifts to “what’s next” instead of making it better. - Competing priorities create chaos. Stakeholder demands and shifting objectives pull teams in too many directions at the same time. I’ve been in those meetings too often, trying to justify why we should refine a solution that looks “done” on paper. I’ve had to explain why an opportunity wasn’t truly resolved or why moving on too soon could mean leaving value on the table. > Why do you want to keep going? How long will this take? Isn’t this already solved? The challenge isn't only with the planning tools themselves, but with the broader economic and organizational systems that create pressure for short-term results. Our planning cycles are deeply intertwined with financial quarters, investor expectations, and economic rhythms that prioritize immediate measurable outcomes. These systemic pressures create a cascade of short-term thinking that flows down through organizations, affecting how we plan, execute, and evaluate product work. The real skill lies not in criticizing these systems, but in learning to navigate them strategically. How can we work intelligently within these constraints, finding creative ways to maintain focus on meaningful, long-term impact while still meeting near-term expectations? #### How can we solve this This ties into a larger issue within product management. While we’re often told to optimize for outcomes over outputs, we’re just one part of an organization. Most of the planning and thinking around us is naturally gears toward shorter time horizons. There are exceptions, like for example Shopify, where Tobias Lütke has set a 100-year vision, and experiments are evaluated a full year after starting. But this is rare. Most of us work with six-month roadmaps, quarterly changing OKRs, or two week sprint cycles. Results almost never come so direct which makes balancing short-term pressure with long-term focus incredibly difficult. After diving into this topic further, I found that many in the product community share the same frustrations. Fortunately, some great advice exists on how to tackle this challenge. Here are the best recommendations I found around the web to answer this question: How can product teams stay focused on the right opportunities and solutions long enough to achieve meaningful, lasting impact while balancing the pressure for short-term results? Francesca Cortesi: Keep a balance between discovery and delivery After reading Francesca’s article, I reached out to her to learn more. She emphasized the importance of balancing discovery and delivery. Not every team can focus on discovery simultaneously—especially early on—but skipping discovery entirely increases the risk of waste during delivery. Product leaders must orchestrate these phases across teams to ensure progress without sacrificing efficiency. Shreyas Doshi: Establish clear long-term objectives Shreyas highlights the importance of connecting opportunities to long-term strategic objectives. These objectives act as a compass, helping teams prioritize their work and avoid distractions from short-term pressures. With a clear focus on where they’re headed, teams can make more disciplined decisions and reduce the temptation to chase less important opportunities. Gibson Biddle: Embrace a portfolio approach to opportunities Gibson advocates treating opportunities like a portfolio, balancing high-risk, high-reward bets with safer, incremental improvements. This ensures focus isn’t spread too thin while maintaining a steady pipeline of impactful projects. A portfolio approach also helps teams avoid overcommitting to one area, allowing them to make meaningful progress across multiple fronts. Julie Zhuo: Build a culture that embraces depth over FOMO Julie emphasizes the importance of creating a culture where teams feel comfortable diving deeply into a few meaningful problems rather than chasing every new idea. This focus on depth fosters better solutions and stronger outcomes. It also creates an environment where teams feel empowered to stay the course and resist distractions. Andrew Chen: Set guardrails to avoid overcommitment Andrew recommends defining clear success and exit criteria for initiatives. These guardrails help teams know when to keep going with a solution and when to pivot or stop. Without these boundaries, teams risk overinvesting in ideas that aren’t working or prematurely abandoning projects with potential. Guardrails provide clarity, helping teams balance persistence with flexibility and avoid wasted effort. #### Leading the way Ultimately, balancing short- and long-term priorities isn’t just a PM problem—it’s an organizational challenge. Leadership plays a critical role in setting the tone. They need to define clear objectives, establish boundaries, and foster a culture that values focus and persistence. At the same time, product managers on the ground can’t wait for perfect conditions. We need to adopt smarter approaches, advocate for the right priorities, and communicate why depth and iteration matter. One question I’ve found helpful to ask ourselves is this: > How can we, as a team, build confidence in deciding when to stick with an opportunity or move on? The answer often lies in making the process visible. Tools like Opportunity Solution Trees or similar frameworks help teams align on the big picture while breaking it down into actionable steps. #### Final thoughts Balancing short-term pressures with long-term impact will always be hard, but it’s not impossible. It requires intentionality, collaboration, and a willingness to embrace discomfort. And when you get it right? The results can truly speak for themselves. Not just in the outcomes your team delivers but in the overall confidence you gain in making better product decisions. Thanks to Francesca for giving feedback and writing her article that sparked the conversation in the first place. ------------------------------------------------------------ ARTICLE: HOW TO CREATE TECHNOLOGY THAT FITS PEOPLE, NOT THE OTHER WAY AROUND ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/how-to-create-technology-that-fits-people-not-the-other-way-around Date: 2024-11-06 Author: Naomi Fitzpatrick Categories: 1% Collective Summary: Naomi leads with purpose, crafting technology that meets people where they are. She blends human-centered design with a collaborative team approach, always seeking to build solutions that truly resonate. By diving deep into user insights and embracing a spirit of continuous discovery, Naomi brings thoughtful strategy to each decision, ensuring the products she builds are not only scalable but deeply meaningful to those who use them. Content: #### Main takeaways - Ask users what they’re trying to achieve without referencing your product to uncover their true goals and needs. - Set aside technology during discovery to focus purely on understanding user behaviors and uncovering real problems. - Use collaborative diagrams to align stakeholders and create a shared, evolving product vision. #### Who are you in a nutshell? What do you do, and why do you do it? Hi, I'm Naomi—a Product Leader with experience at &Open, Intercom, Typeform, and Microsoft SwiftKey. I focus on building human-centered experiences, leading high-performing and collaborative product teams, and I have a particular inclination towards AI-powered products. I work in product management to help people and solve significant problems. My emphasis is on the human side of product development, always striving to make technology adapt to people rather than the other way around. #### What's your setup? What tools, frameworks, and products do you use? Where do you work, and what is your work schedule like? I have a pretty traditional desk setup: a Mac, a monitor, a webcam—everything you'd expect. I've also invested in a great standing desk, so I try to spend half my day standing. I'm really into movement, so my yoga mat is always rolled out behind me. [Image] As for my tools and schedule, I use various applications to scale my productivity. When you're trying to drive everyone in the company in the same direction or convey insights and concepts, one-on-one or even group meetings can become bottlenecks. To mitigate this, I send a lot of Loom videos, voice notes in Slack, document everything in Notion, and use Miro for diagrams. This combination allows me to collaborate with key people and gather input and feedback from a broader group than I could through meetings alone. I also use pen and paper a lot to clarify my thoughts and organize my time. Each day can look quite different, but I know that if I have over four hours of Zoom meetings in a day, I won't be productive. So, I block out focus time throughout the day and reserve time in the morning to organize my thoughts before diving in. Sometimes this works; other times, it's not realistic—but that's the aim! #### What’s the biggest challenge for you at the moment, and how do you plan to overcome it? My biggest challenge right now is figuring out what my next big endeavor will be that allows me to grow and learn. I have extensive experience in B2B SaaS, AI-powered products, and scaling products with a unique selling proposition in human-centered user experiences, all while leading high-performing, collaborative product teams. However, I'm grappling with how to apply this knowledge and experience to tackle bigger problems the world is facing today. My plan is to focus on two areas: FemTech and Climate. In FemTech, one of the significant issues has been the lack of data. Even in clinical trials, women and people with cycles have only relatively recently been included, so much of the healthcare industry operates on outdated data. Companies like Clue and Daye are now making more data available, which is both exciting and necessary. The next step is where I see my experience being most helpful: taking this data and creating personalized, easy-to-understand, and useful actions and insights to solve real problems for people. #### In your opinion, what defines a top 1% product management professional? A top-tier product manager knows when to delve into details and when enough is enough. There are countless frameworks, strategies, podcasts, content pieces, insights, data points, user research findings, market analyses, KPIs, and OKRs. It's easy to get overwhelmed by the sheer volume of "things you are supposed to do" and "things you are supposed to know." The best product managers I've worked with understand the critical data points and insights. They know which processes or actions will help unblock their next immediate step, but they also recognize when they don't need to get involved at a detailed level. It's a classic prioritization problem—not just prioritizing problems to solve or your roadmap, but also prioritizing your time and energy. This means knowing what to say no to or when you have enough information to move forward. #### How do you consistently identify high-impact opportunities that others might overlook? For me, this isn't about a quick hack. I'm always searching for the sweet spot where technical solutions align with the behaviors of real people using the software, creating value for both customers and the business. I typically start by looking at four areas holistically: - Customer Insights: What do our customers' workflows look like? What are their biggest problems? Why are they doing what they're doing, and what are they trying to achieve? - Technical Understanding: How does our current system work end-to-end? Where do we see the most use? Where do we see drop-offs? - Market Insights: Where do we have gaps compared to competitors? Where are we best in class? What's trending right now? - Business Value: What is our biggest problem to solve as a business? Is it acquisition, engagement, retention, overall growth, revenue, contribution margins, or expansion? With a high-level view of each of these areas, significant gaps, problems, or opportunity spaces usually start to emerge. If you're lucky, you might be able to tackle more than one at once. [Image] #### How do you rapidly validate ideas with minimal resources before deciding to invest more? This varies depending on what you need to understand to validate further investment in a solution. Initially, I'll try to determine the next immediate step, the question we need to answer, the hypothesis we need to validate, or the risk we need to mitigate to know whether it's worth investing more time. Often, this involves user research or running through scenarios and options. For example, at &Open, our goal was to move to a completely self-serve platform, which was a potentially large investment. The first step we took was to review the system to understand what volume of our total gifting could be improved by moving to a self-serve platform, and then identify the smallest piece we could tackle to validate whether our customers would use it. This gave us two validation points: first, before building anything, by better understanding the data and our system; and second, by breaking down a potentially large project into a very small chunk that could be validated in isolation. #### How do you balance quantitative data with qualitative insights in your decision-making process? Balancing quantitative data with qualitative insights is similar to finding opportunities and what makes great product people—it's about knowing where to dig into more details. For me, it's about understanding the "why" behind a piece of data or the impact behind customer insights. For example, at Intercom, we noticed a retention problem (quantitative data/business value). We dug into the "why" and discovered our customers weren't able to handle the volume of conversations coming into customer support reps (customer insight/qualitative data). AI chatbots and automation were becoming more popular (market insight), and our system wasn't set up to scale to handle a higher volume of conversations other than by hiring more customer support reps (technical understanding). This led to a significant shift in our strategy towards automated support, increasing three-month retention by 19%. [Image] #### How do you go beyond surface-level feedback to dig deeper into user needs? For me, the most important thing is to essentially ignore technology during initial discovery. When I receive user feedback, it's often along the lines of "Feature X isn't working as expected," "It would be great if you built Feature Y," or "This feature should work like Z." Users provide this feedback with a full understanding of their context and exactly what they're trying to achieve. However, I only have assumptions about how they're using the product and what they're trying to achieve. To better understand their real problems or needs, I use two approaches: 1. Observe Them Using the Product in Real-World Scenarios: At Microsoft SwiftKey, an AI-powered predictive keyboard for iOS and Android, our amazing user research team would bring people in every week. We'd watch them typing on a mobile device to see what worked and what didn't. 1. Ask Them to Describe Their Goals Without Our Product: I ask them what they're trying to do, why they're trying to do it, and how they would accomplish it if our product didn't exist. This is key to understanding real-world needs so we can build something that fits, rather than something that may or may not be suitable. #### How do you present your product vision to skeptical stakeholders, and what do you do to maintain alignment over time? Anyone who has worked with me knows I'm obsessed with diagrams. A diagram of how something should work in the future, backed up with qualitative, quantitative, and market insights that link directly to business impact, is a powerful tool. Diagrams are also easier for most people to collaborate on, whether in person on a whiteboard or using tools like Miro. I usually collaborate with all stakeholders on what the vision should look like. Each time, the overall diagram evolves by incorporating insights and perspectives from around the business, as well as quantitative and qualitative insights, so it's informed holistically. The combination of early involvement, collaboration, and continuous updates to the product vision means it's not just my vision being pushed onto everyone else; it's a collective vision we've all worked on and shaped together. [Image] #### What non-traditional metrics do you use to measure product success, and how do these metrics influence your strategy? I typically focus on two areas to define success metrics for products and platforms: 1. High-Value Feature Adoption: At Typeform, this was especially important because we saw a correlation with 3-, 6-, and 12-month retention among users who adopted our "higher value" features, such as integrations, logic/workflow building, and personalization features. These features are usually more complex and harder to get people to use for the first time, but once they do, they create immense value, leading to continued engagement. 1. Scalability: This metric is often harder to quantify but is crucial. Essentially, I look at whether a solution scales. For example: - At Typeform: Does this solution enable our customers to generate a higher volume of insights using our tool? Can they reach more people with their forms or handle a higher volume of responses? - At Intercom: Does this solution enable our customers to handle a higher volume of conversations without hiring more customer support reps? - At &Open: Does this solution allow our customers to send a higher volume of gifts in less time? Could we handle 10x more volume without needing to hire additional staff? Measuring success against these two areas encourages teams to think big—not just solving immediate problems but also paving the way for more significant impact in the future. It also creates a built-in flywheel effect. If customers are adopting your most valuable features, and those features empower them or your business to scale rapidly without additional costs, it allows both you and your customers to grow exponentially with each solution you build. ------------------------------------------------------------ ARTICLE: WHY DECISION-MAKING IS A PRODUCT MANAGER’S MOST VALUABLE CURRENCY ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/why-decision-making-is-a-product-manager-s-most-valuable-currency Date: 2024-11-04 Author: Alexander Hipp Categories: Product Management Summary: As product managers, our ability to make decisions is our most powerful asset. A product is ultimately the sum of numerous choices made by various people within a company. Product managers are involved in or drive a significant portion of these decisions. Yet we still talk too little about what makes a good decision and how to improve our decision-making skills. Content: - What is our product's long-term vision? - What is the next piece of work with the potential to create the most outcome? - What unique value does our product offer? - What are our product's key success metrics? - Do we work on tech debt or new features? Product decisions like these are the most powerful currency we as Product Managers can leverage to create impact and drive product success. They guide your team and ultimately determine whether you and the product succeed. The best product managers I've spoken with share a few different views on making product decisions that I will outline in this article. They seem to have mastered the art of making better, more informed, and more impactful decisions. I'll explore why I believe decisions are the core currency of a product manager's role, how the best in our industry approach decision-making, and how they leverage the right decisions to create maximum impact. The anatomy of a great product decision Product decisions are rarely simple. I probably faced 1-2 pretty clear decisions in my career. All the other times they carried multiple layers. Going left or right usually gets dictated by lots of variables like customer needs, team resources, business objectives, and future implications. Each decision involves trade-offs and often comes with unseen influences and ripple effects, such as internal biases and external pressures from stakeholders or the market. The best product managers make these complexities visible before taking important decisions. Decision quality vs. speed One of the most common challenges, I hear over and over from all types of product people is balancing the need for speed (if we wait too long or analyse too much the conditions have changed) with the need for high-quality decisions. We want to make the best decision with the least needed input (less time to prepare) fast. You see the challenge here. To strike this balance, you can use predefined frameworks like for example the RICE scoring model, which gives you a rough idea on what blanks to fill to be able to make an “informed” decision. In this case you have to think about different factors like reach, impact, confidence, and effort upfront. The multiplier effect of high-impact decisions But not all decisions should be created equal. Some might result in positive ripple effects that boost product growth, strengthen team alignment, and enhance customer value. Choosing the right solution to develop, the timing for a product launch, or the strategy for pivoting can all have significant downstream impacts. Positive and negative. Understanding which decisions might have this multiplier effect can be a game changer. Amazon is using a nice framework to classify decisions into reversible and irreversible decisions to see how much upfront might be necessary. The less a decision is reversible the higher the quality of the decision should be. Tools like Opportunity Solution Trees (OST) help to visualize potential pathways and assess which decisions can unlock the most value. By mapping opportunities and their potential solutions and experiments, you can can better prioritize and communicate which initiatives will drive the most meaningful results. Data-informed vs. data-driven I think we can all agree that being data-driven is a cornerstone of modern product management, but data alone isn’t always enough to feel confident about a product decision. The best product managers know when to rely on data and when to incorporate their own intuition and experience. Paul Adam’s coined the term Product Sense (now they call it Product Judgement) that exactly explains this concept of “knowing” the right answer without relaying on too much data. Data can guide decisions by showing trends and informing hypotheses, but it doesn’t capture every nuance of the market or customer behaviour. Shreyas Doshi often emphasises the importance of being data-informed rather than solely data-driven. It’s way more important to use historical data to inform a decision that maps perfectly to a new strategy then blindly following the data to plan your next steps. Most of the time we have to trust our instincts and live with incomplete data to make the best possible decision as fast as possible. How to build confidence and accountability in decision-making One of the most effective ways to build confidence in decision-making that I’m trying to practice myself for years now is being as transparent as possible. If something works, great, if it doesn’t, be honest and change or fix it. Same with decisions. You have to be 100% transparent on how you got to a decision. This involves keeping a clear record of major decisions and holding retrospectives to review their outcomes ideally with your team and stakeholders. Looking back to evaluate decisions and learn from mistakes is something that our industry in general is not really good at in my opinion. In general, the goal of these reviews isn’t to assign blame but to learn what worked, what didn’t, and why. This approach encourages us to learn continuously and helps us to get to better choices and outcomes in the future. When your team and stakeholders understand the reasoning behind your decisions and see that the outcomes are reviewed openly, it fosters exactly this trust that you want to create and a culture of shared accountability. This builds deep collective confidence, allowing everyone to feel more invested in the product’s success (and failure). Leadership buy-in and cross-functional alignment In most companies today you need the support of leaders and stakeholders to be able to decide something. That’s why I also see it as a currency, you can invest in decisions and either win or lose credibility. You also would not buy stock without reading about the company or ETF right? The same goes for these shared decisions you will have to make on a daily basis. We must be skilled at communicating decision proposals and final outcomes of a decisions process in a way that aligns with the company’s broader objectives and includes involved views and opinions. This involves presenting a clear narrative that shows why a decision was made, who made it ultimately and how it ties into the overall strategy. Biggest learning here from the top 1% of produce leaders I talk to. Involve other teams, leadership and stakeholders early and often, because when they are part of the decision-making process or understand its rationale, they are more likely to support the outcome and work together effectively to implement it. (Feels like a no-brainer, but is super complicated and hard work to get right) Conclusion Making decisions lies at the heart of product management. These choices shape a product's direction, influence a team's path, and create value for customers. The best product managers understand that making confident, well-reasoned decisions is a skill—one that requires a blend of data, intuition, and strategic thinking. Let's treat each of our decisions as an investment, a valuable currency that product managers can leverage to drive greater impact and become stronger, more confident leaders. In the next weeks, I’m going to share more thoughts on how we can get more confident when making product decisions through strategic mapping. ------------------------------------------------------------ ARTICLE: BUILDING GENUINE CONFIDENCE IN STRATEGIC PRODUCT DECISIONS ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/building-genuine-confidence-in-strategic-product-decisions Date: 2024-10-28 Author: Alexander Hipp Categories: Product Management, About Beyond Summary: Today marks a pivotal moment for Beyond. After hundreds of conversations with product managers and leaders, I’ve decided to focus on what I believe is the most crucial challenge in product management today: building genuine confidence in strategic decisions. Content: #### Why This Matters Now You’re doing all the “right” things. Your OKRs are aligned. Your discovery process is continuous. Stakeholder updates are consistent. Analytics dashboards are comprehensive. And yet. When someone asks, “Are you confident we’re working on the right things?” there’s that moment of hesitation. That split second where doubt creeps in, even after years of experience. This hesitation isn’t just common—it’s costly. #### The Confidence Problem Last year, in a study we conducted with Dave Wascha, we interviewed around 40 and surveyed about 300 product managers and leaders across various levels, company sizes, and industries. We wanted to understand the real “jobs” of product management. I'm going to share the results in more depth in another blog post soon. Through these conversations and many more since then, I’ve noticed a recurring issue: a lack of confidence. Here are some ways this problem shows up: Tool overload leads to confidence deficit Despite countless tools and data at your fingertips, there’s still a lack of confidence in decision-making. You prioritize data-driven decisions but struggle to quantify the actual impact of releases. “Quantifying the actual impact of releases” was both one of the most challenging and most important tasks for PMs. The delivery trap There’s overwhelming pressure to keep shipping and delivering. However, the most impactful product managers aren’t necessarily those releasing the most features but those who’ve mastered continuous discovery. Activity doesn’t equal impact PMs are busier than ever but struggle to “identify the most sensitive metrics that drive the biggest impact.” We’re confusing being busy with being effective. #### The Cost of Low Confidence This lack of confidence doesn’t just lead to shipping the wrong features—it creates hidden costs: Decision debt Every uncertain decision adds up, creating commitments we’re not fully confident in. Teams carry this debt for months or even years, afraid to revisit past decisions because they lack a framework for building justified confidence. Strategy creep Without clear confidence in our choices, strategies dissolve into reactive decisions. We have to plan confidently ahead of time. This also explains why PMs ranked “identifying the most sensitive metrics that drive the biggest impact” as a top priority. Eroding trust Pushing decisions we’re unsure about devalues stakeholder trust. “Providing clear visibility into the prioritization process” ranks among the top PM priorities for this reason. #### Why I’m Building Beyond I don't want to create just another project management tool. Beyond is a direct response to these hidden costs. After talking to so many product teams, I’ve realized our current tools excel at delivery but fall short in critical ways: - They track but don’t guide - They measure but don’t question - They focus on outputs, not outcomes We’ve optimized for delivery confidence (“Can we build it?”) at the expense of discovery confidence (“Should we build it? Are we optimizing the right things?”). #### A new approach to product confidence Beyond starts with confidence at its core. Here’s how: Strategic mapping Go beyond basic opportunity-solution mapping to build justified confidence in your strategic decisions. Deeply evaluate and compare the best outcomes and opportunities to ensure your team’s time is well spent. Impact visualization See how impact is being created, where it’s coming from, and who is contributing. Opportunity Solution Trees are great tools to communicate your strategy, assess what’s working, and identify where to focus. Continuous discovery integration Embed validation into your decision-making process so every choice builds on proven insights rather than guesswork. #### Personal Reflection This matters deeply to me because I’ve seen the cost of low confidence play out too many times. It’s not just about making better decisions—it’s about having the confidence to know you’re making the right ones. If any of this resonates with you—the paradox of having more tools but less clarity, the burden of decision debt, or the challenge of building genuine confidence in your strategic choices—I’d love to hear your story. Not because I’m trying to sell you something, but because these conversations shape how I build a tool that truly helps product managers feel confident in their most important decisions. ------------------------------------------------------------ ARTICLE: ARE WE SOLVING THE RIGHT PROBLEMS? ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/are-we-solving-the-right-problems Date: 2024-10-22 Author: Alexander Hipp Categories: Product Management Summary: At first glance, this might seem easy to answer. But in reality, it’s often much harder than it looks. It’s not just about building many features or solving customer problems, it’s about knowing that your team’s current efforts are going toward the problems that matter most to your product, user and business. Content: As a founder of Beyond, I’ve spent countless hours talking to product managers and leaders from different industries and companies, trying to understand the core challenges they face in their day-to-day work. One thing that comes up over and over again is this seemingly simple, yet deeply complex question: > "Are we addressing the right problems, at the right time, to create the greatest impact?" In many conversations I’ve had, one common theme stood out when it came to problem solving: Prioritization. Too often, decisions about what to build are driven by the objectives of top leadership, and while that’s not inherently bad, it can lead to situations where the deeper reasoning behind a problem isn’t explored. We spend time talking about opportunities at a high level, but we don’t always dig deeper into their potential impact or how to properly implement them. #### Why solving the right problem is so challenging One thing I hear frequently is that product managers often feel like they’re caught in the middle. On the one hand, they have customer feedback and data, and on the other, there’s pressure from stakeholders or leadership with personal objectives that may not always align with the long-term vision. It’s like trying to navigate through fog: you have a general direction but not always enough visibility to absolutely feel confident. And then there’s the challenge of prioritizing opportunities. How many times have you sat down with your team to really weigh two or three opportunities, asking yourselves which one will create the biggest impact and how to break it down into meaningful, actionable steps? Not often enough, if we’re being honest. The problem is that the information we need to make those decisions isn’t always easy to get, or in some cases, it’s missing altogether. This is why solving the right problem becomes so difficult. You might have ten different voices telling you what the product needs, but without clear alignment and a proper understanding of how solving one problem affects your key outcomes, you risk spending resources on problems that don’t really move the needle. #### How to start solving the right problems This is exactly why I’m working on Beyond—to help product teams make confident decisions about the right problems to focus on and the right opportunities to pursue, in the right order. Here’s what I’ve learned along the (hard) way: Start with a clear outcome One of the most impactful things you can do is start by defining the outcome you’re aiming for. What is the business trying to achieve? Is it growth? Retention? Profitability? When everyone on the team is clear about what success looks like, it becomes easier to evaluate which problems matter most. Map opportunities to outcomes Once the outcome is clear to everyone, it’s time to map out the opportunities that can help get you there. For each opportunity, ask yourself: how will solving this problem help us hit our outcome? This helps filter out the distractions and focus on what truly matters. [Image] Weigh opportunities side-by-side This is the part I see missing most often in teams. We talk about opportunities individually, but rarely do we sit down and compare them directly. What if you took two or three opportunities and really dug into their impact, their effort, and their feasibility? The idea is to find the sweet spot where effort and impact align. Sometimes it’s not about solving the biggest problem but finding the problem that can be solved the fastest while still creating significant value. Often the most unsexy opportunities are the real nuggets. Validate and slice Even when you think you’ve found the right problem to tackle, it’s crucial to run experiments or tests to validate your assumptions. Sometimes, the key isn’t solving the problem in one go but slicing it into smaller, testable parts so you can adjust and learn as you go. By the way, this doesn't always need to be shipping code. Personal reflection For me, the reason this question, “Are we solving the right problems?”, is so fundamental is that it forces us to step back and ask: are we being intentional with our time and resources? Every hour a team spends on the wrong problem is not just wasted time—it’s an expensive misallocation of effort, people, and money. The cost of a full team chasing the wrong thing can be immense, not only in terms of lost productivity but also in missed opportunities to drive meaningful impact. With so many distractions and pressures, it’s easy to get caught up in the wrong things. But when you have a clear outcome and a structured way to prioritize opportunities, you can make decisions that feel purposeful. > "Are we fully clear about the problem we’re solving, why it’s important, and the impact it can have?" Shreyas Doshi often talks about the importance of clarity in product thinking, and I think that’s what this question drives toward. Are we clear about what problem we’re solving and why? It’s not about choosing one problem and sticking with it—it’s about constantly reassessing and refining your path based on real insights and data. By aligning your opportunities with clear outcomes, weighing options side-by-side, and validating your approach, you can feel way more confident that your team is focused on what truly makes a difference. At Beyond, we’re building tools to help product teams do exactly that. By visualizing how opportunities connect to outcomes and offering a framework to prioritize effectively, we aim to give PMs the confidence to know that they’re working on the right problem, at the right time, in the right order. Because in the end, it’s not about how much you build—it’s about building the right things. ------------------------------------------------------------ ARTICLE: DECISION TREE TEMPLATES FOR MAKING CONFIDENT PRODUCT CHOICES ------------------------------------------------------------ URL: https://www.alexhipp.com/blog/decision-tree-templates-for-making-confident-product-choices Date: 2024-08-09 Author: Alexander Hipp Categories: Product Management Summary: A few years ago, I was a product manager at a fast-growing fintech startup. I faced a tough challenge when the leadership team tasked us with cutting a feature’s profit and loss in half in the next three months. The team I inherited had accumulated a lot of technical debt due to the company’s fast growth, which led to the loss of millions of Euros. Content: The data was unclear and the business environment was complicated. I used a decision tree, specifically a driver tree, to identify where to begin, gain stakeholders’ support, and convince the leadership that we were on the right track. It’s incredible to see how many decisions product managers have to make on a daily basis. To be able to visualize and communicate these decisions, product managers increasingly leverage different types of decision tree templates. In this article, I’ll explain how useful decision trees can be in product management and how they can help you make better choices when you’re overwhelmed with options. #### What is a decision tree? The simplest version of a decision tree is very similar to a flowchart that can help you make choices. In essence, it can look like a tree where the trunk is the main problem you are trying to solve or the choice you are going to make. As you move up the tree, you define different “tests” that are related to this problem. The tests will lead to other branches and tests, until the final choices. Let’s look at a simplified example to make this more tangible. Imagine you’re working on a new product initiative and you need to decide if you want to add a specific new feature to the product portfolio. Your company’s objective is to increase user engagement within the next quarter, so your first test could be something like “Does the feature improve user engagement?” If the answer is “Yes,” you keep digging. If “No”, you have different tests like “Is it still valuable to add the feature later?” A decision tree template is a helpful tool for making your thoughts visible and externalizing your decision-making process. #### Why decision trees are useful for your product team As a product manager, decision trees are an essential tool for planning and communicating the direction of your product: Make complex things simpler One of the biggest challenges for product managers is the sheer amount of data and feedback they have to go through to make sense of their world. Using decision trees helps to break the complexity down into smaller, more manageable chunks. It helps you to focus on the most important themes and prevents you from getting lost in the details. Allow everyone to understand Presenting to your team, leadership or your stakeholders becomes way easier if you can easily help everyone see the big picture before zooming in and justifying a potential opportunity. Enable better decisions Answering the question of what to do next and why can be difficult. However, taking the time to think about different possibilities, what could happen if you choose each one, and then selecting the most likely to succeed can save a lot of money and resources. Stay flexible In the tech world and especially in product management, things change quickly. Yearly roadmaps are not commonly used anymore (at least I hope so). Decision trees are helpful because they can be easily updated or adjusted when new information arises or situations change, which can save you from a lot of headaches. #### Where decision trees fall short While decision trees offer many advantages, they come with their own set of challenges. As mentioned before, they can easily be updated, but they don’t auto-adapt to changing circumstances or new information so you need to manually update your trees to keep them relevant. Another big challenge I see is the potential risk of oversimplifying a complex situation. Breaking down the wider context with lots of variables into a couple of stickies usually means losing a lot of context and information. Most importantly, decision trees can sometimes reflect the biases of their creators. If there is no solid evidence to support certain decisions, the trees can be misused to promote personal favorites as the best solution, leading others to believe it as well. Nevertheless, building a tree together with your team can eliminate this bias and support you to get to the best possible outcome. Let’s have a look at how this would look like in a step-by-step guide. #### Decision tree template When building your first tree, it can help to follow a methodical approach. As you get more experienced, you can adjust the process to your needs. It’s best to work on the tree with your team to increase the chances of people accepting it. The most common way of creating a decision tree follows these steps: 1. Identifying the problem — Start by clearly identifying a problem to solve or a decision to make. For example, if you’re wondering which feature to launch next, that’s your problem 1. Choosing the decision criteria — These are the important points in the process where you make the choice. For our feature launch question, decision points could include user demand, development time, and potential impact on metrics 1. Creating possible solutions or actions — As you work along the process, you’ll come up with possible solutions or actions. These are the branches of the decision tree. They can go as wide as you need them to be 1. Listing predicted outcomes — Going deeper into the tree’s branches, define possible outcomes or consequences of each experiment. Not every experiment has the same effect on user engagement, customer support load, or subscription revenue 1. Weighing the outcomes — Make sure that you can evaluate the outcomes based on their impact. For example, you might weigh a “+10 for user engagement” against a “-5 for support load” to help you make your decision 1. Choosing the most impactful path — Once you have the decision tree in place, you need to analyze which paths and choices would align best with your product’s goals and bring the highest potential impact. Make sure to stay flexible in case new obstacles appear 1. Iterating on the results — Keep your decision tree up-to-date with the latest learning. After the implementation of the first decision, product results and feedback can help you make tweaks and adjustments to ensure that the tree remains a relevant guide #### What are the different types of decision trees? After understanding the basic concept behind decision trees, I want to present three more specific trees for product managers. I’ve used all three types in various situations in the last years to better visualize decisions and communicate with stakeholders: Driver tree A driver tree breaks down main objectives into multiple drivers that influence them. The challenge is to be as specific as possible on what influences the objective. I’ve used this type of tree for a challenge in my former company. We aimed to improve our profit and loss when sending physical cards to users. Together with my data analyst I created a driver tree to identify cost drivers. Ultimately, we discovered that the actual problems were different from what was initially proposed from leadership. As a result, we conducted several A/B tests to gauge the impact of our changes and managed to save millions of Euros for the business in just a few weeks, instead of developing a solution for a problem that did not truly exist. Opportunity solution tree Opportunity solution trees are created especially for product managers. They mainly focus on growth avenues and their potential impact. Begin by identifying a well-defined problem, then explore various opportunities and sub-opportunities. Within these opportunities, come up with potential solutions and create specific experiments to test them out. It’s the perfect tree to visualize a roadmap or decide what to do next and link it back to the why. It’s also a great way to communicate better with your team and your stakeholders. KPI tree A KPI tree helps you understand how the company’s KPIs influence each other. For example, if increasing “user engagement” is your main goal, this tree dissects what drives it, such as “app performance,” “content quality,” or “user experience.” In the past, I’ve used these trees to make sure I was tracking the right things within my teams, but also to see if our current work actually had the potential to create impact. #### Conclusion You can use decision trees to get a better picture of the complex world of product and company building. However, you must create and use them carefully, review them often, and always focus on what’s best for the user. Now that you’ve learned about decision trees, I hope you feel ready to use them in your next tough decision. Don’t be afraid to make your first decision tree and see how helpful it can be. This article first appeared on the logrocket blog ================================================================================ END OF DOCUMENT ================================================================================ Citation format: Hipp, Alexander. "[Title]." Alexander Hipp, [Date]. [URL]. Contact: https://linkedin.com/in/hippalexander