This article was written by Duncan Steblyna, VP of Product at Veriff and Tiit Paananen, VP of Engineering at Veriff.
Intro: While agility is now part of most organizations’ core capabilities, very few are true to the meaning of it. Many admire the great potential of agile, but struggle with applying some of its core principles.
One long-standing issue for innovative companies is how best to align product management and engineering; with potential issues like miscommunication, a lack of defined responsibilities and confusion over job functions, it can be common for the two departments to clash, to the detriment of users and the business on the whole.
Ahead of his appearance at Digit 2022 to speak on the topic ‘Product Management Exposed,’ Tiit Paananen, VP of Engineering, collaborated with our VP of Product, Duncan Stebylna, to sketch out the key concerns of their departments. They outline how and why product management and engineering can disagree, and suggest what changes can be made to ensure closer alignment.
During hiring interviews, one of the best questions to ask Product Management candidates is “What's the role of Product Management? What do we do?” It’s a very simple question, but it quickly puts candidates into different categories; some will abide by the dictionary definition of the role, but then there's the reality of what they think their job is.
Sometimes candidates will say it’s their job to represent customers, but that’s not exactly the case. The job is to represent the business and customers; if you don't represent customers, the business is not going to do very well. However, if a Product Manager (PM) is only representing customer concerns, then they’ll probably want to give the product away for free. That's not great for the business. The job is actually a balancing point between these two priorities.
Issues can arise from upper management. For instance, imagine you’re a CEO and you're hiring your first Product person; if your perception of Product is that the PM is just going to do whatever you say, you're hiring someone to be a Project Manager, in effect, but you're calling them a PM. This attitude then proliferates in the business, leading to candidates being interviewed by employees who don’t understand the skills and experience they’re evaluating.
In a broader sense, many roles can be poorly defined, such as what an analyst does from one organization to the next. The fuzziness of role definitions is one of the things that we're really trying to clear up at Veriff. It’s part of a transition from being a startup, where everybody does everything, to instead having defined positions.
For instance, design is misunderstood in many companies. One of the biggest complaints from Designers is that they get treated like Visual Designers, so all they do is make things look attractive. A clash can occur when a Product Manager oversteps the mark by drawing out exactly what the product will look like, and then the other person is just supposed to make it look pretty. In various companies, Designers mean different things. A lot of these things are still forming across the industry; likewise there isn't really a shared definition of exactly what a PM does.
Clearly defined role responsibilities, not only for Product, but for the other team members, are very important. If you know what your Engineering Manager (EM) does then you're going to have a much better relationship. However, we have to acknowledge that there's still a lot of overlap, and we still collaborate day-to-day, but ultimately there’s certainty on who has the final call.
The collaboration between PM and EM could be seen as a form of dyad leadership, which you’d see in the medical sector, where physicians and administrators work together to manage a group of professionals. If there is respect and trust in the specific skills PMs and EMs bring to the table, the potential team overlap can actually make the organization stronger.
Ensuring clarity around team objectives is vital. OKRs are important, but they can be used properly or improperly. The most common mistake with OKRs is that people massively overcomplicate them.
For instance, if you ask a fraud team what their objective is, their response could be that they create machine learning models to protect people from repetitive fraud attacks. However, the real objective is to stop bad actors from doing bad things. The KR is there, but how do you know whether or not a solution is actually working? How are you stopping more bad actors or less?
The clarity around the objective, what the team does, empowers your different team members. If the whole team understands that it makes it a lot easier, because then you can let people do their best work. Your EM is not only an engineer, they are also an intelligent human being, capable of thinking about topics outside of Engineering. Your PM might have a technical background and firsthand experience of situations where ignoring technical debt has led to lost client value.
When you're getting together and deciding plans for the quarter, you can share different ideas and approaches. You can then have your designer, your analyst, your user research and different team members all together, focused around one very clear, shared objective of stopping these bad actors from doing bad things. This is an aspect of team working that we commonly see not done very well.
Some of the most important skills for a good PM to have are persuasion and influence, because you don't have direct authority over your EM, you don't have direct authority over your designers or your analysts. They're all in a cross-functional team that often has some matrix discipline-based reporting lines present.
Additionally, when you're working with the sales team, or you're working with a customer, you often have to be able to persuade and influence them to know that one solution is actually a better solution than the one that they've proposed for their problem. Interpersonal skills are incredibly important for a PM.
When managing PMs, the golden rule is to manage expectations before anyone is criticized. It’s about outlining the product method, the questions you’ll ask and to encourage other people to ask those questions themselves before a meeting. There are patterns in questions when it comes to Product Management, such as “what problem does this solve?”
Collaborating with the EM is key for cross-functional teams to thrive; a clear delineation of duties in team rituals will set expectations right. There are a number of ways to outline responsibilities, including creating a Venn diagram that can be detailed with a RACI matrix.
Sometimes you think everything is clear, but it's dangerous to make assumptions like that. If you don't know what problem it is, you probably shouldn't go any further. Stop there until you understand what it is you're even trying to do. Second question, “how big is this problem?” If you can't put a size on it, then you can't you can't figure out whether or not you should spend more time working on it. The two most basic product questions will solve 80% of the problems where you end up building something ineffective or broken.
Workflow-wise, having EPICs go through the problem assessment and solution discovery phases before being selected for development will yield fewer problems down the line. It does not mean a mini waterfall happening in an agile team; it means that your engineers are involved earlier, so they as well understand the issue before deciding on the solution and execution.