We recently ran an event attended by 22 Product Management Directors.
One of the questions we discussed was how should product managers ideally be spending their time?
There were many strong views and one particularly interesting contribution from Gerrit Vermeire who is Director of Product Management at Barco.
He drew the graph above to illustrate where he wants his product managers to focus.
Barco is a world leader in networked visualization for the entertainment, enterprise, and healthcare markets (3,300 employees and over €1 Billion in sales in 2015). Their markets require solid high-quality deliveries and their product development is around 65% hardware and 35% software. They use a classic waterfall development approach with Agile for internal software development.
I spoke to Gerrit after the event and he said…
“I want to absolutely avoid product managers acting as an expert helpdesk i.e. doing things other people or proper documentation can handle. They should focus on the things nobody else will do if they don’t – such as defining the overall mid and long-term strategy, creating the big picture, understanding the market problems, and translating them into solutions and products on our roadmap. I want to drive the bulk of my product managers’ workload into the ‘fuzzy front-end’ – as shown in the picture. These are the more strategic activities of generating ideas, understanding what customers want, finding out what can be built and what could be commercially successful.”
“It involves lots of talking to people, checking of concepts, and preto-typing (faking it before making it). So we try to do lots of mock-ups and presenting of concepts to customers. It’s about understanding the market and validating ideas before we start spending lots of money to build things.”
At Barco, he said this typically takes them around a half to one year for a new product.
Afterward, Product Managers go through a standard process with a Business Case Review and Product Design Review. This is quite intensive but they are typically much less involved in the subsequent development phase.
He went on to say “We get heavily involved again in the launch but once a product is in life we really want to minimize our involvement and for instance, try to push business-as-usual issues onto the Services team. Finally, there is a spike of work when we end-of-life something.”
One of the challenges Gerrit mentioned is working in the early phase with customers, end-users, and consultants to brainstorm on the mid/long-term technology and product options.
“We’re often trying to find out what might be possible in the next 3 years. It’s a subtle art to come to the table with some ideas and then tease out through discussions about what could be developed. It’s very much a back-and-forth, give-and-take process.”
Another challenge Gerrit talked about is how to split the workload across his different product managers.
“If I make product managers fully responsible for a too limited set of products in the portfolio there is a danger they don’t see the big picture. Similarly, if we split things by current and next-generation or pre and post-launch, we don’t get continuity through the whole life-cycle and risk missing a lot of key information.”
“What does work well is to off-load some product management activities to a separate product marketing team. They know their vertical markets well and drive the sales enablement activities during product launches. They have the insight to know which customers are best to talk to and can focus on managing the relationship. My product managers can turn up to customer meetings with new product ideas and get great customer feedback.”
In our event, there was a discussion about what the line in the diagram would look like for a pure software product developed in an Agile environment.
One view was that it would start where the red lines start and run straight across … as product managers are heavily involved all the way through a product’s life cycle. The fuzzy front-end is a continuous process.
Another view was that if the product manager was not the Scrum Product Owner it might be more like Gerrit’s line but with spikes each time a major new release came out.
What would it look like in your company?