Speaker, teacher, and coach, helping product teams improve their practice to achieve greater impact.
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.
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.
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.
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.
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.
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.
Experimentation will have two impacts in development work:
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.
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.
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 🙂
Create your free account to unlock your custom reading experience.