Tag Archives: release planning

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.

Iterative Requirements Management

Your release plan is done (or as done as it’s going to be at this stage). Your best estimates indicate that the development team can probably implement the top 10 to 15 items to meet an acceptable window of opportunity. The team has committed to implementing the top 3 or 4 items in the backlog in the first iteration. So now what? Well, open Word with your trusty, well-used, highly refined requirements specification template and begin writing requirements. Right? WRONG! This template probably started with great lean-ness to it; but over time more sections were added to make it “complete” … until the next new section is added. I see this so often that I wonder why we do this. We essentially are asking our product management team to write full requirements specifications within a short period of time. If you have a small PM team, then it’s virtually an impossible request. The result is that requirements are late, incomplete, not at the right level of depth, maybe even all of the above. Which means that the development team will usually “wing” it, and the PM task turns into a retro-specing exercise. Whether using an Agile methodology or a Unified Process methodology, our development teams develop iteratively (at least they should). They focus in on the next iteration and “grow” the release as they move from iteration to iteration. They tackle the high risk items early in the project. Etc. Etc. So why are requirements managed differently? Maybe because the template was approved some time ago in response to some botched feature and no one took a step back and asked how this can be better performed.

The goal of documenting requirements is to record the needs of the users in terms that development can build from. In other words the spec translates what the user needs to solve one or more of their problems into a format that development can use to design and build from. The underlying goal is that the development team needs to understand what it is that needs to be built so that they can come up with a design and an estimate for effort and risk. Collaboration between product management (representatives of the customers) and product development is essential … throwing a fully-baked requirements spec over the wall does not constitute collaboration. Presenting the requirements in layers is a better approach to achieving the goal.

So let’s break this process down into three essential layers where we present information in ever increasing depth and amount until development understands what they need to do … and no further!

  1. Key Requirements. The first layer is an identification of the essential requirements – those that drive / shape the feature or capability. These are the requirements that are non-negotiable, i.e. you can not go to market without these being met. The first step is to make sure that these key requirements are captured. I recommend no more than 5 requirements, expressed as user stories or high-level use cases or declarative statements – the point is that you capture them so that the development team understands them. Present them to the team (or a subset of the team) as soon as you have them, from which they should begin thinking of the design and effort and risk.
  2. One-page Requirements Document. If step 1 is not sufficient enough, i.e. the development team does not have enough information to come up with estimates for effort and risk, then the next layer is to create a single page requirements specification. Add detail such as usage scenario, actor/persona, problem solved and more depth to the key requirements and possibly even more requirements. Remember that the goal does not change – development needs to get to a level of understanding where they can come up with a design and effort and risk estimates.
  3. Requirements Specification. If the previous steps are not sufficient, then the full-blown requirements spec is the last layer. In these cases the feature / capability is possibly something brand new being added to the product. You should consider maybe dividing this into smaller chunks; in some cases that may not be possible.

By managing your requirements iteratively you can put the appropriate amount of effort into your requirements that’s needed to achieve the goal (i.e. develpoment understands what’s needed from them). Do not waste your time writing requirements that do not add value to achieving this goal. In other words, once you have reached your goal, stop and move on to the next item.

Re-focus the feature debates!

How often as Product Managers do we get into a heated debate over whether Feature A (the cool, sexy one) or Feature B (the mega-reported annoyance) should be included in the next release? Far too often we are in the middle of these heated, opinionated discussions – resources are limited, time is limited so the debate rages on. Invariably the person with the strongest will or voice wins or the biggest, most important customer wins or both.

We always have to remember that product features are like a marriage … until death do us part! In other words, once the feature is in the product you have to support it forever – somebody will always use it; somebody will always want a new and improved version. And to make matters worse, it is an incredibly messy process to get rid of it. The only features that should make it into a release are those that positively impact the company’s objectives – increase revenue, extend marketshare, increase customer satisfaction are all good objectives.

The challenge we face is how to objectively evaluate the myriad of feature requests that come across our desks. The problem that I’ve seen far too often is that the discussion or debate is focused at the wrong place. Instead of debating whether the feature should be in or out, the debate should be around how well a feature meets the business and/or release objectives. Here are examples of a couple of objectives that I found to be very useful:

  • Improve Sales Wins – this objective speaks to the idea of winning more sales engagements. Some features absolutely shine during the sales engagement and others have no impact whatsoever. Features that shine are either very demonstrable or the sales team can speak to them with great impact. Another way to think of this is a resonation factor – features that resonate with the prospect. So the debate surrounding a feature is now, on  scale of 0, 1, 3, 5 how well does this feature meet this objective? 0 – not at all; 5 – home run!
  • Broad Market Applicability – this objective speaks to the broadness of the applicability this feature has with the target market. In other words, you want to add features that apply to as many of your target markets as possible – outliers are not necessarily a good thing. Again, on a scale of 0, 1, 3, 5 how many markets does this feature resonate with? 0 – none; 5 – all of them!

You can add more objectives like these two – I recommend no more that 5 – 7. You can have one or two that are product oriented in nature … word of warning – do not make them too granular, go with something that adds or improves a capability that is a key component for your target market. And lastly, you want to apply a weighted formula to calculate a total score. If your corporate objective is to win more new-named accounts, then weight the Improve Sales Wins higher – that way any features that really help meeting this objective will be ahead of other requests.

The result will be that your scarce resources (development, qa, documentation, etc.) will be focused on the features that help your company achieve its goals.