<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-GB">
	<id>https://go-else.org:443/index.php?action=history&amp;feed=atom&amp;title=End-to-End_Product</id>
	<title>End-to-End Product - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://go-else.org:443/index.php?action=history&amp;feed=atom&amp;title=End-to-End_Product"/>
	<link rel="alternate" type="text/html" href="https://go-else.org:443/index.php?title=End-to-End_Product&amp;action=history"/>
	<updated>2026-04-28T15:51:32Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://go-else.org:443/index.php?title=End-to-End_Product&amp;diff=19&amp;oldid=prev</id>
		<title>Ppugliese: Created page with &quot;__NOTOC__ == Description == When defining the scope of a product, it should ideally encompass an end-to-end value stream (single or composite). Likewise, the definition of the &quot;Product Group&quot; (the product development organisation) that serves the product will also span the end-to-end value stream. End-to-end in this context means that the scope of the value stream spans all activities from idea or request through to market success (internal or external consumers).   == R...&quot;</title>
		<link rel="alternate" type="text/html" href="https://go-else.org:443/index.php?title=End-to-End_Product&amp;diff=19&amp;oldid=prev"/>
		<updated>2024-01-23T23:40:18Z</updated>

		<summary type="html">&lt;p&gt;Created page with &amp;quot;__NOTOC__ == Description == When defining the scope of a product, it should ideally encompass an end-to-end value stream (single or composite). Likewise, the definition of the &amp;quot;Product Group&amp;quot; (the product development organisation) that serves the product will also span the end-to-end value stream. End-to-end in this context means that the scope of the value stream spans all activities from idea or request through to market success (internal or external consumers).   == R...&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;__NOTOC__&lt;br /&gt;
== Description ==&lt;br /&gt;
When defining the scope of a product, it should ideally encompass an end-to-end value stream (single or composite). Likewise, the definition of the &amp;quot;Product Group&amp;quot; (the product development organisation) that serves the product will also span the end-to-end value stream. End-to-end in this context means that the scope of the value stream spans all activities from idea or request through to market success (internal or external consumers). &lt;br /&gt;
&lt;br /&gt;
== Rationale ==&lt;br /&gt;
The essence of this principle is to design the product and services from a business value perspective and then design the team structures to match. This strategy is recommended to avoid shaping the product around organisational divisions, technology platforms or team structures (see Conway&amp;#039;s Law&amp;lt;ref&amp;gt;https://en.wikipedia.org/wiki/Conway%27s_law&amp;lt;/ref&amp;gt;), which could lead to&lt;br /&gt;
&lt;br /&gt;
* A poorly shaped product that fails to appeal to its target market and customers&lt;br /&gt;
* An unsatisfactory customer experience&lt;br /&gt;
* Unused features&lt;br /&gt;
&lt;br /&gt;
*Interdependent product elements required to deliver a complete customer proposition &lt;br /&gt;
*Additional complexity in the product(s) and the product development organisation(s) &lt;br /&gt;
*Greater challenges in splitting a larger product into smaller but still valuable subsets as part of a scaling strategy &lt;br /&gt;
While this is the ideal scenario, very often, large-scale product developments are organised as several &amp;quot;parts&amp;quot; being developed with different degrees of isolation from each other, resulting in the necessity of integrating and testing all the parts together at a later stage, which is one of the major criticism of waterfall development. As Winston Royce wrote in 1970: &amp;quot;The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. [...] and one can expect a 100-percent overrun in schedule and/or costs.&amp;quot;&amp;lt;ref&amp;gt;Royce, D. W. W. (1970). Managing the Development of Large Software Systems. &amp;#039;&amp;#039;Proceedings, IEEE WESCON&amp;#039;&amp;#039;.&amp;lt;/ref&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Agile proposes a solution to this issue, i.e. the concept of a Team developing a Product, which works beautifully for small products but is more and more difficult to implement in larger developments. This is why, where possible, it is important to [[Organise around value streams]] and ensure that product development is done &amp;quot;End-to-End&amp;quot;, i.e. there are no parts of the product development organisation delivering to each other (sometimes referred to as &amp;quot;components&amp;quot;, &amp;quot;internal products&amp;quot;, &amp;quot;frameworks&amp;quot;, ...). &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Related Principles ==&lt;br /&gt;
* [[Align towards business synergies]]&lt;br /&gt;
* [[Avoid Components]]&lt;br /&gt;
* [[Organise around value streams]]&lt;br /&gt;
* [[Minimise unnecessary complexity]]&lt;br /&gt;
* [[The Product Owner is accountable for sustained end value]]&lt;br /&gt;
* [[Minimum Viable Product Owners]]&lt;br /&gt;
* [[Limit Product Owner Mental Workload]] &amp;#039;&amp;#039;- Contending&amp;#039;&amp;#039;&lt;br /&gt;
* [[Reduce factors increasing product complexity]]&lt;br /&gt;
* [[Outcome is the primary measure of success]]&lt;br /&gt;
* [[Collective accountability in case of Product Ownership Group]]&lt;/div&gt;</summary>
		<author><name>Ppugliese</name></author>
	</entry>
</feed>