Is your Product Management process Agile?

I’ve read many articles on whether product managers need to become agile as the development team embraces an Agile development methodology. Saeed wrote a great article for the March ‘09 pragmaticmarketing.com newsletter proving that, in accordance with the Agile Manifesto, product managers have been living the elements of the Manifesto for some time (but may not have known it). Having been with companies that decided to ditch non-Agile methods and embrace Agile development the biggest challenge for my PM team was not for the product managers to become agile (or more agile) but instead the timing of when they perform their activities. Long gone where the days of a 6-8 week planning cycle where product managers brought everything to the table and the horse-trading began. It now meant that the team had to on a regular, timely basis (synchronized with the iteration cycle) prioritize new requests for the backlog, analyze the current backlog, and describe the usage scenario and key requirements as quickly as possible … as well as meeting with customers, performing market research, liaising with the development team on the work items of the current iteration, etc.

It also meant that the team became engaged with the project throughout its lifecycle on a more consistent basis instead of cyclical as was the case with the non-Agile method – i.e. the PM resource loading for the project remained relatively constant. It also meant that they needed to iterate through the requirements gathering / analysis / documentation process. First was to understand the top 5 requirements that meet the request and convey that to the development team. Next was to drill a little deeper in areas where dev neede more understanding. And lastly was to stop, when dev understood what was needed (I recommend reading Lean Software Development by Poppendieck – it provides a great discipline for this type of an environment).

In order to become business-driven in an agile world, product management processes need to be tuned so that product managers can perform all the activities that are needed so that business objectives are met.

Transitioning to a product model

I met with another company that is struggling to transition from a services based business model to a product based business model. Many hi-tech companies start out with a single contract to provide a solution to a particular client. They find more clients that need to address the same set of requirements … sort of – the solution is customized for each and every client. The net result is a handful of one-off solutions to different clients that address roughly the same need. Revenue grows; number of new-named accounts increases and now it is time to scale the business to the next level. Clearly creating these one-off solutions is not a scalable model – you are bounded by your development resource pool. The transition from a professional services driven model to a product-driven model needs to take place. A product-driven model revolves around the sale of a single (possibly configurable) product to customers who have the same needs, or problems that need to be solved. In other words, you develop a single product that you sell to many customers in your target market.

Sounds simple! But there are many challenges to making this transition … here are some of the key challenges:

• Moving away from the culture of ‘Yes’ – in a professional services model your goal is to secure that single contract and so saying yes to the wishes of that single customer to win that contract is paramount. In a product-driven model your goal is to sell your single product to as many customers within your market as possible. This means that you have to learn to say ‘No’. When a customer requests something, you have to determine if it has broad market applicability – if it does not have broad market applicability, then saying ‘No’ is your best answer. Why? You have finite resources and they need to be laser-focused on meeting your goal to secure as many customers from within your market as possible … divergences that do not move you towards your goal is a waste.
• Changing the feature debates – if the customer, in the professional services model, decides where you should deploy your development resources; who decides in the product-driven model? Clearly you make the decision; but at what level do you decide what to put in the product? Far too often the debate rages at a very high level, i.e. each of development, marketing, sales, customer support, etc. have their own top priority item that must go into the next release and so the discussion ends up being opinion-based. Business-driven product management brings the discussion level down to the objective level, i.e. the debate needs to be centered around how well each feature request meets a set of business objectives. The end result is that the business objectives control what goes into the product – not some subjective opinion.
• Assigning new ownership – in a product-driven model, product management owns the product. In other words, through their deep understanding of the market, their ability to objectively analyze requests, and with their full and complete view of the product, product management decides what goes into the product. The owner in the professional services model is the project manager or the account manager and their responsibility is solely focused on the client … not the market.
• Developing a process-driven approach – process has been given a bad rap. No one wants to be process heavy. On the other hand, a lack of process will not deliver the repeatability necessary to become a product-driven company. The process in this case is the clearly defined steps you go through to decide what features to put in the product, the interaction between product management and development. This process is the core of a product-driven company – if it does not operate efficiently and cost effectively, then delivering your products on-time with the right feature set to meet your goals will be a struggle.

Let me know if you can think of other challenges. Maybe you have an experience you would like to share.