If you've stumbled upon this page and need social proof as to why you should read it, here's what other folks think:
One of, if not the best article on the topic of product positioning.
— Hiten Shah (@hnshah) September 4, 2023
Making products is hard. The advice you get doesn't help much; either it's too vague to be useful or too specific to be applicable to your situation. These notes build a model of how products work that's internally coherent (hopefully) and can be used to derive the right advice yourself!
Since I work on software mainly used by developers, I wanted something that worked at the crazy-zoomed-in level like "what should the parameters of this function be" but could scale out to larger business objectives like "who should we sell this to."
Most of this is based on a model I first saw proposed by Cheng Lou and likely other sources I can't quite place but have likely influenced my thinking through osmosis.
Table of Contents
Concepts
The Abstraction Chain
All products live in the Abstraction Chain. Products at the base of the chain are more powerful, but are more complex, and therefore less useful. The farther up the chain you go, the more useful the products are, but have a narrowly defined use, and so are less powerful.
This is most obvious in technology products, where there's often a clear value chain between the products that get built.
But the chain extends beyond individual technologies to products which then have their own utility for their own customers:
Somewhere in the infinite abstraction landscape is the value that the customer wants at some particular time. The goal of a product is to move the customer as close as possible to the value they want at any given time.
Scaffolding
Scaffolding is the glue-work the customer has to provide in order to get value out of your product. Scaffolding is the "build" in build-vs-buy. It's the spaces in between nodes in the abstraction tree.
Some products, like Kubernetes, AWS, Okta, Salesforce, or Retool require lots of work to use, and so have lots of scaffolding:
Others like Snapchat, Spotify, Superhuman, Mercury, or Chrome are fairly frictionless and have little scaffolding:
Scaffolding allows a customer to get the usefulness (the value) out of the product, even if there aren't subsequent products in chain above. Scaffolding is a trade off between work and flexibility; the customer has more control and power by using a lower-level product, but will need to put in more effort to reach the value that they want.
Upshifting
Upshifting happens when a customer choses a product higher in the Abstraction Chain. Sometimes this happens because the new product solves the same problems for the user, with less scaffolding (space between the nodes). Or more plainly, if the product has a better user experience, but solves the same problems (ie: Superhuman), then a customer might "upshift" to the higher level product that requires less work on their part.
A customer may also choose to upshift if the product they're using requires lots of scaffolding in order to support many use cases, but they don't actually have all of these use cases. One example might be the Atlassian to Notion switch; many teams just don't want to make the tradeoff of ease of use for the enterprise-y features that Atlassian forces.
Downshifting
Downshifting happens when a product doesn't exist in the market that satisfies all customer needs, and so the customer is forced to use a lower-level product with more scaffolding to solve their problems.
A downshifting customer may choose to abandon Heroku for AWS, or a lightweight CRM for Salesforce.
Problem Space
A problem space is the subset of the Abstraction Chain that contains all the problems for a particular customer.
Problem spaces tend to have lots of sub-problems, and have their own subsets. A problem space can said to be "deep" if a single need has many sub problems. For example, Spotify has the problem of "streaming music." But within Spotify there are millions of individual songs, and not having a particular song may make them vulnerable up to a competitor.
A problem space is "wide" if it encompasses many seemingly different problems. For example, AWS tries to solve many different problems for you.
- "Rent a computer", with autoscaling
- Private networking ("build your own internet")
- Secret management
- Database management
- Real-time messaging
- CDN ("store files in lots of copies in many places in the world so they're easily accessible")
- etc
Bad Abstractions
Bad abstractions happen when a product has mismatching needs from the customer. Bad abstractions aren't always bad, they can often become bad as the needs of a customer change.
A product that's trying to serve too many needs for customers typically ends up as a bad abstraction, since the customer has to put up more scaffolding than needed to get the value out of the product:
A product that doesn't serve enough needs may also be a bad abstraction.
Products with overlapping (replicated) value, used by the same customer can be bad abstractions. You might see this at a company that's using multiple CRMs, multiple email clients, multiple programming languages, etc. Since these are distinct products, typically made by different organizations, they often don't interoperate with each other. For the customer, this means either not using some of what one product has to offer, or having the same value solved in multiple places (leading to hassle or "cludge").
Bad abstractions make up the majority of the original problems solved by products. That's where the advice "what are the hacks people are using to solving this problem today" comes from. Most products aren't mRNA vaccines, mars missions, or protein folders. They aren't products that fundamentally advance the number of points of value on the tree. Most products are "rebalances" of the abstraction chain to account for bad abstractions that have gotten so bad the market is willing to accept a new product.
Supporting high-level products
If customers can get the same value by using a product that's higher up the Abstraction Chain, they'll upshift, potentially removing your product out of the value chain. To support this customer behavior while still capturing value, there's a spectrum of options depending on the size of your problem space.
UX improvement
In a narrow problem space, a customer may want to upshift because the amount of work (scaffolding) required to use your product is beyond their budget. This leaves room for an upstream competitor to build a cleaner UI that accomplishes many of the same goals. (ie: Linear, Superhuman).
Another version of this is just making scaffolding easier for customers. Design, technical writing, ecosystem, community, all make scaffolding easier for a customer to use. Stripe has lots of scaffolding you have to setup, but it's still a great abstraction because of the quality of their scaffolding support. Stripe seems to tread their scaffolding as a product in-of-itself, just one that the customer can change if they need to. Their examples are the product.
Feeder Products
When a company wants to support upshifting for customers that don't want all the value of the original product for the cost of the scaffolding, they can make a higher-level feeder product.
Most open source cloud platforms (Redis Labs, Confluent) are this model; they maintain a low-level product as well as a higher-level one that feeds off the first. Mailchimp's Tinyletter is another example.
Developer Platforms
Developer platforms are a strategic tool to allow customers to upshift (Upshifting) without cutting your product out of the value chain. They work best for wide problem spaces.
Products with large amounts of required scaffolding and no platform will be at risk of upstream competitors cutting off the flow of value to the product:
Without adaptation, upstream competitors cut low-level products off from parts of the value chain. For example, Atlasssian's suite of products may be cut off by more focused, high-level products (Notion, Linear) which are able to support themselves more feasibly due to a growing market. As their customers mature, the higher level products may downshift and become a threat to Atlasssian's core enterprise customers; or may cut them off from new enterprise businesses.
At the time of writing, Retool may also have this issue; as upstream competitors may productize common use cases. Data labeling, customer lookups, custom CRMs, dashboards, etc are all ripe targets for startups to come along with on-prem, read-from-the-database solutions that are more custom to the issue. While it's certainly possible that Retool's problem space is so wide that they'll always be able to serve more niche problems, it's still leaving money on the table if they don't insert themselves in the value chain.
To do that, they can build a platform. In Retool's case, this is probably a plugin system. With a plugin system, they still allow customers to upshift, but now the product is in the value chain.
Mistakes in product discovery
Fear of Scaffolding
Many early product people (myself included) are obsessed with reducing the friction in their product.
So they carve out some small set of customers and build something really close to where the customer is. After all, this is the standard advice: build something for a small market then expand!
But for larger customers, being exactly what you customer needs right now will make customers want your product less, not more. Businesses are smart; they've been burned by products that didn't scale with them before. If the slightest shift by their customer makes the product no longer work for them, then your product is too brittle.
The fix for this is to move away from the customer's value and require more scaffolding to support the downshifting. This may mean a more complex product with more buttons and options (the horror!), or a product that requires someone to write more code.
Lack of definition
A product is "defined" if its position on the Abstraction Chain is clearly pitched to the customer. The customer can tell how much scaffolding they'll need to do and they understand what problems it solves. If most customers anywhere close to the Problem Space can look at your website and repeat back to you what your product does, then your product's defined.
Some early creators (myself included) who aren't yet sure where their product should be positioned will lack definition in their product pitches. This is a mistake.
The only way to get valid feedback from customers is to show them a clearly defined product. If they can't understand what you're doing, you may get back very excited opinions on what the customer "thinks" the product is. But since you and the customer don't agree on the positioning, their feedback may lead you to build a product they don't want. If instead you gave a clearly defined product, their feedback (or more typically, their disinterest) will be much more honest.
Emergent Properties
Mature customers downshift, growing markets upshift
Maturing customers and growing markets are opposite forces on the possibilities of the abstraction chain.
- Maturing customers tend to move down the abstraction chain. As your customers grow, their place on the abstraction chain is often niched to a particular place; they're the only customer that does it such-and-such way.
- Larger markets support products higher on the abstraction chain. Consumer products can exist high in the abstraction chain, but products selling to fortune 500's have difficulty doing so.
Products higher in the tree are more useful, but are more niche. So if the market expands such that the niche grows, then more higher-tree products will get created.
This is somewhat obvious, larger markets increase diversity of firms. A small town may only have a single restaurant, but a large city will have hundreds of options.
To skate to where the puck is heading, create high-level products for growing markets. An initially small market may not be able to support it, but that can give a startup time to build a polished product by the time the market is at a peak.