The modern enterprise software company

Back in the 20th century, making enterprise software was a long and arduous process. It involved spending time with customers, writing down their business needs, then translating them into hundred-pages functional requirements documents, to build or integrate the application finally. End-users mainly interacted with on-premise applications which were, at best, manually updated twice a year. It was costly for the software company, both in terms of initial investment and maintenance. It was costly for the customers, and the overall experience for end-users was terrible. But it worked.

Then, at the end of the 2010s, we started getting simple, aesthetic and affordable (if not free) consumer applications: Gmail, Facebook, WhatsApp, Uber, Airbnb… But, while simple-aesthetic-affordable was becoming the norm on our phones and computers, enterprise software was still stuck in the 20th century. Most enterprise software was still built brick by brick and sale by sale. It was still more focused on pleasing the buyer instead of the end-users, and it was still expensive. Hell, even today, 36% of developers confess using Waterfall methodology in some way at their company. Slowly but surely though, enterprise software companies have started to change.

A new wave of companies founded over the past ten years (Slack, Dropbox, Zoom, Stripe...) has started to look a lot more like their consumer counterparts. Like them, these modern software companies have an initial low cost of development, are focused on building the very best product (simple-aesthetic-affordable), and target end-users directly.

In the table below, I have highlighted seven software companies’ practices and how they differ in legacy and modern organisations.

The new user expectations

Have you been in a place recently where 4G reception was crappy, and the Internet was super slow on your phone? How did you feel? Probably frustrated 😫 As comedian Louis C.K. sums up in the below interview, people take modern-day technology for granted and forget about old usage as soon as new ones appear.

You can see the same pattern with software applications. End-users now expect applications to work all the time, from any device, with their data magically updated everywhere. They expect new features to be released regularly and bugs to be fixed even sooner. They expect all their applications to connect easily with each other, without any manual integration. And they expect to try their applications extensively, ideally using a free version of the product, before making any usage decision.

To cope with these new user expectations, software companies had to make technological and methodological changes to release more scalable features faster. For example, JavaScript has recently become the most widely used programming language for designing interactive frontend enterprise applications. JavaScript frameworks do more with fewer bytes from the server, resulting in low network latency which in turn improves end-user experience. They are platform-independent, and their grammar makes it easier for developers to write programs.

Another example is the use of microservices. As defined by Martin Fowler, “services are built around business capabilities and independently deployable by fully automated deployment machinery”. A microservice architecture makes it easier for the development team to release new changes to customers quickly in a sustainable way.

This process, called Continuous Delivery, allows development teams to release quality products frequently and predictably from source code repository to production in an automated fashion. A microservice architecture can also force the different systems to be more open to the external world since they already use APIs to communicate between themselves. It the early days of Amazon, Bezos even threatened to fire any engineering teams that did not expose their data and functionality through service interfaces).

But making technological choices is not enough since, according to Conway’s law, “any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.” To release user-focused quality features quickly and frequently, software companies also need to update their organisation.

Product vs Project Management

As we’ve seen, a great product is the first focus of modern software companies, and product management, a job which has elements of engineering, design, business and project management, is key to building great products. It is the practice of identifying and building out products that are viable, feasible and desired by customers.

While Product Management is a relatively new position, it has become central to the success of companies like Google, Facebook or Dropbox. At these companies, product managers are considered like the CEOs of their product and take care of its full lifecycle, interacting with customers, engineers and support. They usually wholly own a functional part of the product, working with a small team of developers to decide what ideas to build, how best to implement them and are in charge of ongoing operations.

These teams can be tiny (one tech lead, two developers, one product manager and one designer at Hubspot), or slightly bigger (6–12 people at Spotify). But whether they’re called feature teams, product teams or squads, the central theme here is the focus on what Venture Capitalist Peter Levine calls “design-first, code-second product development.”

In the past, companies would often write code first and then build the user interface as an afterthought. However, users now expect all applications (even enterprise) to deliver the same ease of use, and design and UX have become a competitive advantage. We increasingly see more cycles spent on design iteration. Products are prototyped as a nearly functional app, beta tested with users, and then code built from the design. With this design-first, code-second approach, products are more dynamic and fluid, and teams can iterate on new ideas faster.

Peter Levine

Product managers, together with the rise of agile methodologies, have also started to overshadow project managers. In the waterfall model, project managers were necessary because it was all about flawlessly executing the requirements, projects were usually very long (>1 000 person-hours) and involved integration with multiple teams. In the new model, the focus is more on product-market fit (through user research and A/B testing), sprints are very short (~ 100 person-hours), and the need for coordination with other teams is much lower since every system has documented APIs.

Growth+Sales

Slack is probably the fastest-growing enterprise software company of all times, and it achieved the majority of this growth with no sales team. If you go on their website, the primary call to action is not contacting sales (which you can do now), but the ability to try their software for free.

Project management software Basecamp has hundreds of thousands of customers, but no sales team. Mailchimp, the world’s leading email marketing software, made $700 million in revenue in 2019 and, still, today, has no sales team. The secret here: focusing, again, on the end-user as the primary decision-maker. End-users don’t care about white papers, analyst research reports and sales pitches. They only care about how well the product delivers on solving their problem.

This product-led growth strategy can be summarised in the following steps:

1/ Make the best product with easy-to-use and slick features that truly solve users’ problems

2/ Win the end-user mindshare with consumer marketing techniques (educational content, branding, community building…)

3/ Fuel bottom-up enterprise adoption by making existing users your inside sales agents (building, for example, viral loops and high stickiness into the product)

Obviously, this approach doesn’t work all the time. When your product requires access to secure business systems authorised by centralised IT, the CIO remains your go-to person. But, with the generalisation of external APIs, IT systems are becoming more interconnectable, leaving more space for operating departments to make or influence IT purchasing decisions.

News

This section is only available to email subscribers. Sign up, it's free!

Summary

• End-users now expect enterprise software to be like customer apps: simple products, precisely solving their problems, that work all the time, with new features released regularly
• Modern software companies are now behaving like customer companies, making technological and methodological choices focused on end-user satisfaction
• This focus on end-users is also fuelling their growth, enabling a new kind of sales model without (or with few) salespeople

Reading List

[ESSAY] The SaaS Manifesto: Rethinking the Business of Enterprise Computing - Peter Levine

[ESSAY] What Is a Modern Software Company? - Victor Soares, New Relic blog

[VIDEO] Growth, Sales, and a New Era of B2B - Martin Casado

[BOOK] Hooked: How to Build Habit-Forming Products - Nir Eyal