Product Management: Successfully Combining Business and Engineering

Common question to product managers, “Are you more technical or more business driven?”. I say, for a successful product manager, you should have knowledge of both. Confusing, I know but the truth is that you cannot do your job effectively without some technical knowledge.

In the daily grind of a product manager, you have a mix of research, planning, strategy, communication, and networking. Each of these has a fundamental purpose to moving products, features and services to market. It should go without saying that all product managers understand the product/service, how it functions and how users perceive it. You should also have some good business process in learning and preparing for market.

The business process consists of (not limited to):

• Understanding the target market
• Defining target segments (personas, etc)
• Understanding competitors
• Product Marketing Support (Pricing, problem oriented features, documentation, etc)
• Profit and loss for product line team (what is your budget and expected return)
• Understanding how your organization works
• Defining legal requirements (regulatory, contracts, terms/conditions, data rights, etc)
• User experience design
• Success metrics and business reporting
• Information feedback loops (customer interviews, current features, beta testing, partnership integrations, etc)

So, let us assume you know there is a market for some widget. You have a plan for who, what and where. All of the preliminary research is done and you have business approval to take a team and build your product. What is next? What are the engineering process requirements for building the product successfully?

The engineering process consists of (not limited to):

• Team structure (backend engineers, lead, UI, UX, analyst)
• Dissemination of purpose/idea (why are we building it, who is it for, etc)
• Functional / non-functional requirements (more the non-functional but some, more technical PMs will do both)
• Visual design
• User acceptance testing (UAT)
• Agile process for development (Scrum, Kanban, Waterfall)
• Product / development team building (know your dev team, their personalities and capabilitites)
• Understand how the product functions/will function technically
• Learn the lingo and research the technologies being employed (will save you lots of stress later if you know the potential issues before you start)

As you can tell, there are lots of responsibilities on both sides. You are the bridge. You are expected to know the product inside and out. If you have to ask engineering for common questions, you cannot be expected to provide strategic direction.

You are the bridge. You are expected to know the product inside and out.

Think of it like a car. You know there is a speedometer, a turn signal and a stick shift but you dont have to know how it all works, the general market only wants to know the details that those features are included. Yet, you could have a different market (mechanics) that really cares what kind of engine and transmission is in the car. It is why FORD truck commercials focus on stating the engine specs but a Kia commercial would focus on the design and drivability. Perception is key.

Roadmaps, timing, expectations. All of these rely on a stead combination of business and technical know-how. I use my engineers heavily in the business process. Giving them insight into the market and knowing their thoughts is really important to launching a successful product/feature. When they know the who and the why, you get better communication and technical design from them. From a technical perspective, learn what you can and leverage that information as frequently as possible.