Kevin Brennan

Addressing competitor price reductions

Competitors can reduce their price for a variety of reasons, including reacting to the launch of your product, selling off inventory in the run-up to the release of a new product, or in a strategic shift to win more market share. Below are a couple of approaches to navigating competitor price reductions.

Percentage breakeven sales

A good first step when considering a competitive price reduction is to calculate the percentage breakeven sales change and make a judgment call on whether to change your price or not.

First, a definition. “Contribution Margin” is the incremental money generated for each product sold after deducting the variable portion of the product’s cost. For example, if the current price of your product is $50, and the variable cost is $40, then the contribution margin is $50 less $40, or $10. The percentage breakeven sales is calculated by dividing the potential price reduction by the product contribution margin. 

For example, if a competitor reduces their price by 5%, the percentage breakeven sales change for the same 5% reduction in your product is the price reduction (5% of $50 or $2.50) divided by the contribution margin ($10), or 25%. As a first-order analysis, if you believe that by not matching the competitor price, sales volume will be reduced by 25% or less, then it is better not to match the competitor price change since doing so would result in lower overall profit. 

On the other hand, if you believe sales will drop by more than 25%, then a price reduction should be considered. In deciding, you also need to consider whether the competitor price reduction was a one-time or temporary event. Perhaps the competitor is preparing for the launch of a new version of the product and is temporarily reducing the price to sell off their remaining inventory with the intention of reverting to the prior price for the next version when launched. If so, a price reduction on your part may be unwise and unnecessary. On the other hand, if you believe that a price reduction on your part may result in the competitor further reducing price, then you need to account for that when determining the appropriate course of action.

Cost of responding and competitor strength

Another approach is to estimate (1) the total cost of reacting to the competitive price reduction as well as (2) the strength of the competitor, and respond in one of four ways:

  1. Ignore – Ignoring the competitive move is prudent when the competitor is weak, and the cost of reacting outweighs the benefits. Matching the price reduction may also only precipitate a further, more painful reduction.
  2. Accommodate – When the competitor is strong and responding would be too costly, it is best to accommodate the competitive move and make the strategic changes necessary to address this new reality.
  3. Defend – When a response is cost-justified, and when dealing with a strong competitor, then the best strategy is to engage and defend your market position. The goal here is to convince the competitor to “play nice” and to signal that aggressive pricing is not in the competitor’s best interest. This may involve a temporary price reduction on your part with a subsequent price increase to signal your intent.
  4. Attack – Sometimes, a weak competitor misjudges their market strength and initiates a price reduction in the hope of gaining market share, only to be outdone by a strong response on your part.

Read more about pricing and other key product management topics in my book, Mastering Product Management: A Step-By-Step Guide, available now in paperback and eBook.

Five steps to prepare for powerful product demos

Demonstrating product features and benefits is a key skill for successful product management. Often, the Product Manager will conduct the demo, while at other times, the Product Manager will define demos for others to carry out. Demos are likely required in the early stages of the new product process to gain support for the new concept. During development and testing, demos can be used to showcase recent work and get feedback, either from internal stakeholders or customers. Demos to potential and existing customers are a critical part of the sales process for winning new business and are also often an integral part of tradeshows and other events featuring the product. The following is a general five-step process for planning compelling product demos.

  1. Define the demo goal. Consider the purpose of the demo. Is it to move a “prospect” to the next stage of the sales funnel by persuading them of the key benefits of the product? Or is it to gain feedback on a proposed feature during development?
  2. Consider the audience. Think about the audience’s needs. What needs, wants, or goals do they have that the product can help achieve? Engage directly with the audience or with the demo organizer to confirm your understanding of the audience’s needs before defining the optimal demo.
  3. Understand key constraints. Enquire about and confirm all potential constraints for the demo. These include how much time is allocated for the demo, the characteristics of the location (is the demo to happen in a small office space or a large, noisy tradeshow floor?), and the size of the audience.
  4. Define the demo. Given your agenda for the demo (“your goal”) and the audience’s agenda (“their goal”), define the best demo that will accomplish both. Items to consider when defining the demo include:
    • An “A/B” demo, where you show the audience today’s solution (“A”) and then contrast that with the new product (“B”) and show how it is superior, is often very effective.
    • Plan to start with the high-level context before driving down into the details.
    • Consider localization and cultural sensitivities when doing demos for foreign audiences.
    • Consider what could go wrong and how you will respond if something does go awry.
    • Plan to end the demo with a call to action in support of the goal for the demo.
  5. Do a dry run. Do a dry run of the demo and practice it a few times. Ideally, do the dry run in the location where the actual demo will occur using the actual equipment and leave the equipment and room set up. Confirm during the dry run that the demo meets all the constraints, including timing. If possible, record a video of yourself doing the demo to identify areas for improvement.

Read more about demos and other key product management topics in my book, Mastering Product Management: A Step-By-Step Guide, available now in paperback and eBook.

Clearly define roles and responsibilities to avoid product team conflict

Product teams, like all teams, tend to move through a series of phases from the time the team is assembled to when the team is executing optimally on the product scope. One model of group development identifies four phases: Forming, Storming, Norming, and Performing.

In the Forming phase, the team comes together to discuss and understand the product project and resulting goals. Mature teams or teams that have already worked together on past projects often move from the Forming phase directly to the Norming and then Performing phases, where the team is operating cohesively toward the overall product goals. However, the team often passes through a Storming phase where friction and conflict arise.

One common source of conflict is misunderstanding about the roles and responsibilities of the product team members. Spending time when the team is formed, or when there’s a personnel change, to have a discussion on the different roles, who does what, and the expectation that each role has of the other roles will go a long way toward eliminating this source of team conflict.

Common technology product team members often include a Product Manager, a Program or Project Manager, an Engineering Lead, and a UX or Design Lead. Each role should identify what they see as their responsibilities to the team and also their expectations of what the other roles will do and deliver. For example, the Product Manager may include the following as key responsibilities of the Product role:

  • Is an expert on the market, including customers and competitors
  • Has ultimate responsibility for the business success of the product in the market
  • Owns the creation and execution of the product strategy
  • Owns the product roadmap
  • Defines the product requirements
  • Sets pricing
  • Monitors and manages the program P&L and return on investment
  • Is the final decision maker on product scope and schedule

The Product Manager may also identify the following in their list of expected responsibilities and deliverables for the Engineering Lead role:

  • Specifies, develops, tests, and releases the product
  • Defines the technology and architectural strategy for the product
  • Translates product requirements from the Product Manager into technical specifications
  • Creates and owns the engineering plan

The other roles would likewise identify the key responsibilities of their role and their expectations of the other roles. Having an open discussion on each role works to identify areas of alignment and, importantly, misalignment, which can then be resolved.

The final area the team should identify is the responsibilities that exist at the collective level and are no one role’s responsibility. This can include items such as monitoring for where ownership is unclear or identifying capacity deficits and working together to resolve those.

Read more about product teams and other key product management topics in my book, Mastering Product Management: A Step-By-Step Guide, available now in paperback and eBook.

Five best practices for sharing product roadmaps

A product roadmap is a visual tool to summarize a product offering over time. A roadmap is most often used internally, for example, when working on project planning. However, there are times when a product roadmap needs to be reviewed with entities outside your company, for example, when pitching a future version of a product with a prospective customer. Be extra careful when reviewing what is primarily an internal tool with people outside your company. Here are five best practices for sharing product roadmaps externally.

  1. Remove all sensitive data such as features that are not being disclosed, project cost information, staff names, and competitor references.
  2. Include a prominent disclaimer to note that the roadmap is not a commitment and is subject to change. It is critical that external parties are aware that while the roadmap is an expression of intent, it is not a committed plan. Setting the right expectations is critical to avoiding disappointment if a plan changes in the future.
  3. Use project code names to obfuscate the product or brand name in case the roadmap ends up in the hands of competitors or others outside of the intended audience.
  4. Consider creating two versions: The version that is presented and a “leave behind” version that further removes sensitive data. Sometimes it’s acceptable to present certain information verbally but leave that undocumented.
  5. Use a secure .PDF or another non-changeable format. If sharing the roadmap under a non-disclosure agreement, note that and include the name of the external partner on the roadmap.

Read more about roadmaps and other key product management topics in my book, Mastering Product Management: A Step-By-Step Guide, available now in paperback and eBook.

Not all product features are created equal

Products and services are often made up of a collection of features and benefits that combine to deliver the full value of the offering. Some features are bare essentials and represent the “price of entry” for customer consideration. Other features make up the core of the product value proposition and are the focus for customers when deciding to buy. Understanding how a feature is perceived by customers is the key to successfully defining a new product or service and optimally managing scarce product team time and resources.

A tremendously useful paradigm for evaluating product features is the Kano Model. Features are categorized based on how satisfied the customer would be with a given feature (ranging from “frustrated” to “delighted”) based on the level of implementation of the feature (from “absent” to “fully implemented” ). The resulting five categories are:

  1. “Must-Have” features are expected by the customer. Although these features will not make a customer satisfied with the overall product, excluding them creates dissatisfaction. Continuing to invest in Must-Have features beyond the customer’s expected level of performance is pointless as it does not increase satisfaction.
  2. “Satisfiers” are features that provide a satisfaction level that increases linearly with the given level of functionality (for example, higher pages per minute throughput on a laser printer or more processor cores on a PC). These are typically the core features that the product competes on. Choose the right Satisfiers and the right level of implementation given how the product will compete in the market.
  3. “Delighters” are unexpected features that have a disproportionately high impact on customer satisfaction given the level of investment. Strive to have one to two Delighters in the product to create customer delight and positive differentiation.
  4. “Indifferent” features are ones that the customer doesn’t care about. Eliminate these since they have no impact on customer satisfaction.
  5. “Reverse” features are the opposite of Satisfiers in that the more that are added, the more dissatisfied the customer will be. It’s important to monitor new features to ensure they are not, in fact, Reverse features, and if they are, to remove them.

When considering a new product or service, gather feedback from target customers on potential new features and attributes. Start by eliminating any features that fall into the Indifferent or Reverse categories. Include Must-Have features but only develop them to the customer’s expected level of performance. Build the overall feature set primarily on Satisfiers, the key three to five features the product will compete on in the market. Finally, include one to two Delighters to create customer delight.

Recognize that value changes over time. What was a Satisfier in a prior version of a product may now be a Must-Have feature as customers’ expectations evolve. When planning a new version of an existing product, re-evaluate all features to see if their classification has changed.

Read more about feature prioritization and other key product management topics in my book, Mastering Product Management: A Step-By-Step Guide, available now in paperback and eBook.