The malleability of digital products

Last post was about the first of the two fundamental properties of digital products that I believe necessitates us to think about them differently, their zero marginal cost. This post is about the second property: their malleability, that is how easy they are to change. 

Software wasn’t always easy to change. Once it was launched, distributed on CDs or floppy disks and installed, software was impossible for the company to change unless the customer proactively bought the new version. However, with the internet, SaaS and cloud services almost all software companies can now push out changes continuously, doing small improvements. This is quite unique, in other industries once a product has been launched the company more or less loses control over the product.. 

Isolated for the individual company, this is a good thing. They can fix things after a product has been sold and improve it based on changes in market conditions or changes in customer preferences. The problem for the individual company is that this benefit is available to all companies in the market. What starts as the “nice to have” of getting improvements to the product after you’ve purchased it then very quickly becomes the baseline and expectation of customers. 

I believe these types of liquid expectations (expectations on e.g. UX is affected by other services not just your competitors) increase the uncertainty for digital product companies. Who could for example have foreseen that “Dark Mode” would be one of the most requested features in the fall of 2019? Digital product companies need strategic process that can incorporate these types of uncertainties.

The zero marginal cost of digital products

My tenth post, halfway to 20! This was the hardest topic yet to write about and I will likely update my views and formulations of the points below in the future.

One of the two fundamental properties of digital products, that I believe make them different, is the zero (or near zero) marginal cost of producing them. In this post I expand on this concept and aim to show how this property affects competition and strategic planning. 

Marginal cost is the cost associated with producing an additional copy of a good. For in every industry (until digital products) this cost was:

  1. Larger than zero
  2. Decreasing with increasing cumulative volumes

In traditional industries this was the foundation to the “economies of scale” of large companies. I.e. large companies could in theory do everything a smaller company could but thanks to its scale do it to a lower price. In an industry where almost identical products can have very different prices customers will focus on price in their purchase decisions and, most other things being equal, choose the cheaper alternative.

Contrast this to digital products. How different would the competitive landscape of digital products be if a small company would have a marginal cost of $100 for each new customer whereas a large company would only have a cost of $10. The though is almost absurd but think how much harder it would have been for companies like Slack to compete with Microsoft Teams if each new Slack user incurred a cost 10X that of Microsoft’s. Microsoft would in this scenario likely be able to out-price Slack just by virtue of its size. It’s reasonable to assume that Slack could not have provided its services for free if such a marginal cost were in affect.

This matters for strategy. In a world where price per unit is a driver for customer volumes, planning for lower prices becomes an integral part of strategy. Detailed planning is done on whether to build another factory this year to increase volumes and lower prices or to not invest and instead return more to shareholders. These strategic choices are mostly internal and thus more controllable. Strategy is in the environment rightly thought of as a game of chess where the grand-master could think one more step ahead (i.e. have a more detailed business case) than his competitor.

In a world where the marginal cost is zero however, prices will quickly be competed away as a factor and customer will therefore look for other factors. These factors are usually external to the company that provides the services and therefore less controllable. They can range from: “How usable is to product?”, “Does it solve my particular need?” etc. I believe there are actually very few factors that affects a customer’s decision to use a digital product that the company can control by focusing only on internal processes. Strategy therefore becomes much more of the poker game I’ve described earlier: instead of doing detailed business cases to justify large investment we make many small investments and see them as experiments to learn more about what our customers actually want.

As I wrote in the introduction, this is a tricky topic. One could, for example, argue that consumer brands for ages has used customer knowledge to build differentiated products and move away from price as a factor in purchase decision. This is true but I believe the zero marginal cost makes this even more important in digital products. However, zero marginal cost might not have been enough as a single property. I believe it’s the combination of the the zero marginal cost with the high malleability of digital products that ultimately makes it necessary for companies in this industry to approach strategy in different way.

In the next post we’ll look into malleability and how this beneficial property though competition can start to dictate how we see strategy.

The uncertainty of digital products

During the last posts I have written of the importance of process in high uncertainty situations and the idea of strategy as a framework. In this and the following posts we will explore why I believe this uncertainty is higher in digital product companies than most other companies.

First consider the integrated steel companies in the 70-80s and the disruption they faced from the new mini mills. As described famously by Clayton Christenssen the novel but worse performing mini mills started in the low margin, low quality rebar market. However they then worked their way up market, improving their quality and taking market segment after market segment, to the point where now there is only a few integrated steel mills left in the US. No question this is a story of disruption, change and uncertainty.

In one area where the steel mills faced some amount of certainty though was in the predictability of demand. In steel, if you could produce steel at the right quality (as could be measured objectively) for the right price and have acceptable distribution demand was not that unpredictable. For this types of products, the lower uncertainty in demand also extends to new products. Demand for new products can be estimated looking at segments in the market that would likely be interested in the new product and the price could be estimated based on how much extra value the product new product would provide.

I believe this is radically different in digital products. In digital products a main dilemma is usually not whether its possible to build something but rather if anyone want to use it.  Lean Startup author Eric Ries formulated it well: “Just because it can be built doesn’t mean it should be built”. An easy way to exemplify this is to draw to memory all social products that traditional companies have launched and failed with. The underlying assumption in many of these products was likely: “if x% of our customer base started using this product it will bring us benefit A, B and C”. Unfortunately the share was usually 0%. It turns out that estimating the adoption of new digital products is usually very hard and the traditional [customer base * adoption rate] is usually way more off than for traditional products. 

So why are digital products different? This is a topic I will explore over several posts but I believe the difference come from two fundamental properties of digital products and software in general. The first property is the zero marginal cost of producing an additional copy of the product which leads to price per unit is taken out of the equations. The second property is the high malleability of digital products which means it’s possible to make changes quickly and continuously. In the next post we will explore these two properties further. 

Tying it together – the full process

Last post we continued our example and discussed Bet creation and how it differs from Belief creation. In this post we’ll tie it together and discuss what the different processes look and feel like in real life. I have attempted to summarize the last two posts in the simple chart below. 

The White and blue arrows indicate our example Strategic Intent that was then concreatized into a Belief which then was formulated into a Bet. In the end the Bet we started the last step (what Merissa Perri calls Solution optimization). There are two ways to view this process. 

The first way is to view it as a sequence. As can be seen in the chart above, the blue arrows line up in a sequence where we go from the very abstract (top left) to the more concrete (bottom right). This is one of the reasons it’s so important that both the mgmt. Team and the Belief owners stay away from defining solutions. If they were to define solutions (or Good ideas) this process would turn into something akin to a waterfall methodology where the solution is designed in earlier phases in build in later. Instead the Mgmt. team should define broad Strategic Intents, the Belief owners should find problems that if solved can move us closer to the Strategic Intent. Even in the Bet creation much of the solutions that are created are of exploratory nature meaning 

The second way is to see it as iterations. Though the chart omits them, there should be arrows going up from each performed experiment and each user research in the Bet creations. This is indeed where the majority of our learnings for our Beliefs take place. The process above could as well be illustrated as a cycle where the learnings from Solution Optimization goes back into Belief creation.

A last important aspect I want to point out is the two different hats of the PM. The PM is both responsible for the Bet creation as well as wearing the “Product Owner” hat when the teams experiment on Bets. The PM therefore needs to have a sort of split vision, simultaneously focusing on the next Bets as well as the here and now. Done well this will let the PM integrate learnings from the experimentation into the next Bet creation.

This concludes the series of posts about the importance of process. Next week I’ll write about why the aspects discussed so far are most important to digital product companies and what distinguishes that type of company.

Bet creation

After the Belief owners have concretized the Beliefs it is time for a handover to a team.  Depending on the Belief and the company, this team can be more focused on UX, Product, Tech or Business. In our case the Belief was defined as:

“We believe we can increase revenues by 6% through a more helpful ad insertion funnel and therefore creating more clear item descriptions that will in turn increase success-rate to 50% of the 20% of users that have identified this problem”

In our example company, the team that took over the Belief was a quite typical team for a digital product company i.e. a product manager, a UX expert and three developers. 

So what did the organization actually know about the Belief so far? Melissa Perri calls the work done by the Belief owners that we outlined in the last post: “Problem exploration”. This means the Belief owners have broken down the Strategic Intent using data as well as exploratory user research (i.e. more asking users questions than getting feedback on solutions). Where the team now start is to try to map solutions to the identified needs, that is “Solution exploration.”

In our example, the Belief owners had realized that a significant share of the users thought the funnel where they inserted ads was plain bad. They had also connected the share of users that cited this as a problem all the way up to the Strategic Intent of increasing revenues. What they had (correctly) not done however was to investigate what features or flows that made the experience bad. 

The main difference between a Bet and a Belief:
A Belief deconstructs a Strategic Intent.
A Bet formulates a solution that we believe can move us closer to a Belief. 

It is possible and even common to have multiple Bets addressing the same Belief.

The teams responsibility, therefore, is first to figure out what is making the experience bad and what could make it better. There are various techniques for doing this ranging from showing mockups to doing lean test where we build the UI but have very manual processes behind the scenes. By doing these types of Solution Explorations the team is iteration to find a Bet around the Belief.

The team started conducting user interviews where mockups were shown. Based on the feedback they created a new ad insertion page UI where the inputs had to be manually added to the database (served to 1 000 users). They found that the time it took to insert an ad was drastically lower. What’s more: the sellers rated the experience as better and buyers the ads inserted also had better liquidity than a control group. 

The team formulated their Bet as:

“By improving [description of features] we believe that we can improve the ad insertion experience as demonstrated by our experiments. By doing this we believe we can reach half of the effect in [Belief we discussed above] and thereby increase revenues by 3%.”

During the process the team had formulated several iterations of the Bet described above. The next step is to go into Solution Definition which is about building the actual solution and something that is outside the scope of this blog.

Next post we will tie together the process of beliefs and bets. 

Belief formation process – Example

Beliefs are what we believe we can do to move closer to the Strategic intent. As we discussed in the last post, left to our own devices, humans are very prone to create false beliefs. Therefore a data driven process for creating Beliefs is needed. In this post we will go thought an example case of how such a process can work, starting with the strategic intent of the company and then going through a Belief formation process, concretizing the Strategic intent to Beliefs. This post and the example is inspired by the Melissa Perri book “The build trap” and her discussion of the fictitious company Marquetly. However I have changed the example to better match my own experience.

The company in question is a two sided marketplace which means that its a platform where sellers can meet buyers. The company focuses on used goods and makes money when a buyer and seller performs a transaction on the marketplace. The company was in a pre IPO phase and needed to show strong growth to its investors. Their strategic intents were therefore focused on revenue growth and one Strategic intent specifically targeting the private individuals.

Strategic intent: “We want to grow by increasing revenues from private individuals by 30% per year”

These statements are a type of interface between the management team that sets strategy and in the product organization where the work needed to reach the goals are defined. 

The first job in breaking down the targets is an analysis of current revenue streams. In the case of our company, the revenues from private individuals were made when a buyer and seller performs a successful transaction. The way to increase revenues are therefore to increase the number of transactions happening on the marketplace. 

There are three general ways to increase the number of transactions:

  1. Increase the number of sellers on the site
  2. Increase the number of listings per seller
  3. Increase the average success-rate of listings (listings resulting in a transaction)

Given that this is likely the company’s core business, this type of breakdown should already exist but it’s good to do the exercise of breaking down the goals all the way from the top even if we already know the answers for some of the early break-downs.

The next step is to analyze the current performance of the three potential drivers. In our example the success rate stood out with very low. The Belief owners decided to focus in on the success rate and stated the first iteration of their Belief.

First iteration Belief: “We believe that if we can increase the success rate from 20% to 30% we can increase our revenue by 50%”

To be honest, the data above is also nothing that should come as a surprise to the company as it is likely a metric they are already tracking. The management team could have likely created this first iteration Belief themselves. The next step is where it starts to get interesting since we have now unbundled the Strategic intent enough to start doing user research.

This exploratory user research can be done in many ways, in our example the company opted for sending out simple questions to all sellers that had received at least one message but that were not successful. The feedback they received were mixed but some patterns emerged. For example, the company learned that 20% of the sellers perceived that they had received many leads but that they were irrelevant and felt unstructured so they had chosen to sell the item on another platform. The Belief owners chose then to narrow down and focus on this problem and formulated their second iteration.

Second iteration Belief: “We believe that we can increase revenues by increasing the success rate through improving the quality of leads to sellers”

Depending on the maturity of the development teams and the time constraint of the Belief owners the Belief could potentially be handed over and start doing Bets. More likely though is that the Belief owners will take this Belief through more iterations understanding why the leads were not good.

Fast forward and the Belief owners had done five iterations and combined analysis of their data with user research. Their fifth iteration was much more specific.

Fifth iteration Belief: “We believe we can increase revenues by 6% through a more helpful ad insertion funnel and therefore creating more clear item descriptions that will in turn increase success-rate to 50% of the 20% of users that have identified this problem”

Now this is a Belief that was not obvious for the organization when the process started. This much more sharp formulation is also a much better foundation for teams to define Bets for since it has clearly created a bridge between user problems and our strategic intents.

Next week we will look at how teams create Bets around these Beliefs

How are Beliefs formed?

(Short post this week as I spent most of the week being sick)

Last post talked about the importance of Beliefs in the process of breaking down strategy into actions and results . I loosely defined Beliefs as “what we believe we can do to move closer to the strategic intent”. This begs the question of how these Beliefs should be created. 

To start, it is enlightening to look at how humans generally form beliefs. A proponent of the “Homo economicus” (rational choice theory), would argue it goes something like:

  1. We hear something
  2. We consider it carefully comparing it to other things we know
  3. We accept it to be true and create a belief

This is a flattering image of the human mind. However modern psychology paints a more embarrassing picture of our belief formation process which goes something like:

  1. We hear something
  2. We accept it to be true 
  3. In the best case we construct arguments for why we believe it to be true

This is most evident in common false beliefs that we hold such as that male baldness is inherited from the maternal grandfather or that Inuites have a disproportionate number of words to describe snow (entertaining list). When it comes to beliefs, we are programmed to prefer false positives over false negative, which makes sense from an evolutionary context. Compare the survival odds of always believing the sound in the bush is a lion versus never believing the sound in the bush is a lion. One bias is more likely to produce offspring. But though it has served us well, this bias is now making it harder for us to form correct beliefs. 

Taking this back to product management, I would argue there is an even larger risk of an organization creating “false beliefs”. Since the employees apart from having their normal flawed belief formation process are also usually incentivised by the organizational structure to create biased thinking in one direction. This is why we need  guardrails that makes it harder for us to create false beliefs. These guardrails are basing facts in data and a process that mitigates social effects such as rank from the Belief formation process.

Inspiration: Thinking in Bets by Annie Duke

Strategic intents, Beliefs and Bets

Last post was about the importance of managing by outcomes instead of outputs. In that context I used the more general terms: business outcomes, product outcomes and user needs to describe what each level in the organization should focus on. I believe those terms give a good theoretical distinction for the three types of responsibilities of upper management, middle management and teams. However: this nomenclature might not be the best from a practical perspective. Instead, in this post I’ll use “Strategic intents”, “Beliefs” and “Bets” that will add some color to the “output metrics” and are a better way to describe the actual difference between the three. 

Strategic intents are another way to describe desired business outcomes. A strategic intent should indicate a move the company wants to take over a longer period. This can be over a single year but could be as long as three years. The reason it’s possible to have the same strategic intents over several years is because of how general they are. Since a strategic intent is the general direction the company should move in, the need to change it often should be smaller. New competitors, technology or trends should most often not change the general direction the company wants to move in. Strategic intents are either formulated as metrics or as very broad stroke initiatives (e.g. “Become more customer centric”) that has a metric attached to them. This metric is often an aggregated metric meaning it has multiple drivers. It is then up to the middle management to form beliefs on how to move closer to the strategic intention.

In Poker, a player needs to form a belief on what the situation around the table is and thereafter put a bet down. The bet therefore is only as good as the beliefs that made the player place the bet. This is a helpful analogy to how a product organization need to break down the strategic intents into Beliefs and Bets. 

Beliefs are things you hold to be true and should be based on data and generated insights. In this breakdown the Beliefs are what we believe we can do to move closer to the strategic intent. E.g. How an improved product outcome such as conversion can move us closer to a strategic intent such as growth. The Belief are therefore not a solution but more of an unpacking and concretization of the strategic intent. Since Beliefs are not solutions they should always have a success metric so that Bets later can be evaluated against the success criteria. Generally the people defining Beliefs should not be the same as the ones defining the strategic intent or bets. This means that it’s usually “middle management” that are responsible for the Belief formation. 

Bets are finally where we start working with solutions to problems. The reason they are called Bets is that all solutions we apply to a problem have some degree of uncertainty. Calling it “implementation” indicates that we have high certainty whereas “Bets” give a more accurate expectation of the uncertainty. As in Poker it is often ill advised to make a few huge bets, instead bets should be smaller (many companies have an upper limit of 6 weeks time for a bet).

Inspiration: The Build Trap by Melissa Perri and Spotify video: “Software engineering culture” and Thinking in Bets by Annie Duke

Managing outcomes over outputs

Last post was about the perils of good ideas and the danger of managers steering teams with features and solutions. How then should a manager steer her teams? Answer: by managing outcomes instead of outputs. Managing by outcomes means managers let teams do the work of figuring out what user problems to solve in order to improve a prioritized product metric that in turn improves a business metric. 

The matrix below shows a simplified version of the responsibilities of different levels in the organization. The higher up, the more the work is around strategy and the further down the more the work is around providing solutions to customer needs. Middle management here refers to the one to several levels of management in the product organization. 

The management team are responsible for the vision and strategy of the company. They are also responsible for translating the strategy to prioritized business outcomes. Given that these outcomes are what the whole company should achieve, they are usually aggregated. Aggregated metrics (e.g. revenues) have multiple drivers and no single person can affect them by themselves. The management should not come up with solutions, see last post.

Teams (and most of all the PM) on the other hand are responsible for being experts in their customers and domain. Based on prioritized product outcomes the PM / team is then responsible for prioritizing which customer needs to try to solve. The PM prioritizes the customer needs based on a hypothesis on what product outcomes it will result in.  

Between the management team that works with aggregated business outcomes and the PM that needs to know what the prioritized product outcomes are, there is a translation job to be done. This is where middle management come in. This is not an easy job. To be able to successfully translate the prioritized business outcomes into product outcomes middle management need to have a good understanding of the product and its users. In a simple case this could be translating growth (business outcome) to a funnel conversion (product outcome). But the translation could also be alot less obvious and more specific e.g. more type of a certain content will increase the perceived value of one user group and therefore reduce churn.

Managing by outcomes therefore is all about working with the right levels of abstraction in the right place in the organization. By managing outcomes an organization can achieve alignment of their efforts while at the same time leave the decision of what solutions to build to the teams working most closely to the customers.

The perils of good ideas and a trick PMs can use

It’s human nature to want to come up with solutions to problems we face. This is true in everyday life as well as in business. A parent of a child struggling in school might want a change in the way a subject is taught and a manager that is falling behind on revenues will want to come up with good ideas to accelerate growth. In business and especially in agile organizations this natural tendency of coming up with good ideas can however be very problematic.

The first problem is that good ideas are usually aimed at solving a business needs (which is ok) but often, little or no real user research has been done (not ok). For example, a VP is seeing that she is a risk of missing her yearly growth target. Since she meets a lot of customers she has formed some ideas on some features that the product is missing. She books a meeting with a product manager and explains the situation and that team really need to prioritize the new feature so that the division can reach their growth targets. An idea is not a verified user need though and since the idea is not verified it is likely to contain a lot of false assumptions.

The second problem with good ideas is that they take time to implement and are disruptive to the product development process. To get good and constantly improving products, teams and PMs need to have the ability to plan out their development process. An “important request” coming from the sidelines can derail weeks of progress and worse create a culture where teams let go of their ownership of their product. For example: arranging exploratory interview with customers and solutions testing to verify hypotheses are critical activities that takes time to arrange. If a good idea comes in the middle of this process, a lot of the work that has been done risks getting lost.

The third problem with good ideas is that they don’t work. Almost no features work as intended on the first release and it is first after customer feedback and iterations that products usually become good. This is why product teams need to focus on outcomes and not outputs. After a features is launched the team should learn from how it is performing and over time get closer and closer to a solution that generates the intended outcome. However this is not a level of commitment the good ideas usually have. Instead of becoming a product, the good idea becomes a one-off that miss targets and adds to technical debt. 

So what can a PM do to avoid getting stuck doing good ideas? One way is to ask (and demand an answer for): “what happens when we launch this feature and it fails?”. New features usually fail so the question is legitimate and the answer can hopefully spark a good debate around current priorities and the challenges the manager is facing. Maybe the team is already on the verge of an insight that will positively affect revenues? Maybe the team actually do need to refocus, but if they do it’s likely not to implement the feature as it was conceived in the good idea.