Team Producter: Would you tell us a bit about you and your career path in product management?
Greg: I started my career as a developer (on mainframes!). I then became a consultant at IBM and had an opportunity to become a PM in 2000 in the area of workflow and business process management (BPM). There wasn’t much information available on the discipline back then. I then spent a few years at Microsoft working on process modeling tools for business users. In 2006, I was recruited by SAP and moved to Germany. We launched SAP’s first business process platform. I helped establish product management as a role in their technology organization. For the last several years, I’ve been a consultant, trainer, and coach, focused primarily on product management maturity in the global B2B space. I coach PMs and product leaders at all levels of experience.
Team Producter: How do you think departmental silos affect product companies? In what ways do you build and maintain relationships with stakeholders from different teams?
Greg: The whole idea of functional area as the main organizing principle in tech companies (all companies?) is probably misguided. I’ve spent my career thinking about business processes, which turn business inputs into outputs. Organizing primarily around processes is, in practice, a much more effective approach.
Managing internal stakeholders begins with prioritization (like so many topics in product management). Since PMs have an essentially unmanageable number of stakeholders, it’s critical to know at any given time which ones can make the biggest contribution to the success of a product. It is these stakeholders we much focus on, ensuring we have a shared definition of product success and an engagement model which allows us to share important information and enable “knowledge accidents”.
Team Producter: When it comes to listening to your users, what's your method? Is their input considered in critical product decisions?
Greg: I believe in using a balanced set of engagement techniques based on context. Interviews are great and give you one perspective. Those same people may provide different feedback if they’re completing a survey. While there is a lot of emphasis on face-to-face engagement in product circles, it doesn’t scale well and can easily give us a false sense of confidence.
It is critical to understand that, to grow, we must serve the overall market, not just those who have bought our product (customers). I’ve had good luck looking for proxies for the market who could aggregate feedback from multiple sources. For example, we once created a design partnership with global systems integrators who effectivenly represented far more customers than we could have ever engaged with directly.
Team Producter: How do you think product-oriented communities add value to products?
Greg: The value of the community varies with the product value proposition. In many cases, having a thriving community that has a strong interest in your product’s evolution is highly valuable. I’ve worked on “framework” products in the B2B space that required a significant amount of configuration and even programming to do anything valuable. We heavily relied on a strong community of business people and technicians to help prospects understand the value the product could deliver and to minimize customer time to value.
The effort to establish and cultivate a valuable community is very often underestimated in my experience. You can’t achieve and maintain momentum with community building as an afterthought. Also, community management is a complex competency that takes time to develop. Having a person or people dedicated to managing the community is a good idea.
One aspect of a healthy community that I particularly value is strong relationships that make getting feedback and validation much faster, cheaper, and effective. You have to be careful because the community isn’t always a representative sample of the overall market, but if approached carefully, I think the benefits far outweigh the risks.
Team Producter: Is there a method you use for prioritization? Or, Is there a custom approach you designed?
Greg: I like to use multiple methods on the same set of requirements/features to do cross validation. I’m partial to prioritization matrices with criteria selected for the current context. What we sometimes overlook are the fundamentals. For example, prioritization outside the context of a meaningful strategy is little more than codifying your personal preferences. That means we need to define and validate a clear strategy before we try to prioritize almost anything.
We also have to be careful to compare apples to apples. I believe in defining top-down guidance within “buckets”, e.g., maintenance, evolving existing features, building new features. It is within these buckets of like things that we get the most meaningful prioritization. It’s important to define roughly how much of our engineering capacity we’d like to invest in each bucket and then manage to it. As we prioritize, we may find that we need to adjust the top-down assumptions.
Producter is a product management tool designed to become customer-driven.
It helps you collect feedback, manage tasks, sharing product updates, creating product docs, and tracking roadmap.
You may also like:
Samet Ozkale
Samet Ozkale
