I recently hypothesized about what Cloud 2.0 should mean.

In short; "Mis en place across foundational business functions. Cloud 2.0 products and companies should focus on first principles of designing, shipping, and selling software. Guiding the builders with leading indicators of product market fit."

In the post, which is a bit of an unorganized rant admittedly, I eventually landed on tooling. I wrapped up with a point along the lines of; all the tools are there for Cloud 2.0 already, we just have to put some of them together. Meaning, we already have the software development, design, and sales tooling available, but the right bundling of those products and features is yet to be seen, and once it is, would change the game.

So let's say we already changed the game.

Let's say all the right features and tools were put together in one cohesive platform with super fast feedback loops.

Let's say we have teams and teams of people using the same, unified, super-platform.

Great, right?

Only if this super platform alone would increase a team's return on work such that they were more likely to achieve product market fit, profitability, and scale better, faster than without the platform.

The problem is, I'm not so sure it would anymore.

Consider this quote from DHH on how they (37 Signals) manage projects at Basecamp;

Programmers are trained in consistency and coherence. They're key properties of writing good code. But sometimes chasing those properties outside the code just don't offset the cost of doing so. Managing projects, be they code or otherwise, is mostly about communication. Making decisions about how things should work, doing the trade-offs to ship within the time allotted. That's the kind of work that benefits from narratives, selective highlighting, and human context far more than it does from some procedural idea of Tying It All Together.

– David Heinemeier Hansson, Tying It All Together

With that in mind, I'm not confident that a kind of super-platform would actually help teams build and ship better and faster, and sell better and faster, because ultimately, the foundation of designing, building, shipping, and selling software products lies in communication.

When there are delightful narratives, selective highlights, and clear context, due to great communication, projects are likely to succeed.

Amazing communication, not just the tooling, translates into getting things done in a better way, and thus getting to the things I mentioned before; product market fit, scale, profitability, etc. The how, who, when, why are primary. The what and where are secondary.

You're unlikely to hear someone say, "I wish we would just communicate worse."

The tooling will always change, so invest in the things that likely won't.