How Language Binds Us Together

In the summer of 2007, Chris Messina, a product designer living in San Francisco, was frustrated. He was having trouble following along with a conversation happening on Twitter about Barcamp, a Silicon Valley meetup of entrepreneurs and tech geniuses. The messages and profiles were scattered all over the website, and there was no way to see all the conversations regarding the conference in one place.

He tweeted a modest proposal:

How do you feel about using # (pound) for groups. As in #barcamp [msg]?

Stowe Boyd, an anthropologist studying the future of work, tweeted support a couple days later:

I support the hash tag convention.

And as simply as that, the notion of a hashtag on Twitter was born. It ushered in an entirely new way to communicate and connect with others online.

However, Twitter wasn’t convinced. Messina later told The Wall Street Journal, “[Twitter] told me flat out, ‘These things are for nerds. They’re never going to catch on.’”² Messina even went to Twitter headquarters to pitch the idea of using hashtags to cofounder Biz Stone. According to Messina, his reply was curt: “No. But thanks for your enthusiasm.”

What Twitter couldn’t have predicted was that the hashtag would become an incredibly useful mechanism for its users to organize themselves.

During the San Diego fires of 2007, Twitter hashtag usage reached critical mass as users tagged their latest updates with #sandiegofire.³ This created a level of citizen journalism never before seen online. What users discovered was that they could get nearly instant information from a wide gamut of perspectives during a crisis. For better or worse, the public now had access to near-instant information when a tragedy or disaster hit.

Eventually, Twitter embraced the hashtag, turning them into links that, when clicked, provided a view of only messages marked with that hashtag. They even added a guide to their website instructing users how to best formulate a hashtag for their tweets.

When we look at this phenomenon a little more closely, we can appreciate that there’s something much more powerful at play than the simple organization of tweets. Today, a hashtag can go viral and become a shortcut for people to join a shared idea or identity. Entire social movements have been organized and executed just by using a hashtag. This collective behavior of hashtags illustrates the power of having a common language.

Therefore, your organizational culture cannot gain traction and flourish if it doesn’t have the appropriate, common language. Essentially, as illustrated in Figure 2-1, if you change the language, it will start to change the thinking. This change in thinking will change the actions of your employees and eventually change the entire value system and culture of your organization.

Figure 2-1. Changing your language ultimately changes your values and your culture

So the question becomes: “If we must drive culture by pursuing a common language, what should that language be?”

Change the Language

It turns out that the basic scientific method gives us the best language to encourage a learning mindset. This means that you shift from a language that supports what you know and focus your attention on the things you still need to learn. We want to identify our assumptions, formulate them into hypotheses, and run experiments to validate or invalidate our thinking. These words help us remain in a constant state of learning while amassing confidence in our existing knowledge over time.

With our product teams, we use The Customer-Driven Playbook and our workshops to train them in the process of formulating their assumptions into testable hypotheses. Capturing our assumptions about the customer and their problems is a powerful exercise for any product team.

Essentially, we want teams to fall into a cadence in which they’re continually evaluating their assumptions against what they’re learning from our customers. We call it our customer-driven cadence, and it’s an ever-revolving cycle of assumptions, hypotheses, experiments, and sense-making, as depicted in Figure 2-2. For DevDiv, this language of learning—assumptions, hypotheses, experiments, and sense-making—comprises powerful words that make up our cadence of software development.

Figure 2-2. DevDiv’s customer-driven cadence and language of learning: assumptions, hypotheses, experiments, and sense-making

The words we use shape our outlook. When we say, “I have a hypothesis,” instead of saying, “I know our customers want this feature,” we open ourselves to the fact that we could be wrong about our assumptions. Moving to a language of learning and experimentation can be liberating because it makes it OK to be wrong.

However, the business world often doesn’t afford us this luxury. People are paid to be correct and, in the technology industry, we often lavish praise on the “rebel genius” who was spot on when everyone else was wrong. Those stories are plentiful and well covered in the press. What’s often overlooked are the myriad failures that tech luminaries like Steve Jobs, Bill Gates, and Jeff Bezos experienced on their journeys to becoming legends.

Before Steve Jobs changed the world with his iPod and iPhone, he was behind consumer flops like the Newton and the NeXT Cube. Famed innovator and CEO of Tesla and SpaceX, Elon Musk, once applied for a job at Netscape and never got a reply, even after hanging out in their lobby.⁴

When the focus of your work is to experiment with your assumptions, it becomes a quest for answers—not a quest to prove yourself right. A language of learning takes the ego out of it, leaving a pursuit of knowledge in its wake. That can be liberating, particularly in an atmosphere like Microsoft (and so many other companies), where a pursuit of one’s own personal achievement can reign supreme.

Stating that you have an assumption about a customer’s motivation or behavior puts that belief in the proper context and frees it from a sense of ownership, releasing the fear that comes with finding out that your assumption was wrong. In fact, in DevDiv, we almost delight in being proven wrong because, like Edison, we’ve discovered another way it won’t work. The important point here is that assumptions aren’t a bad thing. They’re a mental shortcut that reveals ideas based on previous experience or observations. The problem with assumptions is when they remain untested. If we’re not careful, untested assumptions quickly become untested “facts.”

Therefore, in DevDiv, you’ll find that words like assumption, hypothesis, and experiment are part of our daily lingua franca. It wasn’t always this way, but through purposeful encouragement and modeling, it evolved in that direction. These terms were introduced in communications from leadership, reinforced in product reviews, and taught in our workshops. We had to invoke them wherever appropriate to create an atmosphere in which employees were hearing these terms multiple times each day.

Much like a viral Twitter hashtag, this language of learning became a visible way to show that you were part of the culture of DevDiv. The language became a social norm, and you were considered an outsider if you were unwilling to approach new product ideas with a learning-first, customer-driven mindset. Basically, to show that you belonged to the new movement that put customers at the center of everything we were doing, you needed to use the language of learning.

Use Language to Change the Thinking

It’s critically important that the language you choose is accessible by everyone. In DevDiv, nearly half of the employees are engineers. Even though the UX researcher, designer, and program manager were often seen as the people responsible for customer development, we knew that for everyone to share in the journey, we needed a language that would make sense to our engineers as well. Fortunately, the language of learning (assumptions, hypotheses, experiments, and sense-making) were terms that were being celebrated in the Lean software movement. These were Agile methods our engineers were already adopting and integrating into their development work. Our engineers already wanted to adopt Lean methods, and books from authors like Eric Ries, who wrote the immensely popular book The Lean Startup, were showing up in team rooms and engineering meetings.

The Lean movement was built upon an ethos of rapid learning and experimentation, using words like “assumptions,” “hypotheses,” and “experiment.” By reinforcing these words in our culture, we were able to exploit the excitement our product teams already had about the Lean movement. These terms provided a common ground where engineers, program managers, researchers, and designers could come together and evaluate their work.

Encouraging the use of hypotheses empowered our teams to track and share what they were learning and became an essential part of promoting our language of learning.

Many of us learned to write hypotheses in our high school science class, but we still found that teams struggled to produce hypotheses that could be used in meaningful ways. Many of them were just vague statements that could be applied to just about any customer segment or problem.

For example, it wasn’t uncommon to see hypotheses that targeted generic customer segments, like, “We believe that developers are…” If you’re at all familiar with the developer space, you know that there are hundreds of types of developers. You have enterprise developers, small business developers, consultants, hobbyists, desktop, web, mobile, Internet of Things (IoT), just to name a few.

When the team’s hypotheses targeted literally everyone in our customer base, it created difficulty because they made their way through the customer-driven cadence. They were ending up with generic learnings that weren’t helpful or targeted. It became a sort of “garbage in, garbage out” problem. Although writing hypotheses might have been what some Americans learn in eighth grade, studies show that nearly half of Americans have trouble identifying a proper hypothesis and understanding the entire scientific process.⁵ In other words, we found that writing testable hypotheses wasn’t something that just came naturally to people.

That’s what inspired us to create the HPF, which we discussed in Preface. It became a vital tool because it included a set of templates to make it easy for teams to formulate their hypotheses. Each stage had its own template (e.g., Customer, Problem, Concept, Feature, and Business). Depending on where the team was in its development life cycle, it could choose the appropriate stage and create a fully formed hypothesis, as shown in Figure 2-3.

Figure 2-3. Hypothesis templates for the first two stages of the HPF (Customer and Problem stages)

Frameworks like the HPF proved invaluable in creating an instruction set for working with our new language. All our product teams had to do was fill in the template with their assumptions, and they would have a fully formed hypothesis, ready for testing.

When building your cultural language, we highly advocate employing hypotheses as a key instrument to root your language in learning. You’ll quickly find that everyone has the capacity to create them. You can even use them to engage your detractors. Many of them will have their own opinions of how you should proceed with culture change. Having them express those ideas as hypotheses will not only get them practicing your language of learning, but it will also help them realize that their suggestions are based on their own assumptions. It involves them in the discussion in a way that puts them in a learning mindset, even when they’re disagreeing with you.

If you create an environment in which teams are trading and evaluating their hypotheses, you create a culture that is dependent on learning. As product teams engage with and learn from their customers, you’ll find that they’ll respond more quickly to customer demands because when an idea has been proven wrong, they won’t waste time protecting their egos; they’ll just update their hypotheses, iterate on their idea, and keep learning.

Use Language to Change the Actions

Moving to a common language takes practice. It’s like a new pair of shoes: they feel a bit awkward at first, but as soon as you break them in, they feel like an extension of your feet.

One of the most profound changes we saw was when leaders began to model our language of learning.

During our engineering reviews, our corporate vice president, Julia Liuson, would ask questions like, “What is your hypothesis about this customer?” and, “What are your assumptions about the customer’s problem?”

This was a subtle change in language, but it proved to be overwhelmingly effective. Teams realized that, to get through a successful engineering review, they would need to identify the assumptions that had led them to their decisions. After those assumptions were identified, teams needed a way to communicate them to our leadership team and one another and demonstrate how they had collected data from customers to validate or invalidate their thinking.

The structure of the hypothesis fit the bill. Soon, teams were leading engineering reviews with Excel spreadsheets full of hypotheses. Others had them written down in OneNote, Microsoft Word, or email. Some teams began to tag their hypotheses as “validated,” “invalidated,” and “inconclusive.”

The method didn’t really matter. What was more important was that our leadership team could easily follow along with a team’s progress, and the entire review process was led not by anyone’s opinions, but by everyone’s desire to update their learning.

Teams also adopted Lean experimentation methods for validating or invalidating their hypotheses. Teams began to engage in “Quick Pulse” studies in which they would share iterations of product ideas with customers—to validate or invalidate their assumptions—every week. The game of product making in DevDiv had shifted from “How can I convince everyone that I’m right?” to “How quickly can I learn if I’m wrong?”

Each year, our teams in DevDiv have more than 10,000 direct customer interactions, whether by directly observing customer behavior or directly talking to customers.

These actions occur because we now have a culture that is obsessed with learning and experimenting. Continually refining our assumptions with our customers proves to be a fruitful landscape for exploring ideas and learning quickly.

Use Language to Change the Values

When an organization begins to adopt new activities and behaviors such as a language of learning, new values also begin to emerge. Effectively, the moment that DevDiv shifted to an organization that was motivated to learn, we began to value the work teams spent learning from their customers.

We began to identify innovations, not just in our product features, but in how we could put zero distance between us and our customers. Teams were getting creative with how they connected with customers because it became clear to everyone that customer connections were the new currency.

For example, many of our program managers were using developer conferences and local meetups as an opportunity to grow their customer network. Others were using sites like LinkedIn, Twitter, and Reddit to find new customers to talk with. There was also a huge demand for our UX research team to guide and mentor our product teams in interviewing techniques and customer development strategies. It turned out that our product teams had a deep desire to create better connections with their customers; they just needed tools, like the HPF, that provided a pathway to do it effectively.

Your organizational values stem from what you talk about and what you give attention to. Therefore, your language, thinking, and actions are an expression of your values. In DevDiv, our values evolved from being celebrated for reaching a shipping milestone to being celebrated for connecting with customers to learn.

Consider a Language of Positivity

When working toward a customer-driven culture, it’s easy to get into the mindset of focusing on what isn’t working. Too often, we fall victim to obsessing over every individual who is resisting change. We lament that they’re unwilling to incorporate customer feedback into their decision making or, even worse, think they know the customer better than anyone else in the organization. Sometimes, they sabotage our efforts or are vocally resistant to our proposals.

These “problem children” get the most attention because we see them as the ultimate obstacle to conquer in order to achieve our ultimate goals. We obsess over them, strategize about them, and convince ourselves we’ve failed because they haven’t come over to our way of thinking. We say to ourselves, “If we can just win them over, everyone else will fall in line.”

Focusing on where you’re weakest or vulnerable is important, but it shouldn’t be the only signal you’re considering as you experiment with various methods to build your culture. With all the hyperattention given to what isn’t working, we run the risk of missing key situations where we’ve made progress, making it more difficult to repeat that success.

In the late 1980s, management and organizational literature was dominated with problem-solving techniques. Their focus was to understand and frame problems so that they could be efficiently analyzed and corrected. Although dealing with problems is a key management function, it also created a language that focused energy on everything that was going wrong.

In the book Management and Organization: Relational Alternatives to Individualism, the authors propose that “language is the vehicle that makes knowing possible by describing or picturing the objectivities of ‘that-which-is.’”⁶ Therefore, words we use to describe our circumstance affect our mindset, our strategy, and our outcome. Put another way, if we’re constantly talking about our problems, we don’t give ourselves enough time to talk about potential solutions.

Appreciative inquiry is a style of change management that encourages us to ask more questions about what is working rather than what is not. The goal of appreciative inquiry isn’t to delude ourselves into believing everything is fine; it’s to help us investigate and learn from situations that have had a positive outcome.

Agents of Change: Monique and Jerry Sternin

To illustrate this idea, consider the story of Monique and Jerry Sternin. As staff members of Save the Children, a nonprofit organization founded in the early 1900s, they shared a mission of giving all children a healthy start in life. In 1990, their work brought them to Vietnam, where nearly half of the country’s children were malnourished.

When they arrived with their 10-year-old son, they found themselves completely out of their depth. They didn’t speak the language, they had a minimal staff, and even fewer resources. “We were like orphans at the airport,” Jerry recalls. “We had no idea what we were going to do.”⁷

Additionally, the Vietnamese government wasn’t entirely supportive. The small team was given six months to produce results. If they couldn’t, they would be expected to leave.

As the Sternins saw it, the way nonprofits like Save the Children were dealing with malnutrition was not entirely effective. They would go into underdeveloped areas, teach the inhabitants about the importance of good sanitation, protecting their water supply, and the benefits of an organized food distribution plan. However, the moment they went back home, all their hard work would be reversed as villagers crept back to their old ways. Additionally, six months was not enough time to set up those types of infrastructures. The villagers were leery of outsiders and were frustrated by previous attempts that had failed. From their baseline assessments, the Sternins could see that 64% of the children in villages they planned to target were at risk of starvation.⁸ These children were dying. The team would need to hit the ground running and think quickly.

Instead of wasting time getting an understanding of every problem that was contributing to the crisis, they decided to employ appreciative inquiry. They would go into their targeted villages and talk with families whose children were not malnourished. In Dan and Chip Heath’s book Switch: How to Change Things When Change is Hard, they refer to this method as “finding the bright spots.”⁹ Essentially, the Sternins and their team would focus on the bright-spot families to help them illuminate ways to help the families that were struggling.

For example, bright-spot families were feeding their healthy kids more frequently throughout the day. Technically, it was the same amount of food as struggling families, but instead of feeding them two large meals each day, they were feeding them four smaller meals. These smaller amounts were easier for the children to digest and gave their bodies time to absorb the nutrients.

Another finding was how the bright-spot families ate. Struggling families assumed that smaller children could take care of themselves, believing that they would feed themselves when they were hungry. Bright-spot families would hand-feed their children if necessary.

Armed with these insights, the team created a program in which 50 struggling families would meet daily at a hut and prepare food. During these meetings, they shared their findings and trained families with skills of basic food cleanliness and preparation. The families used this time to discuss what was working and to get advice on how to improve their techniques. This focused ritual of food preparation became the norm, and families began to develop their own knowledge networks to help one another and their children thrive.

Six months after arriving in Vietnam, 65% of the children in the study were measurably more nourished and, most important, they were staying that way.

There are many lessons that we can learn from this story of culture change, but what’s most exciting about the Sternin’s story is the power of a positive mindset. The Sternins could’ve easily arrived in Vietnam, outnumbered and unwelcomed, and thrown up their hands, saying, “These people don’t want our help!” They could’ve faced the impossible six-month window and said, “This can’t be done, we will need much more time.” Instead of spending the entire six months cataloging all the various problems that were leading to the malnourishment of children, they decided to focus on what was working well and try to repeat it in the areas that needed the most help.

Consider this in your own cultural movement:

• Are you spending enough time examining when things move in the correct direction?

• What can we learn from those situations and, more important, can it be repeated elsewhere in the organization?

It’s not that you should ignore your problem areas; it’s that those areas are not always the best place to find your next innovative idea. Think about spreading your analysis of your cultural efforts. Dive deep into areas where you’ve made progress and develop new hypotheses that can be carried to more difficult parts of your organization.

Many times, our past successes provide answers for our future challenges.

Additionally, positive language can be more motivating. If you’re in a situation in which morale is low or the team is frustrated with poor outcomes, perhaps shifting the focus to what is going well can be the approach that helps your culture team uncover new insights.

In her book The Influential Mind: What the Brain Reveals About Our Power to Change Others, author Tali Sharot says:

When we are stressed, we become fixated on detecting dangers; we focus on what can go wrong. This then creates excessively pessimistic views, which, in turn, can cause us to become overly conservative.¹⁰

It’s really no different when we experience organizational change. For many, this change can cause stress because you might need to adopt new behaviors and learn new skills. In these moments, it’s all too easy to point to everything that isn’t working as evidence that the organization is moving in the wrong direction.

Use the Hypotheses for Exploring Cultural Initiatives

As we saw our language of learning evolve in concert with the HPF, it became clear that we could absolutely shape our culture with the same experimental mindset that we were applying to build our products. The language of learning—assumptions, hypotheses, experiments—proved to be the perfect set of tools to experiment with cultural changes as well.

An example of this was an initiative we started in DevDiv called Culture Club. Every year, Microsoft conducts an “MS Poll,” which is a survey given to all employees to determine where we are on things like the Work-Health Index (WHI) and Leadership Index (LI). Essentially, it’s a way for all employees to give feedback on things like the effectiveness of our leaders, their work/life balance, and feelings on where the company is headed.

One area for which we received feedback was the challenge in preparing managers for leadership. We needed to make people management more accessible to employees and give them opportunities to explore whether people management was right for them.

In late 2017, Ryan Salva, Julia Liuson’s chief of staff, was tasked with improving these metrics and to invest in building the next generation of qualified leaders.

“From the management side of things,” Ryan explains, “our directors were facing a deficit of qualified candidates for people managers. They were running out of leads and they were searching for ways to increase the strength of their leads bench.”¹¹

Additionally, senior-level employees were asking Ryan for advice on how to get into people management:

We had a senior-level [employee] who was thinking about pursuing people management, but he didn’t know how one gets into it; and even then, he didn’t know if people management was right for him, because the only example he had to follow was watching his own manager.

Ryan saw this as an opportunity to do some experimentation and solve two pressing problems: the need to invest in building the next group of talented leaders and the need for new voices and faces to emerge as leaders in DevDiv. Ryan partnered with a couple of enterprising employees (who were also interested in getting into people management), and together they crafted some hypotheses using the HPF (see Figure 2-4). They used the framework because it had become familiar to them during their product development. Even though this project represented a cultural initiative rather than a product or feature, they still saw that they could use the framework to identify their assumptions.

Figure 2-4. How Ryan and his team used the HPF to explore Customer and Problem hypotheses

Essentially, Ryan and his team had a Customer and Problem hypothesis. In this case, their customers were their fellow coworkers:

Type of customers

Senior-level employees

Motivation

Learn whether people management is right for them

Job-to-be-done

Exploring options to advance their career

Problem

The lack of information on how to get into people management

After completing a handful of interviews with their peers, the team came up with an idea for a manager panel discussion. This would be an opportunity for managers to present topics and answer questions surrounding the role and responsibilities of people management. It could be an open and supportive dialog in which employees and managers (from diverse experiences and backgrounds) could discuss and shape what people management should be for our organization.

Again, they used the Concept hypothesis template from the HPF to formulate the idea, as demonstrated in Figure 2-5.

Figure 2-5. The Concept stage of the HPF includes a hypothesis template for exploring concepts like a manager panel discussion

The point here is not to unpack the entirety of the HPF (that’s covered extensively in The Customer-Driven Playbook); rather, it’s to appreciate how hypotheses and a language of learning can be applied to cultural initiatives, just like they are applied to product initiatives.

In this case, Ryan and the team theorized that a manager panel discussion would be the best way to address the lack of information available to employees exploring career opportunities in management. Just like a new feature in a product, there could’ve been many ways for the team to address this problem. The panel discussion was only one idea of many, so it needed to be tested to determine whether employees found the solution valuable.

“We started an experiment by having a single panel discussion,” Ryan says. “It was a 20-minute presentation by an experienced manager on what it means to be a manager, followed by a Q+A….We were thinking, you know, maybe we’ll get one to two dozen folks to attend. The first panel discussion had over 115 people show up,” Ryan remembers.

This was a very strong signal that they had landed on a valuable concept, so the team decided to invest further.

They’ve since created the Aspiring Managers Series, which is a series of similar panel discussions designed to help employees chart their careers into management. They’ve found that this not only removes the mysticism on what’s required to become a lead in DevDiv, but it also gives all employees a better understanding of how their managers can help them shape their careers. It’s created an avenue for leaders and employees to get together and learn from one another about what makes a great people manager.

The team continues to evolve its understanding by formulating its hypotheses and experimenting with various programs. Each time, they make iterations based on qualitative feedback (e.g., interviewing employees) and quantitative data (e.g., surveys and attendance records).

This is the same pattern DevDiv uses when building and shaping products for customers. In this case, the Aspiring Managers Series is the product, and its target customers are senior-level employees trying to advance their careers. Attendance and employee feedback will shape the series going forward, and the Culture Club team will take those learnings and apply them to other programs designed to promote diversity and inclusion.

This is an incredible example of the power of the three vital behaviors of change (awareness, curiosity, and courage). The team was aware that there were gaps in the leadership bench and were curious to see whether there was a desire among staff to receive leadership training. Finally, they had the courage to try something different—running a panel discussion to test the waters and see how much interest there was before investing in a huge, overly funded initiative.

Be Mindful of Everyday Language

Language is one of the most valuable tools that will affect the culture of your organization. Therefore, you must be mindful of your day-to-day operating language. It must be a language of action that can be used in everyday situations, and it should be reinforced in all communications from the board room to the team room.

Disney refers to Disneyland park attendees as “guests” and its staff as “cast members.” This language is intentional, and it reminds employees that their core focus is to create a larger-than-life experience for the thousands of families that arrive at the park each day. Starbucks calls their employees “partners” to reinforce that all employees have a vested interest in the success of the company. This is also supported by the fact that all Starbucks employees receive stock in the company based on the amount of time they’ve worked there. These language choices are intentional and have deep meaning within their respective organizations. The language your organization or team uses becomes a shared identity on which you operate. It tells newcomers, “This is what we value, because this is how we chose to name things.”

In the case of DevDiv, we value a culture where employees are connected and learning from our customers. To do that, we reinforce a language of learning using hypotheses, experiments, and the HPF. In turn, we take advantage of those very same mechanisms to experiment with various cultural initiatives.

Therefore, you should consider the language that your organization is using every day and determine whether it aligns to a culture that is driven by your customers. Are you asking employees to “create amazing customer experiences,” but your day-to-day language is full of how to “optimize customer revenue”? Are you asking employees to “have greater customer empathy,” yet the language in your meetings is full of emotionless usage metrics or adoption numbers?

In their book Organizational Culture and Leadership, authors Edgar and Peter Schein sum it up perfectly:

As a group grows, has success, and develops an identity, the shared learning process broadens from just the minimum behavior we need to agree on to get the job done to a language, a way to think, and a way to feel.¹²

That’s what your organizational language provides. It’s a roadmap for employees to understand a way to think and a way to feel.

We included a list of useful maxims in the back of this book. These maxims can be helpful in creating short, punchy, and memorable sayings that can spread virally within your teams and organization.

Applying the Hack

Here are steps that you can take to hack the language of your organization to be more customer driven:

• As you begin to build your own language of learning for your organization, you might consider how to employ terms that have worked well in DevDiv’s customer-driven transformation. Terms like “assumption,” “experiment,” and “hypothesis” are great starting points.

• As your language evolves, you might consider other terms that we’ve found to be successful in building a language of learning: “customer motivation,” “customer ‘jobs-to-be-done,’” “problems,” “concepts,” “unique value proposition,” “business outcome,” “validation/invalidation,” “inconclusive findings.” You can start to sprinkle these terms in your communications, publications, and presentations.

• Provide your team a “glossary of terms” so that they can see the proposed language and align to it. At first, trying to change old habits (especially ways of speaking) can feel forced and awkward. If necessary, gently suggest the preferred language, in a fun and positive way.

• Ask new questions in your product or engineering reviews, such as:

  • Who is the customer you’re serving?

  • What is their motivation?

  • What problem does this solution solve for them?

  • How impactful is this problem for them?

  • How confident are you that this solution solves the problem?

  Questions like these will encourage reflection and learning. They tie the decisions that are being made in the product to direct customer needs.

• Maintain a backlog of assumptions, hypotheses, and planned experiments. You want to track these things over time to see the evolution of your learning as a team.

• Create a consistent and easy-to-read template for sharing your hypotheses. For example, you might create an email template that has a table to track your assumptions or hypotheses. Columns in the table might include: the type of hypotheses (customer, problem, concept, feature, or business) and the status (invalidated, confirmed, or inconclusive).

• Help managers and leaders by reviewing emails, presentations, videos, and any other publications. Look for opportunities to showcase your key terms to reinforce the language of learning as a strong belonging cue.

• Work with your product teams before product reviews with leadership. Review presentations and encourage the use of the key terms. You can also help them prepare by role playing and assuming the role of someone from the leadership team. You can ask them questions like, “Who is the customer?” “What problem are you trying to solve?” and, “What makes you confident that this is the right problem to solve?” As they practice their answers, you can give them feedback to help them identify the weak spots in their arguments that can be supported with richer customer data.