Thursday, September 24, 2009

What does Product Management need from Engineering

Yesterday while at lunch I was asked by a VP of Engineering what Product Management expected from Engineering. An excellent question and one that is valid no matter what the organization size - and not as easy to answer as I thought. The definition of product management (and engineering) is different from organization to organization and from person to person - and every organization has different needs, strengths and weaknesses.

The first goal of a Product leader is to create a common understanding with engineering on roles and responsibilities. Don't assume when you turn up that everyone knows what you should be doing (even the CEO). Start with the job description, and sit down and interview all the stakeholders - you'll always find a broad range of definitions and understanding. There is nothing worse than a Product Manager who waltzes into an organization and suddenly expects everyone to follow their definition of Product Management.

A mandatory pre-read to this article is Marty Cagan's excellent article "Moving from Engineering to Product Management", explaining the key differences in thinking between the two roles. I won't repeat those here, but this is extremely important.

The best products are built by a team of engineers and product people who trust each other and interact closely and regularly - there is absolutely no doubt in my mind or experience that a one sided approach leads to failure (or a failure to capture the full opportunity). Interacting with the market, customers, partners, analysts, press, developing product plans is a full time job. Ditto building software.

Keeping that in mind, here's how I answered the VP of Engineering's question:
  1. The number one goal is for PM and Engineering to form an open and trusted relationship and nothing else matters. The groups must be talking every day and feel that they can rely on each other and trust the other to do their job. Although this sounds simple, it's often neglected. Communication must occur in person and a good model to follow is the agile "15 minute standup". If frequent and open contact does not happen then the relationship is doomed - at one role of mine the CEO was almost continually unavailable, so I was never able to really connect and understand what was needed/wanted.
  2. Conversations must be open and honest - each side are smart and have an ability to detect bullshit. There is nothing wrong with admitting shortcomings, concerns, resourcing issues, etc. I have noticed in the past that it may take a "blow up" i.e. emotional argument to reach a point of openness - I am not advocating this as a path, but it has worked for me when we didn't seem to be making progress in the day to day meetings.
  3. There needs to be a recognition from Engineering that Product and Market issues cannot be solved the same way as engineering problems. Engineering is analytical and technical discussions can be debated in precise terms and solved in an absolute way. Market issues are a complex mix of data, market forces, customer desires, economic conditions, positioning, pricing etc. I have seem a lot of conflict between Engineering and PM when Engineering continually pushes and frustrates PM for "more data" even though decisions are made with a different set of criteria.
  4. In a similar vein to above, Engineering needs to understand that we are living in an extremely fast moving and dynamic world, and in the worse recession for 70 years. Product can do all the right work to decide a future direction, but the ultimate approach that all companies must take is one of Product Discovery (another blog post of its own). You must get to market quickly and validate the path is correct. There is no shame in ackowledging that all the right work was done, but after the first iteration the market has moved or you missed the mark - the main thing is that you can understand what changed, and refocus quickly. So Engineering needs to not show frustration to course changes along the way, and not blame PM.
  5. When the above occurs we can reach the ultimate point - Engineering and PM see themselves as joint stakeholders in the product. No one group owns it or takes credit, and each team is confident that they have part of a successful team, and when PM asks for changes they do it for good reason.
The above has focused on relationships, frames of mind, and reaching a mutual understanding, because once that happens, everything else can be solved. From a nuts and bolts perspective, here are some of the things that PM would expect from engineering:
  1. Requests for clarification or additional information on products, MRDs, uses cases, etc
  2. Status updates on projects - what is on time, what is behind, what needs more resources
  3. Feedback on support issues - how much time are they consuming, trends etc
  4. Feedback on any customer issues or opportunities uncovered directly - engineering is often in customer calls or conferences that can be fed back to PM
  5. Exciting innovations that engineering has produced or could produce
  6. Information on new features and products so that Marketing and sales can be fully briefed on how to take to market
  7. Collaboration on roadmaps
  8. Collaboration on product releases
  9. High level product design and user interaction reviews, so PM can understand if the design will grok with customers.
  10. And finally, don't let issues fester - sit down and discuss concerns early and get them solved before things blow out of all proportion.
The next post will cover what Engineering should expect from Product...

No comments:

Post a Comment