12/10 - Co-Hosting Nir Eyal author of Hooked: How to Build Habit-Forming Products

Hooked: How to Build Habit-Forming Products with Nir Eyal 

What makes some products so engaging while others flop? Nir Eyal explains the psychology behind the world's most habit-forming technologies and provides practical advice for increasing user engagement.

About the Presenter:

Nir Eyal writes, consults, and teaches about the intersection of psychology, technology, and business. Nir founded and sold two companies since 2003 and has taught the "Using Neuroscience to Influence Human Behavior" course as a lecturer at the Stanford Graduate School of Business. In addition to blogging at NirAndFar.com, Nir's writing frequently appears in TechCrunch, The Atlantic, and Psychology Today. He is the author of the bestselling book, Hooked: How to Build Habit Forming Products.

Agenda: 

6:30pm - 7:00pm Networking

7:00pm - 7:40pm Nir Eyal Presentation

7:40pm - 8:00pm Q&A with Nir Eyal

8:00pm - 8:30pm Announcements & Networking 

This Meetup event is a collaborative effort between the 

Agile / Lean Practitioners

and 

The UX Lab

RSVP NOW for this event.

Product Ownership is Challenging and Rewarding

The Product Owner role is essential but can be extremely challenging to fill.   Most organizations struggle to find someone with the right blend of skill and experience to fulfill this role perfectly.  Before we explore why that is, let us define what the role entails.  


Roman Pinchler, author of Agile Product Management with Scrum, describes the role as "the individual who champions the product, who facilitates the product decisions, and who has the final say about the product."1   The ideal product owner has to have:

• Vision for the product(s) they own
• Strong understanding of their customer(s)
• Deep domain expertise
• Ability to collaborate with multiple stakeholders
• Authority and respect throughout the organization
• Time and willingness to work with team to describe his / her vision 
• Leadership style to motivate others to see that vision and work with the team to achieve it 

Having been a product owner for several years, I know the pitfall and rewards of this role.  In his article, The Product Owner and the Product-Shaped Hole, Jeff Patton jokingly suggests product owners should wear "spandex and a cape” given the super-hero-like demands placed on them.4  

Organizational context and product maturity greatly influence the expectations on a product owner.  For example, if you’re responsible for delivering a new product that will change how we sell products to our customers that is a very different challenge than inheriting an internal business system that has been in production for 10+ years.  If you are responsible for delivering a new product, you are likely to be judged as an "entrepreneur" or “intrapreneurs,” while an owner of a mature product might be judged on how well they maximize the return on investment on a series of enhancements.1 This is does NOT imply that product owners of mature products are less inventive than those building new products, or that one is easier or more valuable than the other.  Understanding how your product fits into the larger ecosystem of the organization you are working in is critical to the choices you make as a product owner.  

Most agile literature on product ownership takes it as a given constraint that there is ONE product owner per product.  This is certainly a best practice, but in many resource-constrained organizations that I’ve worked, teams often support more than one product, and sometimes product owners support more than one team.  If you find yourself supporting multiple products or multiple teams, do the best you can to protect the team from context switching and churn by helping to focus the team’s effort and coming to planning sessions fully prepared.  Furthermore, leverage the talent on your team to see how you can involve them more and take some of the load off your shoulders.   

Here are some suggestions that I offer to product owners, regardless of the organizational context, product maturity, or number of products you support:

• Focus on outcome, not output  – Outcome is what we expect to happen after the software ships. We can only improve if we assess whether what we deliver is meeting its intended purpose. Furthermore, teams are motivated by knowing that what they build is expected to move the needle. 
• Involve the Team - Resist the feeling that you need to figure it out on your own. Present the team with the opportunity or problem you’re looking address, and they’ll find a solution that works and likely be more engaged as part of being involved in product envisioning. 
• Talk and test with actual customers – Why not learn from the people you are looking to serve. Validating your assumptions or being able to course correct will greatly improve your product offering.
• Communicate with Your Stakeholders – As a product owner, it’s your responsibility to make sure that you’re effectively prioritizing and sharing feedback from stakeholders and representing your team well back out to stakeholders.

While challenging at times, I have found product ownership to be one of the most rewarding jobs because you have an opportunity to work with motivated team members and deliver true value to an organization.  


Sources:

1. The Product Owner on One Page by Roman Pichler
2. Top 10 Product Owner Qualities and Characteristics by Peter Saddington
3. The Product Owner Role: A Stakeholder Proxy for Agile Teams by Scott Ambler
4. The product owner and the product-shaped hole by Jeff Patton

Product Owners can Prioritize their Stakeholders

The product owner role is a critical to the success of an agile team.  Scott Ambler describes the product owner role as a Stakeholder Proxy for Agile Teams. "The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team." Scott Ambler further illustrates this with the following image:

Scott Ambler's Role of Product Owner

If you are a Product Owner and you struggle to partner effectively with the various stakeholders in your company or organization, rest assured that you are NOT alone. Depending on the product you responsible for and size of your organization you may have numerous stakeholders and need to develop ways to coordinate among so many people. We all have limited time, so we need to determine how to invest your it most effectively to deliver value. In traditional project management, a suggested technique is to prioritize stakeholders based on their influence and interest so you can identify who you want to manage closely, keep satisfied, keep informed, and monitor with minimum effort.

The problem with this approach is that it is a power grid and emphasizes a stakeholder's influence, instead of knowledge or value, that a stakeholder can provide to a product owner and agile team.   It positions the stakeholder as a power broker that the team serves, rather than a partner who works with it the team.  


I like the concept of a simple matrix for prioritizing stakeholders, however, I choose not to use the power or influence of the stakeholder as an axis.  Instead, I modify the grid to focus on the value the stakeholders can provide the team.  I define value as knowledge that can take many forms.  It could be domain expertise, understanding of customer needs, business acumen, technical know-how, and the list goes on.   
  
My form of the stakeholder prioritization matrix looks like this:

• High Knowledge / High Interest = Stakeholders that you partner closely with
  These are the stakeholders require little effort to involve and willingly work with the team.  As a product owner, I identify touch points (development / updates to product roadmap, prior / following release planning, during backlog grooming sessions) to keep these stakeholders in the loop and often seek their counsel.  
• High Knowledge / Low Interest =  Stakeholders that you consult with (and try to move to high interest category)
  These are stakeholders that you want to involve but they are either too busy, or may not (yet) see the value to them helping the team.  I seek to convert these stakeholders to willing partners (i.e., high interest) by .   I seek  
• Low Knowledge / High Interest = Stakeholders who you keep informed
  Agile teams believe in transparency.  I believe demos should and any communication of team progress should be made available to anyone who is interested.  You may discover that one of these stakeholders deep knowledge in an area that you were unaware of.
• Low Knowledge / Low Interest = Stakeholders who have an open door in get more involvedThese stakeholders are welcome to attend demos or express interest in becoming more informed, but I don't go out of my way to involve them.

If you have a number of stakeholders and find it difficult to keep up, this technique might help you prioritize your efforts accordingly.  While this post is geard at Agile product Owners, it is useful to others who work with Stakeholders on a diaily basis.