• Arun Saxena

    Pricing dilemma

    A year back I was involved with a leading mobile apps company on an issue related to product pricing. The company developed customized mobile apps for business. At the time it had a staff of 20 programmers and reasonably successful – having on its customer list several top global corporations like cola companies, few leading banks, advertising giants and others. It had revenues close to USD 1 million. The company had identified 20+ software functions (routines) that were commonly used in most mobile apps. They had put these together into a single library that programmers could access from a central repository when working on a mobile app project. Examples of such routines included memory management, real-time authentication, camera control, text messaging within the app and so on. Use of this central repository of frequently used routines had resulted in 30% saving in programmer time, standardization and uniform quality across projects, shorter time to market and finally the monetary benefit.

    The company saw a window of opportunity externally. They knew the mobile app business was growing at a fast clip with app vendors mushrooming all over. They were also aware of the trend of end customers developing mission critical apps internally. Both these customer segments would see a value proposition in the library if the company offered it. The company was at a critical point – thinking how to breach the psychological revenue barrier of USD 1 million. It faced fierce competition that had brought down margins from 80% to 25% in just two years. They thought the library was a ticket to new profit stream and improved competitive position. They were debating how to price and market the product.

    However this meant a sea-change in the way the company thought and worked. So far, they delivered single project as per known customer requirements to a single known customer at fixed price. They did their best to deliver within time and budget. They priced their services at cost plus margin. Any delay ate into their margin. Selling the tool externally would involve selling a generic product to external customers whose size and number was unknown and uncertain. They had a hunch but did not know for sure the external customers would really see value in the offering. For example a tribe of software programmers take pride in and get thrill from solving tough problems. They would not care for such a product. A few team members even felt that their competitors would also acquire the library thus diluting company’s competitive advantage in the market.

    The company sought answers to several questions:

    1. Should they sell the library externally at all?
    2. Should they price it on cost plus basis or some other method e.g., value based pricing?
    3. What should be the list price of the product?
    4. What should be the license structure i.e., kind of licenses they should offer?

    The company made a set of decisions. I will share those in the next post. Meanwhile, I invite you to share your suggestions on the questions facing the company.

    Notes on Product Management – insights from Slideshare / MMT / ex-Google PM
    The Other E-commerce Guys

    Tags: , ,

    • http://twitter.com/spatni_extensio Sangeeta Patni

      The art of being able to package libraries and selling a set of libraries as a Product is a tough one indeed. The packaging sounds perilously close to being labelled as a “Platform” or a “Framework” – one of the most difficult things to sell. Coupled with it is the fact that the company clearly sees developers as its target group, one of the most avidly wooed set of people from all tech companies. And for a company that is used to selling services – this is close to changing DNA midlife! I do not envy the entrepreneur at all :)

      That said, the best thing would perhaps be to license the framework on a Per Dev User basis, based on the platforms (iOS, Android, BB etc) delivered on. This will give the internal IT team some kicks in building their software skills on the framework – along with providing Certification on the Framework, which will increase their pull on the developer community.

      • http://twitter.com/ARUNS57 ARUN SAXENA

        Sangeeta, you have an interesting point regarding treating the library
        as a platform. The company thought about both product and platform strategies
        for the library.

        If you look at successful platforms, few salient features spring forth. These
        are:

        The technology solves an essential problem. It has unique features that are
        hard to imitate. Yet, it facilitates others to add complementary products. This
        meant the technology was relatively open at the same time having intellectual
        property that allowed the inventor to have some control and ownership. It is
        important that it forces some dependencies between itself and the complementary
        products built on it. In business terms it must provide incentives for others to
        contribute and build offerings off it. Finally, a platform is predicated upon a
        large number of ecosystem members engaging with it. That requires huge amount of
        marketing and evangelization. In this context, the company had many challenges
        promoting it as a platform.

        For starters, there were 3-4 big competitors i.e., iOS, Android, Windows
        Phone and Blackberry (RIM). There promoters provided frameworks (SDKs) for
        developing apps on those platforms. The question was how to align with these
        big players?

        Second, the developer market was highly fragmented – consider the number
        of one-man shows in this business. Moreover, the developers tended to solve tough
        problems themselves. How could one build high momentum roping them into the platform?

        Third, what would be the business model? For one, what would be the
        incentive for the developers to come onto the platform? Other issue was how
        would the developers exploit the platform?
        The library was not just like other IDEs; it would have more direct
        impact on user experience. How would this come in the way of developers
        differentiating their product in the market (assume everybody was using the
        same library of routines).

        Some solutions company considered were –

        1. Get into OEM licensing with the big mobile operating system vendors. The vendors made the library part of the their SDKs. The pricing could be based on a fixed annual fee or per copy
        downloaded.

        2. Sell directly in the open market like a product. Go commercial open source (COS) – buyers with
        certain volumes would get full source code. That meant they could customize the code as much as they wished.

        More to follow. Thanks.

        • http://twitter.com/spatni_extensio Sangeeta Patni

          Following this conversation keenly – all ears :)

    • http://twitter.com/VinodShintre Vinod Shintre

      Best strategy would be to run a quick survey with existing target users & ask how much & what would they pay for. Select a alpha-beta pricing cycle but again its a thin line.

    • http://www.emportant.com/ Sandeep Todi

      Arun, there is no doubt they should sell the library. If there are more avenues to leverage your IP than what you can do directly, then why shut out those options?

      I feel they should …

      a) Offer a free version that’s got 80% of the common pain areas addressed. This gives them visibility and scale and allows them to acquire a large footprint of potential paying users.

      b) Offer a paid version to independent app developers and corporate IT. This should have the complete feature set and include dedicated support.

      c) The value should be 1/10th of what it would cost someone to develop something similar. If someone considers the cost of hand coding those repetitive tasks and the long term cost of ironing out bugs in that code, it should appear like a bargain too hard to refuse.
      d) Licensing has many options, but I’d opt for a simple strategy to sell the licence with one year of free updates. Anyone could then update to the latest version at anytime in the future by paying an upgrade fee. I would choose this over a subscription/AMC model to keep it simple for the buyer, and minimize the cost of servicing contract renewals.

    Apr, 19
    2013
  • Copyright © 2013 - 2017 iSPIRT foundation | All rights reserved | Powered by iGenero and Netsolutions

    Read more:
    Capability -> Functionality -> Usability

    The capability to build something - a product or a solution - is, but, just the start of things. Capability is needed to build a product but capability is not what gets your product to......

    Close