I am a passionate Product Leader. I love sharing my learnings from multiple failures. In this channel, I share relevant insights about Product Management and Agile Mindset.
The goal of this change is to help product people escape from the build trap. I dream of a world where product people can focus on doing what matters the most; solving the end-users' real problems.
The issue with primarily going for the low hanging fruit in the matrix is that you're not chasing the bets enough. They equally deliver value, but are harder and also need to be prioritised. Some developments are hard and do deliver good value and therefore are equally worth chasing.
If the goal is to deliver value, benefiting from what drives that fast is often a wise choice. Yet, I do not recommend neglecting bets; instead, I recommend balancing, knowing that bets may fail to drive value and that the costs are high. Balance is the key.
@@DavidPereira88 Agree. There's also an element of short term vs. long term goals. Low hanging fruit usually deliver ROI in the short term, while the bets have longer ROIs.
David, as CEO/PO, we struggle with when to bring the engineers into the conversation. I was told by a few PM's that you secure the high-level requirements/design(s) and business goals prior to inviting any developers to a meeting. Thoughts?
Great video. As CEO, our company struggles with alignment of deliverables. I don't mind small wins, but we end up focusing on so many projects, like you said, we never (or at least feel like) we never get anything done.
@DavidPereira88 Are you available for a business chat regarding your Udemy course? On getting you more sales, Real and active student with 5 stars positive reviews I'll be looking forward to your response Thanks
Thank you David for your video! Please, I would like to understand the part where you say we must show the problem and not the solution in the refinement meeting. In our product team, we usually use the Refinement Meeting to explain to the team what needs to be built (previously we had a meeting between the Product Manager, Product Designer, and the Tech Lead to find out the best solution to the problem). But, what would it look like to have a refinement meeting with user problems and needs (opportunities) and how would be possible to put product backlog items in the sprint if we are just talking about problems in the refinement? There won't be time to better define the solution if we do so. Please, help me understand that.
Why would you need detailed solution descriptions? The way you asked the question implies the DEV implements the solution instead of uncovering how to solve a worth problem.
@@DavidPereira88 We are following the following abbreviated process: BA and UI/UX designers receive user issues, analyze competitors, conduct market research to provide requirements. Then, they brainstorm with the development team to gather additional input, ideas for solutions, and finalize the best approach. Afterward, the BA needs to complete detailed documentation, including business process descriptions and system design descriptions for the development team. Currently, our refinement sessions are struggling to clarify the solution, and new documentation is needed to facilitate them. Can you provide advice on where we might be going wrong
@@trunggiang2573 That's a classic way of working, which differs much from how I work. I don't see a short answer for that. I'd recommend reading my newsletter or attending to one of my upcoming cohorts. maven.com/david-pereira/product-discovery-done-right
Love this concept, but I can tell you from many recent experiences, this is NOT what hiring managers think Product Owners are. They DO think POs are backlog shepherds or BAs. The real question is how do we lead those horses to water, especially under economic duress?
Many hiring managers are ill-equipped to differentiate the real Product Owner from the wrong versions of it. It's hard to transform. But I always ask the question, do you want a team of achievers or doers? If your answer is the second, I'm not your guy because when someone tells me what they want, I won't do it because I will strive to understand what they need and lead teams to create value beyond features. It's a different game, and that's the one I play.
I guess your quadrant in min 6 is a bit incorrect. If stg is not easy to build & also doesn't promise that much impact, it is waste of time. hence, you need to replace reds and grey circles' positions in your quadrant imho.
@@DavidPereira88 I just watched this and came to comment the same thing as @erman… but then noticed you’re using “Easiness” instead of the more common “Difficulty” that we normally see on these graphs. If the X axis were difficulty, then you would need to swap red and grey… but should also have a swap between green and orange. With difficulty on the bottom you would get a reverse result of: High return, low effort=green High return, high effort=orange Low return, low effort=grey Low return, high effort=red
Bjorn for president! XD It is so true! I see the same problem over and over again. Truth be told, Scrum or no Scrum, most companies choose a type of hybrid framework that simply doesn't work. And they have a management system that has disaster written all over it: Sales makes impossible promisses (about things they know nothing about - they are not developers-) then they tell the developers what to do (and of course this must be done yesteryear), the developers are like "what the f+++k are you talking about?!". Or worse still, companies allow stakeholders access to Jira! >_< every time time I see this I just want to slap someone in the face, with a chair!, are they insane?! you give a child a hammer, everything is a nail! they claim they want to be transparent, but this is just stupid! (talk about paving the road to hell with good intentions) ; stakeholders end up treating Jira as a feauture wishing well, hoping their ticket will work as a coin that will hit a developer on the head! I mean, for crying out loud! And then they wonder why developers keep leaving them...
Thank you, David. Could you please advise? If my product deals with some complex logic: puzzling algorithm or formula to calculate some chart or widget value. Should the team (Devs + QAs + PO) investigate the proper rules? Who should document the description, diagram, spreadsheet in acceptance criteria? I can hardly imagine developers spending time on science papers research. Thanks again
@@areochou8044 results talk more than words, sometimes you got to do what's opposing top management requests but great outcome you help you earn their trust and start changing.
,@@DavidPereira88 You got it. Trust is everything, I changed my jobs thrice in the last 3 years. Maybe it is a little bit affected by covid-19, as you know, many small businesses shut down during that hard time. Each employer has yet to give me enough time to prove myself. Maybe, other people like me want to hear your experience and stories about how you conquered the bosses. 😀Appreciate your replies, I will continue to do what I do. Thanks so much.
Do you have any advice for being a product owner, doing agile, with internal architecture products? I'm finding that the end users for this dynamic are other agile scrum development teams themselves, so there's less involvement for the product owner, outside of maybe being an order taking backlog manager for the CIO. Any thoughts for this dynamic?
That's a complex topic. I've been a PO for backend services already. We found our way by setting clear goals, one, we kill dependencies. Then we organized the backlog based on it. I strived to evaluate which dependencies would be worth removing first and then prioritized. The CTO tried to push for different things, but we could focus on the goal. In summary, start with the goal and gain support for it.
