Why you need to care about Product
Product is the most critical pillar of a squad. It doesn't matter if your tech stack has 100% unit test coverage and your team always delivers on time if the deliveries have no impact. Most startups fail because they run out of cash before shipping a product that people want.
Even if you're not in a startup, every team operates like a small company within a larger organization. If no one is interested in your product, it's only a matter of time before the team disbands. Your mission is to solidify your squad's reason for being before that happens.
The first step to shipping the right things is knowing your problem domain. Answering "What problem was my squad created to solve? For whom?" helps you understand your target market and your customers' issues, such as how they work around them currently and what value will be delivered when they use your product.
In most companies, a squad will also include a Product Manager (PM) who typically owns this pillar, but Product is ultimately a shared team responsibility. It's too important to leave up to one person.
Product Manager vs. Engineering Manager
Your product manager (PM) champions the "what" and "why" of a product. They conduct market research and user analysis to understand your target customers, who they are, and the problems they need to solve.
Using this research, PMs map potential solutions and features. They then prioritize these solutions based on the value they could bring, such as potential revenue, increased user conversion, or better engagement.
Having a product manager on your team is a valuable asset. While engineers complain about the extra meetings PMs schedule, some are critical for defining the right product to build, ensuring engineering efforts are well-directed.
They help answer the ultimate question: "Are we building the right thing?".
Collaborating with your PM
If you have a PM, you need to work closely with them to establish a healthy product roadmap and receive context on the expectations around your squad.
It's your responsibility to communicate on technical blockers that could impact the final product or its delivery date and align tradeoffs. It's their responsibility to provide your squad with new projects that will have a significant impact. You must keep each other accountable for each doing their part.
Your PM will be talking with all sorts of people—executives, clients, other PMs, and leads. These chats often spark requests that need your technical perspective. Sometimes, these requests are pretty straightforward, and your role will be to help figure out the best timing for them on the roadmap.
Other times, a new idea might not be quite doable with your current tech. You must push back, align, and adjust the scope to seek a better impact-to-effort ratio.
Once your team assembles a part of the roadmap, you'll delegate the solution's architecture to your engineers. You'll then work with them to establish milestones and deadlines, communicating these back to the PM.
This close collaboration also helps your PM build trust in your team, which is critical when you provide effort estimates for proposed solutions. They must believe in your team's capability to deliver, as they'll often defend your timelines and plans to upper management.
When you don't have a PM
If you don't have a PM, someone needs to act as one. In companies where the PM leaves or becomes overwhelmed, the team might see its product roadmap stall, run out of projects, or begin prioritizing the wrong initiatives.
Not having a dedicated PM permanently can be reasonable in specific scenarios. For example, the CEO often takes on this role in early-stage startups, building client relationships and bringing market insights directly to the engineering team.
Another squad scenario that doesn't require a PM is a purely technical project, like a large-scale database migration. Here, the target value and success metrics are often so clear that the technical team inherently understands the "what" and "why."
Why your engineers also need to care
Managers are responsible for the product, but it's essential for everyone in the squad to care about it, even if you have a highly competent Product Manager. Getting your engineers to care about the product is one of your core responsibilities as an engineering manager. You need to be an evangelist for the problems your team is there to solve. Help your engineers develop empathy for the challenges your clients face and see their work's positive impact on clients' lives once the project is delivered.
The first reason you do this is to motivate people. A few times in my career as a developer, I wondered, "Who is this feature even for? Who will use it?". No one on my team knew. We were doing it because we were told to. Our morale was low, and we felt we were working on things that didn't matter.
The second reason is that your team isn't paid to create code but to solve problems. Code has value only when it affects the end-user. Sometimes, a simple no-code integration is better than a fully customized solution. Your engineers need to understand the value delivered to be more efficient when assessing tradeoffs in a solution.
The last reason is that a team must be passionate about problems, not solutions. Initial ideas rarely happen as planned, and the same goes for codebases and architecture. You want your engineers to be able to pivot quickly away from a solution that might be a dead end and focus on solving the problem in other ways if necessary.
The cost of not caring
If engineers don't understand the product value delivered, they will build the wrong product, which will be discarded by the market or reworked. If they run into a blocker, they won't be able to analyze whether the effort is truly justified and propose tradeoffs. Instead, they will overspend time on 'nice-to-have' features that don't align with core priorities because they lack product context.
Some companies try to work around engineers not caring about the product by creating tickets with very strict "definitions of done." The goal is to reduce the risk of engineers building the wrong thing. However, this approach doesn't help engineers see the bigger picture, especially when context is only provided at the ticket level.
This approach also overloads PMs with ticket writing and takes their time from doing product discovery. Broader team involvement could spark new ideas and provide valuable feedback for shaping the product, maximizing value, and minimizing effort.
We call the role "software engineer" and not "software coder" because engineering requires a deep understanding of problems to build solutions.
With the rise of LLMs, software engineering is becoming even more like traditional engineering disciplines. For instance, electrical engineers design circuits but don't necessarily lay all the wires themselves. Civil engineers design buildings but don't personally construct them. Engineering problem-solving starts with design, not at the act of building.