“As a product builder, you're invested in the long-term success of your creation. As a consultant, you're focused on delivering immediate value to your clients.”

— Jason Fried, founder of 37signals

The first thing that I want to clarify with this post is: customers buy products from you, and clients hire you for your services/expertise.

Some people might say “Customers, clients… They’re the same, it’s just semantics!”, but we should all know by now that semantics do matter — especially in software development 😄

The second thing that I want to emphasize is: I love to work in product companies.

I’ve done some consulting work throughout my career, and life in general was good, but I don’t think I’ll ever be able to go back and work on projects for clients again.

In today’s post, I’ll be sharing my thoughts and experiences about working for both types of companies and why I prefer one compared to another — so let’s go!

Building (and iterating) products for customers is so much better than delivering code to clients

Creating something from almost nothing is definitely one of my favorite things about being a developer — it’s insane that just typing simple words and characters into a couple of text-based files can solve problems for millions (if not billions) of people.

Learning which words and characters you should use (and how to combine them) to make something happen is something quite powerful.

But…

Figuring out what to do with those superpowers, finding real problems that cause so much pain and frustration; problems that people/companies out there are so desperate to find a solution (and to pay for it!) — for me, that’s the real deal.

When you work in a product company, you find yourself working side-by-side with amazing people whose job (and expertise), is to figure out what the market/customers need and bring these insights to the team, so that we can work on them together.

This changes everything because it’s not just about delivering some requirements and implementing feature X or Y anymore.

It’s about understanding businesses and human beings, it’s about prioritization, it’s about strategy, it’s about storytelling, it’s about user/customer experience… You realize that engineering/development is just a piece of the puzzle and that you can’t finish it without the rest of the team, because every single one of those pieces matters.

Also, the puzzle never ends :)

There’s no final release where you have to hand off the whole codebase to the client and that’s it — you’re always iterating, polishing, and trying to find other (and better) ways to create more value for the customers, based on their feedback and insights.

Developers in service-based companies often work on multiple projects (for different clients) at the same time

I guess this is something that you can either love or hate, but personally, this was one of the factors that made me want to run away from consultancy — I hated it.

Context switching is for sure one the biggest enemies of productivity (especially for developers), and so often I found myself in the middle of something, after putting in hours of deep and focused work, trying to dive deeper into what I was trying to accomplish and once I was finally in the zone and ready to implement what I needed, I had to jump into another project (usually for another client), and start the same process all over again.

It’s “fine” to go through this now and then… I mean even in product companies there’s some context-switching happening due to meetings, bug reports, etc. But it’s completely different from the experience that I had back when I was doing consulting work, where codebases could be completely different, with different standards, different business requirements, different stakeholders to communicate with, different processes, different workflows…

One thing that I’ve recently discovered about myself is that I love systems.

I enjoy having predictability and consistency in what I do (and how I do it), and I also love to improve those systems — the emotional reward that I get from iterating and making something better is definitely unique.

But I need to learn about those systems first; I need to be fully immersed in them to be able to identify their flaws (and the respective improvement opportunities) before I feel confident enough to propose changes, and I found that this trait is more suitable for product companies because working on projects with clients usually have shorter lifespans and it’s not worth to optimize these sort of things.

Product-based companies scale better than service-based companies

Another great thing that product-based companies benefit from is that when you’re already solving a problem for a group of people, there’s a high chance this same group of people has a few more related problems that you’re also capable of solving.

This means that product-based companies can scale their revenue by adding more value to the same group of people (meaning, solving more problems), or by expanding the group of people they’re adding value to (meaning, acquiring more customers).

To scale a service-based company you usually do one of the following: either you increase the amount of time/expertise you’re selling (making more money, but probably at the cost of hiring more people, so you need to be extra careful with the margins), or you can increase your rates and charge more money for the same amount of time.

Ultimately this means that if you’re not able/willing to keep investing time in a service-based company, you stop making money.

In comparison, if you’re building a product company yourself, there’s a good chance it can make you money while you’re sleeping (or on sabbatical for example) — which you can say is sort of my life goal, but we’ll be able to cover that further in a future post 😄

That's it for today! See you next time 👋