Some years ago I helped found a startup whose goal was publishing and delivering books through crowdfunding — when crowdfunding wasn’t as trendy as it is today. Our team of four was made up of three journalists and one engineer. And it struck me as happy news that the engineering specs made so much sense to me. I could relate to them in a way that made me feel closer to the exact sciences, and that eventually turned me into an advocate of every data-based decision.
A few years after that startup died sadly (and actually after I helped two more startups go bankrupt) I found myself working in a big tech company, where I felt that — despite my journalistic background — I had built quite an exact sciences mindset.
That made me feel more at home, which was awesome — but not that useful. I felt that the amount of effort I put in learning to code, for example, didn’t really pay off as fastly as expected. I began to feel like I was pushing myself towards the path of a young engineer trying to get a job at the tech industry. Which would be great — if I was a young engineer trying to get a job at the tech industry. I already had a job, and it required other types of skill.
And then came the next revelation (for me; I know this is quite standard talk for PMs but that was all new for me, so take it easy).
Understanding the engineers’ mindset is useful as long as you can filter it through a product mindset.
So whenever I needed to ask an engineer something, or whenever an engineer asked me something, I started making myself the following questions:
- What is the benefit for the user?
- What is the impact on the user?
- How does this make life better or worse for the user?
- What does the user think of it?
Having given focus to that beloved entity (the user) I realized where to find the real impact of my job — and for that matter of everyone’s jobs.
But how does one filter the engineers’ mindset in order to achieve the product’s actual goals?
Well, it seems to me that this becomes easier in companies that are already driven by a product mindset.
If that’s your case, just ask yourself a lot of “whys” before moving on to the next epic or story or hot fix. Why creating that new section in the website? Why do users want it? Why will it make their life better?
But if your company is not driven by a product mindset, then you might need to head a daily battle on behalf of the user. Instead of only reminding yourself of the importance of doing things with the right purpose during weekly meetings, you’ll need to remind those around you — all the time.
Whenever an engineer presents arguments to refactor the entire code, ask them what the impact on the user will be; how many more users will come; how happier they will become; what they will lose during the time your team is not doing something else.
Whenever a new hire or strategy or roadmap change is presented, raise your user flag and ask why.
Read more on Tech plus Com.