Category: Articles

Part II – Qualitative Tools

In Part I of “The Product Manager and the Art of Pricing” I described the importance of exercising data-driven practices associated with Product Pricing decisions and also introduced the Magnet Affect through an example of Sale Price Distribution analysis.
In this article, I will present the use of 2 qualitative tools and methodologies for price setting and price execution.

Price Setting – Fixed Price or Variable Price?

Sometimes it is difficult to adjust the price model for different segments of customers, each with different needs and price preferences. One of the most significant decisions is whether to charge customers with a fixed fee or a per-use fee.
The model presented below allows us to make an initial adjustment of the price structure for different segments of customers and helps us to answer the above question.

The most profitable models usually combine elements of fixed and variable price.

Price Execution – Using a Price System

A connection between the worlds of pricing and sales is done using the method of Price System which enables different selling approaches to different segments.

This method outlines list price, target price, minimum price and floor price where each has a role in maximizing the sale price for each segment:

Small Businesses – Similar to each other so often set a fixed price for them, i.e. list price = target price = minimum price for a given segment.

Medium Size Businesses – Different from each other, but you can group them into groups according to characteristics that affect the profitability of the organization. These characteristics are called Counter Performance Elements. For example, Quantity consumed can affect our target price within a specific segment.

Note: In many cases a dedicated simulator is required to calculate the target price depending on characteristics of the customer.

Large Businesses – Very different from each other, have special needs and require non-standard solutions. A specific price should be set for them through a full economic model – Contribution Model.

In Summary:

Product Managers are operating in a very complex environment of both internal and external information and need to integrate the collection of the truths of the organization in order to recommend the right price structure.

Often, your product is sold in a number of segments, which requires multi-pricing depending on customer needs.

In order to maximize the potential of your product, you sometimes need to affect other areas of the organization. For example, the sale model of the product to different segments (which is basically under the responsibility of the Sales organization).

Your way to affect the price of your product is to be the most professional person and drive organizational decisions based on data, facts and principles of the world of pricing.

This is a guest post by Sagy Gulinka, Owner at TMsight

Striving for Product Excellence?  See our next Product Management Course.

#1 Identify a Need in Strong User Experience

Today products are focused on User Experience.  Customers evolved and expect products to fit their needs in a simpler and more intuitive way.

We have no patience for long loading pages or complicated installation processes. Even new hardware products such as our TV remote are better designed for easy use.  The apps we use every day such as Waze, Movit, Google search – all contain just a simple input line. We are used to multitasking and even if we miss-press a button on our mobile, while starting the car and talking to a colleague, we get impatient.  User Experience (UX) plays a major role in our perception regarding a product and even became a norm we expect.

There are also products that are less UX oriented, such as back office softwares like ERP or Billing. There are also examples to hardware products that are less User Experience focused such as car tires, electric wires, smoke detectors…

We have to know whether our product is UX oriented.  If UX is a major concern in our product’s success, as Product Managers, we have to be ready to make an effort for great UX.

#2 Gain a Deeper Understanding of UX Process and Collaterals

UX expert’s place in an organization varies, UX expert can be part of R&D or under the Product Manager. It can be an in-house task or an outsource. Generally the collaterals that are provided in the process are the same. A deeper understanding of the UX process by the Product Manager would define  better ways to generate and use these outputs.

The Product Manager is dominant in the Product Strategy and Product Definition dimensions.  Product Definition is when the UX expert should be able to get input from the Product Manager. The UX expert should be able to give feedback, validate or modify the Product Definition.  Even if we are developing a software for a specific client’s need, we still have to take UX issues into account. The Product Definition process should involve a multidisciplinary team, and in this case a User Stories document is the right choice.

A User Experience expert is more dominant in the Product Achievement dimension, this is when the UX expert should present output to the Product Manager after refining Product Definition. Product Managers should  understand the process and provide feedback. In addition, there is much value in UX expert’s output in terms of Product Marketing.   Wireframes, can be used for better sales engagements and product launch.  If our product is a mobile application, for example, and we are able to demonstrate some screens for the buyer before development is done, the buyer can visualize our software’s functionality and can provide feedback and even commit to buying the product (before it is fully developed).

Think how your User Experience expert can help you in the process of defining and developing a product, and how can you leverage UX output for achieving product excellence.

#3 Establish a Fluent Two Way Communication Channel

UX expert and the Product Manager need to work together, with two way communication, both have to be able to convey feedback each to other for a better product creation process.

Another way to look at this, is that in some situations, the UX expert can be a mediator between the Product Manager and the Development team. It can be by translating customer and user needs to a detailed product UX specifications that makes the communication between the Product Manager and R&D more detailed and clear.

Value your UX expert, use their expertise for a better managed process, and for better multidisciplinary communication in Product Achievement dimension.

Interested in UX management for Product Managers? Join our workshop in 9,10,15 of May 2016. Click here to read more.

Product Managers need to be good at understanding the value the product generates to the customer.

Product value to the customer should grow over time.

This is a responsibility. One of the key areas to grow value is the User Experience.

There are many aspects to User Experience, there is the Exploration experience, the Commitment experience (when the customer buys), the Introduction experience and the User Experience. Over the last few years, inspired by the Mobile revolution User Experience becomes a major issue for technology product companies.

Some Product Managers are using the fact that UX experts exist in the company to leave this issue outside their domain. This is a mistake!

Product Managers should do just that, Manage and this includes the user experience. Even if delegated, UX is something that should be managed.

Some Product Managers, are taking a step back when it comes to User Experience, it seems to them that it is “one of those things”, “it is about intuition” and NOT about rationally calculating what needs to be done. It is NOT an algorithm that needs to be applied. “It is an art” they say, it is not science.

STOP THE TRAIN – YOU ARE GOING IN THE WRONG DIRECTION!

Creating products is a science, NOT an art! It is NOT about intuitions and making intuitive decision, (although intuition may play a role, it should not run the process). So when you hear this about User Experience and you think “well, let those UX experts manage the User Experience”, think again, User Experience is too important to be left to the UX experts, it is strategic.
The bottom line is that Product Managers need to understand and manage UX, just like they manage any other meaningful aspect of the product.

For this growing need, StarVision have generated an innovative User Experience workshop especially for Product Managers.

Hi-Tech companies need to innovate at all times. Technology is changing constantly, and if you don’t innovate, you stay behind. We all know this is true.

One of the big dilemmas for hi-tech companies who already have a product, is whether they should continuously improve the current product , or innovate with a totally new product. Some call it evolution vs. revolution, while some use the terms “creative destruction” or “cannibalization”. But it’s all the same. In this paper, I will use the terms evolution and revolution.

Product managers should weigh the pros and cons of the two, so different, approaches.

The “Revolution” option:

It sounds great for the developing company. They can develop from scratch, they are not dependent of the current product and therefore don’t have to carry along problems this product might have. For the developers – revolution is heaven: rather than adding to an existing product, they get to develop a brand new product, with whatever tools are available today, as if they work in a startup…

This approach fits with the notion of “creative destruction” – a leading concept in innovation theories. Creative destruction means that one gets rid of the old product in order to replace it with a newer one. It stems from the fact that if you don’t come up with a very up-to-date product, your competition will do so. Therefore, don’t fear to “kill” you own product in order to introduce a new one. One more point in favor of revolution is the product’s perception in the market. – customers might like the idea that the company they are buying from keeps creating products with the latest technology.

The “Evolution” option:

The company has a product, it’s selling well today, there are lots of customers using it around the world. For these customers evolution is a smooth way to get improvements on products that are already being used at their premises. Just imagine a customer who uses a complex software solution for the last 7 years. Now assume the software provider offers a brand new product, to replace the current one. From the customer’s viewpoint – this is extremely risky.

Moreover, it might cause them to examine the competition: If they have to migrate to a new product provided by their own supplier – why not open it for re-evaluaion of the other options in the market. This, in turn, means that revolution is risky for the provider as well, and not just for the customers. The more customers you have – the more likely you will select the evolution option.

So – which is best? There is no clear answer. Like most difficult questions – it depends…

I would suggest that:

•  If you have many customers, go with the evolution option, but make sure that the evolution brings your product to a top of the line competitor in its market, and not just makes it “stay alive”

•  If you have few customers, or if the migration from the old to the new product can be relatively easy – consider evolution

•  If you believe (and can show a solid business case for this) that a new product will be 10 times better than the current one, do it!!! (Now, how do you know what 10 times better is – that’s for a different article)

Today, more and more products are offered as Software as a Service (SaaS).

Is the product managers’s job the same for SaaS offering, or is it completely different than the product manager’s tasks for the traditional, non-SaaS product?

In short, we can say that the product manager’s “job description” is the same whether the offering is a traditional / on-premise one, or if it’s SaaS. In both cases, product managers are expected to understand the market needs, perform competitive analysis, define the roadmap, provide high- and low-level requirements, and define the positioning, packaging, pricing and messaging of the offering. So, at first sight, there is no difference.

However, the difference lies in the CONTENT of the above tasks, the dilemmas we have to solve, and the way we do it.

Here are some points that can illustrate the above:

1. Product releases –

for on-premise products, we define the roadmap, with major and minor releases. In SaaS there is no reason to discuss major and minor releases – the users do not care whether the changes in the product are part of a major release or not. They don’t pay for it anyway. Once they subscribe to the service – they automatically get whatever is there. This implies that the product manager is “free” from these definitions, and can introduce any changes at any time, if these make sense.

2. How many releases?

How often do we make changes to the product? – For on-premise products, the answer is clear – every release, according to the release policy (normally, one to a few releases per year). For SaaS offerings, the decision is more complex. Think about yourself, as a user of Gmail or Facebook: Do you like the fact that the product changes often? Would you prefer to see less (or more) changes? The answer is tricky.

On one hand, the ability to add/change things in SaaS is great and very tempting. After all, that’s one of the benefits of the SaaS business model. On the other hand – if we change too much, we might irritate the users. Product managers should find the fine balance between the two options – and it’s not an easy job!

3. Pricing –

Pricing for traditional products is based on licenses. In SaaS, we use the subscription model. And on top of it, we normally offer either a free trial and/or the Freemium model. So it’s clear that the product manager’s job in determining the pricing model is very different. Just think of the Freemium model: it is the product manager’s responsibility to decide which parts of the product are provided for free, and what is “the first step” for which users will have to pay. A poor decision here can affect the company’s ability to be profitable! It could be a life and death decision.

4. Product infrastructure –

do product managers have to care which technological infrastructure will be used for the products? In the traditional model – the product manager has a strong say, as the customers will have to support this infrastructure and approve of it. However, for SaaS – product managers should not care. Let the R&D people make these decisions.

5. Simplicity –

the name of the game in SaaS is simplicity. If the product is complex to use – no one will buy or stay with it. So please, no bells and whistles – just make it simple and easy to understand with little or no training.

There are many more differences, but this list shows that even though it’s the same product manager, with the same tasks, there are significant differences in focus within each task. Does it mean that traditional product managers cannot do it for SaaS – absolutely not! They should adapt to the changes in focus, but overall their role is unchanged.

Practical Product Strategy should highlight the following steps

So what is Practical Product Strategy?

Strategy is a big word, huge… sometimes a little intimidating.

Think about it, what is your strategy?  Do you know what it means?

I’d like to think of strategy from a practical perspective – Practical Strategy!  Practical strategy is the guideline for the  Product Manager.

Strategy is the grand plan…  The Master Plan … the way you achieve your ultimate goals. To do that you have to know what is your ultimate goal – that is also part of the strategy.

If your product is a journey, the strategy the high level plan of where you want to go and how you want to get there.

So let’s break it down – I would like to think of strategy in terms of 9 items that define strategy.

From a practical perspective – we have 9 steps that build us into producing the Business Plan!

Please see the key items to consider below.

Product Management Dilemma:

Are product decisions intuitive or should product decisions be based on a structured rational process?  Is Product Management an art or a science?  This book is probably the strongest supporter for the claim that Product Management is a Science and the decisions Product Managers make (hard as they may be) should be based on rational analysis and not on intuition.

The WYSIATI Trap – What You See Is All There Is:

Product Manager focuses on information about a problem, a pain that the specific customer is experiencing, RFP requirements … and stays in the narrow frame of the context the problem.

We take a customer requirements without asking ourselves – is there more?  Are other customers facing similar problems?  Will this problem be as painful in the future?

If we see Product Management as a science we should always ask ourselves… Do I have all the information?  Should I be searching for more dimensions of this problem/issue/feature/requirement?