.jpg)
Image Used by Permission from Photo by Joshua Coleman on Unsplash
Building product team alignment is critical for success. One of the most damaging situations is when the product manager and the engineers are not aligned. Below is the AKF checklist for product and engineering alignment. We encourage teams to use these eleven questions to kickstart a discussion on the mindset of the team and the ways of working. Feel free to score yourselves to help identify the areas where the team feels it needs to make more progress.
Question number 1: Can the team articulate the company vision and strategy and how their current work fits into the big picture?
It is critical teams work towards a clear product vision. This paints a picture of what you are trying to achieve and should be inspirational, emotional and look beyond three years. Knowing the vision - your ultimate destination - helps the team set the strategy which outlines the steps required to reach your vision
The major reason for the lack of alignment is that the vision and strategy are not well understood, too much work is done outside the strategic priorities (so the team has mixed signals) or that the strategy is not a not strategy at all. A real strategy involves a clear set of steps that define what the firm is going to do and what it’s not going to do. These steps become your strategic pillars for product prioritisation and almost all the work done by the team falls under these strategic priorities. And finally this should be wrapped in a compelling, short narrative that everybody understands. And a narrative that the product team lives and breathes. We urge teams to make sure their product strategy is very clear on how it will change the trajectory of the business. Every engineer, every PM, every designer can see how they are adding value.
Question 2: Is there a clear understanding of what success looks like and shared performance metrics?
Where there is a lack of vision and strategy, there is often a lack of shared metrics and OKRs. And unfortunately the presence of a strategy does not always result in shared metrics. And there are some organisations where the product and/or engineering teams say they cannot be held accountable for business metrics or they argue that their projects do not need to be measurable at all. This is common in teams undertaking a long project project that lasts 12 months or more.
A very recent trend is a growing division between product and engineering around devops metrics. Engineering teams are increasingly adopting metrics such as lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage. These are incredibly useful and should be measured. But these measures cannot replace shared business metrics for the product team as a whole or be used to push the responsibility of business performance onto the product manager alone.
Question 3: Is the product strategy and the tech strategy seen as the same strategy?
If yes - great. Work on tech debt, maintenance etc are all understood in the organisation and regarded as part of the bigger plan. But if the answer is no, you likely have a problem. By looking at the tech strategy and product strategy together, you will have a joined-up plan that clearly shows the business value of all the team’s work.
Question 4: Does the team spend the appropriate amount of time on problems together from the very start to the very end?
There are two common problems we often see here. Firstly, teams say they do agile development but really have a waterfall process where product managers and designers start the process and then hand it off to the engineers. There are many things wrong with this picture but one obvious result is that you rarely get alignment.
The second problem is when everybody tries to do everything. It is possible for teams to take discovery too far, for example where every member of the team is expected to spend the majority of their time listening to users. Engineers should be involved in user research but we have come across developers who sit in quiet resentment as time spent on software development becomes severely restricted.
Question 5: Are ideas encouraged and accepted from everywhere in the organisation?
If ideas come just from stakeholders, engineers often don't know why they are working on a problem. It is no different if the ideas come solely from the PM. Everybody in the product team should be part of the ideation process.
Question 6: Are you validating your ideas quickly enough?
This becomes a source of tension between product and engineering when teams go down the rabbit hole of constantly adding new features and functionality. There is a default to use code to answer every question or address every problem. Adding new features can be quite addictive. Aligned product teams want feedback as soon as possible. It is well known that teams can fall in love with their ideas within two weeks so it is a good discipline to validate in front of real users at least every fortnight. And this does not always require code.
Question 7: Do you hold each other to account?
This a cornerstone when building alignment. In the weakest teams, there is no accountability. In mediocre teams, often the PM or the engineering lead is the only source of accountability. In high performance teams, peers manage the vast majority of performance problems with one another
Question 8: Do you trust each other to do a great job?
To instill trust, a team must:
- Stay in touch on the issues and concerns of each other
- Generate cooperation between others
- Resolve conflict
- Give honest feedback in a helpful way
But this is not enough. Another factor in whether people trust each other is the extent to which the team members are well-informed and knowledgeable. This means everybody’s role is clear and everybody brings specialist expertise. As a result high-trust teams use good judgement when making decisions and they tvalue each other’s ideas and opinions
Question 9: Do you communicate enough?
Communication is probably more important today than ever before due to the huge rise in remote working. Most teams have regular communication channels through various agile rituals, such as stand-ups, and documentation (which should be shared early and often). But communication is not a tick box exercise, it is about building shared knowledge, the cornerstone of effective collaboration. It gives a product team a frame of reference, allows the group to interpret situations correctly, and greatly increases a team’s impact. Effective communication is also about being clear and direct.
How product teams communicate to people in the broader organisation is also important. Ask yourself, does the team present together whenever possible? It is important for a team to be seen as a team. Too often business presentations are left to the product manager or engineers only ever present to other engineers.
Question 10: Is responsibility shared equally when things go right and go wrong?
In some firms, the PM gets all the praise when it goes right and the engineers get the blame when there are delays or implementation issues. Or vice versa, the PM gets the blame for delays and the engineers are congratulated when something is delivered on time. One of the important pieces of glue in a team is the feeling that you are all ‘in this together’.
We would urge any member of a product team to be generous with sharing the praise but also not shy away from stepping forward when things go wrong. If the team dynamics are working brilliantly, you know the team has got your back.
Question 11: Are you being bold enough?
This is probably one of the least obvious causes of misalignment. Teams, over time, can default to what is known or what is safe. Unfortunately we have met teams where engineers don’t want to take risks, designers urge caution due to brand integrity or where product managers have become hooked on optimisation and the team is caught in a cycle of ever diminishing returns.
When it comes to being courageous, everybody on the team has to have this attribute. One fearful person can prevent the whole team from being bold enough. Therefore a team should adopt courage as a team principle - because team courage is the sum total of individual courage.