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.

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.

Interview with a Pure Product Manager

In this audio interview I speak with the author of the blog Purist Product Management: Aziz Musa. I had the opportunity to work with Aziz for a year at Reed Business Information and found him to be an inspirational and focussed product manager. During the interview I review Aziz’s:

  • academic and professional background before becoming a Product Manager;
  • his experiences at Last Minute.com;
  • the strategic element of the job;
  • how best to interact with the customers;
  • the optimum number of products a typical Product Manager should manage;
  • how to keep up with the latest trends and technologies and
  • the top 3 attributes needed to enter the Product Management arena.

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.


Advice for up and coming Product Managers


I received a phone call at the beginning of the year from PM magazine. They wanted to interview me on my thoughts on how young members of a product team could grow in their careers. The questions they asked along with my answers are as follows:


1. What can young project team members do to climb the learning curve, make an impact and stand out in the eyes of their managers?
Make sure that you deliver your tasks on time. If you have any doubts or are not sure on any task be sure to get clarification well before the deadline. Develop a thirst for understanding what drives the business and what the technical drivers are for the projects and/or products that you are assigned to. Be sure to ask for feedback, analyse it and immediately and act on your findings.


2. What's the best way to "sell" yourself and your abilities to higher-ups?
Ensure that you have a proven track record for delivering.
Read good website and blogs on topics that your line manager is interested in – participate in forum discussions – use tools like Yahoo answers and the Q&A sections of Linkedin. Use applications like google alerts or an RSS reader to automatically capture articles on relevant topics – then periodically send your line manager links to articles that they are interested in along with your analysis on the topic and how it can help the products and projects that you are both involved in. Be sure to be able to demonstrate that you can converse confidentially and in an informed way on the topics that matter to them and their career.

3. What should you look for in a mentor? Any downsides to being part of a mentor-mentee relationship?
Look for someone with good people skills and that has your interest in mind – someone who likes to help people. Be sure that they are an experienced professional and understand human nature. It’s also important that your mentor has a successful track record.

4. When is the right time to ask for new duties, more responsibility or even a promotion? How do you let them know you're ready?
Ask for new and additional duties once you have proved yourself with your current responsibilities. Be sure to let your line manager know that you are seeking for additional challenges that will stretch your abilities. Create you own personal roadmap (that clearly identifies your career aspirations) show it to your line manager at the beginning of the year and ask for their input and advice on how to progress. Most companies have periodic reviews – use this as a time to discuss where you see yourself in 2 to 3 years time and the steps you plan to take to get there. Based on this be sure to let them know where you see yourself in the next 12 months.

5. Under what circumstances is it wiser to be patient and wait for another time to seek greater opportunity?
When things are not going well – at times projects will not be going well and the reasons may be outside your sphere of influence – it’s best to get a number of wins under your belt first before seeking greater opportunities. Whatever the situation your request should not come as a surprise to your line manager.

6. If applicable to your situation, how do you handle being younger than people you're supervising or leading?
I think that capabilities and experience are more relevant than age. I manage those who are just as capable as me more as a peer as opposed to a subordinate – however I always reserve the right to make the final decision as and when need be.

7. What is the best way to "speak truth to power"? In other words, how do you tell your boss he or she is wrong?
A lot depends on the relationship you have with your boss and the type of character s/he is and the situation you find yourself in. In general people do not like to be told they are wrong – so try presenting the truth by pre-fixing it with something like “another way of doing XYZ is to…” or pose it as a question – “is there any merit in us taking such and such a course instead of XYZ”. However if your line manager will be making a decision based on the incorrect information and the facts are not subjective then it will be best to present the raw facts and evidence – be sure not to do it in a conceited or pompous way – nobody likes a smart alec.

8. What is the best way to find companies with the best career paths for you?
You could use social networking sites like LinkedIn and search for companies you have in mind and then people who have or are working for the company in question and see how their career path has developed.

9. What advice would you have for someone just entering the job market and wanting to chart a career path similar to yours?
Be sure to read good books on both business and technical topics. Take extra classes either correspondence courses or evening classes. Develop interests outside of your immediate career – do some community or charity work – it’s amazing what you will learn from doing this type of work. Keep your mind sharp by learning a musical instrument or a foreign language.

10. What is the best advice you've received in the workplace that you'll someday pass down to someone else?
Never be afraid of a challenge – if possible do not stay with an organisation that does not offer you a good career path or an opportunity to grow and learn.

11. Is there anything else you think it would be important for our readers to know?
Every set back is an opportunity for a come back – calm seas have never made a good sailor. There will be times when things will go wrong – ensure you do a personal lessons learnt (preferably at the end of each day). Be robust ensure you have a vision for yourself (a wise man once said: without a vision the people perish) and the vision will drive you on to succeed in your career.

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:

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.






A book for all Product Managers: The Art of Product Management

Lessons from a Silicon Valley Innovator by Rich Mironov

This book compiles some of Rich's most popular columns from 2002 to 2008. It includes thoughts on building and maintaining product organizations, understanding how customers think, ideas for how to price new products, and ways to motivate people who don’t work for you. Collected into a single volume, it paints a picture of a typical interrupt-driven day.

Rich Mironov is a software product strategist and veteran of four high-tech startups. He is currently Chief Marketing Officer (CMO) of Enthiosys, a product strategy consultancy headquartered in Silicon Valley, where he advises technology companies ranging from F100 to pre-funded startups. Rich is considered an expert on software product management and marketing with a focus on business strategy, pricing and market analysis.
The five key section are:

1. Falling in Love
2. Organizing your Organization
3. The almost New – New thing
4. Getting into the Customers Head
5. What Should Things Cost

Rich draws analogy between being a parent (and at times a first time parent) and product management – an analogy that I used to describe the difference between product management and project management.
The book promises to be a good read for product managers who are working for start ups and for large corporate organisations – click here to purchase the book from Amazon or here to read more about Rich and his book The art of Product Management.