Developing High Performing Teams: How To Transform a Software Developer Into a Product Engineer

Problem

One of the problems I frequently encountered is that the business side of the company makes in advance very detailed plans on how to structure product roadmap, which product to build, and how to build it. Volumes of analysis are made even before talking to clients, but the reality often unfolds quite differently than forecasted. After the initial discussion with clients and the first efforts to build a product, every so often you realize that you are unable to attain your plans as you come across real-world frictions that you couldn’t anticipate.

At the same time, the level of detail of a plan in many instances goes down to the level of a product team affecting the autonomy of the team itself. While everything is well structured, a little or no freedom is left to change things during the solution definition or execution. Commitments towards investors, customers, or internal stakeholders have already been made and engineers can only blindly follow the direction that was set in advance. Both the process and methodology that were set years ago to reduce uncertainty and tighten control resemble a supply chain with strict roles and strict production processes that undermine attempts to grab opportunities or calculate delays.

As a result, engineers are interested only in technical aspects of things, unconcerned about Why and refrained from being proactive and solving customer problems. Results are measured at a very high level, making it impossible to run product iterations based on usages and customer insights. Consequently, frictions are frequent between a PM and engineers over deadlines and commitment. Therefore, engineers are merely software developers uninvolved in the product side of things.

Actions taken

The first thing a PM (or a business analyst) should do is to explain the context -- the reasons behind the decision to do something in a certain way. This explanation could arrive from analyzing business context or market-specific target segment for example but should be presented as a problem that should be collaboratively solved. Clear objectives should be set at every level and should be defined cross-functionally (versus vertically) and rooted in a customer-first viewpoint. This will reveal Why that is behind of What is being done.

You should be concerned with the outcome, not outputs. How many features will be released in the next quarter is nearly not important as if the outcome is achieved and properly measured, whether on a macro or micro level. If we are able to translate every single Jira ticket into the outcome and establish how to measure that outcome, we will give the team a sense of purpose.

This approach will inevitably require cross-functional team meetings at any stage of the process. While there should always be someone responsible, everyone is the owner of the product at any stage. of the process. The ownership is co-shared by every single person involved and that is pushing engineers to take on product decisions, include challenging the existing product decisions. There are many benefits to this approach. Engineers will be able to attain the same objective by choosing a faster route, become more involved and thus advocate for their solution(s) and be proactive in front of stakeholders and the other team members co-owning the responsibility on the product (from identifying opportunities, finding the right solution, delivering it in the right way and measuring the outcome).

Lessons learned

• People would be able to use resources more efficiently. If you transform your engineers into product engineers you won’t need to micromanage or micro-lead them -- no need for product owners to constantly check on the backlog and check if everything is prioritized. Instead, more time could be spent on specifying the problem and the metrics to measure the outcome.
• PMs and EMs could finally focus on more value-added tasks, for example identifying the right product to build or the right problem to tackle instead of asking engineers to estimate every single task, log every single hour because they are afraid that they are spending time on off-target issues. If everyone is aligned and motivated the whole team is moving forward without the necessity of being pushed.