Product companies offer more opportunities for growth
Before I even landed my first job I knew I wanted to work for a product company. I have changed a few companies, but my attitude has remained the same.
Product companies build and sell their own product. Service companies build other people’s products. Here’s three reasons why I believe product companies provide a quicker route to engineering maturity.
All three are underlined by the same reason - longer application lifespan.
Reason one: maintenance.
Service companies build, test and hand off the application to the client. From that point onwards, the application is under client’s ownership and they maintain it. Some contracts include maintenance work, but it’s not nearly as frequent as maintenance you’re required to do in a product company.
Maintaining and growing something over time is the golden goose of growth. Building a greenfield project is easy and fun. Building on top of something that’s existed for 5+ years is significantly more challenging. Maintaining something you didn’t even build, there’s no documentation and all the contributors are no longer at the company is a rollercoaster of stress.
But this is where your growth lives. Longer product lifespan leads to more challenges which leads to more growth.
Reason two: ramped-up requirements.
Service companies make money by building the product for someone else. Product companies make money by selling the product they’ve built. This distinction is really important.
In a service company, bad business plan and poor specifications are not my problem. You’ve paid me to build and ship, as long as I do that per our agreement, I’m “in the clear”. I’m convinced this is precisely why there are so many service companies around.
People have figured out it’s easier to make money off someone's bad idea, than coming up with a good idea and executing it.
Product companies require more intentionality. Not because it’s our “baby”, but because it’s our income. The thing needs to work, it needs to sell and it usually needs to keep improving over time.
Implications are usually tighter latency requirements, hot/cold data storage problems, different consistency models that pop up over time, etc.
Stuff gets hairy when you need to make money off it in the long run.
Reason three: domain experience.
You’ll gain significant domain experience in each product company you join. It will be required of you, sooner or later. This is amazing, because domain knowledge is extremely valuable.
Say you were working on a banking system for two years. You’ve made yourself more attractive to all banking opportunities in the future, precisely due to your domain knowledge. You know what’s APR, how to manage account balance, or even some fraud detection mechanisms on your day one.
This means better salary on day one too.
Another related point is that immersing yourself in a particular domain can allow you to tackle complex and challenging problems. If you’re building the same Webapp over and over again, only for a different client, you’re losing this valuable growth opportunity.
Granted, you may see more different problems, but the depth simply isn’t there.
What do you think about my take? Am I capping my own potential with this train of thought?
What you get from day one
When your colleagues can’t stand your industry rants anymore, you start venting on Substack. And in that tone - welcome to my newsletter!
While I mostly agree with your points, I still believe that working in software consultancy offers more opportunities for growth, especially early in one’s career.
In addition to building products, I gained valuable experience as a pre-sales consultant, which helped me develop skills in architecture and estimation. I was regularly exposed to a wide range of projects and worked alongside developers with diverse and extensive experience. This variety accelerated my learning significantly.
Many of my consultancy projects required full end-to-end ownership, covering everything from setting up CI/CD pipelines and building features to writing complex automated tests. In contrast, some product teams in product companies have limited exposure to such areas and, for example, might not even understand how their CI/CD pipelines work.
Regarding maintenance, I’ve also worked on long-term projects where my role was to maintain and improve existing codebases, sometimes even rescuing projects with significant architectural or performance issues.
As for requirements, I’ve been in roles where I mentored client-side developers, guided them on best practices, and helped them achieve quality and security standards.