One of the most common questions I get asked is: "what do you do?"

I've been asked this by friends, family, and even strangers. It's a fair question - what do I do all day? Technically, at the moment, I'm back in school, but I spent a good deal of time working at a few different tech companies, and I've been fortunate enough to have different roles. I've noticed some details that I think are worth sharing, and motivate the decision-making process of what role to pursue. This post is more of an observatory one rather than one where I have a strong opinion.

Table of Contents

• Big Picture
  • The Product
  • The Customers
  • The Company
• The Diagram
  • Engineering
    • Startups
  • Client-Facing Roles
  • Solution Architects/Deployed Engineering
  • Product Management
  • Relative Importance

Big Picture

The Product

The product is the thing that the company sells - what they make money off of. There are a lot of different kinds of products, but for the sake of this post, I'll be focusing on "tech" products, primarily software but the same principles apply to hardware as well.

The Customers

The customers are the people that buy the product. They're the ones that use the product and pay the company money in exchange for it.

Every customer has a unique set of problems brought about by their specific situation. Some customers may have very unique problems; perhaps one customer is a small business that needs a way to manage their inventory, while another is a large corporation that needs a way to manage their employees. Some customers may have very similar problems; perhaps two customers are both small businesses that need a way to manage their inventory.

When there is a critical mass of customers that all have similar underlying root causes to their problems, companies are able to build a product solving this particular problem. This is the elusive product-market fit. There's more to explore here, which I will at some point in the future in a subsequent post.

The Company

The company faces a challenge: it has to build a product for what its customers need. It's not necessarily the same thing as what customers say they want. The famous example is the Ford quote: "If I had asked people what they wanted, they would have said faster horses" (which may not have been said). There is still an underlying need for transportation, and the car is a solution to that problem.

This is the precursor for the dynamic that exists between the product and its customers. It's more complicated than it seems, and thus requires careful consideration and precise methodology.

Some companies follow a Jobs To Be Done framework, which is this idea explored more formally. Customers "hire" products to do various jobs, and these jobs may not be that straightforward or tied to specific jobs. There's an interesting book that I would recommend reading about it, Competing Against Luck by Clayton Christensen.

The Diagram

Here's a diagram of the different roles in a company. It's not exhaustive, but it's a good starting point. If two roles are connected, that indicates that the two work closely together and have overlap in their underlying responsibilities.

At the top is the product; at the bottom are the customers. Connecting the two are all the people that make the product.

note: this isn't necessarily true for every company; in fact, most will have subtle variations based on their needs. this is just a diagram that looked nice to me

Many internal roles that support the product and the company are missing, such as IT, HR, and recruiting. These roles are important, but are left out of the diagram to make it easier to understand the product development process.

Engineering

Of all these roles, the software engineers (SWEs), the hardware engineers (HWEs), and the data scientists (DSs) are the ones that build and maintain the product itself. Engineering does vary significantly between companies. For example, a company with a strong engineering culture may have a lot of autonomy for engineers, while a company with a weak engineering culture may have a lot of process and bureaucracy to implement changes.

Startups

Smaller companies, such as those with 10 people, may not have people with specific job titles that align to various parts of the diagram. However, to make a company work, there will be people that wear multiple hats. It's common to have engineers take on the product perspective and design elements, concentrating efforts on building a product and getting customers onboard.

Client-Facing Roles

There are a lot of roles being grouped here, each of which are quite distinct and have different goals. Marketing, for example, may be concerned with promotion characteristics of the product and what customers are actively looking for. Finance, on the other hand, may be looking at internal expenditure and determining how to cut expenditure for infrastructure.

Solution Architects/Deployed Engineering

One common role of confusion is Palantir's Forward Deployed Software Engineering role. There's a separate Software Engineering role at the company too. The difference comes to what the objective is. The Software Engineering role seeks to build or implement the features with the product, whereas the FDSE seeks to build or implement features for the client.

This extends beyond Palantir to deployed engineering or solution architects, present at many companies (I've used Palantir as an example as there's a lot of threads about what the role entails). These roles are often client-facing, working with account executives (AEs) and business development representatives (BDRs) comprising sales to figure out technical solutions and implementations to problems.

Product Management

This is the role that sits at the center of the product and the customer. They are responsible for a variety of things, chiefly that the customer's needs are being reflected in the product. Every other role has a variety of things specific to that function that they advocate for.

However, what does a product manager do on a daily basis? The answer is that it depends.

A new product being introduced may mean the product manager works more closely with the data scientists (despite the corresponding arrow missing from the diagram) to monitor important metrics. A product that is being sunset may mean the product manager works more closely with the engineering manager to ensure that the product is being maintained and that the team is being supported. A new pricing plan may mean the product manager works more closely with the finance team for projections.

Each of these requires different day-to-day knowledge, even on the same product, the same team, and the same company. At the core, they all require the product manager to be able to understand the product, the customer, and the business. That's why the PM sits in the middle of the diagram, splitting the top half into the product-focused roles and the bottom half into the customer-focused roles.

Relative Importance

It's not possible to say one role is more important than the other. Each role is crucial in its own way. Engineering is important to build a great product, but without the right brand equity from marketing, great products sometimes lose. Or perhaps the product is technically sound, but the UX for users is poor, and they don't know how to use it. Or perhaps the pricing of the product was too high, and the product never took off. Or perhaps the product was great, but the company didn't have the right sales team to sell it. The internal roles can also be key - recruiting great talent is important for all of these roles, and so is ensuring that the company is legally protected.

There are countless stories of companies that achieved success due to some significant effort that may make it tempting to lean in certain directions. Qualtrics leaned heavily on its sales teams to achieve success. Microsoft leverages the bundling of its products and effective enterprise marketing to achieve success. Apple uses its brand equity and design to achieve success. Amazon utilizes its logistics and infrastructure to achieve success. Each of these companies has a different approach, yet all remain successful.

note: The diagram SVG was generated with the use of Mermaid.