Time and again, one of the largest challenges I see affecting companies with their product teams is having unclear and/or incomplete definitions of what constitutes the product. My rule of thumb is that if it touches the product, it is within the scope of product management. The rationale behind this is simple – if it touches the product, somewhere, somehow engineering dollars are being spent on the product. And those dollars could potentially be re-prioritized if needed for something else. Not having this aligned often results in missed expectations from a core user personae or significant conflict on how engineering dollars are being spent.
Consider a well-established marketing technology product whose core audience was towards digital marketers within a marketing department, it also had over a dozen technical personae split between the implementation partner (either an agency or systems integrator), the end-customer’s internal development staff, and the end-customer’s IT department to host the solution. None of the technical personae had ownership within the product management team. As the solution transitioned from on-premise to the cloud, this added another dimension of personae and requirements. And, compliance was not looked at by product, but instead resided within legal.
This resulted in several very unfortunate consequences:
- A number of key requirements for the technical personae were missed in their entirety, resulting in several generations that fell extremely flat with customers, costing significant time in the market as well as missed opportunities and customer dissatisfaction.
- Compliance requirements as they started to emerge were derailing roadmap, resulting in very unfortunate conversations such as “We can’t deliver X because we now have to do Y for compliance, which was not on our radar.” This not only disappointed internal stakeholders, but damaged customer credibility due to the lack of a predictable roadmap.
- There was no mechanism to address the needs of moving from on-premise to the cloud, including impact on internal systems such as starting to track resource utilization and managing the cost of goods (cloud expenditures), which existed for the first time. It simply did not exist.
Later on, this organization began investing in strategic partnerships that had material impact upon product roadmap, which further complicated the issue. The ending in this story was a happy one; the organization pivoted to redefine its product organization in a much more all encompassing fashion. This enabled the company to create a holistic product roadmap and deliver predictably against it, establishing themselves as market leaders in multiple product categories with recognition from the likes of Forrester and Gartner. They were also able to successfully pivot to the cloud, which helped them command a premium valuation upon exit to private equity.
The alternatives are poor – chaos as described or the advent of “shadow product management” emerging in other teams and departments, creating a fractured product roadmap and a stymied ability to deliver efficiently and predictably.
Getting there requires that the product team really, truly provide full stakeholder management and roadmap consideration across the full breadth of the business. Please refer to the following diagram.
This requires bi-directional input and consideration from:
- Finance (with a bridge to the Board of Directors and desired investor outcomes) – if the product strategy does not fit within the company’s operating budget and build toward investor goals, it is misaligned.
- IT – to consider line of business connectivity. Most SaaS platforms have multiple touchpoints with many internal systems and these need to be fully considered when formulating product roadmap.
- Business Development / Strategic Partnerships – these generally have material product “gives” in return for strategic product or go-to-market “gets” and need to fully be taken into consideration from a roadmap perspective, as often they will require firm delivery date commitments that may be challenging to hit.
- Legal and Compliance – one must stay fully in front of the regulatory environment by having a close partnership with the legal and/or security teams to prevent de-railing asteroids from impacting, or worse – material product rework due to the need to reach compliance.
- Go-to-Market Teams (Sales, Marketing, & Success/Customer Support) – this will be covered in more depth in a separate section, but it goes without saying that the GTM teams are arguably the most important internal stakeholders for both roadmap input as well as cross-functional alignment.
- Engineering – this is by far the most complex but critical relationship. If a product has any technical personae, this will need dedicated product management bandwidth and coverage (along with the requisite technical skill sets) to own these feature-sets (e.g. APIs, integrations, etc.). If the product is such that it is truly end-user facing with no technical personae, then a product liaison should be identified to partner with Engineering to encapsulate the technical backlog into the overall product roadmap such that there is one version of the truth. This is a huge opportunity for collaboration and partnership, as one of the most effective means of delivering technical initiatives and reducing technical debt is by pairing it with business value and using the old proverb “when the hood is already open” to match-make business value and technical needs.