A Product Manager is the visionary who leads a product and is often held accountable for the product’s success or failure. In many Agile organizations, the Product Manager is also a Product Owner. Product Managers usually have KPIs based on deliveries and revenue or sales generated from their product. In normal circumstances, a Product Manager is doing marketing and sales planning, customer interviews (with UXD), managing their product portfolios, writing requirements and user stories, meeting with business leaders, presenting roadmaps, projecting revenues for this and the next fiscal year, and working with development teams.
It’s clear the Product Manager is a busy busy person who has little to no spare time in their day. When it comes to time budgeting, what often suffers first is direct communications with the development teams.
When Agile came on the scene, the requirements that were once written upfront become stories that are told just before implementation. The Product Manager, now Product Owner, needs to spend more time directly collaborating with the development team, especially during implementation. This is where communications tends to break down.
In VersionOne’s 7th Annual State of Agile 2012 Development Survey,
“communication between Dev/Product Owner”
is the third most frequent cause of agile project failures. In recent State of Agile reports, communications problems are consistently in the top ten causes of agile project failure. (See reports for 2013, 2014, 2015).
In talking with different Agile teams, I hear developers consistently mention the Product Owner and requirements as a problem. Developers would like to see the Product Owner write detailed requirement specifications. In a twist of irony, they would like these details written up as a user story.
Product Owners say they are frustrated at the apparent slow pace of development. They mention that developers seem to be ‘always’ interrupting them for clarification of requirements and are asking technical questions.
When I ask developers who writes user stories the answer is almost always the Product Owner. If I ask Product Owners who writes user stories they say themselves. This shows people having a strong attachment to traditional roles and job descriptions. It also implies a cultural impediment to Product Owner-Development collaboration. If I ask either Development or the Product Owner if they should talk with each other, the answer is yes but with a caveat: they each say the other should come to them.
There’s plenty of literature that speaks on how Agile user stories are developed. Roman Pichler writes that user stories are the result of collaboration. Atlassian suggests the full product team collectively decide the more detailed requirements. Mike Cohn says that the writing user stories is less important than discussing them.
By mentoring and training, the Agile Coach can convey both the reasons for and the expected results of better communications around user stories & requirements. However, this brute force method has taken me a year in some cases and even then, only with the strongest top down management support.
I’ve helped organize user story grooming sessions intended to create better understanding of the customer problems to solve. I’ve also organized customer interviews with the development team. These work well in the near term but constant vigilance is necessary to prevent falling back on old and easier habits. If the company’s culture puts great weight on roles, I’ve found communication reform and increasing collaboration to be most difficult.
Is there a way to establish and perpetuate the desired communications and collaboration between development and the Product Owners?
There’s usually a desire to improve but if the culture gets in the way, improving can be hard. If you’re a developer in a non-agile environment, you’re used to having work flow down to you. You’ve become acclimatized to being told what to do. Agile spins this around where collaboration becomes the objective and common understanding the results. Sounds easy but very hard in reality.
Mentoring and training can help but only as far as the cultural limits allow. What’s needed is a way to work around this and yet stay within the boundaries established, and enforced, by the company.
Introducing the “Development Product Liaison”
Development Product Liaison is rooted in the world of Startups where the founders work closely together to develop an MVP. The idea is development needs to be across the customer problems and the potential business of solving these problems early in the product ‘ideation’ phase.
The Development Product Liaison is a member of the product’s development team who bridges both communication and understanding gaps between product and development.
What are the Development Product Liaison responsibilities
The Development Product Liaison will be a key position and gathers product and customer information very early in the product’s value chain. Involvement by the Development Product Liaison begins during ‘ideation’, before a new roadmap item is created. At a high level, the Development Product Liaison does the following:
- Work with the Product Manager (Product Owner) to define the vision of the project and create a Business Canvas (Tip: use Ash Maurya’s Lean Canvas board),
- Do feasibility studies on potential new products and features,
- Participate on customer contact calls/meetings/interviews (Tip: see Justin Wilcox’s Customer Interviews),
- Help develop high level user stories for new products and features,
- Help the full product development team break down work, targeting high value work first (Tip: see Mike Griffith’s article, Value Driven Delivery)
- Share the vision with the Agile development team; providing a critical link between the visionaries and owners of the product and the technical teams that will turn these visions into a reality,
- Develop a product definition with the Agile development team (Tip: use Roman Pichler’s Product Canvas tool),
- Help each Agile team member to empathize the needs of the user; carry into the team the customer perspective.
Who fits the role
Ideally, this is a person who is a member of the development team working on the product. This could be the team’s lead developer or architect. This person usually has the greatest product knowledge on the development team, both usability and technical. The Development Product Liaison is also a person who will put customers ahead of solutions. This is not trivial and is very hard for developers. It is difficult to put the pride one has for an eloquent solution second to customer satisfaction.
This shouldn’t be one person indefinitely but rotated among all the development team members.
What can you expect to happen by implementing the Development Product Liaison role? Here’s what I’ve seen over the years:
- Better assure the most valuable work is done first. By being the strong link between the business side and technical side of the product or service, the full product team is better at assessing value and priorities.
- The team and business are better able to estimate when the new product or feature will be delivered to customers. By sharing with the full product development team the business and technical impacts of new products and features, the full product team is better giving accurate estimates.
- Development team has fewer surprises during sprints. By being involved with the new product or new feature starting at inception, the Development Product Liaison is the technical expert. The development team can reduce or eliminate most uncertainty and risk by the time a story becomes Sprint Ready.
- Give the Product Owner room to focus more time on Product Management tasks during implementation. By being the technical expert and knowing the details of the business side of each story, the Development Product Liaison can help answer some, but not all, questions about user stories, testing, and acceptance that usually only the Product Owner could answer. The Product Owner and Development Product Liaison can share this responsibility.
No one has ever said having a Development Product Liaison is a bad idea but the Product Owner and developers need to do more than just agree. The liaison between Development and Product Owner must be a strong influencer and seen by everyone as an efficient way to organize the product team. I’ve seen where choosing to do development work over liaison work caused issues. I’ve seen where the Product Owner didn’t like having a liaison close by. But I’ve also seen where the liaison took on the work with great gusto and the Product Owner welcomed the close collaboration. Only the third option will breed success.
It is very important that someone can mentor a liaison in the beginning. A full-time coach would be able to do this. The iteration manager or scrum master can also provide the proper training and guidance. However, the ideal situation would be that former Development Product Liaisons do mentoring. This would be in keeping with a self-organizing Agile team.
The Product Manager benefits massively from having a Development Product Liaison. The trust between Product Manager and Development Product Liaison means that most nuances of customer/user product implementation can be dealt with from within the development team.
For the developer, being a Development Product Liaison can be a great career stepping stone. In one company I’ve been at, most of the Product Managers were former developers. The liaison role will provide valuable insight and learning for a developer move to the product/business side of product development. One of the advantages of working closely with the Product Manager will be learning finances and how a product company works. Forbes article, The Path to Becoming a Fortune 500 CEO lists a strong financial background in 30% of CEO’s. Something to shoot for.
Improving communications between development and Product can only help serve the customers and the business. Once development teams understand the customer and the business, they can contribute greater value faster. The development team acts as a sounding board for the Product Manager. The ability to collaborate and possibly compromise will be enhanced with a Development Product Liaison.
As long as someone on the development team and the Product Manager can agree to work together, the Development Product Liaison experiment should be successful. Egos, lack of trust, traditional role definitions will quickly disappear in the matter of weeks as these two form a union. An eagerness to learn and help on the developer’s part, plus a willingness for the Product Manager to hear other points of views will ensure success. After all, talking is better than not talking.