As a product manager I need to tackle objections before they arise at the product steering group meeting so that key decisions are made in a timely fashion.
The product steering group is designed to do exactly what is says on the can and that’s to give a steer to product management regarding the products direction.
It therefore stands that all senior stakeholders (those that could delay or prevent the product from being launched or a release going out) should be part of the steering group. From time to time, if the agenda warrants it, others may attend to give input. For example, leading up to my last product launch the Head of Communications was invited to attend so we could discuss the communications plan.
Ideally the product manager should chair the meeting, she/he needs to keep the group focused on the agenda, ensuring that the discussions don't go off on a tangent - if they do the product manager needs to pull the discussion back on track. One way to do this is to tactfully suggest the discussion continues when the group reaches the last agenda item: any other business. That said its part of the product mangers responsibility to preempt any objections or concerns, by being proactive and taking appropriate mitigating actions.
Here are three examples of concerns that I've experienced from various steering groups I’ve chaired; along with the actions I took to mitigate them. Mitigating actions were often a result of previous lessons learnt.
1. The Steering Group are not designers.
We've all had experiences where the visual designs are being reviewed and a senior stakeholder says something like "can't we move that button over to the left and move the ‘most popular’ module so it sits above the fold" etc... Design by committee results in what I call a patchwork quilt. Product design is the responsibility of the product team (Visual Designer, UX Designer, Tech Lead and Product Manager).
How the Product Management team can mitigate design by committee.
If they’re not already doing so I tend to get the design team to post hard copies of the designs on a wall (better still in a room) and then I, along with the Visual and UX Designers, will talk through the designs with stakeholders in an informal way. For example towards the end of a meeting I'll raise the topic of the designs and say "would you like to preview the designs" the fact that it’s a preview and done in an informal way helps mitigates against the stakeholder feeling that they need to make edits. Of course each stakeholder needs to be managed in a different way - some, for example a CEO, who has a design flare my need a slightly more formal showing. It’s wise to give this type of stakeholder one or two different options early on in the process before too much time is committed to producing wireframes or designs for every screen/page. The key is to show early and get feedback early. That way there are no surprises when designs are shown at the steering group meeting for sign off.
2. The steering group should not aim to do the architectural design
I've chaired steering groups before where there were a few stakeholders who had studied a technical unit or two on their advanced degree (MBA or MSc) or had a technical background. They could not resist showing-off their technical knowledge. That coupled with a previous migration project that was not future proofed, led to a level of distrust of the engineering team. This meant that steering group meetings became a platform for these stakeholders to air their frustrated technical views. (Note the company was in the process of looking for a CTO.) The result was diminished agenda items and therefore difficulty in driving through key decisions.
How the Product Management Team can manage stakeholders with partial technical knowledge:
I called sub meetings a few days prior to the steering group meeting and got the Tech Team Lead to give an overview of the proposed architecture at a level where all the semi tech savvy stakeholders could understand. He sketched the design out on paper - and handed out photocopies to everyone. I believe the rough hand drawn sketches gave a sense that he was open to suggestions. The stakeholders were always satisfied because they felt their voices where heard and they had the reassurance that all technical aspects had been thought through and the solution was future proofed. The result was that the semi tech savvy stakeholders went into the steering group meeting with a high level of confidence in the Product Management teams - they were onside.
3. The steering group should not determine how long development of features should take.
I've sat in meetings where senior stakeholders have strongly suggested how long a particular feature should take. This can be detrimental if either sales or marketing get the wrong impression which could lead to a premature sale or premature communications to external parties. The result is that the development team then gets put under pressure to drop everything in order to develop and release a feature so that the company does not loose credibility.
How the Product Management Team can prevent the steering group from estimating features.
Present well thought through release plans. Work hard outside of the meeting to determine the vision and priorities for each release and then present the release plans to the steering group for their sign-off. It also helps to circulate release notes so Stakeholders are able to compare what the product manager said would be released (in the release plan) and what actually got released. If there's a gap then give a brief explanation why.
Product steering group meetings are critical if the product management team want to streamline the number of meetings that are often required to get decisions made. Steering groups are a good platform for ensuring that transparency is maintained through out the product life cycle. That said it’s important that the product manager leads out and identifies and tackles objections before they are raised so that the air is clear for key product divisions to be made in a timely fashion.
"The smart product manager will have individually briefed the members of the product council prior to his/her presentation to learn of any issues and resolve them, so he's not caught by surprise." Marty Cagan
The product steering group is designed to do exactly what is says on the can and that’s to give a steer to product management regarding the products direction.
It therefore stands that all senior stakeholders (those that could delay or prevent the product from being launched or a release going out) should be part of the steering group. From time to time, if the agenda warrants it, others may attend to give input. For example, leading up to my last product launch the Head of Communications was invited to attend so we could discuss the communications plan.
Ideally the product manager should chair the meeting, she/he needs to keep the group focused on the agenda, ensuring that the discussions don't go off on a tangent - if they do the product manager needs to pull the discussion back on track. One way to do this is to tactfully suggest the discussion continues when the group reaches the last agenda item: any other business. That said its part of the product mangers responsibility to preempt any objections or concerns, by being proactive and taking appropriate mitigating actions.
Here are three examples of concerns that I've experienced from various steering groups I’ve chaired; along with the actions I took to mitigate them. Mitigating actions were often a result of previous lessons learnt.
1. The Steering Group are not designers.
We've all had experiences where the visual designs are being reviewed and a senior stakeholder says something like "can't we move that button over to the left and move the ‘most popular’ module so it sits above the fold" etc... Design by committee results in what I call a patchwork quilt. Product design is the responsibility of the product team (Visual Designer, UX Designer, Tech Lead and Product Manager).
How the Product Management team can mitigate design by committee.
If they’re not already doing so I tend to get the design team to post hard copies of the designs on a wall (better still in a room) and then I, along with the Visual and UX Designers, will talk through the designs with stakeholders in an informal way. For example towards the end of a meeting I'll raise the topic of the designs and say "would you like to preview the designs" the fact that it’s a preview and done in an informal way helps mitigates against the stakeholder feeling that they need to make edits. Of course each stakeholder needs to be managed in a different way - some, for example a CEO, who has a design flare my need a slightly more formal showing. It’s wise to give this type of stakeholder one or two different options early on in the process before too much time is committed to producing wireframes or designs for every screen/page. The key is to show early and get feedback early. That way there are no surprises when designs are shown at the steering group meeting for sign off.
2. The steering group should not aim to do the architectural design
I've chaired steering groups before where there were a few stakeholders who had studied a technical unit or two on their advanced degree (MBA or MSc) or had a technical background. They could not resist showing-off their technical knowledge. That coupled with a previous migration project that was not future proofed, led to a level of distrust of the engineering team. This meant that steering group meetings became a platform for these stakeholders to air their frustrated technical views. (Note the company was in the process of looking for a CTO.) The result was diminished agenda items and therefore difficulty in driving through key decisions.
How the Product Management Team can manage stakeholders with partial technical knowledge:
I called sub meetings a few days prior to the steering group meeting and got the Tech Team Lead to give an overview of the proposed architecture at a level where all the semi tech savvy stakeholders could understand. He sketched the design out on paper - and handed out photocopies to everyone. I believe the rough hand drawn sketches gave a sense that he was open to suggestions. The stakeholders were always satisfied because they felt their voices where heard and they had the reassurance that all technical aspects had been thought through and the solution was future proofed. The result was that the semi tech savvy stakeholders went into the steering group meeting with a high level of confidence in the Product Management teams - they were onside.
3. The steering group should not determine how long development of features should take.
I've sat in meetings where senior stakeholders have strongly suggested how long a particular feature should take. This can be detrimental if either sales or marketing get the wrong impression which could lead to a premature sale or premature communications to external parties. The result is that the development team then gets put under pressure to drop everything in order to develop and release a feature so that the company does not loose credibility.
How the Product Management Team can prevent the steering group from estimating features.
Present well thought through release plans. Work hard outside of the meeting to determine the vision and priorities for each release and then present the release plans to the steering group for their sign-off. It also helps to circulate release notes so Stakeholders are able to compare what the product manager said would be released (in the release plan) and what actually got released. If there's a gap then give a brief explanation why.
Product steering group meetings are critical if the product management team want to streamline the number of meetings that are often required to get decisions made. Steering groups are a good platform for ensuring that transparency is maintained through out the product life cycle. That said it’s important that the product manager leads out and identifies and tackles objections before they are raised so that the air is clear for key product divisions to be made in a timely fashion.
0 comments:
Post a Comment