Noise Cancelling Microphone Rodeo

Business, Reviews, Technology

I’ve been telecommuting for nine months now. There have been a number of changes as I’ve physically separated from the great folks in my company’s office. But the hardest change has been trading out face-to-face conversations for video conferencing. Although it’s never been easier to schedule and join video calls with our existing browsers, phones, built-in cameras and teleconferencing equipment, it’s still no match for being there. There is so much to communicate and perceive that can only be done with the full fidelity of unimpeded senses: micro expressions, vocal timbre, outside-the-camera-frame body language, posture and gestures, knowing looks and eye contact or lack of eye contact, physical presence, proximity and touch and conversation timing and cadence. Even with the best systems so much of this is just lost! In addition, artificial constructs impede natural communication with so many meetings starting with technical difficulties, bad connections, video and sound checks, issues around muting (or not muting) background noises and then there’s latency! It really does requires intentional effort to make sure that remote meeting participants can hear and be heard during a fast-paced conversations, debates and brainstorming. Ugh. Now there are ways to mitigate these problems and I’ll focus on just two. After all, this is an equipment rodeo and I need room to talk about that!

Video Conference Manners

I’ll start with this because with just a few things you can dramatically increase the quality of video conferences. Good protocol applies to whoever is conducting the meeting, whether in the conference room with others, or remote. 

For starters, not every participant can always see all of the other participants. So take a moment at the beginning of a video conference to make sure you all know everyone on the call. Acknowledge and do introductions just like you would if you were in person. Video conferences can feel impersonal if not anonymous so do what you can to keep it personal. 

Second, take a beat every so often to make sure that remote participants understand what is being said and have an opportunity to pipe in. You may not be seeing the normal nonverbal communication that would clue you into their confusion or need to interject. Generally people are a little too polite on calls and we should give even the meekest a seat at the table, virtual as it may be.

Know who’s on the call, give them time to speak and remember that it all sounds much worse on the other end of the wire.

Lastly, think about audio throughout the call. Are there multiple conversations happening? How many microphones are there? Is anyone not able to speak for lack of being heard? Technology has come a long way, but the audio fidelity in video conferences is nowhere near what it is in real life! The human ears are remarkably adept at filtering noise and recognizing sounds. With just your own head’s stereo-on-a-swivel your audio quality will always be better than those on the other end of the wire. Conference microphones are designed to pick up sound efficiently and make everyone sound close, so if you can’t imagine what a room full of people sounds like coming through a single tinny speaker, take time to join a busy meeting and experience it yourself. It will change the way you feel about over-talking, side conversations and natural pauses in the conversation.

Noise-cancelling Microphones

Even with good meeting protocol, having a bad mic can be a meeting killer. Background noise can betray your location or peel back the illusion that your home can be an effective office. Much is said about noise cancelling headphones but it can be difficult to find a noise-cancelling microphone! Don’t assume that your laptop or your webcam’s mic will do a good job. Most mics have one job: pick up sound indiscriminately—they don’t know that a lawnmower or a crying baby is unintentional sound. Thus began my search, when I realized that people could really hear noises from outside my home office. I did take some time to look at sound attenuation solutions for my office, but ultimately you really can’t/won’t change your walls or your door and sound definitely comes through those. So for me the solution had to come from the microphone.

Having some experience with audio engineering and the physics of sound, I was pretty excited about finding a mic solution that could cancel out unwanted noise. And I found some pretty good ones that did not disappoint. They all use “beam forming technology” which uses an array of microphones to identify the loudest sound and cancel out the sounds coming in on the other mics. If you want to see this in action, check out how the Amazon Echo uses this in a noise room and will light up the direction it hears you from. 

There was a point in my research when I had the epiphany that this problem has already been solved for people who take their calls on-the-go and don’t want the background noise of cars, wind or other people. You know, those people who wear bluetooth earpieces all day and you don’t know if they’re talking to you or someone on a call? I realized that to maximize noise cancellation and also get the benefit of proximity effect, I needed limit my search to microphone headsets. All of the headsets that I found with active noise cancellation were also bluetooth. I’m a tough buyer so I had a few key criteria, mostly around what it shouldn’t be, like looking like a headset from Apollo 11.

  • Excellent noise cancellation
  • Doesn’t require a lot of desk space
  • Doesn’t look like I’m doing anything “weird” to get good call quality
  • Doesn’t break the bank

So here they are, in order of my preference. If you’d like to see more, consider something from one of these lists. All of three are good. I feel like I was picking from the best available.

Plantronics Voyager 5200

My overall favorite. Although initially I didn’t like the design because it seemed bulky, my wife and daughter thought that it was the best looking and head-on, the profile is pretty small. What won me over was that in the testing this mic did the best job out cancelling out unwanted noise. The packaging was really nice, maybe too nice with its pull tab and magnetically-closing flap. The earpiece’s build is solid, but flexible and comfortable to wear for long periods. My favorite part is the ear tip that sits loosely in your ear rather than being shoved inside it. $80 on Amazon.

Sennheiser Presence

I really like Sennheiser. I have their e835 microphone and studio headphones and I can’t say enough good about this brand. So I really wanted this bluetooth headset to win. But it didn’t. The noise cancellation was good, but not as good as the Plantronics. I liked that it was small and it has this clever open/closed switch to turn it on and off. It was pretty light too and could actually just hang from being pressed inside my ear but it also came with an over-the-ear hanger as well. The packaging was simple and understated, which I also liked. $92 on Amazon.

Jabra Steel

This one was a surprise for me. I didn’t think much of it when I ordered it—it seemed too simple but the rugged design and manly-man packaging made me feel like wearing this would make my life better! I gave it a shot but overall the audio quality and noise cancellation weren’t as good as the others. If I kept this, I would only wear it when working in my shop or if I was digging a hole or something. It seemed pretty indestructible and I wouldn’t worry about carrying it in my pocket or dropping it. $60 on Amazon.

Testing Method

As I was most concerned about the mic quality, I tested each one with semi-scripted scenarios that included different kinds of background noise so I could compare them side-by-side as much as possible. I also evaluated ease-of-use, fit, price and packaging. I had some success with attempting to record all of them at once, but I ultimately gave up on that approach in favor of time. The recordings are available here for reference if you’re interested.

Mic Rodeo RecordingsDownload

JTBD Isn’t Complete, But It’s No Gimmick

Business, Design, Reviews

I avoided reading this article for 19 days! It came to me via email and I skipped over it every day to read all the adjacent messages, but not this one. It’s not that I didn’t have time, or that I wasn’t interested. I was actually very interested to hear from Jared Spool on the subject of Jobs to Be Done. I just didn’t want to watch him tear it down! I really like Jared and I really like JTBD and I need these two things two agreeably exist in my universe. JTBD has been a catalyst for my company to successfully focus on the appropriate aspects of our customers. It’s a watchword and a sentinel that continues to guard us from wasting time on well-intentioned but ill-equipped initiatives. When is was introduced to our company we even formed a JTBD guild to justify the fervor and frequency of our acolyte-level adherence! Now, we’ve cooled since then, having found an equilibrium where JTBD is a component of our overall research and decision-making processes. But it remains a key part of what we do. And the idea of unseating it was, let’s say, “unappealing!”

But today I read it. And Spool’s article wasn’t bad. It turns out that Spool employed a good old-fashioned marketing trick to get a rise out of me before I read it, and it worked. While the article title is polemic and seemingly critical of JTBD, I don’t think he’s really against JTBD theory or what Clayton Christensen was positing. But he does make two key points (that I do agree with) that bear repeating:

  1. How people understand JTBD now has more to do with the diversity of application from niche thought leaders and consultants, and it’s getting messy.
  2. JTBD isn’t groundbreaking for those of us who’ve been in user design for a while.

I’ll point out that if you want to prop up JTBD as a be-all, end-all for your business, you’ll find it lacking. It was never meant to be comprehensive. Christensen admits that and doesn’t explore, in particular, appropriate methods of user research. There is already so much content being created to apply the theory to different kinds of businesses. There will be different schools of though because there is room in business for it. As a theory, and a principle in practice, it’s up to you to determine how JTBD should be applied in your company. But as a tool to help form proper processes across the disciplines of your company, I think that JTBD is essential. Competing Against Luck should be on the recommended reading list for anyone who has honest doubts about their ability to correctly read human-driven markets. The article from Spool is also a good read. In particular the links to other works on design research.

Directed Discovery + Jobs to Be Done + Minimum Viable Product + Agile = Your business has a chance

If you aren’t 100% sure that you understand JTBD, you should read up. It’s well worth your time. But don’t start with derivative work or consultant websites. Read it directly from Clay. …… You’ll quickly understand what it’s about, and what it isn’t about. And then it’s up to you to determine how it fits in your company and processes. For me, JTBD plugs in after Directed Discovery and before MVP. Take that, Spool! 😀

Jobs To Be Done: An Occasionally Useful UX Gimmick

Opportunity Knocks?

Sears: now hiring!

I snapped this photo the other night while walking from my parked car. After a good chuckle, the nuances of why hiring at this outlet right now started to come into focus. I don’t know that anyone would expect to apply for a new career at Sears today… but… what if…

As Eddie Lampert angles to try to make something good (for him) happen from the crashing of this iconic brand, the rabble of unpaid creditors grow restless. What if he can pull something out of this?! Will the Kenmore and DieHard brands live on? Even in this dark uncertainty created by the failed effort to boost sales through overextending credit there is opportunity. I don’t know what it is, I don’t know if it’s good, and I’ll guess it’s just not for me, but it is very likely that there are many opportunities for someone. And that’s my point for sharing this picture: I don’t think opportunity knocks or texts. It’s hidden. If it was easy and obvious then it would be for everyone! Opportunity is a narrow circumstance for possibility, so don’t knock it.

Operant Conditioning

Uncategorized

We’ve all used operant conditioning. Just admit it. You know, when you take someone into a plain white room and hook them up to electrodes and then start–wait, what??!?!

No, not that.

As it applies to UX, operant conditioning is when an application attempts to change the frequency of specific user behaviors. Things like confirmation modals, success and zero states, some kinds of error messages, form validation, etc. It comes in several varieties but I want to quickly hit on three common ones:

Positive Reinforcement

Rewards, payouts, praise, humor and value are all forms of positive reinforcement that encourage users to continue to do whatever-they-just-did to get more. It’s the addition (positive) of something wanted.

Negative Reinforcement

Contrary to the colloquial understanding, negative reinforcement is not punishment. Silencing the alarm, hiding the error state, removing the danger, and opening the path are all forms of negative reinforcement that encourage users to continue to do whatever-they-just-did. It’s the removal (negative) of something unwanted. 

Punishment = Bad

Not going to say a lot here because computers should not be used for punishment. Like the first law of robotics, applications should not harm humans. Don’t do this or… or… you’ll be punished? But to be clear, punishment is the addition something bad or the removal of something good as a consequence for specific behaviors. Remember that punishment can only be marginally effective at stopping behavior, it can’t encourage behavior. As you know from your horrible experience with your second grade teacher, you never forget punishment. Not only is it a damaging method for changing behavior, once the punishment is removed, that behavior often returns! 

So What is Proper Reinforcement?

So the studies have been done. You can read more here, here and here and much of it applies to humans as well as lab rats. Everybody likes good things and hates bad things and there’s some morality here too: if you’re hoping to induce improper behavior in others, or worse, behavior that is good for you and bad for them? Stop reading now. 

But in software applications there are “good” behaviors and “bad” behaviors. Or more accurately, user actions that will get them the value they need and actions that will ultimately frustrate them. Incentivizing proper behavior is a smart thing and will actually contribute positively to the tenuous relationship humans often have with software.  And there is a real science to optimizing the change in behavior with proper reinforcement. While you might think that rewarding every “good” behavior is the best, it’s not. Users will actually have a higher response rate to reinforcement (e.g. start doing it sooner) and will have a slower extinction rate (e.g. will keep doing it) if the reinforcement is variable, both in time and frequency. In short, this means that we shouldn’t reward our users every time, but closer to about 50% of the time.

Key Takeaways

  1. Help users find their value by reinforcing supporting actions (e.g. the animation of a lock icon turning unlocked)
  2. Never punish
  3. Mix up the reinforcement (e.g. don’t toast “Good job!” every time)

Reading Guide for Software Estimates

Business, Technology

We’ve all been there. A lot. Before your next argument about a project estimate starts, take a minute to get everyone on the same page. Estimates are in important part of business AND estimates are often wrong. Yes, both of these truths can exist in the same universe!

My favorite insight from this set of articles was from John Cutler, “What job are you hiring estimation to do?” This perspective is perhaps the most valuable thing to keep in mind as your team works through your next estimate.

The Cost of Supporting New Features

Business

Everyone wants more features.

It’s like a car that has a toaster and a rocket engine. Sometimes that can totally make sense.

Plenty of people have covered the dangers of new features and I’m not going to talk about that the cost of building new features. Let’s assume that the new features are important for your market. What I want to talk about is the cost of supporting new features. Say you have a development team of ten. What percentage of that team is available for new development and which need to hang back on bug fixes and minor improvements?  At GoReact we’ve been able to maintain a sub-25% bug allocation for the past two years and we’ve really felt free to work on functionality that’s good for new customers and partnerships. But even with 75% of our resources we haven’t churned out 75% new features. Pointy-haired boss is wondering why at this point, right? Let him wonder. You will always have work in a couple of areas and your ability to anticipate and manage those pipelines as the needs ebb and flow is a critical piece to continued success with development projects. For me this means balancing the bugs, new features, internal projects and changes.

Kudos to the Phoenix Project for making this approach available for the general masses. It took me a year to read this book after a friend and coworker recommended it, and I regret that I lost an entire year of this perspective. It’s now required reading for my team and I keep a fresh copy at my desk for any new-comers. The sooner you understand what is really happening and what is really needed to run year after year, the sooner you regain the reigns on your team’s ability to really make the business move.

Those of us who have been around the block a few times know the pitfalls that come with maxing out development on new functionality. Don’t get me wrong here, I’m talking about sustained focus, like years.*  After huge pushes like this you can turn around to find out that your existing customers are leaving you because their product–the one that you built last year–is falling apart. Almost all of the time this is a bad thing, so unless you’re pivoting your product to a new market and pretty much leaving the old one behind, you’d better run some quick calculations.

Now here’s where I get a little fuzzy, so you’ll have to finish these equations out for yourself

Your velocity for new development (Vn) is what’s left over after you subtract velocity wasted on bugs (Vb), spent on changes (Vc) and invested in internal projects (Vi). In my experience the internal projects are usually small and pretty easy to prioritize where they support Sales, Marketing or Support. Hint: one of those is a cost center. That leaves bugs and changes.

This simple little ditty came to me during a daydream I had while in a product meeting. I’ll walk you through it and then we can have a good laugh about it. Your change velocity (which is refactoring, rearchitecting, server and configuration changes) can be calculated by examining the size of your code repository (R), multiplying that by the sum of the features that Marketing (Fm) and your customers (Fc) think you have and then you multiply that by the number of people on your Sales team. Then you divide that by the number of QA (Eq), product (Ep) and developer employees (Ed) on the team.

The equation for bugs is pretty similar but the numerator is your repository size and the number of features you actually have. This is all tongue-in-cheek but either way it seems like these are the only hockey stick graph (exponential growth) the product development team every sees!

Alright in all seriousness, we know that:

  1. Bugs are best mitigated by talented QA team members and a development team absolutely devoted to testing. We’ve saved ourselves a lot of customer heartache by ensuring that our code is the best possible quality and we attribute that as the reason our customers stick with us so long, second only to product-market fit.
  2. Changes increase as the code and features increase. This part is actually pretty simple math, but never ignore it.

We also track the velocity ratio between our top projects and what we call our “tribute” work. The latter for bugs, small UI tweaks, very minor updates and any out-of-band refactoring. We’re holding at about a 3:1 ratio. This means the next four hires are only going to give us three heads to focus on new projects.

Here is the real key: find your ratios and plan for those as you make hiring decisions.

  • Understand how much of your time is spent in each of your types of work
  • Understand what the business really needs in each type of work
  • Understand how the ratios can change as you:
    • Add more features
    • Add more code
    • Refactor for reusability and modularity

—

* I have to qualify something here. Sometimes teams start to feel some burnout after huge pushes and new features are often the scapegoat. There is a whole area of discussion around helping your team understand why new features are necessary and why bug pushes can be critical for a company’s success. There are also horrible stories about how managers misuse “death marches” and fail to do necessary research and justification for their projects. These big, hard projects can be a harbinger for the death cycle but they can also be just what it takes to succeed.  If you’re in a position to question your company’s approach, I feel very strongly that it’s always on you to get your questions answered and either alleviate your concerns or confirm your suspicion.

I loved Good to Great and although it’s getting dated the principles keep coming up.

Companies that fall into the Doom Loop genuinely want to effect change—but they lack the quiet discipline that produces the Flywheel Effect. Instead, they launch change programs with huge fanfare, hoping to “enlist the troops.” They start down one path, only to change direction. After years of lurching back and forth, these companies discover that they’ve failed to build any sustained momentum. Instead of turning the flywheel, they’ve fallen into a Doom Loop: Disappointing results lead to reaction without understanding, which leads to a new direction—a new leader, a new program—which leads to no momentum, which leads to disappointing results. It’s a steady, downward spiral. Those who have experienced a Doom Loop know how it drains the spirit right out of a company.

 

Eyes wide open. Success is predicted and planned for.

Vehicles for the Tall

Reviews

If you’ve met me then you’ll understand why shopping for a vehicle takes on an extra level of effort. At 6’7″ I don’t get all the headroom that I’m constitutionally entitled to which is an outrage! No seriously, tall guys get left out of a lot of great cars. For a positive spin, there’s a lot of horrible cars that I didn’t even have to consider, so I guess that’s nice too. So when I set out to get a new car, I knew that it would take some effort to find something that would work. I’ve driven a Prius, the Ford Expedition and several Honda Accords in the past, but it’s high time I got something that was made for a big boy. Here are some key takeaways from my research worth calling out:

  1. Of all the trucks, only the F-150 was tall enough
  2. SUVs don’t really offer more space than cars
  3. Man, there are a heck of a lot of SUVs that are basically the same!
  4. There aren’t enough Subarus in Utah

As I am want to do, I created a spreadsheet to help me refine down the list of cars, trucks and SUVs that I’d have to sit in to know if they’d fit. Dealing with dealerships and salesmen isn’t my favorite pastime so I wanted to keep the in-person stuff to a minimum, although it is SUPER important to make sure that you’re comfortable with AND in your new car before you buy. Here are the factors that I looked at:

  • Headroom and its cousin vision line height (VLH)*
  • Price and resell value
  • Consumer reports
  • Gas mileage (this is a commuter car for me)
  • Garage-fit

Weeding out the expensive, gas guzzlers and lemons, there were really just a few cars to seriously consider, although I did try on at least 20 vehicles from at least seven different dealerships. It was amusing to me to watch the reactions from the sales guys on the floor when I told them frankly but courteously that all I wanted to do was “try on a few cars.” They wanted to sell. I wanted to sit. Most of them were pretty cool about helping me out. The key piece of trying on each car was checking out my eye-line, sitting up straight and not leaned back to far, could I see out and up above (like stoplights) without slouching or bending? For some weird reason, in addition to low headroom, a lot of cars curve down from their peak over the driver’s head before the top of the windshield. Wasted space for tall people!

Here’s the spreadsheet I used: Vehicles for the Tall. Feel free to make a copy for your own needs and let me know if I missed anything. 

So in the end it was the Chevy Impala and its little sister the Malibu, and the Subaru Legacy. Of the three the Impala had the best visibility and legroom but I acted on a great deal I found on a Legacy because, in the end, I guess I really am a tightwad. But I’m happy with the purchase. I have the spreadsheet to remind me it was a good buy.

*Thanks to the folks over at Tall.Life for providing the initial research into tall-friendly vehicles. The reason that VLH is so important is because while a car may be tall (height top of roof to the ground), that doesn’t mean there’s a lot of headroom, and just because a car has a lot of headroom, that doesn’t mean that tall people will be able to see well out of the front windshield. VLH tries to give a metric for actual, usable vertical cabin room.

Statistically significant?

Business

If a p-value of 0.05 (5%) is too high, and the inventor of that threshold says it shouldn’t be used without consideration–which it is, all the time–then things we think are significant today just aren’t. We don’t always apply this kind of statistical rigor to decision making, but when we do we’re generally satisfied with this threshold. But we shouldn’t be.

Applied to product development teams, methodology matters a lot. But it can matter so much less than the talent of the individuals on a team. But methods and tools are still championed much more loudly than professional development.

In short, we should be looking for more obvious wins, and recognize that when something is close, but still statistically significant, it’s probably still too close to really move the needle.