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. 
 

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.

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.

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.

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.

Presentation on the Agile PM framework

I wrote a blog post about an agile product management frame work that I had put together in order to give guidelines to the product team and help improve the quality and accuracy of the information on the product roadmap, backlog and release plans. The blog post dealt mainly with the creation of the roadmap. The presentation below gives a high level view of the other elements of the framework.

Framework For Agile Product Management

View more documents from morrisond.

Agile Product Management Framework

There are many good product management frameworks available - however, I thought I would create an agile product management framework that is broad enough to be applicable to any product management groups that is practising agile/scrum. Each activity has an associated document that is vital for communicating to the various stakeholders. The first activity in the frame work is:

Product Road Mapping

I recently did a presentation on roadmaps at our monthly product manager’s forum and highlighted the following regarding product road maps:


A Roadmap is not:

1) A random list of features handed down to the product manager to document.
2) A roadmap is not a static document that stays at version 1.0 all year.
3) A secret hid away on SharePoint or some other document management system.

A road map is according to Marty Cagan of SVPG (product strategy in an agile world):
“A product roadmap is what describes your current plan of how you will get from where you are today, to the vision described in your product strategy.” Marty goes on , in the same article, and states that “The product strategy analyzes the market opportunity and the technology and describes a vision of what the product can be.” Therefore “The product roadmap describes the sequence of product releases to make the product strategy a reality” (the article goes on to say). The product strategy feeds into and delivers on the company’s business strategy.

Taking the above into account means that product managers need to have a firm understanding of the over all strategy of the businesses that they work in. The involvement in the business strategy will vary depending upon the company that you work for, but overall every product manager needs to have a clear understanding of the businesses they are operating in.

How to Create a Product Roadmap

• Understand the business strategy.
• Collaborate with commercial owners, sales, marketing, engineering and business development on developing product strategies to fulfil the business strategy.
• Research and come up with ideas and present to stakeholders and arrange a brain storming sessions.
• Collate the ideas and work up a strategic roadmap.
• Show the roadmap around and get buy-in from budget holders.

Using the roadmap as a communication tool.
It is absolutely necessary that product managers constantly communicate – the roadmap can be used as a good communication tool to commnunicate to:
– Developers, Test Analyst and the wider technical team.
– Your line manager and heads of departments
– Managing Directors and Chief Executives

Communicating the product roadmap demonstrates that the product has a clear vision of where it is planning to go and therefore goes a long way to building confidence at all levels.

Related Articles:

Implementing an Agiles Sales Framework

Part #9 The role of the Product Manager in Scrum

What is the job of a typical on-line Product Manager?
What’s Product Management is like a Year after Implementing Agile

What causes Product Managers to become disorientated?

Agile development gives the software product manager a good sense of orientation. Therefore it’s no surprise that when the development team steps away from using scrum or their preferred agile techniques things get a little disorientated.  I've observed this on two occasions over the past few years.

Totally moving away from scrum/agile
The first time was in the summer of 2007 when we where planning a major redesign of a B2B website. It was decided to take advantage of the redesign and upgrade our technology at the same time – in fact it was deemed pretty much a 'must have'. The development team had to carry out a number of research tasks and experiments on moving from .Net 1.1 to 3.5 and also on how to best build a reclassifying engine to automatically reclassify all the legacy content (some 50,000 articles) and then every new article that the editorial team would create from that point onwards. In hindsight it was a big mistake to allow the research to go ahead with out formally sizing and scoping it in pre-sprint planning. I had no way of knowing how things where progressing and when the research would come to an end.  XP identifies time boxed research as spikes .   

Partially moving away from scrum/agile
The second deviation from scrum occurred this year. At the beginning of 2008 we implemented a radical restructure that effected product management, test analyst and developers. The newly formed team had inherited a newly implemented platform, moved to a new floor and adopted new tools. Initially the new floor did not have the multitude of white boards that our previous floor had. This brought about a lack of visibility. Previously I could walk past half a dozen white boards and get a really good idea on the progress of four scrum teams with in my portfolio of products by looking at the list of impediments, the location of sprint tasks on the white boards and most of all the updated burn down charts.

Lesson Learnt
Irrespective of the work being carried out ensure you stick to your scrum cycle, estimate each task and keep track of progress using burn down charts. Failure to do so could cause you to become disorientated.

What’s Product Management is like a Year after Implementing Agile

It’s been over a year since the product management team went on a series of agile/scrum training courses. The transformation and associated challenges over the past 14 months have been quite interesting. Here’s a report on the journey, progress, issues encountered and experiences to date.

Product Management Prior to Scrum
Before agile working practices where adopted the Product Managers role consisted of a lot of short term tactical wins coupled with continual fire fighting. All this resulted in Product Managers being more reactive to situation as opposed to being proactive in delivering new products to market and improving on developing the feature set of their current product portfolio.

How Scrum was Implemented
The philosophy of agile was presented, by the IS Director and Head of Web Solutions Group - Kelly Waters (author of the blog 'all about agile software development'), over a 3 month period to various committees, steering groups and forums in order to get the by-in from Managing and Publishing Directors.

External trainers where also brought in and presented, to the MDs and the heads of Business Development and e-Marketing, the issues that companies face with software development and how agile/scrum could address the challenges we were currently experiencing.

Agile/Scrum Training
On-line Product Managers, Web Editors and Business Owners spent a few days on a scrum master and product owner’s training course. All Product Managers had a strong idea of the rudiments of scrum and a few where practicing elements of it. The training helped consolidate the principles of scrum within the Product Management team and helped gel a common high level theoretical understanding of the principles and vocabulary of scrum.

Problems and Issues
The real battle started after the training. Whilst some business owners embraced scrum others where less than reluctant to adopt or get involved. A number of open meetings were set up, with the product management team, where business stakeholders were free to ask questions and engage in an open debate regarding the pros and cons of adopting the new way of working. Product Managers also worked on a 1-to-1 basis to evangelize the benefits and to secure and maintain buy-in. Fortunately the Managing Directors fully supported the principles of agile – so inevitably business stakeholders eventually freed up time in their daily schedules to attend the 10 to 15 minutes stand ups each morning and a few afternoons every 15 days to participate in pre-planning, planning, reviews and retrospective meetings.

Identifying and Solving Problems
Implementing scrum did not solve all the company’s problems but went a long way to identifying many of them.

Problems with releases:
Increase in the frequency of releases identified bottlenecks in the resources used/alocated to carry out releases.

Managing the release problem
The Lead Product Manager’s implemented a ‘scrum of scrum’ where releases are put on a white board and at 4.30 every afternoon a Lead Product Manager or the Development Manger meets with the Product Managers who want to release the following day in order to set the release priorities based on business value.

Problems with Agile Testing
Test Analysts found it a challenge adapting to agile – I ran a few sessions with the Web Solutions Group Management team and all the Test Analyst from across the department. Many issues where down to a change in test working practices. No longer did the Testers have a fully documented technical and functional spec to work with. Read Part # 7 Points to watch out for when converting from waterfall to agile testing for more details

Solving the Agile Test Problem
The Test Analyst were sent on Scrum Master training courses, the analyst aspect of the test function was highlighted and the Test Analyst are now given the formal responsibility for gathering and documenting the test cases during pre-planning. The test cases are presented to the customer(s) during the planning meeting in order to get their formal feedback and sign-off. This has formed part of us adopting agile engineering practices and therefore a 'kind of' manual' test driven development.

Return on Investment (ROI) and improvement in quality using Scrum
Just prior to implement scrum I had finished managing a project (re-design of a B2B website). Six months afterwards I worked on another redesign of a B2B website that was more feature rich and technically challenging. However this time I used scrum to manage the project the number of man hours was reduced by 35% and went live with 4 known minor/low bugs – with in 2 hours of launching we discovered 2 bugs that did no show up in our test or UAT environments – both bugs where fixed within a matter or hours.

Product Management Post Scrum
Implementing scrum has resulted in Product Managers being able to be more proactive and think and act longer term. Sure there are still issues with fire fighting and predicting the exact date and time of a release - however the overall negative situation has diminished considerably since the organisation has embraced agile working practices. The profile and trust of the Product Management team has also increased – many act as proxy product owners and are involved in defining features and working along side business owners in making decisions, identifying opportunities to improve the product feature set and advising business stakeholders on a host of different tactical and strategic issues. See:
Part #9 The role of the Product Manager in Scrum
and
What is the job of a typical on-line Product Manager?

Ironically the few business stakeholders who where sceptical about embracing agile are now some of its greatest exponents .

Product Manager adopting web2.0 agile software development

In the world of web development online product managers have two choices big bang (probably using waterfall) Vs incremental redesign (and empower product development) of the websites their responsible for. The world of online moves at such a fast pace that by the time you carry out your research, then work with an analyst to document your findings in the form user requirements and then design and build your website (or online product) and then launch/re-launch it, the original research is in danger of being out of date or put another way superseded by some new online fad. This means that you’re in danger of being in decline before you’ve had the opportunity to experience growth and maturity. In my opinion a combination of adopting agile software development (such as Scrum) along with web 2.0 technologies and mindset (i.e. perpetual beta) coupled with taking a brave decision to develop a new home page whilst leaving the rest of the site as is and then asking for user feedback via your web site has got to be the way to go. The most recent site to do this is the BBC.co.uk.

Opting for incremental raises a few questions for the online product manager.

#1.Will changing and releasing just the home page of a site confuse the users?
#2.Will internal stakeholders adopt the perpetual beta approach?
#3.What do you do if the users make suggestions that go against your company culture for your online product?

I’d value your feedback on this subject.

How Product Managers can estimate business value using agile techniques

We recently finished a scrum sprint; during the sprint review the technical team gave a demonstration, to senior business owners, of the newly developed functionality and bug fixes they had done during the sprint. It was noted at the sprint retrospective and subsequent discussions, that followed, that the demonstration gave equal weighting in terms of the time spent demonstrating each user story. However some stories were minor bug fixes while others where major enhancements to the site's home page. The question is how does the technical team know how much time to spend demonstrating each user story?

One way would be to demonstrate the stories in priority order. However this would just give an order for the demo and not a give any indication on how much time should be spent. I believe one way would be to introduce an estimated business value to each story refer to Measuring business value with metrics for more details. The technical team are quite used to using Fibonacci numbers (1, 2, 3, 5, 8, 13, 21 ...) to estimate the complexity of a given user story and the product owner and other business stakeholders are accustomed to watching the technical team use the poker cards to vote on the complexity of a given backlog item and then witnessing the team member who gave the highest vote discuss with the team member who gave the lowest vote the reasons why they voted in that particular way. The team then votes again based on the new information they have heard.

A way forward would be for the business stakeholders to go through a similar exercise. The business value would depend on the type of product you are developing. For community website the following could be considered: Search engine optimisation (SEO) value; improvement in usability or user engagement; third party sponsorship generating direct revenue; improvement to backend editorial systems that increase efficiency and through put; automating processes for editorial staff….

Once a business Fibonacci has been given it will be a simple exercise for those demonstrating newly developed functionality and bug fixes to give the correct weighting in terms of time to each user story – thus keeping the review fresh and relevant and ensuring that business stakeholders stay engaged through the session.

However there is a much better reason for estimating business value for each backlog item – it not only helps with setting priorities but can be used to measure the amount of value and therefore ROI for each sprint and ultimately be used to calculate business velocity in a similar way that the scrum master calculates technical velocity for a team or individual. Estiamting business velocity, (refer to Understanding your Velocity for an explanationon on velocity) will also give the product manager and product owner a high level indication on the amount of business value that a team are able to generate for each product roadmap.

How Product Managers can push back at an interview

Interviews are about persuading the interviewer(s) that you are the right person for the job. That you will be able to deliver the goods even when the going gets tough. A question that I like to pose to perspective Product Managers to determine if they can deliver in the face of adversity is:

OK here's the question - followed by a possible answer:

"What would you do if you were invited to a high level business meeting with the Sales Director, Head of Business Development, Director of Product Marketing, CEO and other senior stakeholders… The Head of Product Marketing gives a power point presentation on a new (on-line) product. The presentations concludes that the launch, of this new online product (that by the way is nothing like the company has done before) will be launched in three weeks time. After all, the CEO says, it's just another website."

What the interviewer(s) are looking for:

#How would you, as the product manager, manage upwards?
#Do you have the product management skills to communicate at the CEO/MD level?
#Are you able to push back in a diplomatic way?
#Are you able to manage expectations?

Suggested thoughts that need to be projected are as follows:
It’s important to be in tune with the commercial aspirations of chief executives and senior stakeholders. You need to demonstrate that you share the vision and will be an asset and not an obstacle to achieving the ultimate goal. However – and here comes the but – BUT you need to be able to positively steer the thinking towards realistic time frames and firming up on the unknowns [power point presentation are generally shallow]. Details need to be properly defined – here you have the opportunity to demonstrate [to the interviewer]:

• your skills in creating a road map –


• that flows into a project backlog –


• that divides down into a set of user stories -


• that can be estimated in terms of complexity and


• time to complete.

Sets of user stories can be grouped together as themes for a programme of sprints which will eventually give a picture of the size of the project. If your more acustom to a water fall enviroment then talk in terms of product plans etc...

Once all of this has been thrashed out you then have the ability to communicate high level estimates for the project and give feedback to the senior stakeholders. This then opens up another round of discussion regarding resources for the project:

• Who? (permanent or contract),


• When (do you need technical resources to assist in the research if research is needed) and


• How much does will it cost (different organisations have different approaches to recharges – central departments or each business unit having their own development team(s).

Ensure that you demonstrate your ability to balance your business and commercial acumen as it’s the combination of 'business sense and technical sense' that makes a good product manager. Remember organisations (and therefore processes) differ one from another - the interviewer will understand this - so it's the logical thought processes and stakeholder management skills you show when answering that determine if you give a satisfactory answer or not.

How to become a Product Manager

Continuation of the interview with Paul Young
What advice would you give some one who wants to move into product management?
Product Management is unique in that there isn't a well defined career path for a product manager, unlike operations or marketing. I don't know a lot of people who have intentionally sought out Product Management as a career, most people I know have "fallen into it." My best advice is to find a smaller company that is thinking about starting a Product Management group - it may be easier to break into than a large company. I also feel that being well rounded and having good business fundamentals are key.

If you're a developer, find some way to demonstrate your business savvy - you could even do this in your current job. Surprisingly few developers are "in tune" enough to understand the business and provide good trade offs; I'm dying for programmers who can tell me "I understand you want X, but how does Y work for you, it gets you feature a, b, c (but not d), at half the cost and time, and sets us up architecturally for the future." Instead of: "That feature will take 24 months."

If you're currently in a marketing or operations position, demonstrate that you can "speak geek." Since Product Managers are required to regularly interact with and negotiate with development, you need to be able to show that you have the street cred with the developers and that they're not rolling their eyes as you walk out and muttering "marketing idiot."

What is the job of a typical on-line Product Manager?

What’s the job of the Product Manager in a cutting edge web development environment? What does the typical diary of today’s web and/or software Product Manager look like?

Product Management business as usual (BAU) activities in scrum.9.30am attend the daily scrum meeting (stand up) with Engineers, Test Analysis. Depending on which functions are being discussed a representative from Sales, Product Marketing, e-Marketing and Usability may be in attendance - after all good Product Managers get everyone involved in the agile process . Identify progress, update the burn down chart and begin to remove those impediments – the usual activities of a typical scrum master. The above should take around X hours.

Product Management and product planning activities.Spend X hours in meetings and ad hoc discussions with business owners in order to get the backlog in order for the next sprint. This will include reviewing backlog items (enhancements, features and bugs) that have been reported by business and technical stakeholders from across the organisation. It’s essential that the backlog items that will be selected for the coming pre-sprint planning meeting are reviewed and that business stakeholders ensure that they are not so fuzzy that the Engineering team are unable to make sense of the individual requirement. In some cases the stakeholder who raised the backlog item will be invited to the meeting to answer questions – however the Product Manager needs to ensure that the stakeholder has a clear view in their mind of what they are requesting - comment like it doesn't work helps nobody!

Product Management Strategic direction
Spend X hours working with senior stakeholders reviewing the product roadmap, reviewing what the competition are doing, discussing any new ideas that may have been put on the backlog and brain storming on any new innovative ideas (making sure they avoid the innovation trap) that have emerged since your last meeting. The result is an adjusted roadmap that feeds directly into the sprint calendar.

Product Management team building and re-charging activities.Meet with fellow Product Managers and discuss what’s happening in their world: what issues they’re facing – can you help them in any way shape or form and vice verse. What items do they have on their backlog and road-maps – is there any synergy in pooling resources to build features that are common to both product teams if so get buy-in from the appropriate holders: team leaders, development manager or business owners (if they are re-charged for the technical resource).

Feedback on performance of the product.One of the key applications for the online Product Managers is a web analytics tool such as Hitbox, Adtech or Google Analytics. So it is essential for the Product Management team be fluent with the use of these tools to be able to measure the success (or otherwise) of online products and the effect of releasing new features and enhancements onto the site. Product Managers need to Listening to the Voice of Customer with Web Analytics.

Routine tasks of the Product Manager.The tasks above don’t include dealing with the dreaded email inbox, fire-fighting issues as and when they are reported, chairing the sprint pre-planning meeting, sprint planning meeting, retrospective and review. That’s not to mention driving the release of the new features through the various processes in order to ensure that the release goes out on time. If your having problems getting through those routine tasks then you'll do good to invest 30 minutes listening to Brian Lawley podcast "How to Get Twice as Much Done in Half the Time".

Product Managers need to get the right balance by measuring and monitoring X hours.

It’s essential for Product Managers to get the right balance between the above activities in order to avoid perpetual fire fighting. Dividing your time across key activities is a fine balancing act at the best of time. However knowing how much time and energy to spend on each activity is dependent upon each Product Managers individual circumstances. One thing I would say is that quality time and energy has to be spent in creating and maintaining product roadmaps – feeding the vision of the roadmaps through to product planning and eventually into sprints that end up being new features and enhancement released onto the web site.

The sooner this type of cycle is established then sooner the Product Manager can break out of the perpetual fire fighting and help desk mode.

The pragmatic marketing group have produced a marketing framework to aid Product Managers get the correct balance between tactical and strategic activities.

Part #10 Justifying Time to Research with Agile

Agile Research

I worked for a company that designed and manufactured niche signal processing equipment for the broadcast industry. Part of the secret to the company’s success was that it was not shy in investing significant amounts of revenue in a research department as well as allowing its engineers to carry out their own research projects.


In my opinion all technology companies need invest in research, but think about adopting some agile principles in funding research to ensure that time can be traced and that the business gets a good return on investment (ROI) for research that has been untaken. Here's my list of five potential things that you can adopt when thinking about trying to find time during your busy day to justify time to carry out research.
#1. Identify areas that require research and build it into the sprints backlog.
#2. Ensure that product managers have time to research so that they are up-to-date on the latest widgets, gadgets and technologies. Product management research will not be part of the backlog but nonetheless the research needs to be done in a time-boxed way. It may be an idea to set your self a research goal for each sprint (using the start and finish of the sprint as time markers).
#3. Give time for the engineering team and product managers to formally report back on what they have researched.
#4. Take note of any newly introduced functionality or enhancements that comes about as a result of the research that has been carried out.
#5. Track the benefits (in terms of increased traffic to your website - equipment sold because of the additional feature etc…) and therefore prove business benefit and therefore ROI.

For more on this topic read: Innovating in Large Companies which encourages us to spend 20% of our time in research and innovation.

Part #9 The role of the Product Manager in Scrum

Scrum has three key roles:
#1 The team – who owns the sprint backlog and are responsible for estimating. functionality and fulfilling the commitment made at sprint planning meetings.

#2 The Product owner – who owns the product backlog and decides on product functionality.
#3 The scrum-master who owns the impediment log and is responsible for removing any blockages that hinder the team from performing and fulfilling their commitments.

So what's the role of the Product Manager in scrum?

Alyssa S. Dver writes in her book: Software product management essentials that: “The job title of Product Manager is vague…. Sometimes the Product Manager is the business owner. Some companies view Product Managers as the liaison between Sales and Engineering, helping to define and refine product requirements and specifications.” Other companies use Product Managers as the scrum-master in addition to being a liaison between the business stakeholders and technical stakeholders.

The software and publishing companies have different stakeholders who are responsible for profit and loss (P/L), user experience etc… If this is the case then the product owner (who sits on the business side of the fence and is responsible for the P/L and/or the user experience) should be the person in charge of defining the product and the Product Manager can facilitate the discussions and decision between the team (technical stakeholders) and the product owners (business stakeholders).

I tend to view the different roles in scrum as an allegory to help me consolidate the lines of demarcation:

#1 The team is the Rock band – people pay to attend concerts to see and listen to the rock band.
#2 The product owner(s) are the fans – who pay to attend concerts, pay for the music and therefore ultimately determine what music is popular and what music the band plays.
#3 The scrum-master is the bouncer cum manager – they protect the band from over enthusiastic fans, make sure that no harm comes to them – book the gigs and makes sure that the band turns up on time.

So if your a Product Manager in a company who is about to implement scrum you need to ask yourself if what you do ultimately determines what music gets played or do you make sure the musicians play the right music. The answer to this question will determine if your the product owner or scrum-master or even perhaps proxy product owner.

See also:

How Agile is your Product Management

What do Product Managers do?

How everyone can get involved in agile

Part #8 Tips on being an Agile Manager

The agile manager must be able to constantly inspect and adapt in order to keep pace with a changing environment and capitalise on the changes as they occur. Here are 6 tips on ways in which you can inspect and adapt in order to improve the agility of your management and/or Product Management.

Inspecting:
#1 Agile managers tend to have an understanding of what is coming up – this occurs either by information that is cascaded to them from the board or Chief Executives or by anticipating future directions of the company and/or the market place.

#2 Agile managers seek to know the 'strengths' and 'areas that need improving, (weakness) of their team and the teams they work with - whether it's a virtual team (if they are matrix managers - as in the typical agile Product Management role) or those who directly report to them.

#3 Agile mangers strive to be better thinkers: they have the capacity to hold two opposing ideas in their head at once and then be able, creatively, to resolve the tension between those two ideas by generating a new one that has elements of the others but are superior to both.

Adapting:
#4 Agile managers are adaptive managers, they put people before ideas – they value people and ensure that they are placed in the best position for them to succeed.

#5 Agile managers adapt themselves and their programme to ensure that they remove the obstacles that are either slowing down their team’s performance or preventing them from achieving company goals.

#6 Agile managers find out what their teams expect of them and they ensure that their teams know what is expected of them – they then seek to remove any areas of potential conflict between the two in order to ensure that there are no areas of ambiguity.

The world, the markets we operate in, the companies we work for are constantly changing – the agile manager must constantly adapt themselves and their teams to ensure that they continue to function successfully in the constant changing and turbulent environment.

Part # 7 Points to watch out for when converting from waterfall to agile testing

Agile can be a challenge for the Test Analyst who has been trained and is accustomed to working in the traditional waterfall, Prince 2 environments or using the V model. A tester who finds themselves as part of “the team” using the agile scrum frame work can find that they are out of their comfort zone and may feel a little exposed. We recently held a meeting with a group of Test Analysts and asked them to identify what areas of our scrum implementation the needed to be improved and what areas they thought were going well. The key points identified are listed below.
Possible areas to Improve
50% said there were:

• No proper test management processes.
• Not enough sharing of information across the different groups (group = testers, product managers and developers).
• No re-use of test scripts across the different on-line products using the same backend systems.
• 25% said that:
• Being left out of emails containing relevant information to the sprint.
• Changing requirements half way through a sprint and not being clear on the actual change.
• Test work not being prioritised enabling the tester to know what order to test tasks in.
• Tester work is 1 to 2 sprints behind the development. (....Need to read the what done really means)
• 100% stated that:
• There was a lack of written requirements to test against, not enough detail in the requirements resulting in no real understanding on how a feature should work. Also a lack of forethought on features causes problems later on in th sprint.
• No formal tracking of defects: only the tester is using the defect log and changing the status.

Areas that are going well:

• 100% agreed that:
• Definition of sprint cycle.
• Sprint planning and pre-planning meetings.
• Communicating daily with developers.
• Good visibility as to what is coming up .
• Agile process being well implemented- everyone understanding the business benefits of agile.
• 75% agreed that:
  Close working with developers and business owners
• Good use of the impediment log
• Agile process being well implemented: everyone understanding the pros and cons of agile.

Tips for those new to the test agile role

If your thinking about joining a company, as a tester from a waterfall/Prince 2 background, that works in an agile way or your current company is planning to implement agile then I would recommend that you think about the following:

1. Make sure that you attend the sprint planning meetings and wear your 'Business Analyst' hat – make sure you gather requirements that will enable you to write short test scripts and therefore test each backlog item and task. If need be arrange (with the Scrum Master and Product Owner) a follow-up meeting to clarify the requirements.


2. Don’t be shy in raising impediments – it’s the Scrum Masters job to ensure that all impediments are removed so that “the team” can successful carry out their work. Impediments can include "I need more details on how this function should work."


3. Review, on a regular basis, the product backlog and create and maintain a query log that maps each backlog item – this will help you when your in the sprint planning meeting to ask the right questions at the right time.


4. Keep a defect log during each sprint - add those defects that are not cleared at the end of each sprint to the product backlog.
   

See also:
Agile Testing is not for Dummies
Agile requirements are barely sufficient!
Agile Testing
Why Testers should be in at the start

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.

Part #5 How to adopt Agile Product Marketing

The Agile Product Manager works closely with the engineering and technical teams working with in an agile framework such as scrum. The adoption of an agile methodology means that new features will get delivered incrementally every 30, 20 or even 10 days. This is great news for the product owner who sees the product developed and released incrementally (with in a matter of weeks as opposed to months) and gives them the ability to change priority and the features depending on the demands of the market-place. However this can prove a bit of a challenge for the Product Marketing Manager who works closly with the Product Manager and is tasked with communicating product features to the outside world. How do you best communicate product information to outside audiences in an agile way ? Ensuring that you are getting the best kudos for the efforts you put in. Here are seven tips for the Product Marketing Manager who find themselves responsible for marketing products that are developed incrementally in an agile frame work.

1. Review the product backlog and create high-level marketing material based on each product backlog items.
2. Contribute to the product backlog.
3. Meet with the product owner and discuss the priorities for the next sprint.
4. Attend the daily 10 minute stand-up sprints meeting (especially the ones toward the end of a sprint) so that you get periodic updates on what is going on.
5. Attend sprint review meetings so that you get a demo of the newly developed features.
6. Review product roadmap with product owners and scrum master and discuss which sprints (and dates of the sprints) will cover which high-level features that have been sketch out on the road map.
7. When publishing hard-copy material ensure product features are explained at a 'high level' and publish the 'detail' on-line.

The Product Marketing Manager like the Product Manager is duty bound to adopt an agile approach to work in-order to secure the competitive edge for both the product they are marketing and for their own career aspirations.

Read also Agile People Working in a Non-agile world
and Implementing an Agile sales framework