R/K Selection Theory and Product Development [7/100]

I’m writing 100 posts about product development and product management. For this challenge I take weekly cadence (ruined by war…), so you can expect a new post every week (or less). This is post #7.

I love analogies (as you already know). Let’s talk about the applicability of selection theory to product development.

We’ll focus on a simplified r/K selection theory model which has two major strategies:

• r-strategy — produce many offsprings, don’t waste time on them, let’em survive as they can. In general, the survivability of such offspring is low. This strategy works better in an unstable or unpredictable environment. Competition is not that important, you have to adapt rapidly and a high reproduction rate enables rapid adaptation.
• K-strategy — produce fewer offspring, spend time with them and help them survive. This strategy works best in a stable environment with high competition from other species.

Now the fun part. Can we apply r/K selection strategy to new products development?

r/K selection strategy and new products development

In an unstable environment, it is better to release many crappy products and see what will fly. For example, AppStore was a completely new market with a very unpredictive future and rules: new medium, new UI patterns, new niches. It was very hard to predict what products will become popular. When a company produces many products rapidly it learns fast and quickly adapts to the new market. Angry Birds was the 52nd title released by Rovio. Do you remember any other Rovio games?

In a stable, well-defined market K-strategy works better. Here you build and release a single polished product, and improve it with care and passion. For example, the HR market is very well defined and known. How to penetrate it? Rippling took a very deep approach and spent many years on an all-in-one tool to cover almost all employees’ related cases. Using r-strategy here is stupid, you have no chance to penetrate a mature market with many crappy products.

r/K selection strategy and features

What about a single product? Is it better to release many rough unpolished features or a few polished ones?

In an unstable market, many half-backed features might be a preferable strategy since use cases are not settled and it’s not clear what features are pivotal for the product’s success. You can throw out rarely used features and polish the remaining features later, iterating quickly. I think Coda is a good example here. They released many many features in the first two years of operations, but many of them were very rough to explore potential use cases. They learned usage patterns and then polished the most popular features. Now Coda looks good.

In a stable market, it is better to release well-polished deep features. For example, Linear is building a software project management tool and doing a great job here. Linear team doesn’t release many shiny things, but every released feature is deep and cool.

P.S. Every single perfectionist hates r-strategy. 🦐