Product vs Engineering

6 min readJun 22, 2023

TL;DR

Product Managers focus on “the problem” — What it is, why it exists, and why their organization is set up to resolve it.

Engineers focus on “the solution” and how it is built, with properly documented requirements.

They need to interact, but not integrate.

Overview

Many people feel that “Product” should be part of the Engineering team. Some companies put the product team under the CTO, while others line it up under the COO or even the CFO.

Product truly needs to be its own specialty, to avoid conflicts of interest within the business. My next article will be about product roles, including justification (or not) for a Chief Product Officer. For now, let’s dig into the processes and focus areas of Product and Engineering, without job titles.

What is a Product?

In today’s workplace, “product” usually means a technical application or service, but there are also Product Manager jobs in other industries, such as clothing and food. Since those frequently go by other titles, too, we’re sticking to technology, like all my other articles will be, unless clearly stated otherwise.

What is Product Management?

Here are four definitions, according to Bing (with integrated ChatGPT):

Product management is the business process of planning, developing, launching, and managing a product or service. It includes the entire lifecycle of a product, from ideation to development to go-to-market. (1).
Product management is an organizational function that guides every step of a product’s lifecycle — from development to positioning and pricing — by focusing on the product and its customers first and foremost (2).
It is a company’s organizational function that handles a product’s life cycle. This includes the development of new products as well as the planning, production, pricing, marketing and final product launch (3).
The goal of product management is to coordinate and oversee each phase of the product lifecycle. It encompasses a wide range of responsibilities, from marketing to investigative analysis (4).

Recap— it’s the effort of how the business organizes the lifecycle of a Product.

Product Lifecycle? Isn’t that the same as the Software Development Lifecycle?

No.

“Development” is the act of building something.

It’s causing something to grow.

A product’s “life” starts with a concept and definition before its ready to be built, and doesn’t end until it is removed from users.

The SDLC provides a framework for the development of software that ensures high quality and meets customer expectations. The different stages of SDLC are:
1. Planning
2. Analysis
3. Design
4. Development
5. Testing
6. Deployment
7. Maintenance

The product management lifecycle is the process of designing, creating, testing and launching a new product. It includes the following stages:

1. Idea generation
2. Planning and Design
3. Development
4. Testing and validation
5. Launch
6. Growth

Noticeably, there is overlap. Both lifecycles have planning, design, and testing. These, and other phases have touch-points for collaboration, not because Engineering does everything.

The thing to note about the definition of the SDLC is that the software should meet customer expectations.

However… ask any software engineer if they want to talk with customers, and they’ll tell you “No”, although you might hear some colorful language along with it.

They just want to build something (output).

The PM wants to make sure the right thing is built (outcome), which means talking to “the market”.

Product Management = Collaboration

There’s an old saying that Product Managers have “all of the responsibility and none of the authority.” In order to manage the product, PMs will work with the following groups, who are authorities in their area:

Company leadership regarding corporate strategy and vision.
Existing or prospective customers to identify “pain points” and problems that align with the company’s vision to solve.
Other subject matter experts to understand and validate the proper “market fit”.
Engineering and Design teams to formalize requirements and acceptance criteria.
Marketing, to get the word out that the product is (or will be) available, and why this product is unique and/or subjectively better than the competition’s version.
Existing or prospective customers to evaluate if the released product actually solves the problem(s) it’s supposed to, and if others still exist.

This is an overly simplified, and not all-inclusive list. Each item can be one or more articles by themselves.

We’ll get to those over time.

SUMMARY

To build “a thing”, the Engineering function doesn’t have to be part of the internal organization. It can be contracted out to a third party, which many companies do. The company tells the vendor what needs to be built, the Engineers build it and turn it over to the company. Their job is done at that point. That Engineering team can then move onto the next “thing”, and it doesn’t matter what’s done with it, to include overall success or failure. In essence, Engineering is a straight-line process with a beginning and end. Once something is built, even if there’s a bug fix or new feature required, that is a “new thing” with another beginning and end. Although it is being built on top of something that already exists, in theory, any Engineer can build that component without needing to understand the whole product.

Product Managment is the spine of the organization. They have work to do before, during, and after Engineering is involved. They:

Identify and understand a problem
Define the solution with desired outcomes
Work with Engineering to prioritize tasks to complete and accept what’s created.
Leverage business resources to get the product into the hands of users.
Validate with users how well the problem was solved.

It doesn’t end there, though, because the process of identifying problems and solutions is ongoing. Once it’s built, the PM wants to know if additional improvements are necessary or valuable. They do need to understand the entire product and the purpose of each feature. Changing an item not only has a ripple effect on functionality, but also the way users feel about and interact with it, which could change or strengthen their desire to use it.

BOTTOM LINE — We need both Product and Engineering to be separate, not incorporated.

Relative ADHD Superpowers

Not all Product Managers have ADHD, and not everyone with ADHD would make a good Product Manager. However, there are specific superpowers that make those of us with ADHD excellent matches for the position.

According to CHADD, employees with ADHD can be an asset in the workplace because they are curious, creative, imaginative, innovative, and inventive. They tend to be out-of-the-box thinkers. Here are some of the strengths of people with ADHD in the workplace:

Creativity: Creative problem-solving is instrumental for success at school and work.
Hyper-focus: Many people with ADHD become hyper-focused on things that interest them.
Risk tolerance: People with ADHD often have higher risk tolerance than people without the condition. (5).

Other positives of working with employees with ADHD may include:

They’re good in crises.
They’re flexible and spontaneous.
They often bring optimism to the workplace.
They work better under tight deadlines or pressure. (6).

If you’d like to discuss a Product Idea, or about ADHD in the workforce, feel free to schedule a 30-minute session with me. I love meeting new people and discussing ideas on using technology to make the world a better place.

Your Technology Product Philosopher

~ Dutch

My name is Dutch. I’m a Strategic Product Manager, a lifelong geek and military veteran who lived 50 years before being diagnosed with ADHD. My topics may vary from article to article, but feel free to subscribe and hang on for the ride!