Product Developer: 6 skills that make developers shine in product teams and how to interview them

There are a lot of skills that distinguish a great developer from a good (or bad) one. But in particular, when working on digital products there are some of those that are much more important.

Inspired by Marty Cagan’s definition of Product Designer I’ve decided to talk about what I consider a Product Developer.

What does this mean? As is the case with Designers, with Developers you will have many different skill sets and (even more important) mindsets. To build successful product teams there is a particular type of Developers that shine. Those are the ones I call “Product Developers”.

Let’s see what those are and why do they set them apart.

Product Developers Characteristics

1. Customer oriented

Above everything else, the most important characteristic for this role is being customer centric. We want customer centric product teams, and this should be true for any role in the team.

From a developer perspective, this means that satisfying the customer should be above code perfection. Of course we want excellent code in our product, but if that will get in the way of satisfying the customer, it is not a route this role would be willing to take.

On the other hand, this sort of developers enjoying knowing more about the customer. When they start a new task, they want to know why they are doing it for, how would this affect the user? They enjoying receiving information from Product Managers or Product Designers on the latest user research, and even participate in usability tests or interviews.

2. Business interest

Probably similar to customer centricity, these software engineers understand that we are here to make a profitable business. This interest will be noted for example when having to do “not so interesting” or challenging parts of the product to support a business rule.

On the other hand, I evaluate how much they are committed to solving with urgency production errors that affect the business. If a bug is found and excuses are said not to tackle it immediately, it may be a symptom that they do not embrace this concept.

Similar to the first point, they are also interested in understanding the business. How do we make money? What are our results so far? They appreciate when the Product Manager shares metrics and insights on how the business is doing.

3. Outcome vs output driven

Following the first two points, the focus of this type of professionals is not on “how much code / features” are produced (output) but rather how what we are doing affected the results (outcome).

I usually appreciate when they get involved in the prioritization and scoping of what the team will do and provide their input to focus on what will give us more results with fewer efforts.

They understand that in order to see the value everything needs to be released in A/B testing (even when it takes more effort to launch it this way), and after a release, they will be eager to see the results from a KPI improvement perspective.

4. Value oriented slicing

A common problem I see between product managers and developers is how to divide big features into small portions that still add value. Many times from a development perspective is more efficient to divide for example the front end from the backend, coding in one sprint the backend and the next one the front end.

The problem with this approach is that add zero value until both sprints are done. Yes, you have a deliverable at the end on the first sprint, but no real customer value is added and no risk is reduced.

Product Developers understand that there is a need to slice the work in a way that may not be optimal for development time efficiency, but maximizes customer value and/or reduces risk.

5. Rework tolerance

Another thing that may be frustrating for some developers is the need to work twice on the same component or feature.

But when we are working on products, it is almost certain that you will refine and optimize the same part of the system many times.

A quick example that comes to mind is the search box. If you see an e-commerce or content product probably the search component is extremely important. And teams will work on optimizing it over and over. Even some large companies may have teams exclusively dedicated to a particular component.

6. Experiment tolerance

Experimentation will have two impacts in development work:

1. Related to rework, I have seen developers get extremely annoyed when something they did needs to be thrown away. When you experiment you are doing it because there is a high chance of something not working out as you expected. So you will certainly throw code away.
2. The code you do when experimenting is prototype code (which is a fancy word for ugly). Since you want to spend the least possible amount of effort until you validate if this idea will work, you should code it in the least expensive way. This is something not all developers are willing to do.

For product development, the best developers are the ones who are not only willing to do dirty code for experiments and throw it many times away but also who can think about the best strategies to implement the experiment very quickly.

How to interview for this role?

Now that we have a few characteristics that make Product Developers great, it would be awesome to be able to identify them during interviews.

There are a few questions you can add to your technical evaluations that should help you get a sense of how would your candidate fit in this criteria.

NOTE: I have created a quick reference guide if you want to save this questions for later use. You can download it here.

1. Customer oriented

• Who is the customer in the software you are currently working on?
• What problem does the software solve for them?
• Have you ever participated in Usability tests or User interviews?
• What input do you get from the UX/Design team? (you are looking for something more than “the design assets” as an answer)
• Are there different groups of users for your product? (you want to check if he talks about demographics or any other user segmentation)

2. Business interest

• What industry are you in? Who are your competitors?
• How does your company earn money?
• What are the metrics that you know and follow (or are shared by your PO or stakeholders?

3. Outcome vs output driven

• How do you measure your work?
• How do you evaluate something you build was good?
• When you start working on a feature, what information do you receive or what is important for you to know? (expect some input on how he/she gets the “why” we are building this)

4. Value oriented slicing

• You have to build a user profile tool that allows for sign up, view, modification and delete. You know it will take roughly 1.5 months. How would you plan the first 2 weeks sprint?
• What was the last time you had a feature that you couldn’t complete in a sprint and what you did about it?

5. Rework tolerance

• When was the last time you have to do the same work twice in a relatively short period of time? How did you feel about it?

6. Experiment tolerance

• Let’s say you have a new feature that will take 1 month to code. You are asked to make it in 1 week just to show it to 1% of the user base. How would you proceed in this scenario? (you are looking for things like “I would not do I18N work and launch it just in English”, or “I would not code a particular error flow and leave a 404”).
• Have you ever use code prototypes? What for?

Conclusion

Depending on the seniority you are looking for you may need to select how many of this questions you want to include in the interview.

You can download the cheatsheet with the interview questions for later use.

Most of them do not have a “right” answer. As I said in the beginning, we are trying to understand how she thinks and her mindset.

I would love to hear your thoughts and what should I add to this list 🙂

Originally published at leanexperimentation.com. If you enjoyed it and want to receive more tools & tips to improve your product, you can subscribe here and join hundreds of readers!