Products and Platforms
For example, let's select a simple word processor that doesn't have a macro language. It may meet many needs, but it's extensibility is very limited. By designing, packaging, pricing and delivering the word processor according to what consumers want, then the product should sell and make everyone happy -- at least initially.
The issue is that customer desires are often a complex bundle of logical and emotional needs bundled up into what we conveniently call the "customer." What they want and need varies from person to person as well as with time.
What is a Platform?
A platform is a product, but there is more depth behind solving needs. As opposed to being a "point solution" -- meaning that it satisfies one need or group of needs as a point in time -- a platform is an enabling product. It empowers the user to move beyond the original purchase criteria.
When a person buys a simple game that cannot be extended, then he bought a product. If it is extensible and will satisfy needs going forward through additional products and services, then the package is actually a platform upon which to build.
If we use the same word processor from the example above, but we add in a macro language that customers like and enable the ability to "plug-in" additional parties both from the software's authors as well as third parties, then we've created something that is extensible. It isn't just a one-time purchase, to meet defined needs. Instead, it becomes a platform from which new previously unthought of solutions can be developed to meet customer needs.
To a certain extent, software can enable personalization. By changing colors, user interface skins, sort orders, or even what world war you want to fight with killer rabbits from outer space, you are enabling the customer to move beyond the original application's design. Games with the ability to add characters, modules, and so on have proven that the potential is there.
A corporate portal seems relatively boring next to a 3D real-time action game, but some of the same issues apply -- how can the portal remain applicable over time? How can it be designed in order to continue to add value to the company and the individual users over time? Those are the real questions to think of.
The party best positioned to extend the product should do the work. In simple applications, it may be the user doing the macro programming or integration of third party modules. However, the product vs. platform discussion isn't just for desktop applications. It spans the whole breadth of IT systems. A document management system can be very finite in its scope or have an entire underlying tool set and API for extending the platform.
Thus, the small system may seem cheaper initially, but the long-term costs and benefits may point at purchasing the enterprise document management system and having developers available who can continue to tailor the system to meet evolving needs.
It is very important to understand customer needs and deliver solutions that not only meet those needs, but also create enabling platforms by which the customer can evolve beyond the original design. This may mean systems designed for the customer to make his/her own changes or ones where specialized IT staff can quickly react to customer needs and enable new functionality. The point is that a product is limited to a one-time event or limited timeframe whereas a platform enables the customer to move towards the future over a protracted period.
George Spafford is a project management consultant and instructor who lives in Saint Joseph, Mich. He has more than 10 years of experience in the fields of information technology and project management. His areas of personal interest include project management, software engineering, and organizational learning. He can be reached at firstname.lastname@example.org.