What’s a Product Owner To Do?

When I coach companies on Scrum and Agile Methodologies, I’m used to having dedicated, co-located Product Owners and teams. Lately it seems, especially with large corporations involved in an Agile transition, Product Owners and Scrum Masters are leading multiple project teams; often they are not co-located. It can be challenging when trying to coach teams on Agile Manifesto values, such as: Individuals and Interactions over Processes and Tools. Often during these transitions, companies expect a PO to be a part-time Product Owner: doing PO work in addition to his/her day (or real) job. Many times I have had Product Owners ask me to help justify their full-time involvement so that their supervisors understand the extent of the time commitment involved with the role. I have done this by describing what a typical Product Owner does each day. So in this post, I am going to jot down a  (by no means exhaustive) list of what a Product Owner does on a daily basis (in no specific order):

  • Attends the team’s daily planning meeting (aka standup) to understand the team’s progress and issues towards the sprint goals.
  • Captures customer requirements (and wish lists) by writing (or helping others write) User Stories.
  • Accepts/rejects completed User Stories.
  • Prioritize and update the backlog.
  • Is available to the team each day to answer questions and clarify stories.
  • Verifies that stories are in the proper format, contain valid confirmation (aka Acceptance Criteria), and  are in-line with the product vision and scope. This includes any necessary design details, business rules, etc.
  • Makes sure that project/product vision and goals are clearly defined and communicated to everyone.
  • Works with the team to ensure stories meet the agreed upon “Definition of Ready” before pulling them into the sprints.
  • Helps remove obstacles that the team and Scrum Master cannot remove.
  • Makes sure that the Scrum Team has a direct connection with end users through story development and the Sprint Review.
  • Keeps stakeholders informed on project status and how much value has been generated for money spent.

In addition to that, on a bi-weekly or as needed basis:

  • Participate in the demo and retrospective meetings.
  • Work with the team to groom the Release backlog.
  • Work with the team to plan the iterations.
  • Meets with customers and stakeholders on a regular basis to field questions and inform them of project/product updates and changes.
  • Conducts the Sprint demo with the team to present the incremental functionality to users and stakeholders.

Feel free (or compelled) to add your own. My thanks to Bob Schatz @Agileinfusion for his sage advice and input.

Why Companies Choose Not to Innovate

You read that right, it’s a choice. Companies often make a conscious decision to not innovate. Why do companies choose to do this? Why is it so hard for their employees to innovate? Let me count the ways:

  1. Because it is easy, embarrassingly easy, to kill an idea –How often have you been in a meeting, when a coworker comes up with different approach to solve a problem or new idea? What is the reaction? “Oh wow! Great idea Jane! I’ve got some ideas on how we can implement that.” Or is it more like this: “That won’t work, and here’s why…” “We tried that before and it didn’t work, because… “ Why? Because it is part of our corporate culture. It is easy (and comfortable) to find reasons why an idea won’t work. It is easy to poke holes in a new idea or product, but hard to figure out how to make it better and even harder to figure out how to make money with it. The latter requires an extreme use of brainpower to take a germ of an idea and grow it. It requires research, strategic knowledge of your customer base, economics, sales and marketing.
  2. Confuse innovation with entrepreneurship – Innovation could be defined as a cool new idea or process. Entrepreneurship is the ability to take that idea to the next level, and make (or save) money with it. Simply having smart creative employees is not enough. In order to gain business value, a process (and supporting infrastructure) needs to exist which allows companies to nurture and capitalize on ideas. Far too many companies create cumbersome and unnecessary obstacles by forcing employees to fill out copious amounts of paperwork, go before review boards, etc.
  3. Not providing the time or environment to innovate – One of the main tenants of economics is that people make rational decisions. It is irrational to expect employees to work overtime to create innovation for a company; on top of their normal 40-50 hours a week. If an employee wanted to work overtime on an idea, the rational decision would be to simply work his/her 40-50 hours, then put in personal time on his/her idea. This part-time innovation approach is how many startups are initiated. So, by expecting employees to work overtime on innovation for the company, the company is actually incentivizing them to innovate (and hopefully profit) on their own.
  4. Risk Intolerance – If companies choose to allow innovation time, or try to implement something like the Google 20% rule; corporate leaders must understand the nature of risk involved. Many companies are simply unable or unwilling to accept the risk that most ideas will not create value. For those unwilling to accept risk, it becomes a pure opportunity cost, and therefore a wasteful expense.

Issues, 1,2 and 4 above are the result of a toxic, but not uncommon, corporate culture. It has been ingrained into our tech DNA to challenge and vet new ideas (which I view as a good thing). However, I have witnessed corporate cultures, which pride themselves on establishing nearly impossible impediments to innovation. Moving towards an entrepreneurial culture which accepts risk takes time, leadership, and an unwavering commitment to the following principles:

  • There is a commitment to experimentation, innovation, and being on the leading edge
  • This culture does not just quickly react to changes in the environment—it creates change
  • Effectiveness depends on providing new and unique products and rapid growth
  • Individual initiative, flexibility, and freedom foster growth and are encouraged and well rewarded

Culture changes must come from the top of the organizational food chain and it doesn’t happen overnight. It will most likely take years and require vigorous attention to change management principles (see Dr. John Kotter’s Our Iceberg is Melting).

So where does Scrum come into the mix? This is after-all an Agile blog. While a culture change is required to bring about strategic innovation and entrepreneurship, you can use Scrum and Agile methodologies to address issue #3 – Innovation time.

6x2x1 Rule – One way to enable innovation time is to introduce the concept of a Scrum hack-a-thon. For teams that have two-week iterations: every 6 iterations have a 1-week hack-a-thon. This is known as the 6x2x1 rule: After six 2-week iterations, have a 1-week hack-a-thon.

How it works – I first learned this from Kenny Rubin, who originally taught me Scrum. I took it a step further and add a few rules:

  • A separate product backlog is created to track innovation ideas. The stories are not prioritized. They may or may not be groomed, that is up to the team. For the hack-a-thon, the team members decide what to work on (within reason – see below). Should a story start to mature into a product, the product owner can move it into the product backlog.
  • Prior to the start of the hack-a-thon, the team presents what they want to work on to the team and product owner.  The team and the product owner are responsible for making sure the ideas make sense for the company and the team (or individual team member).
  • Employees can work on their own idea, or join other team members.
  • It doesn’t have to be a new product idea. For some, it could be a learning session (e.g. I don’t know JQuery, so I am going to spend the week learning it); which could be used to reduce technical debt or improve an existing product.
  • The team is free to work on what they want.  However, the project(s) they work on must be beneficial to the employee as well as the company. For example, it isn’t beneficial to a telecom company for an employee to create an iOS video game.
  • Other than emergencies, nothing else happens during a hack-a-thon that interrupts the team (e.g. no meetings, planning sessions, etc.).

The 6x2x1 Rule is one method, there are probably many others. Even if you use the above method, you are still below the Google 20% innovation benchmark, but it is a start.