How I take stock of the day

When I think about my daily routines, and what I’m trying to accomplish each day as a Product Owner, I tend to focus around 4 different areas.  Each of these areas is a win/loss for me each day.  I look and think about these as wins/losses daily, each sprint, each release, and each time I update the road maps.  These 4 things are different than what Bob Galen calls the “4 quadrants of Product Ownership” ( which I really like ) in that I believe those are skills that a PO needs to have to win these 4 different areas.

At any rate, here are the items, ranked in the order that I place their importance.

  1. Team – The team ( dev, test, design, analyst ) are of course the people who are producing the work.  They need to be the right people, working together well, and delivering meaningful results each iteration.  If the wrong people are on the team, or if they are not working well, then nothing else matters because nothing useful will be produced. I protect the team from outside noise that are always on projects and to make sure they are capable of completing the work.  The concept of a “1st team” is important here, and I believe that the team the PO works with should be their first.
  2. Product – What is being produced by the team and what will be delivered. It needs to be useful, well built, solve the needs, and do it in a manageable ( CI, test, deployment ) perspective.  I separate this out because there’s a difference between what the user ASKS for vs what the user NEEDS. The difference between user directed design and user centered design. I’m much more interested in building a product that solves a users problem rather than simply implementing a requirement document without discussion.
  3. Customer – The people who are engaging you are obviously important because they have a need, and they have the means to get something done.  In other words, if you solve their needs, they give you money.  Communicating with them is vital to understand their goals, objectives, and problems. Once you start listening, you can help guide them to understand the limitations, trade-offs, and expectations that will happen when creating the product.  Client’s have an expectation that you will listen to their needs and their issues, which is really why the PO is there. Doing exactly what someone asks is not the best way to solve something, if discovery and improvement aren’t two of the goals they are buying from you then it will be a much harder road for any agile process. Clients should come to you and your team/company to help them, and they should allow you to do that.
  4. IT(other) – This is everybody else, the resource managers, your direct manager(s), Business Solutions, IT PMs and other ( mostly ) necessary roles that usually accompanies any effort.  These are people who give you the opportunity to ply your craft and will never stop talking if they are unhappy. They can start or stop opportunities or projects from happening or continuing based on numbers or something else that you have no control over. They also typically control how the company operates ( agile, waterfall, or chaos ) so make sure the way you like to work is matching their standards, otherwise there will be a lot of noise.  Anytime there is a spreadsheet, MS Project plan, or accountants involved in determining your project/team, expect a disproportionate amount of your time to be sucked into the black hole of management.


The reason I put these in the order that I did, is simple; I believe that if a team is delivering a great product and you have happy customers, most  IT folks will fall into place or get behind you.  It’s harder to kill a successful project even if the PHBs disagree with what or how you’re doing something.

Each day I take stock of these 4 and see if any are going well or where one is sinking quickly.  I usually feel really good if I am winning on at least 2 of these, so I focus on how to improve the others. If I am consistently only winning one of these over a period of time there’s a real problem that should be addressed.  If I can’t win on any of them, then what am I really doing?  What could I improve and what can’t I improve without help, or at all? If I’m winning on all 4 then everything should be humming along. No drama, and everybody wins. I had a period of about 4 months that this was happening and it was the best working experience of my life.

I’ve had all of these happening at various times, usually on the same, definitely on different products, with different variables. The purpose is to give an idea of which problems you are having, which way to go to solve them, and how to know, in your own head, how to clarify which one’s are going wrong.

I will do a bit more in detail about each area, how to tell if I’m winning or losing that particular battle, and some specific strategies for each.  I was writing a bit on the team first when I thought about this idea and it’s really how I try to help others understand more about the role.  Hope it’s meaningful to you.


I like to create things, work with interesting people, and do all things agile. I have a testing background and really want to make great products that solve problems.

Tagged with: , , ,
Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: