From IIT Madras to Consumer Tech Product Leadership
A feature can work exactly as specified and still leave people confused. That gap becomes important when an engineer moves towards product leadership. Technical knowledge helps explain what can be built; understanding the user helps decide what deserves to be built. The path from IIT Madras to consumer technology provides the career context here. The broader lesson concerns engineering design to product management: keep the discipline of testing a system, while widening the question to include the person using it.
Connecting technical thinking with user needs
An engineering background can be a useful foundation for product leadership. It helps a product manager understand constraints, question assumptions and work with the people responsible for implementation. The next step is learning to connect that understanding with what users need.
Prem Dharmani’s background connects study at IIT Madras with consumer technology work. The connection between those fields is problem solving: defining an outcome, testing possible approaches and improving a system through evidence.
Moving beyond the specification
An engineering specification asks whether something meets defined requirements. Product work also asks whether those requirements address the right problem.
Consider a sign-up flow with slow completion. A technical solution might reduce loading time. Research might reveal that users are actually confused about why a document is required. Both issues matter, but they require different interventions.
That is why a product leader must become comfortable with interviews, behavioural data and business context alongside technical discussion. A small project offers a way to develop those skills in practice.
Keeping the discipline of experimentation
Product leadership benefits from the habit of making assumptions testable. Before committing to a large release, define the riskiest belief. Build the smallest prototype capable of testing it. Record what changed after observing users.
For example, a conversational onboarding prototype can test whether people understand the questions before a team builds production integrations. A failed prototype may prevent a more expensive launch mistake.
Constraints and iteration connect engineering design with everyday product decisions. The practical lesson is to carry technical rigour into product discovery while allowing user evidence to change the original plan.
A familiar engineering problem with a different question
Imagine a team is asked to make an upload screen faster. An engineer might investigate file size and network delay. A product manager also asks why the upload exists and whether the user knows which document is needed. The slow step could be the technology, or it could be the user's uncertainty. The right answer depends on observing the task.
This is where an engineering background in product leadership can help. It supports useful questions about what is possible, while user research tests whether that possibility is worth building. Neither side works well alone. A beautifully researched idea still needs a workable service, and a technically clever service still needs a reason for people to use it.
Leadership is not having every answer
A beginner may picture a product leader as the person who decides everything. A better picture is someone who helps the team reach a decision that other people can examine. The leader makes the assumptions visible, asks for evidence and changes direction when the evidence changes. That is a practical extension of design thinking for products, rather than a departure from technical rigour.
The bridge between a technical question and a user question
An engineer may ask whether a service can process a request faster. A product manager also asks what the person is waiting to achieve. These questions belong together. Faster processing helps only when it improves the part of the journey that matters. A user who doesn't understand what to upload may remain stuck even after the system becomes quicker.
Think about a student using a scholarship application. The document upload works, but the labels don't explain which file is required. The technical system accepts valid files exactly as intended. The experience still fails because the person cannot confidently choose the right document. Product work helps the team see that a correct implementation and a clear experience are related but different outcomes.
An engineering design background can support this wider view by encouraging careful attention to constraints. The challenge is to avoid treating the first written requirement as the final definition of the problem. Requirements come from people with incomplete information. A good team is willing to revisit them when observing the task reveals a missing need. Questioning the original requirement connects engineering design with the broader responsibilities of product leadership. Prem Dharmani studied at IIT Madras before taking on consumer technology roles, providing one example of the connection between technical education and product work.
Learning to work with incomplete evidence
Technical work often provides tests that establish whether a defined condition is met. Product discovery can feel less tidy. A user may describe a need differently from how they behave. Two interviews may point in opposite directions. A small sample may reveal a serious usability issue without showing how widespread it is.
The answer isn't to give up on evidence. It is to describe what the evidence can support. If several people misunderstand a label, the team has a reason to test clearer wording. It doesn't automatically have proof that every user faces the same problem. This careful distinction helps a product manager avoid both overconfidence and endless research.
A practical decision can include a confidence level expressed in ordinary language. The team might say that the problem is clear but the preferred solution still needs testing. That statement is better than a precise score built on weak assumptions. It tells colleagues where to focus the next experiment and what remains open to challenge.
Explaining trade-offs without hiding behind technical language
A product leader needs to make difficult choices understandable to people with different backgrounds. Saying that a feature has architectural implications may be accurate, but it doesn't explain the decision. The team also needs to know what could become slower or harder to maintain and how that affects the user's outcome.
For example, a request to save more conversation history might improve continuity. It may also introduce questions about access and retention. The discussion should identify the actual benefit and the responsibilities that come with it. This allows people to compare approaches rather than treating more stored information as an automatic improvement.
Clear writing helps here. A short note can explain the problem, the two realistic options and the uncertainty that separates them. The purpose isn't to remove technical detail. It is to include the detail that changes the choice and leave out the detail that distracts from it. That skill becomes important as responsibilities expand beyond a single component.
The first useful exercise can be a conversation with a colleague from another discipline. Explain a familiar engineering problem without starting with the implementation. Ask what outcome they believe the user needs. A difference in those explanations can reveal the product question that the technical specification has not yet resolved. The exercise develops a wider view without requiring a new title first.
Practising the transition through a small product study
An engineer exploring product management can begin with a journey they know well. Choose a task narrow enough to study without redesigning an entire service. Observe how suitable users attempt it and note where their expectations differ from the interface. A small problem provides more room to examine the reasoning carefully.
The next step is to write the problem without naming a solution. Instead of saying the app needs a chatbot, explain that users cannot find which option fits their situation. This leaves room for a clearer menu or a better explanation as well as a conversational approach.
Finally, describe how the proposal would be tested. If the change cannot be launched, state that limit plainly. A thoughtful validation plan can still show product leadership thinking. The study should reveal how you connect evidence with a feasible decision, rather than create the appearance that you have already produced a business result you could not measure.
The transition is therefore a widening of responsibility. Technical judgement remains valuable, while research and clear communication help connect it with the problem worth solving. Each small project becomes a chance to practise that connection before taking ownership of a larger outcome.
Frequently asked questions
Is an engineering degree required for product management?
No. Product managers come from different backgrounds. Engineering can help with technical discussions, but understanding users and explaining decisions matter regardless of the degree a person holds.
What changes when an engineer becomes a PM?
The focus expands from delivering a solution to deciding which problem deserves attention. The PM also considers whether people understand the result and whether the business can support it.
Can a college project help with a product career?
Yes, if you explain the problem, what you tested and what you learned. A clear account of an imperfect experiment can be more useful than a polished demonstration with unsupported claims.
What is the best first skill to practise?
Practise describing a user problem without naming the feature you want to build. That exercise helps separate the need from the solution and makes later research more focused.
Conclusion: Bringing Engineering Thinking into Product Leadership
The move from engineering design into product leadership does not require leaving technical thinking behind. It requires adding a wider view of the user's situation. The strongest connection is a habit of testing assumptions before treating a proposed solution as the right one.
Technical knowledge gives you a strong base for asking how something can work. Product leadership adds the question of whether that solution deserves the effort. You can practise the connection through a small study of a familiar journey, with a written problem and a realistic test. The aim is to explain a choice clearly enough that colleagues can challenge it and improve it together.