How Engineers Should Think About Products

Why a product perspective matters for engineers

In a recent interview, someone asked what they should do to grow as an engineer. Go deeper into programming languages? Get better at algorithms? Study computer science, cloud operations, or machine learning engineering? None is a clear, universal answer. Software development is too broad and varied to fit neatly into the single word “engineer.”

The question led me to think about what engineers should develop when their work involves building and operating services. There is still no single ultimate answer, but I would like to explore what thinking deeply about products can mean for an engineer's growth.

What makes a good PM or PO?

People Who Should Not Become PMs or POs

An article titled “People Who Should Not Become PMs or POs” recently circulated widely in the community. It uses counterexamples to define the perspectives and skills a PM or PO needs. Its section headings are:

1. Someone who does not understand why the work is being done
2. Someone without a concept of deadlines or minimum specifications
3. Someone who cannot see the big picture
4. Someone who cannot set priorities
5. Someone who only sees what is on the surface
6. Someone who cannot ask questions
7. Someone who cannot recognize problems
8. Someone who cannot withstand pressure
9. Someone who does not see things through
10. Someone who cannot recognize failure

Put positively, this describes someone who understands the purpose and reasons behind the work in its broader context, sets priorities through communication, defines detailed specifications and schedules for each stage, and gives their best until the work is finished. Are these qualities only necessary for PMs and POs?

What makes a good engineer?

Barry Boehm, author of Software Engineering Economics, ranks the following factors in order of importance when evaluating engineers.

1. The ability to analyze a problem and decide how to solve it
2. Raw programming ability
3. Experience analyzing and solving problems
4. Experience and knowledge of the environment in which the software runs, including the OS or application domain
5. Experience and knowledge of a specific language

As the order suggests, knowledge and experience in a particular language come last. A strong engineer can learn a new language quickly, while application-domain expertise and experience are harder to acquire. What matters more is the ability to define, analyze, and solve problems, grounded in experience doing so in a particular domain.

To borrow a phrase I like, craftsmanship has never defeated the logic of economics. With that in mind, let's consider why product understanding matters from an economic perspective.

• Better product understanding improves your ability to analyze and solve problems.
• Better problem-solving ability leads to better evaluations.
• Better evaluations increase your market value—or so we hope.

Easy, right?

Understanding the product

So what should we actually do? We may already feel that we understand the product we are building. Taking inspiration from the PM/PO quality of asking good questions, let's ask a few.

The product perspective

• What is the purpose of this product or feature?
• How many people will use it, and how often?
• What happens if something goes wrong?

The user perspective

• Who will use it, when, and why?
• What does the user do immediately before and after using this feature?
• Are there exceptional cases during use? If so, how should it behave?

The business perspective

• What role does this product play in our business?
• How does it affect users, revenue, and profit?
• What risks arise if the feature succeeds or fails?

Can you answer these questions easily? Many good engineers may already have internalized them and be able to answer immediately. Still, there is a gap between “I can answer” and “I have answered.” Being able to respond on the spot matters, but so does asking and answering these questions yourself before development begins.

You might have a few questions in response.

Q. If people above us have already considered all of this, why should engineers think it through again?

A. You may bring a different perspective to the problem. You should also verify whether the requirements you receive are well formed. As I mentioned earlier, analyzing problems and finding good solutions can increase your market value—or so we hope. And first of all, let go of the idea of “above us.”

Q. Isn't thinking from the user's perspective the PM's job?

A. Engineers are a product's first users. Looking at it from the user's perspective inevitably reveals things that were overlooked. If you are asked to build a login screen and the requirements do not explicitly mention hiding the password, that is no reason to display it in plain sight.

Q. We build features for users. Why should we think about revenue?!

A. Everything is connected. Money is like air for a company, and earning a profit cannot be separated from business goals. Even nonprofits need income to sustain their operations. This does not mean you should build solely for money or profit. It means understanding what your work means for the business so that you can prioritize appropriately and analyze and solve problems better.

What roles do Buzzvil's products play?

What does it take to swim well? Swimmers have broad shoulders and highly developed shoulder muscles. Clearly, arm movements have a major effect on speed. But good arm movements alone will not make you fast. If the arm stroke represents the amplitude of a periodic function, kicking shifts it along the y-axis: your kicks provide steady speed. All of these movements depend on basic fitness and core strength. You need a foundation to improve. I am no swimming expert, so please take this loosely as a metaphor.

Thinking about the roles played by our company's product portfolio and the features we develop can clarify our understanding of the business and the meaning of those products and features. The role of each Buzzvil product is a good topic for internal discussion; I will leave that discussion out of this article.

How do our products contribute to Buzzvil's growth?

There is a concept in service scalability called the Scale Cube. In theory, it enables unlimited scaling by combining three axes: the X-axis, which scales horizontally through replication; the Y-axis, which separates functionality; and the Z-axis, which partitions similar things into groups.

The idea applies to more situations than you might expect, beyond technical scalability. Consider it from a service perspective. We can pursue X-axis growth by replicating the success we have already achieved, Z-axis growth by increasing our capabilities and efficiency, and Y-axis growth by offering independent capabilities from our system as separate services.

Closing thoughts

When I was in a photography club at university, a surprising number of friends became absorbed in cameras rather than photographs. They cared about camera performance and immersed themselves in operating techniques. A good camera and good technique are important ingredients in taking a good photograph. But without thinking deeply about photography itself, might we eventually lose our way?

I hope this article helps, even a little, as we think about what we do as engineers, why we do it, and how. Keep going, fellow engineers 👍