In this article, I reflect on my journey as a software engineer and the lessons I've learned from building products. Through my experiences, I've come to understand the importance of focusing on outcomes rather than outputs, and I believe this approach is key to creating products that truly deliver value to users. In the following sections, I'll discuss the challenges I've faced in my career, the role of mentorship in helping me learn and grow, and the importance of being directly involved in product development in order to solve real customer pain points. By sharing these insights, I hope to provide some inspiration for others who are also seeking to build products that matter.
At the very start of my career, it was all about going solo. I started as a solo developer, doing tiny contracts and barely making more money than I would make if I spent the same time at a local McDonald's. No matter what, I loved that - earning money with something that started as a hobby is very empowering and I feel grateful for it.
I quickly realized that it wasn't a way forward forever - at least not for me. If you go solo, it is important to have strong mentors within reach; it is much easier to learn with great teachers around you. The exercise I like to use to check how I am doing is to ask myself if I ever feel like I am the smartest person in the room. If I do, it means I am in the wrong room and I should move on. It doesn't work well for this corner case, right! Being exposed to other, more senior, developers, and other roles in product development was essential for me to broaden the context; it helped me massively to see the value of considering the long-term impact of my work and striving to solve real customer pain points rather than just churning out code. This shift in mindset has been crucial for me in terms of delivering more effective solutions.
Like many developers and engineers from my country, later on I moved to an agency delivering (usually small) software solutions. And honestly, it was great. Here and there I had ad-hoc mentoring sessions with my peers and I feel quite strongly that a good agency is a pretty good starting point for one's career. Looking back at my younger self, I was able to touch a variety of different tech - implement them from scratch into greenfield projects, see them fail and rebuild them again. I was able to experiment with different languages, frameworks, and services. It would take an entirely different article if I dived more into how development, 10 years ago, was for me. However, that's not what I want to write about. At least not today.
The thing different agencies have in common is the fact that it's usually hard to be working on something personally meaningful. Something you can connect to. Yeah, you might be super invested in some new technology and then the client might be so kind as to have you implement it for them. But sooner or later you realize that if you are detached from real customers, you'll start losing interest and, worse, you will solve the wrong problems. You might spend months building the best real-time architecture just to realize there is little to no collaboration happening and simple polling would do the job.
When I was a child, I developed games for fun; Game Maker was my obsession. It was amazing to be able to create games, rules, and universes - whatever I could think of. Maybe also because of this, I realized what I needed was to be directly involved in product development, to be part of something great for the end users, creating emotion and delivering value to them. I know it is tempting to focus only on the technical aspect, but I ultimately think the outcome is all that matters. I'm a missionary, not a mercenary; your users don't care if your Todo app uses Redux or not, they care about getting value from it.
Outcome is the key: it took me a few years in my career to recognize that aiming for outcomes rather than outputs is the key to success and feeling grateful for what you build. Solving some user pain by removing a bunch of code is the nice outcome - I'd even argue that's what I consider the best, and I celebrate every moment when I remove code, especially my own. The difference is that if you are judged by outputs, it is much harder to sell the fact that you removed code; at worst, you might even look incompetent for having written it in the first place. Shame.
If you have never experienced a truly empowered product team, trust me, you are missing out and you should fix it. If you want to read something about this topic, I highly recommend INSPIRED: How to Create Tech Products Customers Love by Marty Cagan.
The book describes, among other great things, four big risks in product development:
market risk (will the product or service be perceived as valuable by potential buyers and generate sufficient demand?)
usability risk (will users be able to easily understand and use the product or service as intended?)
feasibility risk (do we have the necessary resources, skills, and technology to successfully develop and deliver the product or service as planned?)
business risk (will the product or service support the overall goals and objectives of the business and be financially successful?)
In a nutshell, there are two basic buckets where you might end up as an engineer: a feature team or a product team. Your affiliation determines all the rest of the relationships you might experience while being a member of either one or the other group. Feasibility is a concern of engineering, that's clear. Hopefully, you always have a dedicated designer, so you can cross out the usability risk as well. Although good product designers want to seek solutions, not draw borders and buttons someone sketches out of the blue. Where it starts to be tricky is business and market fit.
In a truly empowered team, this is a concern and explicit responsibility of the product manager. On the other hand, in feature teams, it is usually an executive or another stakeholder pushing the feature onto the roadmap with the expectation of a return on investment, expanding the business, or both. The product manager then serves more like a project manager, trying to handle all the parties and eventually helping the project to get delivered, left at the mercy of stakeholders.
You might be wondering what happens in case the thing you deliver is not performing as expected. You guessed right, it will mostly be your problem. They would blame bad design, that it took too long, or that it was underutilized, or all three together.
On the contrary, in the case of empowered product teams, you do the research as a team (I highly recommend taking a look at the Double Diamond approach), you propose the solution, and it is your responsibility to properly validate the solution and keep iterating until the problem is solved. The goal is to solve the problem, and learning how to do it well enough is part of the journey.
Of course, nothing is that simple in the real world, and the buckets I described are more like a spectrum that your team might be on. However, there is likely space for both types of teams, especially during different times and company phases. It is essential for you to understand where you stand so you can set your expectations correctly.
One last thought I cannot resist pointing out is team play, a crucial part of product teams. By being too restrictive about the roles and responsibilities of each team member, you may not fully utilize their skills and expertise. In my opinion, engineers should be allowed to participate in activities such as product discovery and strategy sessions, as they often have valuable insights as users of the product and may be able to identify opportunities for improvement that others might overlook. Encouraging cross-functional collaboration can lead to more creative and efficient solutions.
With that said, I wouldn't be surprised if a really good craftsman would prefer to work in an empowered product team where they can work on more than just stacked JIRA issues, prioritized by someone who might no longer be with the company.