Category: Agile

Book Review: “Shape Up” by Ryan Singer

marcabrahamLeave a comment

Basecamp is a project management and communication platform, widely known for its innovative software development practices and novel ways of working. Ryan Singer, Basecamp’s Head of Strategy, recently captured Basecamp’s approach in Shape Up, which is freely available online and as a PDF. The product development process at Basecamp consists of three distinct stages: shaping, betting and building.

Taken from: https://basecamp.com/shapeup/4.1-appendix-02

Basecamp typically work in six-week cycles, building and releasing new features within that timeframe. The work is shaped first before it’s given to a team to work on. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before considering a project ready to bet on. Interestingly, shaping is less about traditional estimation of development work, and much more about appetite. Instead of asking how much time it will take to do some work, people at Basecamp will consider how much time they want to spend on a specific piece of work; how much is this idea worth?

Taken from: https://basecamp.com/shapeup/4.1-appendix-02

 

Shaping

When shaping a solution, the aim is to strike the right balance between ‘too vague’ and ‘too detailed’. Wireframes are deemed too concrete, whilst words are often too abstract. The reason why this balance is important is that the scope of a project needs to be flexible enough for the team to come up with appropriate design solutions whilst not running the risk of growing out of control due to a lack of boundaries.

Taken from: https://basecamp.com/shapeup/1.1-chapter-02

These are the main steps to shaping:

  1. Set boundaries – First figure out how much time the raw idea is worth and how to define the problem. This provides the basic boundaries to shape into.
  2. Rough out the elements – Then comes the creative work of sketching a solution. At Basecamp, they do this at a higher level of abstraction compared to wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.
  3. Address risks and rabbit holes – Once there is the feeling that a solution has been found, the goal is to find holes or unanswered questions that could trip up a team. The solution gets amended accordingly, tricky things removed from it, or specified details at tricky spots to ensure that a team doesn’t waste time or gets stuck.
  4. Write the pitch –  When the solution is shaped enough to bet on, things are packaged up formally in a pitch. The pitch summarises the problem, constraints, solution, rabbit holes, and limitations. The pitch then goes to Basecamp’s betting table for consideration.

Ryan Singer writes about how Basecamp uses the technique of breadboarding, a concept borrowed from electrical engineering. When breadboarding, three things are drawn:

  1. Places – These are things you can navigate to, like screens, dialogs, or menus that pop up.
  2. Affordances – These are things the user can act on, like buttons and fields. Interface copy is considered to be an affordance too, as reading it is an act that gives the user information for subsequent actions.
  3. Connection lines – These show how the affordances take the user from place to place.

I like how words are used instead of pictures, focusing on the solution’s components and the connections between them and allowing you to figure out an idea. Importantly, this technique allows you to judge if the sequence of actions serves the use case you’re trying to solve.

Taken from: https://basecamp.com/shapeup/1.3-chapter-04

 

If the idea being considered is a visual one. In this case, breadboarding would be insufficient because the visual representation is the fundamental problem. At Basecamp, wireframes wouldn’t be created in this circumstance, but fat marker sketches would be created instead. A fat marker sketch is a sketch made with such broad strokes that adding detail is difficult or impossible.

 

Taken from: https://basecamp.com/shapeup/1.3-chapter-04

 

Bets, Not Backlogs

Singer explains how at Basecamp backlogs are viewed as time wasters; the time spent constantly reviewing, grooming and organising ‘tickets’, working on a list of items that might or might not get done. By contrast, Singer talks about holding a betting table before each six-week cycle. At the betting table, stakeholders evaluate pitches from the last six weeks, or any pitches that somebody purposefully revived and lobbied for again.

 

Taken from: https://basecamp.com/shapeup/2.2-chapter-08

 

The betting table at Basecamp consists of the CEO, the CTO, a senior developer and product strategist (Ryan Singer himself). The main reason why Basecamp use bets instead of plans, is the difference in expectations set when talking about bets:

  • Bets have a payout – Solutions are deliberately shaped into six-week projects so that there’s meaningful finished at the end. The pitch defines a specific payout that makes the bet worth making.
  • Bets are commitments – If a bet is made for six weeks, then the relevant people will get six weeks to work exclusively on that thing for six weeks, without distractions.
  • Bets have a cap on the downside – When a bet is made to work on something specific for six weeks, the most that you can lose is six weeks and thus avoiding a situation where you’re spending multiples of the original six-week commitment on a solution.

Build your way uphill

                     Taken from: https://basecamp.com/shapeup/3.4-chapter-12#build-your-way-uphill

 

This section of “Shape Up” starts with a great and very true point about the unpredictability of development work: “This goes back to the notion of imagined versus discovered tasks. In our naive notion of a list that’s planned up-front, somebody populates it with items that are gradually checked off. In real life, issues are discovered by getting involved in the problem. That means to-do lists actually grow as the team makes progress.” Also, numeric estimates of pieces of work often don’t take into account the level of uncertainty involved in different tasks. Basecamp have recognised this and instead use the metaphor of the hill, which concentrates on what’s unknown and what’s solved:

 

                      Taken from: https://basecamp.com/shapeup/3.4-chapter-12#build-your-way-uphill

 

The idea behind this hill is that anyone in the company can see at a glance where things are at. If a task been ‘uphill’ for while, why is that? What unknown is holding it up? Or perhaps the item on ten hill consists of a number of smaller items. The hill helps to see what is stuck and what has been done, or getting close to being completed.

Conclusion: I found “Shape Up” a very helpful and insightful book. Not only does it provide a great insight into Basecamp’s approach to developing products, it also made me reflect on my own ways of working – and the teams that I’m part of. Highly recommend reading “Shape Up” if you’re interested in learning about alternative ways of developing software products or collaborating during the product development lifecycle.

 

Book Review: “Unlearn” by Barry O’Reilly

marcabrahamLeave a comment

“Disruption does not actually apply to organisations. The truth is it applies to individuals.” states Barry O’Reilly early on in Unlearn: Let Go of Past Success to Achieve Extraordinary Results. O’Reilly goes on to explain what great leaders and their companies have in common: a capability within themselves to innovate, adapt, and anticipate the future. Barry O’Reilly is a business advisor, entrepreneur, and author who operates at the intersection of business model innovation, product development, organisational design and culture transformation.

In order to adjust, O’Reilly argues in his latest book, we’ll need to unlearn, which starts with acknowledging that what you’re doing isn’t working for you. You need to let go of past viewpoints or behaviours, and take action to do what’s needed to progress. The Cycle of Unlearning contains four distinct steps to go through each time we need to adapt and innovate.

Barry O’Reilly, The Cycle of Unlearning

 

Step 1: Unlearn – Unlearning starts with the recognition that what we’re doing isn’t working. The core premise of “Unlearn” is a strong willingness to learn and to unlearn those behaviours and mindsets which once served us successfully. The first step in the process of unlearning requires courage, self-awareness, and humility to accept  that your own beliefs, mindsets, or behaviours are limiting your potential and current performance and that you must consciously move away from them.

Step 2: Relearn – O’Reilly makes the point that as you unlearn your current limiting but ingrained methods, behaviours, and thinking, you can take in new data, information, and perspectives. This is the process of relearning, which comes with its own challenges: (1) you must be willing to adapt and be open to information that goes against your inherent beliefs (2) you may need to to learn how to learn again and (3) you must create an environment for relearning to happen in a meaningful, yet often challenging, space outside your existing comfort zone. The point of relearning is that you’re trying to get better information and learn to see, sense, and listen differently, to respond and act differently.

Step 3: Breakthrough – Breakthrough is the net result of unlearning and then relearning. O’Reilly stresses in his book that breakthrough isn’t simply a matter of telling people to think differently, with the expectation that they will act differently as a result. Instead, the way to think differently is to act differently. This isn’t a one off event; it’s continuous and a deliberate practice or habit in its own right, often triggered by specific unlearning prompts:

  • Where are you falling short of your expectations?
  • Where are you not seeing the outcomes you want?
  • What are you willing to do to affect those outcomes?
  • How could you get out of your comfort zone and succeed?
  • What would thinking BIG but starting small be for you?

In the book, O’Reilly outlines what he sees as the four necessary conditions of unlearning:

  1. Identify a challenge you wish to address – Pick a challenge you want to tackle and don’t worry about waiting for the right moment to do so. O’Reilly suggests that the best place to start is where you’re right now.
  2. Define success as though you have dissolved or conquered the challenge – What are the behaviours you, your team, or your customers would be exhibiting to confirm that you had addressed that challenge and not only solved it, but dissolved it forever?
  3. Channel courage over seeking comfort – O’Reilly makes the point that seeking comfort over courage often results in taking the easy option of avoiding situations where you feel you’re not in control of the outcome. As a result, you’re stuck in the status quo and not growing. Whilst not easy to do, moving outside your comfort zone requires courage and a willingness to be vulnerable.
  4. Commit to, start, and scale the cycle of unlearning – Once the three previous conditions are in place, it’s important to commit to moving forward through the Cycle of Unlearning and to do so continually (see above).

Helpfully, O’Reilly has included necessary conditions for relearning and breakthrough too. Reflection, for example, is a necessary condition for relearning. Continuously reflecting on what has happened will lead to valuable, breakthrough moments and insights. You break through by stepping back and reflecting on exactly what it is that you’re doing and the results your effort is yielding.

 

Main learning point: Having not really thought about the concept about unlearning before, Barry O’Reilly’s book provided much clarity about discarding old beliefs or approaches and replacing them with new ones. Never does the book feel like unlearning is a silver bullet that will magically solve all your learning or innovation challenges. Instead, O’Reilly pains a realistic picture of the courage required to unlearn, and the ongoing nature of un- and relearning.

 

Book review: “High Output Management” by Andrew Grove

marcabrahamLeave a comment

“High Output Management” by the late Andrew Grove, ex Chairman and CEO of Intel, is a must read management book in my opinion. It’s easy to be quite cynical about most management and business books as a lot of them seem to introduce one central theme (or buzzword) right at the beginning of the book, followed by endless repetition throughout the remainder of the book …

 

 

In contrast, “High Output Management” contains valuable advice and tips from the beginning right to the end of the book. First published back in 1983, the book applies production principles to management. Some of these principles really resonated with me and I feel strongly about all (product) managers benefiting from these principles as part of their day-to-day working practices:

Identifying the “limiting step” – Grove defines the “limiting step” as the step in the overall shape of the production flow that will determine the overall shape of a company’s operations. In the book, Grove uses the simple example of a breakfast company, and highlights the time required to boil an egg is the critical component or the ‘limiting step’ in the production flow (see Fig. 1 below). The key idea here is to construct your production flow by starting with the longest (or most difficult, or most sensitive, or most expensive) step and work our way back. As a (product) manager you’ll thus focus on the limiting step within your context, e.g. in the workflow of your team, the customer funnel or the decision-making process.

 

Fig. 1 – Example of a limiting step when creating a breakfast – Taken from: http://clarkeching.com/ccblog/2018/1/21/what-are-bottlenecks-andy-grove

 

Detect and fix issues at the “lowest-value stage” possible – If there’s a problem with your product, you want to find out about it as early on in the production process as possible so that you can minimise risk. In the production world, I witnessed lowest-value stage thinking first hand at the assembly line of a Toyota factory. Here, employees can pull the   “Andon” cord to (temporarily) bring things to a halt as soon as they come across an issue. It’s an easy way of escalating things, making sure that a problem or bottleneck is dealt with before proceeding with the rest of the assembly process. Think about when you last pulled an imaginary Andon cord to flag a product or team issue early!?

 

Fig. 2 Using the Andon cord to raise an issue and stop production – Taken from: https://www.lean.org/lexicon/fixed-position-stop-system

 

 

Using (leading) indicators to measure and predict – In order to run a production process well you’ll need a set of indicators which help you monitor and improve the efficiency of the production line. Grove stresses that for these indicators to be useful, “you have to focus each indicator on a specific operational goal.” He goes on to list a number of relevant production indicators (see Fig. 3 below). Leading indicators give you one way to look inside the production process by showing you in advance what the future might look like.

 

Fig. 3 – Indicators related to the production process – Taken from: Andrew S. Grove, “High Output Management”, p. 16:

  • Sales forecast
  • Raw material inventory
  • Manpower
  • Quality

 

Leverage – Grove introduces the concept of “leverage”.  This is the output generated by a specific type of work activity. An activity with high leverage will generate a high level of output; an activity with low leverage, a low level of output. This raises the question about what qualifies as managerial leverage and output. Grove’s distinction between activities and output really helps to bring the concept of leverage to life (see Fig. 4 below). The overarching idea is that with each activity that the manager performs, the organisational output should increase.

 

Fig. 4 – Managerial activities vs output – Taken from: Andrew S. Grove, “High Output Management”, pp. 39 – 54:

Managerial activities:

  • Judgments and opinions
  • Direction
  • Allocation of resources
  • Mistakes detected
  • Personnel trained and subordinates developed
  • Courses taught
  • Products planned
  • Commitments negotiated

Managerial output:

A manager’s output is the output of all of the people and the teams that report into her. For example, if someone manages a design team, then his output consists of completed designs that are ready to be implemented.  That output can take many different forms depending on the type of role and industry. Regardless of the form of output, managers must measure its quantity and quality:

A manager’s output = The output of his organisation + The output of the neighbouring organisations under his influence

 

High leverage activities – We’ve already touched on the impact of highly leveraged activities on an organisation’s output, and Grove explains how these activities can be achieved (see Fig. 5 below). For example, to maximise the leverage of his or her activities, a manager must keep timeliness firmly in mind. Equally, managers micro-managing or ‘meddling’ are examples of negative leverage activities. A big part of a manager’s work is to supply information and know-how, and to share a sense of the preferred method of handling things to the teams under his control or influence. A manager also makes and helps to make decisions.

 

Fig. 5 – Three ways in which to achieve high leverage activities – Taken from: Andrew S. Grove, “High Output Management”, pp. 54 – 55:

  • When many people are affected by one manager.
  • When a person’s activity or behaviour over a long period of time is affected by a manager’s, well focused-set of words or actions.
  • When a large group’s work is affected by an individual supplying a unique, key piece of knowledge or information.

 

Applying production principles to management – In the book, Grove rightly points out how time management techniques are commonly used to improve managerial output. He then uses production principles to improve on some of these time management techniques (see Fig. 6 below).

 

Fig. 6 – Ways to improve on time management techniques – Taken from: Andrew S. Grove, “High Output Management”, pp. 62 – 63:

  • Identify our limiting step: determine which things that have to happen on a schedule that’s absolute, and which can’t be moved. You can then plan more flexible activities around it and thus work more efficiently.
  • Batching similar tasks: group similar activities, e.g. performance reviews, as these activities tend to require (mental) set-up time. You can thus maximise the set-up time needed for the task and reduce duplication of effort.
  • Forecasting your activities: Your calendar can be a valuable production-planning tool (and not a dumping ground for random meetings or “orders” by others). If you want to use your calendar as better forecasting and planning tools, Grove suggest that two conditions should be met. Firstly, you should move toward the active use of your calendar, taking the initiative to fill the holes between the time-critical events with non-time critical though necessary activities. Secondly, you should say “no” at the outset to work beyond your capacity to handle.

 

Meetings, the output of managerial work – A lot of managerial tasks (see “High leverage activities” above) are best suited for face-to-face interactions, and more often than not, for meetings. Grove provides a useful distinction between two basic kinds of meetings: process-oriented and mission-oriented meetings (see Fig. 7 below). I love how at the end of the book’s chapter about meetings, Grove reminds us of a quote by the late management guru Peter Drucker who said that “If people spend more than 25 percent of their time in meetings, it’s a sign of malorganisation.”

 

Fig. 7 – Process-oriented and mission-oriented meetings – Taken from: Andrew S. Grove, “High Output Management”, pp. 72 – 87:

  • Process-oriented meetings: Knowledge is shared and information is exchanged during process-oriented meetings, which take place on a regular, scheduled basis. One-on-ones and team meetings are good examples of process-oriented meetings.
  • Mission-oriented meetings: The purpose of mission-oriented meetings is to solve a specific problem and often produce a decision. These meetings are ad hoc affairs, not scheduled long in advance, because they usually can’t be. The key to the success of a mission-oriented meeting is what the chair of the meeting does. The person leading the meeting needs to have a clear understanding of the meeting’s objective – what needs to happen and what decision needs to be made.

 

 

Planning: today’s actions for tomorrow’s output – In High Output Management, Grove offers three simple steps of a  planning process (see Fig. 8 below). He describes planning as an ordinary everyday activity, something we all do – both in our professional and personal lives. The planning process enables you to reflect on what’s needed, the gap with the current situation and the specific actions necessary to close the gap.

 

Fig. 8 – Three steps your planning process should consist of – Taken from: Andrew S. Grove, “High Output Management”, pp. 103 – 120:

Step 1 – Establish projected need or demand: What will the environment demand from you, your business, or your organisation?

Step 2 – Established your present status: What are you producing now? What will you be producing as your projects in the pipeline are completed? 

Step 3 – Compare and reconcile steps 1 and 2: What more (or less) do you need to do to produce what your environment will demand?

 

Main learning point: “High Output Management” is probably one of the most valuable management books I’ve read in the last couple of years. If you’re looking for an inspiring but practical book about management, I suggest you look no further: High Output Management is the book for you!

My product management toolkit (33): launch and learn

marcabraham2 Comments

“Build it and they will come!” I used to work once with a senior executive, who was of the opinion that a product or feature should just be launched, without any testing with customers beforehand. “I know that once it’s out there, people will want it” she’d explain to me, adding that “it’s what people want”.

 

 

Hearing this “build it and they will come” mantra time and time again did annoy me 🙂 At the same time, it did make me wonder whether it might be a good idea to (continuously) release product features without prior customer discovery … What if this executive is right and any new product, feature or service should just be launched, as a way of learning as quickly as possible!?

Being able to ‘launch and learn’ is a vital tool in any product person’s toolkit. I strongly encourage you to avoid ‘one-off product releases’ at any time; what are you going to learn from shipping a product only to then move on to the next thing!? One can debate about when to best learn – should you learn pre-release? – but the main point is that you’ll need to ship early and often to learn continuously.

Basecamp, a project management software compare, does take ‘launch and learn’ to the extreme, they don’t show customers anything until every customer can see it. In the book “It doesn’t have to be crazy at work”, Basecamp’s co-founders Jason Fried and David Heinemeier Hansson describe how at Basecamp:

  • “We don’t beta-test with customers.”
  • “We don’t ask people what they’d pay for something.”
  • “We do the best job we know how to do and then we launch it into the market.”
  • “The market will tell us the truth.”

Fried and Heinemeier Hansson argue that anything you ask or test with customers prior to launch is hypothetical: “Real answers are uncovered when someone’s motivated enough to buy your product and use it in their own environment – and of their own volition. Anything else is simulated answers. Shipping real products gives you real answers.” Whilst I do agree with this line of thinking, I don’t believe in simply launching some crappy product or feature and see if it sticks (just as much I don’t believe in “build it and they will come”).

 

 

My suggestion would to ‘launch confidently and learn’. This means that for each new product or feature you determine – based on your confidence level – whether it needs some form of customer research before launch:

  1. Deliver value in order to learn – You want to be smart about the things you want to learn. The best opportunity to learn comes when you’re confident about the value that you’re delivering to the customer. Naturally, people might not buy or use your product despite the value it intends to deliver, but that’s a learning in itself.
  2. Minimum Level of Confidence (1) – How confident are you? What exactly are you confident about (and why)? The main reason why I believe in product managers adhering to a confidence treshold is to avoid launching products that don’t work or provide an awful user experience. The Newton MessagePad which came out in 1993 is a good example of the launch of an incomplete product, which didn’t live up to its promise. Larry Tesler, senior exec at Apple at the time of of the Newton MessagePad, described Apple’s promise about the Newton’s handwriting capability as a large nail in the Newton coffin. The lesson learned here is that you shouldn’t launch when you’re not confident about the capability and value of your product or feature.
  3. Minimum Level of Confidence (2) – I’ve come up with a number of basic questions and criteria to apply when you’re thinking of launching a product (see Fig. 1-2 below). In my experience, identifying your Minimum Level of Confidence shouldn’t result in ‘analysis paralysis’. In contrast, it’s an important conversation to have throughout the product lifecycle to ensure that everyone fully understands what risks or unknowns are associated with the upcoming release. As an outcome of such a conversation you can decide whether to get customer feedback pre-release.
  4. Make sure you learn! – Whether you do or don’t engage with customers before launch, being clear about what you’re looking to learn from a release is paramount. Like I mentioned above, I view releasing something without learning from it  as a cardinal sin. It’s very important to continuously learn from real users and actual usage (or not) about your key hypotheses. These learnings – both quantitive and qualitative – will give you the data points to iterate or terminate a product.

Fig. 1 – Questions and criteria to check your confidence about launching a product or feature:

  • Internal quality assurance – Have you tested your product feature to ensure there are no obvious bugs or gaps in the user experience? Even if you don’t test with customers prior to launch, you should test some key acceptance scenarios internally before launch to make sure the product works as intended.
  • Does the feature or product touch on core user experience? – If “yes” is the answer to this, then I recommend you do test with customers prior to launch to identify any major usability issues worth solving before launch. You typically need to test with no more than five customers to unearth any critical usability issues.
  • How confident are you? – The combination of low confidence in something which your business has got a lot riding can be deadly. Yes, one can always try to do damage limitation, but it might already be too late at the time of you trying to repair things! The idea behind determining your confidence levels upfront isn’t a scientific one. Instead, it enables a conversation, making sure that people have got their eyes wide open and understand the level of risk and unknowns involved in an upcoming product launch (see Fig. 2 below).

Fig. 2 – Basic confidence levels to consider before launch:

  • High Confidence: Our confidence in the upcoming release is high because we tested it thoroughly internally, have launched a similar product or feature before or if there’s an issue the fallout will be small.
  • Low Confidence: Our confidence in the upcoming release is low because we haven’t fully tested it, it’s based on new technology or creates a totally new user experience.

 

 

 

Main learning point: Even if you decide not to generate customer learnings before a product launch, make sure you at learn after launch. Launch and learn. Don’t launch without learning!

 

Related links for further learning:

  1. https://www.mindtheproduct.com/2017/02/the-life-of-a-product-manager-learning-by-doing/
  2. https://www.intercom.com/blog/shipping-is-your-companys-heartbeat/
  3. https://medium.com/@joshelman/a-product-managers-job-63c09a43d0ec
  4. https://uxplanet.org/10-things-i-learned-from-jason-fried-about-building-products-5b6694ff02aa
  5. http://time.com/13549/the-10-worst-product-fails-of-all-time/
  6. https://twitter.com/jasonfried/status/935555293014036480
  7. https://247wallst.com/special-report/2014/03/03/worst-product-flops-of-all-time/2/
  8. https://www.macworld.com/article/2047342/remembering-the-newton-messagepad-20-years-later.html
  9. https://www.nytimes.com/1993/09/26/business/the-executive-computer-so-far-the-newton-experience-is-less-than-fulfilling.html

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

marcabrahamLeave a comment

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 (24): ‘pre-mortem’

marcabraham3 Comments

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

Book review: Yes To The Mess

marcabrahamLeave a comment

In May last year, I attended a great talk by Ken Norton – partner at Google Ventures – titled Product Managers: Make Yourself Uncomfortable. In his talk, Ken talked about the book Yes To The Mess: Surprising Leadership Lessons from Jazz by Frank J. Barrett, a management consultant and jazz pianist. Ken talked about feeling uncomfortable, his point being that uncertain and unstable times call for embracing uncertainty, improvising, learning and improving.

In “Yes To The Mess” Frank J. Barrett highlights the leadership lessons that can be learned from jazz music and jazz greats. These are the main lessons I learned from reading this fantastic book:

There’s no such thing as making mistakes

quote-if-you-don-t-make-mistakes-you-aren-t-really-trying-coleman-hawkins-54-15-31

Fig. 1 – Coleman Hawkins “If you don’t make mistakes, you aren’t really trying” – Taken from: http://izquotes.com/quote/81208

How often do people get chastised for he mistake(s) they’ve made!? Having to lower one’s tune because of having tried something that ultimately failed? Or trying to cover up a mistake or an error? In contrast, jazz music is all about ‘failing’. Like the great saxophonist Coleman Hawkins once said: “If you don’t make mistakes, you aren’t really trying” (see Fig. 1 above). In jazz music and in business, Barrett argues, there’s no such thing as making a mistake.

Instead, the focus is on not missing opportunities and embracing errors as a source of learning. For me, Miles Davies is the ultimate embodiment of the courage to make mistakes; “If you’re not making a mistake, it’s a mistake” is one of Davis’ famous quotes. “Do not fear mistakes. There are none” is another one (see Fig. 2 below). As Barrett points out, Davis was talking about the importance of continuing to take risks and to try new possibilities. Because when you do, something new and unexpected is likely to happen.

milesdavis

Fig. 2 – Miles Davis “Do not fear mistakes. There are none” – Taken from: http://www.ideachampions.com/weblogs/archives/quotes/

Informed risks and constructive learning

If mistakes don’t exist and we should all learn by trying, does this mean that we can just act recklessly and stop caring about what could happen!?

Absolutely not. Barrett explains how well conceived plans not always pan out as expected. “Everyone has a plan until they get punched in the mouth” as Mike Tyson once said (see Fig. 3 below). I came across an organisation once where project people probably spent a good 40% of their time drawing up great detailed project plans and 60% of their remaining time continuously adjusting timings on their project plans and “controlling the message” towards their stakeholders. Perhaps if they’d read “Yes To The Mess” they might have instead embraced unexpected factors or errors, and built on them. In jazz, the artists don’t correct mistakes as much, opting to recognise and ride with them instead.

quote-mike-tyson-everyone-has-a-plan-till-they-get-6007

Fig. 3 – Mike Tyson “Everyone has a plan ’till they get punched in the mouth” – Taken from: http://quotes.lifehack.org/quote/mike-tyson/everyone-has-a-plan-till-they-get/

What I like about this approach is that jazz players will learn by leaping in, learn from taking action and adjust accordingly. Barrett describes this approach as taking informed risks, taking action based on something that happen before and discover as you go. Jazz bassist and composer Charles Mingus once famously said: “You can’t improvise on nothing. You gotta improvise on something.” Even improvisation needs rules and some kind of order. As a result, especially in jazz bands, improvisation will lead to collective discoveries.

In my experience, improvisation isn’t easy. It can be pretty daunting when something doesn’t go according to plan – or when there isn’t a plan to begin with. An understandable first reaction is to try and fix the error, make sure the plan can still be executed upon. However, the results of not following this instictive response can be amazing, and can lead to new insights and approaches.

Generous listening

A key point Barrett makes is how improvisation requires jazz musicians to do lots of listening. Jazz players need to be attentive not only to the music they’re playing, both individually and as a group, but also to what isn’t being played. When Miles Davis was asked how he went about improvisation, he explained that he listened to what everyone in the band was playing and would then play what was missing.

Although I’m not yet great at it, generous listening is all about listening more then talking, or asking questions even when you might already know the answer. As a product person, it means not trying to be a rockstar or to push through your opinion. In contrast, it’s about truly listening to what someone else is thinking or might have to offer. In jazz, there’s even a term for this: “comping” – the rhythms, chords, and countermelodies with which the other players accompany a solo improvisation.

screen-shot-2017-03-05-at-07-17-11

Fig. 4 – Duke Ellington “The most important thing I look for in a musician is whether he knows how to listen” – Taken from: https://www.apassion4jazz.net/quotations4.html

Affirmative competence

Taking informed risks and listen generously leads to organisations developing “affirmative competence”, where the organisational system is no longer top down and deliberate, but much more emergent. As Barrett stresses, “an emergent system is smarter than the individual members.” Andy Grove applied this approach whilst at Intel when being faced with the challenge of Intel’s existing business drifting away. Since that experience, Grove’s advice is to “set aside everything you know.” Organisations and teams will thus learn while doing and by building up an underlying confidence in the competence of their group of people, taking the following steps in the process:

  • Take action
  • Revise assumptions
  • Value learning from failures
  • Try again
  • Discover as you go

Main learning point: I absolutely loved both Ken Norton’s talk and “Yes To The Mess” by Frank Barrett. The idea that well conceived plans are fallible and that that it’s ok to learn from one’s mistakes really resonates with me. Even if you’re not a jazz lover, it’s really worth reading “Yes To The Mess” and studying the lessons we can learn from jazz and its musicians.

 

Related links for further learning:

  1. http://www.mindtheproduct.com/2016/05/product-managers-please-make-uncomfortable/
  2. http://www.forbes.com/sites/susanadams/2012/08/10/leadership-lessons-from-the-geniuses-of-jazz/
  3. https://hbr.org/2012/08/what-leaders-can-learn-from-ja
  4. https://www.theguardian.com/music/2011/jun/13/grand-wizard-invents-scratching
  5. http://pubsonline.informs.org/doi/pdf/10.1287/orsc.9.5.543
  6. http://fortune.com/2012/09/10/what-biz-leaders-can-learn-from-jazz/
  7. http://jazztimes.com/articles/134503-beyond-the-music-what-jazz-teaches-us