Hey friend,

Up until my mid-level engineering, I didn’t think about the product. My focus was on writing good code, designing software well, and delivering it on time. Clean and readable code, decoupling dependencies and sub-systems, adapting to changes that Apple announced (I was an iOS engineer), and learning about collaboration strategies (Scrum, Kanban, etc.) were my focus. Although that focus made me a better mid-level engineer, I needed something else to go beyond mid-and senior-level when the time came. That’s where I realized that I needed product and process thinking. I’m gonna talk about process thinking in upcoming letters but let me open product thinking and how it is essential to level up.

There was a point in mid-level engineering where I started talking with stakeholders directly, looking at the data to understand the important user problems instead of waiting for my product manager or team lead to tell me what I needed to do. The behavior change broadened my horizon and extended my influence on the product and company as well.

Once I realized that I was hired to solve problems and have to understand the product to solve them, my career started to go up fast. I became knowledgeable about the product and was able to influence its direction. Thanks to product thinking, my focus moved from solution to problem.

What is Product Thinking?

Product thinking means thoroughly understanding the domain you’re working at, knowing the market your domain is part of, and how your product contributes to the overall business model and strategy. You need to actively keep the customer needs in mind and leverage input from product stakeholders and engineering leaders to determine the right technical solutions to deliver customer value quickly.

For example, I’m currently working in payment and billing systems. Therefore, I have to know billing, payment, invoicing, dunning, discounts, etc., so that I can understand the problems we’re facing. I also have to follow how the payment engineering market evolves and learn the changes and new technologies in the domain. Additionally, I have to know how our solutions fit into the business strategy, such as our subscription model, discounting strategy, and more. Although these topics are not related to coding at all, they make me a better engineer and engineering leader.

However, there is also an engineering side to product thinking: you have to understand your organization’s engineering strategy and its implications for your team. For instance, if you start a new project, you have to know which technologies you should use (programming languages, frameworks, tools, etc.) and which ones you should avoid. I’ve seen (many, many times) that a few engineers favor one programming language that no one else knows in the company and develop a product and leave the company after a year. What they leave behind is a burden, pain, and a codebase that no one wants to work on (Side note: please, never do that).

Why do you need product thinking?

Because if you want to develop better software, you have to understand the factors that contribute to the problem you’re solving. Without understanding your product’s strategy, how it will evolve, and the roadmap ahead, you will start accumulating technical debt at light speed. The system design and code structure will be flawed and inflexible.

If you don’t know the engineering strategy of your company, you’ll have unnecessary debates and create future problems such as knowledge gaps, ineffective onboarding, and not leveraging engineering tools available to you. I’ve seen many engineers get lost in creating the best architectural design because they focused on their engineering solution instead of the user’s or product’s problem. (I also made these mistakes, and that’s why I’m sharing these learnings with you.) When you focus on the problem and dive deep to understand the real issue before writing a single line of code, you get to meet with your stakeholders, collaborate with your teammates, and create a better solution that actually solves the problem.

That’s why you have to increase your product expertise and keep your users in mind. This way, you will deliver customer value quickly to get the fastest feedback. You will step up within your peers and start leading. If you leave product thinking to product managers, your chances of showing your excellent engineering skills will be low, and you will hit the ceiling whenever you want to get to the next level.

Simply put, instead of expecting someone (e.g., product managers) to tell you which product features to develop, you should be able to tell what are the most critical problems your users or product are facing and find the best solutions that fit into your product and engineering strategy.

— @candosten

P.S. Maybe you need to learn how to approach software architecture design.

Updates from The Last Two Weeks

📝 Learning Cone and Blame Spiral — The Case of Blame Absorbers

Some people learn the best when they take responsibility. When blame absorbers are not mindful or misguided, this behavior goes out of its way.

Blame absorbers are everywhere. It's not a personality; it's a behavior that everyone develops from time to time. For some people, it happens often; for some, it's rare.

I'm one of them and I wrote about how learning turns into a self-blame.

If you find this letter valuable, consider sharing it with friends or colleagues!