Product Trio Challenges - Part 1
We are product managers but our challenges for the rest of the team are not exactly known. Let me explain. Depending on the type of organization you operate in, you ’d have to adapt accordingly. Engineer(s) are required for discovery. However, you might encounter resistance from their end. Don’t get me wrong! (I was an engineer once and so I do empathize with the same). In part 1, here are some ways to try to solve for that resistance.
Have you heard things like this from your engineers?
“The product team wanted”XYZ” requirements and that is not completely possible”. The situation gets escalated more than it should be!
“As an engineer, why should I be part of any meeting with any non-technical staskeholder?”
“The product team is responsible for requirements and so unless they come up with the perfect requirements, we will not be able to start!”
Few ways to solve this -
Engagement from engineering in discovery
I believe that unless we bring value to the customer, we will not have the product outcomes we want. If we don’t have the product outcomes, then you will not have the business outcomes either. So, as part of discovery, if you understand what the customer is expecting and determine what is feasible then you for sure would have relayed the value they want.
If you follow agile methodology then use maybe 10 minutes of the same to update the team is what is happening in the discovery world. And then ask if this is possible technically or if there are technical challenges. I have found this to be effective (although initially there was backlash).
Speaking their language
Since we have teams spread across the world, use the tools at your disposal. Sometimes for them to understand new concepts, you might have to display the same thing in multiple ways until it clicks. Visually, you also have templates regardless of the tools you use (like MIRO, Figma and so on). This will help them understand even the “hidden” requirements that may exist. For example, there might be a big technical requirement, which is not obvious to the non-technical PMs and stakeholders. That is another reason why engineer(s) should be engaged in discovery.
Remove the fear of delivery dates
I wish that there was a word for this! LOL. During discovery, we iterate on customer’s ideas and they are NOT set in stone. So it is important for us to communicate that their input will be taken into consideration and we will make decisions after that.
Final Thoughts
Unless we engage all the parties involved, we will never be able to successfully deliver a product to the customer. Engineering is one of the key areas and we for sure need their input to come with feasibility and realistic dates (We will talk about that another time)!