Archive for Product Owner

Product Manager 2.0 – New Course I am Working On

Posted in Uncategorized with tags , , , , on August 1, 2010 by vikramadhiman

I currently work as a Product Manager. My last job was a Product Manager. The one previous to that was a mix of Project Management and Business Analysis. I have been an Agile and Scrum fan for a very long time now 🙂

One area where enough coaching is not available is the role of Product Manager/ Product Owners in Scrum and Agile world. I am compiling a slide deck talking about this. I’ll also think of exercises, theory and examples.

Whatever conference comes up next, I’ll try and schedule this talk there!

Any links, examples – will help!

——————————————–

Here is what the outline looks like:

  • What is changing about the way products are developed? -> Internet times, Marketing changes, Hardware upgrades, Customer preferences, Increased competition
  • What is changing about the way products are supported and marketed? -> Social communities on the web, Instant gratification, Thought leadership
  • What is changing about the engineering teams? -> More involvement in product strategy and support, Better work-life balance, Increased communication demands, More informal structures
  • A bit about Agile and Scrum
  • What does a traditional Product Manager do?
  • What changes now?
  • How to gather requirements?
  • How to write requirements?
  • How to prioritize?
  • How to work with engineering teams and testers?
  • How to work with marketing, support, sales, PR?
  • How to work with senior management?
  • Skills required!

This is still a bit hazy. Let’s see how it develops 🙂

How to Prioritize Requirements YouTube Video

Posted in Agile, Business Value, Project Backlog, Release Planning with tags , , , on July 24, 2010 by vikramadhiman

I have written about how to prioritize before:

As Agile Product Managers, you are constantly prioritizing requirements to get higher value items out sooner. One approach I saw recently, seems very promising. Here is the video. Go ahead and watch it.

Basically, divide your requirements into four quadrants with Y-axis being Business Value and X-axis being Complexity. Hence, you would ideally do quadrant number 1 first and quadrant number 4 last. You can take a call between quadrant number 2 and quadrant number 3 – depending on what your current business strategy/ pull is. Simple. Do it over and over again and we will always provide higher value first.

Product Vision : The Key Role and Responsibility of Product Owner

Posted in Agile, Business Value with tags , , , , on October 19, 2009 by vikramadhiman

Continuing with the discussion on Product Owner role and responsibilities, and based on two excellent comments from Martizza and SJJH, let us review the key role and responsibility of the Product Owner. One can argue that the four skills/ competence areas highlighted in the Who can become a Product Owner post along with people management and interaction skills, help the Product Owner articulate, defend and refine the Product Vision. One can also argue that this is a separate skill and competence area and some people can just be better at this job even if they do not have the domain knowledge, are not technically sound or have the necessary experience. What will these people then typically possess? I think it would be a mixture of ability to learn [learn very fast], a highly analytical mind [capable of drawing analogies], intuition [strong emotional connect with real and abstract] and a thinking mind [one that can think even when it does not know it is thinking]. These people would generally believe hopelessely in what they are working on – and it is this belief and the conviction that helps them exude the product vision. Hence, when one is looking to appoint or hire someone for Product Owner position, one should see if they identify with the product and what are the ideas they bring to the table. If the connect is established, the rest of the work would flow a lot better.

So, what exactly does a Product Owner do with the Product Vision. They do 03 things:

1. Define the Product Vision – This involves close connect with the customers and market needs. Hence, domain expertise and exposure to tech support/ marketing comes in handy. Further, exposure to some sort of modeling methods helps the Product Owner define the product vision. Often, the Product Vision phase can take long. As a Product Owner, you may consult other domain experts, technical team or embark on marketing feasibility studies to confirm and reconfirm the vision.

2. Articulate the Product Vision – This is more important than 1. Typically, the Product Owner should be available to the development team anytime and everytime. The Product Owner should be able to sit down with different team members – together, in groups or alone – and discuss aspects related to the product – what will happen in 02 years, 02 months and what do they think could happen. This helps build the trust and orients the developers from a Product Owners perspective – a key requirement to build a great product. One of the means available with the Product Owner, to articulate the Product Vision is Product Backlog and ceremonies like Sprint Planning, Sprint Review help achieve this too.

3. Refine the Product Vision – Each time the Product Owner meets people from marketing, sales, technical support, development team, testing team or customers – they will keep uncovering new things about the product. It could just be new technology [Google Wave was launched a few days back for instance] or a new trend [micro-blogging and social media]. This can represent opportunities or threats. Product Vision is not stagnant. It is dynamic.

If a Product Owner can take care of the Product Vision, the Product would largely take care by itself.

Scaling Product Owner Role in Scrum : Potential Issues and Workarounds

Posted in Agile, Collaboration, Project Backlog, SCRUM with tags , , , , , on February 23, 2009 by vikramadhiman

In the previous post on “Multiple Product Owners or Not“, I analyzed if there is a case for multiple product owners. As per me, there can be grounds and case where this is a necessity. Now let’s see if we did indeed have 02 product owners, what will happen. The potential problems [I have seen these] could be:

  • Product owners have power – they influence the product direction. As long as 02 or more product owners agree on the direction, it is fine. However, product owners also influence product execution [user interface, test cases, priority]. These are soft areas and different people can interpret these differently.
  • Each product owner is likely to have more appreciation for their own features and their importance, than of the other product owner. If both of them feed a common development team, there would be issues of working together at some stage or the other.
  • If you have product owner depending on expertise [horizontal slices than vertical slices], there will be even more potential for disaster striking soon. Let’s take an example. Something which is good from SEO perspective, might not be so great from user interface perspective. If we have 02 product owners, one for SEO and one for user interface, major conflicts will arise.
  • Having a whole lot of people influence product direction can mean paralysis in decision making, where almost the bare minimum everyone can agree on, only gets done and anything exciting and challenging, will never even be attempted.

There are some things one can try, to make multiple product owners work together. Let’s look at some possible solutions:

  • One way to work around this is to have all the members of the team as stakeholders, but have a Chief Product Owner to have the final responsibility of prioritization. Hence, depending on the size and nature of your product, one might have group of people responsible for grooming the product backlog [design, SEO, user acquisition, interface, development, marketing] but only one person should be responsible for overall prioritization as well as decision making in case of conflict. The problem in this case is to identify such a person. Typically, such a person would be someone with great knowledge about the product, marketing and strategic objectives. This is the typical approach and this takes along specialists in various domains together. Although, this is against the idea of generalists not specialists, it is needed. I personally believe specialists have their place and very important one too. I have benefited as a Product Manager from people advising me on aspects I will overlook or most likely not even know. Specialists give me insight from marketing perspective – Internet Marketing (paid), Internet Marketing (organic), Offline Marketing Channels, User Behavior … one which [A] I won’t ever get time to analyze in detail or [B] would need enormous training to even get started.
  • Another approach is to divide the product in multiple sub-products. The Chief Product Owner can divide work to other Product Owners depending on their expertise, experience and importance of the features. This is commonly called feature teams. Organizations and products which spend time on this, reap benefits. We are getting started on this and this is streamlining our processes. There will always be areas where the Chief Product Owner would step in, but mostly delegation and scalability of product owner roles is supported through this model.

One Product Owner Only or More Than One?

Posted in Agile, Collaboration, Project Backlog with tags , , , , on February 21, 2009 by vikramadhiman

Once every few months, debate on “Whether there is a case for multiple product owners” comes back in Scrum and Agile Community. Most often, the response by Scrum Community is – No. There should be only one product owner and there CAN NOT BE more than one product owner. There are some [like me], who suggest that after the very first releases out, the product becomes too big and complex and multiple directions emerge and one person does not have full knowledge or expertise or even time to be able to do the job of a product owner effectively.

Let’s start by looking at the role of a product owner. Product owner is the main decision maker on behalf of the stakeholders, users, customers and clients. Product owner decides what is to be built and when. Product owner is not the only contact but most likely the primary contact for the team. If the team has only 01 product owner, it should theoretically move faster. One person would make faster decisions and team will get used to working with one person after a few sprints, fostering increased collaboration and more agility. This works fine if the product owner is available and qualified to make these decisions. However, this might not always be the case. As the product grows, there would be multiple directions, sub-products and large development teams. One product owner might just not be qualified or even available to take the product further. Hence, if 01 product owner is the bottleneck [does not have time, does not have competence], adding a product owner might be a good or only option. This is not always smooth and not without its problems. However, this is the only option available. And like scaling development teams and Scrum Master role, Product Owner Role also needs to be scaled.

The main argument against why there should not be multiple product owners, is that in Scrum, Product Owner is the single wringable neck. So, once you have more product owners, you won’t know whose neck(s) to wring? This according to me is a no starter argument in the first place. I have never understood the concept of single wringable neck at all. How can one person be so powerful as to be responsible for the overall success of the product? Product Owner trusts various people to give the right input. Product Owners listen to various people who give their own input and then prioritize features. Success or failure of these features [some of which can take time to reflect], are dependent on the advice. It is a collaborative, snyergestic relationship between domain heads and product owner. Both are in it together, and not separate. Further, the idea of single wringable neck goes against the ideals of Agile as well. What is the use of wringing someone’s neck after product fails? Why not start with “Everyone did everything in their power to make the product successful” thinking to the product owner as well? And, most importantly, can “we need 01 single wringable neck” potentially overpower a solution that can work [and works] of scaling the product owner role further?

In my next post : Scaling Product Owner Role in Scrum : Potential Issues and Workarounds

Business Alignment over Engineering Features

Posted in Agile, Collaboration with tags , , , on November 18, 2008 by vikramadhiman

In his blog on Product Management, Saeed proposes a fifth element to the Agile Manifesto:

Business Alignment over Engineering Features

His argument is that developers, testers and even managers treat each feature equally without worrying about how the business makes money. There were some interesting responses to this:

1. Jelena said that this is already contained in the Principles “Business people and developers must work together daily throughout the project”, and also can be filed under “Customer collaboration over contract negotiation” element of the Agile manifesto. She also goes on to say that sometimes engineering excellence is more important.

2. Others illustrated how product management and development can never reconcile.

I don’t think it is needed to have another element to the manifesto at all. As Jelena said, it is already contained in the principles and also in the elements. If a  Product Owner can not make efficient decisions and guide the roadmap, then the team can’t do anything. For instance, in the firm I work with currently, the Product Managers and Development Managers blend so effortlessely that you wont even notice, who is who. This closely aligns the business with the development. We prioritize, reprioritize vigorously and we make decisions collectively – sometimes development helps us make better decisions [what if we just made a single HTML page rather than all dynamic feature that you want and will take time] and sometimes businesses help development make better decisions [we need a guarantee that whatever was working before is working in future].

In essence, elements basically highlighted the importance of where our focus should be. Business Alignment over Engineering Features places a lot more emphasis on Business Alignment and takes the focus away from Engineering Features. This is also partly wrong – engineering features and excellence in itself is also sometimes desirable.

I am back and how …

Posted in WiZiQ with tags , on August 20, 2008 by vikramadhiman

Hello Readers: I really do apologize for the delay in posting on this blog. I have been really busy coming to grips in a role of a product owner. However, now I am back [I know I said this last time too], but this time I would be really active – one post a week is minimum. I start with our private beta testing of Live Virtual Classroom embed. See below, for more details:

http://vikramadhiman.bravejournal.com/

It is a perfect example of how product owners should get feedback. This private beta would allow me to test the application using a Web 2.0 approach and get back to the team with further upgrades [if any]. You can email me the feedback at vikramd at wiziq dot com

This embed was a marketing driven priority feature and done on priority. I would address how was this conceived and brought to private beta stage under one month in my next post.