When we talk about the topic of recruiting with our colleagues in other startups, the question of the candidate’s “product thinking” often comes up, as opposed to “outsourcing thinking”. Its absence is often a blocker for hiring, since the candidate has good hard skills.
So, what does product thinking mean? Is it really important when hiring engineers for a startup? Can it be taught? That’s what we’ll talk about today.
Let’s start with a definition: what is product mindset?
We think it’s simple.
When we talk about product thinking, we mean that the developer is interested not only in the problem itself, but also in the context around it. Why are we doing what we’re doing? What user problem are we trying to solve?
As opposed to the “outsourcing model”, where you’re only interested in whether the customer accepted the work and maybe how many hours it cost them. Why we do what we do and how good our solution is is often impossible to understand in principle, so it’s easier not to try.
Okay, we’ve figured that out. Why is it important and is it important at all?
The biggest complaint we hear from other product companies is a developer, who is not interested in the product and users, but wants to “just close tasks from JIRA”.
So what’s the problem, you ask. A developer is paid money to write code, right? If you really want to dive into the user’s problem, a business analyst or PM or someone else can do it, they are paid for it.
A typical outsourcing answer, we’d say. 🙂
The problem is that 1) product development is a super-complex, creative task and 2) the role of the developer is key in it. And if you “switch off your brain” in this key place and do only what is written in the technical specifications or what the PM thought, then the result will suffer.
And the result will not be 30% worse. The result will be 10 or 100 times worse. For a startup, this is often the difference between a successful product and bankruptcy.
Any product is thousands of “micro-decisions” and trade-offs that developers make every day, without even thinking about their importance and without discussing them with anyone.
If a developer does not think about the product and users, the team can spend six months developing a useless feature that could have been rejected in a week.
If a developer does not think about the product and users, the PM becomes a bottleneck for the development of the project, who is tasked with finding hypotheses for growth. This is bad and does not scale.
If a developer doesn’t think about the product and users, the team has little chance of creative (read – “cheap”) solutions to the user’s problem, because they are usually impossible to see from a distance, without having the full context of the task.
OK OK, product thinking is super important. Can you learn it?
Of course!
Moreover, we are sure that any developer has product thinking a priori, because this is how we think if we work on our pet project or hobby.
Another thing is that years of working in outsourcing could easily atrophy it, especially if there was no motivation and / or opportunity to apply it in the context of the project. And for trying to apply it, they were also actively “hit on the head“. Here, anyone at some point will wave their hand and say “until there is a task in JIRA, I do nothing.”
It seems to me that product thinking is essentially empathy for the user. The better we get to know our user, the more difficult it is to perceive his problems abstractly. We are social creatures, we care what others think about us.
This is how positive feedback is built: the better we understand the user and their problems, the better we can solve them and the more we value positive feedback from the user when we show them our solution.
Once you feel this buzz, it will be hard for you to “jump off” the product needle, we promise.
