Marty Cagan - The Nature of Product

[@____2080_____]

12:37 the point being made at this timestamp is in contrast to my earlier comment pretty spot on. I wanted a few people who the product designing function who dealt with designers whether they are sea suite, or whether they are starting out, always constantly losing focus on this point. The problem comes from a dual issue: product managers generally discounting it because of the pressure coming from the start up, who is already behind the eight ball in terms of to hit a home run being down several runs in the bottom of the ninth versus your blue sky, in love with the profession fluffy designer who wants to slavishly follow the religion of UX process, and is typically oblivious to understanding how to design a product with impact. I think product leaders of the future would do best to stir the pot of that gumbo in order to get the best of both worlds. Research can be actionable, immediate and aware of business goals. Designers can combine insights, understanding and synthesizing it together with intuition , product managers can realize that user experience cuts across all titles and build product efficiencies within their teams, leveraging technology for faster builds (particular black box of engineers, who are as guilty as anyone for being oblivious to the business goals and urgency of hitting deadlines)

[@alexanderharenstam8633]

The ten misconceptions outlined by Marty: 1. you need to solve a problem nobody has solved before 2. you need to spend as much time as possible understanding "the problem space" 3. you need to be an expert in the domain 4. you need to listen to your customers 5. you need to commit to your solution, and iterate until success 6. you need product owners 7. you need to come up with innovative product ideas 8. you need your engineers to focus on coding 9. you need to focus on creating a product your customers love 10. you need process people to grow your company

[@KannanKalidasan]

Great talk ❤ and many learnings

[@____2080_____]

26:53 you’re 1,000,000% right on this point. I’ll use a case study that accompany that has fixed this problem: Logitech. Another name for product owner is stakeholder or division, head or industry lead

[@____2080_____]

28:25 i’m going to use this phrase “agile rituals“ in my next presentation

[@charlescrawford1788]

There is a strong Dave Ramsey vibe coming through here. Saying "just make your teams able to release every two weeks" is as easy as telling someone that makes $300 a week to "save $1000 in a hurry". Disregards any regulations in the industry, ignores organizational silos, and relies on manufacturing boogeymen (SAFe, Agile, Europe, The US Government) to keep emotional binds tight. (shrug) Sadly, there ARE decent ideas embedded here; which I suppose is how book-selling consultants stay in business.

[@claireowen9809]

Excellent keynote. Thank you for sharing.

[@visweshkris]

This is Gold. Thank you.

[@ramyaram]

Amazing!!. Thank you so much!!.

[@TheAramarmenia]

Product Owner part is pure manipulation. The fact is: 1. You can have a PO and an SM in your team and still deliver continuously 2. You can have a group of talented engineers that continuously deliver but the end result is not relevant to the market 3. Managing delivery is nowhere near to 10% for any role, it is more 4. Many big and successful companies in Valley have very well defined processes 5. The companies above have POs and PMs in their structure working very effectively 6. PO role was introduced with/by Agile and the role includes also Product Management responsibilities. It works the best for small teams, that's why PMs come into the play with the scale 7. PO is just a name, it is all about responsibilities. You can call it PM, or other names, however there are duties that should be covered by someone. In one of my previous companies (30K Valley company) PMs were acting more as Marketing Managers and POs were responsible for for customer relationship and defining features, as well as driving the delivery. At lastly, there is no universal recipe for success, you need to inspect and adapt.

[@charlescrawford1788]

Yeah, "as a customer" it's a real disappointment that he takes so much time crapping on rival frameworks. It only lowers his own product in my eyes. It's like his own proposals aren't strong enough to stand on their own without playing emotional games with the audience.

[@siddeshdhananjaya7180]

Too good, Thank you for sharing

[@fredg4449]

Excellent .....as allways !

[@Andrea-np3dh]

Agreed!!!

[@marvinpesch2313]

Thank you for sharing! Very inspiring!

[@tombennett6939]

I refer to that group of people that want to "productize" a process as the "methodology industrial complex". They can take something very useful and morph it into something that takes it completely away from its original intention and purpose. Every company and product team is different. Every set of customers is different. You have to be more in service to your team and customers and the problems you are solving than a slave to the process...

[@vanylaskywalker]

What does "process" mean in this context?

[@jenslindgard-paley1178]

At what time did he hold this speach? (Year)

[@SchoolofProduct]

October 2022, School of Product conference in Paris schoolofpo.com/

[@jenslindgard-paley1178]

@@SchoolofProduct - Thank you !

[@GuruprasadKini]

I agree with everything Marty says about Agile (with a capital "A"). However, I think he over-indexes on the "Product Owner" bit. It is just a role. Is it because it has the word "Product" in it? 🤔 Also, I don't think process can be always thrown away in favor of speed/innovation. Just like CI/CD is a process (which Marty seems to approve of), testing and verification is a process, code review is a process, blue/green deployment is a process. Yes, they slow things down. But for many products, you just can't fix it after release with any repercussions - so the extra time and effort for these processes is justified. Not every process is as stupidly evil as "putting coversheets on the TPS Reports". After a company grows to a certain size, policy and process play an important role - the leadership cannot be in the room every time a decision is made. Of course, process is often misused and overblown but so is product dogma. Building a product needs more than just sound product thinking or just good engineering - there are many different dimensions and viewing it from just one lens is a mistake.

[@MDK83]

How do you release once a day? You can't possibly be working on anything complex.

[@KhadAlbs]

Check trunk based development, I think he meant something like that. I don’t think he means releasing a full feature, but small changes that can make a difference.

[@prestige2k]

Build it, Ship it, [continuously] Tweak it.

[@mleanca]

Bookmark 31:57

[@____2080_____]

15:35 Marty is getting into heretic territory here. Sadly, unless you get into a relationship with a great visionary, director, level person, mini organizations, especially those who have over hired and stuff their organizations with bloated product teams will not only be the opposite of this, but will really disagree. I agree with this sentiment. But the way, most organizations higher, even when we are dealing with a new reality of limited budgets and reduce teams, they literally are blind to skills that are different yet complementary. HR hiring managers will use automated AI to screen exactly for that precise fit. Even those who do it manually Will rationalize that their need is to find someone that can just “jump in and understand” rather than rely on the intelligence of someone they hire to use complementary skills to not only figure it out, but to bring the type of innovation that a Martin or other product managers really want out of their teams

[@AlanSpina]

Marty you are the best! What happened with your voice???