![\"product](\"https:\/\/www.pragmaticinstitute.com\/wp-content\/uploads\/2020\/08\/Untangle.jpg\")
<\/p>\n<\/p>\n
<\/p>\n
Many organizations struggle to define their products. They have complex products that do a lot of different things for a lot of different people, making it hard to say what the product really is, what value it delivers and to whom.<\/p>\n
Why is this bad? In a word, focus.<\/p>\n
The more things a product does for more people, the more complex it becomes, the harder it is to use and the harder it is to deliver. Complex products that are burdened with features no one understands\u2014but no one can kill\u2014create organizational complexity, increase costs and result in baffling products that frustrate customers.<\/p>\n
To cut through this, my simple definition of a product is \u201ca vehicle for delivering outcomes to some group of people.\u201d With luck, these outcomes achieve value for the user as a result of a positive change. The customer (or user) finds value in doing<\/em> things they couldn\u2019t before or experiencing<\/em> things they hadn\u2019t experienced before.<\/p>\n The best products deliver a relatively small set of positive outcomes to a group of people with a common set of needs. To illustrate the importance of simplicity, consider when you\u2019re preparing dinner and you need to cut some vegetables. Which will better meet your needs: a multi-tool pocketknife or a chef\u2019s knife? And which knife would you prefer if you\u2019re hiking in a wilderness of unknown conditions?<\/p>\n Different people have different needs in different circumstances\u2014each of which is served by different products that deliver different outcomes. A lot of product professionals talk about \u201cthe customer\u201d as if there is such a thing as a single user with a single set of needs. This language prevents people from seeing who really uses the product and why.<\/p>\n Going back to the knife example, I have both types of knives, so I am \u201cthe customer\u201d for both. But focusing on all my needs at once is confusing. Instead, focusing on my desired outcomes under specific conditions yields better insights:<\/p>\n <\/p>\n <\/p>\n Outcomes focus on the end result and the context in which I want to achieve them, not the means by which I achieve them.<\/p>\n <\/p>\n Many organizational scaling problems come from large, complex, and poorly focused products. The more a product does, the more people need to be involved in its development. As a product grows beyond something a single team can develop, the cost and complexity of delivering that product increase exponentially.<\/p>\n Rather than trying to figure out how to scale product development, first, try simplifying a complex product into two or more simpler ones. If the product is getting too complicated, if it delivers this<\/em> outcome to one group of people, that<\/em>outcome to another group, and another<\/em> outcome to a different group, it might be time to split it into several products.<\/p>\n <\/p>\n <\/p>\n For example, in Figure 1, \u201cProduct Polyglot\u201d does a lot of different things for different people in different situations (by way of metaphor, it speaks in different languages to different groups of people). There also are some shared capabilities (the black dots) that benefit all users. By splitting Polyglot, each product becomes simpler to develop and use. There is a little complexity to manage the common capabilities in each, but there are ways to manage this\u2014and using shared components is just one.<\/p>\n By dividing Polyglot, each product serves its customers in the simplest possible way. Each product development team can get to know their customers and their unique needs more intimately, thus producing better results.<\/p>\n Of course, there are some products that, if they delivered only a single outcome, they would be less usable. For example, think of using a single smartphone clock app (rather than separate apps) that tells your current time as well as the time in various time zones and has an alarm clock, stopwatch and timer.<\/p>\n An ideal product bundles related outcomes because people tend to think of them in similar ways. Likewise, that ideal product may be less costly to produce because similar expertise is needed to produce it.<\/p>\n <\/p>\n There is a good way and a bad way to split a big product into smaller ones. The bad way clones the big product into different versions, each of which is a partial copy of the original. The problem with this is that you now have several versions of the same code (or components for physical products), and each must be maintained.<\/p>\n Products become large because organizations don\u2019t have good ways to manage shared components. They understand that maintaining multiple versions of the same thing is bad, so they choose the evil they consider less bad: bloated products.<\/p>\n But there is a better way.<\/p>\n <\/p>\n <\/p>\n\n
\nSimpler Products Are Easier to Develop and Use<\/strong><\/h2>\n
![\"simplify](\"https:\/\/www.pragmaticinstitute.com\/wp-content\/uploads\/2020\/08\/Refining_Figure1-1024x430.jpg\")
<\/p>\n
\nThe Importance of Architectural Finesse<\/strong><\/h2>\n
![\"common](\"https:\/\/www.pragmaticinstitute.com\/wp-content\/uploads\/2020\/08\/Refining_Figure2.png\")
<\/p>\n