Book review: “The Fearless Organization” by Amy C. Edmondson

Before you read this review of “The Fearless Organization” by Amy Edmondson, I’d encourage you to watch Amy’s Tedx Talk in which she talks about how to build psychological safety. Edmondson is a management professor at Harvard Business School and has done a tremendous amount of work in the area of psychological safety.  In her Tedx Talk, she describes psychological  safety as “a shared belief that the team is safe for interpersonal risk taking.” I believe that psychological safety is a critical yet often overlooked concept, and one which underpins Edmondson’s latest book, The Fearless Organization – Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth.

 

 

These are the things that I took away from reading The Fearless Organization:

  1. Starting with “Personal and Organizational Change through Group Methods” – The aforementioned concept of psychological safety dates back to a 1965 book titled “Personal and Organizational Change through Group Methods” by Edgar Schein and Warren Bennis, which addresses the need for psychological safety for to help people cope with the uncertainty and anxiety of organizational change. Schein later noted that psychological safety was vital for helping people overcoming the defensiveness and “learning anxiety” they face at work, especially when something doesn’t go as they’d hoped or expected.
  2. Psychological safety isn’t a personality trait or difference – Based on her extensive research, Edmondson observes that psychological safety “is not a personality difference but rather a feature of the workplace that leaders can and must help create.” This observation made me think about the conditions that leaders can and must ‘enable’ to create a culture of psychological safety within the organisation, establishing a climate that supports learning. Edmondson mentions a number of other things which psychological safety is not, and which I’ve captured in Fig. 1 below.
  3. Measuring psychological safety – Perhaps you think of psychological safety as quite a fluffy idea, but it can actually be measured. I like the seven survey items which Edmondson introduced in her original research dissertation and which I’ve included in Fig. 3 below. She uses a seven-point Liker scale to obtain responses (from strongly agree to strongly disagree), and three out of seven items are expressed positively. Agreement with these items indicates greater psychological safety, whilst those items items expressed negatively (highlighted with an “R” for reverse), such that disagreement is consistent with higher psychological safety.
  4. Adopting an agile approach to strategy – I loved Edmondson’s point about viewing a company strategy as a hypothesis, to be tested continuously, rather than a plan. This perspective ties in with Edmondson’s broader theme around organisational learning. She argues that organisational learning – championed by company leaders but enacted by everyone – requires actively seeking deviations that challenge the assumptions underpinning a current strategy.
  5. Set the stage for psychological safety – In the book, Edmondson offers some useful tips with respect to ‘facilitating’ psychological safety, sharing a valuable toolkit (see Fig. 4 below).
  6. Proactive inquiry – Being able to say that you don’t know and driving participation through inquiry are two strong tenets of psychological safety. Edmondson shares some rules of thumb for asking a good question: one, you don’t know the answer; two, you ask questions that don’t limit responses to Yes or No, and three, you phrase the question in a way that helps others share their thinking in a focused way (see also Fig. 5 below).

Main learning point: In “The Fearless Organization”, Edmondson has written a valuable book about psychological safety. Even if you’re unable to create a truly fearless organisation anytime soon, Edmondson offers a number of valuable starting points with respect to critical aspects such as questioning, conflict and speaking up.

 

Fig. 1 – What Psychological Safety Is Not – Taken from: Amy Edmondson, The Fearless Organisation, pp. 15-19

  • Psychological safety isn’t about being nice – Working in a psychologically safe environment doesn’t mean that people always agree with one another for the sake of being nice. It also doesn’t mean that people offer unequivocal praise or unconditional support for everything you have to say. Psychological safety is about candour, about making it possible for productive disagreement and free exchange of ideas. Conflict inevitably arises in any workplace. Psychological safety enables people on different sides of a conflict to speak candidly about what’s bothering them.
  • Psychological safety isn’t a personality factor – Some have interpreted psychological safety as a synonym for extroversion. They might have previously concluded that people don’t speak up at work because they’re shy or lack confidence, or simply keep to themselves. Psychological safety, however, refers to the work climate, and climate affects people with different personality traits in roughly similar ways. In a psychologically safe climate, people will offer ideas and voice their concerns regardless of whether they tend to toward introversion or extroversion.
  • Psychological safety isn’t just another word for trust – Although trust and psychological safety have much in common, they aren’t interchangeable concepts. A key difference is that psychological safety is experienced at a group level. Further, psychological safety describes a temporally immediate experience.
  • Psychological safety isn’t about lowering performance standards – Psychological safety is not an “anything goes” environment where people aren’t expected to adhere to high standards or meet deadlines. It isn’t about becoming “comfortable” at work (see Fig. 2 below). Psychological safety enables candour and openness and, as such, thrives in an environment of mutual respect.

 

Fig. 2 – How psychological safety relates to performance standards – Taken from: Amy Edmondson, The Competitive Imperative of Learning, https://hbr.org/2008/07/the-competitive-imperative-of-learning

 

 

Fig. 3 – A survey measure of psychological safety – Taken from: Amy Edmondson, The Fearless Organisation, p. 20

  1. If you make a mistake on this team, it is often held against you. (R)
  2. Members of this team are able to bring up problems and tough issues.
  3. People on this team sometimes reject others for being different. (R)
  4. It is safe to take a risk on this team.
  5. It is difficult to ask other members of this team for help. (R)
  6. No one on this team would deliberately act in a way that undermines my efforts.
  7. Working with members of this team, my unique skills and talents are valued and utilised.

 

Fig. 4 – The leader’s tool kit for building psychological safety – Taken from: Amy Edmondson, The Fearless Organisation, p. 159 

Setting the stage:

Leadership tasks:

  • Frame the work – Set expectations about failure, and interdependence to clarify the need for voice
  • Emphasise the purpose – Identify what’s at stake, why it matters, and for whom

Accomplishes:

  • Shared expectations and meaning

Inviting participation:

Leadership tasks:

  • Demonstrate situational humility – Acknowledge gaps
  • Practice inquiry – Ask good questions and model intense listening
  • Set up structures and processes – Create forums for input and provide guidelines for discussion

Accomplishes:

  • Confidence that voice is welcome

Responding productively

Leadership tasks:

  • Express appreciation – Listen, acknowledge and thank
  • Destigmatise failure – Look forward, offer help. Discuss, consider and brainstorm next steps
  • Sanction clear violations

Accomplishes:

  • Orientation toward continuous learning

 

Fig. 5 – Attributes of a powerful question – Taken from: Amy Edmondson, The Fearless Organisation, p. 171

  • Generates curiosity in the listener
  • Stimulates reflective conversation
  • Is thought-provoking
  • Surfaces underlying assumptions
  • Invites creativity and new possibilities
  • Generates energy and forward movement
  • Channels attention and focuses inquiry
  • Stays with participants
  • Touches a deep meaning
  • Evokes more questions

 

Related links for further learning:

  1. https://www.businessinsider.com/amy-edmondson-on-psychological-safety-2015-11
  2. https://www.tandfonline.com/doi/abs/10.1080/00207284.1967.11642993
  3. https://hbr.org/2008/07/the-competitive-imperative-of-learning
  4. https://marcabraham.com/2017/08/17/book-review-radical-candor/
  5. https://www.huffingtonpost.com/matt-tenney/be-a-dont-knower-one-of-e_b_7242468.html
  6. https://hbr.org/2014/07/the-fukushima-meltdown-that-didnt-happen
  7. https://www.mindtheproduct.com/2018/05/how-to-improve-your-teams-conflict-competence-by-julia-whitney/
  8. https://marcabraham.com/2018/03/12/book-review-the-no-asshole-rule/

Book review: “Overcoming The Five Dysfunctions of a Team”

You might have come across “The Five Dysfunctions of a Team”. Patrick Lencioni, a consultant and speaker, wrote this seminal business book back in 2002. In this book, Lencioni identified the common root causes behind teams and companies underperforming:

Dysfunction #1: Absence of Trust:

The fear of being vulnerable with team members prevents the building of trust within the team.

Dysfunction #2: Fear of Conflict:

The desire to preserve artificial harmony stifles the occurrence of productive ideological conflict.

Dysfunction #3: Lack of Commitment:

The lack of clarity or buy-in prevents team members from making decisions they will stick to.

Dysfunction #4: Avoidance of Accountability:

The need to avoid interpersonal discomfort prevents team members from holding one another accountable.

Dysfunction #5: Inattention to Results:

The pursuit of individual goals and personal status erodes the focus on collective success.

Fig. 1 – Patrick Lencioni’s “The Five Dysfunctions of a Team” – Taken from: https://www.tablegroup.com/books/dysfunctions

 

I recently read Lencioni’s followup book to “The Five Dysfunctions”;  “Overcoming The Five Dysfunctions of a Team” is all about how to best solve common team dysfunctions. There a number of things one can do to overcome the different team dysfunctions that Lencioni identified all those years ago:

1. Building trust

Lencioni stresses the importance of trust: “no quality or characteristic is more important than trust.” Trust and vulnerability are closely interlinked, as Lencioni explains. Vulnerability-based trust comes from people not being afraid to admit the truth about themselves.

People being open and honest with themselves and each other, instead of wasting time and energy on politics. Building up this level of trust is by no means an easy feat or one off exercise. In contrast, it’s best to start small – with The Personal Histories Exercise, for example and continue maintaining trust.

Fig. 2 –  Patrick Lencioni’s “The Personal Histories Exercise” – Taken from: https://www.tablegroup.com/imo/media/doc/AdvantagePersonal_Histories_Excercise(4).pdf

2. Mastering conflict

Mastering conflict comes back to vulnerability-base trust, according to Lencioni. He explains that “When people who don’t trust one another engage in debate, they’re trying to win the argument.” In contrast, when vulnerability-based trust exist, team members say everything to each other that needs to be said and things don’t need to be discussed further behind closed doors.

Let’s make no mistake about it; conflict is supposed to feel a bit uncomfortable. Lencioni explains that if team members “never pushing one another outside of their emotional comfort zones during discussions, then it’s extremely likely that they’re not making the best decisions for the organization.”

Conflict Profiling is a great way to understand where you and your colleagues sit on the Conflict Continuum (see Fig. 3 below). What’s your appetite for healthy conflict? How does your appetite compare to Joe or Kathy’s on the team? Once you’ve figured out the different conflict profiles on the team and understand the differences, the best thing is to just talk about it within the team.

For example, what to me might feel like a good discussion, might to you feel like we’re butting heads … Once we understand our individual conflict profiles, we’re in a much better position to talk about how we best have a constructive discussion. One could, for example, agree that when we ask what might sound like difficult questions, these questions aren’t meant as personal attacks. Instead, these questions are only being asked because we want the best for the team, the business or the product.

Fig. 3 – Patrick Lencioni’s “Conflict Continuum” – Taken from: http://www.corporategames.com/whats-new/leadership-training/good-leaders-can-use-conflict-build-great-team/

3. Achieving commitment

The next dysfunction to overcome is the lack of commitment by team members. Lencioni makes the point that “commitment is not consensus.” There seems to be this misconception that everybody needs to agree intellectually on a decision, and that you’re bound for failure if you don’t … Lencioni argues the opposite: “Waiting for everyone on a team to agree intellectually on a decision is a good recipe for mediocrity, delay, and frustration.”

 

 

I totally agree with Lencioni’s points about most meetings being boring due to a lack of conflict. As counterintuitive as this may sound, I think we can all think of at least one regular meeting where we all just turn up and go through the mentions. However, meetings don’t have to be dull and unproductive.

In the words of Lencioni: “Team members can indeed become engaged in a meeting, but only when there is something at stake, a conflict worth caring about.” There is an important role for team leaders here, since they’re in great position to give team members a reason to care at the beginning of a discussion or a meeting.

In contrast, commitment is about “Buy-In”, defying a lack of consensus. It’s about getting a group of individuals to buy into a decision especially when they don’t naturally agree. Lencioni identifies two critical steps to achieve buy-in for a decision:

  1. Extract and explore team ideas – Good leaders drive team commitment by first extracting every possible, idea, opinion and perspective from the team. This is why I believe that good product leaders and managers need to be able to facilitate these open ended conversations or brainstorming sessions, especially since product people need to be able to influence without authority.
  2. Stick your neck out and decide – Once you’re comfortable that all options and perspectives have been explored, then the team leader needs to step up and make a decision. I know from experience that this is easier said than done, because our instinct is to try and get everybody to be happy about your decision. However, it’s unlikely that you’ll please everyone with your decision and that’s fine, as long as you explain the decision and why you made it – especially to those people with an opposite view. Lencioni refers to this process as “disagree and commit” and suggests the “Commitment Clarification” exercise to ensure that everyone in the team is clear about what exactly has been decided in the meeting or conversation (see Fig. 4 below).

Fig. 4 – Patrick Lencioni’s “Commitment Clarification” – Taken from: https://www.tablegroup.com/imo/media/doc/Commitment%20Clarification%20Exercise.pdf

4. Embracing accountability

Are you prepared to “enter the danger”? It’s the key question that comes out of Lencioni’s chapter about embracing accountability. Lencioni defines accountability as “the willingness of team members to remind one another when they aren’t living up to the performance standards of the group.” In an ideal world, this kind of accountability should be peer-to-peer and require the team leader to hold people accountable.

In reality though, and for peer to peer accountability to become the norm, the team leader needs to be prepared to call an individual on their behaviour or performance, and thus “enter the danger”. I totally agree with Lencioni where he observes that most leaders he knows “have a far easier time holding people accountable for their results than they do for behavioural issues.” This can be problematic because behavioural problems almost always precede results.

As daunting as it may seem at first, it is possible to have a constructive conversation about their behaviour. In my experience, the key is to be very specific about the behavioural issues that you’ve observed and describe the impact that these issues have caused (I highly recommend reading “Radical Candor” by Kim Scott if you’re keen to learn more about this topic).

The next step would be to run what Lencioni call a “Team Effectiveness Exercise”:

Fig. 5 – Patrick Lencioni’s “Team Effectiveness Exercise” – Taken from: https://www.tablegroup.com/imo/media/doc/AdvantageTeamEffectiveness_Exercise(8).pdf

 

5. Focusing on results

Lencioni raises the questions about what makes it so hard to stay focused on results? He answers the questions by talking about self-interest and self-preservation. To avoid these human pitfalls, Lencioni suggest the team picking one goal the whole team can focus on:

“On strong teams, no one is happy until everyone is succeeding, because that’s the only way to achieve the collective results of the group. Of course, this implies that individual egos are less important than team achievements.”

In this scenario, the team will know that it’s being successful when it accomplishes the results it sets out to achieve. This requires team members to prioritise team results over their individual or departmental needs. To stay focused, teams must publicly clarify their desired results and keep them visible.

Main learning point: “Overcoming The Five Dysfunctions of a Team” is a valuable resource for anyone interested in creating or being part of effective teams. In addition to studying the factors of successful teams, the book  offers a number of helpful exercises to overcome these dysfunctions.

Related links for further learning:

  1. https://www.tablegroup.com/books/dysfunctions
  2. https://www.tablegroup.com/books/overcoming-the-five-dysfunctions-a-field-guide
  3. https://www.tablegroup.com/imo/media/doc/AdvantagePersonal_Histories_Excercise(4).pdf
  4. http://www.corporategames.com/whats-new/leadership-training/good-leaders-can-use-conflict-build-great-team/
  5. https://www.truity.com/blog/personality-type-conflict-style
  6. https://www.tablegroup.com/imo/media/doc/Commitment%20Clarification%20Exercise.pdf
  7. https://www.tablegroup.com/imo/media/doc/AdvantageCascading_Communication_Exercise(6).pdf

My product management toolkit (30): giving and receiving feedback

I’ve got many, many flaws. Taking things personally is one of them … On one hand, I’m always going to ‘expose’ myself to feedback by trying, challenging and simply ‘doing’, expecting to be challenged and to receive feedback. On the other hand, however, every time that I do receive feedback – direct or indirect – I need to make sure I pause and listen carefully, taking the feedback in fully first.

i-dont-always-take-things-personally-oh-wait-yes-i-do.jpg

 

For example, the other day I found myself asking “why” a lot in a discussion about a customer problem and a colleague kept saying “let’s stop overcomplicating things, let’s just keep things simple.” Guess what I felt? I took it personally and wondered why she wasn’t as keen as I was to explore the problem in a bit more detail …

It made me realise again that feedback is crucial, and particularly for us as product managers:

  • We’re likely to give plenty of feedback.
  • And we’re likely to receive a whole lot of it too.

Giving feedback

As a product manager, I often find myself giving feedback to others, either about a behaviour or something that they’ve produced – for example:

  • A presentation, either in the making or delivered
  • A product thought, idea or prototype
  • One of my product managers failing to collaborate effectively with their product team members
  • Feeding back to colleagues in the senior leadership team about their ideas or decisions

When giving feedback, I believe it’s important to:

  • Have a think about what you’re going to say first – Many a time I’ve made the mistake where I’d just blurt out feedback in the moment. This can be ok when interacting with certain people, especially if you’re in a trusted relationship with them. However, the risk with this ‘in the moment’ approach is that your feedback might not be well thought through or constructive … Simply writing down a few bullet points can help to think through the essence of the feedback and how to best get that across.
  • It’s about the person’s behaviour, not about the person – Another common pitfall can be to focus your feedback on a person instead of their behaviour. Let’s, for instance, think of a scenario where you’ve observed a colleague being late a few times. Instead of saying “Ellen, why are you always so late?”, which makes it all about Ellen as a person, you could ask: “Ellen, I’ve noticed you being late for meetings over the last two weeks, do you mind if we have a chat about why that is?”
  • Be specific and timely when describing the behaviour – I strongly suggest avoiding sweeping statements or being very black and white when giving feedback. For example, compare these two examples: “Paul, your product ideas haven’t been clear” versus “Paul, when you suggested ideas for a new product feature last week, I missed detail about what the feature would entail and the assumed customer value the feature would bring.” In the latter example, the feedback provided is specific and offers a good starting point for conversation. Asking for permission in the form of “May I give you feedback?” can also be a friendly way to start the conversation.
  • Describe the (emotional) impact the behaviour had on you – When making your feedback specific, it helps to describe the impact the person’s behaviour has had on you. I think it’s important to steer clear of statements like “Richard, your lack of decision making in the last prioritisation conversation was frustrating for lots of people in the team” – which feels very broad brush and not fair on the recipient of your feedback since he/she won’t be able to clarify with the people you claim to be speaking on behalf of. Instead, I suggest saying something along the lines of “Richard,  your lack of decision making in the last prioritisation conversation made me feel directionless, as I don’t know how to best proceed from here.”
  • Consider the “S-B-I” framework – In essence, I strongly recommend looking at the “Situation, Behaviour, Impact” (‘S-B-I’) framework, as it offers a nice way of framing the feedback that you’re giving (see Fig. 1 below).

Fig. 1 – Situation, Behaviour, Impact framework – Taken from: https://www.ccl.org/articles/leading-effectively-articles/hr-pipeline-a-quick-win-to-improve-your-talent-development-process/

Receiving feedback

Going back to my earlier admission about take things personally, the way in which I receive feedback is critical for me. I’ve found that it can be easy to feel completely floored by the feedback received, instead of treating the feedback as an opportunity to learn and improve. Without saying that I find receiving feedback easy, I’ve learned to (pro) actively ask for feedback and guidance.

When receiving feedback, I believe it’s important to:

  • Listen with the intent to understand, not to respond – If you’re anything like me, i.e. not super comfortable with asking people for feedback, your initial response might well be to act defensively and respond to the criticism. In the great book “Radical Candor”, author Kim Scott urges us not to do that; don’t start criticising the criticism! Instead, she suggests saying something like “So what I hear you saying is …”
  • Ask for specifics – Try to understand when you displayed certain behaviours, what you could have done or said differently and why. To me, the whole point of asking for feedback is that you’ll be able to learn from the feedback received. When you receive and digest the feedback, you can decide to either to not act on it or to put your learnings into practice. Either way, it’s imperative that the feedback is specific, so that you can make a well informed decision on whether to act on it.
  • Express appreciation for the feedback and give yourself time to process – If you did get feedback, the next important thing is to follow up and show that you really welcomed the feedback. You don’t even need to respond straight away and mention the things that you’re going to do to implement the feedback. It’s perfectly fine to say “Thank you so much for your feedback. Let me take it away and reflect on it.” If you agree with what was said, you should make a change as soon as possible. If the necessary change will take time, do something visible to show you’re trying.

Main learning point: Giving or receiving feedback isn’t easy, and there’s no silver bullet available to make it any easier. However, tools like the “Situation, Behaviour, Impact” framework can help us to better frame the feedback that we’re giving. And when it comes to receiving feedback, I’ve found “listening” to be the most powerful tool of all.

Related links for further learning:

  1. https://marcabraham.com/2017/08/17/book-review-radical-candor/
  2. https://marcabraham.com/2018/02/18/my-product-management-toolkit-26-pause-and-listen/
  3. https://getlighthouse.com/blog/give-constructive-feedback-motivate-improve/
  4. https://www.youtube.com/watch?v=-oRKr5xA9N0
  5. https://www.mindtools.com/pages/article/situation-behavior-impact-feedback.htm
  6. https://www.fastcompany.com/3019036/simple-direct-honest-personal-and-blunt-how-the-5-word-performance-review-works-wonde
  7. https://www.inc.com/the-muse/how-to-give-constructive-criticism-employees-managers-useful-feedback.html

Book review: “The No Asshole Rule”

Do you consider yourself an asshole at times? Can you pinpoint moments where you felt – in retrospect – where you acted like an asshole? Apologies for the profuse use of the word “asshole”, I blame it on a great book I read recently: “The No Asshole Rule” by Bob Sutton. First published in 2007, Sutton describes what makes an asshole and offers tips on how to stop yourself from acting like one!

These are the main things I took away from reading “The No Asshole” book:

  1. What makes an asshole? – Sutton refers to a valuation by Bennett Tepper who studied psychological abuse in the workplace and introduced a useful definition for asshole behaviour: “the sustained display of hostile verbal and non verbal behaviour, excluding physical contact.”
  2. Do the asshole test – In the book, Sutton suggests two ways to test whether there’s an asshole at play or not. Firstly, after talking to the alleged asshole, does the ‘target’ feel oppressed, humiliated, de-energised, or belittled by the person. In other words, does the target feel worse about him or herself as a result? Secondly, does the alleged asshole aim his or her venom at people who are less powerful rather than at people who are more powerful?
  3. “Handle with care!?” – I like how Sutton cites research which shows how constructive arguments over ideas – NOT nasty personal arguments – drives greater performance. In order words, interacting effectively with others doesn’t mean that you’re not allowed to have a constructive debate or pose a constructive challenge. Harvard Business School professor Amy Edmondson talks a lot about how to best create psychologically work space. A strong sense of fear among employees or people feeling uncomfortable to speak up (especially with more senior people) can be signs of work spaces which don’t feel fully safe to the people that work in them.
  4. What to do when facing an asshole? “Small wins” – Research has shown that a feeling of control – even over the smallest aspect of your fate – can have a big impact on your wellbeing. Psychologist Karl Weick contends that aiming for ‘small wins’ is often a more comforting and ultimately more effective strategy than aiming for ‘big wins’. In the case of being exposed to assholes, Sutton suggests looking at small ways to reduce the interaction with assholes or other wise to seize a sense of control.

Main learning point: “Assholes are us” is one of the closing comments in Sutton’s book. If you want to create an asshole-free environment, you need start with having a long, hard look at yourself. A good friend of mine once encouraged me to think “how is that true of me?” every time I’d judge someone else or their behaviour. It means being able to stop your ‘inner asshole’ from coming out or you avoiding working at places with lots of assholes 🙂

 

Fig. 1 – “The Dirty Dozen – Common Everyday Actions That Assholes Use” – Taken from: Bob Sutton, “The No Asshole Rule”, p. 10

  1. Personal insults
  2. Invading one’s ‘personal territory’
  3. Uninvited physical contact
  4. Threats and intimidation, both verbal and non verbal
  5. ‘Sarcastic jokes’ and ‘teasing’ used as insult delivery systems
  6. Withering email flames
  7. Status slaps intended to humiliate their victims
  8. Public shaming or ‘status degradation’ rituals
  9. Rude interruptions
  10. Two-faced attacks
  11. Dirty looks
  12. Treating people as if they are invisible

Fig. 2 – What’s your Total Cost of Assholes to Your Organisation; factors to consider when calculating the total cost of assholes to your organisation – Examples taken from: Bob Sutton, “The No Asshole Rule”, pp. 44-46

  • Damage to victims and witnesses – For example: distraction from tasks; reduced psychological safety and climate of fear and loss of motivation;
  • Woes of certified assholes – Victims and witnesses hesitating to help; retaliation from victims and witnesses and long term career damage.
  • Wicked consequences for management – Time spent appeasing, calming, counselling or disciplining assholes; time spent ‘cooling out’ employees who are victimised and managing burnout.
  • Legal and HR management costs – Anger management and other training to reform assholes; legal costs for inside and outside counsel and health-insurance costs.
  • When assholes reign: negative effectives on organisations – Reduced innovation and creativity; reduced ‘discretionary’ effort and and dysfunctional internal cooperation.

 

Related links for further learning:

  1. http://bobsutton.typepad.com/my_weblog/the_no_asshole_rule/
  2. https://hbr.org/2007/03/why-i-wrote-the-no-asshole-rule
  3. http://journals.sagepub.com/doi/abs/10.1177/0149206307300812
  4. https://www.youtube.com/watch?v=4STnZm21–E

My product management toolkit (24): ‘pre-mortem’

As helpful as ‘post-mortem’ sessions can be, how often do you find yourself wondering: “if I’d only thought about that beforehand!” In a medical environment, a post-mortem creates the opportunity for health professionals and the family to establish the patient’s cause of death. With digital products, a post-mortem typically happens at the end of a project or after a big product release. It’s similar to Agile retrospectives which often take place more regularly; the goal is to reflect on areas for improvement and related actions.

With a pre-mortem, the idea is to think about a project or a piece of work before commencing it. A pre-mortem can be done either as a group or as an individual exercise, and participants need to imagine the product or project to have failed (see Fig. 1 below).

For example:

“This product has failed because nobody wanted to pay for it”

“The product was never released in the end because the regulator refused to approve the product and its underlying business model” 

“The product has failed because many of its users complained about its poor user experience”

“The product failed because we the design & build project had to be rushed in the end to get it over the line?”

A pre-mortem thus enables you to start working backwards, and look at the individual factors that could lead to failure as well as the actions to take in order to pre-empt failure. Once you’ve identified these factors, you can start thinking about how to best avoid or mitigate these risks from occurring.

Naturally, it’s up to you to figure out how to best structure your pre-mortem, but these are some aspects that you might want to consider:

  • The product has bombed – Rather than consider the possible failure of a product or a project, in the pre-mortem the product is assumed to have failed. Similarly, if you’re doing a pre-mortem at the start of a project, it’s really helpful if all the participants in the pre-mortem think of any reason why the project could fail dramatically.
  • Categorise failures – When getting people to think about the reasons for failure, I always find it helpful to think about failures in specific areas, dependent on your product, market or organisation (see Fig. 2 below).
  • Does this mean that nothing will go wrong!? – Of course, things will not go according to plan and unexpected things will still happen. However, right from the get go, you’re creating an environment that allows people to think about and continuously talk about risk. You’re effectively creating an environment where people can speak freely about potential risk scenarios, without fear of being seen as impolite or difficult.
  • Identify threats and risks – There are a number of ways to elicit risks and threats from the pre-mortem. You could do a simple ‘brain dump’ for example. Alternatively, you could try a more structured approach whereby people need to come up with risks within certain areas (see “Categorise failures” above).
  • Analyse likelihood – Once you’ve collated threats and risks, you can use a simple scale ranging from “highly unlikely” to “highly likely” to assess likelihood of a specific risk or threat materialising. I’ve found that the activity of placing risks against the aforementioned scale, helps creating a shared understanding of the biggest risks. It also focuses the mind on the actions that need to be taken or things that need to be in place to mitigate risk.
  • Are the right people in the room? – When running a pre-mortem session with a number of people, it’s important to make sure you’ve got the right people in the room. For example, if you’re looking to work on a digital product, it’s important to have developers and designers present. Similarly, if you’re working in a highly regulated industry, having a compliance person brainstorming upfront about potential risks will go a long way.
  • Brainstorm and assess preventative actions – Once you’ve collectively established your highest risks, you can start thinking about ways to mitigate these risks. Realistically, you might not be able to stop all risks from happening  (think about a garden party being impacted by a sudden rain downpour …). In these scenarios, you can still figure out how to best reduce the impact of a risk happening and come up with a ‘plan B’. For example, if the heavens open during your garden party, people could always seek shelter in the tent that you put up ‘just in case’.
  • Not a one off exercise! – The risks and actions that you identify during your pre-mortem are something that you can use as ongoing reference point. “How are we doing we against risk X?” or “We can see risk Y materialising soon, how can best pre-empt things?” A regular product retrospective offers a great opportunity to take a step back from the day-to-day and look at the risks involved with your project or product.

Fig. 1 – Pre-Mortem by Dave Gray – Taken from: http://gamestorming.com/pre-mortem/

Fig. 2 – Possible failure categories to consider:

  1. Marketing – Think upfront about what could go wrong with your product’s go-to-market strategy and the marketing channels that you’re looking to use. For example, what would be the impact be if product messaging fails to resonate with your target audience?
  2. Customer – What if customers don’t want to pay for our product? What if we’re addressing the wrong customer segment? What if we’ve got customer needs wrong?
  3. Technology – The chosen technology implementation doesn’t work, what do we do? The technology isn’t scalable!? At this stage, it’s very valuable to explore the complexities or unknowns related to the technical implementation. As a group, you might agree on running discovery sprints to test certain technologies or non-happy path scenarios to deal with some of the ‘unknown unknowns’ being discovered early on.
  4. Stakeholders – I know some people like stakeholder mapping, but the pre-mortem can also help in figuring out who the relevant stakeholders are and how they’d need to be communicated with. Also, when look at the different risk areas, it can be very helpful which stakeholders have the most knowledge in a particular domain.
  5. Cost – What if our budget gets slashed halfway through the project? What if costs spiral because we failed to budget properly? What if the technology we’ve chosen turns out to be far too expensive or complex to implement?
  6. Compliance – Compliance and regulatory aspects are easy ones to forget at the start of a project. However, compliance can have a massive impact on a product or a project. For instance, I was involved in a project where we only found out halfway through that launching in China would be very tricky from an internal compliance and external regulation point of view. This proved to be a major stumbling block and it would have been good if we could have identified this as a major project risk beforehand.
  7. Competition – What if your direct competitor launcheds the same product as yours, but just a bit quicker? Or we imagine a situation where the product has failed because the competitor lowered its product price. Do we need a plan B for when this scenario happens? If so, what should this plan look like?

Main learning point: Running a pre-mortem isn’t a substitute for fully planning projects upfront. You can do the best pre-mortem possible but things will still happen, and to which you’ll need to adapt. A good pre-mortem, however, will get people to think and be open about risk. It will help significantly in identifying and addressing risk early and often.

Related links for further learning:

  1. https://zapier.com/blog/project-retrospective-postmortem/
  2. https://www.cmcrossroads.com/article/when-postmortems-meet-retrospectives-improving-your-agile-process
  3. http://retrospectivewiki.org/index.php?title=Retrospective_Plans
  4. https://en.wikipedia.org/wiki/Pre-mortem
  5. https://hbr.org/2007/09/performing-a-project-premortem
  6. https://simplicable.com/new/premortem
  7. http://gamestorming.com/pre-mortem/
  8. http://www.springer.com/gb/book/9783319490663

My product management toolkit (22): how to create a product culture?

What can you do when you’ve joined a company that hasn’t (yet) got a proper product culture? Making it harder for you to do your job or get people’s buy-in. Unfortunately, this tends be harsh reality for a lot of product managers, who then become increasingly frustrated with a lack of progress or an unchanged mindset.

However, there’s no need to despair, as there are a number of techniques and tools to start instilling a product mindset and creating a product culture. In this piece, we’ll first define what product culture means and then explore ways in which you as a product manager can contribute to the creation of a product culture.

What is product culture?

Fig. 1 – Martin Eriksson, “What Is A Product Manager?” – Taken from: http://www.mindtheproduct.com/2011/10/what-exactly-is-a-product-manager/

If you look at the famous product management venn diagram by my friend Martin Eriksson it quickly becomes apparent how the three components of Martin’s diagram feed into my components of a strong product culture:

  • Customer understanding – We all know how easy it can be to pay lip service to ‘customer empathy’ or ‘understanding user needs’! However, a strong product culture begins and ends with your customers. In organisations with a strong product culture, all staff members interact with customers or are at least fully aware of their customer needs. Companies like Zappos and Amazon are well known for their focus on customer centricity factors (see Fig. 2 below). In my experience, signs of  non customer centric companies are those where only a small part of the business ‘owns’ the customer relationship or where the customer has become this imaginary persona for most staff members. Also, I encourage you to pose a healthy challenge to those people in the organisation who claim to “know what the customer wants” based on their experience.
  • Everything is geared towards creating great products – Throughout the company with a strong product culture one can find a strong sense of innovation, a desire to experiment in order to create great products. Etsy is a good example of a company that develops new products and services iteratively, constantly testing and improving on previous product releases. One of the telltale signs of a strong product culture is when employees possess what Marty Cagan refers to as a product mindset (see Fig. 3 below).
  • Value proposition and business model – A shared understanding of your business’ value proposition and business model is a clear sign of a good product culture. Alignment around the value you’re aiming to provide to your customers – combined with an awareness of who those customers are – is a critical part of a strong product culture, as it underpins the products and services that you put out there.
  • Curiosity and experimentation – You know that things could get challenging if you, as a product manager, turn out to be one of the few people in an organisation to ask ‘why’ and be curious. These are traits that can be learned and adopted, and the more innovative and customer centric businesses are those that aren’t afraid to be curious, learn and ‘fail well’. I heard a colleague of mine phrasing it quite well the other day when he spoke about “taking calculated risks”. In other words, taking risks in such way that you learn a lot – quickly and cheaply – about your riskiest assumptions, whilst any negative ramifications are limited or non-existent.

 

Fig. 2 – Steven MacDonald, How to Create a Customer Centric Strategy for your Business – Taken from: http://www.superoffice.com/blog/how-to-create-a-customer-centric-strategy/

 

Fig. 3 – Marty Cagan, Product Mindset vs IT Mindset – Taken from: http://svpg.com/product-vs-it-mindset/

  1. Purpose.  In an IT mindset organisation, the staff exists to service the perceived technology needs of “the business.”  In a technology-enabled product organisation, the staff exists to service the needs of your customers, within the constraints of the business.
  2. Passion.  In an IT mindset organisation, product and technology are mercenaries.  There is little to no product passion.  They are there to build whatever.  In a product organisation, product and tech are missionaries.  They have joined the organisation because they care about the mission and helping customers solve real problems.
  3. Requirements.  In an IT mindset organisation, requirements are “gathered” from stakeholders, prioritised in the form of roadmaps, and implemented.  In a product organisation, we must discover the necessary problem to solve or product to be built.
  4. Staffing.  The IT mindset shows up very visibly in the staff and the roles.  The lack of true product managers (especially strong product managers), the lack of true interaction designers, the prevalence of old-style project management, engineers unfamiliar with the demands of scale and performance, the existence of old-style business analysts, and heavy use of outsourcing, are all clear examples of this.  I would argue the most telling manifestation of the IT mindset problem is that the product managers in IT mindset companies are typically very weak, and at true product companies they are necessarily very strong.
  5. Funding.  In IT mindset companies you find them still funding projects (output) rather than product teams measured by business results (outcome).   There are many serious problems with this antiquated model, and it generates all kinds of bad behaviour in the organisation as they try to work around the constraints of this system, but most importantly, it results in very poor ROI for the company because of the very high cost of finding out which ideas work and which don’t.
  6. Process.  In IT mindset companies, you usually find very slow, heavy, Waterfall processes, even when the engineers consider themselves Agile.  The only part that would be considered Agile would be at the tail end of build, test and release.  Much of this stems from the Funding issue above, but deciding what areas to invest in, staffing a team, defining and designing the solution, and release planning are all typically very Waterfall.  Technology-enabled product organisations simply must move much faster, and work differently, in order to deliver the necessary solutions for our customers and our business.
  7. Silos.  In IT mindset companies, people align by function, creating silos between the different areas of the business, product, user experience design, engineering, QA and site operations.  In contrast, in a product organisation, we depend on true collaboration between product, user experience design, technology and the business units.  In a product organisation we optimise for product teams, not for the individual functions.
  8. Organisation.  In IT mindset companies, engineering is often under a CIO, and “product” (if it exists at all) is often under marketing or absorbed directly in the business units themselves.  In product organisations, there’s a big difference between the engineers that support “true IT” and those that work on the commercial products,  The True IT engineers usually report to the CIO, and the commercial product engineers report to a CTO.  Similarly, product is not a sub-function of marketing.  It is a top-level activity on par with marketing and technology.  It is not so much the org chart that matters here, as much as a recognition that the way we manage True IT work is very different than how we manage commercial product efforts.
  9. Accountability.  In IT mindset companies, accountability frankly is a farce.  The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due.  In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault.  So management writes it off as yet another failed technology initiative.  In contrast, in a product organisation, we are measured by results.
  10. Leadership.  As with so many things, much of this boils down to leadership.  In IT mindset companies, the technology is viewed as a necessary evil.  It is a source of fear more than a source of inspiration.  Leadership in IT mindset companies is always looking for a silver bullet when it comes to technology.  Maybe they should outsource the whole mess?  Or maybe they can acquire someone else that hopefully has a better track record than they do.   In contrast, in a product company, technology enables and powers the business.  It is embraced and valued.  The people that create the technology are respected as the key contributors they are.  Leadership in a commercial product company understands that it’s their job to create the culture and environment necessary to nurture continuous innovation.

Where to start?

As daunting it may sound, starting to create a product culture doesn’t have to be overly complicated or onerous. As always, my advice is to smart small. Kick things off with some simple but targeted initiatives:

  • A visioning workshop to create a shared product vision – A product culture starts with a shared vision of what the product is (not), and what we’re trying to achieve with it for our customers and our business. Lack of a shared vision usually manifests itself in a product that wants to be too many things to too many people. As a product manager you can drive both the creation and the shared understanding of a product vision, starting with the facilitation of a visioning workshop.
  • Agree on a mission statement (and make sure it’s omnipresent) – Whereas a product vision is typically more aspirational and future oriented, a mission statement is all about the problems your business is aiming to solve right now (see Fig. 4-5 below).
  • Live and breathe clear values that underpin your (product) culture – Naturally, every organisation will have its own unique values – both explicit and implicit. However, there are a number of values that I believe underpin most product cultures: curious (see above under “what is product culture?”), courageous, innovative, open, trying and learning. Formulating and agreeing on such values is the easy part; truly embodying them on a daily basis tends to be much harder. For example, within my current product team, we’ve got a ‘team manifesto’ which encapsulates our core values and principles, and we use this as a living reference point, asking ourselves regularly whether we’re actually living up to our principles.
  • 5 simple ways to become more customer centric – Especially if you find yourself in a business with an IT mindset (see Fig. 3), bringing the customer into the picture can be difficult. However, I’ve discovered and applied five simple techniques that have helped me in making organisations and colleagues to think more about the customer and their needs (see Fig. 6).
  • Hire and fire for the right behaviours and values – A successful product culture depends heavily on the people within the organisation. This means that when you’re hiring product people, you’ll be looking for some of the key values that underpin your product culture. For instance, when I recruit new product people, I always try to filter out any ‘product janitors’ as quickly as I can, simply because it doesn’t fit with the values that I’m trying to instil into my product teams. Equally, this also implies that you sometimes need to make tough decisions and fire those employees who might be great people but don’t form a good fit with your product culture and its underlying values (see above).
  • Clear goals, celebrate success and failure – Outcomes over outputs. I understand people’s obsession with certain features or ideas, but I believe that businesses benefit from a continuous focus on goals and problems instead of of fretting over features. I’ve found a goal-oriented roadmap to be a great tool in terms of driving an understanding of common goals.
  • Continuous learning – In my experience, the ‘learning’ aspect comes from continuously exploring different ways to tackle a problem, celebrating success as well as reflecting on the ‘failures’. The more you can share these learnings with the wider organisation, the better. This helps in creating a culture where there’s full transparency with regard to both achieved results as well as those things that didn’t go according to plan. In turn, this breeds a culture of experimentation, taking calculated risks, experimenting and being open about the outcomes, whatever they are.

 

Fig. 4 – Elements of a mission statement:

For (target customer)

Who (statement of the need or opportunity)

The (product name) is (product category)

That (key benefit, compelling reason to buy)

Unlike (primary competitive alternative)

Our product (statement of primary differentiation)

 

Fig. 5 – Mission statement examples from Patagonia and Cradles to Crayons – Taken from: https://blog.hubspot.com/marketing/inspiring-company-mission-statements

 

Fig. 6 – How do we become more customer centric – Five simple ways to get there:

  1. 5 customers every fortnight – User research and usability testing don’t have to part of massive projects, getting input from thousands of customers. In contrast, engaging with 5 (target) customers every two weeks goes a long way in my experience. It gives you an opportunity to learn continuously, in tandem with your development work and product / feature releases.
  2. Team based user research – I learned from UX expert Erika Hall about the importance of collaborative or team based research. The key point here is that user research isn’t a one person job. People across the business will benefit from learning from and about their customers.
  3. Exposure hours – Similar to team based user research, the idea behind so-called exposure hours is to share customer learnings directly with team members and stakeholders, by them sitting in on a user interview for example and being directly exposed to customers.
  4. Feeling what users feel – In my previous company, Notonthehighstreet, we had a programme called “In Your Shoes” which meant that all employees had to spend one day at a customer and be part of their businesses and lives for a day. It was a great to experience first hand the problems and needs customers have, and understand their contexts better.
  5. Product retrospectives – Finally, I’ve found product retrospectives to be a great way of instilling a more customer focused mindset. Regular product retrospectives are a great opportunity for a team and the wider business to reflect on its products or services. How are our products performing? What did we release last month and how is that release doing? What are our customers saying, thinking and feeling? Product retrospectives are explicitly not about the team or process improvements. Instead it’s all about the product and its users.

Main learning point: Creating a product culture is by no means easy but as a product manager there are number of tools and techniques one can use to instil a product mindset and a more customer-centric approach.

Related links for further learning:

  1. https://www.slideshare.net/abrahammarc1/how-to-create-a-product-culture
  2. http://svpg.com/establishing-a-true-product-culture/
  3. https://www.slideshare.net/reed2001/culture-1798664
  4. https://medium.com/we-are-yammer/onboarding-as-a-product-manager-cc7ad1d618c9
  5. https://www.quora.com/What-companies-have-a-strong-product-management-culture-and-how-do-they-achieve-it
  6. http://www.walkingthetalk.com/zappos-customer-centric-culture/
  7. http://www.superoffice.com/blog/how-to-create-a-customer-centric-strategy/
  8. https://leanstartup.co/heres-how-5-companies-create-remarkably-innovative-cultures/
  9. https://apptimize.com/blog/2014/01/etsy-continuous-innovation-ab-testing/
  10. http://www.svpg.com/the-product-manager-contribution/
  11. https://blog.hubspot.com/marketing/inspiring-company-mission-statements
  12. https://articles.uie.com/user_exposure_hours/
  13. http://www.tommyandlottie.com/in-your-shoes
  14. https://hbr.org/2012/11/its-not-just-semantics-managing-outcomes
  15. https://www.playbookhq.co/blog/lean-product-development-positive-economics-of-failing-fast
  16. http://www.cleverpm.com/2015/08/25/fail-fast-fail-cheap-and-fail-often/
  17. https://techcrunch.com/gallery/internet-trends-2017/

Jeff Gothelf and Lean UX

In case you don’t know, I’m a big advocate of “Lean UX” and the work of Jeff Gothelf on this topic. It was Jeff who originally coined the term ‘Lean UX’ and wrote a great book about it, together with Josh Seiden. In short, Lean UX is all about not doing all your product design upfront, designing in more iterative fashion instead. I recently attended a talk by Jeff in London, where he talked about the concepts behind Lean UX, and here’s what I learnt:

  1. Cut out the design phase – Jeff stressed that the traditional design phase, where design is done in isolation, needs to go. I totally agree. Far too often designs are being thrown over an imaginary fence and implemented in a way that didn’t match the desired user experience, as intended by the designer. Instead, designers and developers should collaborate around ‘transient artefacts’, a simple sketch or prototype (see Fig. 1 below), in order to come to a shared understanding. These artefacts are by no the finished article, but create a shared understanding of what we’re looking to achieve and why.
  2. So what!? – The main idea about being ‘lean’ and ‘Lean UX’ is to “do less, more often.” Instead of just focusing on shipping features as often as you can, Jeff argued that the goal should be to achieve specific user outcomes as frequently as possible. I can imagine that this means a change in mindset and approach for some product teams. I believe, however, the ability to constantly ask the question “so what!?” from a user’s perspective is critical to building successful products. Whether you ship 2 or 50 features per iteration, this becomes totally irrelevant if you’re not changing customer behaviour.
  3. Humility and risk mitigation – I personally believe that as a product persona, you need to have a healthy degree of humility, and Jeff addressed ‘humility’ within the context of assumptions. He acknowledged how hard it can be for all of us to admit that we don’t know what the end state of a product or solution is going to look like, especially when you haven’t spent months creating a full product specification upfront. However, this is a risk that can be mitigated by being humble, acknowledging that you’re making assumptions and picking the riskiest assumptions to test first. In practice this will mean that you’ll be doing user research and getting feedback as part of each iteration.
  4. Change definition of “DONE” – Instead of just taking a feature release as the final stage of the definition of “DONE”, Jeff suggested that “changing customer behaviour” should be the ultimate definition of DONE. You pick a tactical metric that reflects the impact that the product is looking to make on customer behaviour. For example, you focus on a leading indicator to represent ‘customer intent’ or ‘conversion’ and something is only considered DONE if you’re moving the needle on your chosen metric (see Fig. 3 below).

Main learning point: I always learn something new from Jeff Gothelf and it felt no different with his recent talk in London. The main thing I took away from his talk was the importance of focusing on user outcomes instead and changes in user behaviour, as opposed to just shipping features.

Fig. 1 – Visual depiction of a transient artefact – Taken from: http://www.jeffgothelf.com/blog/you-dont-need-a-ux-portfolio/ 

ixdPortfolio_blog_image

 

Fig. 2 – Acknowledge that we’re making a lot of assumptions when building products – https://medium.com/the-job-to-be-done/replacing-the-user-story-with-the-job-story-af7cdee10c27

Assumptions

 

Fig. 3 – Build-Measure-Lean and Think-Make-Check – Taken from: http://www.smashingmagazine.com/2012/10/lean-startup-is-great-ux-packaging/

Think Make Check

 

IMG_2814 (1)

 

Related links for further learning:

  1. http://www.jeffgothelf.com/blog/you-dont-need-a-ux-portfolio/
  2. https://medium.com/the-job-to-be-done/replacing-the-user-story-with-the-job-story-af7cdee10c27
  3. https://www.uie.com/brainsparks/2015/07/17/jeff-gothelf-discover-what-customers-really-want-with-lean-ux/
  4. http://www.smashingmagazine.com/2011/03/lean-ux-getting-out-of-the-deliverables-business/
  5. http://www.smashingmagazine.com/2012/10/lean-startup-is-great-ux-packaging/