Ask A Good Product Manager

Your product management questions answered

How can you best manage a product atop a platform?

Posted on November 10, 2008 · 6 Comments

Question: What considerations should I make when developing an application that runs on a core platform?

We are designing a product to run on top of a core platform. Some functionality can be built in to the product, and some can be built into the platform. How do you distinguish between what should be in the product vs. what should be in the platform?

Answer from Michael Hopkin of Lead on Purpose: My definition of a “core platform” is a base on which two or more (usually many) applications run. There are many different purposes for platforms, and there are many out there. In most cases their main purpose is to provide core functionality that some or all of the applications will use. Platforms include functionality such as printing, spell check, network communications, etc.

When developing an application, should you use all the functionality or services on the platform? That depends. The following questions will guide you in making your decision:

  • What is the purpose for developing the application? Determine what benefits the platform provides and use the capabilities that are necessary to offer the functionality demanded by the market.
  • What functionality does the platform provide? Determine the functionality the platform provides and use the options that will enhance the functionality of the application. Take advantage of the platform components that can add value to the application, if (and only if) implementing them does not exceed time or cost estimates.
  • How is the platform received in the market? Many platforms exist on which you can develop applications. When you choose a platform for applications, be sure it’s well received in the market and it’s heading in the right direction. (If the platform is owned by your company you will likely need to use it regardless of its market acceptance.) Carefully compare the direction the platform is headed with the desired long-term outcome of the platform.
  • Can you justify the cost? Perform a careful analysis of the cost of building on a platform vs. the cost of building comparable functionality yourself. Most often it costs a company much less to develop their applications on a platform than to develop the same functionality into the application. However, if the platform does not provide the necessary core functionality required by the application, you either need to find a different application or incur the cost to develop the functionality into the application.

When you develop an application on a platform you should use the functionality necessary to meet the application requirements, and if it fits within your cost and time estimates, implement additional functionality that will be useful to your market.

6 other answers so far ↓

  • John Mansour // Nov 11, 2008 at 12:38 pm

    The most simplistic approach to the platform dilemma is to view the platform as a common set of services (features) that products on that platform inherit. To that end, features that are desirable to all products on any given platform should be built into the platform. This will eliminate development redundancies and lower the cost of ongoing support and maintenance.

    The decision may not be as clear if there is only one product on the platform. This is where strategy and vision are of utmost importance in driving these types of decisions for the short or the long term.

  • SharePoint Fridays: Designing An Application To Run On A Core Platform | Usability Counts: Usability, User Experience, Social Media, and SharePoint // Nov 14, 2008 at 10:02 am

    […] There are some key questions you should ask before you select MOSS as your platform, and Ask A Good Product Manager has a great post about this. The summary […]

  • Building products on a platform « Lead on Purpose // Nov 15, 2008 at 10:45 pm

    […] he asked me to answer is “How can you best manage a product atop a platform?” Take a look at my response and let me know what you […]

  • David Locke // Nov 30, 2008 at 3:41 pm

    In a discontinuous innovation context, your platform will be the technology, and your product will be a use and productization of that technology. The technology focuses on enabling code. The product focuses on users and their needs.

    Typically, we use various third-party platforms via APIs. We have to time our development cycles relative to the upgrades to those APIs. We have to evolve the base functionality as it evolves in those platforms. Platforms have costs associated with them.

    We also broaden our markets when we sublimate a particular vendor’s platform with those of other vendors. Since a client will more than likely have only one vendor’s database in their infrastructure, we would only get paid by the client to support that vendor’s database. When we move the application into the vertical, we will run into more platforms. Write the adopter before plugging into the database the client has. Expand the adopter to span other databases as the vertical market demands them.

    The functionality provided by these third-party platforms should be points of parity, and not points of difference. Low use, outilier functionality in these third-party platforms might have to be ignored. Discontinuities from third-party platforms should definately be ignored until they can be productized in a new product. Discontinuities in sustaining products will not be adopted by the market the sustaining products are facing. Discontinuities demand a new market, a new cost structure, and a new policy basis. Going further, discontinuities demand a new sales force, and new forcast realities.

    The in-house platform should be treated just like a third-party platform. The technology team should have a roadmap that lays out well defined functionality in their releases, and release dates independent of product releases. This will enable the product programmers to get their releases out the door without waiting for the technology. And, it enable the product managers for products to consider where the technology will be relative to the product roadmap.

    Even if you only have one productization of the underlying technology and one niche market now, you will need additional productizations, each with their own productization before you can go into the early hoizontal market. Keep your technology roadmap separate from your product roadmap. Synchronize them.

    One thing to beware of is any discontinuities in the technology platforms after you have gone into the vertical or niche market. These discontinuities might drive your current market away. They require their own separate commercialization effort, which means starting with early adopter clients again. At some point after this new technology has a customer base, you may consider and plan a means to combine the technologies, but the new technology must present a value proposition to the market of the prior technology before you will make headway.

    See McGrath’s early books for hints on managing a technology platform.

  • Gopal Shenoy // Dec 4, 2008 at 3:28 pm

    I second what John Mansour has said – that would be the primary criterion I would use to determine what goes into the app vs. the platform.

  • December 19th – Relevant Links – spatially relevant // Dec 28, 2015 at 2:20 pm

    […] How can you best manage a product atop a platform?: Ask A Good Product Manager: Your product managem… […]

What do you think?