Over the past 10-20 years, software development approaches have undergone significant changes. What used to resemble the Wild West has now evolved into a vast ecosystem built from startups, accelerators, and venture funds. This transformation has inevitably influenced how companies structure their internal processes. Due to intense competition, the primary question for young companies has shifted from "how to build" to "what exactly to build." This has prioritized speed over high quality, emphasizing the velocity of hypothesis validation, market responsiveness, and adaptation to changes.
We observe how lean and scrum methodologies have displaced the waterfall model, focusing on addressing bottlenecks that are crucial in the new realities. However, are there other ways to optimize the process?
Typical team structure
Most modern development teams can be broadly categorized into two types:
- Conservative Teams: These teams typically consist of a few engineers led by an engineering team lead. The focus is on a more traditional hierarchy, where the team lead guides the technical aspects and decision-making.
- Cross-Functional Teams: These teams are more contemporary and are composed of a cross-functional mix. They include a product manager and a designer who are responsible for customer communication. The team is still led by an engineering team lead, and there are multiple developers working on tasks.
The choice between these models often depends on the nature of the project, the organizational culture, and the specific goals of the development effort.
However, both of these approaches share a common drawback - all feedback from a large number of stakeholders goes through the Product Manager. The feedback is somewhat processed by the Product Manager, then passed on to the team or team lead. Specifications are written, requirements are decomposed, and the task is handed over to the developer... except for the details and business context. The developer works with a task that's already prepared and doesn't directly interact with the client. If they have questions, they ask the Product Owner or team lead, and either the questions are passed on or the team lead attempts to solve them based on their own knowledge. All of this resembles an attempt to play a game of Chinese whispers.
At the end of the sprint, developers submit their task, roll it out to production, and it turns out they did something completely different. The entire process has to be initiated again. What's wrong with this approach? Each link in the team becomes a bottleneck for task progress. Due to limited capacity of team members, answering questions and passing context can take days or even weeks, significantly increasing the feedback loop for your new product features.
Is there a way to optimize this process? Certainly - by eliminating unnecessary links in the existing chain. That's how the role of a software engineer evolved into a product engineer.
Who is this product engineer of yours?
Product engineers possess a powerful combination of skills. They excel in communication, building strong relationships internally with colleagues and externally with customers. These strategic thinkers go beyond just completing tasks; they see their work as a key force driving towards a successful IPO. The most vital aspect is that product engineers deliver. They conceive, construct, and meticulously validate their work, ensuring that new features quickly reach customers.
To illustrate how the feedback process changes with the new approach, you can refer to the following diagram
So let's consider the features of a product engineer's work and how they differ from a software engineer:
Measure of success:
- Software Engineer: Success criteria often revolve around the quality of the engineering system they develop.
- Product Engineer: Focuses on solving user problems. Success is not always about the most productive code or code covering the most corner cases. It's about writing code that best addresses user problems, closes the most popular use cases, and provides the maximum possible UX for end users.
Scope of work:
- Software Engineer: Works based on ready specifications and tasks (for example in JIRA).
- Product Engineer: Concentrates on a user problem, usually described in the form of a user story.
Depth specialization:
- Software Engineer: Often has a clear specialization in frontend or backend development. For software engineers focused on technical excellence, having a specialization and deep technical expertise is vital.
- For a product engineer, it's crucial to balance speed and quality. They are often specialists without a strongly defined specialization in frontend or backend. They can contribute to any part of the product or are full-stack developers, following a T-shape or even W-shape approach.
Customer interaction:
- Software Engineer: Main sources of requirements and feedback are product owners or their immediate supervisors.
- Product Engineer: Emphasizes communication with users, involving both quantitative feedback through analytical systems and qualitative feedback through participation in customer development interviews to better understand user needs.
Development and delivery speed:
- Software Engineer: Can afford to solve technical problems that do not always directly impact end users.
- Product Engineer: Typically contributes to product development and drives shorter iterations, focused on obtaining feedback quickly from end users for their solutions.
What are the requirements for the role and how to become successful?
So, you've decided that you like this and want to try yourself in such a role. Should you just go and tell your boss about it? You can certainly try, but it doesn't always work. Transitioning to such a format usually requires changes in the overall company structure and internal processes, and not everyone is ready for such rearrangements. For larger companies with a strict and deep vertical structure, such a transition may prove more challenging than for horizontal companies or startups that are more aligned with them.
If we look at the job market, a similar correlation is evident. For example, in a LinkedIn job search, where larger companies post vacancies, a search for software engineer yields 143,146 job listings, while product engineer results in 1,773, which is only 1.2% of the total number of job listings. However, if we examine platforms where engineers are hired by younger companies, such as www.workatastartup.com, the distribution becomes much more interesting — 665 companies for product engineer compared to 686 for software engineer indicating a high demand for such specialists in young and growing companies.
Since this role involves continuous learning across adjacent tracks, the company culture should be geared towards growth and open communication among employees with different skill sets. If you are already an established technical professional, you will need to enhance your understanding in areas like product management, UX design, and analytics to identify issues in your product and propose user-effective solutions.
The next point may be a bit controversial, but I believe that to transition into the realm of product engineers, you should already be a software engineer with at least a middle+ or senior level. To address user problems, a developer must already have a well-developed technological worldview and experience to understand the pros and cons of specific solutions and make necessary trade-offs. The primary challenge in such a position should be product validation of the chosen solution, rather than writing the corresponding code.
By the way, when we talk about UX, we don't always mean the interface. It is more about how the user interacts with your product. For example, being an API-first company at Monite, 99.9% of user interactions with our product occur through the API. Therefore, we address this at the API level by adhering to industry standards, providing detailed documentation, and creating walk-through examples formatted in Postman that cover most user scenarios.
Does this bring value to the company?
Embracing a no-compromise approach, product engineering focuses on efficiently reducing communication noise. Forming small, agile teams leads to fewer meetings, rapid decision-making, and a streamlined feedback loop. By eliminating unnecessary layers of communication, product quality experiences a significant boost. When engineers have a comprehensive understanding and the authority to make decisions, the process becomes faster and more effective, preventing delays or errors.
When I discuss this topic with employers unfamiliar with such an approach, there's often a certain level of skepticism for two main reasons:
- Developers have gained a reputation as technical geeks interested only in manipulating bits, optimizing algorithms, and scaling containers.
- The approach where an employee is expected to be involved in more than one direction is often perceived as a lack of focus and a stress-inducing factor related to work.
Finally, I have a source to reference to refute these claims. In the DevOps report by Google released in 2023, there is a separate chapter dedicated to how a focus on users affects various team parameters. Among the findings, I would like to emphasize:
- Teams with a strong user focus experience a 40% higher organizational performance.
- Prioritizing user needs leads to a 20% higher job satisfaction.
- User-focused approaches significantly improve other metrics.
Wrapping-up
Fundamental changes in the industry always impact the requirements for companies, which, in turn, influence approaches to development and the internal organization of teams. So, if, in addition to development, you are interested in:
- Growing along a non-technical track
- Gaining a better understanding of the domain you work in and the existing problems within it
- More closely aligning your efforts with the successes or failures of the company
Then perhaps now is the perfect time to be at the forefront of these changes and consider embracing a new role for yourself.
If you prefer not to participate in this and feel more comfortable in the technical track, it doesn't mean you'll be left behind! Since all your teams are now focused on users and often do not pay full attention to engineering, there is a need for individuals who will address this aspect of your workflow. Therefore, roles such as architect or platform team (which I will revisit in future topics), providing a strong technological foundation for product engineers and preventing them from diverging too much, become even more crucial than before!
In my blog, I still focus on approaches to work, team building in the early stages of company development, the role of a product engineer, and establishing a data-driven culture within a company. If these topics interest you, feel free to subscribe for me and other Monite developers.
Top comments (0)