Why is it so hard to find experienced Product Owners?

Lynn Winterboer – (@agilelynn) With a proven background in a variety of data projects and agile practices, Lynn Winterboer teaches and coaches DW/BI teams on how to effectively apply agile principles and practices to their work. For almost 20 years, Lynn has served in numerous roles within the analytics, business intelligence and data warehousing space. She has worked in numerous industries, including insurance, banking, retail, energy, high-tech manufacturing and channels, telecommunications, education, internet security, web marketing, government and healthcare. Lynn very well understands the unique set of challenges faced by DW/BI teams who want to benefit from the incremental style of Agile development; Lynn leverages her experience and training to help deliver practical solutions for her clients and students. I have noticed a recent increase in the number of recruiters contacting me for Product Owner roles, many of them looking for someone to work with a data-focused team (my area of expertise).  I just chatted with a recruiter looking for an experienced product owner (PO) to work with a healthcare company’s analytics team in the Denver Tech Center area. (Know anyone?) We both bemoaned the fact that there aren’t many experienced POs available in the market, much less any who have a good background in working with data warehousing/business intelligence/analytics. I can imagine other teams struggle to find product owners with the right amount of experience in their industry or business function.

If you are looking to hire product owners for your analytics team, and can’t find the perfect person on the market, I have an idea for you.

Step 1: Find someone who has the right experience as an analytics business analyst and WANTS to work in an Agile framework:

Focus Why

Eliciting business requirements for BI/DW/Analytics projects. One must know how to ask the right questions and capture the right information related to DATA projects (which can be different than requirements for workflow, web or mobile projects!)

Business process analysis: How the inputs, actions, and outputs of each step in a process add to (or inhibit) the value the organization gets from the process. Product Ownership is all about understanding, articulating, and prioritizing the VALUE each piece of work brings to the organization.

Solid experience working with data. One needs some good, healthy scar tissue from wrangling with data in order to understand the challenges faced by the delivery team members and work collaboratively with them

REALLY good relationship skills across all business functions, from accounting to sales. Product Owners for BI teams often need to support multiple functions in the business.  Therefore, a PO has to facilitate and negotiate priorities across these various functions. (See “BI Product Owners Love an Agile PMO!” for more on this)

Natural tendency toward, and desire to learn more about, agile practices: Focuses on team success over personal glory, loves to learn and grow regularly, comfortable with change, already knows agile is a MUST HAVE in future career choices! Agile is not for everyone.  There are places where traditionalists would be happier than on an Agile team.  Agile is simple in concept and difficult in execution.  One has to have a deep passion and drive to live the agile values and principles or it just won’t work.

STEP 2: Train, mentor and coach this person to work within an Agile framework:

Topic Why

What is “Agile”? One needs to understand the background, tenets, and various approaches of the Agile movement in order to have a strong foundation to stand on. Throughout a product owner’s career, it is very helpful when in doubt to go back and review the Agile values and principles, and figure out how to align with them.

How do DW/BI/Analytics projects work within an agile framework? The data world has some additional challenges to working within an Agile framework that other IT groups don’t. There are also ways in which an agile approach is a better fit for data teams.  It’s important to understand these differences so the PO can be a healthy participant in the delivery process.

How does a Product Owner build a roadmap based on prioritized projects and capabilities? This is where a PO’s experience in cross-functional relationships and business process analysis comes in handy. The Product Owner seeks out and takes multiple viewpoints into account, assesses organizational value for each opportunity, and decides the order in which the delivery team should focus on each project/capability. The agile world has lots of good practices available for POs to use in prioritizing and building a roadmap.

How does an agile team initiate a project? The PO is responsible for creating a project vision and motivating involved folks to quickly deliver organizational value.  It’s a big job!  Fortunately, there are agile practices that make this a community event where everyone leaves with a common understanding of, and excitement for, a new project.  This allows the delivery team to be much more autonomous in figuring out the best way to deliver the desired product – which leads to better code as well!

How does the Product Owner write, prioritize and groom user stories? The Product Owner has a big responsibility – to make sure the team is building the RIGHT THING (while the team focused on building the THING RIGHT). Without this leadership, a team can quickly iterate in the wrong direction and fail to deliver value – even with perfect code. Most of the user story classes and examples available to Product Owners today are based on web or mobile projects, and it can be difficult for a new PO to “translate” that guidance into something useful for a data-focused team.  Training and mentoring on user stories for analytics teams shortens the learning curve and reduces false starts.

How does the PO know when to accept a story as “done”? A key method for making sure the user stories are clear for the team is to include detailed acceptance criteria for each story – possibly even to the point of articulating the tests that would need to pass to “prove” the story is complete.  This takes a lot of work, and is critical for the PO to reduce wasted team effort (building the wrong thing due to misunderstanding) and creating faster value for the organization.

In my experience, it’s more difficult to teach somebody about the nuances of the data world (this often takes years of hard-won experience to really understand), than it is to teach them about the Agile approach. The main reason is that Agile is a journey and the community is supportive of “newbies” with the right attitude who want to continuously learn and grow. One of the key tenets of ALL agile frameworks is a regular and frequent “inspect and adapt” process (often called retrospection) that allows participants to learn from their mistakes and do it differently next time. It’s a wonderful situation for someone learning something new!