You know that even the perfect product strategy is still utterly dependent on execution. Successfully pulling off strategies as wide ranging as the build, buy or partner decision will all require granular insight beyond what a product manager is aware of. Ultimately, engineering insight is the key to accurately analyzing the complications of and necessary effort for whichever path you choose. But how do you collaborate effectively with a development team that may or may not agree with the path you have chosen?
As product manager, it often feels like you have little control over the development challenges that get in the way of critical releases, due diligence, or a reliable integration. Getting the result you want will likely require some ingenuity, and a little diplomacy can go a long way.
Bottom line? You may not have transactional power over your development team, but let’s explore the levers you do have.
In this article, we’ll delve into effective communication, collaboration and consultation tactics. And we’ll work through how they help you overcome (or even avoid) product management challenges with developers.
Stay strategic throughout
It’s easy to get bogged down by the short-term minutiae of product delivery. While this article will help you reduce the need for reactive fixes, they’ll never disappear. And that’s ok, as long as you balance your focus between both short and long-term goals.
In fact, carving out time for the strategic part of your role is critical in smoothing those day-to-day challenges. As Roman Pilcher, product management expert says:
“…recognise that a shared product vision and validated product strategy are more important to guide and align people than beautifully crafted user stories.”
So, before you work on overcoming your current challenges, define your business objectives, market positioning and project goals. They give developers context and purpose. And a multi-year product roadmap helps developers anticipate how today’s decisions will affect next year’s priorities. This in turn prevents the build-up of technical debt.
Tailor your communications
So, you have your roadmap and objectives. Next, you need to communicate them.
“Where great marketers nail messaging externally, great product managers nail messaging internally … Great product managers communicate with those stakeholders in a way that speaks specifically to them so they know where their needs stand, feel clear about what’s coming next and why it was prioritized, and trust their product management partner’s judgment in determining how to maximize customer value.”
Meg Murphy – Hotjar’s VP of Product
You want your developers invested in your product and what it will deliver for the business. This will promote focus and a commitment to quality. It also helps them understand the priorities in your project, be it completeness of vision, time to market, or efficiency of budget.
When it comes to tailoring your communications to developers there are three key factors to consider:
- Providing enough detail
- Building trust and respect
- Sharing ownership and responsibility for delivery.
Let’s explore each in more detail.
Give developers everything they need up front
Measure twice, cut once. As true for tailoring as it is for tailored product development. It’s cheaper and faster to resolve ambiguous software requirements before work starts.
Communicate everything before the sprint planning and build start. As a basic, there are three things your developers need to understand and plan a build:
1. Well-written user stories and acceptance criteria.
Sometimes, written requirements alone aren’t enough. Developers need to understand what a user expects from a feature, why it matters to them and what success looks like. Share actual end user testimonials with developers about the problem the feature solves.
Top tip: Don’t let your own preferences for the product get in the way. The HBR warns what happens when you push a feature not backed by customer interviews and evidence. “This lack of self-awareness could … damage the PM’s relationship with engineers, who may lose confidence in their PM when the feature isn’t readily adopted by users.”
2. Detailed expectations for the UI/UX.
Whenever possible, provide a detailed wireframe, mockup or prototype of the UI. If you can, provide all three. And do so before the team does their estimates.
Top tip: Communicate the broader user experience too. Help developers understand how a feature will fit into an end user’s routine. For example, do they need to complete a workflow 100 times in an hour or once a month?
3. Feedback opportunities.
Get developer feedback on planned features early to surface potential problems sooner. This gives you time to consider alternatives.
Top tip: Feedback is crucial throughout product development. When you get positive feedback from customers about new functionality, pass that back to the developers. It’s all valuable.
Trust your developers
“View the [development] team as an equal partner, involve the members in product decisions, and encourage them to take ownership of the product details.” – Roman Pilcher, product management expert
Trust and respect are critical for an effective working relationship with developers. It’s your job to explain how users expect new features to interact with existing functionality. In return, they can provide you with critical technical foresight and expertise. This helps to head off technical debt and allows for accurate release planning.
Writing for the International Software Product Management Association, Garm Lucassen outlines the ‘Reciprocal Twin Peaks’ model of collaboration between software product managers and technical stakeholders. It’s essentially a repeating loop of steps for validating new feature requests:
- A product manager spots trends in feature requests and sees a market opportunity.
- The product manager turns this idea into rough requirements for a potential feature build.
- They then share and discuss the requirements with the development lead. This is to understand feasibility and where it sits in the product roadmap.
- Together, the product manager and technical lead work back and forth to refine the rough requirement. They do this at the project, product and work package levels.
- Not all requirements that start this process will end in a release definition. Viability and business value determine what goes ahead.
Adopting this kind of model elevates your development team to the role of trusted partner. And with trust comes a wealth of benefits. There’s a great deal of research on the neuroscience of trust, including an HBR study that found,
“Compared with people at low-trust companies, people at high-trust companies report: 106 percent more energy at work, 50 percent higher productivity, 76 percent more engagement.”
Ultimately, trusted developers are more committed and more engaged developers.
Get granular, and then let go
You know deadlines are critical for getting a product or feature out the door. You also know how often you have to push them, making them seem futile. To revive the power of deadlines you need to rethink who owns and sets them.
Your developers know how best to deconstruct a feature and phase it into releases. They know which elements take the longest and which ones they can complete quickly. So, work with them to prioritize requirements in an MVP or a thin pass. This will allow more time to flesh out details on the most urgent release work.
Shared ownership also means shared responsibility. Developers that feel like partners will feel empowered will raise issues early, offer solutions and more effectively avert delays.
The HotJar team suggest using team-driven deadlines:
“Setting delivery dates for key milestones should be a dialogue between business and product teams, and within the product team itself. Empower your team by creating an environment where they can set—and meet—targets.”
Adopting this agile, self-organizing approach means letting go and respecting the autonomy of your team. Once you set deadlines and your development team organizes its sprints – do not interfere.
Acquisition and partnership: spotting hidden challenges
At this point, you might assume acquiring another codebase or integrate a third-party product is an easier route to.
Not necessarily.
The challenges might be different, but they still require strong, trusting developer relationships. And not just for those reviewing third-party code or advising on integrations and add-ons. Buy and partner routes create added complexities around influence, communication and motivation.
Partnership developer challenges
Collaboration and conflict are the most common issues with the third-party route. Your developers will have to work with your partner’s developers. This creates a dependency on teams who are beyond your influence and who are not aligned to your organization’s priorities.
McKinsey found that the most common factors cited as missing in failed joint ventures were “alignment on parent and partnership objectives” and “effective internal communication and trust”.
Top tip: Be circumspect with your expectations. Keep a close watch on which side of the partnership is more dependent on the other. And plan longer timelines accordingly.
Common developer challenges with acquisition
This scenario can be the most complex, presenting developer challengers that are hard to overcome.
- Due diligence. Assessing an acquisition target may require advanced software development expertise. This may be in short supply or something your team lacks entirely. Competitive instincts can also distort an objective evaluation of third-party software. Developers may diminish the quality of a competitor’s product or feel threatened they could become redundant.
Top tip: Trust balanced perspectives and reassure everyone involved in due diligence of their role post-acquisition.
Of course, it’s not just developers that may feel nervous about an acquisition. You’ll often find yourself working in parallel with the acquired product manager and their team for some time. It may be that your market overlap diverges or, more likely, one product subsumes the other. Here having a keen eye to developer management and cultural shifts is key.
- Team integration. With acquisition comes a new team with their own culture and their own ways of working. Shifting or adapting to that culture is difficult and time-consuming. Add to that, some developers may be hostile to their new parent company. You may struggle to keep those who know the product best.
Fintech influencer and entrepreneur, Alessandro Hatami writes about the competing challenges of build, buy, partner. He warns that the people and culture challenges of acquisition mean, ”one could end up with a business that is a shadow of what was acquired.”
Top tip: Show patience and a willingness to listen to developers’ concerns. Newly acquired developers often know about lurking issues, not disclosed during due diligence.
Factor these challenges into the estimated time and cost to buy and you may decide building isn’t so formidable by comparison. Either way, this clarity will ensure you ask for the development resources you need.
The evergreen challenge: getting the resources you need
We’ve shown it is possible to overcome product development challenges with developers. But this advice hinges on one critical factor: that you have an adequate team of developers that can meet your goals in the first place.
You may find your developers are busy with another product. Or your organization struggles to recruit the right talent. Either way – this lack of resources is a huge challenge for product managers.
Diminishing the needs of other products in a zero-sum internal competition won’t help. Nor will pushing for developer talent over other critical hires in a smaller business. You can’t influence the speed and effectiveness of recruitment. Nor can you control market conditions. For example, you can do nothing about the fact that three-quarters of global IT decision-makers experience critical skills gaps on their teams, a 145 percent increase since 2016.
So, it may be time to consider other options.
Rethinking outsourced resource
A dedicated team of nearshore or offshore developers – provided by the right outsourcing partner – has many of the same benefits as an internal team. They will provide the same level of commitment, communication and critical skills covered in this article. And their impartiality and product focus can outweigh the benefits of waiting for an internal team.
Of course, hiring developers isn’t always your decision to make as a product manager. Often, it sits with your colleagues in development. And they may have legitimate concerns about outsourcing to an outside team. (Concerns that the right partner will be well prepared to address.)
To show you can address these concerns, deploy the same skills we’ve covered in this article. Set out your vision, respect your development lead’s feedback and keep them in the loop. And if you need support making your case, we can offer a few pointers on why even software companies should consider software development outsourcing.
Ho Chi Minh City, Vietnam