[{"categories":null,"contents":"We are all painters The brown compromise is an analogy from the painting world. The story goes like this: if you ask a family of five folks living in the same house which colour they prefer, you may end up with a dataset like this one: green, yellow, blue, violet, and I don’t care (yes, this is not a colour!). You may also end up in a family (like mine) where one of the users (me!) is colour-blind and has a very different perception of the world than the other four family members.\nIf you don’t apply any other criteria and respect everybody’s preference, you will end up with a brown colour of some sort. More or less dark. You can also spice up the model and use more or less complex weight-scaling and even advanced mathematics, but you will end up in various forms of brown as you add more people to the group.Notice that nobody, in our example, says white. Nonetheless, most houses tend to have lots of white/clear colours. Also notice that very few houses are painted in brown.\n{{\u0026lt; html_include \u0026ldquo;venn_brown_compromise.html\u0026rdquo; \u0026gt;}}\nThis type of decision-making also happens in a business context, especially in the product and design world. When you share a design document of any type (i.e: wireframe, Figma, design doc, product brief, PRD, press release/FAQ, etc.) … you will receive feedback. The feedback is used to decide either a go/no go decision or some more nuanced decision (scope, architecture, etc.).\nUsually, given four stakeholders, you will most certainly receive different types of feedback\nI don’t care, but when can you ship it [I want your team to work on another project that has not yet been prioritized!] I will never use this [this is terrible, don’t ship it!] Can you also do X and Y while revisiting this flow? I hate it you should do B instead. The feedback comes from various folks you must please, including stakeholders, direct or indirect reports, peers, etc. And quite often, the main strategy to get this initiative/project moving is the brown compromise: the teams deals with all these influences by trying to please everyone. For instance, given the feedback above, the team will incorporate into their A project a bit of X, a bit of Y and also more B. Doing this will lead to a brown compromise that does not meet anyone’s need and is complex, hard to explain, super expensive to build, support and maintain. The business impact will be low (if any).\nWhy do we agree to it? Three main reasons. Each is psychological and directly linked to behaviour/habits related to our desires to please, serve authority and belong.\nDesire to [blindly] please others: We are afraid of the tension and negative emotions that arise in us when we disagree with people we love and respect. The other person who respects and/or loves you also has the same behaviour. Without a shared and strong commitment to being radically candid with each other, this fear of our negative reaction is a root cause for the brown compromise between humans. Desire to [blindly] respect authority: We were all taught (kindergarten, school. College, university, parents, family, etc.) to respect authority from a very young age. When an authority figure proposes something, we are very reluctant to confront this proposal directly. Open communication, trust and a safe space are hard prerequisites empowering us to be radically candid with our managers or authority figures.. Group thinking: Group thinking is connected to our deepest fear as human beings: the fear of being rejected from the group. In primitive societies, being rejected from the group (banishment) was a death sentence! It creates, for every group member, extreme pressure to conform. To be nice to the group, everyone will tend to stay centred around what is agreed upon. The alpha of the group will help the group to come up with a brown compromise: his goal is to remain the alpha, and he does not care much about the compromise as long as the group remains together and grows. The Brown compromise in a work environment: Product Management case study In a professional environment, you are rarely the sole decision maker. For instance, a typical product team includes engineers, designer(s) and a product manager. Sometimes it includes additional profiles like product marketing, data, and other specialties, depending on the team\u0026rsquo;s needs (legal, security, etc.).\nThe cross-functional (matrix) impact In a matrix team most members do not report to each other but report to another hierarchy. They are members of another group. It creates a complex group-belonging system. Quite complex for large organizations, way simpler for start-ups/smaller structures. For instance, inside the team, craft teams overlap with each other.\nThe hierarchical impact At the organizational level, each team also belongs to another structure:\nThe product team is part of another larger team: maybe in charge of part of the product experience (ex: onboarding, activation, payment, etc.) The larger team is part of another team: for instance, the whole R\u0026amp;D organization producing all the product experiences Everyone is also part of the same organization and ultimately, the CEO has global authority on everybody. When a product team receives feedback from all these levels of authority from all these groups (with various levels of belonging and various levels of safe space), all the habits detailed above kicks-in at the same time. All these factors constitute a perfect storm to create a system that maximizes the production of brown compromises every time there is some tension or a decision that needs to happen.\nIn this context, many teams fail to make good decisions. Why is it? Feedback is always ambiguous and has to be balanced between internal and external (user testing) feedback. This ambiguity amplifies the three root-causes identified above: trying to please everyone, respecting authority and belonging to all our groups.\nHow to avoid the brown compromise then? Here are three antidotes to the brown compromise behaviour. I think they are all equally important, and depending on the situation, you may need to apply a single one or have to work hard and apply all of them. The team is part of a system, and the more brown compromise a team has done, the harder it is to change behaviour: every decision reinforces the decision-making behaviour. It causes more and more confusion and more disengagement (harder to find an owner).\nClarify Ownership Find a single-threaded owner! As we discussed, group thinking is dangerous, especially when associated with our desire to please authority and others. Important decisions should have a well-identified single-threaded owner, not a group.\nWho should own a decision?\nUsually, the owner has a set of clear characteristics: more context, more skills in this area and more experience. She is also dedicated to this project/decision (ideally working full-time in this domain and this domain only!). She is committed to this project/decision and will live with the consequences of the decision. The success of the decision owner will directly impact her impact review. The owner is the best positioned to apply the next two brown compromise remedies.\n{{\u0026lt; figure src=\u0026quot;/schemas/ownership-vicious-circle.svg\u0026quot; \u0026gt;}}\nOn the contrary, once you have identified a single-threaded owner for a specific problem space/area, you can create a positive reinforcement loop.\n{{\u0026lt; figure src=\u0026quot;/schemas/ownership-virtuous-circle.svg\u0026quot; \u0026gt;}}\nDefine success If you don’t know what success looks like, you cannot optimize your decisions to get there as fast as possible, and you will not be able to learn whether this was a good decision or a bad one.\nMake it crystal clear. Make it simple. Make it memorable. Make it measurable.\nShare your success criteria and debate + align with the authority figures until you have a clear mandate. This is the goal of various product and design techniques like Product Requirement Documents, PR/FAQ systems, Product Brief, Design Doc, RFC systems, etc.\nWhen success is not defined, unclear or partial (team only, stakeholder only, etc.), it causes more and more brown compromises to be made. Everything becomes less and less clear as well as less measurable. It, in turn, removes the ability for the team to learn and improve their success definition skills.\n{{\u0026lt; figure src=\u0026quot;/schemas/define-success-vicious-circle.svg\u0026quot; \u0026gt;}}\nOn the contrary, you can create a positive reinforcement loop when you define clearly success criteria for a decision that will lead to more learnings and less brown compromises:\n{{\u0026lt; figure src=\u0026quot;/schemas/define-success-virtuous-circle.svg\u0026quot; \u0026gt;}}\nBreath: create time for yourself and for the team ! Making a decision is, by nature, uncomfortable: it is always ambiguous and involves the future. It causes stress. When stressed, we want to fight or flee the scene. We want to get it done as fast as possible. In these situations, we revert to our habits (feelings, authority, group thinking). The more stressed you are, the worse your decisions will be. This section applies only to irreversible/hard decisions: please don’t slow down the easy/reversible decisions!\nAs an individual: breathe! And breathe again. And again (you need at least three breaths!).\nAt the team level, it will take more than a few breaths to succeed (but this is an excellent start!). You need to create the space required to gather context, gather evidence, formulate hypotheses, test them, understand and formulate the trade-offs and then decide. You also need time to apply the two precedent antidotes (find an owner, and set-up well-defined success criteria).\nUse delay to create a breathing space for the team. Manage expectations by asking (for instance) for a two-week period where the team will have time to breathe, hold the tension and unpack what is essential. Make it a high-integrity commitment to come back with the stakeholder at a specific date and time with the team proposal.\nWithout time to process the feedback, you will have a brown compromise, a team that feels stressed, reactive and more and more disengaged.\n{{\u0026lt; figure src=\u0026quot;/schemas/breath-vicious-circle.svg\u0026quot; \u0026gt;}}\nOn the other hand, for hard and difficult decisions, with a realistic timeline, you will be able to find an owner, define success criteria, find relevant data, align internally and with stakeholders to make a great decision while leveraging the stress to create a positive momentum for the team.\n{{\u0026lt; figure src=\u0026quot;/schemas/breath-virtuous-circle.svg\u0026quot; \u0026gt;}}\nProactivity leads to empowerment, reactivity leads to disengagement.\nConclusion The brown compromise is a helpful concept to master at any point in time. Processes, tools and culture within organizations are the root cause of producing lots or few brown compromises. Teams and individuals can influence organizations (within their team) but ultimately, this is a leadership and systemic issue.\nThankfully, we have seen three antidotes that can prevent the problem altogether: Find a single-threaded owner (who will champion the decision) Define success (crystal clear, simple, memorable, measurable) Breath (create breathing time for the team)\nApplying these antidotes consistently leads to the continuous growth of team members, teams of teams and of the organization. It creates the mental space for everyone to contribute meaningfully, increasing the quality of decisions over time. Think of it as compounding interests for your bank account. It leads to more peace of mind (breathe!) and a proactive team that is not afraid to tackle hard and ambiguous problems.\nThese antidotes are not a blanket guarantee that every brown compromise will be avoided, but it will maximize the probability of making a better decision, and provide the team with more autonomy, mastery and purpose.\nProgression over perfection!\n{{\u0026lt; feedback-en \u0026gt;}}\n","permalink":"//localhost:1313/en/post/how-to-escape-the-brown-compromise-trap/","tags":["Product Management","How-to","Leadership"],"title":"How to Escape the Brown Compromise Trap"},{"categories":null,"contents":"Navigating the Rhythms of the Mind An elephant at sunset by Aarón Blanco Tejedor on UnspashPhoto by Aarón Blanco Tejedor on Unspash\nOur mind operates with two main paradigms. Open or closed.\nOpenness is the feeling we experience when connecting directly with our experience. It can be while being in the flow state, as identified by psychologist Mihaly Csikszentmihalyi where we lose our sense of time and solicit our brain effortlessly. We have multiple expressions for these states.\nIf you meditate, it can be the open feeling of pure awareness as vast as the blue sky and accepting of any experience. When running, you can experience the runner\u0026rsquo;s high state of mind \u0026amp; body. When competing in a sport or game of chess, it happens when the self disappears: you are entirely focused and engaged. The feeling is called the groove if you play or listen to music or dance. For intellectual or manual work, you feel in the zone. It happens when learning new concepts, languages, tools, and techniques and creating things (woodworking and blogging, for instance).\nA multitude of terms and expressions exists to designate open experiences. They all imperfectly describe our open minds.\nWhen our mind is open, we associate these states with feelings like happiness, curiosity, effortless, control, empathy, relatedness, togetherness. These feelings lead to growth, wisdom, joy and happiness. There is no self in these feelings, simply a wide-open sensation welcoming and joyful.\nTypical Open vs Closed feelings - (c) RadicalOptimist.org 2022 Closed is a feeling we have when our self feels threatened. It is a feeling designed to protect us from danger. We have three basic modes of survival: fight/flight/freeze.\nThe flight response: we are trying to make ourselves as small as possible to not appear as a target for predators. We also protect our vital and reproductive organs. We blush as blood is pumped faster and stronger in our bloodstream to prepare us for the life-saving effort, and we run away from the threat. The freeze response: we do precisely that. We are indecisive, incapable of taking any action. We wait until the threat is gone. The body is also ready for a life-saving effort as we can transition to a fight-or-flight response: both require a high-intensity effort. The fight response: we manifest ourselves in the physical world. We type upper-case hate messages and press send without any thought; we make ourselves bigger and change our appearance and behaviour to be intimidating and threatening to others. We raise our voices and adopt a dominant position. We want to be the alpha in the room and impose our presence and charisma on others. In these states, the ego manifests itself. There is a clear separation between us and the world and others. We have tunnel vision and even tunnel perception: we can only focus our attention and energy on some particular aspects of the experiences. These states close our perception of the outside world, and we focus all our resources and energy on the danger source that threatens our survival.\nWhen our mind is closed, it manifests as fear, anger, stress, indecision, craving for possession, authority and fear. It can happen at work, at home, in a crowd, in public speaking (or writing), during family dinners, performance evaluations or meeting strangers. It can lead to chronic stress, chronic illness, unhappiness and burn-out.\nConnexion with Maslow\u0026rsquo;s pyramid Our open \u0026amp; closed states relate to Maslow\u0026rsquo;s pyramid of needs. While our fight or flight reflex is indispensable to ensure our physiological and physical safety, it is hurting our ability to develop our self-esteem and self-actualization.\nSchema of Maslow\u0026#39;s needs with the open and closed experiences. Good news: open and closed states do not last! As you all know by now, these experiences (whether open or closed) are all temporary. You can remember when you were happy or a pleasant experience from yesterday when listening to a podcast. Or your latest crisis at work or with a close friend or family member.\nIn our life, we alternate between these extremes. In one state, our self disappears (open); in the other, our self takes center stage in our experience. Both of these experiences constitute a strong argument that you don’t have a stable self that behaves identically and consistently, nor that you don\u0026rsquo;t have a self (open states).\nYou only have open, closed and in-between experiences.\nWhat is Happiness? Our mind operates within two primary paradigms: openness and closure. Openness allows us to discover our interconnectedness with the universe. Closure compels us to protect ourselves from potential dangers: it limits our perception and confines us to negative patterns to protect ourselves from real or imaginary threats.\nThroughout our lives, we oscillate between these two states. It is crucial to recognize that they are only temporary experiences. A stable and consistent self does not define us, nor should we identify with our states of openness.\nReal life happens at each instant between these two types of states.\nHappiness is your way to find balance between these two type of states.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/happiness-a-dance-of-openness-and-closure/","tags":["Happiness","Optimist","Psychology"],"title":"Happiness: a Dance of Openness and Closure"},{"categories":null,"contents":"What better moment to reflect on life, life choices and happiness than a day after you were laid off?\nUltimately, the reasons do not matter much and will not be exposed here.\nA one to zero transition: I realized today that quitting your job (without another one planned) or being fired is a 1-to-0 transition. In physics, this is called a non-linear transition. It describes rapidly evolving phenomena like phase transitions and the exponential growth of tiny lifeforms. We don\u0026rsquo;t practice (mentally) this 0-to-1 transition! It is, in fact, the exact opposite of a prevalent mental model of the product \u0026amp; business world. Pether Thiel popularized the 0-to-1 mental model in a well-known book of the same name.\nA one to zero transition It is incredibly challenging because I consider myself a 0-to-1 person: entrepreneur, start-up, team builder, product builder, and team builder. Let\u0026rsquo;s see what a 1-to-0 transition looks like:\nWhen you lose your job, you realize we are all addicted to our job. Like any addiction, losing it during a 1-to-0 transition creates withdrawal symptoms.\n1-to-0 withdrawal symptoms: No more connexions. All the relationships you developed with coworkers/customers/partners seem to disappear. They seem irremediably gone. It feels like losing someone: you can still hear their voice, their laugh, their accent, etc., but like any other memory, it will slowly fade with time and disappear. No more habits. Suddenly, your calendar is \u0026hellip; empty! And you have to figure out what to do with your time. This can be daunting, especially while you mourn the losses associated with a 1-to-0 transition. It is hard because instead of being part of a system that imposes a specific discipline, you now have to think about every task: what will you do next? You rapidly reach decision fatigue and this can become a vicious circle. Less Ego: Ego is pumped by our job in three main ways: Job Title and Employer name, Scope of what you were working on (impact/power) and monetization (money you were earning). All this is going to zero for a while. If you had any attachment to your title, your revenues or the scope of what you were doing, you would feel it quite acutely. Tangled symptoms Most of these feelings are tangled together and will be hard to separate. Having a mental model to identify them will help process this information.\nHow tangled are the job withdrawal symptoms How do I feel about these symptoms? This will be different for everyone and each 1-to-0 transition.\nConnexion: This is the hardest for me. As a team player, coach and manager, I always build solid and meaningful personal relationships with the humans I work with. Most of us do. I feel this one quite acutely! Habits: I am disciplined, and I decided not to change my daily routine of waking with the sun, meditation, reading, writing, coffee, physical activity (biking these days), etc. Not much impact (for now) besides the unusual feeling of having a lot of free time! Ego: I don\u0026rsquo;t feel a sense of loss related to my ego and job loss yet. I expect this to come later, especially if I remain unemployed or have not had a project for a long time. Society can make you feel excluded if you are not a productive contributor. You can practice the following mantra: I am not my job and my job does not define me as human being.\nWhat can you do? I did my research, and here are some tips that could help:\nChange your environment! You have a lot of free time now. Leverage this to experiment with other environments. Go outside, to the library, to this coffee you did not visit yet. Don\u0026rsquo;t try to maintain the same environment: remember that this is a 1-to-0 transition: changing your environment will help your brain accept this change. Distract yourself! Seriously. You will feel the urge to work on stuff. Maybe even write down the unfinished aspects of your job (this can be quite therapeutic!) or even continue working on specific issues/projects/past or future decisions. Don\u0026rsquo;t! If you want to journal it, do it but then leave the past to rest and resist these urges to continue your past job role \u0026amp; responsibilities as if you still had a job. Distracting yourself will cause dopamine release and demonstrate to your brain that you can find pleasure outside of work! Don\u0026rsquo;t stay isolated! Talk to your family and friends. Build your support network (alumni, etc.). If possible, do not talk job or work: you don\u0026rsquo;t want to reexperience the addiction you are trying to break! You may also want to consider finding a health counsellor (and this is quite often part of your separation package) Have fun! It may be the most counterintuitive, but life decided to give you some free time! Change your environment (to have more fun!), distract yourself (to also have more fun!) and create/reinforce meaningful connexions with fellow humans. Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/yesterday-i-was-fired/","tags":["Happiness","Work","Essay"],"title":"Yesterday I was fired 🔥"},{"categories":null,"contents":"This blog is relying heavily on Nudge by Richard H. Thaler and Cass R. Sunstein. While I highly recommend this book, this is not a review of the book, and you do not need to have read the book to enjoy this article.\nIn this enjoyable read, with a lot of humour, the authors present the impact of choices and decision-making on critical economic and societal issues: healthcare, loans, subprime, student loan, education, marriage, etc.\nWith a lot of humour, the authors present two key personas: The Econs and the Humans.\nThe Econs\nOn one side, the Econs: These folks are pure analytical brainpower. They are spreadsheet experts, and before making any decision they will review thoroughly the options, survey the market for the best possible solution and come up with the best possible choice architecture for their own situation. Imagine a spreadsheet with 20 columns and more, some type of future projections and then all the weighted criteria based on their own situation and problem.\nTo give you an example, an Econ friend of mine was looking for a new microwave. He built a spreadsheet with 20 interesting models for his use case and then came up with 30 criteria (each in its column!). All in all, he filled in 600 values. He used online product descriptions, reviews, and local flyers, visited some stores, and took pictures of the micro-wave he found. He also ordered a special consumer report edition dedicated to home appliance reviews in order to complement his analysis. Then he made his choice with a scorecard formula weighting all the various criteria. He finally purchased the selected microwave based on this thorough analysis.\nThe Humans\nOn the other side, the Humans. Humans are not as rational as the Econs. When faced with lots of choices, they do not come up with a spreadsheet with 600 values. They prefer to enjoy life and are quite happy making decisions without a formal model and a formal analysis. They rely on other signals to make decisions in particular feelings (beauty, trust, etc.), quality of the pictures and social proof.\nFor most of us, Humans, if your microwave is broken, you will most certainly look at the flyers in your mailbox (if you still accept them!), define a budget and browse online your two or three favourite places where you had good customer service. Then you will commit to the purchase and buy it.\nChoice Architecture and Choice Architects\nEach time your product gives a choice to your users, you are implementing a choice architecture. Most of the systems are designed by experts, and experts tend to be of the Econ type. They are well aware of the context, have deep knowledge of the problem space, and want to maximize their users\u0026rsquo; possibilities. A typical flow in product development is that we are developing our product for the CEO or any high-pay person. Moreover, we often assume everyone is like us and will behave like us when faced with these choices (especially in teams lacking diversity or trust).\nWe, as product managers, are often in this category: we are subject-matter experts in an area (we are in love with the problem space, after all!). We also have goals for our products, for instance, objectives and key results. We also love to measure things and behaviours and supplement our qualitative research with hard evidence.\nUser testing and UI design are robust anti-bias processes that help the team realize this mistake: nothing is more enlightening than watching a user struggling to make a choice that seems effortless and evident for the product team…\nA Neutral choice architecture does not exist!\nThe Nudge authors demonstrate that there is no neutral choice architecture. Let’s see why!\nYour users will most certainly trust your defaults. That said, because Humans are change adverse, they will stick with the default for a long time even if it is detrimental to their long time success (or health, financial independence, etc.).\nIf you refuse to have defaults, you are forcing your new users (with minimal context!) to choose from a list of options. In this case, the first option listed (the default option!) will become the most used one! This has been proven to have consequential decisions: for instance, being listed first on a ballot give this candidate roughly 7% more vote compared to other candidates who have a similar level of popularity!\nIf you randomize the list, you are also choosing your users: you are choosing to distribute each option equally. Once done, you will realize that it will most certainly cause a great disservice to your users as they will stick with this random default for a long time for no good reason (your users do not have random needs!).\nAs you can see, it is impossible to “not decide” and to implement a “neutral” choice architecture in your product!\nPMs most crucial responsibility should be to set up a correct choice architecture for all their users as their needs evolve.\nYour users are not static personas. As they start using your product, the choice architecture should support their growing understanding of your product. Thinking about your users with a video game analogy may be helpful.\nNewbies/New users have little context and lots of trusts. They decided to purchase and use your product after all! They should not be overwhelmed with a complex choice architecture. The default setup will remain the most prevalent option for these users. If no default is possible, radio buttons and simple high-level selection with a wizard and in-context help sounds like a great idea. In most video games, we have a tutorial mode where every choice is very limited but easier to make and understand than the “real game” with helpful contextual help and a safe zone to experiment and learn. As users better understand your product, they learn more about their needs and what your product can and can not do. They will be very interested in certain areas that are very important or relevant to them. This would be the “main quest” or “main gameplay” for most players in a video game. As a PM, you make these controls/setups readily available and discoverable as your users become more proficient with your product. Power users’ needs differ: they have mastered the fundamental principles and are experts in their domain. To continue the video-game analogy, these players require “add-ons”, “plugins,” or even “mods” to be satisfied. They are also exploring all the options, quests, and sub-quests to ensure they have a complete experience with the game. A platform approach with API, partners and apps can play a considerable role in pleasing these experts. They tend to be Econs, happy to learn and read hundreds of documentation pages, advanced tutorials and developer docs to meet their needs. The PM must carefully determine these functionalities: what is not directly doable in your product but can be extended via third-party and partnerships? Conclusion\nThe choice architecture for your product is essential to remove friction and ensure the adoption and usage of your product for new, experienced, and power-users. As a product manager, you should consider how to help user graduate from newbies to experienced users to power-users and not overoptimize for one type of user experience.\nAwareness: A first important step is to be aware that most of the product team (and even, at a certain level, your company!) tend to think like “Econs.” They know all the complexities, subtleties, competing implementations, trade-offs, possible success metrics and features required to implement a new product (or functionality). Acceptance: You cannot solve the Human\u0026rsquo;s and Econ’s problems simultaneously. Try to divide your use cases/job to be done for new users (mostly Humans, great default/straightforward choice, tutorial mode), experienced users (more functionalities, less need for contextual help — a mix of Humans and Econs) and your power users (mostly Econs with lots of context, lots of expertise and an exact need) Action: Make sure you test your choice architecture with all types of users (newbies/tutorial mode, experienced users, power users). Validate the content and information architecture that support these choices with each user type. Based on this discovery, define carefully what need your product will not fulfill and whether or not you want to enable third parties to solve this need (meeting and validating your ideas with potential partners is also a great way to ensure this will happen!). In general, it is easier for new product teams to focus on new users because:\nThey don’t have a lot of contexts/face the same challenges as new users. They focus on acquisition as this tends to provide more immediate value. Once the team gains experience and context, they can focus on the power users (harder /more challenging problems). Once a team has the expertise, there is no turning back: this is the curse of knowledge bias (at the team level). We tend to lose our Human nature and become increasingly Econ-like with sophisticated mental models, tools, and holistic understanding of the problem space. Two useful tactics to look at things with a beginner\u0026rsquo;s mind:\nfresh eyes either from new team members, interns and other specialties testing with non-users Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/nudge-why-product-managers-should-become-proficient-choice-architects/","tags":["Book","Choice"],"title":"📖 Nudge: Why Product Managers Should Become Proficient Choice Architects"},{"categories":null,"contents":"Introduction Do more with less from Black Mouse Design\nInstead of asking for more, focus on helping your team succeed. Ensure you align your goals with the team’s current capacity: this is the only way for you to lead the team and help each team member grow.\nAs a Product Manager, there is no way we can prioritize all the critical needs improvements and new ideas from our users, stakeholders, customers, family and friends.\nWe can have two attitudes when faced with too many projects and not enough resources to accomplish our dreams and product goals.\n— You can ask for more resources; or — You do more while asking for less. Let’s examine the consequence of asking for more: — It will sap your mental energy. You will live in the future and pester stakeholders for more. Stakeholders will consider you as an immature product manager (leader) that is not in control of his/her team’s outcome. — Your team will perceive you as never satisfied: you may even impose unreasonable scope and deadlines (the so-called death march) and lead your team members to burn-out and repetitive failures to execute and deliver value. — Your team’s best interests and yours are not aligned. Your own goal is extrinsic: you want an even bigger (smarter, more senior, etc.) team. Because of this, you will focus your attention and efforts on these externalities. You will be unable to give your team the attention and care it needs to succeed. Let’s examine the consequences of doing more and asking for less: The mindset of doing more with less is essential for any leader including product managers. Instead of focusing on what you don’t have (larger team, more skilled team-members, simpler problem space, etc.) you focus on what you have (a great team, a big and hairy ambitious goal, a super-complex project, etc.) and work hard to optimize the outcome of your team. This will set you up for success:\n— You will set ultra-realistic goals and deadlines and prioritize better. You will focus your attention on execution and make sure scope creep does not happen. Not under your watch. — You will become laser-focused and very skilled at avoiding distractions and shielding the team from distractions. The team will notice, trust you more and help you reach your shared goals. You can only succeed if the team succeeds! — Your stakeholders will be positively impressed by your ability to ship tremendous value with few resources. Conclusion It may be counter-intuitive to less experienced product managers but focusing on the team and embracing each members’ strengths and weaknesses (including your own) is the best way to have an impact. Embrace this fact and make it your mantra each time you interact with a team member.\nOnly once you will have a proven track record will you be trusted with additional scope. It will open up the world for you regarding product leadership opportunities, stakeholder trust and ultimately, team size.\nConvinced? Please watch Thanks Thanks a lot to Cliff des Ligneris \u0026amp; Nicolas Lupien \u0026amp; Ramya Srinivasan for proofreading \u0026amp; super valuable feedback.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/dont-ask-for-more-resources-do-more-with-what-you-have/","tags":null,"title":"Don’t Ask For More Resources: Do More With What You Have!"},{"categories":null,"contents":"Boost your success and team growth by … not deciding! Product Managers do not have authority over the product team members. The same can be said for almost any member of an organization. This is even truer in a post-pandemic world where, suddenly, every organization and human being has to change, learn and lead others.\nWhen I joined Shopify in 2018, my formal authority was zero: I was an individual contributor, and I could only rely on influence to achieve my goals.\nI did have some domain expertise (shipping \u0026amp; fulfillment) but in another context and country (hint: 🍷 \u0026amp; 🦘). Most of my team members had much more context on our customers’ real problems as well as more tenure, experience and official authority. I was providing a different point of view but was not a subject-matter expert: I had 0 informal authority,\nI would not say that this transition was easy, but it was (and still is!) a great source of retroaction that is continuously helping me become a better human. It may well be the subject of another article!\nIn this article, I want to share, based on these two very contrasting experiences, what I have now defined as “the dark side of authority,” whether this authority is formal (like attached to an organizational structure) or informal (because of experience or domain knowledge).\nDisclaimer: Authority and formal organizational structure are great and super-useful in times of crisis or during any emergency. You don’t want firefighters or ER practitioners to debate and start an alignment process during a fire or while you are on the operation table!\nLife with authority I started my professional career with lots of intrinsic and extrinsic authority. During my last year of university (Ph. D. in physics, Postdoc in distributed computing), I founded a tech company and was its CEO for nine years. The company was quite successful, and I was both an expert on the technology we were developing and the company’s ultimate formal authority holder.\nBeing a convinced humanist and Buddhist, I did my best to treat everyone’s voice and concerns inside the company equally. From the support-line specialist, the cleaning crew to some of the most brilliant open-source talent, engineers and sales professionals, I have had the privilege to lead.\nFast forward in 2018, 6 years after I sold my company and worked for three years as CTO/Chief of sales and then failed to launch and fund a startup, I was able to join Shopify in a product management role.\nThe Dark Side of Authority It does not convince anyone As C.E.O, co-founder and in general as an executive, you often have pleasant and unpleasant surprises. While expressing an idea or a recommendation, you realize that these suggestions have a life of their own!\nThese suggestions were not debated and are now on top of the backlog. Your suggestions are used during meetings to prioritize this feature … because you said so! Sometimes, the team did not bother to create an issue and went straight into implementation mode and the code is live in production!\nNone of the owners of this area were part of these discussions, and they are not convinced!\nSuch events are a net negative for these leaders and for the team they lead. It even has a name: a HIPPO (Highest Income Person‘s Personal Opinion)! It is often called a “XXX-Tornado” where XXX is the exec or HIPPO’s calling this particular shot. In my case a so-called “Ben-Tornado”.\nThe TL;DR is don’t call the shots unless it is a business-threatening (or life-threatening!) situation (for an employee, a team, a business unit, a customer, etc.). Be aware that when you “call the shot,” you destroy the shared view of the world and mental models that your team(s) have been patiently putting together.\nIt promotes a culture of secrets, shadows and gives a prominent role to politics The organization rarely, if ever, evaluates the impact of the HIPPO shots. They are like “black ops” with private channels, low visibility, hidden emails, screenshots and videos with restricted permissions, low transparency and … low impact.\nEveryone’s goal on these black-ops team is to rapidly do what has been asked without even bothering with understanding the success metrics and how it fits within the team roadmap and priorities. I have been on such teams and the prioritization method is: what is the minimal amount of work we can do to get this behind us and come back to our team’s work?\nAs a consequence, these HIPPO processes, features launches and improvements are encouraging any team member to actually promote their own ideas/problems and simply voice them to the HIPPO with the secret hope that a HIPPO will mention it at the next leadership meeting.\nEveryone understanding the power dynamic suddenly stop making sound plans and simply wait for the next HIPPO tornado. Influencing and nudging everyone between them and the HIPPO to bring this subject to the HIPPO’s attention.\nTL;DR: **** As a leader with formal or informal authority, do not encourage office politics. If you are in such a “chain of command,” voice your concerns and do your best to make sure this HIPPO tornado follows the normal approval process and is shared transparently to your team and reports. Become transparent and do not hold-on information from your team and reports.\nYou are, slowly but surely, becoming the weak link The more a leader uses authority (formal or informal), the more s/he becomes indispensable for his team’s success.\nAs the need of the team grow, the authoritarian leader has now to scale and grow at an unprecedented rate. The more distance from the frontline exists, the less context such authoritarian leaders have. Slowly but surely, the team’s needs will surpass the leader’s capacity to gather context and make significant decisions.\nThis chain of events has been the root-cause for the demise of great teams, organizations and companies.\nTL;DR: **** I sincerely believe that authority usage should be restricted to value-preservation decisions. Do not use authority with the false hope that you will create long-lasting value.\nSaid differently, the organization’s authority given to a human being should help her/him ensure that the organization continues to exist by managing risk appropriately. Your main responsibility is to provide the teams you lead with the maximum autonomy level possible while articulating very clearly the value-preserving boundaries imposed of your organization.\nIt prevents growth in your team If you are “calling the shots”, you will have a hard time to help the team grow. As team members gather more context and gain informal and formal authority, they will continue to look at you very much like the classic paternal family structures.\nYour reluctance to share the authority given to you by the organization to preserve value, end-up blocking the growth of your team. You are taking away each and every opportunity the team and individuals have to learn. A manager that has completed his journey to the dark side is even called a micro-manager.\nAs people mature and graduate, they will simply leave your team and find a proper team where they will be able to thrive and grow as leaders.\nTL;DR: Each time you “call a shot”, make sure that this is your role and consider who are you depriving of a crucial learning opportunity? Decide whether or not you need to be involved. If this is about value-creation, refuse to decide and make sure the decision owner knows that you are here to support her/him but that it is not your call to make.\nConclusion For new managers and newly appointed (formal) or revealed (informal) leaders, using authority is often perceived as the primary benefit of their new position. It may even be a stated goal in your career plan.\nTheir role models may have been imaginaries heroes with lots of formal and informal authority (princesses, awesome warrior-kings, elves, wizards or master Jedi, action-heroes, etc.) routinely “calling the shots”.\nIn reality, life is much messier than these mythical stories. As a leader, your success is your team’s success. The sooner you will relinquish calling the shots for trivial and key decisions that could not destroy value for your organization, the better for you and your team.\nUsing authority only to preserve value for your organization will help everyone interact with you and understand why you ask questions and want to be more involved in specific initiatives.\nIt will ensure that you will develop meaningful relationships and create learning opportunities for each human being on your team.\nIt will also and protect you and your team from our current millennium’s professional disease: burn-out.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/the-dark-side-of-authority/","tags":["Essay","Authority","Leadership"],"title":"The Dark Side of Authority"},{"categories":null,"contents":"Introduction \u0026amp; Definition In this blog post, we’ll explore the concept of “trifecta” (also called triad in some organizations) that I have seen used successfully in the past both at start-up and even at large scale organizations (ex: Shopify).\nLet’s start with a definition. The trifecta represents a subset of a product team whose goals are to capture systematically:\nvalue: for the business usability: for the user feasibility: technological, ethical, legal, etc. Valuable \u0026amp; Usable \u0026amp; Feasible are the trifecta goal! I will use the term craft in this article and would also like to define it: a craft is one or more people inside the product-team with their hierarchy, rituals and specialties. Example of craft includes engineering (sometimes back-end, front-end, mobile), UX (designer, researcher, content specialist, etc.), Product (product manager, product owner, product lead, etc.), data-science (data-scientist, etc.), commercial, legal, etc. Each organization is different and has a different structure to execute its mission. In this article, I will refer to “craft” as the various specialties \u0026amp; hierarchies that exist within the organization.\nMost of the time, the trifecta comprises the senior team members of the essential crafts required to build, launch and land your product. Launching a product is easy, but landing it is the hard part ;-) Trifecta goal — illustration by the author\nDepending on the maturity of your organization and team size, it can be a team of 1 (CEO/Founder), 2 (co-founders), 3 (UX, Product, Engineering) or more (commercial, data, partnership, etc.) depending on the problem space the product team is tackling.\nThe trifecta is an integral part of the product team and a kind of council of the wise that ensures alignment in all day-to-day activities.\nMost of the time, a majority of the trifecta members will have authority on some of the product team members as they lead/manage people directly. This statement is often true in the case of UX and engineering. This statement is false for product managers as their leads are not, generally, involved directly in the product team.\nHere is an example of a typical “classical” trifecta with three trifecta members and a product team of 11 people.\nTypical trifecta and product team composition Illustration by the author\nFeasibility/Engineering: Staff Developer (leading a team of developers) Usability/UX: Senior Designer (leading a team of UX folks) Value/Product: Product Manager Feasibility/Data: Senior Data-scientist (leading a team of data-scientist) Note: The “tri” in trifecta does not relate to the number of people in the trifecta (three main crafts: UX, Engineering and Product). It symbolizes that each trifecta member has a responsibility to help the product team make significant decisions quickly so that each of these decisions results in a systematically valuable, feasible and usable product.\nWhy a trifecta? What problem does it solve? 1 — Team alignment Product teams have the autonomy to decide what to do next and why. They have to convince stakeholders to do so. Why introduce a hierarchy at the team level?\nSteve Jobs — The trifecta is not here to tell product team members what to do!\nWhile this is a hierarchy inside the product team, it is crucial to notice that none of the trifecta members has authority on another trifecta member: they are all equals. And they all share the same goal: make sure the product is usable, feasible and valuable. Each brings its area of expertise to the table.\nOne of the main goals of the trifecta structure is to ensure inter-craft collaboration within the product team. With smart and experienced people, nobody inside the trifecta can understand the totality of the problem space! Because the trifecta members lead other product members, it is a guarantee that everyone on the product team, as well as stakeholders, share this view of the world.\nThis critical shared view of the world provides the basis for a healthy space where radical candour happens. Each product-team member can ask respectful questions and make sure each decision is considerate of her/his opinions and ideas.\nThe trifecta does not “lead by committee” to disempower trifecta members. Each craft owns its decisions. For instance:\nthe product trifecta member makes scope decision the UX trifecta member makes UX decisions, user flow decisions and any design decisions The Eng trifecta member makes implementation decisions, technology decisions, service level objectives’ decisions, etc. Data, Commercial, Go to market, Finance members decide for their craft as well. Once the trifecta sets the decision’s ownership, the other trifecta members may have to disagree and commit. Each trifecta member now supports this decision within their craft: they can use the correct language and arguments to justify the decision within their craft and, if necessary, bring back more information or better proposition that could lead to a decision change.\nWith a trifecta in place, each trifecta member naturally becomes more considerate and aware of the consequences, risks and impact of every impactful product decision.\nThe inter-craft team decision can happen within the product team during team rituals (planning sessions, retro, workshops, etc.). It also happens during regular 1:1: Trifecta members have regular 1:1 with their reports. Some also have 1:1 with specific product team members depending on the risk and decision to be made.\nThe trifecta decision happens during trifecta rituals: most of the time, a weekly meeting where the trifecta assesses progress, reviews the next steps, shares inter-craft news, plans team activities and makes critical decisions.\nTrifecta members also tend to have a weekly 1:1 meeting with each other to address any specific issue that could negatively impact the team and the product.\n2 — Informal stakeholder alignment Thanks to the hierarchy at play in each craft, each trifecta member also has weekly 1:1 within their own craft’s stakeholder. It is also common for trifecta members to have regular 1:1 with stakeholders of other crafts.\nAll these 1:1 allows feedback to flow continuously back and forth from craft to trifecta and from trifecta to craft regularly. Stakeholders can challenge each decision during these 1:1 and be very naive and candid about it. The most critical feedbacks come from inter-craft 1:1 with stakeholders from one craft and trifecta member from another craft.\nInter-craft decisions are often more ambiguous and more impactful than intra-craft decisions. The discussions between trifecta members and other craft leaders are essential to maintain the right inter-craft balance and ship impactful outcomes.\n3 — Formal stakeholder alignment During product reviews, the trifecta members are also aligned and have done all the required preparation work with the stakeholders. Usually, stakeholders only want to discuss and align on the most important (and potentially the most conflictual) decisions.\nBecause each of the trifecta members has a better understanding of other craft’s constraints and requirements, and because lots of informal alignment already occurs (via 1:1 and workshops), all the interested parties are well aware of the problem space and of the context of each decision.\nSometimes one or more stakeholders disagree with the solution. When it happens, the trifecta is mandated to deepen their understanding of the problem, craft, team and organizational constraints. The goal is now for the product team, led by the trifecta, to come back with a better solution.\nStakeholders control the product team resources. In some (less frequent) occasions, stakeholders can reassign the product team to another initiative while only the trifecta continues to work on the problem. These decisions do not signal a lack of trust: these decisions occur to protect the organization. Stakeholders estimate that the trifecta needs to build up the context and develop a better understanding of the problem-space. As a consequence, they keep only the most senior people active so that they have more time to focus on the problem at hand and reassign the team to more concrete and actionable product areas.\n4 — External alignment: other product teams \u0026amp; organizations The trifecta members also interact within the organization and outside of the organization regarding the product area they are focusing on. It gives them the authority to act as stakeholders for various related-project and to interact within their craft with any team that interacts with the product they are building.\nOnce again, the fact that each trifecta member as a global understanding of the various decisions, with a focus on the impact created at the crossroads of feasibility, usability and value, gives her/him a lot of context and a lot of ability to influence other teams decisions.\nIf the product area involves partners outside of the organization, trifecta members are also in an excellent position to interact effectively. They have developed an in-depth knowledge of the context of the product, and they are used to considering the feasibility, usability and value created by the product.\nConclusion Trifecta at the product team level plays a vital role in aligning the organization with each of the product decisions. While it introduces a hierarchy in the team, this hierarchy is pre-existing (team leads or seniority) in each craft. Trifecta members create alignment with each other and within the product team as well as with stakeholders in formal (regular lead/report 1:1, rituals) and informal (inter-crafts 1:1, workshops, etc.).\nThe trifecta is a bit like the heart of a product team. Ideally, stakeholders attribute a problem area to a trifecta at the early stages of the product lifecycle: ideation and exploration. The most experienced team members are assigned to the trifecta. Hard decisions tend to be decided by the trifecta using the existing scheduled meeting, 1:1 and also during an ad-hoc workshop with one or more team members and hands-on stakeholders.\nA high-performing trifecta will cause the team to operate at a high-level: hard decisions are debated thoroughly, but the owner will decide without delay. Stakeholders will feel confident that the key aspects of the product (valuable, feasible, usable) are covered and that all crafts (including their own) are aligned.\nTrust between the stakeholder and the trifecta causes the product team to be more proactive, more engaged and take more risks. Trust leads to better decisions and more collegial management of risk: the product team will take risks for the most impactful decision with the full commitment of the organization.\nHigh team morale and performance are root causes to ship, launch and land a great product. It starts with a high-performing trifecta.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/trifecta-product-teams-and-impact/","tags":["Product","UX","Business"],"title":"Trifecta: How to maximize a product teams impact"},{"categories":null,"contents":"Minimally Viable Products are a myth or, if you prefer a mental model. Always wrong but sometimes useful. Original Image: Making sense of MVP (Minimum Viable Product) and why I prefer Earliest Testable/Usable/Lovable by Henrik Kniberg\nVery much like Prometheus and the fire or Icarus and the sun they are powerful analogies and ideas that shape our view of the world. A tribute to their power is that, thousands of years after their creation, we still relate to them even if their initial context is long gone.\nAs a product manager, it would make sense to embrace and use the MVP myth. But should you?\nAll these myths have an historical context that is key to their understanding and also key to decide if you should pursue these myths … or not.\nIn the case of MVP, this myth was created in the context of start-ups as a way to minimize waste and help these newly born organizations and teams find product market fit in small, iterative, agile steps.\nA minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers and provide feedback for future product development\nIf you are not in such a context, pursuing and MVP approach will be impossible and detrimental to both your team, product, career and users. I discovered this the hard way when my team and I were tasked with the complete replatforming of the shipping rates configurations for … one million merchants.\nInitially, it could be easy to get frustrated at what appears as slowness and red-tape. In retrospect, I really think that this chain of events was caused by my unwillingness to embrace the complexity, scale and depth of the problem space I was exploring.\nComing from way smaller organizations, my original approach was to adopt the MVP framework and deliver incremental value. I quickly discovered that this was a mistake: successful organizations have safeguards to protect their customers. Most of these safeguards are part of the company culture. And culture is more powerful than your product manager desires ;-)\nThe safeguards are processes, tools and organizational systems that protect product teams from themselves. They limit the blast-radius of any product launch while maintaining a safe space where the product team car experiment and fail, learn and grow. To reflect this, each crafts (UX, Engineering, Product) have rituals to ensure the usability, speed, scalability and value of what will be launched.\nI was consistently trying to nudge, convince, charm, influence any decision in order to force the MVP approach. In a way, I was a blind MVP believer mainly because I applied this successfully in other venture and was also coaching and helping entrepreneur to successfully adopt it.\nSo what happened? Well, at some point the project was almost cancelled and only three persons, a minimally viable team composed of one experienced representative of each craft (UX, Engineering, Product) worked on the project. Once we took the time to reflect on what we needed to build, the minimal functionality and the enjoyable user experience, a team was reassigned to the project and we were able to build it.\nBut for more than 18 months we had exactly … 0 customer, 0 user and of course no MVP at all.\nAre you a blind MVP believer? MVP is what is defined, in philosophy, as an orthodoxy: you are either a believer or … a non believer. And by the way, the holy text has already been written: do not expect to change it or reinterpret it.\nLike any orthodoxy, a single mental model to apply for product development can only lead to stress, burnout, stagnation, less innovation, less diversity and less fun.\nThis is why I believe it is time to introduce another mental model linked to product development. MVP is very specific to a certain culture and context. If your organization does not have the culture or context relevant to MVP, don’t try to use this orthodoxy.\nThe Minimally enJoyable Product (MJP) What is an enJoyable product, can you explain? Based on my experience in a highly successful organization with a great culture and incredible growth, here is the proposed definition:\nA Minimally enJoyable Product is a product which scope is the one needed by the market at launch and with a quality and user experience that matches or surpass the one expected by users: it sparks Joy for its users.\nWhat is Joy? I will use a great definition written by C.S. Lewis:\n“Joy, which is here a technical term must be sharply distinguished both from Happiness and Pleasure; the fact that anyone who has experienced it will want it again… I doubt whether anyone who has tasted it would ever, if both were in his power, exchange it for all the pleasures in the world. But then Joy is never in our power and Pleasure often is” C. S. Lewis\nThis definition is interesting because it contrasts Joy with pleasure and even happiness. It is also an experiential definition: you have to experience it.\nCan a product bring joy.\nPlease think about it: when is the last time you experiences joy using a product? Why did this experience resonate with you? Was this experience only functional? usable? or did it provide something more? Scarcity vs abundance The MVP mental model was created in a world of scarcity. There was no recipe for start-up and start-up where few. We now live in a world of abundance. Start-ups are legions and the recipe for success is now well documented. Capital is also broadly available. The cost to develop a software are lowered every day with the generic availability of open-source libraries and the cloud remove the need for costly servers with a pay-per-use model. Most if not all organizations have adopted agile methodologies to ship faster.\nIn a world of plenty, as a customer, which product will you chose:\nA product that is valuable and usable A product that is valuable, usable and brings you joy Customers expectations How to use the MJP model and how does it differ from the MVP model? Most of the time, startups don’t have a clear culture or definition of quality. This is why the first hires are high-potential and self-motivated individuals with experience. The most senior people ensure the quality but this is an “as you ship” activity. The minimal quality is not defined and will be part of the MVP learnings. Most of the startup do not have a “design framework”, not product management methodologies, no or few “playbooks” , “standard operating procedures” and “service level agreement”.\nBy definition, start-ups don’t have customers. Really. They are seeking another myth, the Product Market Fit.\nWhat happens to products that do not spark joy? If you already have customers, you can not use the same tactic. You already have product market fit! Your users have certain expectations regarding your product and a MVP is not one of them.\nThey rely on your solution on a daily basis. And they expect an easy to use, powerful product: this is a given.\nThey also expect more: they want to have fun and enjoy the experience!\nWithout this spark, competitors will joyfully welcome them and help them solve their problems.\nIn a world of abundance, and not living in isolation in a monastery, you will be faced with alternatives that seems more enjoyable. Friends will start to invite you or recommend these products. And at some point, you will test it and experience joy. Then you will switch product and enjoy it with your friends or co-workers.\nMarie Kondo is famous for her Konmari method:\nImage source: Yourtango.com\nImagine the choices faced by your prospective and current customers?\nLet\u0026rsquo;s examine our product graveyard (negative examples): your first videogame, IRC, ICQ, MySpace, BlackBerry and all these products who where sparking joy at some points in our lives but they now have disappeared. Only pleasant memories remain while we took our attention (and business!) to another company.\nA positive example would be the Zoom success because of Covid-19. While other group-video conferences have been around for ages, most of them were not sparking joy: complex to use, tight to google, tight to facebook, tight to apple, not working at every occasion, no fun background to play with, etc.\nConclusion The MVP model is not enough for established companies and as a consequence for start-up who expect to disrupt the incumbents. In times of abundance and intense competition, products have to aim higher than bare-bone usability and viability.\nCompanies and product managers should have higher goals: they should aim for Joy and ship a Minimally enJoyable Product.\nOriginally published at https://hackernoon.com on May 1, 2020.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/dont-give-us-mvps-we-want-mjps-minimally-enjoyable-products-an-analysis/","tags":["Product Management","Joy"],"title":"Don't give us MVPs we want minimally enjoyable products!"},{"categories":null,"contents":"A simple set of questions to remove ambiguity, build team alignment and prioritize This method is directly inspired by Simon Sinek Golden Circle’s book and start with why method.\n“People don’t buy what you do, they buy why you do it.”- Simon Sinek\nSimon Sinek golden circle principle — Illustration by the author\nMethod description The method is simple: the team will answer each question individually (Why?, Who?, What?, How?). Some back and forth will most certainly happen between the questions as new ideas surfaced, and alignment is created.\nThis method generates engagement and high-quality discussions within the cross-functional team.\nThe outcome of this activity is simple: picture four zen-like slides containing one or two sentences or one schema of crystal clear, precise and easy to understand content that summarizes the current team alignment and next steps.\nWhen to use this method? The absolute minimum to use this method is a cross-disciplinary team assembled and ready to tackle a roughly defined problem. This method is particularly useful when thinking or exploring product feasibility.\nIdeally, you can bring to the first session an alpha or beta version of the materials that you use inside your organization to define a product — for instance, a product or project brief, a press-release, an issue.\nI believe that the questions’ order, from the circle’s center to the circle’s exterior, is the best possible one.\nIf you already had a session or have lots of great answers for some of the questions, it may be tempting (especially for a PM!) to skip the question altogether and optimize for time.\nResist the temptation to go fast! Remember that the primary goal of this activity is team alignment. Team alignment is never built by taking shortcuts, avoiding discussions or limiting interactions. Use this time to repeat the key messages, test their validity and make sure everyone understands them and is completely aligned.\nThe four questions ordered and their position regarding four quadrants — Illustration by the author\nThis process is iterative: you may need more than one session to get to the bottom of all the questions. Each session builds on the precedent. Between sessions, the team will have time to think about the findings, gather data, validate the various hypothesis.\nDepending on the ambiguity level of the product you are working on, one or more one hour sessions spaced by a few days works best. Each session can impact previously discussed answers: do not hesitate to come back and refine the previous answers to these questions so that they reflect the current team alignment.\nWho to invite? You should invite the cross-functional product team. In lots of organizations, this is the so-called trifecta whose goal is to ensure that the product will be usable, feasible and desirable.\nFeel free to invite passionate stakeholders, especially if they like to shape-up the work and contribute directly to the project. This is an excellent opportunity for them to weight-in and influences the team’s way of thinking about a problem space. If they remain silent, take this as a confirmation that the team is aligned with their views. The more they weight-in, the more they have strong opinions or valid contention points with the current team thinking and mental models for this product.\nIt is critical to have subject-matter experts in the meeting. If you do not have one of these experts on the team, find one and invite her/him. Deep expertise about the problem-space will help the team understand the problem and build a shared context about the product.\nData-scientists are also a great addition to the team. They are passionate about data, know existing data-sets, reports, dashboards and will help the team move rapidly from opinion-based discussion to data-informed discussion. During the session, they can analyze existing data and even create just in time rough queries to provide rapid answers to the team questions.\nThese sessions should be as intellectually stimulating as possible. Multiple points of view and expertise are key to produce such an environment. You should limit the attendance to 5–7 people maximum.\nAs a PM, you know that you can not please everyone.\nWhy do we want to build this product? Why is the most important and critical question. Take the time to write a mission statement for your project. Why are you doing it?\nIt can also be useful to answer the whitespace question: Why should we not build this product? Being the devil’s advocate will force you to consider all the potential risks and issues with your product and help the team align.\nLess is more for your why: aim for a single sentence. Two at most.\nThe five-why framework A beneficial method to help answer this question is the five-whys framework. Ideally, you want to spend time in the world of first-principles. If you are more familiar or want to use any root-cause analysis framework, go for it!\n5-Whys example — illustration by the author\nEthical and legal Is it especially important to clarify and agree on all the ethical and legal aspects impacted by the product? Do not hide non-ethical or borderline-ethical impacts. Make sure you address them in-depth with the team: this is a good and healthy discussion. Ethical questions are crucial whether your product affects a single user (start-up) or millions or even billions of people.\nYou can often start with a sentence and write it on the whiteboard or collaborative whiteboard if some team-members are remote. Make sure everyone in the team can contribute and is OK with it before moving to the next question.\nDon’t aim for perfection but for what I would call a “good enough” agreement within the team. Certain words or verbs could be debatable at this stage. Once you have a sentence that everyone can relate to: you are ready to move to the next step. Don’t get too attached to this first formulation: this first sentence will most certainly change later on as the team answers the other questions.\nWho are we building this product for? Depending on your organization, you either have lots of customers (established company) or none at all (start-up pre-product-market fit). If you are in a hyper-growth unicorn, you may have both problems at the same time.\nAnswering this question is critical to provide the team with a clear focus. A clear answer will remove future ambiguity and uncertainty for all future decisions related to this product. As a PM, you know that you can not please everyone. Use this question as an opportunity to make this actionable and top-of-mind for the team.\nThis discussion should be grounded in facts and reality. Beautiful ideas and principles are often crushed at this stage. Sometimes we do not have enough data; sometimes we know from past studies that this our target segment is not a homogenous group. Digging deeper may be necessary. Data scientists can help at this stage as they tend to have access to lots of data or can most of the time, roughly answer the team questions.\nUse the following guiding principle: try to find the best segment to deliver value for the least amount of effort by using the product team knowledge.\nAnswering this question may require you to discuss your product’s impact on some of your customers or partners (good or bad!) as well as the potential roll-out plan. Most of the time, it will trigger discussions about the ambition of the product: do you target a majority? A significant cohort of your current users? Only the one who will be delighted with your product? Do you start small and then scale?\nIs it OK to revisit answers to the Why question? Absolutely.\nDuring any phase of the Why-Who-What-How session, you may need to go back and forth to an earlier question. For instance, if you refine your target customers, you will be able to improve your Why by being much more focused and precise.\nIn fact, before moving to the next question, you should always revisit the precedent answers. You can use these questions to validate the team alignment:\nDoes it still make sense? Is our formulation one hundred percent compatible? Can we be more precise? Can we remove some useless words? What are we building? The team produced a strong and clear statement defining the Why and the Who. It is now time to find a creative way to operate the change you want in the world for the selected users.\nTeam alignment is never build by taking shortcuts, avoiding discussions or limiting interactions.\nEveryone will have a very different approach based on their background and role: business, UX, product, engineering, data, marketing. For this question, brainstorming techniques can be used effectively.\nBased on the cross-functional team experience and various known or expected constraints (budget, timing, stakeholder engagement, resources): what should the team build to ensure the best possible outcome for our targeted users?\nOnce again, you want to build a strong consensus and find the most cost-effective (also known as fastest) way to impact the lives of your targeted users. You should be ready to discuss divergent solutions. Be super open to ideas that do not involve writing code. For instance: could we achieve our outcome with a marketing campaign? Better help? Explanatory video? Better messaging?\nIn my experience, these ideas can quickly become experiments or iterations to validate your assumptions or start impacting your users’ life positively. Most of them are quick wins.\nThe output of this question can take the form of a table with the main items that will be impacted by the project. For instance, for a small experiment, we had four things to build involving various skills:\nModified home page (code + content + design + data) Modified order index page (code + content + design + data) Content: blog and/or evergreen documentation Experiment dashboard (data) If possible, a graphical representation (schema) is great. It can be build after the meeting. A visual representation will reinforce the mental model of what you want to build. It is way easier to share than words.\nVisual representation of what to build — Illustration by the author\nHow? are we going to build it From a product manager’s point of view, it can be frightening to ask this question. After all, roadmaps and planning are, after all, a product manager’s core responsibility.\nDon’t be afraid to introduce the team to the world of planning and roadmap.\nUse this question to build a team roadmap instead of a solitary product manager roadmap. Use this question to define a green-path for this product collaboratively instead of in silo(s). The Now, Next and Later framework To help the team agree on what to do next and to decide the importance of various deliverables, the Now / Next / Later structure has proven its usefulness.\nWhat should we do now? What should we do next? What should we do later? The output of this section is a shared vision of the roll-out plan on the time horizon that makes sense for this product. For instance, the output could look like this one:\nExample of Now, Next, Later view — Illustration by the author\nDo not push for a rapid conclusion of the prioritization effort. Disagreements at this stage could be hiding a more profound difference on the foundational Why?, Who? and What? questions. Reopen the discussion and go back to these critical discussions until you reach a more robust agreement.\nClose the session 10 minutes before the end of the allocated time If you did not have time to answer all the questions, do not rush it!\nUse the last 10 minutes of the session to revisit your precedent findings with a critical eye. If possible, do not change anything: this is the outcome of the meeting, and those are ideas, principles, and words that everyone agreed upon. Revisiting any answer will most certainly require more than 10 minutes and can have a cascading effect on other responses as well. Instead, create a todo list or a specific agenda for the next meeting.\nSchedule another follow-up session to finish the activity. If you need to gather data, validate some hypotheses, read some additional reports or documents assign owners to each task. Ideally, everyone should attend the next session with more context and knowledge.\nConclusion This method generates engagement and high-quality discussions within the cross-functional team. It will help everyone contribute to a structured, safe debate around the key product areas.\nIt starts from a very strategic and abstract level (Why?). At this level, it will reveal any potential ethical and legal issues. It will ultimately create clarity of purpose at the product-team level. As we move toward the more practical aspects (Who?), the team makes critical decisions about who will be served best by our product. Then the product-team looks for abstract artifacts: What to build to achieve the vision for these users. The last question, “How?” allows the team to agree on the next practical actions to execute a shared green-path. Once completed, every team-member can now explain the product, in a very brief form. Participants can now articulate the vision, mission and plan to any other team member, stakeholder, and senior leadership.\nPrecise answers will create a robust framework for prioritization and alignment during the delivery phase of the project and even beyond.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/how-to-run-a-why-who-what-how-alignment-session/","tags":["How-to","Product Manager","Alignment"],"title":"How to Run a Why, Who, What, How Alignment Session"},{"categories":null,"contents":"What is tech debt? Tech debt is a term which uses is very common in the tech and start-up ecosystem. “It is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.” (Wikipedia).\nThe analogy with debt is linked to compounded interests. For instance, with time, a 5% tech debt will compound into a super costly and hard-to-maintain product. In a way, the system becomes more and more brittle, and more and more expensive to maintain and change.\nIn real life In real life, tech debt is quite often a concept that is abused. I will use “tech debt” to identify the abused concepts.\nIn the modern world, “tech debt” tends to be, in essence, like a magic incantation used by engineers to prioritize some work before anything else. It sends the wrong signals to the rest of the team (product, UX, data): “Sorry, you can not understand why, it is too complex, but we have to do it”.\nIs all “tech debt” created equal? In 2020 and beyond, is it true that we can have engineering-only projects that do not create business value? Let’s examine these questions by looking at some real-world “tech debt” abuses.\nThere is nothing unique about tech debt, just change.\n“Tech debt” as a consequence of unfinished sprints In the agile world, we try to build a complex product in multiple iterations. If you have unfinished sprints … you should not start a new one before you finish this sprint!\nThank you old code for all your efforts in sustaining our company for the last 5 years.\nIf you encounter this type of problem on a regular basis, you should stop your current sprint and use any incident/event as a good opportunity to improve your agile process.\nUse recent incidents and problems to do a root-cause analysis and if this is linked to past sprint(s), you have to dig deep with the team and change your definition of one from now on.\nUsers are directly impacted. The value of not doing this project should be easy to materialize and prioritize accordingly.\n“Tech debt” as a changing definition of done For instance, the current page speed load time is five seconds. Today senior leadership decided that the page load speed has to be less than one second.\nIs less than one second even a realistic goal for this page? If the answer is no, engineering should not even try to tackle this project! The engineering-only solution may be super hard and costly to implement, but as a product team, we can do better! Involve UX and product, look for efficiencies and what is causing the page to slow down. Use this to improve your user metrics, prototype and test your improvement ideas! What about the progressive loading of the page? Prioritization of what is loaded according to the user’s interest? How are we going to measure success?\nWith the whole team involved, this project has to be prioritized like any other. It will compete with further improvements to improve your users’ life and create business value.\n“Tech debt” as unfinished business As your product grows both in adoption and usage, it is tempting to call “tech debt” a bunch of technical issues or tickets remaining on the board. These stories/functionalities were not deemed critical enough to ship to the user for the initial release. Like any other UX and product gaps, they should be part of your regular backlog grooming exercises. No special treatment here.\nIt may be tricky to find business value for these issues, but it should be done. For instance, if the main impact of these issues is to improve resiliency, it can be presented as a business impact: fewer support costs and higher availability for the product. If needed, define a new metric, look for the current status of this metric and put it on your KPI dashboard.\nNow you can start evaluating the impact of these issues/stories from a business point of view. Once the business value has been determined, use the prioritization framework your team is comfortable with.\n“Tech debt” as re-architecture projects This one is quite fun. You learned that this particular technology is now end-of-life inside your organization. All teams have to transition by Sept 21st. But rest assured, this is a purely engineering project and it will have no impact whatsoever on the user experience.\nChange is part of life. But don’t be naive. It is extremely rare that any major change inside the architecture will have zero impact on your user experience.\nSome examples:\ndo we need to update the docs: where are the logs? Should we produce a new support doc and retrain all our support staff? Do they need to learn an entirely new system to support our users? Transition: is it a big-bang roll-out, progressive roll-out, what about support for the two systems now? Do we need two sets of docs? Is there a planned outage? Any unit conversion, change in how we represent numbers, units, strings, etc.? Any new encoding that could derail the system? How will we test it beforehand and ensure it is working fine? This should be managed as a complex, high-risk project. It is a high risk for two reasons:\nit is mandated by a top-level executive, it has a hard deadline. Most of the time, for valid business reasons: legal or financial reasons “Tech debt” as unmaintained systems This one is quite common. There is a saying in product management: a product is never complete; we simply stop caring for it.\nFor instance, you discover that in addition to your “regular API,” you also offer a “legacy API” and even “legacy-legacy API. “ Partners and users can access three technological layers with different pricing and functionality!\nUnmaintained systems are problematic. They stopped growing long ago. However, their business value did not decrease with time. Or it did not decrease enough to mandate their disposal: the current users may well be your more valuable customers. Moreover, the organizational knowledge about them tends to disappear as employees move on to other roles, teams or companies.\nThe root causes tend to be one of these:\nThe organization does not celebrate killing products/people are only evaluated based on what they ship. This is a toxic culture that will create, again and again, unmaintained products. Unclear business value for this functionality. Abandoned products tend not to generate enough revenues, or their business value is super hard to quantify. With this in mind, you should assess the business value of current and legacy systems and make decisions regarding killing it, leaving it as-is or investing heavily in it to produce a new version.\nAs a Product Manager, you should aim to kill products at least once a year or every quarter. Make it clear that removing an old functionality is part of the team\u0026rsquo;s success. Make sure it is on the performance report of everyone involved. Help materialize the value of killing old products, old code, old blogs, and old documentation.\nYou should organize a ceremony for this, Marie Kondo style. “Thank you, old code, for all your efforts in sustaining our company for the last five years”. Ensure to thank every active contributor and make it official that it is good to delete code and kill products.\nIf you don’t, you will have to live with the consequences: fewer resources for your products or a difficult situation for your replacement if you move to something else.\nOnce again, this type of tech debt mandates a full-fledged project (killing an old functionality) and, most certainly, two if your organization decides to invest in a new version.\nConclusion While I do not deny the existence of tech debt per se, I don’t think “tech debt” should be used as an engineering incantation to prioritize projects and work in a silo.\nThe software does not change with time. From a technological point of view, running old software becomes more and more costly with time: libraries, OS, language, tooling, dependencies, lost organizational knowledge, etc. However, bytes assembled ten years ago operate identically from the first day they were released to the world!\nOur business environment: team structure, partners, technology, value-chain and customer expectations change. These changes can cause previously created software to be ineffective, unreliable and deliver less value over time.\nThese changes should be managed like any other change within your development process and prioritization framework.\nThere is nothing unique about tech debt: just change.\nThanks Any experience with “tech debt” abuse in your organization? Other typical abuse of the “tech debt” concept? Is tech-debt still a thing with agile methodologies that promote just in time (but reusable) code? Thanks to Nicolas Lupien and Andy Dent for early feedback, ideas and reviewing efforts.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/the-abuse-of-tech-debt/","tags":["Essay","Tech debt"],"title":"The Abuse of Tech Debt"},{"categories":null,"contents":"I Am Not a Writer — Not Even a Native English Speaker How I published 16 articles in 2019 and enjoyed the experience Why then, should I publish an article about writing?\nIn 2019, I relocated from a french speaking Canadian city (Sherbrooke, Quebec) to the national capital (Ottawa, Ontario). I had been working in an English environment since I joined Shopify a few months earlier. With my lead, we identified English communications as an area of improvement. We decided to focus on written communication.\nEven though I have a Ph.D. in physics, I felt a prisoner of my grade 5 grammar and spelling proficiencies. Writing in English was comparable to being an adult in the body of a child — articulated but not able to break the communication barrier. Here is my personal 2019 writer story.\nTo become a writer, you need to press the publish button!\nLearning with deliberate practice I know how I learn. Everybody is different in this regard, but I learn by doing. Practice makes perfect is my personal motto. I made my first writing attempts in early 2019. I started writing content in French. Then, I would translate the articles in English.\nTranslating is not my cup of tea! Illustration by the author.\nIt was painful and slow. While translating, I struggled with the order of words and especially verbs. The end-result never felt like natural English and not even like flowing English.\nWorse, I did not feel like a writer at all but more like an incompetent translator. I was actively creating problems for myself! My goal was to learn how to write, not how to translate.\nWhat has proven helpful for me was the habit of deciding the day before, the subject of tomorrow’s writing session.\nLife is change: focus and prioritization Based on these new learnings, I switched to writing in English.\nUpdated process: more fun but not so great either! Illustration by the author.\nI also had a pet project — I operated my own Linux and Wordpress server. I stopped these activities when I decided to switch to Medium. This gave me more time. With these choices, I was able to get back a few hours a week to write more.\nHabits, Ideas and Tools Even when doing my poor translation tasks, I kept the habit of writing regularly: daily to be precise. My daily routine did not change: waking up early, meditating and writing. My daily writing time went from ten minutes at the beginning of the year to close to one hour these days.\nI don’t have a specific format for my daily writing practice. It can be quick notes, ideas or even longer stories. However, I don’t like starting with a blank page or an empty mental space. What has proven helpful for me was the habit of deciding the day before, the subject of tomorrow’s writing session. Having a self-imposed subject is giving me space to find ideas, experiences, pick-up cues from my environment and even, sometimes, dream about it. With time, I wrote about various subjects: science-fiction, how-to, product management or personal well-being.\nI have found two useful apps to help simplify my English and also improve its overall quality. My goal was not to develop my style but to learn how to stop making the most basic grammatical and syntactical errors. I found two apps that I love: Hemingway (macOS only) and later this year Grammarly (semi cross-platform: in-browser editor).\nBoth of these apps were tremendously helpful. They allowed me to learn English grammar as I practiced. Grammarly premium explains the rules, proposes synonyms and helped correct my worse defects.\nI also started to write on the iPad and discovered various creative programs. I added some visual schema to my writer toolbox — mainly to illustrate half-baked articles in French or English. Learning along the way and always trying to increase my own understanding as well as my reader’s one. Schema helps me to understand and explain better. Lots of the schema and illustrations I created are not published: they are simply part of my research.\nFor the longer pieces, not a single word remained of the original!\nEditing is a thing! I rarely edited my drafts before publishing my content. I naively believed I was clear. In fact, I was not really reading what I had written but simply confirming the bias of my own ideas and mental models! And truth be said, with all the research and activities … they were quite clear but only for a single reader: me.\nUpdated process: lots of space to edit the texts and only keep what makes a good story! Illustration by the author.\nI introduced the sleep on it rule. I never publish anything the first day and I wait at least 2 days before re-reading and editing any article. I do this only when I am pleased with the content and the article structure. For the longer pieces, not a single word remained of the original!\nDon’t get me wrong: I am not an expert, and at this point in time, I am not even a write. I was discovering a process that works for me:\nGenerate ideas / outlines / schemas Wait at least two days Edit it: remove all superfluous words and sections. Make it interesting and easy to read + understand for your audience Hit the publish button I published some loosely connected articles on my own publications. I wanted to learn how Medium worked in order to get some experience with the publishing tools (revisions, comments, TK, medium+grammarly, etc.). I also wanted to get comfortable with the publish button.\nAs you can imagine, besides my friends and family, I only had a few readers. Even today, I don’t have any goals in terms of audience, views and read. Some subjects are very technical and affect a smaller audience while others are shared by all humans. Each time I publish an article, I have to fight my own fears, uncertainties and doubt. This became my mantra: To become a writer, you need to press the publish button!\nI am truly humbled by how many hours readers have spent on my imperfect work.\nMake it personal The first articles were, if not dull, let’s say barely readable. They remained at a high abstraction level and were not really based on my personal experience. I was hiding behind other people’s thoughts, books and ideas.\nI have been a long-time meditation and Buddhist practitioner. As I collected years and grey hairs, I was also busy collecting tools and mental models, which helped me be a more fulfilled, calmer and, in general, happier person. I decided to focus on these experiences and did a semi-long form essay (6000 words initially, stripped down to its 2500 words in its final form) and submitted it to a publication I respect and love: Better Human.\nI was humbled when I received the answer: yes, this is an exciting subject. Better Human wanted to publish it! I signed the contract, barely believing I could call myself a writer.\nReinforce your writing skills: extra practice at work Soon after this great news, at work, I had an opportunity to contribute to a new section of our documentation. A few months ago, I would have politely declined, knowing very well that my English was limited and not good enough for prime time. However, given my recent experiences, as a writer, I decided to practice and contribute. My short piece was, of course, heavily edited but then published (importance of processing time for Shopify merchants).\nI was able to apply all my learnings from the year and use them in a completely different setup. I was writing for a completely different audience, using a completely different toolset and writing style. But the process remained identical: write and edit daily, savagely edit until I was happy with the result and then propose it for publication. I was then fortunate to work closely with a wonderful illustrator as well as the editor. Even if writing is a solitary effort it is also a team sport.\nBeing rejected is good for you I also was rejected for a few publications. I did not take it personally. It forced me to reconsider the ideas, article and structure of the story.\nThese days I am busy splitting one long piece I had written that was rejected into multiple independent stories so that I can submit again.\nPractice makes perfect!\nConclusion From a writing point of view, 2019 was a blast. I went full circle: from deciding to learn a new skill to being able to make a difference. This journey was challenging, interesting and fulfilling.\nToday, I understand better what the creative process is for any written content. I enjoy each step of the process. This is now part of my daily routine like meditating, physical activity and brushing my teeth.\nSeeing 2020 For 2020, I want to continue my deliberate practice by improving in three particular areas:\nBe more personal: tackle more personal subjects (like this article!) Write actionable and immediately useful (in opposition to new ideas, framework and hard to use written material) Experiment with long content. I am quite scared of this one: this is a process I know nothing about but I am eager to try. My experiences this year also highlighted the importance of editing my stories to affect more readers. I need more practice and also to experiment more to find my own voice.\nI am truly humbled by how many hours readers have spent on my imperfect work.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/i-am-not-a-writer-not-even-a-native-english-speaker/","tags":["Essay"],"title":"I Am Not a Writer — Not Even a Native English Speaker"},{"categories":null,"contents":"Emotional Intelligence When I came back from work, frustrated and demotivated by a recent reorg in my organization, my wife sensed my disarray. As usual, she listened actively to my rambles. Then she kindly suggested that I should go for a run. And I did.\nI exercise daily and have competed in a few ultra-marathons, many marathons, some trail races, and a few Ironman triathlons. For me, running/biking/swimming is critical to a balanced life. Yes, physical activity is good on its own: it provides well-documented physical and mental health benefits.\nBut these benefits are not what makes me happier after a run. Not on this particular day, anyway.\nDuring this run, I realized that I was, in fact, actively reframing the events that happened to me. With nothing to do but listen to my laboured breath, my mind was free to reimagine the events of the day.\nReframing is a way to revisit your memories (events, ideas, concepts, emotions, feelings) to frame these events in one or multiple alternative ways.\nQuite often, reframing happens automatically. If you are in a negative mood (stressed, sad, disheartened, etc.), it will make the situation worse. You can even be carried away in a full drama, Hollywood-movie style. You are now the hero (or the villain!) of a blockbuster, where all the characters are alternate versions of yourself, your coworkers, and the world. It can play out in your mind with dialogue (sometimes with yourself!), music and all.\nThis day, however, I realized that I could regain some control of this process:\nBy becoming aware that I was reframing the situation, and By applying a new mental model to the situation. I purposely used a mental model of my choosing instead of letting my emotions create an uncontrolled wild drama scenario. I have experienced this technique and used it thousands of times.\nThis type of mental model and how to apply it to its own life experience is part of what is now emerging as the field of cognitive behavioural therapy (CBT). Broadly speaking, the goal of CBT is to change certain mental pathways that cause mental health issues or unhappiness in relation to yourself, others, and the future.\nHow mental models interact with your views of the world. All illustrations by the author.\nThis active engagement of your left brain (the analytical brain) lowers the engagement of your right brain (feelings, visualization, etc.) and allows you to successfully stop the downward spiral.\nThe model I used is generic and can be applied to any situation. It is the zone of concern/zone of control mental model. This model is super simple. It states that you can only be happy if your zone of concern overlaps exactly your zone of control.\nFor example, consider guilt. Guilt is not an intrinsically bad feeling — but imagine feeling guilt on events and actions that you have no control over! It would create a personal hell.\nWhen you are submerged by negative emotions, you clearly feel overwhelmed by the events and your control zone is quite small.\nUsing the Zone of Concern/Zone of Control to Reframe Negative Feelings Here’s how to begin reframing your own experiences using the zone of concern/zone of control model.\nStep1: Identify your negative emotions, especially guilt/sadness Even if it’s unpleasant, identify the negative feelings. Be on the lookout, especially, for guilt. You will often feel it in your gut and lower abdomen. Use this negative feeling as a starting point to identify all the feelings linked to the difficult situation you are working on.\nAt first, it could be helpful to use questions like these: what did you do (or not do) that created this situation? What makes you feel responsible for what happened? Do you feel responsible for your acts only? For your co-workers? for your manager?\nYou are labeling these people, situations, events, things, fears, feelings, and animals as part of your personal and unique area of concern. You care for these people/animals/objects/ideas/things! You now have made huge progress because you can now name what concerns you. This is not a fluffy and negative feeling anymore, but an actionable list of items.\nStep 2: What is your control zone? Now that you have clarified the area of concern, it is time to consider your area of control. For this situation, what was under your control? What did you do (or not do) that contributed to the situation? Identify what was actually your responsibility in the chain of events that triggered the situation (or situations) that impacted you negatively.\nThis type of inquiry is generally easier because we are used to various root-cause analysis methods, and this is also part of the scientific method that tends to be taught broadly.\nThis phase relies on imagination, too (right brain now!) — you naturally consider an alternate version of yourself that took different actions to avoid the painful or difficult situation you are experiencing. By thinking about yourself and your past action, speech, and thoughts, you will be focusing on what you can control.\nFor instance, in the reorganization event, I replayed some leadership meetings and quickly came up with a list of things I could have said or done differently. Each of these actions was within my control zone.\nStep3: Take a step back and look at the bigger picture Now that you have defined your zone of concern and your zone of control, it is time to work on how these two areas relate.\nRemember, in this model, if you cannot match the two zones, you will experience unhappiness. On the contrary, if you can match them perfectly you will have a happy life.\nThis is like a mind game where you have to use all your analytics and creative skills to clearly define what is out of your control, what is in your control zone, and what you feel is your responsibility or your fault.\nBecause this chain of events is in the past, you can not alter it. You can only think about it differently. Now is the time to reframe. You can do this in one of two ways:\nScale down your concern zone Scale up your control zone If you could scale down your zone of concern and scale up your zone of control, you can get rid of most of your negative emotions and start growing.\nHow can you scale down your concern zone? Let’s start with the area of responsibility. Each human has a unique view of the world. For me, being a physicist, I like to start with the hyper-scale of the universe. We all are stardust. Our bodies are made of a few atoms, linked together via a super tenuous atomic and electromagnetic energy field. In a blip, these atoms could be dispersed, and we would stop being aware of this wonderful universe.\nThis does the trick all the time: how can I be responsible for all this? Whatever the situation (including terrible news like death and terminal illnesses), this type of reasoning scales down my zone of responsibility.\nI do not recommend that you use this technique if it does not resonate with you. Look inside yourself for your own model and answers to the mystery of life and of the universe. Use your own words and experience. It will simply not work if you use somebody else’s thoughts and words: you have to make them your own and be deeply convinced by it. The goal is to be able to replay this movie, in your mind, on a snap.\nThis does not soften the sadness or empathy I feel for others or for my personal suffering. On the contrary, it makes it more defined and, as a consequence, more acute.\nYou may have to find other ways to scale down your zone of concern. For example, another way to do this would be by deciding that you can’t concern yourself with how other people feel about the situation.\nHow can you scale up your control zone? I have been meditating daily for more than 20 years now, and I am actively seeking freedom from the ego. Like lots of aspiring sages before me (stoicists, Buddhists, philosophers, priests, etc.), I am convinced that the ego is the enemy. In order to exist, the ego has to exercise control. Each time I want to exercise my power or my authority, this is because of my own insecurities and this uncatchable ego. With time, it is possible to associate any wish for control as a simple and common manifestation of your ego.\nIn fact, I find that the only thing I can actually control is my thoughts (feel free to challenge this!). For instance, I have some control over how I define what is important, just, terrible, funny, sad, or stressful. All these emotions and thoughts are simply appearing in my consciousness. They will, at some point, recede and disappear.\nThis is a spiritual matter that humanity has been exploring since the early days of our social evolution. Use your own view of the world, not mine. Use your view of what you control to go deeper and to frame your view of the situation.\nAsk yourself what is actually in your control. Can you expand that circle by doing something differently, or by thinking about it differently?\nAlternate between control and concern For tough issues, you can alternate between these two views of concern and control. Sometimes you have lots of concerns and you discover some root causes deep within your childhood or in past trauma. You will definitely need to do deeper work, perhaps with a therapist, to reframe those events in a way that allows for more happiness.\nAt each cycle, reframe your concerns based on the control you really have. As you better understand the control you really have, reframe the concerns. This is the reframing process that will make you happier.\nOne more thing… Reframing is not the end of the process. Your negative emotions and life experiences do not necessarily subside and magically disappear. This will not cure your anxiety and negative emotions that you will experience during your life. You will also need to take action as you step forward in your life.\nThis is especially true if you feel that you did not think, speak, or act truthfully or according to your own standards in the situation. It may also manifest strongly when learning about or supporting some friend or family member terminally ill. You may continue to bear a heavy burden.\nUse the negative feelings to help you commit to changing into the better version of you that you want to be. Work exclusively on what you control and relinquish the illusion of control that caused all this suffering. Be 100% present with the people you love and admire. For more mundane matters, keep control of your emotions and temper during each interaction with fellow living beings.\nLife will throw new challenges at you. By applying this mental model regularly, you will be able to remain satisfied with what you have and then use them to grow and become a better version of yourself.\nUse this incredible experience that is life as a learning opportunity to change and grow as a human being.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/how-reframing-negative-experiences-can-make-you-happier/","tags":["Psychology","How-to","Optimist"],"title":"How Reframing Negative Experiences Can Make You Happier"},{"categories":null,"contents":"From product to platform: a PM journey Context As a former technical founder, CEO and CTO interacting mainly with B2B and mature technological stacks, I did not focus my time and energy on GraphQL.\nI had lots of experience designing and integrating with REST API and always had no experience with GraphQL beside a REACT tutorial and then techno-drink I attended. It was early GraphQL days, the tooling was not mature, and the examples I did were not able to convey why this Facebook invented technology was so great.\nExample REST APIs working “together” Example in REST: multiple queries to get a simple answer\nIrreversible decision From a PM point of view, your product/platform API protocol (GraphQL or REST) is an archetypal irreversible decision (Type I decision in Besos mental model). This decision has a substantial short-term (development), medium-term (support cost) and long-term (value creation by the platform partners) impact.\nIt was healthy to examine alternatives and spend some time to gather information and agree on this decision.\nIn this short blog, I do not intend to detail the differences between REST and GraphQL. I will focus on a single element that is extremely useful for platforms and their partner ecosystem (see the from product to platform series)\nThrive on change: GraphQL at Shopify Shopify decided to adopt GraphQL way before I joined. However, at Shopify, the product teams are not simple delivery teams. Each team is empowered to make its own decision based on its product context. So even with a strong GraphQL direction, we met with the platform team and considered the possibility to ship a REST API mainly because we were replacing a read-only REST API by a newer and expended version.\nLearning GraphQL While I do not have an engineering role, I am an engineer by trade with a Ph. D. physics \u0026amp; postdoc in high-performance computing. I believe that PMs are making better decisions when they understand the underlying technologies’ principles. Then PMs can speak the language of the engineers. And the same is true for UXers, data scientists, C-Level: this is the T-shape skillsets of product management.\nI followed some tutorials and was able to rapidly grasp the power of GraphQL as well as the significant design differences with REST API.\nI sat down with engineers, with a developer advocate from the platform team. I started to collect GraphQL queries and mutations. Then GraphiQL became for a while my best friend: a Web IDE for GraphQL queries with autocompletion and all.\nI did not go very deep (as is often the case with PM!) but enough to be able to test our product development, run some queries and mutations and also interact with other areas of the Shopify platform.\nPlatforms + GraphQL = Super Power After talking with a partner who was doing multiple REST calls to multiple Shopify endpoints. I realized that with GraphQL, this partner could make a single GraphQL query!\nThe light went on: my awakening to GraphQL schema stitching superpower!\nGraphQL Superpower: Schema Stitching I believe this is one of the main drivers for GraphQL adoption: GraphQL schema stitching delivers incredible value to partners. Multiple teams can grow several API sections, and GraphQL will magically unify them.\nOne API call to rule them allA customizable payload to returnPaginated, containing only the expected valuesTo, in the land of GraphQL, bind them\nAs a platform grows in scale and capabilities, REST becomes incredibly costly and hard to understand, scale, maintain and … use. The main reason is that each team is shipping its API without a strong consideration for what all the other groups are doing. Concepts within various teams in charge of multiple parts of the API become slowly but surely misaligned and more and more complex as the platform scale. API versioning is also more complicated and not breaking apps become an art much more than a science.\nGraphQL example\nSchema for multiple the same query as the REST example above : more elegant, less bandwidth used and … easier to understand!\nConsidered scenarios and impact of each of them Because this technology helps both the product teams and the partner community, partners create more value faster. It is also cheaper to implement and maintain at scale. GraphQL has become a vital component of the platform flywheel and growth: as partners learn about it and transition their apps because of the GraphQL benefits.\nAs the quality and scope of the GraphQL API expand, partners can quickly improve their apps. It lowers the cost for partners to explore all the platform capabilities and allow them to retrieve only the required information (more efficient, faster and more scalable).\nLong live GraphQL.\nNote: schema stitching is dead! it has been replaced with “federations”. Don\u0026rsquo;t worry: same concept and even more flexibility to organize and adopt a micro-service architecture!\nMany thanks to Nicolas Lupien for early feedback and fact checking ;-)\nSelf-reflection What do you dislike about GraphQL? Do you use GraphQL for your product / platform. Why and … why not ? Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/one-ring-to-stitch-them-all-and-in-the-land-of-api-bind-them/","tags":["Essay","GraphQL","API"],"title":"One Ring to Stitch Them All and in the Land of API Bind Them"},{"categories":null,"contents":"The MoSCoW method is a prioritization framework.\nIt consists of four quadrants:\nMust-Have Should-Have Could-Have Won’t-have These four quadrants classify requirements:\nMust-Have: Those are required for the release to have the expected outcome. I often use the skeleton analogy of our bodies. Everything in this quadrant has proven value or is a vital element of the new product or feature. These requirements are also pre-requisite of others. We need to develop them first. MUST is also an acronym for Minimal Usable SubseT. Think also Minimally Viable Product (MVP). Should-Have: Those are requirements that will have an impact on the new product/feature, but the product/feature can work without them. If you work in cycles, they can be part of the next cycle. You can start building these requirements once the Must-Haves are complete if times and resources permit it. They may have less clear value or depend on some Must-have. Could-Have: These requirements are desirable. They will most certainly improve the product/feature but are not essential. Sometimes their value is not clear; sometimes we need more information: data, user feedback or user-research Won’t-Have: Those are requirements you will not do for this product/feature for this cycle. Use this quadrant to define what the team has agreed not to do for this release. It is beneficial to document these agreements. Focus on the current cycle: aways changing the future is! How to run a prioritization session with MoSCoW The prerequisites are:\na team a strong why a product vision / shared problem space definition a product-brief If possible, a press-release (1-page max) to share with everyone what success looks like for this iteration. If you are missing some of these critical elements, the risk is that the prioritization could be highly inefficient. While building this shared understanding (and producing the documents above), you should pre-fill the MoSCoW grid with what the team has already discussed. This\nI used a simple visual code for each item in the grid:\nTodo (agreed upon by the team and in the Must-Have quadrant) Team is aligned and this requirement is in the correct quadrant ? To be discussed (not agreed upon but captured during discussions or any social interaction) 🐽 Team disagreement / May need further discussions or stakeholder input ☑️ Done — This requirement has shipped You can make your own or use the empty MoSCoW template and pre-fill it to the best of your knowledge.\nInvite the team Once you have done that, you are ready to invite the team to the session. If this is the first time you are using MoSCoW with this team, you can send the link to the Wikipedia article (or this blog post ;-).\nMake sure to attach the MoSCoW matrix or share it in your favorite team communication tool before the meeting.\nThe meeting Make everyone comfortable. Explain the process and why the team is in the room. Ask questions about MoSCoW and make sure to clarify the definitions. Make sure to specify the time-scope of the exercise: the next release. I also like to mention that nothing is permanent and that we can change these decisions at any time.\nThe value of the MoSCoW method comes from the super-interesting discussions it will generate. The talks are a forcing function to create team alignment rapidly. You will also identify the points of misalignment/indecision. These points will be visually easy to spot on the MoSCoW matrix with the proposed pig noses (🐽) symbols.\nDepending on your current alignment, you can experiment with three types of meetings. I will propose two structured approaches and one unstructured approach that is more like a free-form conversation.\nIn my experience, the first few times I used the framework, I used a structured approach. These days, I tend to use a free-form approach, merely making sure we spend some time on each segment. Feel free to experiment with these approaches.\nWeak alignment:You should start from the less absolute quadrants. Namely the could-have and should-have.\nThe proposed path will help the team to build their prioritization muscle.\nThe proposed path is illustrated on the left.\nCould-Have: try to move things from this quadrant to won’t-have or should-have quadrant. Should-have: idem but move requirements to the must-have / could-have quadrant. Must-have: It is OK to spend time on this quadrant and have a deep discussion. Make sure you capture all the requirements that will not be built for this release. This one is often easier. {{ }}\nAlready a strong alignment. If you already have a strong alignment the Must-Have and Won’t-Have quadrants should be well defined. Start with the already agreed upon points.\nMust-Have: Start from there as the team alignment is built in this quadrant. Do not leave any requirement undiscussed but focus on the one with ? and 🐽. Build alignment on these or move them to another quadrant. Won’t have: Should also be quite clear and fast. Don’t hesitate to move things around and clarify Should-have: This is where you should spend most of the team time. Lots of interesting discussions to have. Discussions will mostly be around the should-have vs could-have requirements. Could-have: If you have time, otherwise, you can move to the conclusion. Free-form discussion In this type of workshop, the flow is free. You can still use some form of prioritization: quadrant by quadrant.\nYou can prioritize based on the various requirement importance: start from the most pressing issues that the team has.\nAnother possibility is to go in turn. Each attendee picks one requirement they think is in the wrong quadrant, one in the right quadrant and one missing requirement. The last method guarantees the fair participation of everyone and is very remote-friendly.\nThe tricky thing is to make sure the team is spending enough time on each quadrant.\nTip: use the MoSCoW quadrant forcing functions When a discussion derails, and we start bikeshedding or making plans to go to Mars, keep everyone focused on the goal/quadrants. You can use one of the following questions are a forcing function to make a decision and move to another subject:\nShould we change this requirement from Must-Have to Should-Have? Should we add a new requirement to capture this discussion? In which quadrant? I think we disagree, let’s use a 🐽 for now, and move to the next quadrant/requirement/person. We will come back to it later. 10 minutes before the end: the quadrant walk-through Revisit the Won’t-Have quadrant Make sure to revisit the won’t-have quadrant. Lots of time, we moved things around, and we may have added new requirements. This white-space thinking is super-useful to define what we don’t want to build.\nFor instance, in one of the sessions, we had a generic no buyer facing interface requirement. During the discussion, we discovered that we now have a specific buyer facing element in our should-have quadrant. As a consequence, we changed the won’t have one to a more accurate no buyer facing interface — pre-checkout in the won’t have.\nIt is super-important to do that otherwise you will end up with some contradictory document and misaligned team.\nFocus on the Must-Have This quadrant represents the core of the product. Use leading questions like:\nAre we ready (even if uncomfortable!) to sacrifice everything else to develop these requirements? When all these requirements will be built, can we launch our product? Is everything in the Must-Have column necessary? These questions will generate interesting alignment discussions: some requirements will move to Should-have and some Should-have to Won’t-have.\nThe conclusion of the meeting is not a time for discussion: if the team disagree, use the pig nose symbol (🐽) and move forward to the next requirement.\nThe must-have quadrant should now be quite robust, as well as the won’t have quadrant.\nIf you are short in time, stop there and move to the conclusion of the meeting.\n2 Minutes before the end: Conclude / Wrap-it up. At this point, you will most certainly navigate between these two scenarios:\nAlignment not built yet. Some team disagreement (🐽) in the Must-Have and Won’t-Have quadrants are a manifestation of misalignment. Make sure you have follow-up action-items assigned to team members for which these requirements are essential. You can go 1:1 for these or use another session.\nStrong alignment on essential things: If you don’t have any disagreement in the Must-Have and Won’t-Have quadrants, congratulation! You have now a well-aligned team and a document ready to share.\nIt is perfectly OK to have some disagreements (🐽) in the Should-Have or Could-Have quadrants. Those are good candidates for some data-deep dive, user research or UX explorations. Try to find motivated team members to help the team understand better these requirements.\nConclusion The MoSCoW matrix is super simple but quite powerful to generate valuable team-level discussion. The framework will guide your team discussions toward an agreed-upon prioritized requirement list.\nAfter a few meetings (or one-on-one with key team members), you will reach alignment within your team. Congratulations!\nYou can now share the MoSCoW prioritized requirement list with your stakeholders. Use one of the methods exposed above when you discuss prioritization with your stakeholders:\nBe open to new requirements: add them in any section with a “?” so that you can analyze this scope change with the team; If some stakeholder disagree, use the (🐽) This document is a live document: it should not remain untouched for months in a row. Every cycle, you should be able to mark things done (☑️), and once the Must-Have quadrant is completed: you can release your new product!\nWhen you have almost completed all the requirements in your Must-have quadrant, you can then start a new cycle with the Should-Have as a good starting list for the must-have quadrant. You can then organize your next MoSCoW prioritization team session!\nQuestions: Have you used this method before? Any tip to share with the audience?\nDo you use another framework, how does it compare/relate to the MoSCoW one to build team and stakeholder alignment?\nReferences: MoSCoW template Wikipedia article on the MoSCoW prioritization method Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/how-to-run-a-prioritization-session-using-the-moscow-framework/","tags":["How-to","Product Manager","Prioritization"],"title":"How to run a prioritization session using the MosCOW framework"},{"categories":null,"contents":"Wine clubs are part of the Direct to Consumer (DtC) trend. They allow the winemaker to send large amounts of wine to a selected wine-lover group that has agreed to put their name on a contract. The larger the club, the larger the revenue stream. Even better, most of the wine club shipments are already paid for!\nWine clubs offer great benefits for wineries. Better cash flow, direct contact with customers and no financial dependence on wholesalers. Please see our article on the value chain in the wine industry for more details on these benefits.\nWhile simplicity is a great concept, operating just one single wine club is not very practical:\nCustomers who love your winery and are ready to sign up have different tastes and preferences. Some prefer whites or rosés, other sparkling wines or strong reds.\nCustomers also have different budgets. You should, therefore, have different wine clubs that require different levels of commitment.\nMailing List is a good source of additional revenue. A “non-commitment” club is similar to a mailing list in that it allows you to send periodic promotions as you see fit. This is an unfrightening way to engage one-time visitors and customers.\nYou should take care of your “rock stars”. Some members will go above and beyond and become your best brand advocates. Offering them a membership to an exclusive on-invitation-only could be a great way to reward them and cement your friendship.\nDemographics are also a big differentiator. As alcoholic beverage producers, wineries must observe the minimum legal age requirement to sell their products. In analyzing the demographics of your members, you will see different patterns. Younger generations expect more flexibility and more interactions. Older members are generally happy to receive a box of your wine every six months.\nExclusive events. Some members will be delighted to receive invitations to exclusive events. But others (who live far away) will be annoyed since they cannot attend. They will not view your invitations as something valuable to them.\nAll in all, because your brand is unique, you should create a unique wine club structure that caters to different tastes, budgets, age groups and locales.\nTo connect with your best possible supporters, and your members, you should operate various wine clubs tailored to your customer needs.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/why-should-you-operate-more-than-one-wine-club/","tags":["Wine","DTC","Wine Club"],"title":"Why should you operate more than one wine club?"},{"categories":null,"contents":"Summary of lessons learned in the land of platforms Complete series: This post is the fifth part in a series of five regarding platforms and the critical differences with products:\nPlatform Product Manager: Partner (1/5) Platform Product Manager: Complexity (2/5) Platform Product Manager: Mental Models (3/5) Platform Product Manager: Revolution and Evolution (4/5) In this post, I uses PM as an acronym for a regular PM role and PPM for a “platform product manager” role.\nCritical differences between product and platform The platform \u0026amp; partners form an ecosystem centered around value creation for the platform users. By definition, on aggregate, the platform derives less value than the partners.\nValue creation represented as compounded interest for a user with three different apps.\nApp and platform functionalities create incremental value and this effect compound with time.\nThis derived value is connected to the partners’ knowledge: on aggregate, partners have a superset of the platform knowledge.\nPartners are diverse. Each of them provides distinct value to the ecosystem: training, support, consulting, developer. The partners most impacted by the platform changes are the ones relying on the API and extending the platform capabilities.\nPartners form a community that requires caring and frequent interactions with the platform teams. The platform teams and partners co-create to increase the global value derived by the partners and the platform.\nFor developers, the main interactions between partners and the platform happen via an API that has to be managed by the platform, including legal, financial, GDPR and other regulations.\nIterative evolution happens all the time and is used to evolve the boundaries between core platform functionality and partners slowly.\nMost of the time, the value distribution between the partner and the platform community changes gently with time. Each new API release allows partners to unlock incremental value for their users.\nHowever, sometimes, a tectonic shift occurs. These shifts happen when some functionality previously offered exclusively by partners is integrated into the platform.\nPlatform tectonic shifts prevent some previous partners from extracting any future value from the platform ecosystem. Earlier partner+platform teams are split apart and will now compete directly for market share and value creation.\nThese tectonic shifts are rare and caused by wrong strategic decisions by the platform over a few years or by a critical business or financial change. Because these shifts cause a loss of trust in the partner ecosystem, platforms tend to avoid them as much as possible.\nA platform will always prioritize its user needs before the partner needs it. The overarching goal is value creation and to continue to play the infinite platform game.\nProduct Managers listen to the voice of the customer.Platform Managers listen to the voice of the developer as well.\nPlatforms have to focus on the bigger picture and strategic growth. It is the main flywheel responsible for platform success. The Pareto principle can guide the platform to decide which feature is core and which one should be part of the partner value creation chain.\nFor any decision, always use multiple mental models and make sure to consider usability, feasibility, and viability.\nConclusion At a human experience level, I don’t believe that being a PM or PPM makes any difference. One is not intrinsically more fulfilling than the other. They both have their own set of challenges.\nYou can not win the human existence by defining a metric or by having or not a job title. If you believe this, please review the finite vs infinite game mental models ;-)\nIn one of the mental models used to describe platform and products, we used the single organism vs ecosystem analogy. In this analogy, a PM is more like a veterinarian or physician taking care of a single individual.\nIf we continue this analogy, a PPM is like a gardener providing heat, humidify, nutrient to a complex partner ecosystem of plants and animals. Most of the time, the ecosystem evolve slowly with each season; the gardener better understands the ecosystem and make a better decision regarding the various plants and animals living in the ecosystem. Once in a while, natural disaster strikes. These tectonic shifts are destroying part of the ecosystem or creating a fault line between some constituents of the ecosystem.\nWhile PMs have a direct and immediate influence on their product, PPM exercise an indirect impact. PPM receive delayed feedback on the changes they operate, and they tend to operate via small, incremental changes to maintain trust within their partner ecosystem.\nFrom a personal growth angle, I believe that the PPM role will help you grow faster. The leading cause is the intrinsic complexity of the platform. As a PPM, you will have to interact with more stakeholders both inside your organization (other teams, app store, API team, finance, etc.) and outside of the organization (partners). These interactions will give you even more opportunities to develop meaningful, real and robust human to human interactions with lots of super-smart, tech, and business savvy entrepreneurs. It will also encourage the development of system-based thinking: each of your decision will impact systems loosely connected to your platform area.\nInteracting with these fellow entrepreneurs can be super fulfilling, and it will provide lots of insight about your customers if you can tap into this superset of knowledge. Partners are outside of your organization. You can also expect real-life and non-biased feedback on your organization practices, values, product and, of course, API and business model.\nThis feedback will correlate, or not, with the kool-aid that one tends to drink when having feedback loops provided exclusively by co-workers and management.\nAs a PPM, you will be in a unique position to bridge the gap between these two versions of reality and improve the ecosystem.\nComplete series: Platform Product Manager: Partner (1/5) Platform Product Manager: Complexity (2/5) Platform Product Manager: Mental Models (3/5) Platform Product Manager: Revolution and Evolution (4/5) Platform Product Manager: Conclusion (5/5) Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/from-product-to-platform-conclusion-5-5/","tags":["Product Manager","Platform"],"title":"From Product to Platform — Conclusion (5/5)"},{"categories":null,"contents":"Retrospective help teams realize their impact and grow. Last week we held a team retrospective for a massive 18 months project that we shipped to 1 Million merchants. Our team retrospective was a unique opportunity to reflect on the shared journey we experienced as well as revisit our processes, rituals, and tools. The main goal of the retrospective is to continue our team growth, and work better with each other. These changes will help us create more value faster.\nMake sure the key contributors can attend Ensure the key contributors can attend the event. This is especially important for long projects with many team changes. This activity\u0026rsquo;s main benefit is to create a shared context.\nBe remote-friendly If part of the team or the complete team is remote, use a virtual board tool like Miro, Google Draw, or Lucid Chart. Use the tool you regularly use to avoid technical glitches and delays.\nFind a moderator who was not part of the project. In an ideal world, the moderator should not be part of the project team. One of the goals of the moderator is to help the team self-reflect. A non-biased moderator will ensure everyone can express themselves and discern communication and trust issues more easily.\nIdeally, the moderator should have some context on the project. This context can be gathered beforehand with some 1:1 interviews with individual contributors.\nScribe/Notetaker Have someone responsible for taking notes. While you will have pictures or a virtual board with all the content, many exciting discussions will happen. The goal of the scribe is to capture the essence of these interactions.\nPrepare a timeline For long projects, prepare a timeline of the main events, including team member movements, role and scope changes (pivot?), significant decisions, major drawbacks, and key release dates. The timeline recreates an unbiased and shared bird’s eye view of the project. It will help everyone remember the challenges and, more generally, what happened during the project. Share it beforehand and bring a few written copies to the retrospective.\nTimebox it Block the required amount of time based on the project size and complexity. You should plan at least 20 minutes/question, up to 30 minutes. Err toward 30 minutes, especially for a large team project.\nPhoto by Burst\nHere are some traditional questions: What went well? What went poorly / not so well? What actions will the team take to improve? Be flexible: some questions may be more critical than others. Listen to the team and change the duration of the points to help go as deep as the teams feel comfortable doing.\nSelect a question and write post-its notes. Some of us are introverts. Make sure you solicit everyone in writing before discussing any points. You can use physical and virtual post-its. For large teams, limit the number of post-its to 2–3 per person (for a 20-person team -\u0026gt; 40–60 post-its).\nClustering Once you have everyone’s contribution, write down the virtual Post-it on a physical Post-it or use the virtual board.\nThe moderator will then cluster the various post-its into themes. Excellent opportunity for a short break ;-)\nEach topic will be named based on the content of the multiple post-its, for instance, team trust, resource allocation, etc.\nUse the number of post-its of each theme as a vote. Spend more time on the items with lots of Post-its. This way, you can respect the duration of each phase and still manage to discuss the most central theme. Because of the prioritization process and time-boxing, you may not have enough time to discuss some topics.\nTalk The moderator selects a theme (the one not yet discussed with the most post-its). He asks for contributions from the team: can someone explain and give more detail about this theme. A good discussion can occur: an example of what happened, more precision, and how the team member felt about it. Root cause analysis is a great principle: try to discriminate consequences from causes. Use the five whys technique to help the team reach a meaningful understanding.\nThe moderator will try to draw an agreed-upon conclusion from the team exchanges. At any point during the discussion, merging a theme with another one is possible. For instance, the link between the subject can also emerge as a causation link.\nChange the question and repeat. You can follow this process for these two questions\nWhat went well? What went poorly/not so well? The third and last question What actions will the team take to improve? You can use the same technique (write on Post-it, cluster) if there is no strong consensus about what went poorly.\nHowever, more often than not, problematic areas will emerge. The moderator can then help the group reach focus on these difficult areas. Her/his goal is to focus the team on what everybody agrees were the top problems and explore solutions and then decide on follow-up actions.\nConclusion Use the meeting\u0026rsquo;s last 5–10 minutes to summarize the successes, significant issues, and improvement plan. Make sure you solicit everyone’s feedback.\nNow is the time if you have a team ritual to end your meetings.\nOur team ritual was to end our meetings with this one:\nTo shipping … and beyond.\nSend a summary Make sure all the participants receive an overview of the activity. The moderator and the notetaker will prepare this document. It will help everyone align and commit to the actions and changes discussed during the last phase of the activity.\nOne more thing Of course, if the agreed-upon actions remain post-it notes on a physical or virtual board, the retrospective will not impact your team\u0026rsquo;s growth. Like any issue on the board, some team members must take ownership and change processes, rituals, and tools. The team has to be comfortable to unlearn certain things and learn new things.\nRetrospectives are the fuel for your team growth engine.\nIn a way, the retrospective is only the beginning of a transformative process for the team. Do not confuse the retrospective with the team transformation.\nConclusion Retrospectives are an essential agile ritual. Retrospectives offer quiet self-reflection time for the team. It can be super-powerful to:\nrealize all the good things that the team has shared, learned and shipped; recognize the team’s culture, rituals, and values; carve-up changes that the team wants to pursue to improve to have more fun and deliver more value faster in the process. Thanks Thanks to Mike Grigoriev for the excellent Shipping Profile retro.\nHow do you plan and organize your retrospective? Any advice to have better retrospectives? Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/how-to-organize-a-great-team-retrospective/","tags":["How-to","Product"],"title":"How to Organize a Great Team Retrospective"},{"categories":null,"contents":" Platform tectonic shifts alter the partner+platform landscape very rapidly\nIntroduction This post is the fourth part in a series of five regarding platforms and the key differences with products.\nPlatform Product Manager: Partner (1/5) Platform Product Manager: Complexity (2/5) Platform Product Manager: Mental Models (3/5) Revolutions or evolution? Most of the time, a platform evolution is more subtle than a product evolution. One will have to read all the API release notes to try to make sense of the general platform direction. Different teams are in charge of these evolutions. Each team has its expected outcomes and business realities, which makes analyzing these changes even more challenging. Doing this analysis from outside of the platform organization is even harder because the analyst lacks context. We will discuss these subtle evolutions in the subsequent section.\nLet’s focus on a more drastic way for a platform to evolve: platform tectonic shifts!\nRevolutions: Platform tectonic shifts The root causes of these significant changes are:- an existential threat to the platform or part of the platform- a major strategy shift- customer expectations have changed fast\nTectonic shifts \u0026ndash; Photo by Andrew Buchanan\nThe tectonic shift has the same consequences for the partner ecosystem as a major seism in the physical world. The dissipated energy can be enormous and have a tremendous impact area or be more localized and only affect a few specialized partners. It depends on the partner distance from the seism epicentre as well as the nature of the tectonic shift.\nIn any case, for an impacted partner, these tectonic shifts have all the characteristics of a natural disaster. Usually, these changes happen because customers’ need evolved: they expect some previously partner provided functionalities to be part of the platform.\nIn its most extreme form, some partners are banned from the platform ecosystem (removed from the app store) and can not extract additional value from this platform.\nCase study: Microsoft Windows and Internet Explorer Let’s go back in time and use the Windows operating system platform as an example. Microsoft’s decision to create a default browser (Internet Explorer) instead of using Netscape Navigator for this part of the user experience was a tectonic shift.\nAs often in these situations, the platform team had close to zero expertise into the product, market, and technology they wanted to replace. The first iterations of the product were less performant/feature full than the product they are replacing.\nAfter a few iterations, the product becomes decent and used by millions of customers. It could be argued that Internet Explorer was never really a success from a user point of view. Let’s review these events from a platform and partner ecosystem point of view.\nInternet Explorer: an incredible commercial success Image from Wikipedia\nIn retrospect, Internet Explorer was immensely successful even if its user interface and quality are debatable. The data speaks by itself Internet Explorer was used by 94.43% in 2003 (Wikipedia).\nThis tectonic shift triggered a lawsuit: the United States of America vs Microsoft. The US accused Microsoft of breaking customer consent by bundling Internet Explorer with the operating system.\nImpact on the partner ecosystem The effect on the partner ecosystem was terrible: Netscape was losing the war on both the server-side and the client-side aspects of the Web server and Web browser. From a dominant position (\u0026gt;90%) during the 1990s, it was gone by 2002. Microsoft had won the browser war … on the desktop.\nIt was a terrible blow to the partner ecosystem at this time. Being a browser editor at the time means that you could not derive any revenue from this platform anymore. Any partner needed to find a new niche, a new business model and evolve super-rapidly or disappear into oblivion.\nThe platform needs to remain valuable: users first, partners second Today, we can all agree that an operating system without a browser is not an operating system. The platform did what its customers expected: it delivers a bundled solution that works out of the box.\nNetscape found, almost by accident, another way to compete using an open-source model to remain relevant. While the company disappears (sold to AOL), the source code remained alive and became Mozilla Firefox. Mozilla Firefox was able to survive thanks to its lean business model and revenues from the default search engine shipped with Mozilla Firefox (Google search at the time).\nPlatforms wars round 2: Internet Explorer as a casualty The new mobile operating system platforms (Android and iOS) used this playbook to create their browser (Chrome and Safari). An open-core that could be cross-platform (the HTML and Javascript rendering engine) and a proprietary layer owned by the platform so that no one can compete on the OS of origin of these browsers.\nAndroid dominance as an OS created chrome browser dominance. It also explains why Internet Explorer disappeared on these new dominant platforms. For 15 years, Microsoft was not even competing!\nMicrosoft tried to become a first-class player on mobile. Billions of R\u0026amp;D and a failed acquisition later, RIP Windows Phone, RIP Nokia. Android and iOS crushed Microsoft platform-level competition efforts.\nImage from Wikipedia\nMicrosoft is now a player in the cross-platform browser ecosystem world. Edge is bundled with Windows (of course!) but is also available on Android, iOS and even MacOS (beta for now).\nOnce again, Windows the platform delivers what its users expected for years: a cross-platform browser experience. The windows platform’s goal is that Windows desktop and surface users can use Microsoft’s default browser on other platforms. As a consequence, Edge has already more market share than Internet Explorer (4.51% vs 4.45% — Source: Wikipedia) and received way better reviews than Internet Explorer ever did.\nMicrosoft is an underdog in these markets. Without a vast user base, Microsoft can evolve faster, meet new user needs, delight users in new ways, and, if possible, disrupt the current equilibrium.\nPlatform Revolution Based on this example, we can come up with some sound conclusions and advice for both platforms and partners of these platforms.\nA platform will always act based on its users’ best interests first and partner second (See part 1: the partners). Because of inertia, market dominance and unwillingness to compete on somebody else platform, the platform will always be trying to compete at the platform level. Being cross-platform for a partner is a way to mitigate risk. Impacted partners need to react fast and find creative ways to generate revenues. Adopting another business model, finding other revenue streams, becoming cross-platform saved lots of companies. In general, it is fair to assume that platforms have no interest in disrupting their ecosystems violently. As a consequence, they rely on this strategy mainly because they missed some critical strategic decisions. **** The tectonic shift is a violent o course-correct. It is a manifestation of the decision to stop relying solely on the partner ecosystem for key and core functionalities.\nPlatform iterations This type of iterations is way more frequent than the tectonic shifts described above. Iterations are the primary way platforms evolve and keep up with their user needs.\nWhen user needs and expectations, as well as business reality, change slowly with time, platforms are relying on iterations to evolve. Platforms will either expand the functionality for specific partners’ type to create more value or move some of these functionalities inside the platform’s core offering.\nIterative evolution happens all the time and is used to evolve the boundaries between core platform functionality and partners slowly.\nThese iterations create a perpetual tension between the partners’ single-function highly specialized offering and the broader/generic core offering by the platform. Both the platform and the partners are also actively monitoring what is happening on other platforms or products. In general, it is fair to say that the iterative approach is creating more value for the global ecosystem.\nAs the platform slowly incorporate some of the partner functionalities into its core, partners will have to innovate as well and provide to their customers a better value proposition. These ever-changing boundaries between the platform and partner functionality will help keep everyone honest and competitive as they both strive to meet the user needs and expectations.\nIn a healthy partner-platform community, these changes are discussed jointly with the partner and platform: the roadmap for these changes is well known and shared with partners. Most of the time, the boundaries (between app and platform) evolve organically, and while there is continuous change, there is also a constant displacement of the value creation from the platform to the partners.\nHow to decide what is a core functionality of the platform and what should be provided by partners? In general, platforms avoid tectonic shifts. Platforms prefer an **** iterative evolution as it is almost guaranteed to deliver more value faster and also to maintain trust within the partner-platform ecosystem. The trust between the partners and the platform is the main value creation driver.\nStrategy shifts, as well as legal or financial imperatives, are the root cause of tectonic shifts. Examples include a partner extracting to much value, a partner abusing its dominant position within the partner ecosystem or an existential threat from outside the platform ecosystem. In these situations, the platform needs to come up rapidly with a good enough solution and commit important resources to build, maintain and support the new functionality.\nThe Pareto principle applied to the partner and platform ecosystem The Pareto law states that for many events, 80% of the effects come from 20% of the causes.\nThe Pareto principle applied to platform and partners ecosystem\nThis rule can be super helpful in deciding which feature is core to the platform. Only the most important features used by 80% of your users (or providing 80% of the platform value) should be part of the platform.\nEverything else should be implemented as an API so that partners can provide the remaining functionalities that are critical for specific users or markets. Quite often, these functionalities are exclusive to a small percentage of users. They are super-valuable and indispensable. Usually, these functionalities are deemed more advanced, are often more complicated than the platform and are also harder to implement, set-up and support. Most of the time, most of these functionalities are useless for most of the platform users.\nPareto law is only one mental model of many… While the Pareto principle is super useful to capture the value creation aspects of the platform and partners, be careful to look at the complete picture. Use all the pertinent mental models (see: Part 3 — Mental models) for platforms.\nAs always, consider the desirability and feasibility and viability of these decisions:\nFor viability: Make sure you know what the competition (other platforms) is doing and why. Run business analysis and have clear financial metrics and goals. Share this with all your stakeholders to make sure everyone is on board with the proposed changes. For desirability and usability, consider the user experience. For instance, does it makes sense for a user to install an app and a partner page for this feature? What are users’ expectations for this functionality: do they consider this is a basic one? For feasibility: is it realistic to have external API calls for this function? Will it slow down the application to a crawl? Can this functionality be down because of various network or partner outages? From a data integrity and accuracy point of view, who should own this data? Complete series: Platform Product Manager: Partner (1/5) Platform Product Manager: Complexity (2/5) Platform Product Manager: Mental Models (3/5) Platform Product Manager: Revolution and Evolution (4/5) Platform Product Manager: Conclusion (5/5) Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/from-product-to-platform-platform-revolutions-4-5/","tags":["Product Manager","Platform"],"title":"From Product to Platform — Platform Revolutions (4/5)"},{"categories":null,"contents":"Introduction In the first post, I described the importance of the partners in a platform world. In the second post, I described why a platform is more complex. This third post is about mental models.\nThe Product Manager role is abbreviated as PM while the Platform Product Manager one is abbreviated as PPM\nMental models We will review four mental models that I have consistently found useful when thinking about platforms.\nThose are practical models that can also be useful for PM as lots of successful products share some commonalities with platforms.\nI will use this mental model to highlight the main differences between a platform and a product. This will help me establish my main thesis: platform development is more unpredictable than product development.\nPlatform: Increased unpredictability A key component of the PM role is to increase predictability. This is done using two main tools:\nby helping each team member to grow and make better decisions; by providing guidance and a framework to help the team make a great decision quickly (start with why, prioritized roadmap, rituals, debate, decision log, etc.). Let’s start with the first mental model.\nPartners knowledge is a superset of the platform team knowledge The notion of subset and superset is a mathematical concept that applies to pretty much anything. For instance, we have seen above that the world includes all the mental models and much more: real living beings, planets, stars and so on.\nWe can apply this model to the partner ecosystem (see the next platform mental model) as represented below.\nNaive representation of the partner ecosystem diversity: colour is country, size is revenue, the shape is type of business (five partners, one platform).\nAll partners know about the platform. Quite often, the platform is what connects them together in the set theory: they need to have some sort of knowledge intersection with the platform. The platform is really the only universally shared knowledge among all partners.\nNow, most of the partners do not know each other and operate using very different business models (shape) in various domains, industries, countries that do not intersect with each other (colours, position in space). Each of the partners has developed deep domain expertise and is in direct contact with a subset of the platform customers. Some partners are larger (more revenue, more customers) than the platforms while others are operating at a local scale and are super-specialized: let’s assume that the area of each set represents the size (revenue) of the partner.\nSome partners are competitors: their domain expertise overlaps with each other’s while some of them operate in completely different business areas and have no shared knowledge.\nPartners, in aggregate, have a superset of the platform knowledge.\nIf we could map all knowledge from all partners of the platform, it is my belief (validated with experience!) that the aggregated knowledge of partners represents a super-set of the platform knowledge.\nHere is a tentative demonstration: As the number of partners grows and as the value created by the partner ecosystem surpass the value created by the platform. So does the partner knowledge.\nIn other words, partners have more direct knowledge and context of the problem they are trying to solve than the platform.\nHow to use this mental model as a PPM?\nWorking with partners is indispensable. Contrarily to a singular product organization in which a PM goal is to become a domain expert, with the user research team, and to collectively know more about the problem space than most participants (users/customers, partners), this goal is not even worth pursuing as a Platform PM. As the number of partners grows, their aggregated knowledge will always be a superset of the platform available knowledge.\nAs a consequence, user research, API roadmapping and API development should never be done in isolation. As a PPM, you have to engage with partners and involve the partners at every step: ideation, testing and delivery. This is also where the magic happens: partners are passionate about their domain of expertise and they are eager to find the best possible solution. As you engage and connect with partners, you will be able to leverage the impressive mass of knowledge.\nThis reinforces the need for PPMS to build a network of trust outside of their organizations as this is the most efficient way for us, humans, to exchange information, knowledge and ideas. By leveraging partners’ super-set of knowledge PPMS can now super rapidly test futuristic ideas (ideation), explore/define the problem space and solutions space, validate the riskiest assumption of any new endeavour.\nIn this context, the main goal of a PPM should be to abstract all the partners’ current and future needs. What is shared between all partners and should be built as a service inside the platform? What will remain true in 10 years? (at Shopify we even ask ourselves will this be true in 100 years as we want to build a 100-years company ;-).\nEverything that is common to lots of partners, which has a long term future and is valuable, feasible and desirable should build inside the platform and build for the long term.\nEverything else should be built as an API that partners can now leverage to create value in their own domain and compete with each other to offer the best possible value to the platform customers.\nPlatforms are an ecosystem A product can be seen as a plant which is growing on a certain are on planet earth. A platform is similar to a complete ecosystem operating on the same planet. Each partner is now a plant or an animal operating in this ecosystem. Some of the platform partners will become their fiercest competitors, some are already a competitor, others are contributing to multiple ecosystems helping users to switch from one ecosystem to the other, etc.\nSource (Gartner)[https://blogs.gartner.com/smarterwithgartner/files/2017/06/BusinessEcosystem_Infographic.png]\nIf we follow this analogy, it is clear that the platform team has way less control of who is using their API and what their goal or business model is.\nFor instance, some partners specializes in deplatforming a customer from one platform to another. Others will add tremendous value and help the platform grow.\nWhile we often complain, as a product manager, how users ‘hack’ our products, without an API, what they can do is easier to control than a platform API.\nWith a platform, the variety of how a partner can use an API is infinitely more complex … and unpredictable. This is unpredictable because partners are expert in an area that the product or platform team are often completely unaware of.\nThis unpredictability makes defining the success as well as the planning/roadmap activities way harder: your success depends on partner success! While your API will provide huge leverage to partner, ultimately, this is not something you can contribute directly. The best way to have successful launches is really to build a strong partner community (see part 1/5: the partners).\nIn the ecosystem mental model, the PPM role is very alike to the role of a gardener. He needs to provide all the key vital elements (sun, soil, water, etc.) to each partner species and help them thrive. The PPM does not control mother nature and events outside of the PPM control zone will cause serious damage in part of the ecosystem very much like a drought.\nThe ecosystem mental model is also quite interesting when considering the yearly and quarterly business cycles. The season\u0026rsquo;s analogy should be used by the PPM in order to plan the year ahead. I recommend defining what needs to be shipped in order to launch at the annual developer conference. The PPM can now use this fixed date as a forcing function inside his own organization to get alignment and have well-identified key milestones.\nFinite game vs infinite game analogy Image from The Planning Center\nSome games are finite. Good examples include Asteroid, Tetris, Donkey Kong and more generically games with fixed gameplay and with a clear and singular goal. One can progress and become more and more proficient at these games however, the end game, winning, is known in advance and does not evolve. This would be a good analogy for a singular product.\nInspired by The Planning Center\nCompare these games to something like Minecraft where players can contribute to the world, define a new world with completely different rules and where winning is not even defined!\nDevelopers and hackers are providing extensions, contributing, along with the editor to this infinite evolution using every possible extension available and, in certain cases, hacking the system to add additional extension points in order to deliver the experience of their dreams.\nThis analogy helps better define platform-based product management. **** The platform main role is to define the rules of the world and help the players create new and exciting things and … have fun in the process.\nOf course, in the business world, a powerful alignment tool is … money. It is used to incentivize each partner to have fun and continue to play, create value, enrich the ecosystem, generating more value and having new players join the ecosystem and … repeat the process.\nAnother powerful tool used by the platform is the API as well as the intrinsic API limits that players can use. These APIs define the boundaries between the world and the players. The API limits are not only technical. They include numerous dimensions: legal, commercial, data, service level agreement, etc.\nThe compounded interests analogy As platform mature and gather user demand, this stimulates more partners to join the platform. Each of these partners is providing value and extracting good revenue in return.\nValue creation as compounded interest from a platform user using three different partner apps.\nFor instance, in the schema above, particular user benefits from three different apps. Each app is installed at a different point in time. Each app is its own product and provides additional value as new functionalities are added to these apps to better fit their customer needs. The platform capture also a share of the value but, ultimately, a platform redistribute the value to partners more and more, capturing less value than the aggregated partners.\nIn opposition, a product wishing to provide the same value would have to develop incredible expertise in lots of product areas or geographies. This can be a real daunting task as the product want to scale globally and to different markets. This is a lot of pure developer talent! In fact, lots of these developers main identity is an entrepreneur and not a developer. It would be almost impossible to attract these talents inside a large scale platform-type organization.\nA great example would be the iOS or Android platform. Users do not even pay for the operating system on a monthly basis. For all-purpose, the platform cost for the users is in fact zero. However, these users install between 50 and 100 apps on their devices and sometimes pays additional services to the platform operator (Apple or Google). The platforms capture between 20% and 30% of the direct value created by each partner.\nEach partner is on its own compounded interest trajectory where they try to maximise value creation and minimize the cost. The platform is a broker whose goal is to generate even more partner engagement and value creation via improvements to the platform itself.\nIn this model, the PPM main role is to maximize value creation. As this is a financial mental model, a PPM success in launching or iterating on a new API call or a brand new API can easily be measured by counting the total revenue generated by partners. This can be super granular, down to each API call. As partners grow and use multiple API (especially in the case of GraphQL and Schema stitching,) causality becomes harder to establish as partners will create huge value by using multiple sections of the API. This is a super helpful model when financial metrics are needed: it can really stimulate investments into the API and partner ecosystem.\nComplete series: Platform Product Manager: Partner (1/5) Platform Product Manager: Complexity (2/5) Platform Product Manager: Mental Models (3/5) Platform Product Manager: Revolution and Evolution (4/5) Platform Product Manager: Conclusion (5/5) Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/from-product-to-platform-platform-mental-models-3-5/","tags":["Product Manager","Platform"],"title":"From Product to Platform — Platform Mental Models (3/5)"},{"categories":null,"contents":"Introduction In the precedent post, I described the importance of the partners in a platform world. Now let\u0026rsquo;s have a look at complexity, once again, trying to highlight the differences between product and platform development.\nThe Product Manager role is abbreviated as PM while the Platform Product Manager one is abbreviated as PPM\nTechnology {{ \u0026lt; figure src=\u0026quot;/images/max/800/1-xxi-kg18lipn4xcfzmoqqq.jpg\u0026quot; caption=\u0026ldquo;Code complexity / Photo by Chris Ried\u0026rdquo; \u0026gt;}}\nAs a Platform Product Manager, you will need to interact with a more diverse engineering team because usually API design and development is quite different than front-end/user-facing development. Example of new specialties: API designer, API developer and then you also have multiple flavors to work with mainly REST and GraphQL these days.\nTypically, it means that you should be more on the technical side of things. You need to understand rate limits, complexity limits, query cost, and basic distributed system architecture. Other useful notions include synchronous/asynchronous calls, Webhooks, subscription services as well as key elements like the source of truth, integrity and backward compatibility.\nYou should be able to read/parse JSON, make read/write REST and GraphQL queries and mutations. If possible, with a developer, you should also build an app and be able to consume and teso that you can.\nAPI first? While this approach could make sense for a product, I am not sure this is recommended for a platform. A platform is a complex set of API(s) and features. Not being able to experience the UI as you use a brand new API will most certainly create misalignment and generate poor quality feedback from partners.\nSaid differently, a published API without any corresponding UI artifacts can be very abstract and quite hard to understand both for partners and for the product team.\nGather partners\u0026rsquo; API feedback instead Even if API first is not an option, the API first principle can be respected. You absolutely should prototype your API and engage with partners before engaging with your users. You could also provide a simple pdf document with the planned API calls and payload. Ultimately, publishing a developer preview version of your queries (read-only API) will also make it more concrete and testable for partners. As soon as it is reasonably bug-free and functional (even if with limited scope), releasing an alpha and then the beta version of the API is recommended.\nFeedback gathering on the API will allow you to create a more compelling vision of the API + product as well as clearly delineate what are the platform functionalities are, what functionalities are shared with partners and which one are exclusive to partners.\nBackward compatibility One of your primary responsibility, as a PPM, is to remain backward compatible. If you can not achieve backward compatibility, this could create chaos among your partners. An unknown number of apps could fail, causing a massive loss of trust (and value!) between the partners, the users and the platform.\nBackward compatibility is not guaranteed even if the API does not change! An API is only an expression of a broader, more in-depth social contract between the partners and the platform. Lots of assumptions exist on the platform side as well as on the partner side.\nFor instance, you inherited a great project: in certain circumstances, by doing two external calls to partners instead of one, you could improve the user experience and solve a sturdy business problem. The team can ship this project during a two-week sprint.\nImage by (Gerd Altmann)[https://pixabay.com/users/geralt-9301/]\nThe product team develops and test it on a small scale (1% of the calls). When you roll-out, this causes a massive outage and lots of partners apps immediately stop working. After long hours of problem-solving, bug fixing and a massive revert of all the changes, you discover the root cause. Some partners were using a security tool to prevent denial of service attacks. The two calls that happened in a short interval triggered the security measure — the platform IPs were blocked for 1 minute. The platform retried the API call on average every 30s. The partners’ production engineering team did not even manage the security equipment!\nA simple behavior change can have dramatic consequences. Be super mindful of areas like unit conversions (measure, weight, currency), internal changes of some unused data structure, removal of hidden fields, broadening or specialization of internal concepts.\nQuite often, these risks are in the blind spot of your engineers: they did not even change the API. Why bother with partner and risk analysis?\nSome risk mitigation strategies you could use:\nBe in constant contact with your partner community even for so-called minor changes as soon as it is in the same domain-area Ship the updated API one partner at a time and monitor the roll-out Have a documented and tested roll-back plan Product launch is more complex When new functionalities in the platform have launched that overlap with the partners offering, the PPM has to make sure that partners will adopt new API.\nA useful model to use is the carrot and stick model from the psychological theory of motivation. The stick should be your last resort weapon. As a PPM, you can deprecate an API version and, at some point, stop providing the service. Using the stick approach causes your relationship with a partner to weaken and add friction to the value creation. Not a great way to build an open and trustful partner community!\nAs a PPM, if you have to use this, it is a clear sign that the newly launched API does not create enough value for your partners to invest in it and migrate. The best solution would be to identify these API gaps and make sure the new API addresses them.\nThe carrot is my favorite approach. As a PPM, your goal should be to make the new version of the API so desirable that it is adopted right away by some key partners. They adopt it because you engaged with them and made sure that the API was a great answer to their business needs. Once a few significant partners have adopted, you can now leverage them as an example, do case studies and special events with these early adopters. Make sure you give early adopters more visibility (case study, developer conference) because they create value faster than the other partners. At this point, the main driver for API adoption is competition.\nThe platform must handle each partner with equanimity. Make sure you support and engage all other partners. Be super explicit about the timeline for launch, early adoption and offer all partners the possibility to shine and be an early adopter.\nLegal and financial complexities API usage requires a social contract to be signed between the platform and the partners building apps using the new or updated API. Each API is not created equal in terms of monetization, revenue-sharing, and even business model. This can create headaches and complexity and even kill projects as legal agreements are rejected by both parties. This can affect the entire feasibility of a new API because of the regulation or the inability to find a revenue-sharing agreement with partners.\nOnce an app is shipped and used, loopholes can be discovered linked to the revenue sharing terms between the platform and the app. Some apps, with a large user base, can now impose their will and hold lots of power because they own a large component of the user experience (for some users). This context has to be perfectly understood by the PPM especially if she/he plans to iterate/change this API. Most of the time, this means meetings with the finance team, the commercial team, doing thorough business and market analysis as well as numerous alignment and negotiation rounds with partners.\nPartner/platform team: UX teams are not necessarily eager to consider partner research as their core responsibility. This can be even more acute in organizations with a “platform team” or “partner team” who own the relationship between the platform and the partners.\nAs always, a PM must use their judgment before deciding what is best for the project. A bit of key advice for a new PPM or when iterating on a new product area would be to always do your own research: learn about the larger partners, meet 1:1 with the key partner\u0026rsquo;s managers, ask the platform team to help you set up 1:1 meetings with key partners, etc.\nForm your own opinion on who can help you the best to understand the problem space and do not hesitate to reach out directly to partners. As we will see in the next section (mental model), they have much more knowledge than you do in their own field of expertise.\nBusiness metrics and internal alignment When a partner/platform team exists, this team will tend to centralize the revenues from the partners. It can then become super hard to obtain funding because on one end the product team is building new API that will generate new revenues and on the other hand the platform team is considering these revenues part of their revenue stream. This could create a vicious circle because product team will then stop investing into the platform and only focus on actions that impacts their revenues and profitability.\nImage by Santa3\nLots of commercial teams and product organization to not have a strong platform muscle. They are well versed in the direct revenue model and prefer to contract partners directly using a 1:1 approach, not an API with a revenue share approach.\nThis is even more critical if you plan to change the revenue-share agreement with the partners vs maintaining the status-quo of the current API. In this case, the PPM will have to make sure that all the interests are aligned. You may have to reach out outside of the product team: GM, finance team, commercial team. For key areas, this can, of course, escalate up to the CFO/organization leaders as well.\nDon\u0026rsquo;t wait for these events to happen: define the financial impact early on and work with these teams to make sure your assumptions and modeling are correct. Have a deck ready to explain all this in 5 minutes with a clear recommendation that you can deliver while in an elevator.\nMore complex stakeholder management The PPM operates in an imposed environment. The product team are users and not owners of the API technological layer, API tooling, API release, and approval processes, API go to market, the acceptable term of use, API limits, agreement with partners, etc.\nAny API change and behavior change that can impact a partner will increase the number and type of stakeholders. More often than not this will add at least three stakeholders dimension to your workspace: a representative of the partner (platform/partner team), a representative of the API process and release, an API go to the market specialist.\nAll these new players and approval processes can cause setbacks and delays. This is especially critical when the launch date is fixed. Typically the yearly developer conference. As often, don\u0026rsquo;t wait: be pro-active, engage with these stakeholders early on, find them, build a meaningful relationship with them and establish trust even before the project has started.\nComplete series: Platform Product Manager: Partner (1/5) Platform Product Manager: Complexity (2/5) Platform Product Manager: Mental Models (3/5) Platform Product Manager: Revolution and Evolution (4/5) Platform Product Manager: Conclusion (5/5) Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/from-product-to-platform-increased-complexity-2-5/","tags":["Product Manager","Platform"],"title":"From Product to Platform — Increased Complexity (2/5)"},{"categories":null,"contents":"What is a platform? “That’s a crock of shit. This isn’t a platform. A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it. Then it’s a platform.”\nBill Gates referring to the Facebook product (from Stratechery: The Bill Gates Line)\nA product becomes a platform once the revenue generated by the partners exceeds the platform revenues. Tech examples include MS Windows, Apple iOS, Google’s Android and, more recently, Shopify.\nThis blog series is not about platform vs aggregators (see Stratechery). The focus of these posts is the key differences between a platform product manager and the more traditional product manager. Most of it comes from my last 18 months at Shopify, where I transitioned between these two roles.\nWhat is this platform manager role? Platform manager is a new role. Job offerings will mostly relate to a Product Manager role. You need to look at the company (is this a platform?) as well as at the role description. Even within platform companies, there are lots of pure product roles inside platform companies, as well.\nIn this blog series, I will use PM for regular PM and PPM for a “platform product manager.”\nPlatforms: The partners’ impact (1/5) Partners as users Partners are users of the API. Their personas, interest, motivation, key objectives are very different from your product users. For Platform Product Managers (PPM), it adds a lot of activities like doing partner research, API design, API MVP as well as a go-to-market strategy for partners. Those require different tools and skills than regular user research, MVP and go to market strategy. The API first approach is also something you may want to adopt in the context of a platform. A PPM should master this context and the associated process, especially if nobody in the team is familiar with partner interactions.\nPartners as stakeholders In product organizations, bringing partners into the mix is often hard. In the product world, partners are a necessary evil: between competitors and part of the value chain.\nIn platform organizations, partners are the ones creating the value: they are critical to the success of any API and product launch.\nAs a PPM, you should consider your partners as stakeholders: they have a critical role to play in the platform’s success.\nProduct Managers listen to the voice of the customer.Platform Managers listen to the voice of the developer as well.\nPartners as a community Once you have more than a couple of partners, it will become hard to gather feedback and have direct information from each partner. Once this happens, you need to consider the partners as a community.\nPlatform companies do not have product announcements. They have a developer conference: a fixed (yearly) release cycle to bring partners together and announce the future of the platform. For platform companies, the developer conference is, in fact, the most critical marketing event of the year.\nLike the yearly reveal of the roadmap for product companies, developer conferences mix a compelling vision of the future where partners have a critical role to play.\nPartners at a workshop Photo from Burst\nIn your area of the platform, I genuinely believe that PPMs should develop this community and use this collective wisdom and intelligence to shape up a better partner and user experience.\nDo not take this community for granted and make sure you solicit this community feedback and interact respectfully and truthfully with each partner. Typical activities include office hours, dedicated 1:1 time with partners and workshops. This will ensure that you remain connected with the partner community.\nPlatform extensibility \u0026amp; partners: where is the boundary between the core platform (product) functionality and the partner businesses? A PPM will have to align with its stakeholders to define, which functionality will remain a partner exclusivity or be part of the platform in a future release. The boundary between a stock user experience (no app) and an extended user experience (with at least one app) will evolve with time.\nThe boundary between the platform and the partners depend on partners’ and platform business model as well as user expectations. The features which were unique to a partner ten years ago are now undoubtedly expected by your users.\nDelighters of the past are basic functionalities of today (See Kano model). Slowly, the platform incorporates more and more features from partners, while partners continue to innovate and create value by adding needs unmet by the platform.\nAs a PPM, you need understand the value creation chain from a systemic point of view. You need to consider partners’ contributions to the ecosystem for each of your decisions. Platform evolution is the subject of the fourth blog post on the platform vs product series.\nComplete series: Platform Product Manager: Partner (1/5) Platform Product Manager: Complexity (2/5) Platform Product Manager: Mental Models (3/5) Platform Product Manager: Revolution and Evolution (4/5) Platform Product Manager: Conclusion (5/5) Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/from-product-manager-to-platform-manager-the-partners-impact-1-5/","tags":["Product Manager","Plaform"],"title":"From Product Manager to Platform Manager — the Partners’ Impact(1/5)"},{"categories":null,"contents":" Never Split the difference by [https://twitter.com/VossNegotiation]\nIt can seems ironical or even sarcastic to review such a book on a blog about optimism and product management. This is not the case: everyone can become a better human being with this book.\nIf you practice, the key outcome of this book will be a more deliberate practice of saying no with empathy. A key skill to reflect on your life and to cultivate happiness.\nA key takeaway for me was the fact that empathizing does not mean agreeing with others (the counterpart). Lots of people are afraid to empathize because they believe it will weaken their resolution. For men, empathy is often associated with weakness. Male peers often discourage you to cry in public if you are man. As a consequence, pals tend to avoid sharing emotions and their impacts. This social pressure reflect more often than not the old paradigm of the alpha male.\nOf course empathizing with others can make you change your mind. And this is a good thing! Leading an examined life requires you to deal with others feeling. If your motivations, values and goals in life are clear, empathy can not weaken you. Empathy reinforces you because you understand others more completely. You can now impact their lives: empathy is the essence of leadership.\nThis book surprised me a lot. Blame the movies and Hollywood but I was not expecting this approach from an FBI expert. M. Voss and Plato shared a lot of commonalities!\nThis book is all about “the art of contextual questioning with respect and empathy”. This would be my proposed subtitle.\nResearch (before the negotiation) is key. Know your counterpart, do your research and come informed. Always keep an open mind. You have to look for for unknown unknowns (Black Swan): remain agile, flexible and nimble. You have to decipher what your counter part said, how he said it and what remains unsaid. Mirror your counterpart and ask questions with empathy. Label the emotions and state of mind of your counterpart.\nYes is not the goal. In fact, most of the book is about how to say no without hurting your counterpart. Empathy is key but you need other tools. You can only influence your counterpart once he is convinced that you understand her/him. The key is to get a “That’s right”, not “You’re right”. This will create a great outcome for both of you.\nThe alternative is almost always a pure negative outcome for both parties.\nOf course, you will also get a chapter on haggling. This makes sense part of a negotiating book. I took it as a great way to practice for low stakes interactions.\nI also loved the fact that the book expand the best alternative to a negotiated agreement (BATNA). The author recommend to use a scenario-based approach. From ideal (ego flattering) to worse case scenario.\nThis technique is not in the book but I always imagine more than three scenarios:\nYour alphabet scenario from Burst\nA: The ideal scenario (very ego flattering) B: depend on the situation C: … D: Best alternative to negotiated agreement (BATNA) E: … … Z: Immediate death or debilitating disease. None of this matter anymore… This scenario approach is key to not get distracted and to not become overwhelmed by emotions. Plan Z allows you to keep your goals and perspective in plain sight. This is true even if your counterpart is hurting your feelings and if you have to completely forget plan A.\nNegotiating is about active listening, framing, patience, empathy and questioning with respect (mirroring). This is an art and not pure science.\nIt has a wider scope than hostage negotiation. If you apply the proposed strategies you will become a better human being.\nYou will be honest about what you feel. This includes some irrational fear like being afraid to “lose”. Or the greatest fear of our time: the fear of missing out. You will understand other human beings better. You will prove to your counterpart that you understand her/him better. Plan Z will help you hold your emotional ground: your emotions will not dictate your actions anymore. You will remain flexible, fluid and agile. Life is change and, to be honest, you don’t know a lot about others and the situations. Always looking for black swans will keep you balanced, honest, curious and eager to learn. What this book is not This book is not about hostage negotiation. The author has a tremendous experience about high stakes / explosive and changing situations. The author then distills errors and success to provide strong communication principles. You can apply these principle each time you want to influence someone. This can be your next pay raise, promotions or to help your son brush his teeth.\nWhat this book is This is a book about radical honesty: yourself, others, what you know and don’t know you don’t know. It proposes a radical communication toolkit to improve the world. It only works if your goals and objectives are noble: anything else is pure manipulation.\nThis is a recommended read to anyone who want to become:\na better communicator a positive influencer (leader) more respectful of others ideas and feelings Conclusion This is a great book that is easy to read. Each chapter has a real-life story from the author or one of his student. As you read through chapters you will experience the negotiation process step by step. At the end of each chapter the author summarized the key takeaways.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/never-split-the-difference-the-art-of-contextual-questioning-with-respect-and-empathy/","tags":["Book","Negotiation","Soft skill"],"title":"📖 Never Split The Difference: the art of contextual questioning with respect and empathy."},{"categories":null,"contents":" Some benefits of optimism 👍\nWhy being optimistic? See “Why being optimistic is a choice”.\nWhy a radical optimist? The world needs a major change to adopt a more balanced view of the future. The optimistic view is far from the most popular adopted by media. This is true for traditional media (radio, TV, newspaper) and social media alike (Facebook, Twitter, etc.).\nWe crave for negative and life threatening events. This is a scar from our evolutionary past. Stories of survival, loss, difficulties and unbearable suffering stimulate our interest. They are extraordinarily powerful and are easy to remember.\nOn the contrary, stories with positive outcome and feelings are often labeled childish, irrealistic, feelgood and even … girly. This is especially true among boys.\nNote: I do not endorse the “girly” term. However, this is a visible consequence of our society genderism. Positive takeaway: It reflects the heightened sensibility of women and also their capability to dream of a better future.\nWhy radical ? Radical has various definitions:\nvery different from the usual or traditional; favoring extreme changes in existing views, habits, conditions, or institutions; associated with political views, practices, and policies of extreme change; advocating extreme measures to keep or restore a political state of affairs. Marketing, the Internet, our brain and the incredible power of fear Each second, our mind captures dozens of messages, advertisements, banners, videos. Click-words, pictures, and finely tuned videos exploit this particular bias. In this day and age, fear of loss is the basis of marketing as we experience it. Fear to lose what we have, fear to not have what we could have, fear to have less than our neighbor, fear to miss the latest shiny object, etc.\nMarketing agencies and the main social networks have gathered a huge data set about human activities. Experts around the world use advanced machine learning algorithms to crack open the human brain. They are looking for bugs into our species brain.\nThese bugs (remains of our animal and evolutionary past) are then marketed to make you change. You are not aware of this change: this is pure manipulation.\nThis is not only used to make you buy more. Information is now weaponized. Cyber war is real: every piece of content that you receive influence your behavior. If we cannot bring you closer to one side of the political spectrum then we will try to suppress your vote. You will now receive some negative news about your own party. These news will present you tweaked information under a negative aspect. Until you are convinced that … it is better not to vote!\nBetter a non voter than someone who vote for the other side…\nBecause of those bugs that are deeply hidden into our DNA and into our society structure, your behavior will change. And you do not have a say!\nWe need optimism to bring back balance.\nOnly radical optimism can bring back some equilibrium in our world views.\nWe need goals, both as individuals and as the earth’s society. Those goals are not hard to find:\nimprovement of all living being individual conditions real happiness for all Past history has shown us conducts we should avoid. What are they?\nWars, exclusion, tribalism, economic crisis, elitism, famine, etc. As individuals we have a short term memory: we remember our youth (after age 7 or so) and some key life events. As a society this is worse! We always want to do better than our ancestors. But we tend to reproduce the same mistakes and the same catastrophes happen again and again.\nAs a specie, as the most evolved specie in the known universe, we have to visualize, dream and tell positive stories about the world we want to build.\nThis requires a healthy dose of radical optimism.\n","permalink":"//localhost:1313/en/post/radical-optimist/","tags":["Essay","Optimist"],"title":"Radical + Optimist"},{"categories":["Books"],"contents":"Intro Sense and respond is an excellent book for knowledge workers. This book is a great map to help you navigate in our increasingly digital world.\nThis book by Jeff Gothelf and Josh Seiden is a much more polished product than their previous one, Lean UX. “Sense and respond” is synthetic, better organized and more natural to read. The information flows more and has been generalized to any organization. It covers examples from the business world. It also offers positive and negative examples from many industries.\nThe core thesis is very similar to the tenants of the agile movement: we don’t know what the future holds for us and as a consequence, we need to:\nEmbrace “continuous uncertainty” (business, technology, human behaviour, etc.) Learn continuously (experiments, personal growth, business growth, etc.) Release experiments Continuously integrate (ship new functionalities as fast as possible to some users) Set up an appropriate culture (everyone involved and engaged) Each chapter contains a useful summary of the key points. It makes it easy to refer to the book or come back to it later on. I took a picture of every chapter summary, and those are very useful to refer to later on when immersed in your craft.\nPart one: Chapters 1–4 — Why do you need sense and response? The first chapter explains “the why” and provides an overview of the “sense and respond” model.\nThe authors explain the differences between the old “product-based, industrial world” and the new software-based agile world. They explore different examples from various industries. If you already work in an organization that has transitioned to this model this can be redundant and even boring. You can skip chapter one!\nThe second chapter gives an overview of the sense and response model:\nSmall autonomous teams (and then teams of team to scale) Learning via loose plans and controlled risk-taking (and failures) Value creation using real conversations with customers A data-based approach to decision making Chapter 3 is about resistance: why do companies/organizations resist change. What to do about it? This chapter is useful if you are in the transition phase. But not only! These obstacles are common to classic organizations who want to transition to a “sense and respond” model. A recommended read even if you work in a software startup or within an already practicing sense and respond organization.\nChapter 4 is about the prominent role that software has in the world.\n“Software is eating the world”Marc Andreessen, VC\nSoftware affects or will affect every area of human civilization. As a consequence, everyone needs to embrace the exceptional fluidity of software (never complete, easy to update at no cost even for billions of users, etc.). The old management playbook has to change! It is essential for the “legacy” organization. Without this critical organizational change, they will become obsolete in no time.\nPart two: Chapters 5–8 — A manager’s guide to Sense and response The title of this part is misleading. Even if the manager role is changing more than the other contributors: everyone is a leader. And everyone is a change agent. The culture is everyone’s problem and responsibility, not only the manager’s responsibility. As such, this part would be better called “A “change agent’s” guide to sense and respond.\nStated positively: the second part contains lots of actionable information. This information would help any individual contributor inside a sense and respond organization. With this knowledge, you will be able to maximize your impact! This is only true and possible if you can convince the management supports those initiatives.\nChapter 5 is about the famous “Definition of done.” In the software world and especially in the SaAS industry, a product is never completely done. Each product growth is organic and unique to this product and specific market conditions. Each product relies on an ever-changing ecosystem both inside and outside of the organization.\nBeing “agile” implies a different way to create roadmaps and prioritize work Uncertainty is part of the game, and everyone has to agree that the plan is only that. The plan will never become a reality… as planned. Roadmaps and prioritization should be outcome-based Alignment is key. The role of managers is to align the teams both inside and outside the organizations. Chapter 6 is all about collaboration. The classic cross-functional and autonomous team is at the core of the collaboration process. This is a team with cross-functional experts. They have total autonomy to ensure that each feature will help achieve an agreed-upon positive outcome. They master the design (usable), the technology (feasible) and the business (valuable) aspects of the problem space. Co-located teams seem to work better and be more efficient. Blameless retrospectives are crucial to individual and collective learning.\nChapter 7 is “continuous everything.” This chapter expands on the DevOps movement. Every process required to build a product, a service or a platform has to become continuous. The recommendations are as follow:\nShip new code every day Test new code every day Sandbox the risky aspects of any project Learn everyday Annual budgeting is incompatible with the fast-pace world we live in Sales and marketing teams have to adapt to a new world where value is delivered incrementally It is impossible to sell in advance a “feature roadmap” (also known as vaporware in the industry!). Chapter 8 is about the required culture to promote continuous learning. This could be a subset of the precedent chapter. But I like the fact that this subject has its section. Without a culture that encourages some key behaviours, it’s impossible to experience any of the positive outcomes.\nWhat should the culture encourage? Always be learning.\nWhat behaviours are critical:\nhumility permission to fail self-direction transparency a bias for action empathy and collaboration. Book review conclusion This book is handy if you are part of a “sense and respond” organization. It is essential if you are curious about this phenomenon or if you want to implement these changes. This is an easy and short read: with less than 230 pages, the synthetic view provided is highly valuable. It relies on many examples and prior art. The reference section is quite detailed (4 to 21 references per chapter) so that you can go deeper or validate the information (examples, theories, etc.).\nI recommend this book for any knowledge worker. To be more specific, if you are a developer, a UX expert or designer, a product manager or a manager: this book is for you!\nThe Reinventing organization parallel I see this book as an attempt to systematize the findings of the agile manifesto as well as Reinventing Organizations by Frederic Laloux. The original book by Laloux is a massive piece. It retraces the management behaviours through the history of humanity. A fascinating read for scholars and people passionate about human civilization. Reinventing organizations is not easy to apply in practice. The “sense and respond” organizations are defined as “teal organizations” by F. Laloux. They represent the most advanced and documented way to create holistic organizations.\nFrederic Laloux highlights the fact that some organization types have been around for thousands of years. For instance, churches, firefighters, military. These organization models work exceptionally well during a crisis (during which time you don’t want to have a daily scrum and a retrospective at the end of the iteration!).\nAnother aspect covered by Frederic Laloux is that some people, because of their culture, can not thrive in a holistic organization. It is tough to find self-motivated candidates who want to workl as purely self-motivated knowledge workers. In these organizations, the recruitment process and selection process is so challenging: lots of interviews, a manager’s point of view, a team point of view, an expert point of view, emotional intelligence, etc.\nCulture is paramount in these interviews: hiring someone with a culture incompatible with the self-management principle can have daunting consequences (for the new hire and the organization). As we all know, it is tough to validate a future hire culture during a few interviews.\nWill this model (teal organizations or Sense and respond organizations) prevail, or will it be replaced by something new? I have a different opinion than the authors. I don’t know if the “Sense and respond” model is a one size fits all model. The authors want to make their point and use some unconvincing marketing efforts to make it appear as if all other types of organizations are doomed. The book examples are not of statistical significance. We will have to wait and learn how the self-organization evolves and thrive before making such claims.\nThese transformations will take time. World culture would have to change drastically. In particular, every education system (primary, secondary, university) will have to evolve worldwide. The education system outcome will be to form lifelong learners (learning how to learn), not some human databases of facts and rules (output-based, easy to test).\nEach knowledge worker’s place in society needs to evolve, as well. Today, we sense that money is not the only criteria we should use to decide what to do with our lives. The response should be a better society where each knowledge worker can thrive and contribute to a better world.\nIt’s too soon to tell if the model presented in “Sense and respond” is a civilization bubble or if it will succeed. Strong forces are in action: the current capitalist approach is almost exclusively output based. Most of the old organizations have shallow ethical standards: respect the law and maximize shareholder value. This output-based approach is in complete opposition with the sense and responds model, which is outcome-focused: having a positive impact, solving hard problems, growing and thriving individually and as a society.\nBonus: great illustration of the Sense \u0026amp; Respond model by XPlane A great illustration of the book process by XPlane\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/book-review-sense-respond/","tags":["Books","Agility"],"title":"📖 Book review: Sense \u0026 Respond"},{"categories":null,"contents":"Definition Here is the dictionary definition: an optimist is one who usually expects a favourable outcome. While this does not seem like much, words are essential.\nThere is no obligation to always expects a favorable outcome Favourable is a very ambiguous term: favourable for you? others?, the earth\u0026rsquo;s ecosystem?, the universe. This definition is quite helpful because, as often, it is very nuanced. This is fully compatible with the pursuit of happiness: you can sometimes be pessimistic about any given outcome (no stress!). Usually, with wisdom (and an examined life), you can redefine favourably as you see fit.\nThe most efficient lifelong lessons come with a direct and very real immediate negative outcome. For instance: a car accident, sports injury, significant failure, or losing a loved one. Optimists will consider all aspects of this event and redefine the situation (or the story) to find a positive outcome.\nA choice Being optimistic is a choice. An optimist in action looks for a reframing of any adverse situations. This can happen immediately, but more often than not this requires a heavy dose of introspection and soul searching.\nAs stated by @theStoicEmperor:\nMore on this blog Psychology Personal challenge and key takeaway: Today, please try to look at at least a negative situation and look for a positive outcome. Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/being-optimistic-is-a-choice/","tags":["Psychology","Optimism","How-to"],"title":"Being optimistic is a choice"},{"categories":null,"contents":"Reviewing an existing or creating a new wine club is an important operation, but, when you run a real-world winery, it is often not a priority. It falls in the category of important but not urgent things to do…\nIn large wineries, the wine club is often the responsibility of the Marketing or Direct-to-Consumer (DtC) Manager. More often than not, this person does not have the authority to make important changes to the wine club.\nGiven the hectic flow of daily activities, chances are you have not reviewed your wine club policies in a while.\nI hope this article convinces you that you have put off this task for far too long!\nImage credit (EmergingTech.tbr.edu)[http://emergingtech.tbr.edu/strategic-planning-mobilization]\nWhy should I review and update my wine club policies? As much as we would all like for our customer relationships to last forever, this, of course, is unrealistic! Tastes and expectations are ever evolving. In reviewing your wine club’s operation, you should consider two key measurements:\nThe churn — How many people have left the club this year?\nThe growth — How many people have joined the club this year?\nTo deepen your relationship with your most trusted customers, you also need to evolve and adapt. A wine club is essentially a social contract between you and your club members. It can be a 140-character or a thousand-page long.\nImage credit: doityourself.com\nWhat should you aim for in the contract?\nA — Financial transparency The financial aspect is a crucial part of any contract. In fact, lots of people only consider this one aspect when making a purchase. Therefore, state, as clearly as possible, the financial benefits that come with being a member of your club. Make sure to mention any list price or shipping rebates, and do so prominently! Make this information as easy to understand as possible.\nYour members will shop around. Do the same! Visit the websites of fellow winemakers you know and respect. Have a look at their offerings. How do yours compare?\nB — Simplicity In this day and age, news travels in 140-character streams (Twitter). Therefore, you should aim to offer the simplest contract possible. Your club members are not interested in legalistic mumbo jumbo (even the lawyers among them)! I am quite certain they would rather sip a glass of your wine than analyse the mind-numbing clauses of a business contract.\nThoroughly review the description and legal information of your wine club. Look for complexity and remove it. Look for unused options and remove them. Look for every sentence or word you can remove to help potential club members more clearly understand what your club is offering. If you write in English, have a look at Hemingway.\nC — Convenience People tend to travel a lot these days and for extended periods of time. Having to manage a wine shipment while abroad can be difficult and lead to unpleasant surprises (like receiving wine you do not like). Your wine club should offer a way to “pause” the membership for a certain period of time. In the short term, you will earn less during your next club run, but, in the long term, your member will remain faithful to your brand and your club.\nImage credit [YogaWineClub]{http://www.yogawineclub.com/)\nD — Flexibility Does your club allow members to personalize their club run? For instance, can they select 4 bottles of rosé and 2 bottles of white, instead of 3 and 3?\nCan your members add products to a club order? This makes it easier to group different shipments together and to take delivery of products. It also helps to increase sales.\nMake your system flexible. If everything is set in stone, your members will need to know which wines they want to drink six months or a year in advance!\nE — Members relationship: Image credit [https://au.pinterest.com/pin/419257046534241323/]\nDo you record their preferences to ensure the delivery of the types of product that they love? For a red wine club, some members want “only Shiraz”, others “No Cab-Merlot”. Don’t ask the same question again and again.\nIs your billing clear and straightforward?\nDo you manage expiring credit cards in advance? Members should be given the opportunity to update their credit card info to avoid missing a club run. This will lower your churn and show you genuine commitment in satisfying your members (who wants to miss an expected case of good wine?!!).\nCan members update their delivery address and notify you of temporary or permanent changes?\nConclusion Wine clubs are the part of the Direct to Consumer trend.\n74 percent of DtC sales, in terms of case production, are logged by wineries that made less than 2,500 cases in California, according to the Silicon Valley Bank (Wine Searcher article, 2016 Report) in California.\nIf you have not changed your wine club policies in the last few years, you should think about doing it soon…\nIn an ideal world, your wine policies should be updated regularly. This should be part of the yearly strategic review of operations, as well as plans for the future. When reviewing your wine club, take the time to do some “ground work”!\nHave a look at the wine clubs of other wineries and see what inspires you. Ask your most faithful members what they would like to see. Ask the ones that have left why they have left and what could bring them back. Ask your tasting room/cellar door staff what steps could be taken to convince visitors to become club members. At subscribility, we believe that a wine club is a key differentiator. Your club policies should reflect what feels true and fair, for you and your members. A wine club provides great benefits for your winery, if you don’t make the mistake of taking your members for granted. Always evolve and adapt!\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/why-you-should-update-your-wine-club-policies-now/","tags":["Wine Club","How-to","Wine","DTC"],"title":"Why you should update your wine club policies now!"},{"categories":null,"contents":"Wine is a complicated industry with a large and complex value chain and many partners, such as winemakers, agents, wholesalers, distributors, retail and online merchants, logistics experts and, of course, consumers.\nAs we expand Subscribility and work hard to explain our vision to prospective clients and investors, we have had to pitch our business model many times and explain how money flows from the consumer to the winemaker, depending on the chosen sale channel.\nLet’s consider a bottle priced at $24 in a retail bottle-shop. Of course, this example can be scaled up (higher-end bottles) or scaled-down, but, we decided to focus on this particular price segment because, in most countries, this is considered a “sweet spot” where consumers start to develop their taste for genuine wines and are ready to spend money on products they love. This is also a price that allows small wineries to generate some profits.\nThe four main channels for wine sales: Restaurants: In most countries, wine bought in a restaurant is clearly more expensive. Depending on the country, the price point can vary between twice (lucky you!) and five times the retail price.\nRetail/bottle shops: Industrial wines are mainly distributed through this channel. In the retail world, our $24 bottle of wine will travel through the hands of various intermediaries such as an exporter, a wholesaler, a distributor and the bottle shop.\nCellar door/Tasting room sales: These sales happen on site, at the winery and, more often than not, during a tasting (for tourists) or some other event. This is the best possible experience for consumers because they can ask questions about the wine and meet with the winemaker or a trained staff member.\nWine Clubs: Wineries use wine clubs to create a special relationship with trusted customers. They can ship wines to their most trusted customers on a recurring basis (usually once or twice a year).\nFor each sales channel, we have represented the value chain and focused on the profits that will flow back to the winery.\nThe gory details (money!) Value chain of one bottle depending on the sales channel.\nBenoit. I find your foregoing diagram a little confusing. Why would the green sections be different in any of the examples? Are you confusing % with $?\nCash-flow There is a huge profit difference (roughly 800%) for winemakers between direct and indirect sales channels. That being said, one must also consider the risks and cash-flow impact of each channel.\nThe two indirect channels, namely wholesale and restaurant sales, produce small profit margins and can negatively impact cash-flow, since it can take between 45 and 90 days for the winemaker to receive payment. In the two direct channel models, the winemaker is paid up front and this has a great positive impact on any business. Business Risks: The indirect sales channels are highly dependent on a few key clients. Risks are high because if, for example, a wholesaler suddenly decides to stop distributing a winery’s wines, this winery loses a huge part of its revenues and may find itself in a difficult, if not dangerous financial situation. Without a fresh injection of cash, it may have to declare bankruptcy or slash the price of its products. Most wineries are warned by their accountant that it is always risky from a business perspective to have just a few big customers that account for 30% or more of their revenues. The direct sales channels have a different risk profile. Hundreds of individuals constitute the client base. As such, the risk is more evenly spread and variations in volume and in sales are more stable and even predictable, based on industry data and, in the case of tasting rooms/cellar doors sales, on weather and traffic data. Recurring revenues Recurring revenues are worth 5 to 10 times one-time revenues. How do these sales channels compare to each other?\nRestaurant channels are quite hard to plan for. Restaurants must adapt to changing client taste. The volume of their wine purchases is also highly dependent on the sommelier goodwill and desire to promote the winery’s brand. Wholesalers usually sign multi-year contracts with various options and clauses that allow for extra purchases of the same wine (at a lower cost as the volume increases). As such, these bulks purchases can be considered recurring revenues. But keep in mind that, as the part of the production sold to the wholesaler grows, the wholesaler increases his bargaining power over the winery and can ask for bigger discounts, which lowers the winery’s profit margin. Cellar door/tasting room sales: Sales are, most of the time, a one-time occurrence. They depend on tourism and the events happening at the winery. They have a high cost because cellar visits and tastings must be handled by a highly trained wine tasting and customer service staff. Most wineries make a determined effort to convert these one-time customers into long-term wine club members. Club membership: Members are people who are won over by the quality of the products and who have a great memory of their time at the winery. They quite often agree to provide their credit card information and, at least, commit to buy on a regular basis wines from the winery. Club members are very trustworthy and loyal. They are a winery’s best customers! No wholesale for boutique and small wineries To complete this description of the sales channels accessible to wineries, I would like to quote the following words from Silicon Valley Bank’s Rob MacMillan:\nWholesalers don’t want small wineries. Distribution isn’t available for most wineries, so they have to elect more Direct to Consumer options. […] Most wineries will not survive without an increasing emphasis on direct-to-consumer sales.\nConclusion Subscribility has been designed, from the ground up, by boutique winemakers to help them set up and grow their direct to consumer sales channels. As wine-lovers ourselves, we make every possible effort to ensure that the best authentic wines are still produced and are able to reach wine-lovers’ palates, thanks to the only channel available to each winery: the Direct-to-Consumer approach.\nSelf-reflection: What can be done to help boutique wineries reach their market? Why has eCommerce not yet impacted the wine industry? Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/value-chain-in-the-wine-industry/","tags":["Value Chain","Wine","DTC"],"title":"Value chain in the wine Industry"},{"categories":null,"contents":"How to start a wine club A wine club is a membership based club where members get special offers of wine. A wine club can be a direct wine club: in this case, it is operated by a vineyard and usually offers only wine produced by the vineyard. Indirect wine clubs can be run by anyone, from a bottle-shop to a wine importer. They normally do not project the impression that they produce wine, but select wines for their members from 3rd party wineries. Some of these clubs are vertically integrated and actually do make wine and/or have wine made for them under contract.\nIn the original wine club concept, there were no options for the members. They would commit and buy in advance a certain number of bottles per period. Bottles were then invoiced and then shipped directly to the member’s doorsteps. This is termed “continuity marketing”. Continuity marketing has the advantage that the marketing expense occurs only once — at the customer acquisition stage. From then on, each sale bears no to little marketing cost.\nToday,due to customer demands, wine clubs tend to be more flexible. Here are some examples of wine club strategies:\nThe “no wine club”: a lot like a newsletter, but with a clear call to action. Periodically, the winery sends special offers to its members who can, with a single click, buy their wines. This could be termed “mailing list sales”.\nThe very open wine club has a small commitment, like buying 2 bottles of Semillon each year. When the time comes to ship the wine, members are notified and can choose to add products (in general with a club membership rebate). The original wine club continuity concept: in which the wines, the quantity and when they will be shipped are all fixed. For example, members commit to buying a case of 6 bottle of Sangiovese yearly, and a case of Chardonnay 6 months later. These are only a few of the current marketing strategies. Of course, you can decide on any strategy for your wine club, either very open (like the “mailing list sales” approach) or more strict. You can also run more than one wine club delivery plan.\nOf course, while this article is centered around wineries and wine club, there are also micro-breweries and distilleries that employ exactly the same tools to serve their best customers.\nWhy start a wine club now? Wine clubs bring many benefits to wineries. They are part of the Direct To Consumer trend. No intermediaries between you and the customer. Each fulfilled order results in much higher profit per bottle. If your members trust you to hold their credit card on file, this becomes a very attractive proposition.\n“The average wine club member buys almost seven bottles of wine when visiting a cellar door and spends almost $65 more per visit than the non-club member.”— Wine Australia Research and Development, March 2014\n4 Steps to setting up your wine club 1. Define your club policies\nWhile you can run more than one wine club plan, let’s start with one!Start with a simple sets of rules, inspired from the examples aboves. Start with simple and easy to understand for you, your members and your staff.\n2. Launch your club\nTo promote your club, you need to publicize the benefits of the club to your members. Use every possible channel: Newsletter (email list), your cellar door, website, social networks… Simply spread the word by highlighting the benefits of your wine club to your audience.\nMost wine club management software allows you to set up your club policies and will handle most operations for you. Most of them a quite prescriptive and force winemakers to operate using some fixed processes or policies.\nSubscribility, our cloud based solution, has been designed by winemakers for winemakers. It offers great flexibility and you can manage your club and wine plans according to your wishes and dreams.\nSubscribility also comes with tools that let your customers sign up and manage their shipments online.\n3. Operate your club\nIn practice, your club starts the day you will sign up…one active member! Your first members are the most important and you will remember them for life. There is an old saying in direct marketing, “the best fish are caught first”!\nCompared to one-time customers, your members seek a more engaging relationship with your winery. They trust you to produce, year after year, great quality wine. In exchange, you have to take good care of them. Offer them some special treatment: private activities (luncheon, private tasting, harvests,…), discounts or even exclusive products. In fact, by definition, your most loyal members do not need discounts — it is better to reward them with special wines, gourmet food or maybe complimentary nights in your B\u0026amp;B if you have one.\n(Four Winds Vineyards)[http://fourwindsvineyard.com.au/] are wine club champs. They know how to make their members feel welcome.\nA “club run” happens when you send a case of your wines (or more!) to all your members. With large clubs and without specialized software, this can be a daunting process. Processing credit cards manually, chasing after missing/invalid/expired credit cards, contacting the members, printing labels…\nAs soon as your club reaches 40 or more members, automation is needed: think automatic renewal of credit cards, automatically generated shipping labels and a link with your carrier, SMS message to your members to inform them about the shipping of their order, etc…\nWhatever tool you use, make sure you honor your policies and ship any order for your club members on time. These happy customers will most likely buy again from you. Since they have trusted you with their credit card details, make sure they receive first class treatment!\n4. Adjust your club\nAs time passes, you will become more and more accustomed to the requests of your members. While it is difficult to accommodate them all, you should use individual requests to define new club plans.\nFor instance, some of your members would like to have only red wine. As soon as you have 5–10 of these members, you can now start a “red” wine continuity plan. Some other members would like to buy 2 cases of 12 bottles a year. You can now create a 24 pack plan!\nFor some smaller wineries it is easier to run multiple small plans, each delivering orders to members at various times during the year, than to operate a very large plan.\nWith this in mind, you will be able to fulfil your members’ needs and keep happy members for life — but don’t be disappointed if “life” means 3 years or less as the average attrition from wine club plans is around 33% per year. People get bored with similar wine, so if you can retain them by giving them more variety, fall over yourself to do so! Surprise and delight them occasionally with a free gift. (But be careful not to build a pattern which promotes expectancy). Talking to them often with interesting relevant news also helps retain their interest.\nConclusion While starting a wine club can be intimidating, it is a very rewarding activity both for the winery and the members.\nCreating a wine club is the start of a loyalty program: you acknowledge that certain customers (the members) are entitled to greater benefits and a deeper relationship with your winery.\nTransforming one time consumers into long time members will allow you to focus on the products and activities that have the most impact. It will improve your knowledge of your best customers, increase revenues (imagine having 80% of your production already sold!), improve profit and improve your cash flow (each wine plan run brings steady revenues at a fixed date).\nBenoît des Ligneris, Ph. D.Chief Growth OfficerSubscribility : Wine club, cellar door, ecommerce management made easy\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/how-to-start-a-wine-club/","tags":["How-to","DTC","Wine"],"title":"How to start a wine club"},{"categories":null,"contents":"Direct To Consumer (DTC) is a major trend worldwide.\nDTC affects or will affect every area of our lives.\nAuthors interact directly with their readers and, often, blog then self-edit their book. Brands often offer a way to buy online, competing with their distributors. TV will either bypass the distributors and move online or die (because of Netflix). Car manufacturer Tesla only sells direct. IKEA furniture company won a sector leadership position by relying only on DTC. Apple computers are available online or in lovely designed Apple stores owned by Apple.\nThese are only a few examples from various industries. It proves that in many sectors, intermediaries are under duress. Layer after layer of intermediaries are put out of business on a daily basis.\nWhat is DTC ? DTC is the leanest business model: One producer and one buyer connected.\nNo intermediary, no fuss.\nSimple and elegant.\nSchematic of the DTC model vs the multi-tier distribution model for wine\nBonuses :\nthe producer (or brand) can now converse with the consumer; The consumer, thirsty for new information, can learn the brand story; The advanced consumer can now influence the future products \u0026amp; services. Often, DTC relies heavily on direct referrals. Your own customers help you find new customers by sharing your story, sometimes for a perk or benefit.\nThink about it: Who do you trust more: a friend or an ad ?A recent Forrester study found that 70% of the consumers trust brand recommendation from friends.\nWine. Why wine ? The current distribution model for wineries is a multi tiered system. To find a distributor wineries have to rely on an agent. The agent then looks for a distributor. The distributor then distributes or exports their unique product.\nThe wines end up in brick and mortar shops (another intermediary!). Each shop contains only a fraction of the wines produced worldwide at a high cost for the consumer.\nGrapes almost ready for harvest in the Hunter Valley (Australia 2016)\nAll in all, a winery’s revenue is often no more than 40% of the retail price. Make it 20% or less if the wine is sold internationally.\nThe consequence of the multi-tier distribution model is daunting.\nAs Cathy Huygue (Wine columnist @Forbes and Food52) points out in her blog, out of 8,287 wineries in the U.S., 30 of them represent almost 90% of the volume of wine sold domestically each year.\nWhat can a boutique, small or medium winery do about it ?\nBypass the legacy distribution system!\nBy selling their wine DTC, wineries take back the control of their brand. They have more control over the price and costs. This translates in higher revenue, much greater profit and better cash flow.\nOn the consumer’s side, DTC guarantees that they know what they are drinking. They are more capable of making an informed decision when picking a wine. No more guessing game at the bottle shop: a single visit on a search engine, Twitter, Instagram, Facebook or even a chat with a mate and they will have proof that the winery is legit, with real people and real story behind it.\nDTC is happening, even for large wineries. Rob McMillan, SVB on wine and author of the “State of the Industry wine report 2016” wrote : “Today the smaller producers absolutely could not live without direct sales, and when we say small in this context, we are talking about wineries with less than 100,000 in case sales.” (p38)\nImage from ShipCompliant 2016 report on DTC\nDTC is the leanest and simplest business model. We envision it as the principal growth channel for independent wineries. What are the key challenges (matter for future articles!) :\nRegulation: shipping nationally (US \u0026amp; Canada) is a challenge. International shipment is even more challenging : complexity, cost, time to the consumer, etc. Monopoly (state-based agency that control alcohol distribution in various states/provinces or countries) Quasi monopoly (private) of the distribution channel. Large international players own the low-end and industrial market. They will fight for their survival. IT : Many wine makers are of the Baby Boomer generation. They often see the winery as a down to earth activity where IT plays a secondary role. Independent winemakers have to gear up and become a complete self sufficient operation. They have to provide the ease of use and fulfillment capabilities of amazon. It means :\nacquire and set-up various cloud-based IT systems create a DTC brand make it thrive on the social networks engage with customers both in person (cellar door) and on the Internet DTC or die ? Many challenges await independent wine makers. The most complex and critical one is finding customers who love their unique product.\nWe have demonstrated, in this article, that the multi tiered distribution model can not help.\nThis distribution channel is already dominated by industry juggernauts. They control distribution, bottle-shops and have bought or built many industrial wineries. Their production capacity is superior to the demand for their industrial products. Moreover, this market segment is expected to shrink in the following years.\nThey have started to focus on boutique and medium wineries. Merger and acquisition for 2016 are expected to grow steadily.\nDTC shipment volume in the U.S from 2010 to 2015 — ShipCompliant 2016 report on DTC\nHowever, current and future consumers (millennials) rely more and more on friends, family and social reference to buy online. They look for authentic products and are ready to pay more for these.\nNow is a good time to be a boutique, small or medium winemaker.\nProviding one can tap into the DTC channels and fulfill customers expectations (online access, social interaction, easy to buy online, good fulfillment), genuine and authentic products will be able to compete head to head with premium wine and industry juggernaut.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/what-direct-to-consumer-dtc-represents-for-genuine-wine-makers/","tags":["DTC","Wine"],"title":"What Direct To Consumer represents for genuine wine makers"},{"categories":null,"contents":"📝 Comment Policy: Embrace Radical Optimism in Dialogue! Welcome to the comment section of Radical Optimist! We\u0026rsquo;re thrilled to have you join the conversation and contribute to our community of forward-thinkers. To maintain a space that embodies the ethos of radical optimism, we ask you to abide by these guidelines:\nElevate with Positivity: Let\u0026rsquo;s uplift one another with positivity and encouragement. Share your thoughts, ideas, and perspectives in a spirit of optimism and hopefulness. Constructive Engagement: Engage in constructive dialogue that fosters growth and understanding. Offer thoughtful insights, ask questions, and provide constructive feedback to enrich the conversation. Stay Aligned with Our Vision: Keep your comments aligned with the values of radical optimism. We celebrate innovation, progress, and solutions-oriented thinking that inspires positive change. Respectful Interaction: Treat fellow commenters with respect, empathy, and kindness. Embrace diverse viewpoints and engage in respectful discourse, even in disagreement. Focus on Solutions: Let\u0026rsquo;s focus on solutions rather than dwelling on problems. Share ideas and strategies that empower individuals and communities to create positive impact. Authentic Engagement: Be authentic and genuine in your interactions. Use your real identity or a consistent pseudonym when commenting to foster trust and authenticity within our community. Moderation: Comments are moderated to uphold our commitment to radical optimism and ensure a safe, welcoming environment for all participants. Comments that violate these guidelines may be edited or removed. Together, let\u0026rsquo;s cultivate a culture of radical optimism where every voice is valued, and every contribution propels us toward a brighter future!\n🌟 Keep shining bright, Radical Optimist! 🌟 ","permalink":"//localhost:1313/en/comment-policy/","tags":[],"title":"Comment Policy"},{"categories":null,"contents":"Here is how you can reach me (your choice):\nOption 1: LinkedIn LinkedIn Option 2: Contact form Your Name Email Address An email address is required. Message ","permalink":"//localhost:1313/en/contact/","tags":null,"title":"Contact me"},{"categories":null,"contents":"Option 1: LinkedIn You can find more details on my LinkedIn Profile\nOption 2: Here is my up to date summary in pdf You can also download it below.\nPrevious Next \u0026nbsp; \u0026nbsp; / [pdf] View the PDF file here. ","permalink":"//localhost:1313/en/resume/","tags":[],"title":"Resume"},{"categories":null,"contents":"Search Provided by a great library Thanks PageFind.app for the extraordinary integration.\n","permalink":"//localhost:1313/en/search/","tags":null,"title":"Search the Site"},{"categories":null,"contents":"I offer fractional services (CPO, CTO or CPTO) for start-ups and scale-ups having either a punctual need or who want to work long-term with me.\nI take an active role with the leadership team (CEO, CFO, founders, etc.) to deliver value. Given my background, I can operate as a fractional CTO/CPO or both. Fractional means that I have all the active responsibilties of a regular employee including a managerial role (hiring, promoting, firing) depending on the size of the team.\nOption 1: Book a meeting with me and let\u0026rsquo;s discuss! Book a meeting with me Option 2: Explain your needs and let\u0026rsquo;s get in touch Your Name Email Address An email address is required. Message ","permalink":"//localhost:1313/en/service/","tags":null,"title":"Service"},{"categories":null,"contents":" The Pyramid of the Product Manager Needs\nA mental model started to emerge as I was trying to represent the product manager role in a similar way to the Maslow hierarchy of needs for human beings.\nLike any mental model, it is sometimes useful and wrong most of the time.\nThis representation and the corresponding layered approach can provide useful guidance to fellow product managers and leaders regarding the scope and role of the product management organization. Its main merit is to represent the product management role as something easy to explain visually. The model is not the result of a broad statistical analysis but based on contemporary product manager literacy and my experiences.\nDescriptions of each level: The real-world/Ecosystem. Whatever your product is, you have customers, partners, competitors, countries and the overall human society where your product operates. They all interact with your product. The impact you have in the world is all about change: how does your product change people’s lives? Interactions go in the other direction, too: how does your customer expectations change your product strategy and direction? Human need analogy: This is the Physiological layer. This layer represents the most basic need for a product. A human being needs food, water, sleep, shelter. A product needs market share, customers, partners and competitors. It can be the most stressful aspect of working in a start-up or funding one: you need to figure out this as fast as possible and with a minimal budget and super-short timeframe. The product artifacts: Once you have customers, you interact with them via some real-life product artifacts, processes and tools. For instance the user stories, the code, the servers running the code. It also includes the documentation, the video tutorials, the go-to-market efforts and strategy, all the blog posts. Anything that the ecosystem (Blue layer) interacts with to use the product is part of this layer. Human need analogy: Unless you are in a pre-MVP start-up, your product materializes itself in the real world. Your product is a collection of real-world artifacts. Very much like most of us need a home, some money every month and good health, so do a product manager. He needs some real-world artifacts in good-enough conditions to interact with the world. These artifacts define the user experience. The product team: This is the close-knit team that builds the artifacts used to evolve the product (green layer). Ideally, this is a cross-disciplinary team working closely together in an iterative/agile kind of way. Ideally, they work in the same physical space to increase collaboration. Culture and rituals are essential here: A safe culture is required for such teams to exist and operate efficiently. The group tends to operate in weekly / bi-weekly cadence. Human need analogy: This one is almost identical. We all need to have some form of social belonging. As a social mammal, your team is who you are! As a product manager without authority, this can be challenging. To be a great product manager, you need to be a great team player. Tell the truth (don’t try to sugarcoat it!), lead by example, stop wishing for control and remove your ego from the equation. If you look at data, you will spend far more time with your team than with your closest family: make it count and enjoy the ride! The Stakeholders: Every product manager has one or more stakeholders. They are the ones that guide and can stop the product evolution by reallocating resources to another product area. Their main concern is the resources. Most of the organizations with product managers are smart enough to let the product team operate with lots of autonomy. Constraints are part of life. Stakeholders’ leading role is to connect the high-level expected outcomes (see layer 5, strategy) with the product team. They tend to think in months and quarters and value more the relationship and long-term success over shorter outputs and objectives. Their goal is to align the overall company mission and vision with the resources they have: what can we do to impact most of our key results? Which team should have more resources this quarter and in which order should we deliver value. Human need analogy: Your stakeholders help you define what is good or bad. As such, they help you strive as a human being or be miserable. That is why a product manager needs to choose a company and a product line which goals and values reflect your own. As a product manager, you can decide who you work with and why. Success definition change with each conversation and is a never-ending story. The leadership (C-Level \u0026amp; Senior leadership): Their primary focus is strategy and future positioning of the organization. They need to anticipate the changes in the ecosystem layer (the real world). They research new trends that could affect the organization, bet on future ideas, products and tools for which the market is far from certain. They also prioritize products that are not market-ready, with lots of ambiguity and knowledge gaps. In a way, they shape-up the future of the organization by making short, medium and long term bets. They are betting on investments and projects that could be highly rewarding but could be very risky. By clarifying the vision, mission, they highlight the culture and product changes required to reach this vision. From time to time, out of personal interest (past career) or when stakes are high, it is quite common for them to provide direct feedback to the product team. This is done directly, without an intermediary. Direct feedback is way more efficient and less ambiguous than indirect feedback, especially because it necessarily involves ego, feeling and politics. Human need analogy: This is the 25 000 feet view of the world. Let’s assume that you master and manage to work efficiently with all the other layers. At a personal level, the company vision, mission and day to day decisions could clash with your personal values. They can also mitigate you by confirming that you are contributing to the best possible cause for you. Another way to look at it is that you can only realize your dreams if the organization you work for share the same dreams. Why such a mental model, what can I use it for? This pyramid of needs can have multiple uses. Here are some key examples:\nWhatever the size of your organization is, as a PM, you have to make sure every layer is covered and that the various actors understand their role. For a start-up, this will help separate the founder\u0026rsquo;s role from day to day activities. For a larger organization, it could be helping managers to better understand their role and help align the product teams with the company vision. Any unmet need in the pyramid will create irreversible damage to your product and endeavour. From a professional development point of view, we may have blind spots and activities we do not enjoy or are less proficient at (also called weakness!). As a product manager, you own your own development. Please make sure you understand, care and know-how to interact with each layer of the pyramid. If not, your product is in trouble. There is no shortcut to impact: as a product manager, you are responsible for all of it! Efficient influence: you have to understand how to influence each of the layers of the pyramids. Each layer is unique and does not share the same view of the world like you. To communicate and influence efficiently, you need to adapt your message and adapt all your communications to the targeted audience. At the cross-functional team level (the crafters/doers), your primary role is to mediate and, more often than not, translate for the team your knowledge of all the layers. You are in charge of maintaining a learning environment where all the pieces of information (from all layers) are shared and updated regularly (daily and weekly or bi-weekly agile rituals). If you are the only one to know, your team is in big trouble. At the Objective and key result (OKR) level, you can correlate the various levels to OKRs. Company level, Product Line level and team level.Update: Please see the Pyramid of Product Manager Need: OKR blog post. Conclusion In this model, the product manager is a mediator between the different constituents of the product manager pyramid of needs.\nIt explains why product managers have to be lifelong learners. Curiosity and an avid quest for knowledge are key to gather the information required for products to succeed and become valuable, usable and feasible.\nIn follow-up posts, we will continue to explore this model both in a practical way (how to use the product manager pyramid of need to become a better product manager every day) as well as in a more holistic approach (the various product management careers, the product management org, small organizations vs large ones, personal happiness and affinity with the organization mission, etc.).\nFollow-up posts: Pyramid of product manager needs: OKR. Thanks An initial question inspired this article by Ben Mosior in the PMHQ community.\nFeedback is a gift 🙏: Please do not hesitate to share your thoughtsts Two ways to share your thoughts with me: via the contact page form via a LinkedIn connexion or message ","permalink":"//localhost:1313/en/post/the-pyramid-of-the-product-manager-needs-maslow-inspired/","tags":["Product Manager","Leadership","Essay","Mental Model"],"title":"The pyramid of the product manager needs (Maslow inspired)"}]