Something I think a lot about nowadays as a CTO-turned-product-manager is what I've started to shorthand as the "product surface area" problem. I'll explain what I mean in this thread. (0/n)

1/ There are four ways your company can end up:

a. Lots of engineers, small product surface area
b. Few engineers, small product surface area
c. Lots of engineers, large product surface area
d. Few engineers, large product surface area

2/ When you have lots of engineers and a small product surface area, Conway's Law tends to reign. You break up your engineering team into sub-teams, with each representing a sub-component of your product. Think Twitter & Spotify, where they have teams like "Search" & "Feed".

3/ When you have few engineers and a small product surface area, you're in a classic "startup" scenario. Consider WhatsApp & Instagram (pre-Facebook-acquisition), which had <50 engineers each, but an intentionally focused set of features, and a huge number of users per engineer.

4/ When you have lots of engineers and a large product surface area, you see a "departments-as-product-line" organization, like at many big tech companies today. Think Google (especially in the Google Cloud division), Amazon/AWS, Microsoft, Apple, Salesforce, etc.

5/ When you have few engineers and a large product surface area, you start to get in trouble. Whereas companies like Twitter & Spotify have to figure out how to "deploy" many engineers, your team will need to "spread thinly" those few engineers among its many product areas.

6/ I think this scenario of few engineers & a large product surface area is when product management is most important.

You've got a real constraint -- engineering capacity.

You've also got a real benefit to "killing" product areas, which arguably only an empowered PM can do.

7/ Another fascinating dynamic is how every software co has the potential for a large product surface area. To understand this, we can study @simplenoteapp & @todoist. These are small teams. Arguably, these are also "small" products -- notes & todos. What could be smaller? Yet...

8/ They aren't as small as meets the eye. For example, Todoist & Simplenote each have:
- a rich web app
- desktop apps for macOS, Windows, Linux
- native mobile apps on iPhoneOS, iPadOS, Android
- sync service across all platforms
- APIs and browser extensions

9/ It's somewhat mind-boggling to realize how much sheer code is required to round out even an extremely focused product vision like "notes" or "todos". You can see how what seems like a "small" product surface area quickly requires a host of programmer skills & experience.

10/ Arguably a small enterprise SaaS company doesn't need to go as deep on "rounding out" everything the way Todoist & Simplenote have. But, yet, "consumerization of enterprise" dictates that enterprise users have the same expectations of their tools as consumers do of theirs.

11/ But, at the end of the day, there is a natural market pull to "spread" engineers, like peanut butter, among these disparate product areas. This inevitably means (so long as your engineering team is small) that they can be dragged away from the core, or from future innovation.

12/ The last point I want to make is about dev specialization. Arguably every midsize software co (say, 20+ engineers) with a widely-used product has a team of specialists rather than generalists. Frontend, Backend, DevOps, PMs, etc. A "specialty bottleneck" thus emerges.

13/ A "specialty bottleneck" can be as simple as, "We have a native iOS mobile app in Swift, but only one of our devs has Swift/iOS experience." This thus means that dev is a bottleneck for any development in on the iOS app. But there are many other such situations.

14/ So, in this few engineers + large product surface area scenario, the PM has to reduce the product surface area (if possible), identify the dev specialty bottlenecks, ensure tech platform simplicity, and, perhaps, identify a path to faster revenue growth, & thus a hiring plan.

15/ Now that I've developed this 2x2 on "engineering capacity vs product surface area", it's also led me to be skeptical of product management "practices" at places in a different quadrant than the world I live in. That is, Twitter's & Google's PM problems are not my PM problems.

16/ It's a very different world for a PM where a cash machine is running in the background, making it so that the engineering organization has hundreds or thousands of heads. Here, PMs are deployed to "figure out what to do with them". Keep that in mind when you read their takes!

17/ I think "Few engineers, small product surface area" is a sweet spot, in many ways.

Companies that can really nail the minimal necessary product surface area, and not over-hire engineering around it, can have small companies with huge impact -- and great business models! /Fin