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?
Join the conversation - 5 replies
Nice chart, in a case of multiple major launches per year we get in to situation that not one line, but multiple lines would turn up with certain delay.(example: while we are in launch period for the spring launch we need to provide busy inputs to global product group for the autumn launch). Also the sustain phase if the cycle might be not that straight. Many times there can occur unusual situation- natural disasters causing stop ship, or different projects from other departments requiring complex involvement of the PLM, or simple reignite the business if certain product category is underperforming, or change of the strategy. On top of it, the essential customer, press events, fair trades, customer advisory councils which are fantastic opportunities for PLMs to collect first hand feedback , might occur in some seasons of the year more frequently, influencing also the line on the graph.
I slightly disagree with the graph above. I agree with regards to statement product manger should be spending time on preparing a vision, long term strategic view but I also believe that unless you have a product management function on the ground working with technical engineers who understand this vision, articulate it correctly, get features build as per the vision & unique value proposition of your product, you will not have a correct product.
Another thing your graph assumes that once vision is set you go into a waterfall development model which in my opinion is not correct. Product Management is trying to understand the market but we can’t give 6-12 months feature set to technical engineers as market keeps changing and you need to pivot/reevaluate what you have done so far as it is worth changing direction of your product.
So you need two product managers for your product, one that is responsible to strategic work and another who is working with technical person to fulfill that vision.
I think this chart can work with Agile and correctly puts strong emphasis on the vital commercial aspects of product management, devising and owning the business case, but also leaving space for a scrum product owner to understand and translate the business case into deliverables.
You are hundred percent right that the `ground work` is extremely important to come to an excellent product definition. You need to know where you are right now with your product offering, also benchmarked versus competition, if you want to define where you want to go with your next generation product. It is my experience that field application engineers, customer support engineers, service engineers have a lot of information related to the above and should always be involved. As stated in the blog, I try to avoid splitting up the strategic and shorter term `ground work` as too much information is getting lost in communication and often one needs to have the full picture, to detect small changes with huge impact.
As a long term product manager for Support, I can vouch for that a lot of the revenue related to a product, at least in the field I am working, can be related to services in the late stages of the life cycle. To make the most of that opportunity, product management needs to be looking how to capture this and work with the services organisation to address customers with the right offering. This is not really reflected in the red line above.