Product Success and Requirements by Cayan Dir
•Download as PPTX, PDF•
0 likes•104 views
In the presentation, Tcheilly Nunes, comes up with three takeaways that he believes are the key for a successful product: -Having way fewer meetings -Fostering healthy team debates -Making product decisions everyone understands
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Product Success and Requirements by Cayan Dir
Similar to Product Success and Requirements by Cayan Dir (20)
More from Product School
More from Product School (20)
Recently uploaded
Recently uploaded (20)
Product Success and Requirements by Cayan Dir
- 1. www.productschool.com What is Product Success by Cayan Dir of Product Engineering
- 2. FREE INVITE Join 23,000+ Product Managers on
- 3. COURSES Product Management Learn the skills you need to land a product manager job
- 4. COURSES Coding for Managers Build a website and gain the technical knowledge to lead software engineers
- 5. COURSES Data Analytics for Managers Learn the skills to understand web analytics, SQL and machine learning concepts
- 6. COURSES Digital Marketing for Managers Learn how to acquire more users and convert them into clients
- 7. COURSES Blockchain for Managers Learn how to trade cryptocurrencies and build products using the blockchain
- 9. This is a snapshot of the daily life of a product leader
- 10. Instructions for today’s lecture 1- PARTICIPATE! Don’t know? ASK! There is no right or wrong here. We are all learning, everyday. 2- LISTEN! You have an opinion and we respect it. BUT, Be kind, have courage, and share. We are here to learn and should respect others experience and point-of-view. 3- HAVE FUN! Agenda 6:30 - 6:45 pm -- Meet & Greet, Networking 6:45 - 7:15 pm -- Product Success? 7:15 - 7:45 pm – Writing Better Requirements 7:45 - 8:00 pm -- Q & A 8:00 - 8:30 pm -- Closing Remarks and Networking
- 11. Takeaways 1- PRODUCT DICTIONARY Learn how to apply some of the key product management concepts into building a roadmap that ‘speaks’ to any stakeholder of your project. 2- PRODUCT REQUIREMENTS DONE RIGHT Explore an easy and fun way to write a requirements document. 3- BACKLOG TRIMMING Learn how to create a ‘shared’ backlog where all stakeholders involved own the final product: A shared ‘theme-based’ roadmap.
- 12. hello! I am Tcheilly Nunes . . . and here is “What Product Success may Look Like” a.k.a writing a better requirements document
- 13. Product Dictionary Let’s level-set and understand what I mean by...
- 14. Stakeholders Product Requirements Document Minimal Viable Product
- 15. Stakeholders Executive Sponsor Executive Team, including your boss Product Lead Sales Team Align (and sell) your product vision to opportunities Finance Makes sure the product fits within the financial parameters and model of the company Legal Ensure your product is legally sound. Trademarks, competition, etc. Engineering Develop and test your product. Consumers Partners Market Analysts Professional Services Understand and support your product Marketing/Communications Promote and gather feedback on your product
- 16. Requirements
- 19. Product success? Existing Backlog Product Line Groups Product Requirements Current Development Near-future goals Shared vision of the final product
- 20. Start here VISION (PURPOSE) Why build this product 3 STRATEGY (VALUE PROPOSITION) How to build it and measure its success 2 YOUR PRODUCT (REQUIREMENTS) What to build (and OKRs) or not to build 1
- 21. Benefits of a Shared Product Requirements Strategic Debates Fewer meetings Shared ownership
- 22. The Product (Requirements) Tree Infrastructure The Foundation necessary to run digital products (Architecture) Core, Current features This is what the product looks like today. You consumers know of you because of it. New Feature branch A tailor-made version of your product to support one client request. New Feature branch Iterations of your product. Phases to release all of your original feature set. New Feature branch A new version of your product. Consumer feedback. New Feature branch Disruptive Technology or innovative ways to grow your product PRODUCT NAME Image credit: Kisspng
- 23. Ready to build your own? . . . . . . . . . . . . . . . . .
- 24. Credits Special thanks to all the people who helped me create this awesome presentation: ★ Cayan, LLC. ★ Presentation template by SlidesCarnival ★ Images by ProdPad, and Kisspng
- 25. www.productschool.com Part-time Product Management, Coding, Data, Digital Marketing and Blockchain courses in San Francisco, Silicon Valley, New York, Santa Monica, Los Angeles, Austin, Boston, Boulder, Chicago, Denver, Orange County, Seattle, Bellevue, Toronto, London and Online
Editor's Notes
- A product requirements document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do. A PRD should, however, generally avoid anticipating or defining how the product will do it in order to later allow interface designers and engineers to use their expertise to provide the optimal solution to the requirements. PRDs are most frequently written for software products, but can be used for any type of product and also for services. Typically, a PRD is created from a user's point-of-view by a user/client or a company's marketing department (in the latter case it may also be called Marketing Requirements Document (MRD)). The requirements are then analysed by a (potential) maker/supplier from a more technical point of view, broken down and detailed in a Functional Specification (sometimes also called Technical Requirements Document).
- A minimum viable product (MVP) is a concept from Lean Startup that stresses the impact of learning in new product development. Eric Ries, defined an MVP as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. This validated learning comes in the form of whether your customers will actually purchase your product. A key premise behind the idea of MVP is that you produce an actual product (which may be no more than a landing page, or a service with an appearance of automation, but which is fully manual behind the scenes) that you can offer to customers and observe their actual behavior with the product or service. Seeing what people actually do with respect to a product is much more reliable than asking people what they would do.
- B - Business Product Owner C - Consumer Feedback E - End User O - Organizational M - Market Research U - Understand Validation
- Existing Backlog Granular areas of focus Specific scope Specs & Design Less Flexible Near term Wide areas of focus Some flexibility Future High level and broad scope/flexible
- Vision and strategy are foundational pieces without which even a good product cannot withstand the weight of its market. The challenge, of course, is that vision, strategy, and product all have varying, and often fuzzy, time horizons — making it challenging to keep them aligned and actionable simultaneously. Most people don’t think hard enough about their “why” because it can be a deep and often uncomfortable exercise. But starting without a “why” is akin to taking a road trip without a ballpark destination in mind. While it can be exciting and adventurous at the outset, it can quickly devolve into aimless and painful wandering — especially if each founder has a different destination in mind. OKRs - Objectives and Key Results (Developed by Intel) Purpose: “What other than money do you want to achieve with your project?” Think about the customer segments you want to serve and why? What problem or jobs do you want to solve for them? Will solving these problems make a significant enough impact on their lives? What’s in it for you? If you know the deep reason why you do such thing, it is easier to look for opportunities that would match your “why”. You don’t force yourself to integrate/create/develop something that does not share your values. In the book Find Your Why, authors suggest to frame your “why” statement into this format: TO (your contribution) SO THAT (the impact of your contribution). Value proposition: it usually takes 3 years to get most ideas past product/market fit and into an early scaling phase which is about as far as we can meaningfully/truthfully attempt to forecast. Like your why, your hows also have qualitative, quantitative, and timeboxing components. Methodology to use (Agile) Gather consumer feedback before launch (focus group, free 30-day trial, etc.) Test, Test and test : This thought-process really shines at testing by using small and fast additive experiments using the build-measure-learn loop. But simply running experiments is not enough. You will need to prioritize your features/experiments based on where you are with respect to your roadmap, and continuously adjust your testing based on the learning feedback loop from your experiments and metrics. Product: Roadmap that reflects all of this.
- The Product Tree is an exercise that helps you visualize the growth of your product together. Get your team to add Post-It notes to branches (which represent product areas) to suggest new features and functionality. Once all the ideas are up, they’ll see what you see every day as a product manager: lots and lots of ideas that you can’t do all at once. Use this as a starting point to discuss what areas need should be prioritized first, and what can wait until later.