The Road to Become More Product Focused Engineer
My Strategy to Become More Product Focused
"Edward, to go from Senior to Staff, you will require a higher impact, and usually, it is an impact on the business instead of the engineering."
This is one of my feedback after becoming a senior engineer.
However, I'm puzzled by what he meant by "higher impact" and "impact on the business." Overall, hasn't shipping products and improved performance helped impact the business?
No.
He said, "A solid staff engineer is not only able to influence their decision on people, but also to have good business acumen to recommend and solve business problems."
In other words, being a programming language and distributed system design guru is not a good indicator of making a business impact. Why? Businesses don't care about any of those if you cannot prioritize or solve an impactful problem for the business. If you solve an impactful problem for the business, there should be a tangible product metrics impact, such as an increase in revenue because of your execution.
After that 1:1, I noticed that most staff engineers in the team are product-focused and pragmatic. They do not care about unit testing because it is what is "adopted" by the industry standard.
They ship code without unit tests if it can help increase business impact.
A product-focused engineer is invaluable to the team because they can turn an idea into a reality and help guide products to prioritize their roadmap.
I wanted to share this week's article with you on my goals and strategy for becoming more product-focused. With this article, you will gain some guidelines and a roadmap to also become more product-focused and sharpen your business acumen skillset. I break down into 5 areas of focus and an action item to build that area of focus.
Understanding Your Product and Market
If the programming language is learning about keys in the piano, understanding your product and market is like composing a beautiful symphony - it requires years of experimenting and understanding the intricacies of music that only comes with experience.
Knowledge of your product and market can help you become more effective in solving problems that are not only technically sound but also aligned with the product's goals and user needs. This also helps create productive collaboration with your product manager, customer support, and other teams to build a unified business strategy.
I remember when I was working part-time at a Taiwanese Restaurant. One perk was that all employees could get lunch and dinner for free on their shifts. In addition, the boss encourages us to try different types of menus and rate them to see why we love or hate them. One of the reasons he wants us to do this is so that when a customer orders certain food, we can explain them precisely and give them necessary recommendations based on our tastebud. My time there has created multiple return customers to the restaurant to get the food I recommend.
The takeaway is that it is important to thoroughly understand your current product, features, and functionality to have empathy towards improving your product.
If you are working on the referral program, you need to understand the main entry point to your feature. How many users are clicking the X button? This helps in understanding if the button you create is confusing. By understanding the referral program's features, you can see if you can achieve common tasks and goals of referring someone.
In addition to diving deep into your product knowledge, pay attention to your product's feedback. One of the best things to understand about your product pain points is by looking at your product's customer support tickets and community forums. This will help you gain insights into the opportunity for improvement in your product. For instance, if you are designing a referral program and you encounter a lot of support tickets asking the same questions about the status of their rewards, or "Why is my reward getting blocked?" that is a good indication of product improvement. This can be improved by making it more transparent and giving the reason to the user why their rewards are being blocked.
Understanding Product Metrics and Analytics
Quantifiable goals are defined by useful metrics. Appropriate metrics are critical to your product and team's growth.
Product metrics are important not only for products and analytics but also for engineers. Many larger companies have separated the product metric away from engineers and let engineers focus only on engineering metrics. This keeps foreign engineers from being more product-focused in helping products and businesses make strategic decisions. However, one benefit of being in a startup environment is that engineers are closer to the product. Thus, they can create a bigger impact on the product.
Each team has different success metrics. Therefore, it is important to constantly discuss the business results with the product manager and continuously integrate and prototype features based on the metric's feedback.
Our team has a business review every sprint. This business review is a review that indicates the status of all of our features and how they behave. This meeting is available for product and analytics, and the engineer is one of the required attendees.
I noticed in many of these meetings that engineers often have the most questions and have the most insight about "why" the result happens. The reason is that we build the product and have the most insight into how the system behaves. Therefore, the input of engineers has been paramount to drive the success of our product.
You understand the priority in managing various tasks and projects and know to work on the most impactful product first. For instance, if one of the performance metrics indicates that the feature you are building has a high load time, it signals a need for optimization, guiding you to focus on the most impactful tasks.
You can precisely measure the impact of your work. If you improve performance, fix bugs, or add new features, understanding the metrics indicates the tangible results of these efforts in terms of user engagement, system efficiency, and revenue generation.
Understanding the product metrics allows you to make more data-driven decisions in designing your systems.
Shifting Development Focused to User-Centric Development
Engineers are required to optimize everything in the past because there aren't as many tools available to optimize them. Before the revolution of cloud computing, many engineers were required to understand how to conduct failover and optimize their code to increase efficiency. This is mainly because mass computing power is not available to the industry. Thus, the engineer needs to focus on optimization to develop a great product. Fast forward, cloud computing has revolutionized how engineers design systems. They no longer require understanding how to manually failover from US-east-1 to US-west-2 and how to conduct rolling updates because cloud providers such as AWS and GCP have helped automate and optimize those tasks for engineers.
However, the engineer is still the most important stakeholder in the team because engineers are the ones who can help turn any ideas into a reality. They are the only ones who understand if such an idea is surmountable. They are the ones who can derive product insight into actual execution. Thus, shifting the mindset from development-focused to user-centric can help increase your impact as an engineer.
User-centric focused development is a development that focuses on the end user of the product rather than the technical feasibility and development. That means, when you work on some tasks, always consider how your work directly impacts the end-user and their experience.
Having a mindset of feature validation before building. Before starting development, validate the need for a new feature or enhancement. This can be done by user feedback, A/B testing, or analyzing user data to ensure we develop the correct product. For instance, to understand if you want to understand onboarding, Apple Pay will help increase your funnel; instead of starting a system design to onboard Apple Pay into the system, you can start by creating a fake button to gauge how many users click on that button. When the user clicks on that button, we can tell them we will work on it soon. This helps us identify the potential impact of onboarding Apple Pay.
Thinking beyond the code. Before you write any code, think about the broader understanding of the business context in which your tasks will impact. For instance, if you are working on a new button functionality, think about how this button is correlated to the overall business objectives and user needs. Understanding the business and market context first before developing helps simplify the process. Usually, this results in giving suggestions to the product on a simpler way to execute the product, which helps improve your iteration process.
Seek more collaboration with Cross-Functional Teams
Working closely with product managers, designers, and marketers helps improve your empathy with their perspective and involve them in product improvements and features discussions.
By understanding their perspective, you can broaden your perspective and provide you with a more holistic view of the product beyond the technical aspects. As a result, you can align your technical work more closely with the overall product strategy and objectives. Your work no longer fulfills the functional requirements but also enhances user satisfaction and contributes to the business goals.
Join each product strategy review and ask a lot of questions during those reviews to gain an understanding of the business terms. I realized going to these product meetings that the product manager also has the same problems as engineers explaining deep technical knowledge to other stakeholders - they often dive too deep into the KPI and specific metrics that other stakeholders aside from themselves know what that means. Often, I would have to ask what product metrics acronyms are, such as "GPPT" and "K-factor," to understand the bigger picture.
Experiment with every Single Product
Last but not least, every single product is an experiment. Therefore, a good product engineer will design their system to be extensible to experimentation.
Even through extensive user research, the new feature we will launch is always a hypothesis. There is no way to surely know if the "user will resonate with X feature if X feature changes its feature name to Y". Therefore, the software industry is accustomed to iterative development by conducting small experiments on each of their launches to measure if such a hypothesis works.
With each feature launch as experimentation, you must consider adding new features on top of your existing system and removing the features from your existing code. This helps you think of extensibility in removal instead of addition.
The key to iterating fast is to make your code flexible. This flexibility can be used to create a good configuration style to iterate on new referral programs or a good way to add or delete experiment variants.
Having an experiment helps you make reversible decisions.
I remember listening to Kent Beck's story about his tenure on Facebook as a TDD advocate and having written extreme programming; he said that Facebook engineers don't care about unit tests, but they care a lot about making their program reversible. Facebook engineers spend a lot of effort on making decisions reversible, and sometimes it takes "extra engineering" to make a decision reversible.
He said that,
"I talked with one of the managers and the network infrastructure, and he said that when they got a new piece of networking gear in and it went to the characterization labs just to put it through its paces, they mostly didn't care about its performance."
"They cared about whether we could turn this thing off safely. That's an investment in reversibility, all the feature flag stuff. That was one of the lessons I had to learn. People in code reviews would say, "Oh, you need to put this behind a feature flag. I'm like, "What? Why?" My attitude is to let me test it, make sure it works, and then I'll just put it out. "That is one of the big lessons that he learned on Facebook, and without experimentation and guarding your feature behind a flag, you are not going to be able to do that.
Recap
Becoming a technology leader is not just about tech skills but also understanding how our work affects the business. This means getting to know our products and market better, using data to guide our choices, focusing on what users need, teaming up with different departments, and trying new things in our projects. By doing all this, we do more than code well; we help our business succeed and make products that matter to our users. This shift in focus is key to growing as an engineer and making stuff that truly makes a difference.
What are your thoughts about this strategy? Is there anything that I should account for to be more product-focused?