Jeff Patton, a.k.a Father of Agile-UX, is doing the most innovative work around product discovery, release planning, agile interaction design, and putting requirements into context. Jeff won the Gordon Pask Award in the year 2007, for his work helping establish what User-Centered Design means in Agile.

Jeff brings two decades of experience from a wide variety of products from on-line aircraft parts ordering to electronic medical records to help organizations improve the way they work. Where many development processes focus on delivery speed and efficiency, Jeff balances those concerns with the need for building products that deliver exceptional value and marketplace success.

We are thrilled to offer Jeff’s exceptional Passionate ProductOwner (CSPO) workshop at the Agile India 2013 Conference.

Recently, we caught up with Jeff and asked him the following questions:

Why the passion in product ownership?

First off, “Passionate Product Ownership” is a stupid title, because you can’t teach someone passion! However, I’ve always been involved in Product Development and Product Management, and I take the greatest pride from knowing that I’ve made a product or put something out into the world that other people use. The class focuses on understanding the business problems we are solving – the people who will use the product and understanding what their problems are. While I can’t teach passion, we can certainly focus on helping everyone understand that they are building products that help people, and that’s where the passion comes from.

The product ownership role is often defined as one of the most challenging roles defined in scrum, why is this?

Scrum and Agile processes in general, offer a lot of tactical guidance for how to get software built. But most Agile processes depends on getting the right person in the Product Ownership role – someone who already knows what to build.

This role difficult because you are responsible for building the right thing, and you are also responsible for communicating what that right thing is to a large group of people, sometimes in excruciating detail! In this class, one of the first things you’ll learn is that while there may be a single Product Owner who acts as a leader, product ownership is handled by a team of people. I’d rather that the role of Product Owner was named “Product Leader” and that whole teams take ownership. If you survive the class and adopt this way of thinking, you’ll be practicing a type of product ownership where everyone is involved in figuring out the details of what to do, who the user is, how best to help them and what solutions should be built and described in detail.

You’ve done significant work in blending UX & Agile. Where do you think the community is headed as far as UX on Agile projects go?

That’s a great question! It depends on which community you’re talking about. In the early 2000s, I spent a lot of time in the Agile community trying to help them understand what user experience was and its importance. Simultaneously, I spent time with User Experience people trying to help them not be so darn afraid of Agile Development as if it was going to “wreck” things.

I’ve seen a lot of maturation over the last decade and many UX people now have experience working inside Agile projects and teams. The coolest thing that’s happened within the User Experience community is that they have learned to change their practice so it works better in an Agile context. I’ve also seen more and more organizations working with Agile development recognizing the importance of understanding users and building products that people like. Organizations see that UX is the kind of work that happens outside the code and it isn’t an “engineering thing.” Currently, I am seeing the User Experience community going deeper and evolving practices that work better. For example, you’ll find books on Agile User Experience and Lean User Experience. Also more and more people who teach Agile practices acknowledge, or at least understand, what a user experience person does, although some challenges remain.

A new kind of Agile is forming, where the work that UX people do to understand users, prototype and try out ideas, is now called Lean Start-Up. A friend of mine, Leah Buley, once said, “Design isn’t a product that designers produce. Design is a process that designers facilitate.” The communities are starting to understand that the user experience work is cross-cutting and the concern is threading it’s way into everyone’s process.

What will be the key take away for the workshop attendees?

You will learn the practices that support the “Product Discovery” process and how to do discovery well. Building the right product is about understanding who the product is for and how they are going to benefit from using it. This is not a singular person’s responsibility – it is the whole team’s responsibility. The practices you’ll get in the class that support this come from user experience. Practices such as simple personas and story mapping provide understanding of users and model user behaviors. You’ll also get practices for good project management. For example, focusing product releases on specific target users, tactically guiding releases, ways to slice stories thinly to slowly build up a product, so that as soon as possible, it is a shippable, complete product. You’ll also gain practices for building small amounts of product as experiments to really validate if you are building the right product.

Limited seats are available for Jeff’s Product Ownership workshop. Book your seat today to avoid disappointment: http://booking.agilefaqs.com

Good Product Owners are:

• Visionary
• Can come up with a product vision which motivates, inspires and drives the team
• Aligns the product vision with company’s vision or mission
• Passionate Problem Solver
• Should have a knack of identifying real problems and ability to visualize a simple solution to those problems.
• Has good analytical & problem solving skills
• Subject Matter Expert
• Understands the domain well enough to envision a product to solve crux of the problem
• Able to answer questions regarding the domain for those creating the product
• End User Advocate
• Empathetic to end-users problems and needs
• Able to describe the product from an end-user’s perspective. Requires a deep understanding of users and use
• Is passionate about great user experience
• Customer Advocate
• Understands the needs of the business buying the product
• Ability to select a mix of features valuable to various different customers
• Business Advocate
• Can identify the business value and synthesize the business strategy as measurable product goals
• Has a good grasp of various business/revenue models and pricing strategies
• Capable of segmenting the market, sizing it and positioning a product (articulate the Unique Selling Proposition)
• Is good at competitive analysis and competitor profiling
• Able to create a product launch strategy
• Communicator
• Capable of communicating vision and intent – deferring detailed feature and design decisions to be made just in time
• Decision Maker
• Given a variety of conflicting goals and opinions, be the final decision maker for hard product decisions
• Designer
• Possess a deep understanding of (product) design thinking
• Able to work effectively with an evolving product design
• Planner
• Given the vision, should be able to work with the team to break it down into an iterative and incremental product plan
• Capable of creating a release roadmap with meaningful release goals
• Is feedback driven .i.e. very keen to inspect and adapt based on feedback
• Collaborator
• Able to work collaboratively with different roles to fulfill the product vision. Be inclusive and empathetic to the difficulties faced by the members of the cross-functional team
• Given all the different stakeholders should be able to balance their needs and priorities
• Empowers the team and encourages everyone to try new ideas and innovate

Disclaimer: This list is based on my personal experience but originally inspired by discussions with Jeff Patton.

In my experience its hard (not impossible) to find someone who possess all these skills. It requires years of hands-on experience.

Some companies form a Product Ownership team, comprising of different people, who can collectively bring these skills to the table. Personally I prefer supporting one person to gradually build these skills.

I amazed how easily companies get convinced that they can send their employees to a 2-day class on Product Ownership and acquire all these skills to be a certified Product Owner.

These days, its common to see teams doing the Product Backlog Management to Sprint Planning t0 Daily Scrums to Reviews to Retrospectives perfectly fine, as described in the book (or the 2 days Certified Scrum Master course). We are doing all the process stuff correctly, except that we don’t seem to be”actually” making money (minting). But somehow along the way, we seemed to have missed the point.

The problem I see is, teams are doing all the process stuff, as they are told, except that, post demo they don’t actually release the software (deploy it into production). Most teams are very happy showing the demos at the end of the sprints. They start thinking that this new process they are following is magical. Until 6 months later, their so-called “Product Owner” comes backs saying I didn’t quite expect “this” this-way and I thought “that” would be “this” and not really “that”. That is when it hits the team that what they were really doing was building inventory and basically doing a compressed-waterfall.

Until you actually release your software and see your end-users actually use it in real life, you don’t have the most important feedback. Hence you are not “done” until you really see you users use the feature you just released (and probably you are not even done after that. “Done-Done” was a cute concept, get over it). There is no better means of feedback nor is there a better risk-reduction strategy other than releasing software to production frequently (at least every week).

Remember code that is not yet deploy and just sitting in your repository is a liability. So is, all your fancy product backlogs and grandiose plans.