One mindset to become a software engineer with product sense

The most common conflict between the product team and the development team is the misalignment of the goals. To solve this as a dev team lead or a software engineer within the team, all you need is one fundamental mindset to shape the product sense:

⁠Focusing on the outcome, not the output.

Why product sense is important?

With it, you can have a more clear view of where you put your time on, maximize your contributions to your team and company. This will dramatically help you in your software engineer career.

Outcome v.s. Output

Focus on the outcome means it has some significant values from the user's perspective. Does it save their time on certain tasks? Does it empower users to achieve what they can't without the software product? Does it have a better performance than before?
Focus on the output means just continuously delivering some features or doing some refactors in the codebase, without even knowing anything else.

Following are three questions to ask that will help you focus on the outcome:

1. Do you know what's the problem to solve?

As a software engineer, if your day job is only about deciding how to implement the given solution, it only uses half of your talent. What makes software engineers valuable is the ability to leverage technology to figure out the best solution to the problem.

2. Do you know how is the product/feature being used?

Spend some time looking at the statistics of the delivered features. Get the feelings about how users are using the product, if no one using it, discuss the go-to-market issue with the product manager if users are trapped in certain steps then talk to the designer. Again, getting all these statistics and feelings will help you have a clear view of what is happening. Besides just being assigned ticket one by one, you can initiate some important discussions according to what you've noticed, this can definitely help you put more time into implementing things that create value.

3. How will it impact the performance?

When introducing a new feature or system design pattern, we first will consider the maintainability or if it's implemented in a "clean" enough way. When it comes to outcome, there are two more important things that should be considered:

From a team perspective, how will it impact the build time or the developer experience, will it let our team suffer in a longer waiting time for each build?
From a user perspective, will the user need to wait longer for the response time?