Product Management needs to tackle objections before they are raised at steering group meetings.

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 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.  

Product Managers need to help stakeholders define the problems as opposed to solutions

As a Product Manager I’m responsible for ensuring that stakeholders express their requests in terms of  business problems as opposed to a pet feature, so that their real needs are met  and do not get lost sight of when backlog items are aggregated into common themes as the product team figure out the best solution.

Albert Einstein said “If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it,”

Product Managers tend to spend a lot of time listening to internal stakeholder requests, from the business, as well as external stakeholders, customers and users. Ultimately product development needs to be driven by data: we know, from experience, that data beats opinions.   

Like all Product Managers I’ve experienced receiving pet feature requests from both external and internal sources.

I’ve had external requests usually via the sales team for a customer special e.g.:

“If you add an additional ad format then I’ll sponsor a channel”

and from internal stakeholder:

    “I want to display nonstandard content in the playlist player”

With respect to the internal requests the Product Manager needs to be able to help stakeholders express their requests in such a way that the underlying problem/user need is articulated as opposed to a solution/ per feature request.

This is how I helped one stakeholder change from a mind-set of requesting a list of pet features to identifying a list of business problems and user needs.  

• Prepare the way:  Before I’d received any requests I spent time understanding the stakeholder.  I discussed, in an informal way (e.g. at the cooler fountain etc…) what their aims and objectives were for the year, what challenges they faced, what their past experiences were.  In this instance the stakeholder was the web-editor and they were tasked with building audience and increasing traffic to the site.  I would use a slightly different approach for a more senior stakeholder but still prepare the way as early as possible. 

• Explain the problems with submitting a list of pet features as opposed to identifying the problem.  I explained to the web editor (who happened to be a new hire) that there was a constant stream of requests from several sources. Therefore their feature requests would most likely get lost when the product team worked on combining individual problems, on the product backlog, into common themes ready for a resolution. 

•  Set the context of their input- I explained that a feature fulfills a need and problem for the user.  We need to identify the users needs if we want to solve the right problems. I did this by quickly sketching out the ‘needs, feature, requirements’ pyramid.  

• Assist in re-framing each request.  I discussed each request in light of the web editors overall goal and helped him re-frame each one as a problem/user need, as opposed to a pet feature cum solution. I did this by using the card part of the user story:  “As a I so that .” After a few iterations we finally got there – there was a realisation that it would take a change in mind set. I then went on to explain that we were working at the Epic level which is akin to an individual scene in a film – as opposed to writing out the individual lines each actor would say in a particular scene.  

• Demonstrate the cases in point:  We eventually reversed engineered the list of feature requests into a list of business problems. I then picked a few problems and quickly sketched out 2 to 3 possible solutions to the defined business problem.  I did this, in a humble way, in order to illustrate the point that there are many solutions to any given problem and that the product team would come up with the final solution based upon aggregated problems (the big picture) as opposed to an individual problem (an isolated instance).   I also stressed the importance developing the product in such a way that the user has a consistent experience which would only be achieved if development was done with the big picture in mind at all times.  Which is the job of the product team.  

Once the requests were properly re-framed they were entered onto the backlog ready for prioritisation. See blog post: Process for Prioritising the Product Backlog

It goes without saying that different stakeholders will need to be managed differently: depending on their pay scale, personality and knowledge of product development. 

Hopefully this blog post will serve as a catalyst to help you think how to best go about changing the mind-set of the stakeholders in your organisation. 
 

Part #6 How Everyone Can Get Involved in Agile

I mentioned in an earlier post that I was adopting scrum (an agile development frame work). At first implementing scrum identified quite a few issues (mainly bottlenecks) with in the organisation. However the past few weeks have witnessed a turn around – all of a sudden it seems that everyone wants to get involved and be part of the scrum process.
So how do you (as a ScrumMaster/Product manager) broaden the influence of scrum so that all the product stakeholders have the opportunity get involved at the appropriate points in time?

1. Make it easy for anyone (Sales, Product Marketing, Information Architect etc..) to contribute to the product backlog. This can be done by placing the backlog on a shared drive or document management system. I’m currently using SharePoint 2007 as an interim solution before we implement Team Systems.


2. Communicated the dates for sprint pre-planning, sprint planning and reviews along with the start and end dates for the sprints.


3. Invite those stakeholders whose backlog item(s) have been selected (during the sprint pre-planning meeting) to the next sprint and the daily scrum meeting.


4. Invite the same stakeholders to the sprint review where the selected feature(s) will be demonstrated along with the other features.

Some may ague that all the business stakeholders should communicate their ideas to the product owner and he/she alone should attend the various sprint and scrum meetings. However it has been my experience (to date) that the product owners are often too busy (not to say that Product Managers/ScrumMaster are not). Therefore assisting the Product Owner by implementing the 4 steps above will go a long way to ensuring that your implementation of scrum will be successful. The one key point is to ensure that the product owner takes full responsibility for selecting and prioritising the product backlog items.

What direct reports and co-workers expect from a Lead Product Manager

In this article I give my take on Larry Bossidy’s article “What Your Leaders Expects of You” published in April’s Harvard Business Review and “..What is Expected from Product Managers..” Where I report what senior managers expected from me as their Product Manager.

Identify what your line manager, MD, and other senior stakeholders expect from their Product Manager is only half of the story. It is just as important to understand what your direct reports and co-workers in other department expect from you and work hard to fulfil them. I have seen a few middle managers become so focussed on keeping the chief executives happy that they forget, neglect and even ignore their direct reports and co-workers. Taking such a stance can only threatens ones future career prospects and hinder current performance. Colleagues may become resentful in going the extra mile.

My Take on Larry Bossidy’s article is as follows:
Provide clarity of direction: Understand what your reports have to do on a daily basis – lead, direct and as well as manage.

• Set goals and direction: Communicate their goals in the context of the goals of the team, group, department and company.
• Give frequent, specific, and immediate feedback: provide feedback in a timely manor and in context.
• Be decisive and timely: Do not delay in acting irrespective or whether the task is agreeable to our feeling or not.
• Be accessible: Try not to be so busy that you do not have time to sit down and have regular (ad hoc as well as official) catch-ups with your direct reports.
• Demonstrate honesty and candor: Be honest, upfront and direct but not blunt, rude or insulting.
• Offer an equitable compensation plan: Recognise and reward high performers.

Compare this academic report with a practical survey where direct feedback from Product Managers to their Lead Product Manager.

• Guidance on the company’s web strategy & how it applies to the online products I manage.
• Knowledge sharing of web strategy & new technology being used.
• Support in resolving issues & difficulties.
• Help in developing new skills and career.
• Fairly access performance & help improve it and processes & working practice.
• Leadership: leading the product manager(s).
• Performance appraisal on a regular basis.
• Training, coaching and guidance for my role of being a new Product Manager.
• Communication and direction given from higher in the food chain.
• Openness – easy for me to approach you regarding work and how my projects are going.
• Recognition of my contribution to department.

A comparison of the two lists highlights that both Larry and the Product Managers who report to me are saying similar things. The following are key point that co-workers expect from their Product Manager.

Feedback from Commercial Stakeholders

• Delivery to agreed timescales.
• Communication of any issues or risks with suggestions of solutions
• Innovative approach, always looking to improve process and technology
• Maintaining effective channels of communication with all key stakeholders.
• Be on hand to lend expertise regarding possibilities for advertising and development on the site.
• Keep team updated on any problems on the site that interfere with advertising or performance.
• Be the bridge between the commercial team and developers for site developments
• Keep me updated on development/deployments we’re requesting for the site and any delays.
• First point of contact for any technical problems on the site.

Feedback from Technical Team Leader

• Coordinating with the business and the development team to ensure that there is a common understanding of priorities.
• Collaborating with the development team leader to ensure that product managers, developers and business owners understand and accept their responsibilities as we proceed with implementing new processes (SCRUM).
• Performing the role of Scrum Master for a number of sites.
• Collaborating with the development team leader to manage the relationship between product managers, developers and the business.
• Contributing to the Release process when required.
• Infrastructure team aware of the importance of a particular release.

Different groups will expect different things from you. It is important to know who expects what and how you can full fill your co-workers and direct reports expectations. Failure to do so could not only threaten your current performance but stifle your career. However by asking the simple question “what do you expect of me” and making the appropriate adjustments could lead to increased performance resulting in an increased ROI and a greater chance of career progression.
What do you expect from your co-workers?