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?
I joined Shane Hastie’s InfoQ podcast for a high-speed talk about building the right things; how engineering teams worldwide are similar; and the importance of bringing development teams into close contact with real customers.
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.
Product managers must be part of the (enterprise) selling process. But selling and learning are hard to do at the same time with the same customer. How do we create separate learning opportunities with a wide range of customers and prospects to deeply understanding markets, segments and fundamental needs?
The AgileCamp organizers have generously invited me to kick off the Dallas event with a keynote on unpacking business value. We’ll look at things from “the business side” ahead of a full day of Agile and Lean practices.
As a long-time B2B infrastructure product manager, I’m used to thinking about my customers as guys. IT managers and directors, 30-50, developers or sys admins who’ve been pushed up into management, frustrated, under-appreciated and under-resourced, pale from weekends spent inside… I’m exaggerating on purpose. Rrecent chats with three women who run IT groups reminded me that we (product managers) need to channel our diverse customer base — wherever it leads us.
As data-driven product managers, we’d like to pretend that incoming technical requests are simply transactional. In the real world, though, real people and real agendas are involved. And that means there’s a personal and political context to consider when prioritizing demands on our already-overloaded development organization.
How do we understand value from the customer’s point of view, not just the vendor? How do we choose pricing units, what portion of value can we capture, and why do we have to do the math/thinking in advance for customers?
Focusing on skills rather than titles, how do we avoid product manager/owner failure modes for revenue (commercial) software? And why do revenue software companies hire product managers, when agile development teams are looking for product owners?