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.
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.
Program management tools need the output of a good product management process, but the same tools don’t work for both purposes. Some thoughts on what product managers need to make good decisions…
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.
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?