60 Second Summary: How to Lead in Product Management – Roman Pichler

3 Big Ideas

  1. How Product Leaders can overcome these six common challenges:
    1. Leading a group without managing them
    2. Leading large and heterogenous groups
    3. Limited influence on group member selection
    4. Both contributor and leader
    5. Working both strategically and tactically
    6. Working with agile practices
  2. Product Leaders need to be aware of their leadership style and nuances of product leadership compared to other forms of leadership
  3. Conflict, Conversations and Decision Making are explored as key leadership skills for leaders in Product Management

2 Quotes:

“People will only follow you for two reasons—because they trust and respect you or because they fear you.”

“Mindfulness helps you make better decisions for the following two reasons: First, it helps you recognise cognitive biases. These include confirmation bias, the tendency to prefer data that confirm preconceived views; negativity bias, focusing on negative experiences; and overconfidence bias, overestimating the reliability of one’s own judgements, control, and chances of success. Recognising these biases reduces the risk of making wrong product decisions—for instance, disregarding valid data because it does not match your view. Second, mindfulness helps you to be more aware of your feelings—for example, how excited, sceptical, or displeased you are. This makes it less likely that your emotions drive a product decision—for example, that being angry with someone prevents you from paying attention to the person’s valid concerns.”

1 Action:

Explore using Non-Violent Communication when resolving conflict


Beyond 60 seconds….

Notes, Quotes, References and Related material


Product Leadership Foundations

Lead at three levels:

  1. vision
  2. strategy
  3. tactics

Leadership Styles (A product leader may flex across these styles)Image result for leadership styles affiliative autocratic

Image result for leadership styles affiliative autocraticImage result for bill campbell create environment

Interactions

Empower the development team, help the members acquire the relevant knowledge, and allow people to take full ownership of the solution or, if that’s not possible, the product details.

“Manage your product, not the team.”

Managing Stakeholders – Use the Power Grid to see where your stakeholders fall

Instead of interacting with the players on a one-on-one basis, aim to build a stakeholder community whose members work together for an extended period of time and who learn to trust, respect, and support each other.

Goals

Conversations

Buddhist teaching – Right Speech – five guidelines

  1. Speak with the right intention
  2. say only what you believe is true
  3. only speak if it’s beneficial for the people listening
  4. don’t use harsh or harmful words
  5. make sure you speak at the right time and place

 

Image result for right speech buddhism guidelines

Handling Conflict

Conflict Pitfalls

  1. win-lose—believing that there must be a winner and a loser;
  2. truth assumption—assuming that the other person is wrong;
  3. problem-solving mode—seeing the disagreement as a primarily intellectual issue;
  4. blame game—assigning fault to the other person;
  5. artificial harmony—ignoring conflict.

“To skilfully deal with conflict, we must change our attitude: We should no longer see conflict as something that produces winners and losers but as an opportunity to connect, learn, and generate mutual gains.”

Artificial Harmony causes:

  1. Fear of confrontation
  2. Not a priority to resolve conflict
  3. Work Culture
  4. Lack of Trust

Use Non-Violent CommunicationImage result for nonviolent communication

“Conflict resolution is not about winning, retaliating, or putting the other person in her or his place. It’s about developing a shared perspective on what happened, agreeing on the changes required, and re-establishing trust. This requires a willingness to forgive the other person and yourself (Amro 2018).”

Conflict resolution requires all parties to:

  1. co-operate—move beyond blame
  2. take responsibility for their behaviour and feelings
  3. embrace a contribution mindset (Open mindness)

“You can encourage change in another person, but you cannot make someone else change.”

Decision Making

“Determining who makes decisions in an organization is one of the best ways to understand who has the power—who is in control.”

John A. Buck and Sharon Villines

Common causes of poor decision making by Product Leaders:

  • Lack of empowerment
  • Lack of knowledge 

Use a facilitator to support collaborative decision making as groups may:

  1. Be used to senior leader making all decisions (HIPPO)
  2. Low trust – Groups may not be familiar with debate and disagreement – Facilitator can help bring out divergent perspectives safely

Product Leader should not act as the facilitator

Principles to support participatory decision making:

Full participation: Everyone is willing to contribute, and everybody is heard. Nobody seeks to dominate or hijack the decision-making process. Everybody feels safe to speak her or his mind.
Mutual respect and understanding: People make an effort to attentively listen to each other and appreciate the other person’s perspective, goals, and needs. The individuals intend to talk to one another kindly and to treat each other respectfully. 
Open-mindedness: The group members strive to keep an open mind, understanding that everybody holds a piece of the truth and that everyone’s perspective matters. “Ideas should not be favoured based on who creates them,” as Brown (2009, 73) puts it.

Ground Rules for Facilitators (Hartnett 2010)

  1. Always speak from a place of respect for others and assume good intentions on the part of the group members.
  2. Respect differences of opinion and value the diversity of the group members.
  3. Listen with an open mind; be receptive and refrain from making premature judgements.
  4. Speak honestly and openly.
  5. Always stick to observable facts.
  6. Refrain from judging and labelling people; separate individual and opinion.
  7. Ask questions when you sense misunderstanding or disagreement.
  8. Speak up if you have not been participating.
  9. Make room for others if you have spoken often.
  10. Do not interrupt others, but allow a brief moment of silence to let the previous speaker’s words sink in before the next person speaks.
  11. Stay present; do not engage in side conversations or answer messages on your electronic devices.

Participatory Decision Rules:

Image result for participatory decision making rules

Avoid Committees – They drive weak compromises

Image result for camel designed by committee

Tips for successful negotiation (Fisher and William 2012):

  1. People: Separate the people from the problem.
  2. Interests: Instead of arguing over positions, look for shared interests and needs.
  3. Options: Invent multiple options, looking for mutual gains, before deciding what to do. Avoid the mistake of prematurely excluding options and opting for one solution.
  4. Criteria: Use objective criteria or a fair standard to determine the outcome.

Stages of Influence (Voss 2016):

  1. Active listening: Make an effort to empathically listen to the other person while suspending judgement.
  2. Empathy: Understand the individual’s perspective, needs, and interest, thereby accepting that emotions play a major role in how we behave as human beings.
  3. Rapport: Build rapport and establish trust.
  4. Influence: Help the other person let go of her or his position, understand your needs, and look for a solution that addresses the individual’s needs at least partially.
  5. Behavioural change: Agree on an acceptable solution that can be implemented (if possible).

Techniques for negotiation: (Voss 2016):

Image result for voss negotiation techniques mirror

Self-Leadership

Mindfulness helps you make better decisions for the following two reasons: First, it helps you recognise cognitive biases. These include confirmation bias, the tendency to prefer data that confirm preconceived views; negativity bias, focusing on negative experiences; and overconfidence bias, overestimating the reliability of one’s own judgements, control, and chances of success. Recognising these biases reduces the risk of making wrong product decisions—for instance, disregarding valid data because it does not match your view. Second, mindfulness helps you to be more aware of your feelings—for example, how excited, sceptical, or displeased you are. This makes it less likely that your emotions drive a product decision—for example, that being angry with someone prevents you from paying attention to the person’s valid concerns.

Hold Personal Retrospectives

  1. What did I get done this week?
  2. Which challenges and difficulties did I encounter?
  3. What did I learn? How am I feeling right now?
  4. How did my moods and energy levels develop during the week?
  5. What changes do I want to make next week?

There is more to life than work.

What is a Product? Oh no! Not another Product definition

Image result for product owner

Product Backlog, Product Owner, Product Management, Minimum Viable Product. These are just a few examples of how product is referenced across agile literature.

Despite it’s frequency, one of the most common questions I’m asked: What is a Product?

This is a critical question, especially for organisations who look to become product centric, organising their teams and delivery around their core products. These organisations may establish Product Owners so it’s sensible to think, what product will these people own.

There are many definitions such as this and this. In fact, I’ve used both definitions and I even have my own definition.

However, I’ve learned that these definitions don’t really help.

It may help individuals but organisations need shared understanding to become a product centric organisation.

Reframing the question: How do we define product?

Shared understanding does not come through a definition you found on the internet, writing it down on confluence or debating your perspective.

The question requires dialogue, not debate.

In dialogue participants open themselves up to the possibility there may be a different perspective they have not considered. They listen actively and question to help the group to learn collectively. The result is a shared mental model co-created by the group.

Debate Dialogue
assumes there is a right answer – and I have it. assumes that many people have pieces of the answer and that together, they can craft a solution.
is combative – participants attempt to prove the other side wrong is collaborative – participants work together toward common understanding
I defend my own views against those of others  I admit that others’ thinking can improve my own
entails listening to find flaws and make counter arguments entails listening to understand and find meaning and agreement.
I defend my assumptions as truth I reveal my assumptions for reevaluation

From The Magic of Dialogue by Daniel Yankelovich

For leaders attempting to become an agile, product centric organisation, the first step is dialogue.

Bring your key leaders together, with a skilled facilitator, to create your shared answer: What is a Product?

You cannot Automate a User Journey Test

Most Test Automation models describe User Journey tests as an important component. In the case of the most well loved model, the Test Automation Pyramid, you’ll usually find User Journey tests towards the top(as per below): B95IkAFIQAAxr2z

These are typically some form of end-to-end journey, usually automated through the User Interface, using tools such as Selenium WebDriver, QTP etc.

Why can’t you automate a User Journey Test?

Lets start by defining a User Journey:

User journeys tap directly reflect the thoughts, considerations, and experiences that people go through in their daily lives, beyond the web. Creating a user journey places a strong emphasis on personas and also merges the creation of scenarios and user flows. However, unlike user flows, hierarchies, or functional specs (which explain the interaction between a user and a system’s logic and processes), user journeys explore a user’s mental and lived “patterns, processes, and paths” and translate these into web-based experiences.” [1]

user_journey

The important part of the definition is that a User Journey is a “mental” and “lived” experience. The journey is deeply linked to “emotions” and these emotions usually have a bearing on the users perception of quality. Within development teams most of our work is focused either on enhancing existing user journeys or creating completely brand new journeys with the work typically broken down into “User Stories”. When building user journeys the success to which we have met the users is needs is based upon:

  • Have we me the users goals
  • Have we understood their motivations
  • Have we alleviated some of their existing pain points
  • Have delivered something that matches their character
  • Does it enable the user to do what needs to be done

As delivering a successful User Journey is so important to many teams its no surprise that many teams look to maximise their testing efforts in this area with some looking to automation. However, as described the key success factors in a user journey are linked to Human Emotion. As it stands, these emotions cannot be encoded into an Automated Test(although in the future it might be possible[2])

Due to this we cannot automate a User Journey test. kobian_sadness_1429339c

Testing the emotions

As a tester some of the most valuable feedback we can provide is on an emotional level.

“Emotions and Feelings are signals. Look into what they’re signalling” [3] 

It is only through experiencing the journey on an emotional level, as human testers, that can we provide feedback on the ‘journey’. A difficult part of testing is to really understand deeply the emotions of people that matter.

– Who is the user in the journey?

– What is their character?

– What are their motivations?

– What are their pain points?

How well we understand the emotions of our users can be an important factor in the success of our testing. If we do not really understand our users on an emotional level we may overlook certain issues such as clunky navigation, slow page responses or misleading messaging.

A great tool we can use(and not, its not Selenium Webdriver) is Personas. These are a great way of “getting inside” the mind of the user. Most agile teams will be familiar with personas as they form part of most User Story templates:

“As Stewart i want to be informed when my loan is due to expire so that i can avoid hefty late return fees”

In my current team we spent alot of time breathing life into our Personas giving them interesting names, personal backgrounds, job titles, goals and objectives. One of our personas is “Sarah the System Admin”. These personas reflect our real user base. We also had “face time” with the users understanding their emotions when using our software. One of our teams even created baseball cards of their personas so it was even easier for them to remember all the ‘players’.

At BDD Exchange 2014 Jeff Patton encouraged the attendees to “Get out of the building, way out of the building” to see how real users interact with our software. A better understanding of user emotions can breathe life into what may be seen as mundane tests. It also allows issues to be discussed on an emotional level “I’m pretty sure Stewart wouldn’t be happy with this flow, he said he wanted something quick, if possible, 1 click” Unfortunately too often this form of ’emotional’ testing falls into a Usability Testing phase. In traditional Usability Testing we prepare a prototype to show the users, usually in an expensive ‘off site’ test center. Following a couple of feedback iterations the idea moves into a lengthy development cycle and once complete, we schedule another session to take the users through the ‘final’ solution. We then go through the development iteration again after we realise further changes are required. Often the gap between this feedback is too long for most teams.

As Testers we can infuse the whole development cycle with our user persona’s. We can ensure their emotions and feelings are considered l so that the developed solution is likely to be closer to the users ’emotional expectations’. As Testers we can do some of our best testing before a line of code has been written through testing paper prototypes, whiteboard designs and challenging assumptions around user expectations.

Many organizations are now realizing the benefits of this type of testing throughout the entire development life cycle. My previous company, Shop Direct Group, are somewhat trendsetters in this area. They have built an in-house customer testing lab located in the center of the office, bringing the customer to the heart of the development process, literally! [4]

Design Thinking [5] is also an emerging as a popular approach. In this the emotion of ’empathy’ is the start of the process.

design_think

If you are interested in understanding more about how our emotions influence us in testing, Stephen Janaway has a great slide deck exploring the topic further [6]

In all these examples human emotions are an integral part and Automated tests cannot provide this feedback.

So what can be automated?

Implicit to a good Customer Journey is at least an application that holds together. If i expect a 5 and i get a 2, or if the user expects the home page to be displayed after Login but they get a 404 Page, we can probably assume its not going to be a great Customer Journey. Automation can help in ‘checking’ our application is at least doing what we expect it to. James Bach differentiates these types of checks from testing:

“Checks are evaluations by applying algorithmic decision rules to specific observations of a product.” [7]

Although we cannot automate a User Journey Test to evaluate the emotional aspects it doesn’t mean that we can forget the user in our automated checks. Understanding the ‘flows’ which different user segments take through the system is vital. Observing users on your application and using data analytic tools from vendors such as Google can build a picture of the most popular flows. We can then create automated checks to ensure that the flow between these pages is at least working. In my experience teams can often neglect the user in their checks. Many automated checks take the ‘path of least resistance’. Rather than automating the most popular user journeys the checks are designed to minimize automation maintenance.

For example, at a previous company we automated quite heavily through the User Interface. A key part of this was adding items to basket and ordering. Our automation checks would start by going directly to a product, we would pass in the Product ID as follows:

http://www.worldbestshop.com/?productId=ItemNumberGoesHere

This was efficient for automation purposes but meant we were skipping one of the most important parts of the customer flow the home page, search and gallery pages, which were the most visited pages of the site.

Our automation also needs to consider user ‘Persona’s’ from a data perspective. Do the users in our automated tests reflect what a real user looks like? Again, in my experience, teams often bulk load in a set of users who are all pretty much exactly the same, again to minimize the overhead of managing lots of different data types. Therefore you’ll often miss issues that occur in the differences between users. A good example is a user returning to a shopping site when they have already added an item to basket. Do all your test start with an empty basket?

To Conclude….

A User Journey is an ’emotional’ experience so we cannot automate these type of tests yet(and probably never will). Ensuring you consider the emotions of your users throughout the entire development life cycle can increase your chances of having an application that will create a good experience for your users. As Testers we can play a valuable part in testing with our users emotions at heart.

Automation can provide an important platform for any customer journey to ensure the application is at least giving the customer the correct result from business logic and allowing to flow through the system.

[1] Introduction to User Journeyshttp://boxesandarrows.com/an-introduction-to-user-journeys/

[2] Softbank unveils ‘human-like’ robot Pepper – http://www.bbc.co.uk/news/technology-27709828

[3] Emotions in Software Testinghttp://www.developsense.com/presentations/2013-05-STAREast-EmotionsInSoftwareTesting.pdf

[4] Shop Direct Test Labhttp://www.shopdirect.com/shop-direct-accelerates-testing-programme-in-house-ux-lab/

[5] Testing your Emotions – http://stephenjanaway.co.uk/stephenjanaway/wp-content/uploads/2014/06/Testing-Your-Emotions.pdf

[6] Design Thinking – http://designthinking.ideo.com/

[7] Testing and Checking refinedhttp://www.satisfice.com/blog/archives/856