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.

Read More

Great Product Managers are on route to becoming tomorrows CEOs.

Mark Dance in his podcast for featureplan (Are Great Product Managers Born or Made) states that the first rule for hiring great product managers is to hire product managers that can grow to be CEOs because they are: the CEOs of tomorrow and are the CEOs for their products. Adam Bullied, in his blog post Not Being CEO, reviews the common aspects of the CEO and Product Manager role, he states that:

“The responsibility of the roles heavily intersect. A large part, in my estimation, is due to both positions having visibility company-wide, and the requirement of working with everyone in a company in order to get your job done.”

Mark Dance also compares the role of CEO and Product Manager: stating that both are strategic and operational in that they:
#1. Create value for customers
#2. Capture that value and
#3. Protect that value

The steps taken from moving from Product Management to becoming a Chief Executive

Barbara Tallent who progressed from Product Management to being a CEO via being a VP of a few departments’ notes in her blog post Product Manager to CEO in 10 short years says:

"In some ways, being a CEO is no different at all then being a product manager. You are responsible for everything and yet there are outside influences that are out of your control. Yet in some ways it is very different. As a product manager, you have all the responsibility, but none of the authority and you need to coax, cajole, or con people into what is best for the company. As CEO you have a level of authority that is easily misunderstood and even more easily misused. But you still have to build consensus and make people feel like they are part of the decision process so, from that perspective, product marketing prepares you well for the CEO role."

Barbara Tallent reviews her career and gives four attributes that all Product Managers need to embrace to prepare themselves for more senior positions in their organization:

#1. Start thinking like a CEO – think beyond the product, the next sprint, enhancements and bug lists. Think about the position of the product and the company in the market place. Bring people together to talk about the product road map.
#2. People skills: motivation, communication – telling people why products, features etc are or are not important. Be able to lead people.
#3. Live in the sales world for a while – understand the sales process – improve your sales skills because the CEO is always selling, either to customers, investors, or employees.
#4. Learn as much as possible about fund raising and its process. CEOs particularly of start-ups will need to raise funds. Also learn what venture capitalists look for when investing in a company.

Growing CEOs from with in the company

Joseph L. Bower in November’s issue of Harvard Business Review gives a number of pointers for those wishing to progress to the level of CEO. The article points out that:

#1.The most successful CEO’s, on balance are developed inside the company – but manage to retain an outside perspective: there is a need to maintain enough detachment from the local traditions and ideology to maintain the objectivity of an outsider.

#2. Build a track record of delivering in the short term while building for the long term.

#3. Take the opportunity, should it arise, to run a business unit, department or even a risky project that gives you the opportunity to be responsible for profit and loss (P/L).

Attributes needed for driving a company forward

Bower also lists four key skills that a new CEO needs to drive a company forward and produce the results that the board and shareholders are looking for:

#1. Anticipate where the world and the companies markets are heading and create a vision to position the company accordingly.

#2. Identify and recruit, if need be, the talent that can transform the vision into reality.

#3. Gain a real understanding for the problems and issues that the company faces.

#4. Understand how the company really works – who are the key players that make things happen.

Irrespective of whether you’re a Product Manager who wants to improve their Product Management skills and standing within their company or whether you are looking to climb the corporate ladder – the advice and tips, I’ve summarised, from the authors quoted in this blog post are applicable.

Final word from Tallent was that “There is a whole lot of good ‘fortune’ and timing that goes into anyone's career” including her own she adds.

I believe the key is to be striving to reach your full potential, at each step in your career, so should the doors of opportunity open (running a risky project, taking on P/L responsibility for a business unit or becoming a CEO) you are prepared to rise to the challenge and walk through the open door.

Read More

Successful Product Managers collaborate to ensure innovative product development

One of the key attributes that a Product Manager has to have in order to be successful is the ability to work in a collaborative way across teams and departments in order to bring new products to market or maintain and increase the profitability of existing products by adding innovative features and enhancements. Collaboration is one of those key requirements listed in the majority of job adverts for Product Managers. Collaboration is a key issue for CEOs because they know that bringing a group of people together from diverse backgrounds, skill-sets and professions to work as a team or virtual team is a challenging job.

According to Lynda Gratton and Tamara J. Erickson:

“The most productive, innovative teams were led by people who were both task and relationship-oriented.”

As such it’s the responsibility of Product Management to be able to work with and co-ordinate stakeholders with different skill sets and from a variety of backgrounds and at different levels.

Three factors that help Product Managers successfully collaborate are:

#1. Work closely with your teams on a daily basis – sit among the engineers and if possible have a hot desk in departments and/or the officers of other stakeholders – spread yourself around.

#2. The Product Manager has to be a universal translator: understanding the commercial and business world and yet have the appropriate technical understanding of the technologies that underpin the products so that they can understand and explain both sides of the equation. This will ensure that business and technical sense is maintianed.

#3. Be clear on your role (what is expected of you) and ensure that other stakeholders know the boundaries of your role. This will aid in dispelling ambiguity and ensure that tasks aren’t inadvertently left undone.

In short the successful Product Managers will understand the issues, technical and business pains of their stakeholders and be able to communicate and help resolve these pains for the common good of the success of the product.

Read More

Profit-Driven Innovation with Hugh Richards

Product Management View blog and webinar series has a webinar by Hugh Richards entitled " Profit-Driven Innovation". This webinar covers key issues companies face when innovating:

#1. Why we innovate.
#2. Key drivers of successful innovation.
#3. Understaning company operations.
#4. Innovation impact across the company.
#5. Necessity for strong leadershp.

Read More

How Product Managers can avoid innovation traps #part2

How Product Managers can avoid innovation traps Part#1 touched on two innovative traps that ProductManagers may encounter:

#1. Strategy: the misconception that every innovative idea has to be a blockbuster – where as a number of small incremental innovations could lead to over all product success. And
#2. Process: subjecting innovative efforts and projects to the same rigor, reviews and filters as standard business as usual (BAU) will stifle innovative growth.

Part #2 will now deal with the innovative traps of Structure and Skills.

Structure
The wrong company structure could easily hinder innovation. However a key part of the Product Management function is to collaborate with stakeholders from across the company in order to collate possible ideas for future product development and product enhancement as well as to smooth the way for the implementation of such ideas.

Rosabeth Moss Kanter gives example of companies that setup innovative projects that included individuals from across various functions [sales, marketing, production…] with in an organization. These individuals worked apart from the traditional company structure in order to avoid a company culture that would hinder innovation. The ideas that were most innovative and promising from the various areas [sales, customer support, marketing…] would be introduced back into the main company. However Kanter reports that the projects failed to integrate the new ideas back into the mainstream part of the firms. The key reason, for failure, was put down to a poor connection between the experimenting innovative team and the mainstream company. Product Management by its very nature seeks buy-in from across various cross functional areas and acts as the oil to smooth the way for such changes in order to ensure products experience constant improvement at each point their life cycle.

The Product Management function also needs to be able to review activity from various divisions across an organization – divisions that will probably be working with various technologies and/or operating in different markets. Kanter gives examples of CBS and Gillette who failed to bring various technologies together from its various divisions in order to come up with cutting edge products.

CBS was once the world’s largest broadcaster and owned the world’s largest record company, yet it failed to invent music video, losing this opportunity to MTV. In the late 1990s, Gillette had a toothbrush unit (Oral B), an appliance unit (Braun), and a battery unit (Duracell), but lagged in introducing a battery-powered toothbrush. The likelihood that companies will miss or stifle innovations increases when the potential innovations involve expertise from different industries or knowledge of different technologies. Managers at established organizations may both fail to understand the nature of a new idea and feel threatened by it.

Possible lessons learnt for CBS and Gillette would be enable Product Management to operate horizontally across the enterprises various divisions in order come up with innovative ideas. This means that the Product Manager would need to have at least an appreciation of the various markets and technology from across the enterprise.

The 4^th and final innovation traps that Kanter list is Communication and leadership Skills:

Being able to innovate is one thing but having the ability to convince others of your innovative idea is another. Failure to be able to sell your idea to internal stakeholders will probably result your innovative ideas not making itto market - and by chance they do they are in danger of being a commercial failure. I worked for a company where the engineers came up with a fabulous idea – it was designed – manufactured – was displayed at exhibitions but was not a commercial success, simply because the Sales Director did not understand or believe in it. I’ve also worked for a different company where a particular engineering team continuously produced competitive products that earned the company substantial revenue. However the team failed (for one reason or another) to gel with the rest of the company. The result was that the team was dismantled by senior management. Strong management including Product Management is required to complement innovation.

• Relationships need to be built and maintained,
• People need to buy-in to the ideas,
• Colleagues need to speak up for your innovative ideas at meeting that you don’t attend,
• Unhealthy competition between R&D teams needs to be put to rest.

Micheal in his blog High tech Product Management who owns innovation in your company writes:

"In most high-tech companies, the Product Management/Marketing team has the best view of the cross-functional processes of the organization - across Development, Marketing, Distribution, Operations, Sales and Support."

In short Product Management needs to drive innovation through various stages by using their soft ‘people skills’. Chief being the ability to communicate at all levels through out the organization.

Read also:

How Product Managers can avoid innovation traps #part 1
The innovation value chain and Product Management
Innovation the classic traps

Read More

How Product Managers can avoid innovation traps #part 1

Product Managers often need to collaborate, co-ordinate, drive, release and launch innovative ideas into the market place. However there are pitfalls that product management need to avoid if success is be to secured. This is a two part series based on Rosabeth Moss Kanter article in Harvard Business Review entitled Innovation: The Classic Traps. The article focuses on four areas: Strategy, Process, Structure and Skills.

Strategy Mistakes
It is not possible for every innovative idea to be a huge success such as the new iPod - therefore Product Managers, Business and Product Owners should be careful not to reject opportunities that at first appear too small because they do not have the inherent promise of being the next killer app. A number of small incremental wins to a product feature set could ultimately result in overall product success - especially with online products.

Rosabeth Moss Kanter states that:
Not every offering [feature, enhancement or new product] will be a blockbuster, but 'Time Incorporated' had learned what successful innovators know. To get more success you have to be willing to risk more failures, Rosabeth quotes the following example from the traditional media business as a case in point:

"Time Incorporated, the magazine wing of Time Warner, for a long time was slow to develop new publications because managers wanted any start-up to have the potential to grow into another People or Sports Illustrated, two of the company’s legendary successes. During the period before Don Logan took the helm in 1992, almost no new magazines were launched. After Logan brought a different innovation strategy to the magazine group, Time developed (or bought) about 100 magazines, which dramatically increased the company’s revenues, cash flow, and profits."

The same would naturally be true for on-line media companies aiming to increase revenue by innovation– whether it’s adding new enhancements, functionality or widgets to an existing website or launching a new on-line product in a new or related market area. The balance will be the risk and reward of innovative ventures versus the risk of the traditional and status quo which could result in the risk of loosing market share to a number of younger meaner online publishing machines.

Process Mistakes
There is a risk of stifling innovation by subjecting it to tight controls and procedures of existing businesses. Again Rosabeth Moss Kanter gives us a practical example:

"AlliedSignal (now Honeywell) in 2000 sought new Internet-based products and services using established strategic-planning and budgeting processes through existing business units. The CEO asked the divisions to bring their best ideas for Internet-related innovations to the quarterly budget reviews. Although designated as a priority, these innovation projects were subjected to the same financial metrics the established businesses were. Budgets contained no additional funds for investment; managers working on innovations had to find their own sources of funding through savings or internal transfers. What emerged were often retrofitted versions of ideas that had been in the pipeline anyway."

Product Managers would do well to justify time for engineering teams to carry out research and therefore help secure budget for both pure and applied research. It would also be advantageous to map the areas of applied research to future product functionality in order to demonstrate transparency..
See also
Innovation the classic trap
The Innovation Value Chain and Product Management
How Product Managers can avoid innovation traps #part2

Read More

The Innovation Value Chain and Product Management

Morten T Hansen and Julian Birkinshaw published an interesting article in HBR about what they call the Innovation Value Chain.
The article highlights the three main phases of innovation:
*Idea Generation
*Idea Conversion
*Idea Diffusion

Idea Generation:
The aim is to generate ideas from various sources: from with in your own business unit of team; from other business units or teams; from across the company; from customers; end users; competitors; universities; related industries and the list goes on…

Idea Conversion:
The list of new ideas need to be appropriately screened and categorised to determine the degree of technical difficulty to develop in terms of engineering time and resources verses the commercial return on developing such a product or new feature. It could be that the new idea will not bring the company or business unit direct commercial success but will help the company enter uncharted territory or, if a new feature, help maintain the products competitiveness due new developments in a rival product.

Idea Diffusion
Hansen and Birkinshaw state that “Concepts that have been sourced, vetted, funded and developed still need to receive buy in” from various internal and external stakeholders.

The key to the article is that a company's ‘innovation value chain’: idea generation – conversion and diffusion is as strong as the chain's weakest link. Hansen and Birkinshaw suggest that companies need to identify where the weak links are and either create new roles for employees to help strengthen the link – and/or when hiring new candidates seek those who will be able to address weakness in their ‘innovation chain’.

I would say that a company with weakness in it’s 'innovation value chain' needs to either review it’s product management team and come up with a plan to strengthen the product management role or consider adopting product management as a new function with in their company.

Also read:
How Product Managers can avoid innovation traps #part 1
How Product Managers can avoid innovation traps #part2

Read More

How Product Managers can successfully ride the storms of a commercial life.

Technology companies often go through good and bad times and even through the good times there will be situations which seek to hinder the personnel performance of Product Managers and Technologists. On occasions there will be situations and decisions that run against the grain of your feelings and the path you’ve laid out for yourself. Company issues: recruitment- either you can not hire the right staff, sudden change in direction that takes you unaware, technical environments not functioning and therefore hindering progress. Loss of an expected sale or even a sale man landing an unexpected deal that pushes a lot of last minute work your way with tight deadlines. And list goes on.

Here are seven tips to help product managers ride the companies storms: Have a roadmap for your self as well as your product and make sure your road map is flexible enough to incorporate changes and therefore capitalise opportunities should they arise.
#1. Develop the ability to hold two opposing views in your mind at one time and yet be able to come up with a third and even better view.

#2. Ensure you have a mentor and know when to ask for help.

#3. Be your own worst critic.

#4. Make sure you are constantly learning from your past experiences and the experiences of others.

#5. Keep your feet on the ground

#6. Be constantly learning and reading – this will help you act and re-act when unfamiliar situations occur.
#7. Make sure you have some fun activities outside of your commercial life.

Read More

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.

Read More

10 Tips For New Product Managers

If you’re new to Product Management then you really should invest 30 minutes of your time to watch Jeff Lash’s podcast “Ten Tips For New Product Managers…” The podcast will also serve as a good refresher for those of you who are experienced Product Managers. Jeff's ten points are listed below.

#1. Spend time with customers
#2. Ask “dumb” questions
#3. Let go of your past
#4. Surround yourself with experts
#5. Gather data
#6. Focus
#7. Concentrate on what, not how
#8. Communicate, communicate, communicate
#9. Sell your product internally
#10. Do whatever it takes

Click here to go to the podcast.

Read More

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

Read More

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.

Read More

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

Read More

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.

Read More

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

Read More

How Product Managers can successfully ride the storms of a commercial life.

Technology companies often go through good and bad times and even through the good times there will be situations which seek to hinder the personnel performance of Product Managers and Technologists. On occasions there will be situations and decisions that run against the grain of your feelings and the path you’ve laid out for yourself. Company issues: recruitment- either you can not hire the right staff, sudden change in direction that takes you unaware, technical environments not functioning and therefore hindering progress. Loss of an expected sale or even a sale man landing an unexpected deal that pushes a lot of last minute work your way with tight deadlines. And list goes on.

Here are seven tips to help product managers ride the companies storms: Have a roadmap for your self as well as your product and make sure your roadmap is flexible enough to incorporate changes and therefore capitalise opportunities should they arise.

#1. Develop the ability to hold two opposing views in your mind at one time and yet be able to come up with a third and even better view.

#2. Ensure you have a mentor and know when to ask for help.

#3. Be your own worst critic.

#4. Make sure you are constantly learning from your past experiences and the experiences of others.

#5. Keep your feet on the ground

#6. Be constantly learning and reading – this will help you act and re-act in unfamiliar situations occur.
#7. Make sure you have some fun activities outside of your commercial life.

Read More

Part #4 Agile Customer Support

I worked for a company where in the morning I was booked on a flight to troubleshot issues at a customers site in Switzerland at Midday it had changed to Germany and by the time I went home I was booked on a flight (for the next day) to Florida. That’s agile customer care for you. The ethos of the company was to adapt your schedules to meet the customers' need. Indeed the competitive edge that we had was the fact the we responded to the customers needs and had a well trained customer support department which was backed up by a test dept, R&D, project managers, product managers, technical sales and even the technical manager and technical director who all had the ability to visit customer sites with the view of fixing problems. The agility of all technical staff meant that the company had a great reputation for customer service and therefore won repeat business and experienced greater ROI year on year, that's got to make good business sense!

I believe that our success was down to two very simple attributes that each member of staff had adopted:
1. We worked hard to be better than the competition.
2. Everybody was customer focussed.
This meant there was very little time for internal company politics and the petty little immature things that causes a company to loose its way.

Success depends on how agile your customer support is – is it down to a few individuals with the job title of 'customer support engineer' or is it the whole company.

See also: Part#1 Implementing an Agile Frame Work

Read More

Part #3 How to run an agile training course

We’ve all attended training session which were death by power point. There was little interaction from the attendees and the trainer seemed determined to get through everyone of his/her dozen or so bullet points that appeared on the numerous amount of slides that they had.

I attended a six day 1st line management training course sometime ago – and was dreading the thought of having to sit through a zillion power point slides and hearing the droning of some poor trainers voice for a the rest of the week. However I was presently surprised. The agility of the trainer was quite refreshing and the participation from the attendees was second to none. Here’s how he approached the session.

1. The introductions: who you are what you hope to gain from the course – all jotted down on a flip chart.
2. Quick survey of participants to see if there were any “challenging issues” they were currently facing that they need to resolve.
3. Merge the participants’ expectation with the course content (the two were pretty close). This could be considered the backlog items
4. Short problem solving exercise to get us to think out of the box and wet our appetites.
   Run a series of exercises and tasks.
5. Open discussion / feedback on the tasks
6. Periodically visit the “challenging issues” previously raised and discuss in conjunction with the feedback from exercises and tasks that were set.
7. At the end of the day review the backlog items and tick off the backlog items that had been covered.
8. Ask attendees if they need any more input on a given backlog task.
9. Review the course at the end of the six days referring to the backlog items that have been covered.

No power point slides, very little use of projector or plasma screen. Lots of writing on flipcharts, constant inspecting and adapting through out the day to ensure participants needs were met. A real agile approach to a training course.
Benefits:

• Managers and leaders are better trained based on emerging needs as opposed to a rigid inflexible curriculum.


• Teams stand a better chance of improving their performance because real life issues are being addressed.

Next time you attend a training course that is "death by power point" and you get a feedback form asking... "how it was for you" - point the training to this article and suggest they adopt training the agile way.

Read More

Part #2: Agile meetings run by an agile chairperson

All of us have attended many meetings during our careers, some good and some not so good. The idea of the sprint meeting: where hands on stakeholders (product owner(s) and technical team) meet for 10 to 15 minutes each day, stand up around a white board and answer 3 basic questions:

#1 What did you do yesterday (reporting back on the commitment you made the day before),
#2 What are you planning to do today (today’s commitment) and
#3 Is there anything stopping you fulfilling your commitment.
Ranks high in my book as a good way to run a meeting to get an understanding of the status of a project, it's: concise, precise and efficient. These meetings are co-ordinated and arranged by the scrummaster (Product or Project Manager).

Sprint meetings which are an essential part of the agile scrum framework.

Sprint meetings are not too different from many typical management meetings that we attend – ironically, these meetings are not conducted in an agile way or form part of an agile framework. These meetings have very firm agendas where each item is time-boxed. It's the job of the chairperson to firmly keep the meeting on track – the final agenda item is traditionally 'any-other-business' (AOB ) which is usually time-boxed at round 5% to 10% of the total meeting time. Some chairpersons will do a 'round robin' in place of AOB – giving each person time to raise any issues they may have (this too is usually time-boxed to 5% to 10%) not enough time to tackle any real issues of concern.

It goes with out saying that the way you chair and organise a meeting depends a lot on the type of meeting, the aim and circumstances surrounding the meeting and the people who will be attending.

For regular team meetings I prefer the more flexible agile approach where the chairperson sets the agenda, gives plenty of opportunity for those attending to add agenda items, publishes the agenda before the meeting and then raises each agenda item in turn but allows the team to divert onto other topics (irrespective of whether the item is or is not on the agenda). The chairperson tactfully pulls it back on track if the discussion does not seem to be adding value to the team or department. Running a meeting in this fashion does take a bit longer (probably up to 25 - 35% longer) however the benefits outweigh the cost.

Another way to run an agile team meeting is to do away with a formal agenda. The chairperson (departmental or team leader) opens up and tells the team what their issues, concerns and achievements are. Then they open up the floor so that others can contributes and share their plans, concerns, achievements etc... I’ve been in teams where this method has been used and over time it has produced good results.

Team morale is kept high as people value agile meetings as a place where concerns can be raised, discussed and possible solutions and support given. This also has the added benefit in that the chairperson (departmental or team leader) gets to know what individual members of their team really think (people talk more freely when they are relaxed and not time boxed) and an understanding of the true concerns and issues that the department/team may be facing – as opposed to a polished presented one-liner that makes them look good.

I worked with one MD several years ago who calculated the cost (based on everybody's, hourly rate) of our weekly team meetings. OK it had the effect that we become more concise with our comments and therefore kept the meeting as short as possible. However the MD didn’t really know what was going on in the various departments in the company.

To get a better return on investment (ROI) out of meetings takes the initial investment of time, that will give you the scope to chair in an agile way. Agile meetings gives the team members time to talk freely – this gives you the ability to really get to the bottom of what is happening. To get concise to the point status of a project adopt a daily sprint meeting (10 to 15 minutes max) the combination of the two (sprint meetings every day and agile meeting every week or two) will help you run any team and or project in an effective way – insuring that you get the best of both worlds: timely reports and a grasp of the real concerns the department/team are facing - the ultimate result being a better ROI from your team.

See also Product Management Productivity Tip #3: Master Meetings

Read More

Part #1: Implementing an Agile Sales Framework

By their very nature sales people are agile in their approach to selling products and services. A good sales rep will intuitively carry out a quick inspection of the prospective customer’s situation, adapt themselves to make the customer feel at ease, and continue to inspect (by asking the appropriate questions) until they feel confident enough to present a solution to ease the customers business-pain. The problem occurs when the salesman becomes too agile by claiming to be able to solve a business pain to which they have no direct solution – or make a commitment to be able to deliver, a solution, with in a timescale that has not been agreed with the technology teams or Product Manager.

Sales teams need to also inspect the technology team’s capability of delivering bespoke or custom designed solutions – this should be done via the Product Manager.

To make a positive contribution to the agility of a company, sales need to operate within an agreed agile framework much in the same way as software development teams operate with in frameworks such as Scrum or DSDM.
A simple framework for the sales teams to operate in might look something like this:

• Only make commitments on products that are released and being shipped.
• If it does not do it out-of-the-box then do not make a commitment.
• Understand the iteration of the software department – know when sprints are starting and when functionality will be released – again the job of the Product manager to communicate this information to the appropriate stakeholders.
• Give feedback on requests for bespoke development, there may be synergy with other requests coming in from other sales teams with in the company.
• Product Managers compare request for bespoke work with agreed roadmap.

Most Product Manager and developers have experienced having to put everything on hold, change direction, divert from the strategic roadmap and deliver a new product or new functionality in order to secure a deal. This is fine – because agile software development is flexible enough to facilitate ad-hoc changes to meet the customer’s needs, however constant chopping and changing has to weighed up against the companies desire to produce functionality and products that has been defined on the product roadmap. I’ve always admired Chief Executives who have walked away from a deal in order to keep the technology teams focused on the current roadmap. I’ve experienced diverting from the product road map to secure medium size deals only to loose bigger deals later on because we did not have that much needed functionality. Worst still I turned up to an exhibition only to see that the competition were demonstrating the feature we had delayed implementing while ours was not yet mature enough to even begin alpha testing.

Technology teams and Product Managers can help shape an agile sales framework by:

• Being an example and demonstrate the benefits of using an agile framework
• Communicate the capabilities of the team (velocity) and let sales know that we can react quickly BUT it comes at a cost (i.e. diverting form the current work).
• Encourage regular and open dialog with the sales team to glean from them the problems their customers are facing - the solution just may be lingering in a developers or product mangers head.
• Update the product roadmap based on feedback and then feed this back, at the appropriate time, to the sales team(s).
• Accompany a sales man on at least one sales trip a year; this will help you understand the commercial pressures that the sales team are under – who knows it could lead to your career changing direction towards technical sales.

Sales teams play a vital part in any successful commercial operation. It is therefore vital for them to operate with in an agile framework in order to ensure that the company does not become a victim of its own success and to make a postive contribution to the agility of the organisations.

The combination of an ‘agile development frame work’ and a ‘sales agile framework’ is akin to a combination of "business sense and technical sense" – it’s just common sense.

Read More

Identifying Agile Organisations, Functions and Roles

There currently seems to be a strong move towards agile software development. Engineering teams and I.T. departments are adopting one agile method or another. However the conversion of software teams, to agile, does not naturally result in the other areas of a company adopting an agile method of working. The question is why should other areas adopt an agile approach to work? The answers is simple - because it is important to 91% of CEOs who are looking at how their company’s will develop over the next 5 years.

Some departments and functions could improve their performance by working in an agile way, while it may not be at all suitable for others. Some departments and functions (in some companies) do work in an agile way but we probably don’t recognise it. While it would be totally inappropriate for others to even consider adopting an agile way of working.

This article is an introduction to a 10 part series on how Product Managers and Engineering teams could influence various aspects of a company to help them identify and/or adopt an agile approach to working. It is also important for technical people to be aware of how other departments operate - many jobs, positions & functions: CEO, Managing Director, COO, Sales, Marketing, Product Management etc... in Hi-Tech companies are performed by people who have strong technical/engineering backgrounds.

The areas that will be covered are as follows:

1. Agile sales
2. The agile chairperson or meeting co-ordinator
3. Agile training
4. Agile customer support
5. Agile product marketing
6. Agile for everyone
7. Agile software testing
8. Agile management
9. Agile product manager
10. Agile research
    

Being an agile company means that you’re a competitive company – being competitive increases your chances of an increased return on investment (ROI ). An increase in ROI means more investment in technology, training and research and ultimately to greater job satisfaction. Hope you enjoy and contribute to the series.

Read More