The money talk in UX

Let’s be short and clear: businesses only exist to make money. All their placed bets are based on the sooner or later expected profit.

To determine the viability of any business case, we need to calculate the expected profit by subtracting estimated costs from estimated revenues. But here’s the issue: even if we’re good at estimating costs (as all the information is on our side), we’re typically bad at estimating the other 50% of the equation — revenues. Most often, we take a wild guess and postpone pricing decisions until the very end. We embark on the long and expensive product development journey, hoping to make money on our innovations, but not knowing if we will.

When I started working as a Product Manager, we naively believed that if we just built a great new product, customers would come and pay a fair value for it. We even believed Product Managers should actively avoid the money talk, as it could pollute innovative thinking. If we failed, that would be okay, as so many innovations do. We weren’t alone.

It’s true: most new products become monetizing failures. Either because no customer wants to pay for it and we put it in the market anyway; or because we give up on bringing it to market without even making any monetization study; or because we cram too many features and create a confusing and overpriced mess; or even because we price products too low from their full revenue potential. Either way, if money is essential to businesses and monetization failures are so common, shouldn’t we do something more to prevent them?

Especially with the ongoing economic crisis, Product managers can’t afford to be blind to market realities any longer. To prevent monetization failures and increase the likelihood of success, we must flip the process: market and price, then design and build.

Here, following the principles outlined in Monetizing Innovation by Ramanujam and Tacke (the best book I know on the topic), we’ll explore how to market and price a product to get to a reliable business case:

1. Market Research
2. Product Structure
3. Monetization Model
4. Pricing
5. Business Case

We don’t need to know precisely what product we’re building before assessing its worth. Neither customers have to experience a new product before they can say how much they would be inclined to pay.

Willing-to-pay Conversations

We can assess a product’s worth right away by having early conversations with customers about their overall willingness to pay and the value they place on specific components. These conversations uncover whether we have an opportunity to monetize our product and help us prioritize the correct set of features (consequently resulting in a better product experience for users).

As price indicates what customers value and measures how much they are willing to pay for that value, the simplest way is to just ask them about it:

• Direct Questions — What is an acceptable price? What would be an expensive price? And a prohibitively expensive price?
• Purchase Probability — What’s the likelihood (0–5) of you buying this product at this price? (If not a 4 or a 5, ask again for a lower price.)

With these questions, we’ll quickly reach a reasonable price range. And we must ask ourselves whether that price range would work for our company. It may not if we can’t deliver a market-acceptable product at a price that makes a profit.

Afterward, we can use more advanced questions to dig deeper into the value of specific product components.

• Best-Worst Scaling — From this feature set, which features do you value the most and the least? And this other feature set?
• Build-Your-Own — Build your ideal product from this set of features — each with a price to make the choice realistic.
• Purchase Simulation — From this product lineup with different price points and feature combinations, which ones would you choose? And in this different scenario?

If we follow each question with the most powerful question of all: “Why?”, we’ll know much about customers’ willingness to pay and their needs.

Segmentation

With the previous conversations, we’ll quickly notice that not all customers have the same willingness to pay or needs. Whether we like it or not, a market where customers are homogeneous is yet to be found.

The only way to cope with this variance is to embrace customer segmentation and not force a one-size-fits-all solution. If we have two customer segments and design offerings for the “average” customer, we end up building a product neither group is entirely pleased about. Segmentation gives us the power to cater to customers’ specific needs.

There are many sorts of segmentation. We’ve all heard about personas and dividing users by demographics, behavior, etc. While this might be good for customizing sales and marketing messages, it is often uncorrelated to what matters the most in product creation. Instead, we should build segments based on differences in needs and willingness to pay and shape products accordingly from there. Segmentation then becomes a product design and development driver rather than an afterthought.

What if there’s not enough capacity to focus on all segments? Fair enough (and expected for startups). When so, we should prioritize and build for the segment with the biggest opportunity (in terms of size or revenue potential) while creating a plan to introduce future solutions for the other segments. This way, we’re still avoiding a one-size-fits-none solution.

With identified segments, we can think of a segment-based product offer structure. It means selecting the right functionalities for a segment product configuration (aka variation, aka package) — just the ones they need and are willing to pay for.

Configuration

Our instinct will be to pack as much functionality as possible in just one configuration.

However, counterintuitively, we must get comfortable giving segments only what they need rather than giving them everything. Too many features lead to feature shock products, especially if customers are not wild about those. Let’s recall that one big reason for monetizing failures is cramming too many features and creating an overpriced mess. No one likes to pay for functionality they don’t use.

Product configuration requires the courage to take away, not just add up. Plainly, we must deliver the Must-Haves, we may keep the Nice-to-Haves, and we should eliminate Turn-Offs.

• Must-Haves — critical functionalities that drive a segment to buy a product
• Nice-to-Haves — fillers of moderate importance
• Turn-Offs — deal-breakers if a segment is forced to pay for them

Still, what is a Turn-Off for a segment could be a Must-Have for another. We might need to include it in another variation, or we could sell it stand-alone if only a few want it.

Bundles

Complementing product configuration, we have bundles. A bundle is a product combined with others, sold for a cheaper price than the sum of those individual products. It works well for cross-selling nice-to-have products and maximizing sales. Think McDonald’s meals — customers end up buying more than they would have if they hadn’t bundled.

It is easy for customers to become overwhelmed trying to decide which offer is right for them. Bundling not only boosts our revenue but even increases customer satisfaction because deciding is more straightforward. They didn’t have to choose between A or B; they got both for less.

The classic approach to bundling is to create a tiered model:

• Good — cheaper, with the most essential products (but not giving away too much)
• Better — more expensive, with product combinations better fit for main segments
• Best — most expensive, with ALL the products!

Also, many people avoid extremes: when presented with a choice, they choose the compromise option. Playing with this psychology, we drive people to choose the Better options.

Yet, without tremendous market power, customers won’t be happy if we hard-force bundles. Selling the products both as stand-alone and in a bundle will probably work better — it’s more flexible, and the bundle price advantage becomes more visible.

Now that we have product configuration and bundles for the right segments, we have the building blocks to consider the right price points. Is it?

Well, not right away. First, we must define the monetization model — how the customer pays. We need to know how to charge before we know how much we charge.

Today, numerous models are in use, not simply the pay-per-unit standard. Ramanujam and Tacke identified five different ones that have proven to be the most valuable for new launches:

• Subscriptions, as in Netflix and most SaaS — It’s beneficial for industries where customers use the product continually. It has proven to be stickier than regular transactions.
• Dynamic pricing, as in Uber and the airline industry — The price fluctuates to monetize volatile demand and capacity constraints.
• Auctions, as in art, yes, but also as in Google AdWords — Let the market figure out what it wants to pay. Customers outbid each other to buy and raise prices. It’s ideal for seller markets and when there’s competition for the inventory.
• Pay-as-you-go, as in AWS and other cloud products — Pricing transactions on alternative metrics closer to product value and customer benefits. It easily adjusts for different levels of usage.
• Freemium, as in Medium and most product-led software — Two or more tiers of pricing for its products and services, one of which is free. The goal is to land a huge customer base for the free version and later expand a significant percentage to paid.

These models are by no means the only ones we can use. We can also combine pieces of each one for a mix-and-match model, as the progressive example below. When done right, the best monetization models are a win-win for us and our customers.

This is not a small matter: the chosen monetization model can be as critical to success as the product itself, and a flawed monetization model can be worse than a bad price.

We’ve chosen what and how to charge; now, we can start deciding how much. But first, we need data.

Price Elasticity

From our analysis of the willing-to-pay research and the decisions on product schemes and monetization models, we can deduct the quantity consumers are willing to purchase at various price scenarios. With that breakdown, we are ready to assemble a demand curve and visualize the relationship between price and sales volume.

With those inputs, we can also assemble a revenue curve: just multiply the price by the volume quantity.

Now, we can better see what would be the optimal price — the one that maximizes revenue. How much margin we have on the optimal price depends on the elasticity. Elasticity is about how sensitive customers’ demand is to a change in price. If our product has high price elasticity (a steep demand curve), we’ll have a relatively low margin in the optimum price. The other way around is also true: low elasticity leads to a high optimal margin.

With the revenue calculated, it would be easy to get the profit if we have estimated the expenses. We have to subtract the costs from the income, et voilá. The ideal price for profit might not be the same as for revenue, as some costs might vary according to the quantity.

Pricing Strategy

So, should we choose the price for maximum profit? Isn’t that our strategy? Hum, it depends…

The right strategy depends on our goals, as different goals can lead to contradictory actions. For example, if we want to expand the market share, we need strategies and price levels that differ from the goal of increasing revenue.

The good news is that, again, according to Ramanujam and Tacke, only three types of pricing strategies matter:

• Maximization, as in products with a clear competitive advantage — Setting the price to generate the highest possible profit or revenue. Classic and straightforward.
• Penetration, as in new brands in a competitive scenario — Setting a lower price than Maximization to grab market share and expand rapidly.
• Skimming, as in Apple and other premium and innovative products — Setting a higher initial price than Maximization to cater to enthusiasts who pay to be first-in-line, then systematically decreasing the price to reach other segments.

We’ve all built some business cases before. Will this time be different?

Business cases usually come in as static documents, built from the inside out, failing to consider critical outside market information. They are run to earn budget approval and put on a shelf right after. That’s a limited usage of this tool’s power.

With the previous exercises completed, we have the pillars of a good business case filled with informed living data, not just arbitrary numbers we want to hear. Value, pricing, volume, and costs all interact to keep us grounded and allow us to extract our product’s true potential, before and after hitting the market.