Agile Product Management
Okay, before we dive into the tips on Agile Product Management, let us first look into what Agile Product Management is! A Product Owner in the Scrum Framework is the single person who is responsible for the success of a Product and for maximizing the value of that Product. In the Scrum Framework, a few of the Product Owners’ responsibilities are described, such as Product Backlog management, maximizing value and stakeholder management. Besides these responsibilities, the Product Owner role also has a lot to do with product management! So, a Product Owner is a sort of Agile Product Manager.
The Product Owner role is totally different from traditional roles that are know in most organizations. Some people think that the Product Owner is a kind of ‘Agile project manager’ or that the Product Owner is sort of a ‘business analyst’. This is not true! The Product Owner is really the owner of the Product. He or she is the single person that is responsible and accountable for the success of the Product. The focus of a Product Owner is therefore not on ‘doing projects’, but on delivering, maintaining and marketing the Product!
In this post, we’ll cover 10 tips about Agile Product Management. Also check out my other blogs with tips for the Product Owner (see the links at the end of this blogpost). I hope you enjoy them!
10 Tips for Agile Product management:
Act as a Product Leader, not as an ‘Agile projectmanager’
A project manager is responsible for managing scope, exceptions, ‘resources’ and reporting (amongst many other things of course). As a Product Owner, your job is not to manage ‘resources’ or ‘tasks’. Your job is to maximize the value for your product! To create those features that deliver the most value for the products’ users! In order to maximize the value of your product, you don’t have to manage stuff like tasks, what people do on a daily basis, what the progress of the team is in a Sprint. All this can be managed by the team itself. So stop micro-managing the team and start maximizing the value of your product, in collaboration with users, clients and stakeholders!
Explain to your stakeholders why you’re working Agile
Agile isn’t a hype, nor is it something you ‘do’. It’s a mindset. It’s a set of values and principles which guide you. Scrum is a framework. It’s a framework used in complex environments to develop and maintain complex products. The way of working, the values and principles you want to embrace are quite different from traditional ways of working. This also goes for the culture and governance of the organization. Stakeholders need to their way of thinking and behavior as well, so you’ll need to invest time (together with your Scrum Master or Agile Coach) in coaching your stakeholders and explaining Agile to them.
Be ‘product oriented’ instead of ‘project oriented’
A project (in it’s definition) is something that ends. A project is a temporary organization which is created in order to deliver a specific scope, within a certain time period and budget. A Product Owner however should focus on delivering a Product. And guess what? Product Development doesn’t end as long as the Product lives! Also, we measure project success in different ways than measuring product success. A project is typically successful when the upfront agreed scope was delivered on time and within budget. A product however is successful when it’s being adopted, used and valued by the products’ users.
Improve your time-to-learn (instead of time-to-market)
A lot of people and organizations are focussed on reducing the ‘time-to-market’. of course, this is valuable, because you’re able to deliver stuff to your customers more quickly. As a Product Owner, you want to maximize value for your customers, so delivering faster and more often sounds good right? Sure it does! There is one catch though… You can’t determine value upfront… What? That’s right! You can’t determine value upfront! Whether or not something is valuable, is determined by your customers and users. Based upon their usage of the product and the feedback provided by them, you’ll learn what valuable is and what isn’t. So you should only improve your time-to-market, you should focus on improving your time-to-learn! Time-to-learn doesn’t only mean going to market, but it also includes the gathering of feedback from the customers and users. Time-to-learn is therefore more interesting, since it also includes the feedback loop from the customers/users, there where time-to-market doesn’t include the feedback loop.
Take responsibility for the success of the Product
As a Product Owner, you’re responsible for the ultimate success of the product. I see a lot of Product Owners who are ‘responsible’ for parts of a system, or who are ‘proxy Product Owners’ that are managing the Product Backlog on behalf of someone else (who isn’t available). Also see my blog on tips for starting Product Owners to read more about the Product Owners’ maturity levels.
Stop ‘waterfalling’ in Sprints, start delivering value for customers/users
We see a lot of Product Owners that are doing Scrum within a project. I also see a lot of Product Owners who are slicing systems in system layers (like front-end, back-end, middleware, hardware, etc.). This won’t help you in maximizing value. For example, a complete architecture doesn’t contain any value for a user. An end-to-end slice of a feature however, does have value for a user! So don’t deliver a system layer in a Sprint, deliver an end-to-end feature! Another example I see often, is teams that create the design in one Sprint, they develop in the next Sprint, they test in the Sprint after and finally deliver to a user in the fourth Sprint. This means you’re not delivering any value for users until the fourth Sprint! Try to make the Product Backlog Items smaller, so you can deliver an end-to-end feature in one Sprint!
Understand that more analysis doesn’t (necessarily) make the Product better
A lot of teams are used to working in projects. Projects are excellent ways of working in complicated environments, however, not so much in complex environments (see the Cynnefin model). In complex environments, you need an empirical approach, such as the Scrum Framework. In complicated environments, problems have a typical cause and effect. Therefore, doing more analysis upfront will result in a better solution at the end. However, in complex environments, problems may have multiple causes and multiple effects. This means that the best approach is not to analyse more. The best approach in complex environments is to take a step (act), than observe what happens (sense) and than react to the new data gathered (respond). So dear Product Owners, please embrace that the world isn’t predictable, but start doing more experiments, tests, releases and gather feedback from the marketplace!
Market research, sales and marketing are part of your responsibilities
A lot of Product Owners are only responsible for a system, or part of a system. However, this doesn’t embrace the idea of a Product Owner being an actual owner of a Product. Of a Product Owner being an entrepreneur (which is the ‘highest’ level of Product Owner maturity). An entrepreneurial Product Owner, someone who is ultimately responsible for the success of the Product, is also responsible for market research, sales, marketing, etc. etc.
Focus on increasing value (outcome) instead of increasing velocity (output)
Many, many, many Product Owners are focussed on increasing the velocity of their team(s). Please stop doing this! Measuring the Velocity of a team is based upon a relative estimation technique. This means that story points are a relative value. It’s extremely easy for teams to double their velocity and if you ask them to do this, they will actually double their velocity in seconds! They will just double or triple al their estimates!!! So don’t compare teams based on velocity, nor focus so much on improving velocity! Start focussing on value! Measure the value that’s delivered by the team, measure the impact of new deliveries on your Products’ KPI’s, measure customer/user satisfaction, etc, etc.!
Be a dolphin, not a submarine!
Our final tip on Agile Product Management is to stay in the water surface (like a dolphin). A dolphin only goes under water for a short period of time and then comes up to the surface again, said differently, a dolphin remains visible. In complex environments and in complex product development, you need to get feedback from customers and users early and often. A lot of Product Owners however are tempted to stay under water for too long (like a submarine). They have the idea that if we spend ‘a little more time’ on the Product, we can make it ‘perfect’ for our customers and users. Don’t do this! It won’t help you to spend more time on the Product, but it will help you to release early and often, to deliver to your customers and users and to get their feedback. This approach will help you much more in maximizing the value for your Product.
So, these are the 10 tips for Product Owners on the topic of Agile Product Management! I hope you enjoyed them and that they’ll help you in becoming a better Product Owner!