Create include-product-owners.md

README.md

@@ -57,7 +57,6 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Assisted Compliance](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/74) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 * [What Before How or Services Documentation](https://docs.google.com/document/d/1_N1wsQeDusfIcNy-O2ZXenY3PL7ZbvkUDRZxGUuegZw/edit?usp=drive_web) - *A lack of common understanding between different management tiers creates funding barriers and increases the risk that solutions will not deliver required business outcomes.*
 * [Open Source Trumps InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/46) - *People find the InnerSource project but, after all things are considered, even if the InnerSource component meets their needs, they still go with the open source component.*
-* [Include Product Owners](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/71) - *Key Performance Indicators (KPIs) for Product Owners are primarily product focused, and don't consider areas such as collaborative development. This results in a lower level of engagement with inner source projects.*
 
 ### Maturity Level 1: Initial
 
@@ -77,6 +76,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Code Consumers](patterns/1-initial/code-consumers.md)
 * [Explaining InnerSource to Management by anchoring it to Agile / DevOps / Lean](patterns/1-initial/concept-anchor.md)
 * [Reluctance to Receive Contributions](patterns/1-initial/reluctance-to-accept-contributions.md) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined.*
+* [Include Product Owners](patterns/1-initial/include-product-owners.md) - *Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.*
 
 #### Donuts (needing a solution)
 

patterns/1-initial/include-product-owners.md

@@ -0,0 +1,72 @@
+## Title
+
+Include Product Owners
+
+## Patlet
+
+Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.
+
+## Problem
+
+Key Performance Indicators (KPIs) for Product Owners are primarily product focused, and don't consider areas such as collaborative development. This results in a lower level of engagement with InnerSource projects.
+
+## Forces
+
+* KPIs discourage Developers from contributing to others via InnerSource.
+* Product Owners have different priorities that may not align directly with InnerSource priorities. Product Owners are focused on their ROI in alignment with Product Management.
+* Product Owners may not be as focused on the longer-term benefits of InnerSource because many of their own metrics and goals are shorter lived.
+* Product Owners may not be aware of the benefits of InnerSource
+* Employees desire to grow their own circle of influence, which leads them to limited sharing of their own resources.
+* Some people lack understanding of the up-front impact and cost of InnerSource in terms of resources, because they are more focused on the efficiencies that it can provide.
+* Product Owners might not use Development tools and may therefore lack the opportunity to find out about InnerSource offerings and opportunities for collaboration and reuse.
+* Fear of loss of control.
+* Resistance to allow people to join and contribute.
+* Motivation: For the receiving Product Owners, there are big benefits of external contributions.
+* Motivation: Some are motivated to contribute because it is the only way that their desired feature will make it into the codebase.
+* Lack of motivation: If Developers don't see what's in it for them to contribute, they might not be highly motivated to help.
+
+## Context
+
+* Teams and individuals are not rewarded for software component reuse.
+* Motivations of the product(s) are not aligned with the InnerSource initiative.
+* Every product area has their own limited resource/budget.
+* Delivery deadlines are not movable.
+* Product Owners rarely make compromises regarding technical items in their area.
+* InnerSource changes resource distribution and requires up-front discussions, which require time allocation.
+
+## Solution
+
+* Talk with the Product Owners to understand their priorities. Prepare for this discussion by understanding their user stories, backlog, and roadmap if possible.
+* Ensure that Product Owners are aware of the benefits of InnerSource that they might care about most, including:
+    - Reuse. Teams can avoid writing new software from scratch because they can leverage and/or existing code.
+    - Savings of time and money. It may cost more for a team other than the original team to write it, but it costs less than   writing it from scratch.
+    - Staff augmentation for the receiving team.
+* Change the collaboration model on the product side. Bring the impacted Product Owners together to discuss the InnerSource project and choices related to resource allocation. Technical collaboration will result in better quality decisions. Overall resources cost could be lowered for some areas. Having the conversation builds trust and may result in evolution of the software component.  
+* If possible, implement effective enterprise search.
+* Adjust KPIs to motivate people to collaborate and reuse. Work with leadership to get support.
+* Internally advertise opportunities for reuse and collaboration. This can be done with blogs, success stories, providing a searchable list of projects to work with, and other methods.
+* Create a champions program and have them identify project opportunities.
+
+## Resulting Context
+
+* Initial time investment is rewarded by the outcomes.
+* Product managers are now collaborating with one another.
+* Resulting development costs less overall.
+* Product owner KPIs might not change but reuse collaboration still occurs (a faster way to achieve them).
+* Product owners factor in InnerSource so they reach their KPIs more efficiently.
+
+## Known Instances
+
+* PayPal is looking into finding a search solution for their project Agora. They are collaborating with other teams pursuing a similar mission, eliminating redundancy and inefficiency regarding effort and tools.
+
+## Status
+
+* Initial (still missing Patlet and at least one Known Instance)
+* Created at the Spring Summit 2017 in Geneva, Switzerland
+
+## Authors
+
+* Silona Bonewald
+* Alex Bozic, Bloomberg
+* Erin Bank
+* Tim Yao