Create outline for product focused learning segment

As suggested earlier in Slack I used the outline template to get my first ideas for what a product development focused learning path segment should contain. Some of the content is based on existing patterns, some is based on in-person conversations. This is a very early very rough draft of a sketch of an outline. I do hope that based on what is there others with more experience than myself get an idea of the general direction I would like to take this and add other relevant points to it (disclaimer: I am not a product person myself, so it is very likely I miss aspects).

Author: MaineC

product/outline.md

@@ -0,0 +1,44 @@
+# Audience
+
+While the content of this segment can be intersting to engineers in order to help their teams better navigate business decisions related to InnerSource the core audience are people in your team and across your organisation that deal with product development. The goal of this segment is to help you understand how InnerSource can help interdependent teams resolve requirements without syncing work to the point where both teams operate in lock-step.
+
+# Takeaways
+
+After going through this segment, you will:
+
+* understand how Agile software development relates to InnerSource:
+   * Which problems does InnerSource address that cause issues in typical agile teams? (Think "wait it out", "build workarounds" vs. "help with the solution".)
+   * In what aspects does InnerSource differ from agile or traditional software development - in particular when the same terminology and technology is used? (Think "Issue tracker for backlog/ board management vs. issue tracker for communication", "code review as quality gate vs. continuous code review as a conversation").
+*  understand how even with InnerSource the host team still has to plan time and capacity when receiving features as pull requests as opposed to features requests.
+*  understand additional negotiation possibilities that InnerSource brings (think "host teams implements tricky feature request of contributing team, in return the contributing team helps with simpler features that the host teams has higher up on their priority list")
+
+# Outline
+
+InnerSource and Agile
+
+- Issues InnerSource solves
+- Common mis-understandings
+
+
+InnerSource and capacity planning
+
+- Small vs. large changes
+- Planning for mentoring
+- Contributions as long term investments in your upstream InnerSource project
+
+
+InnerSource and contribution negotiation
+
+- Small vs. large changes - why smaller changes are easier to integrate ad-hoc than large refactorings
+- Best practices for integrating large refactorings
+- Unconventional solutions to priority conflicts
+
+
+Options for shared ownership
+
+- Common hurdles (line management, performance review setups)
+- Advantages
+- Commons issues wrt. operations and solutions
+
+
+Relation to open source