Engineering Should be PM’s Best Friend
By Wayne Greene and Laurent Gharda
Product Managers are a unique class, a veritable professional unicorn. Responsible for creating business value out of the ether, they must create value as it relates to a “whole product”. They can bridge the business and the technical, forge links between architects, and be the ones who go to market. Seeing the big picture while deciding on micro-features is a piece of cake. Un-ruffling the feathers of irate customers followed by sorting the backlog that results from back-to-back meetings is but one context shift this magical character must handle. The Product Manager must create and nurture excellent relationships with engineering, marketing and CTO counterparts. We will be so bold as to say that Engineering should be the primary BFF to PM. Why is that?, you may ask. Some PMs may have a bit of engineering background. However, if they can work closely with the engineering lead (product owner) and can agree on a specific product feature/positioning/how to build something to last, this duality of support is hard to outdo, even by the senior management.
Let’s explore this theory from two angles: Development Lifecycle View (Requirements, Architect, Development, Test/QA, Release, Support) and the Product Lifecycle View (Business Idea, Prototype, Growth, Saturation, Decline, End of Life).
Development Lifecycle View (Requirements, Architect, Development, Test/QA, Release, Support) — Laurent’s View
More often than not, engineering leadership is comprised of skill sets that go far beyond the role of leading teams in building and maintaining products. World-class Vice Presidents of Engineering (VPE) have — time and again — climbed up the ranks, not only because they were at one time good product designers or implementers, but also because they have a 360 degree swivel head. They have the capacity to keenly and continuously observe the internal divisions working alongside them, as well as the market, competition, industry standards and more.
As a CEO, on many occasions, I have taken a VPE to meet with prospective investors and key sales prospects, and have included them in the interview process when hiring for senior or executive product management roles. As a rule, VPEs are business savvy, sharp as a tack, and, in many cases, crave a role that is more comprehensive than that of running the technology and development side of the shop. If, as a Product Manager, you have worked with such a VPE, count your lucky stars. If you haven’t, hope that, one day, you get to do so.
Naturally, there are VPEs without a company-first mindset or breadth of experience. You may meet those who are territorial (“don’t talk to my engineers without letting me know”), defensive (“I built the product exactly to spec: the spec was horrible and I knew that from the get go”), or, possibly worst of all, siloed (“don’t care about sales objections, marketing plans or stock buybacks”).
Product Management’s relationship with a “good” VPE can and should be a wonderful thing — at all different phases of a product lifecycle. A tight PM-VPE partnership can make a huge difference in product quality, user experience and company revenue. So let’s get started…
Requirements: Whether planning for enhancements to an existing product, or defining a ground-breaking new product or service, PM’s constituents include industry analysts, existing customers, and sales management. Further, they need an ear to the ground about what’s happening in your space (news, competitors’ products or announced plans, etc.). The VPE must be one of your constituents as well, and for several reasons. He/she, along with 2–3 of the senior-most members of engineering, has considerable experience and value to add in defining and prioritizing features, even before detailed architecture is laid out. Engineering can educate PM on possible new technologies or standards that make advanced functionality a breeze to implement in an initial phase, or sometimes the converse (“whoa, that’s the long pole in the tent and you’d be better doing that later in the lifecycle”). Engineering’s participation in the requirements phase will make your product better and you will get much needed buy-in from the team responsible for implementing PM’s vision. This is a win-win!
Architecture: The architecture phase, in siloed environments, is where PM often gets shut out by Engineering. More enlightened engineering leadership that has a good relationship with PM will involve PM in initial discussions [selecting the standards and components to be used in implementation] and in the final architectural design review presentations. PM skill sets vary, so the key here is to be included in the architectural phase in order to be in the know and able to articulate the “why and how”. The purpose is not for the PM to propose architecture guidelines (unless the engineering team is living 15 years behind the times).
Development: This phase is completely owned by Engineering, but having a friendly relationship with the VPE will enable the PM to understand development sub-phases and expected early deliverables. This may well help with large customer opportunities. It is critical that the PM be discreet — nearly invisible here (except in private conversations with the VPE). This is a time when legitimate feature creep (again, based on validated revenue potential) could be introduced and potentially reshuffle internal milestones. Without a close relationship with the PM, the developers will build the product themselves, with little feedback or external point of view. The PM can give Engineering a more comprehensive perspective with which to operate. Consider the areas that can initially be managed by the PM: marketing, sales, and CTO types (this can be done for a while as the PM can speak product architecture). You might disagree with this assessment, but, at the end of the day, without a strong PM/VPE relationship, this would be impossible.
Test/Quality Assurance: QA is one phase PMs too often ignore since it’s “simply making sure that my spec gets tested — not my job!” This, in my humble opinion, is a huge mistake. The QA phase is a PM’s golden opportunity to witness the user experience, flow of the product, application’s messaging to the user and many other aspects that impact a prospective user’s initial impression of the product during a POC. I’ll go one step further and recommend that PM do some QA as well, particularly once the bugs have been found, but before the product messaging (error messages, warnings, tips, etc.) get baked in and passed onto tech pubs. This is the chance for PM to really roll up their sleeves and help engineering by playing customer. There are few other efforts that take only a few hours, yet have the potential to yield immense benefit! All text presented by the service or application to the prospective user should be reviewed by the PM to make sure messaging and steps are crystal clear for the end user.
Release: If the PM has been on the ball up to this point, the Release will be easier in that the Product Manager can communicate with the Product Marketing (outbound) team, the PR team, Executives (about talking points), and Sales. He/she can effectively discuss the competitive summary, SWAT, POV and other communications methodologies.
This is also a phase where it will serve the PM well to give the VPE a bit of the limelight in outbound materials. A simple quote in one of the brochures will not only make the VPE feel valued, it will further build the PM-VPE mutual respect.
Support: Software has bugs. Customers will find bugs and engineering will fix bugs. So what does PM have to do with engineering during the support phase of a product lifecycle? You may be surprised to hear me say, “Quite a bit!” The PM is vital in prioritizing what to fix when, as well as addressing “soft bugs”, unexpected customer behavior in response to ambiguous or poor product messaging, that leads customers to report a bug that can be addressed by clearer wording or messaging. We’ve all seen user messaging with double negatives. One user will understand what the developer meant, while the other will take the message literally. PM should swoop in, address these real issues (perhaps with an informal focus group to play guinea pigs) and aid in the process…always with the support of the VPE.
Summary: Product Management and Engineering are tied at the hip, or should be. For real, meaningful collaboration to happen, traditional hierarchies and reporting structures should be checked at the door. PM traditionally reports into a Vice President of Marketing, so VPM and VPE are peers, but skilled PMs and forward-thinking engineering leaders ignore that hierarchy. The result — making the company’s products the best they can be. Product Managers and Engineering leaders should be Best Friends Forever!
Product Lifecycle View (Business Idea, Prototype, Growth, Saturation, Decline, End of Life) — Wayne’s View
Having Engineering as PM’s best friend takes a variety of hard and soft skills as well as situational leadership. We all know that products have life-cycles and that the PM’s role during each of these phases can vary. It is rare, however, for a PM to manage a product from beginning to end of their lifecycle. How many PM’s stay on a product from cradle to grave (a process that, for enterprise software, may be as short 6 years or go on for as many as 10 years)? How many PMs stay with a single firm that long? This, by the way, is not an indictment on the tech industry. This trend has infiltrated nearly all industries — both domestically and internationally. Consider approaching this section from the perspective of what areas PM and Engineering need to focus on during each phase of the lifecycle to develop the best possible relationship and achieve product and personal goals.
Business Idea: You may be a PM at a large or small company, or, perhaps you are working with a set of co-founders whose desire is to brainstorm a new business idea based upon a product or service. Where the idea comes from is not relevant. What matters is what happens with that idea. They key to this first phase is to focus on brainstorming and valuing the perceptions, opinions, data, and corroborative stories brought to the table by your counterpart from Engineering. The idea may be a concept and not yet thought out as a product. Although you may see your role as having the business lens and knowledge of what your customers or market segments may want/value, you need to be a keen listener to your counterpart. Ask clarifying questions to expand the discussion. This will help you avoid asking ‘zinger’ questions all PMs know can shoot down an idea. If your engineering counterpart views you as a threat to their idea/concept, or, worse yet, as not being an ally (in their quest for product brilliance), you may find yourself cut out of the process. Do not, I repeat, do not get shut out of this phase. You want to be viewed as the catalyst who will help take the idea to the next step — with your strong support. Conversely, you need to have an alliance with the engineering leader who will back you up when you bring up your great idea. Your counterpart will provide business and technical validation, along with enthusiasm and support (yes, I want my engineering team to work on this great idea).
Prototype: That great idea has migrated into the prototype phase with the assistance of both departments. Engineering will need PM’s help get resources and provide the necessary air cover so that the team working on the project can continue to do just that. You will need to work with the team to provide necessary input. Engineering will naturally want to focus on key technical aspects and difficulties. Your role will be to help support them and ensure that the prototype isn’t a “hack”. No one wants the prototype totally rewritten or even significantly refactored as it releases for paying customers. Help guide Engineering on user experience and core-use case workflows, as well as the backend that is invisible to the customer but will, ultimately, consume a great deal of the future backlog.
Growth: The product is launched and you and Engineering are basking in the glow of a successful product (you may smile here as you get the visual image). You have user and customer counts skyrocketing. You are both doing customer interviews (and attending some escalation calls). You both must support growth in this phase, as well as ensure the technical and use case debt does not get too backlogged. It is vital to ensure you and your engineering counterpart are aligned on the direction and maturation of the product. For example, there will be demands to morph the product to take on a wide variety of requirements and use cases. Pressure will come from Sales, which is trying to make ever-expanding sales quotas. The two of you will need to weigh those needs against the purity of your vision and the product direction nirvana. Do you want to take on use cases from an adjacent product or product category getting forced on your team in still increasing amounts? It is obvious that, after a few years of being on this product, you have attained a pretty high market share and are still growing, albeit slowly. More of your time with your Engineering counterpart is spent on satisfying the established customer base. Ease of enterprise usability and migration to the latest release take the most effort. You will have to work closely with your counterpart to ensure ongoing connectedness to the product rather than trying to morph to other products or interesting use cases for the product. Will the Engineering counterpart see this as a resource pulling away from the product product in your space? Or is your goal to drive towards the best customer experience in your existing set of use cases? Be sure to maintain your point of view as the PM and understand that of your counterpart as well. Come to an agreement (with some negotiation and compromise of course) and use this as your basis to move forward..
Saturation: This is one of the trickiest phases in a product’s lifecycle. By now, your product’s growth rate has begun to slow. You have broad penetration into your target customer market and have achieved growth in other areas. That sales velocity and penetration typically begins to fall off even before the onset of this phase. However, you and your engineering counterpart will arrive at a moment in time when you realize the world has changed for the product. Customers are trying to maximize the value of the software within their organizations and, internally, your Business Unit is looking closely at maximizing revenue streams across not just your product, but multiple releases of ALL the products. It is vital for the brand to ensure all customers are happy with all touch points with the product. This will drive, even force, you and engineering to focus on a different set of issues that in many ways is neither sexy nor compelling from a excitement or career perspective. During this phase, junior PMs or engineering product owners are handed the baton. This is an opportunity for you and your BFF to coach and mentor junior staff and to keep an eye on customer satisfaction and business unit controller perspectives of the business. You still need high levels of staffing on the product at this juncture.
Decline: This phase could begin 2 years after launch or, for some, could be 5 years or longer. The product is no longer the key part of a software deal. Customers are starting to move use cases to new models (i.e. on-premise to SaaS) or have relegated the use of the product (even though it is a workforce of the company) to the group in the IT department that deals with the dreaded Legacy systems. During this phase you will be preparing the product and business for end of life. Work with Engineering on those dot or dot-dot releases to confirm customers can get their data out of your product and that you are keeping the product support matrix up-to-date with the latest platforms that it will run on. Ultimately, you and your engineering counterpart know the next phase is around the corner. And End of Life is declared with one more year of bug fixes, followed by phone support only and, finally, shut down of the product. Even in this phase, some interesting questions come up for you as the PM and your engineering counterpart. See below:
End of Life: Undoubtedly, there will be discussions of customers who do not want to end usage of the product, or are even willing to pay extra for post-warranty and bug fixes. Your organization may have a corporate function for this need, perhaps part of technical support. Alternately, you may both be asked about the feasibility of outsourcing the product’s last years to another entity outside the company. It will serve as a way to help those customers who need more time to get off the product. Due diligence on the proposal and the product is necessary in order to figure out the right thing for customers. Remember, sometimes the right thing to do is let the end of life play out and not prolong the patient’s life.
Advanced Topics
A full featured PM needs to have a variety of soft tools in his or her toolkit to ensure the product gets the best treatment from PM and Engineering. Other advanced topics can help even a seasoned PM get a great deal of value. The first topic covers pros and cons of organizational placement of the PM organization, particularly when the company does not have a PM function that reports to the VP, GM, or CEO. It is definitely worthy of a detailed read for PM leaders. The second topic we’d like to suggest is how to run a high performing product leadership team. All too often, great products get mired in committee or horrendous product leadership. Don’t let this happen to your product.
Originally published at fromchemistrytoclouds.com on October 10, 2017.
