Posts Tagged ‘Delivery’

Once you have validated that your product has market fit and you begin to scale, it won’t be long until the product roadmap starts to fill up with valuable product iterations. Soon after that, there will be an appetite from the c-suite to understand how the value on the roadmap can be delivered sooner.

Having to balance solving customer problems, MarTech, tech improvements, tech debt, regulatory, security, bugs, innovation and dev ops requirements with only one development team would make this extremely difficult, as there’s little room to work on some of these different types of work concurrently eg. customer problems concurrently with the more technical driven requirements to improve efficiency.

In order to deliver more value sooner and 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 manager role if delivery is to remain efficient and Lean.

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

Chief Product Officer (CPO)

  • Managing the Lead Product Managers (although there is often a Product Director to help with this)
  • Handling the high level product vision for the overall product

Head of/Lead/Senior Product Manager of the Product Line(s)

  • Market analysis
  • Product organisation improvements
  • Leading Lean initiatives to reduce waste across the business
  • Cross product line strategies
  • Customer analysis
  • Qual / Quant data analysis
  • Product line strategy
  • Product vision
  • Product roadmap
  • Capacity planning
  • Coaching / supporting product managers

Product Manager / Associate Product Manager working with the Development Team within a Product Line

  • Contributing to the product vision, roadmap and strategies
  • Qual / Quant data analysis incl. conducting customer interviews
  • Backlog prioritisation
  • Epic / feature scoping
  • PRDs
  • Requirement workshops
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • User acceptance testing
  • Retrospectives
  • Daily stand-up
  • Live product support

The Associate Product Manager could also be referred to as a Product Owner, Junior Product Manager, Product Executive or Business Analyst.

In order to have the necessary focus on the product vision, managing stakeholder expectations, quant/qual data analysis, prioritisation and product strategy, it’s important that when adding additional development teams to the product line that the product manager gets more support too, or otherwise the development team could easily fall into the build trap and start delivering features which customers don’t want or need.

Pipeline

With a long list of ideas / problems (features) to solve, there needs to be a solid view of exactly where features are in the idea to customer flow, so that anyone can view the status of a feature anytime without constantly asking.

Having a ‘feature pipeline’ report also proves helpful when providing stakeholder monthly / quarterly product updates.

A feature pipeline typically has multiple columns similar to a Kanban view, but it’s important to keep the content at a high- level (feature / epic) rather than stories.

Pipeline

Example Feature Pipeline Format

Some of the columns you’d have on a Feature Pipeline would be:

  1. ‘Idea’: which would be a long list of features sorted by value
  2. To Be T-Shirt Sized‘ (WIP 5): top 5 highest value features move over to a sizing column – in order for the idea to be prioritised on the product roadmap you need a rough size. It’s recommended to have a WIP (work in progress) limit
  3. Capacity Planning‘: once the feature has been roughly sized, it’s then possible to analyse when the feature can be worked on based on capacity and priority (value vs. effort (t-shirt size))
  4. Delivery Quarter‘: based on the capacity planner which should drive the start and end dates of features on the product roadmap, what quarter does the feature planned to be delivered in

There are plenty of tools available to visualise your feature pipeline eg. Aha! and JIRA and it’s a good idea to compliment that with a guide which includes SLAs for each stage of the pipeline and a t-shirt size mapping, so it’s clear what a ‘Small’ or ‘Large’ is for example.

Having a Feature Pipeline in your product toolkit for everyone to access when they want will help ensure that high priority ideas get to customers in a timely and transparent way.

Goals

No matter what product a development team works on, there will often be a big backlog full of high priority customer-centric / commercial work to deliver, technical improvements to make, bug fixing, getting after the next generation technology and security / regulatory / compliance work, so it’s important that there’s clarity over what the specific headline goals are for the development team to achieve over the next sprint / time period.

Some key points when setting goals:

  • They should be specific, but also be accompanied by a high level summary of the bigger picture
  • They should all be action-orientated
  • Make sure your goals are measurable so you know if they’re done or not at the end of the period
  • Indicate a period they’re valid for until they’re reviewed
  • Share the goals with stakeholders and senior management, as well as the review of whether the goals were ‘done’ or ‘moved over to the next period’
  • They should be realistic and the development team should agree to the goals

Setting frequent delivery goals is not only important so that the right focus is being spent on the right things which will increase the likelihood of making progress on solving the highest priority problems, but it also gives visibility of the overall progress made on product iterations and highlights problems in the process if goals are frequently not met, whether it’s due to build pipeline / environment issues or last minute dependencies for example, which should be discussed in the retrospective.

Setting delivery goals, reviewing, celebrating and learning from them should be the norm like it is when everyone’s objectives are set across the wider business.