Hi Teresa, thanks for sharing this. It's an area that is very much in focus where I work. We have had a few instances where the PM + designer have not involved anyone from engineering during discovery, which has led to subsequent friction around what's feasible to build and also a lack of buy-in from engineering as to why it's the right thing to build. I'm hoping to encourage engineering involvement in the discovery work. I very much agree that engineers taking time out to contribute to discovery is time well spent if it increases the probability that we're building the right thing rather than falling into the build trap.
I'm pleased to see these ideas encapsulated so succinctly. Thank you for this! I encourage others to seek out more, in-depth resources offered by Teresa / Product Talk. I've found that they pair well with Marty Cagan's more recent work as well as that of Melissa Perri and Tim Herbig.
Thanks Teresa! Super helpful to understand the various stages of moving towards a full product model. We continue to struggle with PM bandwidth. It's almost a pull back towards project as you said. We'll keep an eye out on this one! Thanks again!
The more the entire team comes closer to the customer and takes part in discovery the more value gets produced. One of the ways is that product managers understand the what and why and create features together with teams to do discovery delivery hand in hand.
Literally, it makes sense to pull tech team closer to customers, but technically it will slow down tech team’s velocity. A scrum team I worked in, the entire tech team worked with users directly to build internal tools, understanding the pain points, and offering solutions to what users asked for, but there are several drawbacks in this process: 1. Tech team spends lots of time at product discovery and communicating with business. Many meetings the entire tech team wants to join to just understand the context and pain points. They don’t have time to code. In this process, product managers should be the one to decide what pain point we want to fix and why before bringing in the entire tech team 2. Since tech team is always in the communication loop with business, they always want to jump in to fix any issues the business asked. In a more traditional way, product managers will negotiate with business to prioritize issues before handing off requirements to tech team, which is more efficient to get things done. 3. Tech team are easily get distracted by business since business will reach out directly to tech team asking to work on a feature or fix a bug. In a more traditional way, product can shield tech team from getting distractions. 4. In a more traditional way, product managers can filter the business or users’ comments, and give a more constructive feedback to the tech team to keep morality high. I did feel tech team working in a traditional model tends to be happier and more efficient than the tech teams who work with business directly. I do agree product should bring in the entire tech team to the project as early as possible, but product managers should also be the one to decide what pain points we want to address, understand what solutions we could have to bring in the most value to the customers and businesses, and also keep tech team to focus on development.
Thanks Teresa, that was a very insightful video. I thought the traditional role in waterfall methodology responsible for writing requirements was the Business Analyst and thought that Product Manager was a more modern version of the Product Owner that was oriented in continuously interacting with customers and running experiments. They would iterate over the product vision and roadmap based on the continuous stream of insights they get and worked with the team to define the requirements by co-ideating a best approach to tackle the problems presented.
Yup, I've seen those labels used those way as well. The reality there is no consistency in who is called a product manager and who is called a product owner. But whatever the label, if you have a role where someone just writes requirements and manages a backlog, odds are you are still stuck in a project world.
Hi Teresa, I love all your content, thanks! Two questions: 1) Are you saying that user stories are no longer written and communication on what to build is now solely through prototypes and other elements supporting the 'why' of what to build? By extension, would story pointing and tracking velocity, burndown etc. (which requires user stories) to manage stakeholder expectations on approximate delivery timelines not be something that's done any longer? If there is still some user story and task writing that needs to be done, which role should do this? 2) You speak to co-creation with clients etc, but in our scenario we have loads of clients. I've attended Jeff Gothelf training and we try to follow the model of 'test until you can predict the next answer'. However, in times especially for internal products when there could be head butting on options, we find the dependence on one decision maker in the business helpful. We term this person the product or business owner. Even in Design Thinking (Sprints) which Jeff Gothelf is a fan of, there is the role of a decision maker. In this more general business reality, is it not helpful to have a Decision maker who would be the Product/Business Owner for a product?
Regarding #1, some teams are moving away from user stories, story points, tracking velocity, etc. That doesn't that's the right answer for everyone. I do think user stories can play a role in continuous discovery. Who writes them? The team. I see two primary problems with how many teams write requirements: 1) It falls on one person (who becomes the de facto decision maker) and 2) we expect requirements to communicate everything and that's impossible. We can't translate complex software into linear requirements and expect a team who wasn't involved in the decisions about what to build to build the right stuff. Product managers and product owners waste countless hours trying to communicate with requirements when instead they should be collaborating with their team. User stories should be a placeholder for a conversation, not a replacement for the conversation. Regarding #2, I prefer to see the trio decide together. As soon as you designate a primary decision maker you undermine the collaboration of the trio. Now that doesn't mean that the trio shouldn't defer to any one role when they can't come to consensus. For example, if you are discussing the feasibility of a solution and the team can't agree, a strong team would defer to the engineer because they have the most knowledge about the technology. But this doesn't mean that the team simply lets the engineer decide. Instead, they need to discuss and align as a team while respecting each others expertise.
@@ProductTalkVideos Thanks for the video. A few thoughts... Back in the late 80's and 90's, those of us that wrote requirements were Data Analysts and Process Analysts (in the days of Information Engineering lingo). Then the term changed to Business Analysts. Other than that title distinction, yes, we wrote a LOT of text that not many people ever read. :(. Scrum and Agile are better approaches as the teams are cross-functional and included much earlier on, and we narrow the focus to smaller delivery of chunks of value. The earlier we involve the creators the better, given the limitations of time. One point, though... the User Story was never meant to be a full set of requirements. It was meant to capture the essential questions of 'who has a need', 'what do they need' (what not how), and 'why'... the business justification or value or outcome that we get from this output. Outcomes over outputs. The card was intended to be a conversation starter, not a fully documented set of requirements. And, the card was intended to provide the essential acceptance criteria to help in scoping the limits of what would be expected. Other than those tweaks, I love the idea of moving at least a few of the key creator teams closer to the client while still providing some team members time to focus on building. As to whether we call the Product people Product Managers vs Product Owners seems to be a local company choice.
Hi, thank you for this video. You helped me realise where we are with our process. Thankfully we are working in Product Trio (which I used to call like this 🙂), but in project based model. And it’s really good model, but we are in the situation of not having designs for engineers quick enough.
This was a great presentation! Thank you for sharing. I really liked the idea of having a Product Trio, I just wish that my organization structured teams that way.
the information is great itself. However, somehow i have expected differently under the title "difference between product owners and managers". I felt the video addressed it from a very different and more historical evolvement perspective. I can't say i know the difference now if someone asks me between these two "job titles". The answer seems to be "it depends" how your team or project is set up and how design and agile work together in your environment.
To-the-point info as always. This team setup is quite similar to how Marty Cagan describes Dual Track Agile. In Lean UX however I think they describe dual track a bit different and that discovery is more a team effort than a prod.trio. But I'm maybe missing something. Anyway, thanks for great content.
I agree having the engineering team close to the customers and the discovery makes them missionary and also enables finding better solutions, but How do you mitigate the risk that the engineering team gets dragged in the gathering requirements flow and does not have time to focus on development and learning new technologies? A developer needs time to focus on the software development in a quiete environment, how do you make sure that happens in this model?
Great video! Thanks for putting the efforts. It's very easy to digest the various types of organizations and their approaches. I've got a couple of points/questions to make: * Where do you see User Researchers in the product discovery phase? * Given there's an engineer in the trio, why do you say engineers are away from the discovery? Yes, you mention when "engineers are available and have time" they should participate in discovery to understand the context, but aren't they at risk of being overloaded as well of participating in the discovery and delivering as well? There's a very thin line between engineers being in the discovery to understand context vs being in the discovery to participate in it, don't you think?
I see User Researchers playing one of two roles depending on the company resources: 1) embed with the product trio 2) support product trios as a subject-matter expert Also, many user researchers work on longer horizon research which is also important.
When I talk about engineers being away from discovery, I'm talking about the hand-off of requirements. Even if your tech lead is participating in the trio, you need to be thoughtful about how you are communicating what you are learning to the rest of the engineers.
Thanks Teresa. Thanks for all th great inishts. Wanted to understand how this scales across large teams of 50-100 people working on single product? Does this mean we should have multiple group of trios and multiple product managers within a single product? multiple prodcut ma
Hi Teresa i loved your video, and there is one aspect on my mind that i cannot answers after seeing the continuous discovery model, "How would you end with a backlog?" My thought process is as follows if the input for the delivery team are prototypes and interview sessions, then would they write their own user stories? Thanks in advance
That's up to them. Many teams that work from prototypes no longer write user stories. They do still need to capture acceptance criteria somewhere, but usually if you work in small enough batches and are building together, the need for formal user stories tends to go away. I realize this breaks a lot of things if your organization cares about story point velocity and other scrum-related stuff. So in that case, the team could write user stories when they are satisfied a prototype meets the customers needs.
When you say product trio, are you referring to a scrum team? I have to ask because out of all the resources I have been reading, watching, and listening to when related to the P.O. , this is the first time I hear “product trio”
Do you have a video on user stories. Just a tad confused by this subject and would love to see user stories in action like if it was happening on the job and in person
This is very useful! so many people don't know this difference and you have them clearly explained!
Hi Teresa, thanks for sharing this. It's an area that is very much in focus where I work. We have had a few instances where the PM + designer have not involved anyone from engineering during discovery, which has led to subsequent friction around what's feasible to build and also a lack of buy-in from engineering as to why it's the right thing to build. I'm hoping to encourage engineering involvement in the discovery work. I very much agree that engineers taking time out to contribute to discovery is time well spent if it increases the probability that we're building the right thing rather than falling into the build trap.
I'm pleased to see these ideas encapsulated so succinctly. Thank you for this!
I encourage others to seek out more, in-depth resources offered by Teresa / Product Talk. I've found that they pair well with Marty Cagan's more recent work as well as that of Melissa Perri and Tim Herbig.
Thanks Teresa! Super helpful to understand the various stages of moving towards a full product model. We continue to struggle with PM bandwidth. It's almost a pull back towards project as you said. We'll keep an eye out on this one! Thanks again!
The more the entire team comes closer to the customer and takes part in discovery the more value gets produced. One of the ways is that product managers understand the what and why and create features together with teams to do discovery delivery hand in hand.
Literally, it makes sense to pull tech team closer to customers, but technically it will slow down tech team’s velocity. A scrum team I worked in, the entire tech team worked with users directly to build internal tools, understanding the pain points, and offering solutions to what users asked for, but there are several drawbacks in this process:
1. Tech team spends lots of time at product discovery and communicating with business. Many meetings the entire tech team wants to join to just understand the context and pain points. They don’t have time to code. In this process, product managers should be the one to decide what pain point we want to fix and why before bringing in the entire tech team
2. Since tech team is always in the communication loop with business, they always want to jump in to fix any issues the business asked. In a more traditional way, product managers will negotiate with business to prioritize issues before handing off requirements to tech team, which is more efficient to get things done.
3. Tech team are easily get distracted by business since business will reach out directly to tech team asking to work on a feature or fix a bug. In a more traditional way, product can shield tech team from getting distractions.
4. In a more traditional way, product managers can filter the business or users’ comments, and give a more constructive feedback to the tech team to keep morality high. I did feel tech team working in a traditional model tends to be happier and more efficient than the tech teams who work with business directly.
I do agree product should bring in the entire tech team to the project as early as possible, but product managers should also be the one to decide what pain points we want to address, understand what solutions we could have to bring in the most value to the customers and businesses, and also keep tech team to focus on development.
Thanks Teresa, that was a very insightful video. I thought the traditional role in waterfall methodology responsible for writing requirements was the Business Analyst and thought that Product Manager was a more modern version of the Product Owner that was oriented in continuously interacting with customers and running experiments. They would iterate over the product vision and roadmap based on the continuous stream of insights they get and worked with the team to define the requirements by co-ideating a best approach to tackle the problems presented.
Yup, I've seen those labels used those way as well. The reality there is no consistency in who is called a product manager and who is called a product owner. But whatever the label, if you have a role where someone just writes requirements and manages a backlog, odds are you are still stuck in a project world.
@@ProductTalkVideos Totally, specially if those requirements come from stakeholder fantasy land instead of validated learning
If you close your eyes its Naruto uzumaki teaching you about product management
Hi Teresa, I love all your content, thanks! Two questions:
1) Are you saying that user stories are no longer written and communication on what to build is now solely through prototypes and other elements supporting the 'why' of what to build? By extension, would story pointing and tracking velocity, burndown etc. (which requires user stories) to manage stakeholder expectations on approximate delivery timelines not be something that's done any longer? If there is still some user story and task writing that needs to be done, which role should do this?
2) You speak to co-creation with clients etc, but in our scenario we have loads of clients. I've attended Jeff Gothelf training and we try to follow the model of 'test until you can predict the next answer'. However, in times especially for internal products when there could be head butting on options, we find the dependence on one decision maker in the business helpful. We term this person the product or business owner. Even in Design Thinking (Sprints) which Jeff Gothelf is a fan of, there is the role of a decision maker. In this more general business reality, is it not helpful to have a Decision maker who would be the Product/Business Owner for a product?
Regarding #1, some teams are moving away from user stories, story points, tracking velocity, etc. That doesn't that's the right answer for everyone. I do think user stories can play a role in continuous discovery. Who writes them? The team. I see two primary problems with how many teams write requirements: 1) It falls on one person (who becomes the de facto decision maker) and 2) we expect requirements to communicate everything and that's impossible. We can't translate complex software into linear requirements and expect a team who wasn't involved in the decisions about what to build to build the right stuff. Product managers and product owners waste countless hours trying to communicate with requirements when instead they should be collaborating with their team. User stories should be a placeholder for a conversation, not a replacement for the conversation.
Regarding #2, I prefer to see the trio decide together. As soon as you designate a primary decision maker you undermine the collaboration of the trio. Now that doesn't mean that the trio shouldn't defer to any one role when they can't come to consensus. For example, if you are discussing the feasibility of a solution and the team can't agree, a strong team would defer to the engineer because they have the most knowledge about the technology. But this doesn't mean that the team simply lets the engineer decide. Instead, they need to discuss and align as a team while respecting each others expertise.
@@ProductTalkVideos Thanks for the video. A few thoughts... Back in the late 80's and 90's, those of us that wrote requirements were Data Analysts and Process Analysts (in the days of Information Engineering lingo). Then the term changed to Business Analysts. Other than that title distinction, yes, we wrote a LOT of text that not many people ever read. :(. Scrum and Agile are better approaches as the teams are cross-functional and included much earlier on, and we narrow the focus to smaller delivery of chunks of value. The earlier we involve the creators the better, given the limitations of time. One point, though... the User Story was never meant to be a full set of requirements. It was meant to capture the essential questions of 'who has a need', 'what do they need' (what not how), and 'why'... the business justification or value or outcome that we get from this output. Outcomes over outputs. The card was intended to be a conversation starter, not a fully documented set of requirements. And, the card was intended to provide the essential acceptance criteria to help in scoping the limits of what would be expected. Other than those tweaks, I love the idea of moving at least a few of the key creator teams closer to the client while still providing some team members time to focus on building. As to whether we call the Product people Product Managers vs Product Owners seems to be a local company choice.
Thank you! Nice to learn from this kind of content.
Hi, thank you for this video. You helped me realise where we are with our process. Thankfully we are working in Product Trio (which I used to call like this 🙂), but in project based model. And it’s really good model, but we are in the situation of not having designs for engineers quick enough.
This was a great presentation! Thank you for sharing. I really liked the idea of having a Product Trio, I just wish that my organization structured teams that way.
the information is great itself. However, somehow i have expected differently under the title "difference between product owners and managers". I felt the video addressed it from a very different and more historical evolvement perspective. I can't say i know the difference now if someone asks me between these two "job titles". The answer seems to be "it depends" how your team or project is set up and how design and agile work together in your environment.
To-the-point info as always. This team setup is quite similar to how Marty Cagan describes Dual Track Agile. In Lean UX however I think they describe dual track a bit different and that discovery is more a team effort than a prod.trio. But I'm maybe missing something. Anyway, thanks for great content.
I agree having the engineering team close to the customers and the discovery makes them missionary and also enables finding better solutions, but How do you mitigate the risk that the engineering team gets dragged in the gathering requirements flow and does not have time to focus on development and learning new technologies? A developer needs time to focus on the software development in a quiete environment, how do you make sure that happens in this model?
Great video! Thanks for putting the efforts. It's very easy to digest the various types of organizations and their approaches.
I've got a couple of points/questions to make:
* Where do you see User Researchers in the product discovery phase?
* Given there's an engineer in the trio, why do you say engineers are away from the discovery? Yes, you mention when "engineers are available and have time" they should participate in discovery to understand the context, but aren't they at risk of being overloaded as well of participating in the discovery and delivering as well? There's a very thin line between engineers being in the discovery to understand context vs being in the discovery to participate in it, don't you think?
I see User Researchers playing one of two roles depending on the company resources:
1) embed with the product trio
2) support product trios as a subject-matter expert
Also, many user researchers work on longer horizon research which is also important.
When I talk about engineers being away from discovery, I'm talking about the hand-off of requirements. Even if your tech lead is participating in the trio, you need to be thoughtful about how you are communicating what you are learning to the rest of the engineers.
Thanks Teresa. Thanks for all th great inishts. Wanted to understand how this scales across large teams of 50-100 people working on single product? Does this mean we should have multiple group of trios and multiple product managers within a single product? multiple prodcut ma
so in the final continuous discovery diagram, where's the product owner gone, or are they part of the Trio?
Hi Teresa i loved your video, and there is one aspect on my mind that i cannot answers after seeing the continuous discovery model, "How would you end with a backlog?"
My thought process is as follows if the input for the delivery team are prototypes and interview sessions, then would they write their own user stories?
Thanks in advance
That's up to them. Many teams that work from prototypes no longer write user stories. They do still need to capture acceptance criteria somewhere, but usually if you work in small enough batches and are building together, the need for formal user stories tends to go away. I realize this breaks a lot of things if your organization cares about story point velocity and other scrum-related stuff. So in that case, the team could write user stories when they are satisfied a prototype meets the customers needs.
what a thought provoking idea, thank you very much for being so generous with your knowledge
When you say product trio, are you referring to a scrum team? I have to ask because out of all the resources I have been reading, watching, and listening to when related to the P.O. , this is the first time I hear “product trio”
See this video: czcams.com/video/iEFCyt8Y4Is/video.html
Thanks for this!
Do you have a video on user stories. Just a tad confused by this subject and would love to see user stories in action like if it was happening on the job and in person
This is a very informative video on user stories -> czcams.com/video/R62Iu_4zcpU/video.html