- [History of product mgmt](https://medium.com/@paulcpto/product-strategy-the-new-toolset-8e8e3d49e719) - [[Product at Ubisoft]] - [[Product at Sqreen]] ## Opportunity Backlog Framework Resources: https://svpg.com/the-opportunity-backlog/, https://svpg.com/time-boxing-product-discovery/, https://medium.com/think-like-a-designer/the-opportunity-backlog-framework-a-user-focused-alternative-to-the-product-roadmap-145cb4df596c, https://medium.com/think-like-a-designer/how-to-write-effective-problem-statements-deliver-products-that-matter-2618aee9e538, https://medium.com/noé-product-management/what-i-learnt-about-user-research-67e7d3e189af To simplify, the product cycle includes two main phases: ![[product_double_diamond.png]] Simultaneously: - The **product discovery team** (product owner, lead designer and lead engineer) **works in product discovery,** **using the opportunity backlog**, to come up with the product backlog (steps 1, 2, 3) - and the **delivery team** is **shipping the backlog** (step 4) Definitions: - **Opportunity Backlog** = prioritized set of opportunities for the product discovery team to explore. Its output is the product backlog. - **Product Backlog** = prioritized set of work (usually represented as user stories and prototypes) for the delivery team. [[Product backlog management]] ### The Framework - Why [opportunity backlog > product roadmap](https://medium.com/think-like-a-designer/the-opportunity-backlog-framework-a-user-focused-alternative-to-the-product-roadmap-145cb4df596c) ![[product_jazz.png]] Product roadmap = classical music Opportunity backlog = jazz ![[product_opp_backlog.png]] #### 1. Define Problems Source: [How to Write Effective Problem Statements](https://medium.com/think-like-a-designer/the-opportunity-backlog-framework-a-user-focused-alternative-to-the-product-roadmap-145cb4df596c) ##### a) What's a Problem? > “If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” - Einstein > **Definition** In Mathematics: "an inquiry to investigate or demonstrate a fact, result, or law." Similar to [Job To Be Done's view](https://strategyn.com/jobs-to-be-done/customer-centered-innovation-map/) on problems **Examples** Problems can be large: Have enough aside for retirement. Problems can be small: I can’t find the Submit button. **Why use problem statements?** - Having a clearly stated user problem defines a mission for the team, building empathy for the end user and uniting team members around the purpose of designing solutions that will improve users’ lives - Most people get a sense of pride when helping others. Knowing that you’re working on a solution to someone’s problem makes the work you’re doing more rewarding and more enjoyable - How do you measure success when the goal is feature parity with the competition? What metrics do you track when the goal is to build a new widget because it’s the flavor of the week? If you know what the user problem is, the only metric that truly matters is how well the problem gets solved - Another critical benefit of starting with the problem is it opens the door to innovative thinking (and what organization isn’t dying for more innovation?). Truly understanding a problem and its root causes allow for a myriad of creative solutions that can be prototyped and tested with users ##### b) How to Identify Problems? **P - Firsthand > secondhand > thirdhand** 1. Firsthand: **feedback from your target audience** a.k.a. (and most importantly) **voice of the customer** 1. Interviews 2. User surveys 3. Usability tests 2. Secondhand: **from customer service and sales representatives** whose jobs consist of talking to customers 3. Thirdhand (assuming you already have a live product on the market): review **analytics** to identify potential issues (Ex: bounce rates, time spent, fall off in conversion funnels…) ##### c) How to Write a Problem Statement? When… *<context>* I want to… *<action>* So I can… *<goal>* But… *<problem>* **Example** When I’m about to run out of dog food I want to place an order for another bag So I can get it before my current supply runs out But my order probably won’t arrive in time. **P - Don't hint at solutions** Problem statements articulate problems. If you’re hinting at a solution in the problem statement, you’re doing it wrong. **P - Validate problem statements with users** Have users read it! And ask: “Do you agree with this statement?” and “Do you see yourself in this statement?” #### 2. Describe the Opportunity > How might we… > **Example** How might we help customers make sure their orders arrive before they run out of their current supply? **P - (in product discovery meetings,) always reference the problem statement to:** - Make sure everyone agrees it’s still a problem worth solving - And uses the problem as a benchmark for the work that’s being done. #### 3. Ideate Hypotheses > We believe (doing)… For… Will achieve… > **Example** We believe a monthly auto-shipped pet food subscription For our customers who forget to re-order their supply Will achieve a consistent and reliable supply of food, ensuring pet owners don’t run out. **Ideate!** Example: Instead of a pet food subscription, maybe the solution could be a scale or container that weighs the amount of food and alerts the pet owner or auto-orders more when the supply gets low. Maybe it’s building more local warehouses across the country to store and deliver food faster. **Prioritise** #### 4. Design Concepts **Minimum Viable Experiment** (MVE); i.e. something users can react to that most effectively tests the hypothesis (impact) with the least amount of effort for the product team to create (ease) **Example** For our pet food subscription hypothesis: monitor the click-rate of a marketing email promoting a new monthly pet food subscription sent to customers who are often placing last minute food orders. #### 5. Test and Validate Get user feedback. Did it help solve the user problem? Yes → graduate to the product backlog! No → next MVE ### Working the Opportunity Backlog #### Visibility Your opportunity backlog should be visible to: - Your entire team - Senior stakeholders - Other Product teams. It’s especially helpful to socialize user problems and hypotheses because there’s often overlap within organizations. Sharing the opportunity backlogs helps break down silos. #### Refinement Problem statements should be refined among the members of the Product team (or PO, Lead designer & Lead Engineer, see dual-track Scrum): 1. The statement effectively describes the problem 2. The problem is worth solving 3. Prioritize The more you work the backlog, the better the team will get at creating innovative solutions and delivering products that matter. #### Time-boxing Time-boxing is not the same as time-limiting. - **Time-limiting** (like Waterfall): schedule with 2-4 weeks of time to do “requirements and design” - **Time-boxing**: decide what to focus on in a given iteration, then work for that fixed period of time, and then reflect. Most of MVEs techniques are about validating in hours or days rather than delivery sprints (typically measured in weeks and months). Unless you’re working on hardware, good teams will explore and validate many iterations in a week (~3 days). Product discovery depends on establishing a rapid ideation/validation rhythm, and short duration time-boxing may help the team to move to this mindset! ## The Product Backlog & DEEP Framework List of all the work that needs to get done by delivery team: user stories , bugs, technical tasks… ### **DEEP framework** - **Detailed**: Sufficiently detailed such that any member of the scrum team can work on the user stories independently - **Emergent**: Flexible, work will fluctuate based on the needs of the team, business, or customer - **Estimated**: Size and complexity is estimated using story points — If a story comes with a high estimate it is likely large enough to break apart into more than one user story - **Prioritized**: User stories are ordered in the backlog based on product priority — If all stories in the sprint are completed early the team should pull in the next user story on the backlog. ### Refinement The backlog is periodically refined by PO and team: ensure 2-3 sprints ahead of work. Tips to organize refinement meetings: - Invite the whole team (UX, testers, etc.) - Priotitize User Stories - Have a reference US for estimates - Distribute US before the beginning of the session - Limit time per US with a timer. If discussion takes longer than estimated, go back and define the US better - Spend enough time - if you're starting out, couple of days to refine the backlog ### How to Prioritise a Product Backlog? > Formula: impact * reach / investment **P - Never use average scores** Force people to take a stand. Replace text input with single choice from a dropdown. Example: how many ideal customers does it impact? 1. None - 0 2. Few - 20 3. All - 100 **Reach** What % of Ideal Customer Profiles users does it affect? None, few, all. **Impact** Does it contribute to key clients' KPIs (List and score them)? No, a little, a lot. Does it help us sell? No, a little, a lot. **Ease** How long to develop? Hours, days, weeks ## 4 Stages of Team Progress https://tomtunguz.com/an-elegant-problem-will-larson.md/ As a manager, your obligation is to identify the correct system solution for a given transition, initiate that solution, and then support the team as best you can to create space for the solutions to work their magic. If you skip to supporting the team tactically before initiating the correct system solution, you’ll exhaust yourself with no promise of salvation. Teams want to climb from *falling behind* to *innovating*, while entropy drags them backward. Each state requires a different tactic. ![[3a Business/product_4stages.png]] Four stages of a team’s progress, from falling behind to innovating ### Falling behind A team is **falling behind if** each week their backlog is longer than it was the week before. Typically, people are working extremely hard but not making much progress, morale is low, and your users are vocally dissatisfied. Fix: - System: hire more people until the team moves into treading water - Caveat is **scale tax** - Don't reassign people (people aren't fungible, too political) - Tactical: provide support - Setting expectations with users - Beating the drum around the easy wins - Injecting optimism. ### Treading Water A team is **treading water if** they’re able to get their critical work done, but are not able to start paying down technical debt or begin major new projects. Morale is a bit higher, but people are still working hard, and your users may seem happier because they’ve learned that asking for help won’t go anywhere. Fix: - System: consolidate the team’s efforts to finish more things, and to reduce concurrent work until they’re able to begin repaying debt (*e.g.* limit work in progress) - Tactical: the focus here is on helping people transition from a personal view of productivity to a team view ### Repaying Debt A team is **repaying debt** when they’re able to start [paying down technical debt](https://firstround.com/review/forget-technical-debt-heres-how-to-build-technical-wealth/), and are beginning to benefit from the debt repayment snowball: each piece of debt you repay leads to more time to repay more debt. Fix: - System: add time to allow the compounding value of paying down technical debt to grow - Tactically: support users while repaying debt (don't switch technical debt for users' perspective) ### Innovating A team is **innovating** when their technical debt is sustainably low, morale is high, and the majority of work is satisfying new user needs. Fix: - Sytem: maintain enough slack in your team’s schedule that the team can build quality into their work - Tactical: ensure that the work your team is doing is valued ## Good PM Bad PM ### Mindest #### 'CEO of the Product' *vs.* Excuses Good PMs measures themselves in terms of the success of the product, responsible for right product/right time and all that entails: - Context: know the market, the product, the product line, the company and the competition - Execution: devising and executing a winning plan (no excuses). #### 'What' *vs.* 'how' Good PMs aren't project managers of the functions, they manage the product team: - Crisply define the 'what': gather information informally, communicate formally (in writing and verbally) - No time sucked up by the 'how': meeting minutes, sales support, engineering, design. #### Preparation *vs.* Reparation Leverage collaterals (FAQ, white papers…) to anticipate product flaws and take strong decisions instead of time lost extinguishing fire and bad omens. #### Value *vs.* Results - Focus the team on revenue and customers *vs.* features - Focus on best executable product *vs.* best product. #### Clarity *vs.* Obvious - Good PMs define their job and their success without being told what to do - Good PMs send their status reports in on time every week because they value discipline. ### Execution #### Prioritisation The secret is the **Three Buckets** framework: - **Metrics movers**: pay the bills, software that doesn't justify itself will lose the ability to fund itself (Ex: eBay was data-driven but failed to please customers) - Customer requests: if you don't listen to customers, they'll lose faith and hate you (you hate somebody that is successful and not helping you) - Delight: inspire passion and loyalty (Tim Cook : 'at Apple we believe people value surprise') Features don't have those, great products have : PM is about the arbitrage. #### Find the Heat 2 ways to boost engagement: - Lower friction - Increase desire (often overlooked by engineers!) Look for **magic 'Aha' moments** and reduce the time for people to have it when they use the software. #### Einstein's Razor Little different from Okam's razor: > Make things as simple as possible, but not simpler. Ex: iPhone kept the home button to keep a physical interface, like 'Home'. #### Obsess about Your Non-users Selection bias by all the data harnessed. - Think about what your company looks like to non-users - Increase virality to gain users touching your customers #### Solve the Product Maze backwards - Common product questions: - Should we build this? - When should we build this? - How should we build this? - Teams debate 'should' when the question should be 'when'. #### Know Your Superpowers - Software is a team sport: each function brings something critical and deserves respect - Product - frame the problem (half the work) with strategy/metrics - Design - visualise the possible choices - Engineering - show what's possible #### Don't Forget Values These are tools to get the job done, but don't forget your values to help people and make the world a better place. Resources: https://medium.com/nsquared-labs/user-stories-and-the-product-backlog-in-scrum-c87d36df4b96 ## The Product Backlog & DEEP Framework List of all the work that needs to get done by delivery team: User stories, bugs, technical tasks… ### DEEP Framework - **Detailed**: Sufficiently detailed such that any member of the scrum team can work on the user stories independently - **Emergent**: Flexible, work will fluctuate based on the needs of the team, business, or customer - **Estimated**: Size and complexity is estimated using story points — If a story comes with a high estimate it is likely large enough to break apart into more than one user story - **Prioritized**: User stories are ordered in the backlog based on product priority — If all stories in the sprint are completed early the team should pull in the next user story on the backlog. ### Refinement The backlog is periodically refined by PO and team: ensure 2-3 sprints ahead of work. Tips to organize refinement meetings: - Invite the whole team (UX, testers, etc.) - Priotitize User Stories - Have a reference US for estimates - Distribute US before the beginning of the session - Limit time per US with a timer. If discussion takes longer than estimated, go back and define the US better - Spend enough time - if you're starting out, couple of days to refine the backlog ### How to Prioritie a Product Backlog? > Formula: impact * reach / investment **Never use average scores**. It forces people to take a stand. Replace text input with single choice from a dropdown. Example: how many ideal customers does it impact? 1. None - 0 2. Few - 20 3. All - 100 - **Reach** - What % of Ideal Customer Profiles users does it affect? None, few, all. - **Impact** - Does it contribute to key clients' KPIs (List and score them)? No, a little, a lot. - Does it help us sell? No, a little, a lot. - **Ease** - How long to develop? Hours, days, weeks ## Product Opportunity Assessment https://svpg.com/assessing-product-opportunities/ 1. Exactly what problem will this solve? (value proposition) → most difficult to answer 2. For whom do we solve that problem? (target market) 3. How big is the opportunity? (market size) 4. What alternatives are out there? (competitive landscape) 5. Why are we best suited to pursue this? (our differentiator) 6. Why now? (market window) 7. How will we get this product to market? (go-to-market strategy) 8. How will we measure success/make money from this product? (metrics/revenue strategy) 9. What factors are critical to success? (solution requirements) 10. Given the above, what’s the recommendation? (go or no-go) ## Draft Notes ### Free Trials https://www.saastr.com/free-trial-not-checklist/ - Yes if you can - Can someone potentially deploy your app in minutes? - If they can, would it work well self-deployed? Or does it need a ton of data in it to work well and show value? - If it needs a ton of data, can a “demo org” adequately convey that value? I.e., could you prepopulate data and have the self-deployed app show well? - Would you yourself want a free trial first, before buying? - Would it add value to some of your customers, and increase conversions, if they could try on their own before they bought? https://tomtunguz.com/top-10-learnings-from-the-redpoint-free-trial-survey/ - Time and Usage Based Free Trials Convert Better. There are four ways to limit trial. - Usage: 500 of API calls, then upgrade. - Seats: first two seats free. - Time: 30 day trial. - Feature: upgrade for better security. - Time and Usage based trials have at least 2x the conversion rates. ### [[X-HEC]] Course on product/growth - Marty Cagan - Silicon Valley Product Group - MindTheProduct - The Black Box of Product - NPS - Ramen - Wootric - Dave McClure : AARRR - https://www.slideshare.net/amontcoudiol - Tooling - Tracking - segment - Analytics - G.Analytics, Mixpanel, Amplitude - BI Tools - chartio, tableau - Autre : FullStory, Maze.Design - Customer support : ZenDesk - General knowledge - Laws of UX - [Pageflows.com](http://Pageflows.com) - [Pttrns.com](http://Pttrns.com) - [Littlebigdetail.com](http://Littlebigdetail.com) ### Locomotive Prioritization Framework - Stage: Product spec > tech spec > to dev > doing > done > deployed > announced - Priority: TBD, high, normal, suspended, killed - Impact - What % of Idea Customer Profiles users does it affect? None, few, all. - Does it help us sell? No, a little, a lot. - Does it contribute to key clients' KPIs? - Ease: How long to develop? Hours, days, weeks