Posts Tagged ‘Roadmap’

Scale

Once a product is mature and the product roadmap is filled up with valuable product iterations, it’s likely that the product owner and senior management will be keen to find out how some of the financial value driving product iterations can be delivered sooner.

Whilst having to balance technology improvements, technical debt, regulatory, security, bugs, dev ops and business requirements with only having one development team on the product stream would make this difficult, as there’s little room to work on multiple different types of work concurrently eg. business requirements concurrently with the more technical driven requirements.

To work on different sets of requirements concurrently, the product would need to scale which would involve adding additional product development teams to the product line. With more development teams working on the product would also require additional firepower from the technical architect and product owner role if delivery is to remain efficient and ROI positive.

An example of how you can scale the product owner role across multiple development teams who are working on the same product line:

Chief Product Owner (CPO)

  • Responsible for ensuring that the Product Owners are handling their product lines effectively
  • Handling the high level product strategy across all product lines

Product Owner (PO) / Senior Product Owner (SPO) of the Product Line

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Backlog grooming
  • Sprint planning

Product Owner of the Development Teams (Associate Product Owner (APO))

  • Customer analysis
  • Epic breakdown
  • Requirement workshops
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

The Associate Product Owner of the development teams could also be referred to as Feature Product Owner, Junior Product Owner or Product Executive.

In order for the Product Owner to be able to focus on the product vision, prioritisation of the product backlog and product strategy to ensure the product remains competitive, it’s important that when adding additional development teams to the product that they get additional product owner support to help them out with the more tactical day to day activities, as you can see from the split in tasks above – Product Line Owner handling more strategic tasks especially prioritisation in all instances and the Associate Product Owner handles more tactical tasks.

Spreading a product owner too thin with little support could result in a lack of focus on both product strategy and getting product backlog items delivered in an efficient way.

Once you’ve created a solid Product Vision, it’s likely you’ll be asked to provide more granular details on the ‘what’ and ‘when’ and the Product Roadmap is a great way of helping you answer that.

The product roadmap is also a good way of giving the development teams an idea of the exciting upcoming features / problems to solve for the product.

Key points of a Product Roadmap:

  • It should be at a high level eg. Epic, feature or iteration level – Epic level is a preference as then it maps nicely to the product backlog items (PBI)
  • It needs to include dates spanning the next twelve months whether monthly or quarterly
  • The bars on the chart show when items start and when the development will be complete (live hidden)
  • One of the most important things is to educate development teams and stakeholders that the drop dates are an intent (not commitment) of focus / delivery and that things can and will likely change, so it’s advisable to avoid spending significant amounts of time making each item exact, as the desire from the business would be to have a rough idea of the twelve month view rather than knowing whether something starting in six months time will be delivered exactly a month later than that for example
  • The roadmap needs to be easily accessible by anyone in the business where they can use their network login and can also access it from outside the office eg. on the train – if it’s hard to access, people just won’t view it and assume there’s no plan
  • It needs to be updated frequently – if it’s regularly out of date, again people just won’t access it

Product Roadmap examples

Roadmap sample 1

Roadmap sample 2

The most important thing about the Product Roadmap is to always provide a sign of intent for when product items will be delivered over the next twelve months, with the key word being ‘intent’ here ie. Not exact drop dead delivery date and a couple of people with experience of productivity could use gut feel which is totally acceptable, rather than dragging developers away for days on end to roughly size big pieces of work which will either 1. Change anyway and 2. Be extremely inaccurate as unknowns result in estimates going through the roof.

A sign of intent for the next twelve months for the product is also better than a half empty roadmap!