Tag Archives: agile methodology

Product Marketing for an Agile World

At this month’s OCRI Zone5ive meeting I delivered a presentation entitled Product Marketing for an Ever-changing World. [The Ottawa Centre for Research and Innovation (OCRI) is Ottawa’s leading member-based economic development corporation for fostering the advancement of the region’s globally competitive knowledge-based institutions and industries.] The goal of this presentation was to educate the Zone5ive membership on how they can become more effective as the development team shifts to Agile development. This transition does not just impact the development team, it also impacts Product Marketing, Product Management and Marketing.

The net result is that product marketing (and product management) teams will have the ability to engage customers early and often throughout the project which will increase the chances of a successful product (or release) launch. In other words, by engaging customers during the project, they will feel like they helped shape the release (or capability or feature) and so will be in a better position to talk to the press and industry analysts. They will also help you with your messaging, i.e. they will provide with real value statements.

Transitioning from Waterfall to Agile

Is your transition plan in place? Are you thinking ahead to that inevitable moment? Summer holidays are starting to happen. I can, with almost 100% certainty, state that a product manager in some company will return from holidays to hear that familiar refrain – ” we have switched to agile … oh by the way where’s the backlog”.

So before that happens when you, Mr. Product Manager, return from your fabulously relaxing holiday and you get even further behind, here are some important ideas to ponder and some key items to have at the ready before you head out on your holidays.

  1. Make sure that you have a system and process in place to easily and quickly manage your list of enhancements (the requests from customers and what you need to do to your product to help increase sales in current and potential markets). In the old methodology you were able to assemble and debate the features on the list early in the project and that’s what development agreed to build over an agreed upon timeframe. Now however the cadence of your development team (e.g. the sprint or iteration length) is short and so you need to be able to re-prioritize your list very quickly; you need to add and prioritize new items easily and quickly; and you need to be able to handle changes in business priorities very quickly. Before every sprint your list needs to be up-to-date.
  2. Make sure you reset the expectations of your executive team. In the old methodology the executive either fully participated in creating the list of features or they were peripheral to the process but kept their finger on the status of the meetings. In any event, the result was a list of features that development agreed to build within the agreed timeframe. Now with an agile methodology your executive has visibility at the sprint level. In other words, the horizon of agreement is far shorter with this new methodology; they do not have the full list of features that will be in the release – it is revealed sprint by sprint. The upside for your executive team is that the ability to embrace and react to change is far easier than with the old methodology.
  3. Make sure that you have a system in place that gives as much visibility of the project status as possible to as many stakeholders as possible. Your system should be easy to update from one sprint to the next. Executives like the high level picture – what enhancements are done, which ones are underway and which ones are ‘on deck’. Make this information available to them in real-time and make sure that the status is updated as soon as the state changes.
  4. Make sure that you have the ability and a process to assess when you have developed enough value for the release. Early in the project define the objectives of the release. Then later in the project, evaluate what has been completed against the objectives at the end of every sprint. At some point you will need to decide that you have enough value to go to market with. Everyone needs to be in agreement as to how this will be evaluated.
  5. Make sure that you gain an understanding with development on the product manager vs. product owner roles. Understand the product owner role and the differences / similarities with your role as a product manager. If you take on the product owner role then make sure that development understands that you still need to leave the office and visit customers – maybe at the most inopportune time.

If you think through these points and come up with an action plan, your transition will be relatively smooth.

Are you now a Product Manager or a Product Owner?

Agile has certainly changed the way Product Managers are perceived. In fact it raises the question within organizations that are moving to an Agile environment about what Product Management does. It raises the role of the product manager and the need for product management to the executive ranks – if it was not there already. But even though product managers have that title, are they really performing this role in an Agile environment. There are many blogs and tweets about this topic; my goal is to determine how many product managers in companies that use an Agile methodology actually perform the tasks of a product manager or do they in fact perform the tasks of a product owner.

Before we get too far ahead of ourselves, let’s look at some of the key activities for a product manager and for a product owner.

Product Managers own the product roadmap and the release strategy – they worry about the big picture. They work with all the stakeholders to maintain the roadmap and thus each of the releases and the vision for those releases are part of their responsibility. To do this effectively they need to get out and visit customers and be “plugged-in” to their target markets and the problems these markets have. They define the priority of the enhancements needed for the product based on meeting business objectives. To them the success of the product is paramount. They look for new markets for the product or ways to expand the reach of the product in existing markets.

Product Owners are responsible for delivering to the release plan – they are heavily involved in the day-to-day operations. Their focus is iteration by iteration. They write/elaborate user stories and prioritize them for each iteration so that iteration deadlines can be met. They virtually “live” with the development team(s), attending all stand-up meetings through each of the iterations. They understand the user stories extremely well and deep.

So now onto the poll.

[poll id=”3″]

If you picked that you are a Product Manager and primarily perform product owner activities, please answer the following.

[poll id=”4″]

Both roles are key to delivering products. Smaller companies in most cases cannot staff both positions. But it’s imperative that all companies understand the difference in the roles and make sure that both are adequately covered and that clear lines of delineation are drawn between the roles.

Thanks for participating.