Monthly Archives: April 2014
Product Owners – like great products – must be developed. While some skills are innate, others must be learned and organizations tend to throw new Product Owners into the mix without adequate information. In this blog series, we have explored new product owners who are assigned to new products and those owning a system migration. Now we are going to explore a new product owner who takes over an existing product with a robust product backlog. In some respects, one might think this is the easiest of the three scenarios but it comes with its own set of challenges. Here are some tips for how to get started.
1. Get to know your customers
The first step to get your arms around an existing backlog is to understand your current customers. To do this, you need both
qualitative and quantitative information. Data is always your friend. How many customers do you have? Are they profitable? Are they the ideal customers that you want to attract? Once you understand the numbers, now you need to actually talk to customers. Schedule interviews with key customers – both happy ones and those that are frustrated. Use your strong product management skills by asking open ended questions. My favorite is “What keeps you up at night?” Let your customers talk or complaint or suggest – wherever the conversation goes can be valuable. Knowing who is buying your product is very important.
We have a problem with Product Owners in Agile. These are incredibly difficult jobs and it is easy to blame the product owner when things go wrong because “the requirements were not clearly articulated or prioritized.” That might be an easy path, but it often is neither correct nor fair. Instead of pointing fingers, let’s support our Product Owner and give them the training and tools that they need to be successful. Just like we introduced with developing New Products and explored with existing backlogs, here are some tips and tricks to managing system migrations.
Moving from old technology to new is a common project for Agile teams. Many companies have platforms that are no longer providing the necessary value and features to the marketplace and IT organizations are faced with the challenge of moving from an old, tired, inflexible system to a new, dynamic, configurable system. Or it might not be that dramatic – perhaps you just need to move from one software package to another for cost or vendor relationship reasons. Either way, a new product owner must discover how to break this big effort down into manageable chunks. How do you get started?
1. Analyze what is being used
The first step is to figure out what pieces of the legacy software are actually being used. There is no sense migrating functions or features that no longer matter to the organization. If you can weed out some portions of the migration to minimize the size of the effort, that is great news for the company. Some firms want to skip this analysis step and just build “like for like.” This approach will save time as part of the project prep, but it will cost precious developer time down the road.