Building new product – My experiences (Part V – Product development)

This blog is the Vth part in series of blog post on new product development. Actually product development phase is the final phase of new product development. However i am not concluding series, i missed to talk about ‘Ideation phase’. So the next blog post is on ‘Ideation phase’ and the final blog post is to outline the essential traits of PM for success of NPD

The entire product development phase is completely driven by the Program Manager, the role of the Product Manager cannot be negated and I have outlined various activities performed by Product Manager in parallel to the product development for the success of new product. In this blog, I will focus on activities exclusively driven by the Product Manager during product development. The key activity during this phase is to conduct weekly or periodic review meetings with Program Manager to ensure that the program is on track without any delays. In case of any delays caused by delay in development or delay in supply of HW/SW components by the vendor etc, Program Manager will outline the impact to the release timelines. Product Manager has to figure out the risk due to delay in releasing the product and immediately draft a mitigation plan. Even though

Activity checklist

There are lots of activities that are either tracked or performed by the Product Manager during product development phase to ensure the timely release of the new product and it would only get worse if the release gets jeopardized because Product Manger misses to complete at least one of those activities. So preparing a checklist and periodically reviewing the progress is critical. The checklist should pre-dominantly contain the list of items driven exclusively by the Product Manager. I have listed down the basic set of activities common for any new product development, especially HW products

  • Product price
  • Support cost
  • Ordering
  • Creating part numbers
  • GTM plans
    • Marketing collateral
  • ….

The above listed activities might not be exhaustive and the idea is to ensure that the Product Manager drafts an exhaustive list of activities in the form of a checklist, so he does not miss any activity. I would not shy away from suggesting to take some cues from Program Manager on how to prepare an effective checklist. Program Managers are generally more adept at such tasks. Note of caution is to ensure that you and Program Manager do not duplicate the efforts of tracking the activities. At least from my experience, the earlier listed activities are exclusively driven by the Product Manager while Program Manager would focus on product development, supply chain, documentation, compliance, vendor finalization etc.

Know the process

Each organization has their own processes to complete the above activities. As a Product Manager, it is really critical to have a complete understanding of those processes including the timelines required to complete them. Always add 20%-25% buffer to the duration required to complete each activity. Later Product Manager has to figure out how many weeks before the 1st release do each of the earlier mentioned activities has to be completed. Backtrack from the target date to identify the start date. For instance if finalizing product cost takes 8 weeks and the activity has to be complete 4 weeks before the 1st release, then essentially the activity has to be started 14 weeks before the 1st release (4 + 8 + 25% of 8). Also try to understand the dependencies between each activity and plan accordingly. For instance, creating part numbers, product cost and ordering are mostly inter-related items. For instance product cost could not be derived and recorded without part number. Ordering could not be enabled without pricing and part numbers.

It might sound simple, but in most cases Product Manager fails to ascertain the time taken to complete each activity and it happens primarily because of the lack of knowledge about internal processes. New product development is not everyday activity, so it is imperative for any Product Manager to undergo quick training on the list of processes involved in new product planning and development.

Pricing

The most important premise during pricing phase is to optimally price the product so Product Manager does not leave any money on the table and Product Manager monetizes the product in much more effective way. There are various kinds of pricing (cost-based, value-based) pricing. The exact methodology depends on the nature of the product and market conditions, but irrespective of the methodology, for pricing review it is always best to have some reference point so Product Manager could justify the price point. In case of product being introduced in new category, price of perceived alternate product should be considered as reference point.

In case of cost based pricing, the price of the components used in the product will come down after reaching certain volumes or after specific time period. In such case, would the strategy be to price the product higher initially and lower the price later to retain the same margins or have thin margins initially to drive volumes and compensate for the lost margins little later. There is also an aspect of product life time that will determine the product price as well. Another aspect to note in pricing of B2B products is ‘Discounts’. Is discounting the product a norm and customers always seek higher discount irrespective of the final price, then it is always suggested to price the product higher and later provide higher discounts

In case of value pricing, I would just pick the cost based pricing and add standard margin. Later understand the exact value delivered by the product in tangible terms to the customer, does it save customer money or help them generate revenue, Product Manager has to add % of that tangible value to the cost based pricing and derive the final pricing.

In case of xAAS model, primary aspect is to identify the pricing strategies (consumption model, term/perpetual license, freemium, tiered model) and secondary aspect is to understand infrastructure required to implement xAAS pricing model. There should be mechanism to track licenses purchased by the customer and validate whether customer is using the product or services in accordance with the license agreement. xAAS pricing model should be simple and measurable.

Pricing by itself is a bigger topic, I just outlined the thoughts based on my experiences and there is no right or wrong way to derive the pricing. End of the day what matters is that whether product is recovering the cost and making sufficient margins without leaving any money on the table. Pricing has to be looked alongside the business model of the product as well. Business model primarily outlines how to capture value. Another aspect to consider is total cost of ownership, while the product might be affordable the total cost of ownership might be too high for customers to afford. For instance, the service cost and spare parts of the cars can be higher or in a B2B product the support cost, training cost will be higher.

Price will always be directly proportional to a specific attribute(s) of a product. Before Product Manager starts pricing exercise, he has to ensure that those attributes does not change in the completely built product. For instance, the price of hard disk is directly proportional to its storage capacity and RW speeds etc. Sometimes Product Manager don’t get the pricing correct, it is better have some mechanisms to evaluate the efficacy of the pricing and allow room for any changes even after the product is released.

GTM activities

Putting aside the range of GTM activities, Product Manager need to look at the primary purpose of GTM. The primary purpose of GTM is to effectively communicate product value proposition to the target customers in a more optimal way. Communicating the value proposition is not about creating a booklet but about the ability to tweet the value proposition effectively to target audience. Any product essentially does lot many things and it is appropriate to list them in a product booklet and it is not wise to dump all the information to customer during initial messaging. Product defining attributes outlined during product requirement phase would come handy to formulate an effective value proposition messaging. The messaging should definitely strike a chord with the target audience and should raise the curiosity factor; otherwise Product Manager has failed miserably. Probably Product Manager has failed much earlier while drafting the defining attributes. If those defining attributes are neither striking a chord nor raising a curiosity factor, then customer is not valuing those attributes and the success of the product is really at stake.

Next step is to identify the list of mediums (social media, events, blog or traditional methodologies such as print or TV) through which target audience could be reached. In order to determine which methodology is more effective, identify the cost and penetration rate (ie what % of your target audience could be reached) to rank the mediums based on their effectiveness to reach target audience. In case of budget constraints and the initial estimated budget for GTM was not allocated, simply apply 80:20 rule (20% of your budget should help you reach 80% of your target audience). Ranking process of mediums can help Product Managers implement 80:20 rule to effectively and efficiently communicate product value proposition.

Final activity is to decide the timeline to start communicating the value proposition of the product and through which medium. The timeline purely depends on the exact strategy, for instance in certain cases there is a need for suspense factor and the details about the product would be revealed just few weeks before the launch (eg iPhone). In other cases (mostly B2B products), the suspense factor will be counter-productive and therefore the information would be let out in bits and pieces pretty earlier to create a curiosity factor. I said ‘bits and pieces’ because if the communication is started during the product development and most probably some of the details would be missing. If AIRBUS is building a plane that can go longer distance non-stop consuming less fuel, even though Product Managers would have provided some benchmark numbers for distance and fuel savings, it is not wise to communicate the actual data without testing the completely build product. So Product Manager will start messaging that a new plane being built will travel longer distance while consuming less fuel, initial messaging will not shed any more information on exact distance and fuel savings. The precise idea is to create enough buzz about the product while effectively communicating the value proposition.

All those messaging activities through various mediums have to finally converge in a big launch event for the product inviting the PR, customers and other stake holders. Probably the number of events would depend on the budget and geographic spread of the target audience.

I consider messaging to be primary constituent of the GTM activities, but there are also bunch of other activities including product training (to channel partners, sales team etc), product pages, support document, product images, launch plans etc. Product Manager alone would not be able to drive all of them, but he has to draft a plan outlining the activities and who will be in-charge for those activities and timeline to start and completion of each of the activities.

Whole product approach

Product Manager need take a look at the entire sale process and understand what factors would influence the sale process. Product capabilities alone would not influence the entire sale, there would be other parameters such as reputation of the company, quality of post-sales service, availability of support, reference customers, availability of trained engineers (for B2B products) etc. Whole product approach is to list such factors that are critical for a sale and plan to fulfill them.

The big ticket item of whole product approach is to outline the plan for product ecosystem that was elaborated in ‘Detailed requirements gathering – PRD’ section. If the new product has to spur an entirely new product ecosystem, then Product Managers has to sweat a lot to create a proper ecosystem that would fuel the success of the new product. Another aspect to consider is that the elements of whole product vary as the product evolves through various stages of technology adaption life cycle (describer by Geoffrey Moore). The decision making process of the early adapters are not same as early majority. The early adapters might consider product capabilities as the key deciding factor in the buying process, they are curious to explore new products without worrying about the existence of support, product guides etc. New technology excites them more than anyone else. Whereas early majority might consider good product reviews, existence of support etc in addition to product capabilities as the key deciding factor in the buying process.

Final Word: Product development is lengthiest phase and during this phase Product Manager handles umpteen activities for successful release of the product. Considering that 25% of the products get killed during development, PM has to exhibit attention to details and meticulous planning during this phase. Otherwise product development might go terribly wrong.

Whole Product Experience – How to create right mix

‘Whole Product Approach’ as explained by Economist Theodore Levitt has been one of my favorite concepts. The concept was later familiarized by Geoffrey A. Moore through his book ‘Crossing the Chasm’. So it was kind of Déjà vu when I chanced to read an older article in ‘Accidental Product Manager’ blog. Though Dr. Jim Anderson does not explicitly talk about ‘Whole Product Approach’, all the activities such as location of stores, customer service, training manual, sales collateral etc that he was referring in his blog, encompass ‘Whole Product Approach’ and those activities are critical for the success of the product.

I initiated this blog to figure out the right constituents of ‘Whole Product’ during each phase of the Technology Adaption Lifecyle. I refer to the ‘Whole Product’ as the sum of core product and its add-ons such as location of stores, manuals, installation guides, and after sales service etc. The list of add-ons differs according to the product and the industry. For instance in smartphone segments, availability of apps forms the critical component of add-ons, whereas in automobile sector after sales services, dealership networks forms the critical part. Universal truth is that we could not focus on every element of the product and its add-on in version 1.0, so in Product 1.0 we should only focus on critical elements of the core product and its add-ons that would provide a compelling reason for the target customers to buy the product.

Invariably with exception of few products like Windows most of the products follow the technology adaption lifecycle and hence the target customers for Product 1.0 are Innovators and small chunk of Early Adaptors. So we have to initially focus on their requirements when we attempt to form the constituents of ‘Whole Product’ and as the product threads the subsequent paths of technology adaption lifecycle, the constituents of ‘Whole Product’ varies according to the expectations of each category. Now let us to try understand how to arrive at the constituents of ‘Whole Product’.

To do so, I would primarily list down all the elements of ‘Whole Product’ in the form of matrix as listed below. Against each of those elements, we have to indicate in % values how much each category would value the core products and its various add-ons relatively. Higher % value against any element indicates that it is a stronger influencer to sell the product and therefore should be focused.


Innovator
Early Adapters
Early
Majortiy
Late
Majority
Laggards
Core Product





Technical Support





Installation Manuals





Additional SW for ease of Use




















For instance, Innovators value the core product much higher than any other element. So in product 1.0 there should be lots of emphasis on the core product and its ability to solve customers’ pain points in more unique and optimal way. Within the core product, lots of features will be competing to find a place in 1.0. The features should be prioritized depending on its ability to solve the critical pain points. As the product is embraced by other categories, the emphasis will slowly switch from the core products to add-ons. Detailed discussions with the respective target audience will help us fill the matrix and facilitate us to constitute the essential add-ons that would increase the Whole Product experience.

The success of this approach is largely dependent on our ability to successfully trace in which phase of the technological adaption life cycle is the product currently positioned. As far as i am concerned, i am still trying to figure out how long product will remain in each phase when exactly the product will move from one phase to another. My quest to learn more continues, if i could figure out anything substantial i will draft another blog post.