Disclaimer: This article is based on my experiences working in the Software Industry, more specifically SaaS Companies. And while it might also be true for a majority of other industries, I will only address the Software Engineering aspects of it in this article.
Since I started working in the Software industry back in 2003, I have been working with development in many different ways, from being in teams that had no idea why they were building the things they did, to teams that were strongly empowered to take ownership of the features they built, and highly encouraged to ask questions. The latter is what I want to focus on in the article.
Closing the knowledge gap between tech & product
So why is it important to have product-minded engineers? and how can you foster a culture of curious engineers that are embedded into the what and why of your product.
It’s about closing the knowledge gap between, tech, product, and design. Having a strong product manager is absolutely key to empowering your team of engineers, but you also need to hire and nurture your engineers correctly, sharing the why, with them regularly – making it compelling for them to invest more time in the product.
One way of doing this is to show them the ways users interact with your product, ask them to sit by in user interviews, share quantitative user data & refined tracking metrics, have them see and feel what the users experience.
It usually triggers some ‘aha’ moments, when engineers see that the majority of users don’t use the navigations how it was intended or that they completely miss the big green button that if clicked would have saved them 3-4 additional clicks to arrive at the desired place in the product.
Time & Focus
Another important aspect is time and focus. Make sure to give your teams the ability to do discovery and research, don’t set hard deadlines unless it’s absolutely necessary. Things take time, and by investing time upfront on these things, you end up with a more thought-through, robust product.
I’m purposefully skipping easy over some really big changes by mentioning discovery and research, but for this article to not blow up into a 62 page one, I’ll instead link to other sites where you can read more about it.
What will change with this
So, what is the outcome of having product-minded engineers?
You close the gap between design, product, and engineering, making it easier to make the right decisions.
The end result is no longer only the brainchild of a PM and some stakeholders.
It’s been discussed, tested, broken up, validated with both engineers, designers, and product people in your team.
Often when you empower engineers to see the bigger picture and take part in adding to the overall product/feature, you end up getting new ideas and solutions that otherwise might not have been considered.
I will also strongly encourage companies to allow for 10/20% time for their engineers.
At some of the places I worked, many of the 20% time side projects worked on by engineers, ended up becoming core company products, taking Trustpilot’s widgets, bringing in billions of impressions monthly.
This started as a 20% project back in 2013 by a few engineers and grew to be a common sight on thousands of websites a few years after.
What can you do?
If you’re an engineer, you should start by asking a lot of questions to your PM, why are we building this, what’s the purpose. which users are benefitting from this, are we covering a need, based on our user data? If you are using product metrics, tracking data – ask your PM to share these data with you, so you can browse around it and learn more about how users use your product.
As an Engineering leader, you need to make sure your developers understand the importance of this, and they have time to get more into the product aspect of things. You should also make sure you get the necessary support from stakeholders to free up time for your engineers to focus on acquiring the knowledge.
if you already have empowered teams, and are running dual-track agile with Product Discovery it will be a lot easier to get product-minded engineers, as they are exposed to users and frequent testing much more.
As a PM, you have to first understand that your job is not to be a Product Owner, if you spend the majority of your time creating backlog items, grooming, prioritizing, and coordinating with the team and stakeholders you are effectively a Product Owner.
You need to be a Product Manager first and foremost.
As a Product Manager, you need to make sure your engineers are attending the user interviews, actively contributing to business canvas, opportunity canvas sessions, not being afraid to voice their concerns or ask questions, even tho the answers might be obvious to you.
At C-level, it’s your responsibility to set the stage for teams to take ownership of the problems or challenges within the company, you point them in the right direction and set out a high-level problem that they need to solve. Usually, this is done using OKR’s, but is can also happen through a high-level roadmap, not to confuse with a detailed, time-bound feature roadmap, we don’t want to kill creativity and innovation by telling our teams what to build and how much time they have to build it, if you run your company like this, you’ll likely never experience the full success or potential your product has.
You also need to ensure your teams have the right tools to do the job, it takes a lot of time and investment to transition into an empowered teams structure using product discovery as it’s intended.
Last but not least, as a CPO/CTO, it’s you who has to fight for your teams and pave the way for them to get the time and focus to develop a better product mindset.