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
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
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
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
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.