Evolving from Software Engineer to Product Engineer

For almost ten years, I have been building mobile applications. App architecture, platform behavior, API integration, performance, and the user experience on a phone, these were the main things I was doing day-to-day.

During that time, I occasionally worked with backend services, web development and system analysis. Those tasks were usually outside my main responsibility so I learned only what was needed to finish the feature in front of me.

This was close to the usual T-shaped model. I had depth in mobile development and some knowledge of adjacent areas but mobile was still clearly the center of my work.

Recently, I have started to think about this differently. AI makes it much easier to go beyond the boundaries of one specialization and I think this is changing what we expect from a software engineer.

Why mobile knowledge alone is not always enough

A mobile app is only one part of a larger system. It depends on APIs, authentication, databases, business rules, external integrations and the processes behind all of them.

As a mobile developer, I can build a screen from a design and connect it to an existing API. But that is not always enough to understand whether the feature will work as intended for the user.

For example, an API contract may look simple from the app side while the backend has to combine data from several systems. A small change in a mobile flow may affect support tools or a business process that is not visible in the app at all.

This is where broader knowledge becomes useful. I do not need to be the person who owns every part of the system but I need enough context to ask the right questions and understand the trade-offs.

Moving toward a product engineer role

I use the term product engineer to describe an engineer who can take responsibility for a feature beyond a single technical layer. This is not someone who is equally good at mobile, backend, web, infrastructure, system analysis and product management.

That expectation would be unrealistic. The idea is to keep deep expertise in one area while understanding enough of the surrounding system to help deliver a result end to end.

For a mobile developer, that means gradually learning more about:

• how a business process works before it becomes an app flow;
• how a feature should behave including errors and edge cases;
• how APIs, authorization, databases and integrations work;
• how web clients fit into the same user journey;
• how changes are delivered, monitored and supported after release on both front and end sides.

This does not mean that a mobile developer should replace every specialist on the team. It means that every specialist can understand the full path of a feature instead of treating everything outside the platform as a black box.

Garbage In, Garbage Out

AI makes this broader role more realistic, but it also makes one old rule even more important: Garbage In, Garbage Out. If the input is unclear, incomplete or based on the wrong assumptions, AI can produce a wrong result very quickly.

We can ask an LLM to create an API, write a database migration, generate tests or explain an unfamiliar codebase. But it cannot decide whether our requirements are correct or whether we have missed an important business rule.

If we do not understand the system and the expected behavior, we cannot provide useful context. In that case, AI is not solving the problem. It is only making implementation faster.

The important part is not simply generating more code. The important part is defining the problem clearly enough that both a teammate and an AI tool can work with it.

System analysis is where documentation helps

The more systems are involved in a feature, the less realistic it is to keep everything in your head. At some point, memory becomes an unreliable source of truth.

We need to know which services are involved, where data comes from, what happens when another system is unavailable and which rules apply to a specific user flow. Without this context, even a small change can have unexpected consequences.

This is where documentation becomes useful. It should describe the expected behavior, the affected systems, the important data and the cases that need special handling.

LLMs can help prepare this documentation. They can create a draft from existing materials, summarize an API contract, describe a change or suggest edge cases that are easy to forget.

However, generated documentation still needs review. If the source information is outdated or incomplete, the document will be outdated or incomplete too.

For me, a useful habit is to describe a change before implementation. I want to write down what is changing, why it is changing, what should happen in normal and error scenarios and which systems are affected.

This gives the team a clearer starting point. It also gives AI much better input when I ask it to help with implementation.

Learning enough backend to make better mobile decisions

I do not plan to become a backend expert. There are engineers who have much deeper knowledge of backend architecture, databases, security and infrastructure than I do.

Still, I want to understand the basics well enough to build a small service myself. That includes API design, authentication and authorization, database access, error handling, integrations and the way API contracts change over time.

This knowledge changes how I look at mobile work. Instead of seeing an API as something that simply needs to be called from the app, I can better understand why it has certain constraints and what needs to change on both sides.

AI is useful here because it reduces the cost of experimentation. I can create a small backend project, explore a framework, generate tests and ask questions about unfamiliar code without being blocked at the first step.

This does not remove the need to learn the fundamentals. An AI-generated service may work locally while still having unsafe authorization, poor error handling or a data model that will become painful to maintain.

Why web development also matters

Web development is another area I want to understand better. A product often has more than one client, even when the mobile app is the main user-facing application.

There may be an internal web tool, an admin interface, a support dashboard or a web version of the same feature. A user journey can also start on the web and continue in the mobile app.

I do not need to know every frontend framework. But I want to be able to read a web project, understand the basic structure and make a small change when it helps to validate or deliver a feature.

Sometimes a simple web interface is enough to test an idea before investing in a complete mobile flow. In other cases, understanding the web client helps explain why the same API needs different behavior or data for different users.

What AI changes in mobile development

Mobile expertise is still important. Platform behavior, performance, application lifecycle, accessibility, unreliable networks and offline scenarios are not details that disappear because an LLM can generate code.

What is changing is the amount of routine code we need to write manually. AI can help with boilerplate, simple refactoring, tests, debugging, documentation drafts and exploring unfamiliar parts of a codebase.

This gives us more room to work on the parts that require judgment. We can spend more time understanding the user flow, checking assumptions, reviewing architecture and validating that the feature actually solves the intended problem.

What I want to try next

For me, the next step is not to become an expert in every part of development. It is to take more features, bigger features beyond the mobile client.

That can mean writing a small API or chaning an old one, creating a basic web interface, documenting a business flow or following a feature from the initial request to its behavior after release. Each of these tasks gives me more context for my main work in mobile development.

This approach is useful when you want to understand how your work fits into the product as a whole. It does not replace deep specialization but it makes that specialization more valuable.

AI is making this shift easier. The real challenge is learning enough about the product and the system to give AI the right contex and to know when its output is wrong.