In 1937 Ronald Coase published one of the most frequently cited articles in economics–«The Nature of the Firm», where he introduced the concept of the Transaction Cost.

He claims that the company size is defined by the value its employees produce less the cost of the interaction with these employees.

So if you run a coffee shop, and five times a month you need a pretty Instagram post for it, then you should rely on a freelance designer as the value of him being a freelancer exceeds the transaction costs.

As soon as the coffee shop scales up significantly, your transaction costs of communication with that designer dramatically increase, and it's now cheaper to just hire him full-time.

Looks like it's the same story in product management.

I hypothesize that a customer starts using a product if the value is at least tenfold of the transaction costs of learning/remembering how to use it.

(The assumptions are that this customer is used to a traditional way of solving the problem, and the product in question DOES solve this problem, and the customer indeed has this problem).

I think that this is the main reason why startups focused on a specific and niche Job Story lose to multifunctional ones in the long run, even though the latter don't solve this particular Job Story so well. It's just because it takes too much cognitive effort to:

  1. Learn about a new app
  2. Decide to install it
  3. Register in it
  4. Familiarise yourself with how it works (and quite often it doesn't)
  5. Remember it every time you use it
  6. Pay for it separately.

At the same time, when you see a new feature in a good ol' Slack/Zoom/Instagram/you-name-it, your transaction cost of trying and using it is lower by an order compared to getting a separate app.

  • A specialized app for microphone noise cancellation > a feature in Zoom
  • An app for translation written words into Spanish > a feature in Google Translate
  • An app for courier delivery > a feature in Uber App

This seems to be the main reason why super apps are thriving.

So pack as many important Job Stories as you can along with your key Job Story and be merry.

But this is also a slippery slope to becoming a cumbersome catch-all monste

There are many bad examples too, such as:

  • Jira – a total mess; it's much easier to create a Kanban board in Trello
  • Adobe XD and Facebook Messenger are illustrative examples that an app turns into a cumbersome monster when too many Job Stories are jammed into it.

A few more words about Jira:

  • it seems to focus on a different segment. If you simply want a Kanban board, Trello has all you need. Atlassian – it owns Jira – doesn't care about it, because they wouldn't earn much on a user who just creates a basic board.
  • Atlassian bought Trello so that those users who grow out of Trello could switch to Jira within the same ecosystem.

And a bit more on Adobe XD and Facebook Messenger:

  • these are great examples of failed complexity management in app design. Figma and Telegram prove that a similar set of Job Stories can be dealt with in a much better way if you use your brain when designing the app.

The bottom line is – when you add new job stories, complexity grows exponentially. If you invest a lot in design, then the cognitive complexity for users may be growing at a slower rate than the cumulative value from solving multiple job stories. Examples of faster growth of the cumulative value than cognitive complexity:

  • Notion -> +public pages -> +comments -> +updates -> +boards -> +tables -> +everything-at-once-Atlassian-is-a-goner
  • Yandex.Taxi -> +Food -> +Lavka -> +Drive -> +anything-you-can-think-of-and-ultimate-dominance-yay

Examples of the cumulative value growing slower than the cognitive complexity:

  • Evernote
  • Zoom
  • MS Office