1:22 There's a tremendous difference between how most companies work and how the best companies work 2:59 I wanna try to describe what I will bet money the vast majority in this room are actually doing and the 10 biggest reasons why that way of working is fundamentally flawed 5:35 Point 1: Everything starts with ideas 6:00 Two main sources of ideas: execs (internal leaders) and customers 10:11 So this is what I see in the vast majority of companies (ideas>biz case>roadmap>requirements(user stories)>design>build(agile comes in here)>test>deploy). Basically waterfall. 11:20 Why is this so bad. 10 key points 11:40 Reason 1: Source of ideas. Consistently the best source of your ideas: The engineers. 12:19 Best source of ideas... Your engineers! 13:18 Another source of ideas. Data. Customers don't know the data 14:30 Reason 2: The fallacy of business cases. You can't know. You have no clue how much money you'll make coz you don't know what your solution is. 18:40 Reason 3: Roadmaps. Number 1 on my list of why teams fail. The two inconvenient truths about products. First: At least half of the items on your roadmap won't work with customers. 21:40 Second inconvenient truth. Things that could work require iteration to work. Requires money and patience. 21:50 Jeff Bezos quote "Be stubborn on the vision, but flexible on the details". Roadmaps are the details 25:26 Reason 4: The Role of Product. Capturing requirements is not the role of product managers. That's project management. 28:17 Reason 5: The Role of Design. In this process, it's considered the lipstick on the pig form of design. "We need missionaries, not mercenaries" 32:32 If this is the way your company insists on working you might as well use a visual design agency. The reason we bring it in house is so that we don't work this way 33:00 Reason 6: The role of engineering. They're not just there to code 34:10 Reason 7: The role of agile. 35:20 Reason 8: Output Not Outcome. Output is easy. Results are hard. 37:57 Reason 9: Customer Validation Too Late. Nail in the coffin for the waterfall process. 39:10 Reason 10: Opportunity Cost. This way of working (waterfall) takes a lot of time and a lot of money. You can't get that back. 41:55 SOLUTION: Continuous Product Discovery. Ideas> Discovery> Delivery 44:15 Vision and OKRs. OKRs are the alternative to roadmap. OKRs tell us what problem to work on this quarter not solution 45:25 Run MVP tests in discovery and the idea is to get the product market fit. Those are the two most important concepts in product. MVP and Product Market Fit. 45:50 When we're in product discovery we need to make sure whatever were making is valuable for people. It also needs to be usable. Feasable is can we build it and would our stakeholders support it 46:55 Should we build it? Suggesting we add ethics to discovery 48:14 It's all about quickly getting that evidence, separating the good from bad, and making sure our developers are spending most of their time building production, building stuff we have evidence is going to move the needle.
Continuous Discovery and Delivery is the way to go forward instead of following the Waterfall(Agile) methodology of delivering solutions to your customers. The Waterfall(Agile) is time consuming, expensive, built on log of assumptions based on discussions with not so correct stakeholders. For more knowledge on this new way of building products we must give a read to this very nice book by Marty named as 'Inspired'.
The way he gasps for air at the beginning of his talk makes me think he is overwhelmed with so much he needs to say in so little time and we are about to drink water from a fire hydrant.
If you were patient to listen to the end he spoke about the better way to go about achieving product success. He titled that part Continuous Discovery and Delivery. The third and final segment of his speech.
First lesson: It's impossible to please everyone all the time. If the speaker talks too much about the solution, then you most likely will complain about what's wrong with the traditional way of building products. Second lesson: If you work in the product space, you're probably not qualified enough if you say things like "too much talking" when you clearly don't have a better solution. Learn how to learn.
lots of problem have the same root cause, but there is no best practices solution. actually its easy: just don't do theses things and you are good to go. so easy. whats next? end world hunger?
1:22 There's a tremendous difference between how most companies work and how the best companies work
2:59 I wanna try to describe what I will bet money the vast majority in this room are actually doing and the 10 biggest reasons why that way of working is fundamentally flawed
5:35 Point 1: Everything starts with ideas
6:00 Two main sources of ideas: execs (internal leaders) and customers
10:11 So this is what I see in the vast majority of companies (ideas>biz case>roadmap>requirements(user stories)>design>build(agile comes in here)>test>deploy). Basically waterfall.
11:20 Why is this so bad. 10 key points
11:40 Reason 1: Source of ideas. Consistently the best source of your ideas: The engineers.
12:19 Best source of ideas... Your engineers!
13:18 Another source of ideas. Data. Customers don't know the data
14:30 Reason 2: The fallacy of business cases. You can't know. You have no clue how much money you'll make coz you don't know what your solution is.
18:40 Reason 3: Roadmaps. Number 1 on my list of why teams fail. The two inconvenient truths about products. First: At least half of the items on your roadmap won't work with customers.
21:40 Second inconvenient truth. Things that could work require iteration to work. Requires money and patience.
21:50 Jeff Bezos quote "Be stubborn on the vision, but flexible on the details". Roadmaps are the details
25:26 Reason 4: The Role of Product. Capturing requirements is not the role of product managers. That's project management.
28:17 Reason 5: The Role of Design. In this process, it's considered the lipstick on the pig form of design. "We need missionaries, not mercenaries"
32:32 If this is the way your company insists on working you might as well use a visual design agency. The reason we bring it in house is so that we don't work this way
33:00 Reason 6: The role of engineering. They're not just there to code
34:10 Reason 7: The role of agile.
35:20 Reason 8: Output Not Outcome. Output is easy. Results are hard.
37:57 Reason 9: Customer Validation Too Late. Nail in the coffin for the waterfall process.
39:10 Reason 10: Opportunity Cost. This way of working (waterfall) takes a lot of time and a lot of money. You can't get that back.
41:55 SOLUTION: Continuous Product Discovery. Ideas> Discovery> Delivery
44:15 Vision and OKRs. OKRs are the alternative to roadmap. OKRs tell us what problem to work on this quarter not solution
45:25 Run MVP tests in discovery and the idea is to get the product market fit. Those are the two most important concepts in product. MVP and Product Market Fit.
45:50 When we're in product discovery we need to make sure whatever were making is valuable for people. It also needs to be usable. Feasable is can we build it and would our stakeholders support it
46:55 Should we build it? Suggesting we add ethics to discovery
48:14 It's all about quickly getting that evidence, separating the good from bad, and making sure our developers are spending most of their time building production, building stuff we have evidence is going to move the needle.
Great thanks just 1 correction,
Source of idea is data 13:21
Thanks for briefing
He literally changed the mindset of millions of people out there. Thanks Marty
Continuous Discovery and Delivery is the way to go forward instead of following the Waterfall(Agile) methodology of delivering solutions to your customers. The Waterfall(Agile) is time consuming, expensive, built on log of assumptions based on discussions with not so correct stakeholders.
For more knowledge on this new way of building products we must give a read to this very nice book by Marty named as 'Inspired'.
I love Marty really knows the product game
He sounds like Ross from Friends
This is one of the gem by Marty
Wonderful insights!
The way he gasps for air at the beginning of his talk makes me think he is overwhelmed with so much he needs to say in so little time and we are about to drink water from a fire hydrant.
This is fantastic 🎉!! And I learnt a lot ! Off to finding a company which is at least believe in this
are the slides available? Thanks
Depends on the engineer. My engineers have no interest in learning about the business problems.
Moore Donald Martinez Frank Taylor Angela
12:36 Engineers are dangerous. They dream a lot, but… 😅
too much talking about the problem no solution provided
Well yeah, the subject of the talk was root causes of product failure not product success. His other talks are about how to do it right/better.
If you were patient to listen to the end he spoke about the better way to go about achieving product success. He titled that part Continuous Discovery and Delivery. The third and final segment of his speech.
I need a shorter way. For example a list of root causes is enough.
First lesson: It's impossible to please everyone all the time. If the speaker talks too much about the solution, then you most likely will complain about what's wrong with the traditional way of building products. Second lesson: If you work in the product space, you're probably not qualified enough if you say things like "too much talking" when you clearly don't have a better solution. Learn how to learn.
lots of problem have the same root cause, but there is no best practices solution. actually its easy: just don't do theses things and you are good to go. so easy. whats next? end world hunger?