What is a Product — A Strategy Perspective — III
In the last article, What is a Product — A Strategy Perspective — II, we saw how companies brought economies of scale into marketing and selling. They developed a captive customer base to who they reached out to hone the products. They can add new functionalities to their offerings and make the products more attractive. We called the collection of products a suite. However, customers wanted more. They want behavioral integrity across point products in the suite. We look at achieving economies of scale with engineering processes in this article.
Once a product is part of a suite, people expect every aspect of the product to be similar. Outlook uses F4 as a keyboard shortcut to search a text, while other products like Word, Excel, and PowerPoint use Ctrl-F. People would expect the tables in Word to be as capable as Excel spreadsheet tables. Word art objects should be as feature-rich as PowerPoint. They are looking at Microsoft Office as a single product with a consistent experience. Even someone may like to pick up a spreadsheet from Microsoft Excel and embed it inside a Word document. Will Microsoft say no to a corporate finance team designing the annual filing with Word with all the tables taken from Excel?
Looking at the challenges, the Office product team now involves a UX team that looks at cross-product compliance. They engage an engineering team that designs software components like search to behave consistently across Word and Excel and develops a file format for all Office point products. While it may seem like a lot of work, abstracting the conceptual elements and sharing the engineering elements of the product saved cost. Microsoft went a step further and took this architecture across products and allowed third-party application developers to develop components for the web pages and other applications. ActiveX, COM, and DCOM are some of the component development architectures fulfilling such needs. Even Sun Microsystems, IBM, and Oracle provided similar solutions with Java Language. Each provided powerful development environments and tools to aid application development. Today, we know such environments as development platforms.
Companies like Novell were selling ZENworks, a composition of seven to eight independent point products. Now they decided to build a base that can act as a platform and provide standard services like installation, system update, package management, etc., for all the other products could reuse. Today every product is built on some product platform for its sharable service requirements. When several companies see the need for such sharable services across industries, they develop such platforms in the open-source and seek collaboration from other companies. Today most programming platforms are built in open source. There is hardly any organization that does not use any open source component.
While components and platforms improve software reuse, they also increase complexity. There is better coordination needed across teams. Agile engineering process frameworks like Scrum, SAFe, XP, or Kanban with continuous integration tools can help manage the products better. As the number of components increases, the need for better tools and processes becomes more relevant. Organizations achieve economies of scale with effective frameworks and tools. Per-employee revenue is a success metric to watch out for in such initiatives.
Building products is all about realizing economies of scale. Improved marketing, sales, and engineering processes are the way to achieve the goals. Improving infrastructure is another way as well. That shall be the topic of discussion for the subsequent article. The product management juggles between buy vs build for the best value creation. What are your current challenges?
Note: Sambit Kumar Dash is a founding director of Lenatics Solutions Pvt Ltd, which provides product management services to businesses for Sustained Competitive Advantage. You can reach him at: firstname.lastname@example.org