Each stage is responsible for building functionality that furthers their vision and direction. Even if some components of that functionality happen to cross into spaces typically owned by other stages, they should still build it (if it's important to them).
If the feature isn't necessary or urgently needed to move forward (for example, it won't block another feature's development), then you can always consider putting it on the backlog of the stage that owns that feature.
Here are some guidelines for thinking about "Which stage should do this work?":
Ecosystemgroup by default. But again, if the feature is core to a stage's value proposition, they should go ahead and build it themselves.
This model allows teams to be flexible and calibrate their priorities accordingly, and no team should ever be "blocked." Exceptions may be items where a change requires anything that a software engineer would not be allowed to do, such as a production change, in which case the infrastructure team would be the blocker.
While any team can contribute features to any stage, it is recommended to loop in the most relevant PM from that Group to provide strategic support to help the contributing team align to the Group's broader plan and vision.
Below is a guide to help other product groups understand how to work on these areas and quickly locate the best parties who may assist on the subject matter.
This section is modeled after the engineering handbook version of ownership of shared services and components.
|Merge Requests||Code Review||Link|