Do you agree that a software developer’s value goes far beyond coding? For me as a full stack engineer, building the right things, searching for the most effective ways of discovering users’ problems and shaping solutions to make people’s lives better are crucial. Recently, I’ve shared my findings and approaches to product creation that we use at Railsware at the Pivorak conference, organized by the Lviv Ruby community.

Also, you are welcome to check out the slides at Speakerdeck.

Inspired by the feedback, I decided to share more about product development focusing on how we grow as engineers, and how we can examine our problems both from the user’s and the product’s perspective, as well as how to effectively manage ideas.

What does a product development engineer do?

Before we dive into the specifics of product-oriented engineering at Railsware, let’s have a closer look at the job description, responsibilities, and skills required of a product engineer.

Role description

Product engineers solve problems. They work with cross-functional teams to identify the solution which meets the business needs. They also make sure that the solution they offer is feasible and solves the right problem in the fastest way. Being engineers, they think through all the details of the implementation as well as different scenarios of product growth and scalability.

As more feedback and real-world data are acquired, they adapt the product and create new solutions, focusing on the business problem and efficiency of the result. This process repeats for the lifecycle of the product. Instead of just implementing the features they’ve been asked for by different stakeholders, product engineers assess the problem from different angles and deliver the solution that everyone needs.

This job is not unique to software development, you get product engineers in every industry. However, we’ll be looking at the role of product development engineer specifically as it applies to software.

Skills and responsibilities of a product engineer

• Communication – Possibly the most important attribute of a good product engineer. Bringing a new product to market involves collaboration across different teams. The engineer has to be able to understand the slang of business, marketing, sales, and analyst teams, then interpret it to other engineers. You might have the best developers in the world, but if they’re not aligned around the same problem and goals, the end product won’t be successful. Product engineers close the gap between strategic and tech teams.
• Customer-focused approach – This remains relevant throughout the entire process. As the product is developed consideration of the customer experience will be a top priority. After a product is released, feedback will be used to identify areas of improvement. Ultimately, even the most technically challenging solutions are created to solve a customer’s pain point. Without having this in mind, you risk over-engineering the solution or solving a problem that didn’t exist in real life. To help the product be desirable by the end users,, it’s essential that a product engineer is familiar with best UX practices and regularly participates in users interviewing.
• Analytical thinking – Plays a key role in shaping the product development strategy. What are all the moving parts of the solution? How do they fit together? What happens if…? What are the pros and cons? Is it a cost-effective solution? Every product engineer will have their own process, but a many-sided analysis of the problem and opportunities is the key.
• Prioritizing – Both emerging and mature products will have a huge number of things that could be improved. It’s the engineer’s job to evaluate these options. It’s a waste of resources to create a new feature that will make the system more complex and won’t solve any business problem. There will be a greater ROI by prioritizing a feature that brings value to the customers or makes the product maintenance easier.
• Out of the box thinking – Finding a novel solution that’s a viable product isn’t easy. The most successful startups are great examples of this. Great product engineers will be open to unique ideas and won’t be scared to pivot into new opportunities.
• Engineering Best Practices – Although a novel solution will occasionally be required, the majority of problems can be solved with a pre-existing solution. A good engineer will have familiarity with the best practices; enabling more efficient use of time, money, and brainpower.
• Broad knowledge base – A good product engineer will have a strong technical background and on top of that, they need to understand related areas such as design, management, and marketing to make better decisions in general. They need a breadth-focused understanding of their team’s capabilities.

Salary and career development

This can be a well-paying position. According to Indeed, the average salary of a product engineer is $89,922. In addition, an average of $4000 is awarded as an annual bonus. An entry-level product engineer will likely earn somewhere in the range of $35,000 – $65,000.

As your experience increases, the role allows good opportunities for career development; some companies offer salaries of around $125,000. A huge advantage for software-focused product engineers is that many positions will offer remote work opportunities. This gives you access to the best-paying roles worldwide.

How to become a product engineer?

There are two main approaches you can take if you decide this is the career you’d like to pursue.

Your first option is to obtain a relevant degree. According to Zippia, about 54% of product engineers hold a bachelor’s degree. Of these engineers, more than 58% studied an engineering-related topic. This is going to be the most straightforward career path as it will grant you access to jobs across several industries. Assuming you have sufficient programming knowledge you can apply for software focussed roles.

The second option assumes you’re already in an engineering or programming-related role; adopt a product-orientated approach to your work. You can grow into this position. Learn as much as you can about the approach – the rest of this article will give you insight into how we implement it.

In short, you need to shift from a task-oriented mindset to a product-focused mindset. Zoom out to see the overall picture and then zoom in into the details. Leverage your engineering brain and break business challenges down the same way that you do software applications. You want to identify what the business needs and deliver that. Apply this successfully to your projects and you’ll have relevant experience. When applying for jobs emphasize your technical knowledge base and share specific details on how your product-orientated approach improved the project.

It’s important to recognize that a product engineer is a mixture of different specialties. You need to develop an interest in the business, management, and design elements of your company’s process. Offer your help, learn about the other roles, and close the gap in cross-functional communication.

If you work for a smaller company or a startup, it’s possible you’ll grow into the role without ever applying for it specifically. The boundaries of roles tend to blur in startups. You can use this to your advantage by deciding to think and act like a product engineer. As your company develops and formalizes roles, you’ll be the clear candidate for the product engineer position.

We’ll now look at the importance of the product-orientated approach and discuss how we implement it at Railsware.

Why do companies and products fail?

A lot of companies fail. According to various studies, four out of five startups fail within the first 18 months, the remaining 50% of those companies do so within five years, and 70% of those companies do not reach their tenth year. Why does this happen? Besides well-known reasons like poor management, operations, lack of marketing experience, no unique value proposition, a high level of competition etc., there is one more critically important thing: absence of the need for the product and/or market.

Let’s recall Blockbuster, a DVD rental company from the U.S. which was founded in 1995. In 2004 it had more than 9,000 stores across the country. Now Blockbuster is no longer an operational company, with just six franchise-based stores. What is the reason?

Imagine it’s a nice evening, and you have planned to watch a movie. To pick up that movie, you need to drive to the store, then browse the shelves by yourself. You finally find one, bring it home, and then just realize it is the French version. If you are lucky enough, you watch the movie and then you have to drive to the store to give the DVD back, otherwise, high fees apply. Are you happy as a user? Obviously, not really, but you don’t have other options. It was like this until Netflix came along in 1997, offering DVD rentals and sales by mail. Users had no need to drive to the store anymore, they just had a subscription and good search options. In 2004, Blockbuster had 9,000 stores while Netflix reached almost 5 million users. Actually, Blockbuster considered the idea that Netflix brought to the table, but they just thought “nobody will want that” and were completely wrong. There was no more market need for what they offered.

There was no more market need for what they offered. Sometimes the situation is the opposite: there is no market need yet due to the lack of the infrastructure or some other conditions. In any case, thorough market research is strictly required at any stage of product development.

Why should software engineers care about product success?

Software developers write code, don’t they? Actually, no. They build products, whether they work for an outsourcing company, product studio, or their own startup. The code is just one facet of building products. Users don’t care about clean code – they have their own problems and they want them to be addressed. They pay for the value that products deliver to them. Solving users’ problems will increase the monetary flow that comes to the company, and therefore our salaries can be increased as well because eventually, we, as software engineers, are the ones who create that value.

A software engineer is just a role. Roles serve as labels to describe functions on a team, pretty much as modules gather methods in code. They help us understand what our primary set of responsibilities may be, but our main goal is to create a good, helpful product that people need.

By the way, we are hiring. Check out our job openings.

How are products created, and what is a product engineer?

The product creation process includes three main parts.

1. First, engineering: This answers feasibility questions: what would we need to do to build it? Can we really build it?
2. Second, design: Whether users will like a product, and what should be done for users to like it.
3. Third, product management: This provides answers about product viability; will it actually help the business?

This structure engages both technical and non-technical specialists.

• Product engineers close the gaps between different functions and specialties.
• Product engineers leverage their strong technical background to translate business and user needs into either a working solution or a technical specification.
• Product engineers are not additional specialists. Any role can be highly specialized (in the outer parts of the circles), or closer to the center to better understand associated functions.

Moreover, these roles are not about doing someone else’s job; it’s about moving forward as a team and helping each other. The main goal of any product-oriented role is to look for the right balance and strive for better communication.

Approaches to product engineering

People tend to overly focus on addressing urgent issues, while not thinking enough about the things that are really important. Concentrating on urgent, short-term priorities leads to missing points that become significant in the long run. We usually pick a story and jump into code, while the most effective way should be ensuring that we are building the right things. We can do this by asking a few simple questions:

1. What user problem does the story help to solve? Is it what the user needs? Choosing a user in the center helps determine the highest-value user problems. This way you see what’s important, not only what’s urgent, so you can focus on what matters. Finding the right problems is the first step.
2. What should be done to deliver the proper solution? Is there only one way to solve this problem? One task can be solved with a variety of tools and approaches. Sometimes a quick decision is critical, but the most obvious solution is not always the most effective. Finding the right way to solve those problems is the second step.

Want to work in such an environment? Apply for one of our open positions!

Implementation plans

Usually, it is difficult to keep an entire problem or solution in your head. The human brain prefers to take things one at a time. We have partial information, we figure out a way forward, but then cannot fully explore either the problem space or the solution space, because details keep slipping away. We may keep recreating these spaces, and without proper understanding, cannot provide varied solutions or variations. If we stick to one solution, we can lose the chance to look into other potential solutions.

The implementation plan approach helps to overcome this challenge. It consists of two main components:

• an issue.
• an idea.

In the premium pack, you get benefits and risks.

The main idea of this approach is to go as deeply as needed to understand different ways of solving a problem. You write what the issue is, what your ideas are, then you add issues for each idea. Each idea can have its own issues, and each of them might have own ideas of how to address them, each with possible benefits and risks.

An implementation plan lets you:

• capture your ideas and move firmly in one direction
• see variations or revisit other directions
• realize any gaps or uncertainties
• explore variations of short-term, mid-term, and long-term solutions
• get a sense of progress.

When you start working on a story, you can start writing the code right away; or, you can try to come up with a plan and immediately understand what the problems are, where the gaps that need refinement are, and define the questions you need to ask to get more information so that you can proceed further. Then, you can better understand the efforts that are needed, discuss the situation with the team and decide on the optimal solutions and next steps.

The power of inputs

Communication is king. Poor communication leads to frustration, missed chances and negative outcomes. Developers are those who can see the product from the inside and note all the inaccuracies and hiccups created when aiming to decrease the time to market, or just failing to deliver coordinated changes. This leads to an increase in tech debt, which itself is not visible for managers or stakeholders, but results in drastically reduced team performance. Making tech debt visible with timely communication is one of the ways to contribute to the product.

There are many more ways to contribute. Many things happen every day, market needs change as do user expectations, and even tech frameworks come and go. So how do you manage all that incoming information? How can we collect ideas?

From the product perspective, there are three groups of people involved in information acquisition:

• customers
• product team
• stakeholders.

To manage all the incoming feedback, we have created a single place where we put all this information, so that everything is combined in a single project in Jira. Customer feedback can be collected via Drift, UserVoice, Intercom, or any other system. Feedback should go to the same place where we store ideas and issues (such as tech debt tickets) by the product team. Stakeholders can also contribute to this.

To know more about tools and tips on product management, check this cool list of product management blogs.

Having a single source of information is crucial, but it will grow quite rapidly. That is why we divide the space into contexts, which can be structured as a tree with some sub-contexts, and organize those pieces of information into the corresponding buckets.

We call those entries inputs. First, we collect all the information (inputs), groom these inputs, then we form the problem space. Afterwards, we shape the solution space. When we figure out what we’ll be building, we move the tickets to the roadmap.

We have been using this approach for three years, and within this period we have created over 4,500 inputs.

Besides enforcing a better order to your ideas, such an approach stimulates contributions, as anyone can contribute to anything. It also works as a means of collective leadership, so we all become leaders. In this sense, we move the organization forward.

Summing up

I’m frequently asked what is needed to become a good software developer. First of all, I would advise following the customer-centric approach and getting involved in the product creation process as early as possible. Collaborate with designers on features and approaches, bring your input at every stage, learn who your users are in more detail, and don’t forget to follow the usage metrics. Here are some points that help to deliver value:

1. Product success depends on solving user problems, so products are much more than just clean code. This is why artificial intelligence will not replace humans any time soon: we have empathy.
2. Build what clients need, not just what they want. Research, analyze, think long term.
3. Products are created by teams, not individuals. What matters is what gets done, not who did it.
4. Technical skills are extremely important, but are not enough on their own. Hard skills should be complemented by soft skills.
5. Sharing ideas, communicating and killing the “not my job” mindset should lead the way. It doesn’t matter whether you are a CEO or just a junior developer. You can generate great ideas that could save thousands of dollars and it will be worth more than hundreds of hours of engineer work to implement.

Overall, we at Railsware believe in doing the right things in the right way and then improving them. Every one of us has around 80,000 hours of experience in our careers. Let’s use this time wisely and build things that make people’s lives better.