rw-pivorak-2018

How Can You Become More Successful as a Software Engineer? Go Product-Oriented

Do you agree that software developer’s value goes far beyond coding? For me, as for 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 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, how we can look at our problems, both from the user’s and the product’s perspective as well as how to effectively manage ideas.

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, and the remaining 50% of companies do so within five years, and 70% of companies do not reach their 10th year. Why does this happen? Besides well-known reasons like poor management, operations, and marketing due to a lack of experience, no unique value proposition in a high level of competition and etc., there is one more critically important thing: absence of the product-market need.

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

Imagine, it’s a nice evening, you have planned to watch a movie. To pick it up, you need to drive to the store, browse for the shelves by yourself. You have finally found one, brought it home and then just realized it was 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, the 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 rental and sale service with mail delivery. 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 mln users. Actually, Blockbuster evaluated the idea that Netflix brought to the table. They just thought “nobody will want that” and were completely wrong.

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 them. Solving users’ problems will increase the money flow that comes to the company, and therefore our salaries can be increased as well because eventually, we, software engineers, are the ones who create that value.

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

Who is a product engineer?

The product creation process includes three main parts.

  1. Engineering. It answers the feasibility questions: what would we need to do to build it? if we really can build it?
  2. Design. It responds to whether users will like it and what should be done for users to like it.
  3. Product management. It provides an answer about the viability: will it actually help the business?

three main parts of the product creation process

This structure engages both technical and non-technical people as well as product and tech ones. Product engineer closes the gaps between different functions and specialties. Product engineer leverages a strong technical background to translate business and user needs into either a working solution or a technical specification. Product engineer is not an additional specialist. Any role can be highly specialized (in the outer parts of the circles) or closer to the middle and understanding neighboring functions better. Moreover, it’s 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.

Product engineering approaches

People tend to overfocus on addressing urgent issues while not thinking much about the things that are really important. Concentrating on urgent, short-term priorities leads to missing points that are 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 thing. 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? Picking a user in the center helps select 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 not always the most obvious solution is the most effective one. Finding the right way to solve those problems is the second step.

Implementation plans

Usually, it is difficult to keep the 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 and then can’t explore either the problem space or the solution space because details keep slipping away. You keep recreating them and without proper understanding, you can’t provide various solution directions or variations. You stick to one solution and then you lose the chance to look into others.

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.

implementation plan product engineering approach

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

Implementation plan lets you:

  • capture your ideas and move in one direction deeply
  • see the variations or go back and see other directions
  • realize the gaps or uncertainties
  • explore variations of short-term, mid-term, and long-term solutions
  • get the sense of moving forward.

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, define questions you need to ask to get more information so that you can proceed further. Then you can actually understand 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 worse outcomes. Among other things, 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. It leads to a tech debt increase which itself is not visible for managers or stakeholders but results in team performance falling drastically. Making tech debt visible, timely communicating it is one of the ways to contribute to the product.

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

From the product perspective, there are three groups of people involved in the 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 comes to a single project in Jira. Customer feedback can be collected via Drift, UserVoice, Intercom, or any other system. It should go to the same place where we have ideas, issues, like tech debt tickets by the product team. Stakeholders can contribute to that too.

Having a single source of information is really 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 put those pieces of information to the corresponding buckets.

creating inputs and contexts

We call those entries inputs. First, we collect all the information, groom those inputs, then we form the problem space and afterward 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 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 details, and don’t forget to follow the usage metrics. Here are are some points which 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 yet: 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 by individuals. What matters is what gets done, not who did it.
  4. Technical skills are extremely important, but not enough on their own. Hard skills should be complemented with soft skills.
  5. Sharing ideas, communicating and killing the “not my job” mindset should lead the way. It doesn’t matter if you are a CEO or just a junior developer. You can generate great ideas which might 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. Roughly, every one of us has 80,000 hours in our careers. Let’s use this time wisely and build things that make people’s lives better.