So, you are an entry-level or mid-level software engineer working in tech, trying to build your career while also making a meaningful impact on the product you’re developing. You’ve become proficient at coding, started contributing small features, and are progressing towards building end-to-end functionalities. But what truly sets apart a great engineer from a good one?
The key lies in a mindset shift, from being a feature builder to becoming a Product Engineer. This transformation will not only accelerate your growth as an engineer but also help you make substantial contributions to the product’s success.
Beyond Just Writing Code
Until now, your workflow likely involved receiving well-defined requirements, attending grooming sessions, and then jumping straight into development. For example, you might get a ticket in your backlog, discuss it in a sprint planning session, clarify a few details, and then start coding right away. For years, this has been the norm in many organizations. However, in today’s fast-paced, product-driven teams, this is no longer enough. Engineers who want to make a real impact must go beyond execution and actively engage in product thinking.
Let’s break the process down into three key phases:
1. Why Phase — Understanding why this functionality is needed in the first place.
2. What Phase — Planning what needs to be built to achieve the intended goal.
3. How Phase — Engineering and execution: designing, coding, testing, and deploying the feature.
Most engineers are already proficient in the How Phase, as it’s a routine process — writing code, testing, merging PRs, and deploying. With experience, engineers also get better at the What Phase, where they define requirements and propose solutions.
The Importance of the ‘Why’ Phase
But what happens when you realize that the feature you built doesn’t actually solve the problem? Imagine spending weeks developing a new dashboard, only to find that users don’t even use it because it doesn’t address their actual pain points. What if the feature wasn’t even necessary in the first place? Time, effort, and developer hours are wasted, leading to a real financial cost for the company. Worse, the motivation of the engineering team takes a hit.
This is why the Why Phase is critical, especially in startups and fast-moving product teams. Great engineers don’t just execute tasks; they question assumptions, validate problems, and ensure they’re solving the right issues.
Mindset Shift: Asking the Right Questions
On the surface, questioning the ‘Why’ may seem simple, but it’s often the most overlooked part of product development. In a startup or an agile environment, this is one of the most crucial skills you can develop. Asking the right questions leads to better alignment, fewer wasted efforts, and stronger products.
Here are some key questions to consider:
Why are we building this feature?
How is this useful for the end customer?
What is the actual pain point the customer is facing?
Does the solution being proposed actually solve the customer’s pain point?
Why are we choosing solution A instead of solution B?
The customer might ask for a feature. But does the customer really need it? (This happens a lot)
The customer might ask for a feature. But doesn’t this deviate from our overall product strategy?
Why is this feature needed in Q1, while it can be addressed in Q3 or Q4?
Why is this feature X prioritized over feature Y?
Who should you ask?
The answer depends on the feature, your company’s org structure, and the product development process. Generally, the Product Manager (PM) is a good starting point. However, don’t limit yourself, insights can come from solution engineers, directors, CTOs, CEOs, and even direct customer interactions.
Pro tip: If you have access to direct customer feedback, leverage that data to validate your assumptions before writing a single line of code.
Becoming a Product Engineer
Transitioning from a software engineer to a Product Engineer isn’t about taking on a new job title, it’s about thinking holistically. This means considering not just how to build a feature, but why it’s needed and what impact it will have on users and business goals. Instead of just focusing on implementation, you become a stakeholder in the product’s success. This means:
Being proactive in understanding the business and customer needs.
Engaging in discussions about feature prioritization and trade-offs.
Taking ownership not just of the code but of the impact it creates.
Final Thoughts
At the end of the day, great engineers don’t just write code, they solve problems. By actively questioning and understanding the ‘Why,’ you go beyond execution and contribute to real product success.
So, the next time you receive a feature request, take a step back and ask: Does this truly matter? If the answer isn’t clear, start a conversation, gather data, and make sure you’re solving the right problem before diving into code. That’s the mindset shift that will set you apart as a Product Engineer.
