Tactics for transformation: Campaign and scale

Stop me if you’ve heard this one: A company/product/organization isn’t doing well, they realize the customers are furious. Their solution? spend money on a UX team and have them do production work. The UX team is engaged at the last minute after all feature decisions have been made with requests like “Can you guys just UX this a little bit?”.

This example is very common in a Developer-Centered environment. The Nielsen Norman Group would rate this setting as a UX maturity of 2. In this post, I’d like to talk about some tactics I’m using to aid the cultural transformation to get the environment to the next level.

• The 1 vs 1 (Negotiation, consulting)

• The 1 vs 100 (Campaign, presentation)

• The 1 vs 1, 100 times

In an environment where everyone is doing their job correctly but somehow not gain any traction, coordinating these 3 conversations tactics can help provide a North Star for everyone involved.

The 1 vs 1

1 vs 1 is by far the most effective way to influence change. Problems and solutions are contextualized to the every day experience of the people engaged in conversation. Negotiations take place, agreements are made, people generally leave with a hopeful disposition. It is imperative that this opportunity leads to trust through delivery on promises made.

The 1 vs 100

1 vs 100 is a campaign. It is a presentation of an idea made over and over again to an audience. It is the fastest way to spread a message to large numbers of people. While this tactic is strong in speed, it is weak in effect. However, the goal of the 1 vs 100 isn’t to convince everyone in the room, its to find the handful of people out of the audience who had resinated with your idea. This select few is who will help with the following stage of this campaign.

The 1 vs 1, 100 times

It is simply impossible for a person to have a 1 vs 1 conversation with enough people to promote grass-roots cultural transformation. This is where the allies found from the 1 vs 1s and the 1 vs 100s need to help spread the message as a team. With this model, the message of positive change can spread like wildfire leading to the changes the visionaries hope to see.

BETTER THAN THE SUM OF ITS PARTS

Making more out of a team to make a team do more

Among the many catchy and wise quotes Aristotle used to throw around, “The whole is greater than the sum of its parts” remains to be a favorite in corporate America. Though arithmetically incorrect and in contradiction to the Ringelmann effect, corporations love to tout the value of synergy. For teams where synergy is not a part of their culture, when and how do we synergize? Who should be leading that effort?

Where Does My Job End?

A dev manager once said to his entire team during a project kick-off meeting, “I want everyone to know what the person next to them is working on.” It was a statement meant to motivate as well as imbue a sense of accountability and unison into his team. It is a fantastic mind-set for a dev team to have, but there is no reason to stop there. Understanding the responsibilities and roles different from one’s own can have massive impact on how an individual plans their execution. A business analyst that understands how to extrapolate objectives from client demands can help a UX designer solve the right problems. A UX designer who can help write stories and understand development processes can deliver assets that are more comprehensive for a development team. A developer who understands the business objective can be constructively engaged in assessing if the sprint goal aligns with the product vision.

It is important for every member of the team to remember that they are all stakeholders of a product, not just a representation of talents. “Where does my job end?” is a slippery slope that can quickly deteriorate into “That’s not my job.”

How Much Talent Is Enough to Make a Good Product Team?

A good product isn’t simply a collection of good features. Though existing features in a product may provide value to the user individually, it is in the efficient flow from feature to feature where the benefit of a product is evaluated.In t he same way, the strength of a product team can be measured in its relations between teams & talents.

A designer creating a perfect design solution doesn’t mean anything if the solution isn’t properly communicated to the developer who will be building it. In the same way, a business solution will not translate in the design if the objective is not conveyed to the designer properly. It is in these key moments of communication where synergy needs to be at its strongest.

Synergy Through Alignment

“Happy families are all alike; every unhappy family is unhappy in its own way.”

-Leo Tolstoy 

The opening of Tolstoy’s book, Anna Karenina has been used to describe a principle where failing to meet even one of a number of factors, can destine an entire operation to fail.

“In other words: in order to be happy, a family must be successful on each and every one of a range of criteria e.g: sexual attraction, money issues, parenting, religion, in-laws. Failure on only one of these counts leads to unhappiness. Thus there are more ways for a family to be unhappy than happy.”

The Anna Karenina principle can be applied to product team dynamics as well. When the scales of power lean too far in favor of, let’s say, a development team for example, it becomes easy for product decisions to become catered to the capacity of the development team rather than the user. The tipped scales lead to missed business objectives and compromised user experience. In these situations where alignment is lacking, it is on the Product Owner to facilitate a goal-setting exercise. These sessions will not create organic synergy in the entire team, but it is rather meant to create a shared goal that everyone can be excited over. When all the members feel like they have contributed in creating an inspiring vision, they are likely to worker harder and collaboratively.

Moments where one can hold the attention of the group are rare. When one is fortunate enough to have the attention of key actors in the product team, it is worth evaluating if the current work methodology is appropriate for a team with tipped scales. Analyze the entire process with the team, identify the problem areas, and suggest adopting some beneficial practices from the number of different work methodologies out there (Kaizen, six sigma, lean, etc).

VISION, STRATEGY, TACTICS, & EXECUTION

“A picture is worth a thousand words” is an idiom that could greatly benefit product development teams if its principles were applied their daily work. Too often our own cognitive biases allow us to believe that the vision is ready to be turned into a story when we can’t think of any more questions to ask. While every member has agreed on the objective, the differences in the envisioned solution don’t surface until the sprint has already started. After running into so many of these situations, I have become adept at ensuring team alignment. Here are some easy ways I have been able to help mitigate risks of terminating sprints.

Ask Better Questions

Human beings are natural problem solvers. It is in our nature to seek solutions, sometimes as a detriment to our own interests. When a product team rushes into a solution, the team stops focusing on the objective which often contains underlying purposes which may not have yet been realized. In my experience, it has been a highly constructive exercise for someone on the team to take on a detective-like role, and facilitate interviews with everyone who touches the product. Asking a dev manager a question like “What do you think the client wants?” or asking the client “What is your vision for this product?” can lead to a normalization in the team mission and a tighter bond.

Empathy is not a UX skill, it is a human skill. Like many skills, it gets better with practice. Frequent promotions of empathetic questions will lead to a team full of people with rounded skill sets.

Be The Logical Checkpoint

Despite the bad reputation it can earn, being the person who questions everything can end up helping the product by getting the team to truly evaluate the value of a story. Taking on this role requires some people skills, and does at times reduce the momentum a team can have. However, by creating a habit with-in the team to be the logical check-point, and demonstrating that it’s a simple skill that can be performed by anyone, this behavior will soon become a regular part of the team’s product creation process.  

Mini-Visions & Mini-Strategies

Simply put, the further we look into the future, the less we see. This ambiguity in the vision makes it harder to plan for, which makes it harder to win the approval of IT workers who tend to favor the tangible. While the Product Vision exists as a North star, every epic and story needs to help get the product closer to that. As obvious as this sounds, it is very easy for teams to lose sight of this objective when the focus is on the tactics & execution. It is in these very moments where designers have the opportunity to bridge the gaps with scaled vision proposals. A designer who can illustrate the connection between the Product Vision and an epic for the up-coming quarter is naturally in a better position to steer the small efforts into the right direction.