schedule Mar 9th 10:30 AM - 11:15 AM place Mysore Hall 2 people 27 Attending

As with everything else related to agile, the nature of the Product Owner role, and whether it is needed or all, depends a great deal on context. As teams discover this, it leads to some common questions:

  • What do Product Owners Really Do?
  • Do we even need Product Owners?

Join Kent to examine the Product Owner role and attempt to answer the above questions. He’ll  share his experiences and give you a chance to share your perspectives with each other. By the end of the session, you'll have more insight into the Product Owner role and how it applies (or not) to your situation. After all, the only consistent answer to the above questions is “it depends”.

 
2 favorite thumb_down thumb_up 2 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Note: I referenced my Slide Share account below.  I'll  post slides for this talk that I am giving at Lean Agile KC after November 9.

A Brief History: Brief Overview of the Product Owner role - point out where it originated & some common misconceptions

What Do Product Owners Do: Ask attendees to get into small groups and create a list of what they think Product Owners do. Hang on to lists for later reference.  I then cover three main things that I think Product Owners are responsible for: Outcome over Output, Building a Shared Understanding & Making Decisions.

Where Do Product Owners Fit: Show three common models for Product Owners in organizations and share a brief case study for each model. Following discussion of the three models, ask attendees to revisit their lists to see if anything changed and to identify what model they are currently working in.  Discussion at this point.

Do We Need Product Owners: Wrap up discussion on the question "Do We Need Product Owners? Wrap up with the point that the activity of Product Ownership is more important that the role Product Owner.

 

Learning Outcome

  • Identify common organizational models for product owners
  • Determine appropriate product ownership responsibilities and practices
  • Share product ownership experiences with other attendees

Target Audience

Product Owners, business analysts, people who work frequently with product owners or want to be a product owner

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Niranjan N V
    By Niranjan N V  ~  11 months ago
    reply Reply

    Hi Kent,

    The role of a product owner is not new. Hence, my suggestion would be what are some your personal experience would help a lot. 

    • Kent McDonald
      By Kent McDonald  ~  11 months ago
      reply Reply

      HI Niranjan,

      Thanks for your comment.

      I certainly pull heavily from my own experience during the talk, and the three case studies I mentioned when describing the three models are all from my own experience.

      I find that while the role of product owner is not new, people do find it difficult to figure out how it works in their particular situation, and how they can best fulfill the role. That is one of the main reasons for this presentation - to give folks some techniques they can use to figure out the best way to apply product ownership "by the book" in their own situation.

      Thanks again,

      Kent


  • Liked Heidi Helfand
    keyboard_arrow_down

    Heidi Helfand - Dynamic Reteaming: The Art and Wisdom of Changing Teams

    45 Mins
    Talk
    Intermediate

    Who says you need "stable" teams in order to build a successful software company? While the addition or removal of one person from a team means you have a "new team", there is a myth out there about "stable" teams. When your team compositions change it doesn't mean you're doing it wrong - it could be the secret to your success. Different companies have thrived through reteaming - the act of moving people around teams in different ways. In this talk I'll go over the what, why and how of reteaming and will share stories from different companies who are living this reality.

  • Liked Kent McDonald
    keyboard_arrow_down

    Kent McDonald - 'Tis Better to Be Effective Than Efficient

    45 Mins
    Talk
    Intermediate

    Better. Faster. Cheaper. Many IT organizations are constantly seeking the "best" practices that will deliver those characteristics, and the fact that they continue to search indicates they haven’t found them yet.

    It could be they are looking in the wrong place. Most efforts around achieving better, faster, cheaper center around becoming ultra efficient.

    Effectiveness may just be the better target.

    Join Kent McDonald to explore the difference between efficiency and effectiveness and learn three simple, yet powerful, techniques that he has found can help teams be more effective. You’ll learn how to:

    • Build a shared understanding of the problem you are trying to solve
    • Establish clear guard rails for distributed decision making
    • Measure progress based on outcome, not output

    Along the way he’ll share stories about how he has used these techniques and help you figure out when these techniques may work in your situation.

    You may be able to get faster and cheaper with efficiency, but in order to get better outcomes, you need to be effective. Come to this session to learn how.

  • Liked Diane Zajac-Woodie
    keyboard_arrow_down

    Diane Zajac-Woodie / Doc Norton - Making Sense of Sense-Making

    90 Mins
    Workshop
    Intermediate

    The world as we know it is growing more complex. As we automate away those things that can be easily repeated, we leave ourselves with ever more challenging work. The way we’ve worked in the past won’t necessarily work for today’s problems… or will it? Join Diane and Doc as they explore dimensions of complexity in software development and look at how teams and leaders might adjust their behaviors (and the software they create) based on the complexity of the problem at hand.

    This hands-on, interactive workshop will provide a practical introduction to Cynefin (a sense-making framework for complexity) and show how it applies to the work we do every day as creators of software. You’ll map your own work to Cynefin and learn about applicable management styles and optimal team interactions for each of the Cynefin contexts.

  • Liked Diane Zajac-Woodie
    keyboard_arrow_down

    Diane Zajac-Woodie - How Agile Helped a BA Discover Her Real Value

    45 Mins
    Talk
    Beginner

    As companies introduce agile practices, the Business Analyst role is often left by the wayside. The title does not even exist in Scrum or other specific agile implementations, leaving many Business Analysts wondering where they fit in. But fear not! The skills of a good BA are even more valuable in an agile environment!

    Join Diane Zajac-Woodie as she tells the tale of a new agile team, struggling with no formal training, a resistant corporate culture and unwilling team members. She shares how this team benefited from the communication, collaboration & facilitation skills of an experienced BA. She then highlights specific shifts that Business Analysts can make in order to help their own team’s transition. These include using story maps and writing executable requirements, just in time.

    Embracing their new roles, BAs can also encourage team members to cross role boundaries. This leads to new skill acquisition and a more cohesive team, which ultimately leads to higher quality software.

  • Liked Diane Zajac-Woodie
    keyboard_arrow_down

    Diane Zajac-Woodie - Explore Your Customers' Needs with Empathy Mapping

    45 Mins
    Workshop
    Beginner

    “Success is not delivering a feature; success is learning how to solve a customer’s problem.”  ~ Scott Cook, founder of Intuit*

    If this is true, then the next question is: what is your customer’s problem? Unfortunately there’s no magic trick to figure out what customers need. But there is a simple technique that can help you gain insights and build empathy for them.

    Empathy mapping is a simple activity that you can facilitate with stakeholders (or anyone responsible for delivering products and services) to build empathy for your end users. It allows you to explore what your customers see, hear, say & do, as well as consider what they think and feel. This leads to insights about their pain and potential wants.

    Because this is done collaboratively, using silent brainstorming, everyone on the team contributes to a shared understanding of the customer. So not only do you build empathy, but you also create alignment within the team and among stakeholders. And that can only help you be more successful. 

    *as quoted in The Lean Startup, page 66