The Difference Between Hearing and Listening

I’ve been thinking a lot about the importance of listening to product professionals lately and had a recent experience that brought that point home for me.

A co-worker and I were talking about our notes from a recent meeting. She pulled up her OneNote and read back to me word-for-word what was said. My notes looked like an art project (I use a sketch pad for note taking). I had scribbled down some models. I wrote objectives. I made lists of pain points. I documented how someone felt. I furiously underlined things that appeared to be important to them. Our note taking was very different and I realized it’s a great example of hearing vs listening.

She was hearing the words that were being said and documenting them. I was listening to what was being said and attempting to identify their source – pain, opportunity, money concerns. I was documenting things that were unsaid that could help my customers “get real” with their actual needs.

As product professionals, we must move past just hearing what our customers say. We must listen to what and how they are saying it. As coaches and managers of product professionals, we must help our teams build skills that help them go beyond simply hearing a request and taking action on it. Anyone can follow instructions. The value of your product team is to design and deliver solutions that delight (ok, I hate that word) customers. We do that when we listen to what they aren’t saying so we can help them identify the real problems to solve.

Happy listening!

By clicking submit, you agree to share your email address with the site owner and Mailchimp to receive marketing, updates, and other emails from the site owner. Use the unsubscribe link in those emails to opt out at any time.

Processing…
Success! You're on the list.

Empathy in the Time of Coronavirus

I was at the grocery store over the weekend. It was one of those warehouse-sized stores so the few people in the building made it eerie. Though there weren’t many people, I noticed that everyone was saying a few words to each other and the staff. I was very aware that the conversations were darkly humorous about the virus and its impacts on our lives. I chose not to join in the jokes.

As a product professional, part of our skill set is to actively listen to HOW people say what they say. I didn’t hear humor. I heard fear. I heard annoyance. I heard uncertainty. My response to them – or lack of a response – was to make eye contact, to physically show my support (a head nod, a smile) and really hear them. They needed acknowledgement and I wanted to them to know “I’m here with you. I understand.”

We need to remember as product people when we actively listen, we tap into our empathy and emotional intelligence. Those are skills that enable us to respond and react in deeper ways than just hearing what what someone says. We can meet our clients’ unstated needs when we open ourselves to using those skills.

Coaching the Remote Product Team

Are you coaching a remote product or analyst team? As their manager, you’ll need to make sure they are ready for the challenges of working remotely. But some of the key skills they’ll need are the same skills they’ll need to be successful in the office. Here’s my list of the most important skills and capabilities that will make your team members successful while they are working remotely.

Facilitation

Because so much of the work remote teams do is by video conference or over the phone, having top notch facilitation skills is key. Good facilitation starts with having a meeting purpose and agenda. It’s knowing the right people to include and their roles. And finally, it’s being able to guide the group through the topics, achieving the intended purpose of the meeting. (See my post Five Principles to Make Your Meeting Planning Effective Every Time for more tips on planning effective meetings.)

Facilitation is more than knowing how to lead a meeting. It’s also about modeling behaviors that convey to the group that you are confident in what will be discussed, in getting the group to the goals stated in the agenda and more importantly, that you will create an environment that is psychologically safe and open so that the participants can contribute.

Active Listening

Active listening is listening with all your senses, not just hearing what someone is saying. Some of the ways to employ active listening is:

  • giving the speaker the floor or being silent as someone speaks
  • asking questions to not only clarify your understanding but also to show that you are engaged with what they are saying
  • paraphrasing or summarizing what’s been said to confirm your understanding

There are also physical ways that we can demonstrate active listening. These ways can be important to demonstrate when participating in video conference or phone call:

  • monitoring our posture and that of others to watch for signs of inattentiveness or defensiveness. Someone have their arms folded while they’re listening? Or looking at their phone? Are you slumped in your chair?
  • watching the body language of others on video calls. Just as you are monitoring your own physical state, it’s important to watch others for signs of disagreement, disinterest or discomfort. This can tell you a lot about how (or if) they are engaged.
  • knowing voices by name. I think this is a really special skill and one can that build trust and confidence especially in calls without video. You work with many of the same people. I’m sure you recognize their voice and can respond to them by name even when you can’t see them. Develop this skill and you will be a conference call hero!

Tools

Having the right tools at your fingertips make the job of being a remote work easier. The tools I’m referring to are the ones that will keep the team connected to customers and to each other. Having these tools isn’t the skill. Knowing how to use them and how to recover when they malfunction (which happens sometimes!) is critical. Leaders with remote staff should ensure that these tools in these categories are available:

  • Hardware – Let’s start with the obvious. Your machine or laptop. These must enable you to connect to the internet reliably but also connect to your network or the tools you use to do your job. (note about VPN: these can be fickle. Lots of remote workers can overwhelm a poorly planned VPN. Cloud products which don’t rely on network access are better for companies who use remote workers).
  • Internet – I have seen lack of access to or poor quality of internet be a barrier to remote workers. Your internet access should be as high quality as possible. Many times employers will provide a stipend for your internet account so be sure to ask.
  • Audio/Video tools – I don’t just include the computer in the list of required hardware. Having a camera and headset (or one of the fancier speaker/microphone combos) is essential. Your work is already largely conversational and collaborative as an analyst. You must have tools that will enable you to communicate clearly. Don’t just rely on your machines microphone and speakers. These are generally mediocre quality.
  • Collaboration tools – At some point, the results of your work will be documented and when it is, collaborative tools are the best. These tools allow you to get your thoughts on “paper” and then have co-workers or stakeholders access the same content. Collaborative tools like wikis (think Confluence), online document tools (Google Docs) or SharePoint make your work accessible 24/7 to an audience anywhere who can comment, update or view. These tools are critical to the role of the remote analyst.

Leaders of remote teams need to make sure their employees know how to recover or whom to call in the event that something stops working. The day doesn’t end if there’s a tool failure but the remote worker must be resilient enough to know what alternates are available to resume their work.

Self-direction

Do you get your work done when no one is watching? That’s pretty much every day on the job when you’re a remote employee. If being self-directed is tough, being a remote product person can be tough. A remote worker must be able to put together a work plan for the day and then perform her tasks. In addition, being remote means that if you encounter an obstacle, you must figure out a workaround or know that you must reach out to someone for assistance.

Examples of what it means to be self-directed are:

  • able to plan your own work
  • being accountable for seeing work to its completion with little direct guidance
  • being able to move forward without having to ask for permission or instructions
  • capable of independent decision making
  • knowing when to reach out for help before an assignment is late

Managers of remote teams must have regular touch points with remote employees to help gauge progress and assess their remote workers’ ability to keep moving. This doesn’t mean being over-bearing or micromanaging but finding a balance between checking in and letting the product team member work independently.

Team Spirit

Admittedly, this is one you probably haven’t heard before. I think having team spirit and knowing how to convey it is essential for the work of the remote product team. Most of the work that product professionals do is transactional. We have conversations. We ask questions. We listen to our customers. We build relationships. In the office we do this by “showing ourselves” to build trust and collaboration. A little play and team spirit are a crucial part of your virtual day too! Product Leaders and Managers, remember to coach your remote product team to incorporate a few of these things into their day:

  • Start the first few minutes of your meetings with a little light conversation. I call this technique Take Five to Socialize: A Remote Technique! As people are joining the call, call each person by name and speak to them. Such as, “Jenny, good to see you. How was your ski trip?” Tell a funny story or do a little show and tell. This light conversation builds a sense of community and trust.
  • Host virtual lunches or coffees. I spend a lot of my day on calls, but I like to catch up with my team mates every once in a while. The only time I can do that is over lunch . . . introducing the Virtual Lunch! We bring our lunches and shoot the breeze. Just like in the office break room but virtually.
  • Celebrate. I’m not typically the one in the office who decorates for holidays or dresses up for occasions but when I’m remote, I do. Why? Because I am in front of the camera most of the time and I want the people I work with to see that I’m human and I like to have a little fun. This can also be a fun activity if you have a multi-cultural team. I love seeing my Indian team members dressed so colorfully for Diwali and they love my ugly Christmas sweaters!

Managing a remote product team is much like managing one located in an office. The focus of your time however should be on coaching for these five key areas that will enhance their communication and collaboration. Coaching in these areas will make your product team not only better at remote work but better all around in their product work.

Common Myths About Requirements and Business Analysts in Agile

Years ago I used to host a study group for new business analysts in our organization that were just transitioning into our agile practice. One of the very first things we would talk about was what agile was not. For all the reality of agile, there are many, many myths particularly when it comes to requirements and the work of the business analyst. In this post, I tackle some of the most prevalent ones.

#1 Nothing is documented in agile

This myth goes something like this: “agile is fast because you don’t have to document anything.” Because agile methodologies don’t prescribe types of requirements to develop, I have found that many IT organizations interpret this to mean there are no requirements in agile. All of the agile frameworks support documented requirements of some sort. The difference from traditional methods is that the agile documentation is lightweight with a preference for executable requirement models over text-heavy specifications. More importantly, only what is needed to produce the story or feature is documented and nothing more.

#2 Stories don’t need requirements in agile

Agile lingo is heavy in the use of the word “stories” and light on the use of the word “requirements” in my opinion. I think the myth here is that stories are the only thing from which code is written and test cases are executed. This is misleading. Stories are simply placeholders for conversations about a feature or need to be developed. They are not intended to be requirements. The idea is that there will be collaboration to provide details about exactly what will be developed. That further detail is found in a requirement artifact. The nature of that artifact will be less like text-heavy, upfront requirement documents typical of traditional processes. Instead agile artifacts will incorporate models and diagrams that make requirements come alive for the business and IT team members. Still, that doesn’t mean that the model gives all the detail. Other artifacts, like system configurations, rule tables, error messages and non-functional requirements, must be built in order to develop a cohesive product. These artifacts will take the form of more standard requirement artifacts.

#3 Requirement management is not needed in agile

So if stories require some level of requirements then, yes, requirements on agile projects must be managed. But the term “requirements management” comes with its own baggage because of its association with traditional and waterfall methods of collecting requirements. I’m not suggesting detailed Word documents or complicated requirement tables. There is a need for being intentional about what artifacts will be created, how they will be linked together (traced) and what systems will be put into place to keep them updated, accurate and reflective of what is being built as it is being built. This takes a little creativity when the basis of the artifacts is lightweight and iterative, meaning small pieces will be developed over time. Someone – like a Lead BA – will need to have a big picture for how they will evolve over time and how to manage the versions of those artifacts. This cannot be ad hoc or left to the discretion of the BAs on the project (unless, of course, there’s only one BA). Requirement artifacts are assets, just like the working code or an automated test bed, that have a cost to build; therefore, how they are created and managed must be planned in agile projects.

#4 Agile teams don’t have business analysts

While it’s true that agile methodologies don’t have a specific role called “business analyst,” business analysis is critical to the success of the team by helping to ensure that value and quality are delivered for the customer. For example, the business analyst may:

  • plan and facilitate collaborative requirements workshops
  • act as the product owner if one is not or cannot be available
  • manage requirements to ensure completeness, correctness and consistency in delivering towards the requested feature
  • coach and train others on the team to create requirement models
  • perform other functional tasks needed by the team such as facilitating sprint ceremonies, writing the acceptance criteria, testing or triaging bugs

Analysis work may be performed by a BA or can be incorporated into the work of other roles on the team; however, analysis, elicitation and documentation of requirements must happen to ensure the right product is built.

#5 Product Owners do the business analysis in agile

The role of the product owner is the voice of the business and is the ultimate decision maker for the product. This role may perform some business analysis activities. However, while they may have a good handle on the needs of the business, they rarely have all the skills needed to perform business analysis. Business analysts can pair up with Product Owners to ensure that stories are fully fleshed out and more detailed requirements are developed when needed.

In addition, many times Product Owners may not be fully allocated to the project. Business analysts can fill the Product Owner role when necessary to keep the work moving. They may also be able to perform other Product Owner functions such as making some decisions, adding to or prioritizing the backlog, or working directly with the customer when the agile team has questions.

I’m sure you’ve heard some myths about requirements or business analysts in agile. Share your myths and let’s debunk them!

5 Guidelines for Effective Workshops

Outcomes define the success of business analysis professionals in organizations. Whether you work in an agile or waterfall environment, many of those outcomes are produced through working sessions. Workshops are a key technique in the business analyst’s toolkit. But all you need to know is how to schedule them, right? Nope! You need to know what makes workshops produced their intended outcomes. I use a set of guidelines that I learned as part of an organizational meeting culture overhaul a decade ago. In this post I share my top 5 guidelines for effective workshops.

Handshakes, Not Handoffs

This was a favorite quote from the CIO that sponsored that meeting culture makeover. He (correctly) believed that there was a significant return on investment by having the people that would use the workshop’s outputs involved in the workshops. Too often we don’t invite these folks because we aren’t talking about solutions yet or we don’t want to distract those folks from what we perceive as higher value work.

Our project outcomes told us a different story when we applied this guideline.

We were able to:

  • share the why and what behind the changes we were implementing to these people. This knowledge gave them a more complete understanding of the project that the documentation did not.
  • identify risks and issues early and make necessary adjustments before committing to solutions. This expedited later phases of work because downstream teams had accounted for them.
  • give downstream teams time to plan and prepare for their work, which dramatically reduced or eliminated the time needed to create these later
  • create a common understanding which enabled us to accommodate changes faster

I know. You’re saying “we can’t pull in those people earlier.” Is it always possible? No, but if you adopt this principle you can begin to find ways to incorporate them into your workshops and you will see a different in your outcomes.

Workshops are Collaborative, Working Sessions

Meetings are different from workshops. You can read more about what how I define those differences in my post Meetings vs Workshops: Workshops are for Working. What we generally call “meetings” are, in fact, “workshops.” Workshops produced a completed output. Getting to a completed output requires the organizer to plan what will happen to achieve that output.

Workshops must:

  • have a purpose (why are we having this meeting)
  • have an agenda (what do we need to do)
  • identify who is needed and why (ex. Bob, we’ll need you to make a decision on X topic)
  • provide pre-work when possible (so people have a chance to get acquainted with what we’re going to do)
  • define the goals or outputs of the meeting

And this principle includes the word “collaborative.” Collaboration is not a spontaneous activity that occurs when people get into a (real or virtual) room together. The organizer must put some thinking into how best to make the workshop collaborative.

Planning a workshop in which collaboration can occur includes making decisions which support a creative, productive environment like:

  • uninviting people that don’t add value to the outputs,
  • creating psychological safety by building equity among all attendees and reserving judgement of ideas, and
  • making time for fun and socializing

All Attendees Must Have a Defined Role

To have effective workshops, the right people must attend. The organizer must spend time to decide who those people are, why they are needed, and what they are expected to do.  Once you’ve answered those questions, you invite only those who will help you achieve the workshop’s purpose and produce its outputs.

I’m a stickler for ensuring that everyone who comes to a meeting knows why they were invited. The workshop purpose and agenda must be specific as to what will be achieved so that attendees can see why they have been invited.

I’ll share a secret with you. You can become a Meeting Hero. Become known as someone who invites only the people needed for your workshops then use their time effectively. It will make you a legend.

Bonus points for organizing workshops that regularly end on time or early.

Check out my post on identifying the right participants for your meeting or workshop.

Attendees Come Prepared to Work

Imagine for a moment that you plan a workshop, identify the right participants but don’t tell them what they will do. What kind of a result can you expect? Using more time than expected to prepare the group for the work they will perform in the workshop. This almost always results in a follow up workshop.

Imagine instead that you give your invitees time and material to focus on before you meet.

Providing pre-work gets everyone ready to participate. Attendees that come prepared are more likely to generate the outcomes you need. To do this, you must provide them with the materials in advance with plenty of time to prepare.

Your best case scenario is to have materials in the hands of participants no less than 24 hours before a workshop. The longer or more complicated the workshop’s agenda, the more time your attendees will need to prepare. Factor in pre-work to your workshop planning schedule. If you are late getting materials out, don’t ask your participants to cram. Reschedule your workshop or reset your agenda.

Are you having trouble getting your attendees to do the pre-work? That’s a common problem. Check out my post on When Your Participants Aren’t Ready to Work.

Workshops Are For Working And Completing Work

Effective workshops produce outcomes. They have a purpose and they produce a completed deliverables. What do I mean by a deliverable? A workshop deliverable is:

  • an approval,
  • completed tasks,
  • a decision,
  • putting the finishing touches on a work product, or
  • some other output that represents a final state.

Action items and notes are not deliverables. This is meeting hygiene content that can add to churn (will people read the notes? will the action items be completed? and if so, will they lead to another meeting?).

Reading a long document to an audience is not a deliverable (and don’t even get me started about what a waste of time that is). Consider what outcome you want to achieve by reading the document out loud. Is it to get changes? Is it to get approval? Those are deliverables. I would challenge you to reconsider whether getting everyone in a room to do that will get to a completed deliverable.

And here’s where your purpose will help you define the best format in which to achieve your deliverables. Perhaps the best use of time would be to have the reviewers read and comment on the document asynchronously and reserve meeting time to resolve outstanding questions and get final approval, only if needed.

Effective meetings happen when the right attendees come prepared to finish planned deliverables. Want to go into the components of effective workshops and meetings? Read more in my series on workshops and meetings!

Our BA Journey Begins

This blog has been on my mind for awhile. I’m particularly passionate about requirements management and its importance for business analysts. See, I’m a big believer that business analysis is most successful when it has a purpose and leadership behind it. Too often I see projects that need requirements and business analysts are deployed to “gather requirements.” There are no systems or standards in place. Project leaders believe that somehow the act of putting business analysts on a project – without their own processes or practices – will simply make a project successful.  What results is a haze of unrelated Word and Excel files stored usually on a shared drive or directly in the work management tool.  They’re hard to find and even harder to source control so practices of requirements re-use or versioning are not used (just a new document each time). Moreover, BA work and processes are ad hoc and inconsistent leading to uneven work products. When the project is completed, a lot of money has been spent to create requirement assets that will be thrown on the trash heap because they are almost immediately out-of-date by the time the product rolls into production.

You know what I’m talking about. You’ve been on that project. More than once, I bet.

So this blog is dedicated to requirements management techniques and leadership. I’ll give you a little strategy but we’re going to get right to the tactical bits so even if you don’t have a formal requirements management practice at your shop, you’ve got some tips and tricks you can immediately put to use.

What requirements management practices are problems at your shop? I’d love to hear your thoughts so we can make this blog what you need it to be.