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 manly with the creation of the roadmap. The presentation below gives a high level view of the other elements of the framework.
Wednesday
Tuesday
Advice for up and coming Product Managers
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?
2. What's the best way to "sell" yourself and your abilities to higher-ups?
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?
6. If applicable to your situation, how do you handle being younger than people you're supervising or leading?
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.
Sunday
Agile Product Management Framework
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 Share-Point 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 & 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.
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 agile development team steps away from using scrum (or their preferred agile method) either in part or completely
Could cause the product manager to become just a little disorientated - this has been my experience on two occasions over the past few years.
Totally moving away from scrum
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 necessary. 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.
Partially moving away from scrum
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.
Wednesday
A book for all Product Managers: The Art of Product Management
1. Falling in Love
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 mar¬keting with a focus on business strategy, pricing and market analysis.
The five key section are:
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.
Posted by
Derek Morrison
at
9:31 PM
2
comments
Labels: Product Development, Product Management, Product Manager


