3 Ways a PM can help the team De-stress

With Project deadlines looming, stress is often a factor that project managers have to deal with, especially with the team they are managing, with a clear correlation between the level of stress indured and the quality of work produced, not to mention emotional endurance. Let’s face it, almost every project (most likely every project) is under the pump at one stage or another during the lifecycle, and duress is something, as a Project Manager, you certainly need to deal with. 

With fixed resources, fixed time and budget, things tend to go awry, whether it is a strong dependency of a delivery from one team, a technical difficulty that cannot be resolved, scope changes, resource changes, and your job is to make sure things don’t go belly-up. Negative stress influences teams by de-optimizing their work efficiencies, resulting in lower-than-expected sprint velocities, dampen creativity and constructive thinking, resulting in mental fatigue, resulting in even simple coding errors creeping in.

There are of course specific PM courses of action you can take to address the problems, and this article isn’t about that, it’s more about how you can leverage your influence to act as a mentor, or guru to project positivity, in order to boost the morale of your team. Here are 3 Ways a PM can help the team De-stress.

With Project deadlines looming, stress is often a factor that project managers have to deal with, especially with the team they are managing, with a clear correlation between the level of stress indured and the quality of work produced, not to mention emotional endurance. Let’s face it, almost every project (most likely every project) is under the pump at one stage or another during the lifecycle, and duress is something, as a Project Manager, you certainly need to deal with. 

With fixed resources, fixed time and budget, things tend to go awry, whether it is a strong dependency of a delivery from one team, a technical difficulty that cannot be resolved, scope changes, resource changes, and your job is to make sure things don’t go belly-up. Negative stress influences teams by de-optimizing their work efficiencies, resulting in lower-than-expected sprint velocities, dampen creativity and constructive thinking, resulting in mental fatigue, resulting in even simple coding errors creeping in.

There are of course specific PM courses of action you can take to address the problems, and this article isn’t about that, it’s more about how you can leverage your influence to act as a mentor, or guru to project positivity, in order to boost the morale of your team. Here are 3 Ways a PM can help the team De-stress.

#1.Empathy

The most important attribute I believe a project manager should possess is empathy. Empathy – em·pa·thy – the feeling that you understand and share another person’s experiences and emotions : the ability to share someone else’s feelings (source: Merriam-Webster Dictionary)

Measured as emotional intelligence, a powerful leadership quality is the ability to connect with each of your team-members on a non-technical, but emotional level, and understanding their needs, concerns and helping build a stronger and safer mental state for your team-member.

“Leaders with empathy,” according to Dr Daniel Goleman of the Harvard Business Review (“What Makes a Great Leader”), “do more than sympathize with people around them: they use their knowledge to improve their companies in subtle, but important ways.”

This tool, empathy is powerful not just in the sense that it allows you to help console a team-member, but also a strong negotiating tool. That is, empathy doesn’t infer you need to agree with someone, but rather substitute agreement for empathy, showing a genuine concern for the other person’s concerns, feeling and motives, thereby portraying a greater level of reasoning that leads to a response that is in tune with what the person is going through.

#2. Rallying Your Team

Empathy should not just in the form of words, but actions, and you know the saying work hard, play hard, that’s something that PMs should always do. Ideally, you want your team to bond and gell well, in order to build a strong sense of synergy and dynamics, and while that takes some time to form, you need to help facilitate the fostering of positive relationships. One way of achieving this, is through providing down-time, or socializing activities for your team. 

For instance, start with something simple as pizza Fridays, catered lunches during meetings, and lunches outside of the office. Allow your team members to get to know each other on a more personal level, and the bond will directly translate into the team rallying together for a common cause, or goal. 

One analogy I like to give is to compare it to the ancient Roman or Greek battle-cries, where a strong army morale with inspiring rallying, leads to armies defeating other armies of even greater sizes. Morale therefore is one of the most powerful emotional states a team can have. 

“Schedule monthly get-togethers to reaffirm the project goals, congratulate the team on their successes to date and boost their confidence in doing what it takes to complete the project successfully. Make sure that each person leaves the meeting energized and passionate about finishing the remainder of the project.” (source: Jason Westland. “Managing Projects of all Sizes.” ProjectManager.com, 2014)

With sprints, this is also where retrospectives come in, where you always make sure that you recognize success, and attribute success to each member always. 

#3 Prevent Negative Members from Influencing the Team

Sometimes its not external influences but internal influences that causes stress in the team. It could be someone from another team, say a product owner, that is the instigator. As a Project Manager, you play a fundamental role in shielding your team from negative outside influences, you bat for the team, advocate for the team (I’m looking at you, overzealous product owners).

Identify the instigator and use your personal negotiation skills (remember we talkd about empathy as a tool as well) and directly come to agreements so that they go through you. While listening to his or her perspective on the matter, you also put forward a strong stance that you won’t tolerate negative influences on the team, to hinder their performances. 

If the instigator is someone from within your team, you need to quickly pin-point the stress point (weak points) early on, provide a concrete action plan that will improve the situation. Of course, to be respectful of that person and everyone else, do this in a private manner. 

Remember, as a PM you need to always practice what you preach, and be a positive influencer, for others to follow. You don’t lead through authority but rather through influence, so your charismatic and empathetic attributes as a great leader will greatly determine whether your team is performing at its optimal or not. Rubbing out negiative influences, and instead rallying around your team, with positive re-inforcement, will allow you to achieve more, with less, all thanks to the comradership of each of your team-members.

Listen to your competitor’s customers


image.jpgimage.jpg

An interesting article on the merits of not just listening to your own customers, but your competitors’ customers as well, thanks to medium.com

Much has been written about wether or not you should worry about your competitors or completely ignore them. A quick Google search brings ups many opinions one way or the other. Every business has its own strategy with regard to this and of course it’s your call.

It’s also widely accepted that watching and listening to your customers is critical to building a product that people want. Many of us who are working to create products and services people love in order to build sustainable businesses, spend a lot of time and money getting feedback from potential customers.

When we do it right listening to our customers helps us to find our difference. It’s a lot easier to refine your product to more closely align with what customers want if you know what they want. And it’s a lot easier to fill the gaps that your competitors are leaving wide open by listening to their customers.

Source: 

Medium.com

5 Mistakes we all make with product feedback

I recently went through an article written by @destraynor titled 5 mistakes we all make with product feedback that I enjoyed, and wanted to run through it.

Having read a lot of literature this past year, on Lean Customer Development and this article put into perspective over five-points, common mistakes that are made from false assumptions when reading customer feedback.

I always champion teams not looking at face-value from what they get as feedback, because they are based on many assumptions, many of whom are either erroneous, or because you are taking into account customers that shouldn’t matter as much to you. Ill go through the list in a more abbreviated form, but I encourage you to read through the entire article, at http://blog.intercom.io/?p=6279

1. STOP TALKING TO “ALL USERS”

You need to segment the types of feedback you have by the type of audience, rather than mixing up all and forming an analysis from the combined pool. You have customers that use your product daily, some that use it sparingly, and those that downloaded or purchased but never used it. In order to get relevant feedback for a feature, ask the users that use your feature the most.

If you want to improve your onboarding, only listen to people who recently signed up.

— Inside Intercom

 

2. FEEDBACK SHOULD BE ON-GOING

Customer Engagement should be on-going, and iterative, the same way your software development cycle is iterative. Lean Customer Development champions the notion of continuous engagement, which should be in sprint-cycles, so every two weeks, every four weeks. Aligning your feedback mechanism with your development feedback allows you to continuously improve your product the following iteration based on feedback in a modularised and systematic way.

Feedback should also be done implicitly, through AB testing continuously, trying different on-boarding techniques etc, as well as using analytics to track specific feature usage, how long a user has been on a particular screen.

 

3. DISTINGUISH FREE FROM PAYING FEEDBACK

@destraynor distinguishably points out that not all feedback requests should be treated equally. That is, users of your freemium model versus the paying-customers provide different sorts of insights. Free users can be used to provide feedback on the free aspect, but not to be used to provide insights on the premium side of things. Once again, segment your feedback for different users, to different parts of your product. 

 

4. DON’T FALL FOR THE VOCAL MINORITY

It’s often said the plural of anecdote is not data, but that does not mean anecdotal evidence is not useful. The plural of anecdote is a hypothesis, or narrative. Something that’s easily verifiable.

http://blog.intercom.io/?p=6279

You need to take feedback in context, you shouldn’t take the feedback of five people as the gospel on what you should do next. In Lean Analytics, your goal is to fine a specific and trackable measurement that correlates to success. With customer development, you need to ensure the right type of customers provide feedback that is constructive. With quantitative data, you need the right amount of data to offer feedback value, if you are working with qualitative data, you need to ensure the right type of customer is providing feedback, without bias or distortion.

As @destraynor says, treat every feedback as a hypothesis, don’t build it but verify and prove it. Then you should build it.

5. DON’T ASSUME USERS REQUEST THE RIGHT FEATURE

There’s a famous quote from Confucius that the author makes mention of:

when customers point to the moon, the naive product manager examines their finger.

— Confucious

That means, as a product manager, you shouldn’t take things at face value, if a customer wants something, it may be something derived from something abstract that the solution to may be, similar to the 5 Why’s technique. Interrogate the response, think laterally and essentially ‘abstract a level or two above what’s requested into something that makes sense to you

For the complete article, visit http://blog.intercom.io/?p=6279

 

 

Proper Release Planning in a Project

Release planning is defined as the process of producing high-level planning that eventually gets broken down into iterations. Whilst a lot of literature and blogs focus on iteration planningrelease planning is by no means less important. 


The breakdown of a project from purpose progresses to release planning, which can roughly be 3-to-6 months, and encompasses about 8-10 iterations. It’s purpose serves to comprehend at a granular level what the development effort is and start to put ball-park scheduling (conceptually) so we can figure out when we may see a release.

The benefits of a release plan is that the entire team can sit and iron out a roadmap without having to commit at a more molecular level, whilst also setting up the expectations for the stakeholders. I also conceive of release planning as setting milestones for how we are progressing through our individual iterations, a sort of benchmarking, setting and ticking off sets of features.

Release planning is being granular enough 

The premise of release planning lies in determining at a higher-up level, based on a collection of user stories, what can be done, when. What is the development effort required, without having to drop down to the level of individual tasks. In fact, it’s a real no-no to specify or describe the planning in terms of tasks. 

Release planning is not about what tasks each developer works on, but about describing user stories–functionalities required–. Deferred delegation is essential, allowing the project team to assess individual development capacity when required, minimising the risk of roadblocks from task-dependencies.


In fact, delegation decisions should be left up to the individual developer, at the time of iteration, later on, as determining effort and capacity too early will lead to poorly assumed or understood assessments. 

what is the key success indicators?

This is something that should be determined up-front as well. In a previous article of mine, I talked about Lean Analytics as part of my review of a book, but the crux of it is that at this level, you need to determine your success criteria. Lean Analytics allows you to find that specific metric that is measurable, tangible and will help you easily understand how you are going. This is done iterative as well. 

Customer Development

I also did a previous piece on Lean Customer Development, and in release planning, we need to also determine our plan of attack, on how we will verify assumptions made on functionality, which directly correlates with the user stories we will have as part of our iterations.

User Story estimation

Whilst we won’t be estimating individual tasks, it is ideal for us to estimate indicatively the user stories, and assess whether we can plausably add the features we want in a specific iteration, and once again, prioritise and re-prioritise, organise and re-organise accordingly. Heavily linked with customer development, differences in customer engagement feedback could result in scope changes for user stories, thus forcing estimation changes.

Regularly updating the release plan

Please always ask the question, how often should we re-visit and re-vise our release plans? Whilst there is no definitive duration between re-visiting, it should be done frequently, as various factors such as project team velocity variances and feature scopes change, it requires getting back to this document, as it will always remain a living document.

I generally enjoy re-visiting the release plan after each iteration, as experience has taught me that iterations never end the way they were planned, and based on various surprises, things have to be pushed back from one iteration to another, which then tends to have a butterfly effect on other user stories. 

Value vs Waste: Customer Validation

I have come to learn, working for a startup for the past few months, the importance of Customer Validation. Granted, I have been immersing myself in one of my favourite books, The Lean Startup by Eric Ries, but correlating the chapter’s philosophies with what’s happening on the ground, is understanding and evaluating what is value versus waste?
man-162604_640

We could spend a lot of time creating our MVP, or Minimum Valuable Product, deciding what features to include, what features not to include, but without actually understanding what features are needed in order to gain actual feedback that we can measure our decisions against, we might as well be spending time on wasteful directions.

The author describes his former company’s decision to support multiple networks in it’s initial MVP, and eventually found out that their assumptions about what customers want was flawed. Could he have determined that prior to going down the track of spending all that extra effort? Sure.

..Learning is the essential unit of progress for startups (Ries, 2011).

The point is, if we are not going to learn anything about what customers want from a feature, then we can defer it, or eliminate it. This is the essence of validating, gauging positive improvements in core metrics (referred to as Lean Analytics) you look at what customers really want. You do this through experiments, not through questionnaires, you provide a decent-fidelity prototype for customers to play with, and observe. You do an A|B Testing methodology, to see from different versions which one gets the most positive responses.

What is considered vanity or actually useful metrics or stats is outside the scope of this post, and I will certainly look at including it in a future post, but it’s important to note that numbers and downloads and registrations are not important to startups. What’s important is correlating what feature you include is a positive attribution, rather than correlating increase in number of downloads based on each update, assuming that your features must therefore be what they want.