In the software development cycle, words matter. When we invent new products, we give them names, define their features and describe who the product is for and its purpose in life – that’s the foundation, or “the why” of the product. When developing, we write stories about how the product is used and define what a successful experience looks like. We also communicate delivery schedules and results. During launch, the messaging around the product is a critical part of the adoption and success.
Fuzzy words, ambiguous terms, blurry lines, grey area, spell check – these are all phrases that come to mind when thinking about the topic of clarity or lack thereof in our spoken language. In general, we associate successful results with specific, clear communication during the process. Yet, in the software development space, ambiguous or “fuzzy” words can either help or hurt the path to inventing, building and launching a product. In this two-part series, we’ll explore both sides of the “fuzzy word” debate.
5 Ways “Fuzzy” Language is Helpful to The Software Development Process:
- It protects the “out-of-the-box” creative process: The invention phase of development can be inhibited by a constant need to clarify. Working out a new product starts with the discovery of what new products should be, which takes time and often, ambiguous, unclear language. Boxing the team in at the outset could affect product development in the long term.
- Certain words are land mines: Some words have a lot of emotion attached to them. The subjectivity involved in defining words can cause disagreement among stakeholders and trying to determine the right answer can shift the invention process. The good news? You’ve uncovered a topic that you may need to reach clarity around.
- It allows young ideas to keep evolving: Phrases like ‘something like this’ or analogies to other products are useful. This helps the team member to clarify their idea so that the team has a better understanding.
- It helps to “get unstuck”: Sometimes, teams get stuck on something and cannot move forward. There can be any number of reasons for it. In order to get ‘unstuck’, we needed to come up with some new words and an approach that sounded enough like what the team wanted to do but was not exactly the same. We needed to be less precise about how to do what we were going to do in order to move forward.
- Interchangeable words represent different stakeholder points of view – Words can have the same meanings from different points of view, particularly from a product standpoint. Since it doesn’t impede the progress of the work or slow the progress of the team, it’s not necessary to insist on more precise language.
On the other side of the coin, ambiguous language can hurt the development process during delivery and launch – a topic we’ll examine in my next post. How has “fuzzy” language impacted the software development process in your organization?