Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Presented at Ford's 2017 Global IT Learning Summit (GLITS)
Similar a Presented at Ford's 2017 Global IT Learning Summit (GLITS) (20)
Último
Último (20)
Presented at Ford's 2017 Global IT Learning Summit (GLITS)
- 1. Discovery and Delivery in Product Organizations SEPTEMBER 28 TH 2017
- 2. Why the hype on Product Management? 2
- 3. What Is Product Management? • ProdBOK Definition – It is the process of Conceiving, Planning, Developing, Testing, Launching, Delivering & Withdrawing products in the market. 3 Product Management is a critical discipline, but it’s widely misunderstood nature leads many organizations straight into “The Build Trap.” These organizations are so focused on building and shipping software that they forget to ask the core question behind great Product Management – “Are we building a valuable product?” - Melissa Perri founder of Product Institute Brainmates Product Management Framework
- 4. How do we build valuable products? It is not possible to build valuable products without doing both Product Discovery & Product Delivery. Discovery relates to all the activities we do around deciding what we should build. Discovery work focuses on fast learning and validation Delivery relates to all the activities we do around creating actual value to our customers. Development work focuses on predictability and quality Product Discovery is best understood in it’s relation to product delivery. 4
- 5. Product Delivery • Product Delivery can be tied to the Ford IT Objective “Confidential” • We all do Product Delivery albeit differently. Some do it once in two weeks, some once a week and some every day. • Frequent Release of Value - Tectonic shift from couple of years back: Once every six months or quarter. • Teams can easily evaluate delivery practices and set a goal in mind. This provides a yardstick to measure delivery and is most commonly understood in teams. 5 https://www.codeproject.com/KB/architecture/1064114/w5.gif
- 6. Product Discovery • Product Discovery can be tied to the Ford IT Objectives of “Confidential. • So what is discovery and what is our yardstick to measure discovery? 6
- 7. Product Discovery Goals 1. Clarity of purpose and alignment • Agree on the specific problem • Visualize user or customers • Create success metrics 2. Identify the big risks that will need to be tackled during the discovery work • What we do? Gravitate towards comfortable risk – Technology Risk • What we should do? Consider value risk Do the customers actually want this particular problem solved? Is our proposed solution good enough to get people to switch from what they have now? Source - https://svpg.com/planning-product-discovery/ 7 Do we need to be extremely conservative and test every assumption?
- 8. Traditional Discovery • Spend time gathering requirements • Create a document of initiatives. Most likely a PRD or MRD which are vague. • Team ranks initiatives and send them off to the development team to build. • Periodically tell the business what we were building. • Launch products and wait for products to be used to know if it was a success or failure. Underlying Assumption: • We know our customers • We are the experts • We are probably right. 8
- 9. How to avoid flops • The frustration of waterfall requirements is addressed by Agile. • Agile History: In 2001, 17 software developers met at the Snowbird resort in Utah to discuss lightweight development methods and published the Manifesto for Agile Software Development. • Agile practices help teams build in batch sizes for immediate feedback & evaluation. But!!! Agile doesn’t have a brain Agile helps us build software right, NOT necessarily the right software 9 http://www.jeffgothelf.com/blog/agile-doesnt-have-a-brain/
- 10. How to build “Right” Products • To build the right product, teams take a step back and Instead of starting with “what should we build next?,” they lead with “what are our customers experiencing?” • This is the core of Product discovery that helps you know your customer and the product they need even before you build anything. • Product teams experiment their way to viable solutions by putting customers first, taking the time to discover unmet needs, and developing solutions that address those needs. 10https://i0.wp.com/faithx.net/wp-content/uploads/2018/01/Jan18_2018.png?ssl=1http://www.mike-dixon.com/wp-content/uploads/2012/03/startup-feedback-loop1.png
- 11. What tools can I use? 11
- 12. What tools can I use? 12 The answer is MANY!!! GOAL 1. Am I using the tool to solve the right problem 2. Learn FAST 3. Be Flexible This is the “yardstick” for Product Discovery
- 13. Is there a structure? Teresa Torres in Modern Product Discovery offers a visual aid called the “Opportunity Solution Tree” to help teams work and make better product decisions by Understanding Your Customers, Experimenting and Measure Impact. There are four sections to the tree: 1: Good product discovery starts with a clear desired outcome. 2: Opportunities should emerge from generative research. 3: Solutions can and should come from everywhere (as long as they are bounded by an opportunity). 4: Experiment to evaluate and evolve your solutions. 13 Teresa Torres www.ProductTalk.org @ttorres An Introduction to Modern Product Discovery
- 14. Opportunity Solution Tree “If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” ~ Albert Einstein • Helps to NOT start with the solution. • The Opportunity tree helps create a metrics driven culture. • Helps define a clear Desired Outcome by quantifying it – “Increase by X%” • Helps discover Opportunities to drive that desired outcome. • Discover solutions that deliver on these opportunities. • Iteratively test and see if the solution delivers on the opportunity. Why Experiment? • Our customers are the experts, we are probably wrong so experiment on the solution. • Add investment based on the data from experimentation. 14 The end result of everything we do should always meets the desired outcome.
- 15. Example: Opportunity Solution Tree • Step 1: Define a really clear desired outcome. Sample Tool: OKRs (Objectives & Key Results). OKRs are a qualitative objective, combined with quantitative key results. Objective: Increase signup conversion rate on landing page. Key Result: Increase signups by 25% • Step 2: Discover Opportunities. Sample Tool: Jobs-To-Be-Done. A tool to understand “What job your product is hired to do?”. Henry Ford didn’t think about the “job” as a “faster horse” but as “getting from Point A to Point B as quickly as possible.” Sample Opportunity: Help Customers know my product and signup. • Step 3: Evaluate Solutions. Sample Solution: Change the existing signup process. 15
- 16. Example: Opportunity Solution Tree • Step 4: Run Experiments. 16 Sample A/B test Actual A/B split test done by a Visual Website Optimizer customer Vendio, an Alibaba.com company. The page without the registration fields performed better – much better – to the tune of a 60% increase in conversions! breaking the so-called “best-practice” of embedding the signup form in the landing page itself. Desired Outcome: Customers Value + Business Benefit = Product Success
- 17. Product Discovery Challenges & Readiness? What Challenges do we face for Product Discovery? • We assume the future is predictable • We assume that given idea will work • We assume that the business knows best about the user needs and only run usability studies when business stakeholders disagree • We listen to what customers say rather than watching what customers do • We wrestle with how to maintain authority while giving their teams autonomy to discover and deliver the right product. Are we Ready for Product Discovery? Ask these questions to yourself • Do you work on a roadmap that lists features and dates? • Is your only idea of an experiment an A/B test or usability test that will act as a gate on release? • When was the last time you scrapped an idea because you learned through experimentation it wasn’t going to have the expected impact? Source : https://www.producttalk.org/2016/03/rise-modern-product-discovery/ 17
- 18. Summary • It is not possible to build great products without doing both Product Discovery & Product Delivery. • Product Discovery helps build the right software by leading with the question “what are our customers experiencing?” • Use the “Opportunity Solution Tree” as a framework to help make better product decisions by Understanding Your Customers, Experimenting and Measuring Impact. • The best teams are exploring many ideas on an ongoing basis, few of which end up worthy of pursuing • The end result of everything we do should always meets the desired outcome. 18
- 20. Resources • Teresa Torres - https://www.producttalk.org/ • Sachin Rekhi - http://www.sachinrekhi.com/ • Melissa Perri - https://melissaperri.com/ • Brainmates • Agile Manifesto • Article on OKR's • Article on Jobs-to-be-done-framework • Article on A/B testing 20
- 21. 21
Notas del editor
- A Product Driven Model provides the opportunity to put the IT Strategic Framework into action: Collaborate beyond our silos; promote team cohesion; build trust; and positively impact our Key Results. Have a bias for experimentation. Commit to this change, and prepare to empower our capabilities and unlock your potential.
- Start with the ProdBOK definition and note that the Brainmates framework gives a great lifecycle to understand this process. Move to the Melissa Perri quote. Apple watch example.
- What we do? Most tend to gravitate towards a particular type of risk that they might be most comfortable with – Technology Risk like Performance & Scalability or Usability Risk like change in workflow that needs some validation Question - Do we need to be extremely conservative and test every assumption? Use your discovery time and validation techniques for a significant risk, or where members of the team disagree realizing there’s a chance the team will occasionally be proven wrong for others
- Ask Audience – Does anyone know what product the image is? Answer: Microsoft Zune. Even though Microsoft had access to as much hardware development expertise as any company in the world and the capital to support a massive marketing budget the Zune was one of the biggest tech failures of the last decade. Robbie Bach, the former leader of Microsoft's home entertainment and mobile business, admitted that the Zune was too little, too late, and that Microsoft never gave consumers a real clear reason to buy one instead of the market leading iPod.
- Closing Line: Agile practices (not a methodology as Agile is a mindset) tremendously help in product management.
- Build Slide Out… 1. We have tools on Design and design thinking that tell you not build for your stakeholders but to build for your customers. 2. The books on Lean Startup that takes asks the deeper question, “Are we building products that our customers want.” The Lean Startup is credited with coining the term “MVP” 3. JTBD framework which answers the question, “Are we solving the right problems for our customers”
- Tools on Human centered experiment driven product management & use of objectives and key results, or OKRs. Tools to run experiments that can help us test our assumptions. As you can see there are many tools available. Do not be overwhelmed with the tools in the market. New tools come out every year. The landscape is always changing. Goal of this presentation is not to present the tools but to help you see what tools ate out there and be familiar with them. In Product Discovery the goal is not to understand a particular tool. The Goal is to be flexible in adopting tools by evaluating if the tool is helping you learn fast about your customers and if the tool is helping you solve the customers problem. Details of the methodologies and tools do not matter and it is not about one tool vs the other or one methodology vs the other. The end result of these tools should be that our practices becomes better.
- Opening Line: So as we saw the goal of Product Discovery is to learn fast. In the number of tools available teams may know all the tools and end up not using anything or use everything. Product team should know what tool to use, what is right and when to use the tool. In order to know how to apply these tools and understand if they are effective it is important to have a structure else we may spend too much time just in a tool and never get to other stages of product discovery. So is there a structure? Build slide out… The Opportunity tree is based on “The Decision Tree Method”. Decision trees have always been used in the analysis of complex decsions with significant uncertainty and is one of the tools used in Product Manufacturing Decisions where a calculated expected value are used as decision criterion (Background in Industrial Engineering referenced here with Decision Analysis as favorite subject). Teresa used this tree to illustrate connectivity among Product Discovery Stages.
- Refrain from starting on solutions first. Avoid brainstorming. Opportunities uncover customer pain points. Initiatives emerge from a deep understanding of the customer. This starts with us developing deep empathy and knowledge of our customers. We should close the gap between what the customer knows and what we think we know. Opportunity space is where product strategy happens. It is where we differentiate ourselves from our customers. Product teams should use the company’s mission, vision and strategy as a filter. Refer Archetypes. We should always ask, Does the solution deliver on the opportunity in a way that drives our desired outcome? Because even if we solved the problem for the customer, but it doesn’t increase their engagement, we didn’t actually create value for our business. Closing Line: Tools may change but the structure of the opportunity tree may not change.
- Go through steps fast as this is just an example and not intended as a model for participants to follows verbatim.
- The purpose of the example is not to discuss the tools themselves but to understand how to put the tools into context within the Opportunity Solution Tree. So if I think about this, OKRs are helping me set a desired outcome, and my whole team knows what the end goal is. What we are trying to accomplish together. Whereas Jobs-to- be-Done is helping the team with opportunity finding because we are doing observations, and communicating with our customers, we are learning how to live in their world. The next level helps us look at usability testing and look at MVPs and helps us test if our solutions deliver on our desired outcomes. The key message is that these specific tools are awesome. If you are not familiar with them, I recommend you learn about them, however the more important message is that not to get fixated or dogmatic on the tools but understand that all these tools should lead to driving desired outcomes and that is the key takeaway.
- We assume the future is predictable by developing feature-based roadmaps rather than using themes, opportunity backlogs, or goal-driven roadmaps. We assume that the business knows best about the user needs and only run usability studies when business stakeholders disagree Feedback reduces along the way Challenges: We Struggle between the prescriptive control of the traditional method vs. the emergent strategy of the more modern discovery Roadmap - Our goal shouldn’t be to hit our commitments. It should be to deliver value. If we learn that an idea isn’t working, we should have the freedom to scrap it and move on to the next best thing. Fixed feature lists don’t allow us to do that with ease When was the last time idea was scrapped - If the answer is never, there is no chance you are doing modern discovery. If the answer is more than a month ago, then you aren’t doing continuous discovery. The best teams are exploring many ideas on an ongoing basis, few of which end up worthy of pursuing.
- Now that we know how to build great Product let us avoid some pitfalls - Don’t be the Seinfeld Cabinet Guy.
- Now that we know how to build great Product let us avoid some pitfalls - Don’t be the Seinfeld Cabinet Guy.