Product Talk
Product Talk
  • 230
  • 208 444
Tools of the Trade: How HiveMQ Used Orbital to Automate Their Customer Interview Recruiting
Tools of the Trade: How HiveMQ Used Orbital to Automate Their Customer Interview Recruiting
Переглядів: 58

Відео

Tools of the Trade: Jira Product Discovery
Переглядів 1,9 тис.3 місяці тому
Tools of the Trade: Jira Product Discovery
Stop validating your ideas
Переглядів 3106 місяців тому
You are inviting confirmation bias in. Learn more: producttalk.org/assumption-testing #ContinuousDiscoveryHabits #AssumptionTesting
Moving on to a new target opportunity
Переглядів 1076 місяців тому
Knowing when to keep at it vs. moving on. Learn more: producttalk.org/opportunity-solution-tree #ContinuousDiscoveryHabits #OpportunityMapping #OpportunitySolutionTree
Master Class: Continuous Discovery Habits - A Course Preview
Переглядів 1636 місяців тому
In this video, I walk through our Master Class: Continuous Discovery Habits course curriculum and teaching philosophy. Learn more about our Master Class at: learn.producttalk.org/cdh-master-class
Building coherent products
Переглядів 526 місяців тому
While working on one opportunity at a time. Learn more: producttalk.org/opportunity-solution-tree #ContinuousDiscoveryHabits #OpportunityMapping #OpportunitySolutionTree
Why surveys aren’t great for finding opportunities
Переглядів 1026 місяців тому
And what to do instead. Learn more: producttalk.org/customer-interviews #ContinuousDiscoveryHabits #ContinuousInterviewing #CustomerInterviews
What is a product?
Переглядів 4196 місяців тому
It’s more complicated than many think. Learn more: producttalk.org/continuous-discovery #ContinuousDiscoveryHabits #WhatIsAProduct
Product in Practice: Shifting from a feature factory to Continuous Discovery at Doodle
Переглядів 1,4 тис.7 місяців тому
Teresa Torres interviews Stephanie Leue, Chief Product Officer at Doodle, about how she helped her teams transform from a feature factory to continuous discoveyr. You can find a full transcript of this video at www.producttalk.org/2024/04/shifting-from-a-feature-factory-doodle/
The value of collecting customer feedback in one place.
Переглядів 828 місяців тому
Reduce the noise. Learn more: producttalk.org/blog #ContinuousDiscoveryHabits
Tools of the Trade: Using Pendo to Manage Customer Requests with Leann Schneider
Переглядів 5208 місяців тому
Leann Schneider walks through how Plum uses Pendo to collect, organize, and act on customer requests. You can find a full transcript of this video at www.producttalk.org/2024/03/manage-customer-requests-plum/
Meet Kelsey Terry: A Continuous Discovery Champion at Going
Переглядів 1358 місяців тому
Meet Kelsey Terry: A Continuous Discovery Champion at Going
The Interview Snapshot by Product Talk
Переглядів 1,4 тис.9 місяців тому
The Interview Snapshot by Product Talk
Managing Discovery Teams
Переглядів 909 місяців тому
Managing Discovery Teams
Help your teams make discovery a habit.
Переглядів 699 місяців тому
Help your teams make discovery a habit.
Invest in your teams’ discovery skills.
Переглядів 569 місяців тому
Invest in your teams’ discovery skills.
Help your teams make time for discovery.
Переглядів 499 місяців тому
Help your teams make time for discovery.
Coaching & evaluating product teams
Переглядів 419 місяців тому
Coaching & evaluating product teams
When we deviate from our strategic context.
Переглядів 7211 місяців тому
When we deviate from our strategic context.
Trends in discovery.
Переглядів 8111 місяців тому
Trends in discovery.
Discovery is messy.
Переглядів 8111 місяців тому
Discovery is messy.
On being an empowered product team.
Переглядів 4511 місяців тому
On being an empowered product team.
Prepare your teams to be empowered product teams.
Переглядів 3311 місяців тому
Prepare your teams to be empowered product teams.
Help your teams understand business value.
Переглядів 68Рік тому
Help your teams understand business value.
Getting reliable feedback from customer interviews
Переглядів 49Рік тому
Getting reliable feedback from customer interviews
Define your strategic context.
Переглядів 122Рік тому
Define your strategic context.
"I don't have time for discovery."
Переглядів 768Рік тому
"I don't have time for discovery."
Avoid the extremes.
Переглядів 33Рік тому
Avoid the extremes.
Help your teams get started with continuous discovery.
Переглядів 49Рік тому
Help your teams get started with continuous discovery.
Organizational change starts with you.
Переглядів 24Рік тому
Organizational change starts with you.

КОМЕНТАРІ

  • @RabiulIslam-vw6ih
    @RabiulIslam-vw6ih 3 місяці тому

    The information I found about your channel is to SEO your videos and make your video title, and description, SEO Friendly, rank (#1) in the videos, also by promoting the videos to thousands of groups, bring thousands of views to the videos, also to me. There are some concealing tips I can share with you if you want. Your content is very professional and very beautiful for engaging the audience. but the problem is that it can't reach the right audience.

  • @MaxHerberger
    @MaxHerberger 3 місяці тому

    Thanks for the insights. I like the idea of using an idea for both, opp. and solutions. The good thing though: the team already confirmed they are working on a solution for OSTs that shall be released soon.

  • @aziontech
    @aziontech 3 місяці тому

    It won’t replace the collaboration of OST sessions, but it will definitely help give visibility to the work that comes out of these sessions. The main takeaway for me is that it makes it easier to show/report stakeholders and managers the effort and results from discovery, especially in companies that are delivery-driven rather than outcome-focused. This visibility may help generate this change.

  • @veronicalabolida
    @veronicalabolida 5 місяців тому

    Amazing 🎉Thanks for sharing ❤

  • @Fransphoenix
    @Fransphoenix 6 місяців тому

    Good video. Needed to hear this!

  • @akshaycherian2047
    @akshaycherian2047 6 місяців тому

    Thanks! really thought provoking:)

  • @UlaBabenskaite
    @UlaBabenskaite 6 місяців тому

    Thank you for a great series!

  • @cardosct24
    @cardosct24 6 місяців тому

    Thank you for all the content you have you on this channel. Your Book has been an eye opener! I'm starting too look for way to implement tools with my own team. Btw, what you think of this critique from Roman Pichler, who gives lot credit to your work, but then makes comment about the OST and the agile framework. ihmo, his comments seem to be misunderstanding of what you yourself stated in the book with respect to finding the fastest path to starting with a solution to explore.

    • @ProductTalkVideos
      @ProductTalkVideos 6 місяців тому

      Thanks for the kind words. Do you have a link to Roman's critique?

  • @martinlennon5439
    @martinlennon5439 7 місяців тому

    Helpful

  • @rolandodelacruz4144
    @rolandodelacruz4144 9 місяців тому

    Great video! (is there a sample experience map that you have shared somewhere? would help ground the concept) Thanks!

  • @oliphon
    @oliphon 9 місяців тому

    Your videos tend to drop exactly when I need them. Thanks for the wisdom!

  • @Volvix127
    @Volvix127 9 місяців тому

    Would you recommend a couple tools for both of them?

  • @lucasl..7307
    @lucasl..7307 10 місяців тому

    Thanks for sharing Teresa!

  • @thegiggler2
    @thegiggler2 Рік тому

    Most big companies are like this. Jobs famously said 'Start with the customer experience and work backwards'.

  • @victoraboh2145
    @victoraboh2145 Рік тому

    This makes so much sense! 💡

  • @charlesegwuh143
    @charlesegwuh143 Рік тому

    If we set ahead what we expect does that not increase the chances of having some kind of confirmation bias?

    • @ProductTalkVideos
      @ProductTalkVideos Рік тому

      No, it guards against confirmation bias. When evaluating results, we have to make a judgement call, "Is that result good enough?" If we make this judgement after we see the results, we'll be impacted by confirmation bias. If we make this judgement before we look at the results, we'll guard against confirmation bias.

  • @andyds11
    @andyds11 Рік тому

    I think you'll find my video on Adaptive Project Management and how I recommend providing a schedule with dates and deliverables. In short, it's fine to provide them, but the messaging is "This is our plan today, but as we learn new things, the plan may change. I'll let you know ASAP what the changes are". ua-cam.com/video/EFTeDV3jIKQ/v-deo.htmlsi=lGQZTr95Cf-9Fy1C

  • @HardenedVMS
    @HardenedVMS Рік тому

    Roadmaps are the base to communicate vision, priorities and dependencies without going into unnecessary details in highly unpredictable and volotile new markets and conditions...

  • @brookrichardson1373
    @brookrichardson1373 Рік тому

    This is why I always insist on statistically significant results and A/B testing running concurrently.

    • @ProductTalkVideos
      @ProductTalkVideos Рік тому

      That's a very slow way to learn. The key is to combine early signals with iteratively more complex tests.

  • @sebastianbernal8897
    @sebastianbernal8897 Рік тому

    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

    • @ProductTalkVideos
      @ProductTalkVideos Рік тому

      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.

    • @sebastianbernal8897
      @sebastianbernal8897 Рік тому

      what a thought provoking idea, thank you very much for being so generous with your knowledge

  • @akimighty
    @akimighty Рік тому

    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

  • @RubenLindgren
    @RubenLindgren Рік тому

    promo sm 😎

  • @siddhantkumar9492
    @siddhantkumar9492 Рік тому

    Which one you would choose as the most ideal framework for Product Discovery from the available choices

  • @MarkFrancis-z1u
    @MarkFrancis-z1u Рік тому

    Hi Teresa. Even when the trio work collaboratively each week in the continuous discovery process they are likely to end up with a large work packet of actually having to write the user stories, acceptance criteria, grooming the backlog and prioritizing. Also, someone needs to oversee each sprint and act as the voice of the customer. Without a hand-off (PM to PO) how will this happen efficiently without completely overloading the PM?

    • @ProductTalkVideos
      @ProductTalkVideos Рік тому

      This video/article might help: www.producttalk.org/2020/10/product-managers-product-owners/

    • @MarkFrancis-z1u
      @MarkFrancis-z1u Рік тому

      @@ProductTalkVideos Many thanks

  • @Astillleros
    @Astillleros Рік тому

    I love the clear example you give here! Yes! Sending this to a whole bunch of PMs right now ⚡️

  • @TheUnknown70777
    @TheUnknown70777 Рік тому

    If you close your eyes its Naruto uzumaki teaching you about product management

  • @rickywbrown
    @rickywbrown Рік тому

    This is chock full of gold.

  • @JanEnthusiast
    @JanEnthusiast Рік тому

    🫃

  • @lawrencemorris3973
    @lawrencemorris3973 Рік тому

    *promo sm*

  • @LittleMichael91
    @LittleMichael91 Рік тому

    You often speak about the difference between product and business outcomes. For any product team's opportunity solution tree, shouldn't they be focused on the product outcomes that ultimately lead to business outcomes, a lagging indicator?

  • @RaphaelAlejandro
    @RaphaelAlejandro Рік тому

    I think Platform teams may have a harder time justifying their work when there’s so much tech debt that they are stuck working on the most “basic” things ever, that will eventually unlock great power, but that right now may feel unnecessary.

  • @carlosbraga9381
    @carlosbraga9381 Рік тому

    wow!

  • @brianfitzgerald3894
    @brianfitzgerald3894 Рік тому

    We have a challenge where one characteristics of empowered teams is ‘no deadlines’… In a complex product space where there are multiple dependencies on the various teams and between product teams and the rest of the business .. and large enterprise customers have expectations for certain outcomes in a predictable time frame how can you work without deadlines even if it’s just the team setting their own?

  • @wanderfussch
    @wanderfussch Рік тому

    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.

  • @scottf9044
    @scottf9044 Рік тому

    So essentially you've renamed Scrum's Sprint Review as a Discovery Demo? The intention is exactly the same, but unfortunately so many organizations' Sprint Review formats don't provide teams the opportunity to demonstrate stepping stones towards a larger goal (Sprint Goal and Product Goal). Sprint Reviews are intended to show progress, be open to experimentation (discovery) and demonstrate via working software both failures and successes.

    • @ProductTalkVideos
      @ProductTalkVideos Рік тому

      In our experience, most teams spend their sprint reviews focused on delivery tasks.

  • @breaktherules6035
    @breaktherules6035 Рік тому

    EXCELLENT insights!THANK YOU so much for sharing!

  • @shipsmahindra9124
    @shipsmahindra9124 Рік тому

    Link to the Transcript please? 🙂

    • @ProductTalkVideos
      @ProductTalkVideos Рік тому

      It will be added tomorrow when the blog post goes live.

  • @maciejbalasinski2419
    @maciejbalasinski2419 Рік тому

    Thank you

  • @Soundmaster91
    @Soundmaster91 Рік тому

    Thank you!

  • @chelseaqiao4957
    @chelseaqiao4957 Рік тому

    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.

  • @agileworldwithprasun1390
    @agileworldwithprasun1390 Рік тому

    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.

  • @an-b28
    @an-b28 Рік тому

    This is so useful! Thank you so much for your contribution.

  • @ViktorEngelbert
    @ViktorEngelbert 2 роки тому

    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.

  • @briannaaikens6039
    @briannaaikens6039 2 роки тому

    Hi Teresa! Question! Do you have any videos that dig more into the experience map exercise? I've read the chapter on it but I'm still unsure how to use it with our team for a feature that's already been decided on. For example, if a feature like the "Get my perfect size" wizard on clothing websites where you enter in your weight, height, body shape, age, etc. has already been decided on as something we need to build but how we actually build it is completely up to us, how would we use the experience map to gain consensus and use it to interview customers? Is being told we need to build this feature already too late in the game to use the experience map and the OST? It's almost like I'm trying to work backwards to fill out the map with what the business outcome, product outcome, and user journey would have been in order to land on this wizard as a "solution" which isn't what you're suggesting. Since the solution is already decided on but how we build it isn't, I'm hoping to use the experience map and OST to uncover opportunities and solutions to help users find their perfect fit.

    • @ProductTalkVideos
      @ProductTalkVideos 2 роки тому

      When you are prescribed a solution, I'd start with story mapping and assumption testing.

  • @garytaylor1026
    @garytaylor1026 2 роки тому

    😁 ρяσмσѕм

  • @briannacaikens
    @briannacaikens 2 роки тому

    Thank you so much for this video! I’m reading through your book and as a product designer, I’m trying to understand what is the best way to source and find the right users to interview and build up that list of users when the majority of customer are non-returning and not account holders?

    • @ProductTalkVideos
      @ProductTalkVideos 2 роки тому

      If you've got the book, check out the section on "Automating Your Recruiting Process" in ch. 5.

  • @bukola_O
    @bukola_O 2 роки тому

    Thanks for this presentation. I find that a lot of startups who use the agile framework barely do product discovery. They don’t have time for it. How can we balance discovery with speed?

  • @ankitGrover-LTD
    @ankitGrover-LTD 2 роки тому

    Great content! Thanks for sharing

  • @jamesoliver8261
    @jamesoliver8261 2 роки тому

    Can a Product Owner (as defined by Scrum) be the Product Manager part of the trio?

  • @jamesoliver8261
    @jamesoliver8261 2 роки тому

    so in the final continuous discovery diagram, where's the product owner gone, or are they part of the Trio?