Many infrastructure development teams don’t have a product manager. That forces an architect or senior developer to manage a range of responsibilities they are not best equipped to handle: settling conflicting business priorities; internally “selling” the value of architecture; tying technical decisions to business metrics; making connections between software and end user joy.
Enterprise companies are structurally different from consumer and SMB companies, and product management tools are different – even though we have similar product/market goals. What should B2C product folks want to know before crossing over?
Product managers need to talk — often — with actual end users and buyers. We need to listen, interview, understand and empathize with paying customers. Unmediated by marketing, sales or researchers. What organizational barriers block this essential work, and can we remove some of them?
Your different audiences have different (often opposing) goals and incentives, which means they probably want different product decisions and therefore different roadmaps. You need to understand and anticipate their agendas.
What are the questions that various groups really want to ask, and how does that shape our roadmap conversations?
Enterprise (B2B) sales teams deal with the world one account at a time; product managers deal with whole customer segments. This naturally creates some friction, which good companies anticipate and manage.
Talking generically about ‘customers’ or ‘users’ can generate lots of confusion, especially in B2B or B2B2C situations. We can be more precise by saying doctors, or shoppers, or data analysts, or whatever we really mean.
The revenue side of the house often believes that incremental budgets – or major deals – all that it takes to add new items at the top of the development queue. Like ordering a custom-built sandwich at the deli counter…
The “No Head of Product Syndrome” is where product managers are scattered throughout a complex organization, but lack an executive-level product leader who can to create conditions for success: drive good hiring/mentoring, create bits of semi-standard processes, and set achievable role/job expectations.
Technical Build versus Buy decisions should be straightforward, but we need development collaboration and motivation to get these right. What emotional barriers do we hit, and how do we address them? And how do we become better students of organizational behavior?