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.  

Read More

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. 
 

Read More

Process for Prioritising the Product Backlog

I’ve spent the past year bringing a new product to market, as a consultant Head of Product for a start-up business unit that’s owned by a multi-national. I had the opportunity to pretty much start at the beginning: pulling together the vision, setting up a product council/steering group, talking to users about the initial concepts and shape the overall product direction.

After launching V1 of the product I ran a number of prioritisation meetings with key business stakeholders.

I’ve chaired and been involved in many different types of prioritisation meetings before. Somewhere there were up to 12 frustrated web editors (who managed sites where advertising was the major revenue stream) all had to bid for a slice of the scarce development resource. Prioritisation was done purely based on revenue: those sites whose demand for inventory was higher than what they were supplying won out.

Other prioritisation meetings comprised of me (the product manager) having to present and persuade senior stakeholders of the validity of a pre-prioritised backlog and drive consensus.

 Recently I decided to use the following process to not only prioritise the backlog but to aid in building unity among a group of stakeholders and win their confidence and trust:

1. We agreed on the goal for the next quarter – in this case it was to build our user base as opposed to driving revenue. A hard sell for an ad funded business. 
2. We went through the backlog and as a group agreed on the category of every item: User engagement, revenue, contractual, audience, acquisition etc... Most where no-brainers,  but the key was that the group felt that it had categorised the backlog. 
3. By common consent a champion was assigned to represent each backlog item (represented in the meeting was: Heads of Marketing, Ad Operations, Head of Product, Tech Team Lead and the MD/General Manager of the business unit). 
4. The champion would then give an elevator pitch on the importance of their backlog item followed by a brief Q&A cum discussion. 
5. We would then vote (in the same way you play poker in scrum) on how the item would best fulfill the goal we all agreed on. Each score is then entered into the spread sheet. 
6. When we get to the end of the backlog click ‘sort’ and hey presto we have a prioritised backlog.

Everyone embraces the outcome because: they participated, there was total transparency and we all bought into the goal for the coming quarter.

Finally I would present the prioritised backlog to the product council/steering group – in general it’s well accepted because either those present participated in its prioritisation or one of their subordinates was involved and reported back to them.

The quality of the prioritisation is directly related to the product manager’s ability to keep everyone on track, focused on the agreed goal as you vote on each backlog item.

Read More

Getting to the Top in Product Marketing and Product Management

I came across this video on Youtube and found it quite inspiring so I thought it was worth sharing.  The introduction on what is product management/marketing is quite succinct and bang on target.

Many of the points resonated with me especially the frequent referrals to the importance of the customer in developing your product offering.  Hope you enjoy :-).

Read More

Meet the Product Manager

What do you do when you’re a product manager (for web applications and tools) who has started a new job, assigned to an existing team who are just about to embark on the development of a range of new products and product features? We’ll whatever the correct answer is, this is what I have started to do. The first step I took was to review the situation and give the team the opportunity to voice their opinion.


I soon realized in my first week in my new role as product manager that there was plenty of scope to improve a number of aspects of the product development process. We are currently using a hybrid of Scrum and waterfall (the logic behind this will form the basis of a later blog post). I waited for all the team members’ to return from their holidays before holding a team meeting that I tagged “meet the product manager”.

I introduced myself as a product manager who ‘eats their own dog food’ – in other words I’m an active user of online tools, blogging platforms, social media and networking sites.

I also took the opportunity to let them know the things (from a professional perspective) that I’m passionate about:

• All things to do with Product Management/Marketing.
• Working with engineering/development teams and cross functional teams.
• Agile software development particularly, scrum.
• Creating strategy and visions and driving them through all the stages to completion.

The things that I’m not passionate about – in fact the things that we should, as a team, avoid at all cost. See the familiar cartoon strip below.

I followed this with a case study: comparing two redesign projects that I was the  product manager for.  One using waterfall which had a shared test resource and the other using scrum with a dedicated test resource. The results were alarming. The waterfall project took +60% more man hours and went live with 100 plus small and medium bugs, whilst the redesign, that was developed using scrum, went live with 4 known minor bugs. I used this experience not only to demonstrate my active involvement in scrum but to illustrate the type of transformational product development we can achieve if we work closely together and use the scrum frame work wisely.

I highlighted that as the scrum product owner I would initially be spending a lot of my time and energy  over the next 4 to 8 weeks, developing: in conjunction with the business owners, commercial owners and other senior stakeholders, the product strategy, product roadmap and release plan - the end result being a backlog with at least 6 to 18 months worth of work in it. Naturally the backlog would need constant grooming as coarse grain items become high priority.  I would also naturally be on hand on a day to day basis to support the team and work with the scrum master to remove impediments

I then handed out post-it notes and ask the team to write on each note their likes and dislikes and also to introduce themselves e.g. where they've previously worked, what they’re passionate about, hobbies and interests…

One of the key messages message that the scrum training drummed home to me when I was first trained on the scrum framework was that scrum does not solve problems it only identifies them. However scrum, if practiced appropriately, will make change and tracking and tracking the results of change much easier. Here are the top three likes and dislikes the developers highlighted.

Dislikes:

1. No dedicated  full time test analyst, not using  automated test tools; the team failing to carry out unit testing and code reviews.
2. Changing requirements /scope creep causing work to be either wasted or having to be reworked.
3. Opinions of the team not always being embraced when it comes to decisions on functionality.

Likes:

1. Knowledge sharing among the team – experience and ideas are traded freely.
2. The fact that we use scrum/agile – the team liked all aspects of scrum especially the ability to select tasks on a daily basis.
3. Product Manager being part of the team as opposed to being absent (note complement was aimed at the interim contract product manager cum technical team leader).

My job as product owner aka product manager in conjunction with the scrum master aka technical team lead – is to ensure that the team is empowered to change those things that we have the power to change. Understand and communicate the reasoning behind the things that we can’t change and be patient with the things that will take time to change.

I said to at the beginning of this blog post that the first thing was to review the situation and give the team the opportunity to share their thoughts – the second thing I’ll do (and publish the results in a future blog post) is to survey the team to see how mature they are with regards to practicing scrum.

Read More

Combining Classical and Agile Product Management

I was asked to present, at an interview, on how I see the role of the product manager working in an agile scrum environment. The key areas that I highlighted were:

• Scope and responsibilities of the product manager in scrum
• Typical product management activities in scrum
• A typical day in the life of the agile product manager
• The agile product management framework
• A case study – the benefits

See full presentation below.

However since the interview/presentation and starting in the new role the company has decided to change direction and combine waterfall with scrum. The idea is that we start off in waterfall mode move into scrum and then finish in waterfall.

Since joining the first thing I noticed was that the current scrum team is being led (as opposed to the team self managing itself) by a contract technical team lead cum product manager who spends part of his time being the scrum master and part being a business analysis.

In order to bring clarity and set expectations from the start I went about working with the head of development and head of product management to define, at a real granular level, the scope of the product manager aka product owner and that of the scrum master who is currently the technical team lead.

The end result was a list of 90+ activities: starting off with documenting the product vision and ending in the release of a sprint. The activities combine classical product management with agile product management – a real hybrid taking the best of both worlds. The roles and responsibilities matrix was signed off by both heads – now the journey begins.

Next week I meet with the development in order to explore the journey we’ll take together in developing the products allocated to us.

How I See The Role Of Product Management

View more presentations from Derek Morrison.

Read More

Product Management interview question on strategy and tactics

I was being interviewed for a Product Managers position by a Chief Operating Officer (COO) who used to do the job that I was interviewing for. The company has adopted and really embraced scrum so naturally expects the Product Manager to take on many of the Product Owners responsibilities. I ask the COO to broadly split the role down into three aspects. His reply was:
1. Vision and Strategy
2. Execution and delivery
3. Stakeholder management and collaboration

I jotted the above answer down on my note pad. He then asked me “what percentage of my time I think I would spend on each of the above three activities.” I paused for a second – gathered my thoughts and jotted figures next to each one:

1. Vision and Strategy – 20%
2. Execution and delivery – 40%
3. Stakeholder management and collaboration – 40%

Fortunately for me he agreed.

I often hear and read of Product Managers and Product Marketing Managers stressing at their yearly appraisals that they get too bogged down with the tactical and have no time for the strategic and visionary part of the job. The problem is that if you don’t use it (the visionary and strategic thinking) then your loose it. Amy C Edmondson in HBR puts it this way:

“Execution is difficult to sustain – not because people get tired of working hard, but because the managerial mindset-set that enables efficient execution inhibits employees’ ability to learn and innovate. A focus on getting things done, and done right, crowds out the experimentation and reflection vital to sustainable success”. Harvard Business Review July – Aug 08

Correct implementation of the Scrum process aims to solve the problem where the Product Managers/ Product Owners gets burned out due to “efficient execution” and a sharp focus of “getting things done” and “done right”. A Product Manager/Owner knows the cycles of the team and can therefore plan his/her work in advance. The key is to ensure that there is a well balanced Scrum team. I like the way Marty Cagan puts it:

“You will need product managers to represent the needs of your target users and lead the product discovery effort. You probably already have project managers (aka Scrum masters), but if not, you’ll need product managers too; just don’t make the mistake of trying to hire one person to cover project management and product management.” (italics supplied)

It’s important for each product person to deliberately carve out time for themselves to do activities that will be the catalysed for strategic and visionary thinking. Such activities would include (but not limited to): visiting customers, researching the marketing and competition, discussions with the development team on the latest and greatest technologies as well as discussions on how existing technologies can be used in an innovative way, looking at how other industries (current and past) have solved problems. When I led a team of product managers – I gave them one day a month to spend out of the office in order to research what ever they wanted – all I asked in return was for a one line explaining what they had discovered. The key is not to get distracted by too many tactical things – hence the one day out of the office: Tom Grant Forrester analysts expressed it this way:

“Product Managers need to focus on the strategic inbound tasks instead of being distracted by too many tactical demands… companies need to hire or cultivate product managers who have the skills and experiences necessary to produce high-quality product management deliverables – not something that anyone can do with out training”

Tom continues by identifying the benefits of ensuring that Product Managers spend quality time on vision and strategy activities:

“Companies that make these product management reforms will be more competitive and better able to use product management deliverables to make better strategic decisions.

In short it’s a win: win situation for both you and the company. So we product people need to take the time to develop ourselves and companies need to give us the time and ensure we have the band width to do it.

Read More