Why Engineers Need to Think Like Product Managers – Especially in Services Companies

Introduction

My career has almost been split equally between service industry and product industry. Throughout this period one skill that I have noticed which sets engineers apart is ability to think like a product manager.

Normally in product companies, engineers work closely with product managers but in services companies the role of product manager is mostly dealt by the tech team itself. But regardless of how these companies operate, engineers who work with a product mindset always tend to build better solutions, communicate more effectively, and drive quality outcomes. I would also go further to say that for engineers working in services companies, this mindset is not just optional but also essential.

The Mindset Shift: From Builder to Problem Solver

The engineers are often trained to think of their job as “build what’s asked.” But when the job involves directly working with the client, what’s asked is most often ambiguous, incomplete, or not thought through.

Engineers who think like product managers ask questions such as: 

• • What’s the business goal behind this feature?
• • Is there a faster or more efficient way to achieve the same outcome?
• • Does this need to be built right now or at all?

When engineers start asking why instead of just what, they become partners in building the system rather than just implementers of the system. 

Why Engineers Need Product Management Skills

The operational dynamics of the services companies are different than the product companies. They operate under tight timelines, budget constraints, evolving requirements and involved with clients who may not be technically fluent.

In this world, the engineers play critical role. They are required to:

• • Lead client workshops.
• • Translate vague business needs into concrete specs.
• • Manage scope creep and setting delivery expectations.
• • Make architecture decisions with long-term maintainability in mind.

If you wait for a Product Manager to guide you towards more concrete requirements, then you may be waiting forever. It is here that thinking like a Project Manager helps engineers to bridge the gap between client need and technical execution.

Why It Also Matters in Product Companies

Even when PMs are present, engineers with a product mindset come up with better architectural decisions by considering future product directions. They think through edge cases which PMs would have miss. They suggest simpler solutions that solve the problem without over-engineering.

The benefits of engineers thinking like product managers are:

• • Faster iterations.
• • Fewer misalignments between engineering and product teams.
• • Stronger collaboration and mutual respect.

Skills Engineers Should Borrow from Product Managers

Whether in a services or product company, these four traits set you apart:

1. Customer Empathy

Engineers should understand who you are building the system for and why. Ask questions like:

• • Who are the end users?
• • What problem are they facing?
• • How will we ensure the problem is best solved?

2. Prioritization

All the tasks and requirements are not of same priority. Think like PM and ask:

• • What’s the most valuable thing I can ship right now?
• • What can we defer or de-scope to meet deadlines?

3. Communication

Engineers often need to explain solutions to non-technical stakeholders. That often means translating technical trade-offs into plain language, so the stakeholders can make informed choices.

Instead of diving into jargons, an engineer might say:

• • What matters more in this situation speed of delivery or long-term sustainability?
• • Are we optimizing for immediate impact or future growth?

4. Ownership of Outcomes

It is every engineer’s responsibility to own the business impact. They should not stop at ensuring that code compiles, they should focus on whether the feature works for the user.

How We Encourage and Practice this at Stryv

Here’s how we foster a product mindset across our engineers.

• • Engineers are included in early client discovery and planning sessions.
• • Tech leads are coached on business communication and solution-oriented thinking.
• • Sprint reviews emphasize the business impact delivered, not just the list of completed features.
• • Code reviews and architecture reviews are not just technical check, but also “value check” to confirm that the work moves the business forward.

This approach has helped us deliver faster, avoid costly rework, and earn long-term client trust.

Listed below are the few examples where our teams have gone beyond just building what was asked and thought like product managers:

1. Building Again a Legacy CRM System with Modern Tech

The requirement sounded straightforward, which was to take the legacy CRM system and rebuild it with modern tech. But the client had no clear specifications, only the legacy system as reference.

Instead of replicating everything blindly, our engineers took a step back and worked towards quick go-live and ensuring future scalability.

• • They went through the system page by page and flow by flow
• • They identified the minimal set of features needed for business continuity
• • They designed screens, navigation, and workflows from first principles
• • They built the architecture to be scalable, so future enhancements could be continued in after go-live

This turned the project from a rebuilding exercise into a strategic product modernization exercise.

2. Building a Scoring Engine

The client wanted a new application with a scoring algorithm. For this, only a pilot script was provided as proof of concept for the scoring engine with the expectation of productionizing it.
Our data engineering team took ownership of the outcome by going beyond implementation.

• • They analysed the source data and questioned its sanity and quality, working to establish clean and reliable inputs for calculation.  
• • They collaborated with the client to understand the end users and how they would consume the scores
• • They shaped the architecture and flow to generate results that were accurate, consistent, and trustworthy in real-world use

This wasn’t just about turning a script into production code. It was about ensuring the scoring system truly served its users.

3. Designing an AI-Driven Chatbot

The initial request was very high-level build a chatbot that answers guest questions using hotel data.

But our engineers saw the gaps and enhanced this requirement to cover other related scenarios.

• • What happens when the chatbot doesn’t know the answer?
• • Should it be able to fetch additional data online?
• • What if a guest needs a human in the loop to resolve their request?
• • How will the guest staff be notified of the requests from the guest?

This helped the client to understand the magnitude of the requirement which led to designing supporting screens, options, and workflows that made the solution future ready.

This sense of ownership transformed a simple chatbot into a comprehensive guest interaction system, complete with escalation workflows, extended knowledge sources, and a scalable AI architecture.

Conclusion

Whether you are building the next SaaS unicorn or delivering a client solution think like a Project Manager, build like an engineer. 

In product companies, thinking like a Project Manager makes you more effective. In services companies, it makes you truly indispensable.

The engineers who stand out are the ones who go beyond output. They dive deep into the problem, make informed trade offs, and care about the final user experience. 

The best engineers I have worked with never waited to be told what to do – they anticipated, questioned, and owned the result.