Posts Tagged ‘Scaling’

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.

Less

LeSS (Large Scale Scrum) is an agile framework for 3-8 Scrum teams, but when there’s more than 8 Scrum teams it’s time to think about adopting LeSS Huge. So let’s look at the differences.

LeSS
LeSS is a scaled up version of one-team Scrum, and it maintains many of the practices and ideas of one-team Scrum. In LeSS, you will find:

In LeSS all Teams are in a common sprint to deliver a common shippable product, every sprint.

LeSS Huge

Less-huge

What’s the same as the smaller LeSS Framework:

  • One (overall) Product Backlog
  • One Definition of Done
  • One Definition of Ready
  • One (overall) Senior/Lead Product Manager
  • One Sprint

So what’s Different?

  • Area Product Managers
  • Area Product Backlogs
  • Area Product Vision
  • Set of parallel meetings per Area

It’s important to remember that these frameworks are just guides and every business has their own org structure, so it’s completely acceptable to mould a framework to suit the organisational structure and industry sector.