Pain without gain (ROI) or pleasure with gain (ROI).

Pain with a threatened ROI or pleasure with an improved chance of a greater ROI - which one appeals to you?

At the end of a waterfall project (or any project for that matter) the product manager or project manager will usually hold a ‘lessons learnt’ session where the participants of a project that has not gone so well discuss what went wrong with the view of improving performance on the next project. Developers and other technical team members feel put on the spot – attempting to explain, from their perspective, why the project was deemed a failure or put another way not as successfully as it could have been. The key points that ususally need to be explained, by product managers and developers, are why:

• deadline were missed
• budget(s) overrun or why
• the customer wasn’t happy.

Post mortems of this kind are always uncomfortable and are a typical symptom of waterfall projects: lots of pain with out delayed gain (ROI).

The symptoms of agile are pretty much the exact opposite: short daily focussed, stand-up, meetings involving all stakeholders. Budgets (man hours) agreed up front and controlled by the product owners, sprint retrospectives designed to give business owner, product manager, and technical teams the opportunity to identify what could be done in the next sprint to improve on the previous one and the opportunity to put it into practice and evaluate with in a few weeks as opposed to many months or a few years (as is often the case under the waterfall project methodology).

From a Product & Project Mangers point of view waterfall is a long and drawn out process that may end up in a painful lessons learnt session. While agile gives short bursts of mild discomfort with the opportunity to turn the discomfort into a pleasurable experience as software gets delivered:

• on time (time is fixed)
• with in budget (which is under the control of the product owners) and
• to the customer’s satisfaction (involvement in the sprint planning meetings the daily catch up meetings limits the chances of unpleasant surprises at the end of the project).
  

This sounds and feels like “pleasure with gain” or pleasure with increased/quicker return on investment (ROI).

For more: How do lessons learnt influence an organastion

Read More

Agile people working in a non-agile world

Implementing an agile development frame work, such as Scrum, does not solve your company’s problems but helps identifies them. My current company has implemented the scrum agile management frame work. The initial results from the product mangers point of view have been quite interesting:

• Various stakeholders gradually changing their behaviour as they record their required enhancements and bugs fixes in the product backlog rather than emailing the Product Manager and CC-ing half the company hoping that the long lists of people who have been copied on the email will somehow generate momentum to make it happen instantaneously.
• An understanding from commercial stakeholders that there will be periodic releases and therefore new features and enhancements will be released within a set time frame.
• Total transparency as groups of business and product owners meet each morning with the Product Manager and engineering teams to review commitments made the day before, discuss today’s commitments and identify impediments that stand in the way of the team delivering on commitments.

The implementation of an agile frame work had certainly helped in delivering software incrementally to the end users but has at the same time exposed a number of cross company issues and bottlenecks that could threaten return on investment (ROI).

Product Managers are agile managers: traditionally interfacing between the engineering team, various other technical teams and commercial/business stakeholders. Being in a pivotal position places them in the ideal place to act as exponents to change – assisting in changing a non-agile company into an agile one. This is especially true of Product Managers who have embraced an agile frame work, tasted the fruits of its success (in the software development life cycle) and now want to move the boundaries of agile working from beyond the engineering team(s) to other areas of the company. However such a programme whether formal or informal would require the full backing of chief executives who after all claim, according to a recent McKinsey survey on building nimble organizations, ranked agility as “very” or “extremely” important to their business success – with 91% stating that it had become more important for their companies over the past five years.

For more on this topic read the 1st half of : Think Big Think Agile Product Management

Read More

Being up front during an interview

During the past 6 months I’ve been interviewing a number people for Product Management vacancies. My company is currently experiencing rapid growth with its online products at the moment and therefore needs to build strong Product Management teams to facilitate that growth and help secure ROI.

I tend to follow the same pattern for each candidate: scenario based discussions/questions that reflect key milestones in the typical product life cycle. I aim to get a firm understanding for the candidates skill set in seven key areas:

• Routine product and project management skills
• Communication skills
• Leading without authority
• Conflict resolution
• Learning skills
• Knowledge of web technologies
• Business/commercial acumen

Adapted from Michael’s article “Seven Traits of Successful Product Managers”.
I flow from the topic of ‘leading without authority’: setting up and managing virtual teams comprising of commercial and technical people from across the company of whom you have no direct line management authority for- to conflict within this team during a meeting where a deadline is not met (that happens to be a dependency) due to changing business priorities in another area. The ramifications being that the launch of the project will be delayed and revenue threatened if action is not taken. The question to the candidate is: “What action would you take?” I have received many good answers but candidates seem to be reluctant to mention escalating the issue as a means of seeking a resolution.
I like to explore how resilient the candidate is and directly ask them “How they handle stress?” By its very nature the role of the Product Manager can become quite stressful at times – and trying to solve ALL issues by yourself without the input of senior management and those who are responsible for resource allocation is defiantly a recipe for increasing your stress level. Why are Product Managers reluctant to escalate issues at the appropriate time? Or are we just shy about mentioning escalating at interviews?

Ken Norton has written an interesting article, on his blog, on the subject of hiring product managers. Good reading for any one attending a job interview.

Related articles

Interview with a Product Manager #Part 1

How others have moved into Product Management

Read More