When Product Management Goes Wrong – Part 5 – the Dread Pirate Roberts

In part 1 of this series, we looked at the underminer product manager. In part 2 we talked about the dinosaur. In part 3, we looked at the erratic driver. In part 4, we looked at the micromanager. In this post, we will discuss the Dread Pirate Roberts product manager.

The Dread Pirate Roberts manager threatens people in a misguided attempt to motivate them.

This is the final post in this series on product management anti-patterns. While it seems outrageous, and maybe amusing, I can assure you it is not the least bit funny to the people who suffer under it.

SPOILER ALERT.

In the book (and movie adaptation) The Princess Bride, there is a character called The Dread Pirate Roberts. Another character, Westley, is captured by the Dread Pirate Roberts. Every night, the Dread Pirate Roberts says to him: “Goodnight, Westley. Good work, sleep well, I’ll most likely kill you in the morning.” The Dread Pirate Roberts never does kill him, but this goes on for three years.

END SPOILER.

Dread Pirate Roberts

The character in the movie is fantastic and likeable, but if you analyze their behaviour, much of it is deplorable. This scene is so memorable that I have named this particular anti-pattern after it.

There are some product managers who think this pattern is a good tool. “We can’t let people get too comfortable, and there is nothing like a threat to motivate them, right?” Well no, fear is a terrible motivator. You’ll get a minimal level of compliance, but you will not motivate people at all. In fact, you’ll do the opposite and demotivate people. (You might also might end up being disciplined by HR, or by legal authorities if you do this.)

Here is an example.

I was helping a software company with some process tuning and advisory work. I would drop in for a couple of days a week and help them with whatever came up. They had created a new team to work on emerging technology, and they worked independently from everyone else on a brand new product line. It was an experiment to try to jolt some new thinking into a company that was resting on past success a bit too much. They had assembled a young, inexperienced but highly talented and motivated development team. They also had communications, marketing, PR and visual designers from the rest of the company working on the same floor. The office was in a gorgeous brick building that was a former factory and it was warm and inviting. The team used an open environment that practiced hot-desking, meaning no one had assigned space. You arrived, plugged in your laptop into a docking station, and claimed that space for your own that day. The next day, someone else might be sitting there, and you would find an alternative.

The development team had staked their claim on one side of the office and found it more productive to sit together. They would pair, diagram, brainstorm or play with nerf guns or have foosball tournaments to ease some stress. The marketing, sales and PR folks claimed another area on the other side of the office. The kitchen was closer to them, and they laid claim to a couple of vintage arcade games for stress release. Everything else in between was a free for all. There was a bit of an empty gap between the teams, but they tended to sit closer or further away depending on what they were working on, and there was a lot of positive energy and good natured joking.

One day that all changed for the worse.

I walked into the office that morning and instantly felt tension and stress. Heads were down, conversations were short and hushed, and the product owner had stopped working in the dev area and set up shop on the other side with the marketing ands sales people. The visual designer dragged herself into the office, clearly fighting the flu. Normally she would have spent the day in bed or worked from home. There was nowhere else to sit, so with reluctance, she set up near the developers. A mountain of kleenexes began to build around her and there were copious amounts of hand sanitizer being used by by everyone else. She looked nervous and afraid.

When the daily standup started, the individual reports were short, guarded and the usual joking and camaraderie was completely absent.

The product manager had returned that morning from a two week trip out of town visiting various client sites. Obviously, they had done something to throw off the team. Whatever they had done was clearly having a negative effect on productivity. The build server was quiet and when I checked the feed for source control, there wasn’t the usual pace of checkins. When I checked the productivity software, stories weren’t moving through the process like usual.

This was odd because they were self-organizing team with strong DevOps practice and they usually pushed several builds to a staging server every day. There was at least one production push per week that included bug fixes, new features and other things that customers and stakeholders were interested in.

Over the next couple of weeks, there were no pushes to production. I monitored source control and build machines, and found code check-ins to have slowed down considerably. The quality of conversations on new designs lacked the creativity that they did before, and the product owner would only show up briefly to clarify or discuss an issue, then would scurry back to the other side of the building. Everyone got sick because they were stressed and working too much, and they would struggle to work from home, or drag themselves in to meetings.

I couldn’t get much out of anyone other than “Talk to the product manager”, so I made sure to track him down. I asked what was going on and that I had noticed some changes with the team. He explained that senior managers weren’t happy with the team’s productivity, so he called a team meeting and threatened them. He told the team that he had picked each of them for this project, and he could easily get rid of them and replace them with other people who were coming off of other projects in the company, or hire new people. He had created this team and he wasn’t afraid of tearing it down and starting over if they didn’t start working faster.

“Are they afraid for their jobs?” I asked.

“They should be.”

Wow.

You can imagine my reaction. I tried to be calm and not ask if he was ****ing crazy, and if he really wanted the product to fail. Well, I did say it, but in much more diplomatic terms. The product manager told me he was directed by senior management to “put the fear of God in the team” and they wouldn’t relent. They understood it was killing productivity and it had a negative effect, but they were just doing what they were told.

The product manager felt the approach was drastic, but appropriate. When I also talked with senior management, they said they had no intention of letting people go, but if they feared for their jobs, they would work harder. No matter that people were so stressed out now that they were getting sick, no matter that productivity had plummeted, no matter that some team members weren’t even hiding the fact they were looking for new jobs, no matter that the development team had packed their belongings in boxes, waiting for the inevitable tap on the shoulder from HR. They felt that eventually people would work faster and do exactly what they wanted.

The opposite occurred. Productivity cratered, and people did get some work done, but the creativity, unique and amazing solutions disappeared. (There go some of your product differentiators.) After advising that this was abusive and not a suitable way to treat people, I left the project. It seemed that leadership were far more interested in feeling in control than creating a great product and having a productive, happy team. Their egos were stroked by controlling people, so that trumped everything. (This is likely why the Dread Pirate Roberts behaved the way he did in the movie threatening and toying with a captive.)

As you can imagine, the product didn’t succeed. Yes they managed to force compliance, but they created a weak imitation of their competitors’ offerings and it went in the market. People on the team left the project and most eventually left the company for more suitable working environments. (ie. non-abusive ones.)

As a team member, if you feel a constant threat hanging over you, you are going to feel fearful and not at your best. All this brain power is needed to deal with your fear and worry about what might happen instead of using that brain power for problem solving. It is horrible to experience. In fact, it is a form of abuse. People will respond to abuse in non-deterministic ways. ie. you have no idea how they will react, but it won’t be good. It won’t be good for the individuals, the team, the product or the company. It won’t be good for you either, if you are the abuser.

Threats and fear are tools that will enforce some level of outward compliance, but they are terrible motivators. Managers who think that they will increase productivity or get products or features out the door faster if they use empty threats are abusing their colleagues. Much like in the movie The Princess Bride, they may feel a sense of control and justify using empty threats. That was a movie though, in real life, pirate behaviour is abuse at best, and criminal at worst.

The Dread Pirate Roberts:

  • Makes threats, either explicit or implicit
  • Never follows through on said threats
  • Believes in antiquated management theory (ie. that fear is a good motivator)
  • Manipulates people to get their way
  • Changes their mind all the time so you never feel like you can make them happy
  • May deny making the threats when confronted, expecting you to doubt your own version of events. (Also known as gaslighting.)
  • Is likely a psychopath, or is directed by one

In another case, I witnessed an accidental Dread Pirate Roberts, but the outcome was the same: demoralized staff who weren’t as productive as they could be.

I had worked with the CTO of a rapidly growing startup at a couple of other organizations. We weren’t close, but we had mutual respect for each other. He told me that their product teams needed some help, but wanted to make sure there was a good fit with me and the VP of Product at his current venture. The VP of Product was a big, good natured man, with full sleeve tattoos and a shaved head with a large beard. He looked intimidating, even though he was kind hearted. He played up the look, wearing black t-shirts, designer work boots and a wallet on a chain. He joked that he was the king hipster of the company. He had a loud voice and a loud laugh, and because he had a nagging shoulder injury, he frequently crossed his arms when talking or listening.

The office, like many software companies, was dog friendly, and he brought his Rottweiler in to work every day. The dog was large and imposing, but quiet and would stare at people. Since it didn’t have much of a tail, it was hard to tell if it was happy to see you or not. It silently followed him around. It was an intimidating creature, especially if you weren’t used to dogs.

Prior to working at this company, I had heard rumours of this “big biker type VP” who would walk around the office with his dog yelling at people. I chalked it up to campfire project horror stories that programmers tell to scare each other. When I met with him and other leaders, I didn’t find him intimidating at all. He was open minded, kind hearted and quick to laugh. Reputations usually have a grain of truth to them though, so I was wary.

It seemed like a good fit, so I was brought in initially to help with User Experience (UX.) The UX folks had done a fantastic job, but the VP of Product had decided to forgo usability testing prior to shipping. The CTO asked me to come in and do an expert review and a heuristic evaluation. My work product was a report, and I made a few recommendations. I was careful to back up all the recommendations with at least two citations from UX experts. The UX team loved the report (I independently verified their concerns), but I was a bit worried when a nervous CTO told me to be careful, the VP of Product might need to be “treated delicately”.

The next morning, the VP of Product marched into my office, with his dog right behind him. His huge frame filled my doorway, and he threw a printed copy of my report on my desk and started yelling at me. His dog peered from behind him, and it felt like the dog was scowling at me too.

Picture in your mind a large, slightly heavyset man with a trucker hat, large framed glasses, Harley Davidson t-shirt, full sleeve tattoos with crossed arms yelling at you. His mouth was open wide and his large beard was wagging. Not to mention both he and his large, intimidating dog are blocking your only exit.

The horror stories were true! I was witnessing it in person. I could hardly believe it and I almost burst out laughing at the absurdity of it.

I can’t remember everything he said, but I got the gist of it: my report was garbage and he was going to rip up my contract and send me on my way. Once I got over my initial shock, I told him that his behavior was unacceptable, and I wasn’t going to put up with it. That escalated the situation, so I invited him in (so he wasn’t blocking my exit) and I asked if he would sit down. He declined, but he did at least come in to the office and loom over me. I was rescued by a call on his mobile, (which he took and talked at length in front of me) and that seemed to calm him down. When he returned to me, I distracted him by asking about his tattoos. Eventually, we found some common ground, had an awkward conversation about tattoos and then he picked up the report he had thrown on my desk and walked out. The dog gave me a look over its shoulder as it trotted after him. I almost felt like it was trying to get in the last word and give me one last scolding.

I’m not easily intimidated, but it was an incredibly unsettling experience. As a consultant, I had a lot of power and could walk away. What about employees who weren’t used to people who dressed and acted this way? What about subordinates or others who felt they had to do what he said to keep their jobs? This would be frightening to endure.

I immediately walked to the CTO’s office and told him what happened and that behavior was completely inappropriate. I said I would not work in an environment like this. He agreed, and asked what we should do. I said we needed to meet with the VP of Product and see if there was a way we could deal with conflict in a more healthy way.

The next morning I met with both the CTO and a now contrite VP of Product. We explained how his behaviour was intimidating, and that the threats, no matter how empty they might be, were distressing and abusive. We also explained that having his dog around while he behaved like this made it the situation worse. It was bad enough for us dog lovers. People from cultures that aren’t obsessed with dogs like North Americans are found it absolutely terrifying. He was shocked and visibly upset. He said he knew he had a temper problem, and that he was working on it. He said he had become angry because he felt that my feedback had criticized the product, and it was his heart and soul, so he felt personally threatened. When we explained that my job was to help the product be better, and not to tear anything down, and I asked if there was anything I could do to help with delivering the information so it felt less threatening. He said he had over reacted, apologized and asked for help.

As we talked, he told us that his father was a successful entrepreneur, and was a big “Theory X Management” believer. He felt that employees are inherently lazy, and need proper motivation to work for you. That upbringing had rubbed off on him, so he resorted to it at times.

In his father’s factory, in another era, it had worked. (Or so he claimed.) However, software companies tend to be egalitarian, and technical people prefer meritocracies. You might be able to yell and scream and get your way, but it isn’t the only factory in town. They can leave. Conversely, theory Y management works well in knowledge fields, where you assume people are intrinsically motivated, and with proper encouragement will work hard and thrive. He mimicked his father’s management style, and when you combined that with his large size, loud speaking, intimidating mannerisms (not to mention his large, intimidating sidekick dog), he tended to get his own way a lot.

He was asked to leave his dog at home for a while during office hours, and to not behave aggressively because of the way it made team members feel. If he felt threatened or angry, the CTO said to come into his office and talk to or yell at him first, if needed. Once the emotion was vented, he should then have the uncomfortable conversation with a peer or subordinate.

At first there was a dramatic improvement, and he really tried hard to adjust and grow personally. Eventually, he was able to bring the dog back to the office, but didn’t bring the dog with him to meetings or when he wanted to confront someone.

I would love to tell you that this story had a happy ending, but it doesn’t. Even though he said the right things, and seemed to sincerely want our help, he quickly grew to resent it. As time went on, the behaviour came back as his attitude soured. He had trouble taking responsibility for his actions, and while he would feel terrible after each outburst, he would rationalize it. He said that people knew that he didn’t mean it when he threatened them anyway, it was just his style. But not following through on threats is even worse than following through with something drastic. At least people know where they stand and what to expect. Furthermore, empty threats cause people to lose respect for you and your ability to tell the truth.

He was eventually forced out of the company, and it took a terrible toll on him afterwards. This was a case of someone really needing to grow up, it didn’t seem like the behaviour was intentional. His motivations aside, the company rightfully saw him as a liability, and got rid of him. Sadly “the Veep with the dog who yells at people” story was spread by every employee who left the company. (And for a while, there were a lot of people who did.)

I don’t have much to say about how to deal with the Dread Pirate Roberts product manager, other than to run away when you encounter it. Unlike the movie (or book by Goldman), I have yet to witness a happy ending. (Sorry for the spoiler.) I have seen this sort of abuse many times, and it never ends well for anyone. If you’re a product manager and you ever feel the need to threaten someone, don’t. Just don’t. Stop yourself and do something to distract yourself to get yourself under control. Take a walk. Count to ten. Drink a glass of water. Go home for the day and collect your thoughts. If you do this regularly, get some counselling and take a courses on managing people.

Bottom line: this behaviour is abusive and you should never do it, even if directed to by someone else. It isn’t worth the cost to the person you threaten, and you’ll not only destroy the people who you inflict it on, you will eventually destroy yourself and your reputation.

Gamification Principles for Product Management Revisited

A few of you pointed out that the link to my 2014 article for commercelab is down, so I have uploaded a PDF of it: Gamification principles you should consider in mobile product management

As I read this article, I realized there are two more important aspects that I have learned in the past couple of years that I should share. This is what I would add if I were to write the article today:

Focus on your core, and build out from there

Games have to focus on their core function or they won’t get used. For example, a lot of games focus on movement and actions (fire, gather, etc.) and then add functionality on that. If you don’t have the basics, you won’t have a very good app. If your game has a poor core function, it won’t get used, so their survival depends on it. It’s easy to get caught up in neat features, or cool ideas, but if the core isn’t solid, the experience will suffer. How do you identify the core? Take away everything, and then add back technology and features until people can get the job done with your app and no more.

Summarize and display of important information

Games are creating and operating with huge amounts of data, yet they don’t overwhelm players. They use clever views, HUDs and maps to show you what you need in context, and right now. Some games are brilliant at showing you what is important within your current location and context, yet providing cues to change focus and look elsewhere for important events or information. They are brilliant at information architecture and information display. We are often at a loss with non-game apps and easily overwhelm and confuse users. Games on the other hand have a lot of approaches for showing just the right amount of information, in a way that grabs your attention, right when you need it.

When Product Management Goes Wrong – Part 4 – the Micro-Manager

In part 1 of this series, we looked at the underminer product manager. In part 2 we talked about the dinosaur. In part 3, we looked at the erratic driver. In part 4, we will look at the micromanager.

A micromanager refuses to trust other team members to do their work properly. Micromanagers can’t let go of their projects, and don’t give people enough time and space to complete tasks on their own.

This is the most challenging management anti-pattern to write about because it has been talked about to death by people a lot more qualified than me. However, it is so common on software teams and so destructive that it needs to be addressed. While micromanagers are often concerned about positive project outcomes and making team commitments, their behavior has the opposite effect of what they intend.

I repeat: IF YOU MICROMANAGE, YOU WILL CAUSE THE OPPOSITE EFFECT THAT YOU INTEND.

image from pixabay

Microscope image from pixabay.

 

There are usually two different kinds of micromanagers:

  1. Outcome obsessed. They are overly concerned with budgets, timelines, resources and logistics
  2. Insecure. They are distrustful, lack confidence in their own abilities and project those feelings on to others

Early in my career I worked with two very different product managers: Mike and Jenn. Mike was a micromanager, Jenn was not. Both were programmers who were put in charge of their own products. They had developed new product prototypes on their own, and after there was sufficient customer interest and company buy-in, their job was to manage the product overall. That meant they talked to customers, did work on research, assisted with pricing models, and helped oversee product development and lifecycle management. It also meant they had to win over team members who worked on cross-functional teams to commit to working with them.

Mike was charismatic, an effective communicator, and had an overwhelming positivity about getting projects done and out the door. In brainstorming meetings, if someone said “it can’t be done”, Mike was the first to disagree and offer to try. He usually failed, but his efforts would inspire the team to figure out that there was indeed a way forward. Without his fearless efforts and inspiring manner, many useful ideas would not have been pursued. Mike was able to inspire others, and get them on board with his ideas, so he had a lot of initial team support for his product. However, he took any kind of criticism deeply personally, and would argue with people who didn’t appear to agree with him.

I was part of a small technical team assigned to both products, and we were closing in on shipping a version 1.0 of both within weeks of each other. It was hectic, and we could also be called in to help with customer concerns or high risk production issues at any time. The team was quite diverse; there were eight of us with different backgrounds and various levels of industry experience. It was up to the product managers to negotiate our time (within limits) and we had a senior project manager overseeing tasks and budgets and logistics. We were using two week sprints, and the project manager would meet with each of us at the end of each week to get a sense of where things were at and to see if we needed any help. The rest was up to the product managers.

Jenn worked on her own deliverables, and had publicized, daily office hours when we could stop in and ask questions without scheduling a meeting. She also wandered around and talked to each of us individually at the end of each day to see if we needed help. She let us determine the length and frequency of daily standups. Mike was militant about the daily standup, but the meeting would run over time because he would question absolutely everything anyone said. Mike also wandered around to check on us, but it felt like he was never not around. He would walk up behind us, stare at our screens over our shoulders, and ask what we were working on right then. He would then second guess our decisions, and argue with us.

At the end of each sprint, Jenn held us accountable for our commitments, and if we missed something, she would step in and help us adjust. If we felt we weren’t going to meet a commitment, we told her immediately, and she would work with the team to help us get back on track. Mike on the other hand held long, painful sprint demo meetings that could last for hours, mostly with him expressing disappointment in what we had done. We told him that he was getting in the way, and he needed to give us some protected time to actually deliver something instead of interfering all the time. He kept insisting that it was his ass on the line and that was that.

The micromanager:

  • second guesses everything
  • is distrustful of team members skills, their decision making, and their use of time
  • never seems happy with anything you do
  • focuses on the small stuff and loses sight of the big picture
  • complains about people arriving late, leaving early, and taking too much time on breaks
  • seems obsessed with up to the minute statuses
  • loves heavyweight processes and lots of documenting of everything
  • requires a lot of time entering and justifying time spent on tasks
  • obsesses over measurement tools and metrics
  • spends excessive time working and insinuating themselves in as many meetings as possible
  • causes people to feel like someone is always watching them over their shoulders

As time went on, and Mike’s product was losing out to Jenn’s for time, focus and attention, his behavior worsened. We did everything we could to try to talk to him about it, but nothing seemed to help. Finally, out of desperation, all eight of us added an “arguing with Mike” item to our timesheets. After a week, the project manager came marching into the office to ask what the hell was going on. Why was there an “arguing with Mike” item in our timesheets, and why was there a team average of 8 hours per day being spent on it? It turned out that each of us were averaging at least an hour a day dealing with his micromanaging behavior. That averaged out to 40 hours a week! It was an expensive waste of time. This triggered a senior management intervention, and they talked to Mike. He was upset with what we had done, but understood we had run out of options. Eventually, his project was so far behind, he lost funding and Jenn’s project shipped. He was given two more opportunities, but in spite of a lot of senior management support, the behavior persisted and he was demoted and let go. Mike’s efforts had the opposite effect of his intentions. What went wrong?

There are some important negative outcomes of micromanaging to be aware of. First of all, when you don’t allow people the freedom to make decisions about at least some aspects of their work, they’ll be afraid to be creative and their work products won’t be as good. When they feel that you don’t trust them, they will resent you and will only do the minimum required. If they feel that you are counting every minute they spend on a particular task, and how long they stay for the day, they will count every minute they spend on your projects. When they have finished counting, you won’t get a minute more of their thoughts and efforts. If you second guess their decisions, they will lose confidence in their own abilities. When you measure at the micro level, you will miss the important things, like deadlines, budgets, key feature deliverables and even shipping the product itself. The last point might seem counter-intuitive – if we are really concerned about deliverables, budgets and timelines, won’t micromanaging help, even if people don’t like it? The answer is a resounding NO!

Measuring the small stuff causes everyone to lose sight of the big, important stuff, like features, deadlines and budgets. There are only so many hours in a day, and of those, only so much time where people can focus on project logistics. If you spend all that time worrying about things on the micro level, there won’t be any time to work on the macro level items. Furthermore, if you measure people at the micro level, they may deliver, but it won’t be in alignment with the rest of the team. They (and you) will lose focus and you’ll have what I call a “bucket of features”, but not a cohesive product.

The human cost is brutal as well. You will have people who only work for the time they are paid for, will be unable to be creative, won’t think about problems on their own, and will be worn out and fearful. Most of your team will actively look for another job. Creative people who are outspoken will at first display anger and find another job as quickly as they can. People who have more responsibilities and others depending on their salary will stay longer, but they will shut down and only do what they are told. Team morale will plummet, and you as a product manager will have to work ten times as hard to get anything out the door.

I’ve worked on teams that were dedicated, creative and had great cohesion and were in alignment with senior management, only to have a micromanager join the company. One example was a cutting edge startup that was well capitalized and was on a huge growth trajectory. I helped them with some basic growing pains, and it was a great place to work. People arrived early, stayed late, and the place was a constant buzz of energy. They loved their work and to be at the office with their coworkers. The problem was that people were doing too much, so they had to put in rules about how many hours a week you should work (so you could rest and be refreshed and productive) and to take your vacation. Employees still researched on the side, and took online courses to learn more to bring to the table. There was a quicksilver of creative problem solving that was infectious.

Six months later, I returned. The once bustling, busy office environment was quiet as a tomb. Management complained that people only put in minimal time and effort. The lunch room and break rooms, once hubs of knowledge sharing and teamwork were dead zones. People would rush in, get what they needed and leave. No one arrived early, and no one stayed late. (NOTE: This can be abused too, so don’t expect people to work overtime for you without pay. When people want to spend a few minutes here or there extra, try to reward them for it.) Productivity was down, and senior management had to put in a lot of overtime and have a lot of meetings to repeat goals, and supervise product development. A bit of investigation revealed that they had hired a micromanager and put them in a significant position of power. One project that year shipped on time. Product quality suffered, clients got upset, and staff turnover went through the roof. On some teams, people would stay for an average of three months. It was horrific to witness. One bad hire ruined the company and they never quite recovered.

What do you do instead?

  • give people enough time to meet deliverables – days, not hours
  • leave people alone to get stuff done! (unless they need help)
  • be visible, available and encouraging in case they need to ask you questions or need encouragement
  • make lost time due to micromanagement (especially your own) visible
  • empower people and trust them to do the right thing. Just because they do things differently than you like doesn’t make it wrong
  • people make mistakes. If they are honest mistakes, use them as learning experiences, don’t hold a grudge.
  • pick battles: live with some outcomes that you may not like, but move the process towards shipping instead of nitpicking
  • measure value points at a higher level such as features delivered, products and services shipped rather than individual tasks
  • hold people accountable for missing their commitments and make it visible so everyone knows where the project status is
  • succeed as a team, fail as a team – don’t single people out unless it is required due to performance issues, attitude problems, and do that in private

More recently I was asked to help a team that was struggling with delivering software for a new client. This was a startup that was well funded, but the CEO was worried about team performance, so I was called in. Dave, the CEO, had hired experienced developers and an experienced project manager. The team was very small and deeply experienced, so the first red flag to me was that they needed a project manager at all. Dave and I had worked together in the past, and while he saw the value of a product manager, he decided to also play that role to save money. Dave read articles about product management, and took a short webinar on how to be a product owner on an Agile team. He did his best, but he knew something was wrong – they had been working on a 3 month project, and 6 months in, they had nothing to show for it.

When I arrived as a product management consultant, the project manager was on the way out. The programmers had resorted to working from home as much as they could, in spite of having a well appointed, modern work environment that they had designed for themselves. Any meeting of three or more people would devolve into arguments that were unhelpful. Any meeting of two or more people would catch Dave’s attention (he had a nice office with glass walls, and faced outwards) and he would swoop in, eavesdrop, and then start to get involved, no matter the topic. Daily standups were no longer held in the dev area, they had moved to the boardroom with everyone sitting down. This was because every person who spoke up and reported what they were working on, what they had accomplished and if they were having any problems were grilled by Dave. It took far longer than a few minutes. To cope with this,if you didn’t want to be grilled, you didn’t say much. Also, if you didn’t do much work at all and kept a low profile, you flew under the radar and were spared. (Result? Several people were doing little to no real work for fear of reprisal.)

Dave was a type-A personality extrovert, and he was working with mostly introverted technical people. They needed protected time to be productive, and he needed to talk to people to think. Anyone that was sitting quietly that caught his eye would fall victim to a chat. Dave didn’t realize that the programmers needed protected quiet time to be productive. It was even worse when they were pair programming. Dave’s efforts had the opposite effect of his intentions.

This required a major intervention, and I wasn’t sure if it would work, because it meant Dave had to go through some personal growth. I would too, by virtue of working with him and both of us solving this particular problem together. I was willing, Dave was willing, but were we both able?

The first thing I did was create a product roadmap. Dave felt it was an unnecessary expense since the team was small, and they were already behind schedule. Why would I spend the first few days on that? But, he trusted me, so we worked on it together. Once we had that squared away, and the team agreed with the vision, I implemented a simple project management system. We used spreadsheets to create a product backlog and sprint backlogs. We only used the project management software they had been using for bug reports and high level features. We created a status dashboard on a whiteboard, and since the team was now a bit distributed, we re-created it in a spreadsheet that everyone could see.

Dave was banned from standups until he could learn to be an observer, not an active participant. He was also banned from engaging with staff who were working, unless they initiated it, or were in a break room or the lunch room. If they were at their desk, unless it was an emergency, they were to be left alone. If he needed to talk, he had to talk to me first. We also recruited a couple of his peers that he trusted deeply to stop in or call him more frequently so he could talk through ideas and get what he needed.

Next, we prioritized features and tasks, and the programmers made their own commitments for them. They decided a two week sprint was adequate, and signed up for an ambitious set of deliverables to demo at the end of that sprint. I was skeptical because it was so ambitious, but I kept my thoughts to myself. Dave was also skeptical, because he wanted more. Thankfully, he kept that to himself (and me of course.) I also told him to back off for two weeks, and if the deliverables weren’t met at the end of that sprint, then we would be worried. People needed protected time where they actually had a chance of delivering. We empowered them to make their own decisions, and to come to us if they needed help, but they were on their own. I would be visible and available, but no one would hound them anymore.

This was INCREDIBLY hard for Dave. He constantly backslid, and he would pull me into his office or phone me several times a day. I sent him daily status reports using a template for client billing, and he would phone me immediately after I sent them with lots of questions. But after a few days he settled down and decided to trust the process.

I’d love to tell you that at the end of two weeks the team delivered and everyone was happy, but that was not the case. It was a mess. There was nothing tangible that was delivered. Two team members realized they were in over their heads and resigned, and one engineer was put on probation for poor work and was eventually let go. Dave was furious at first, and told me he wanted to fire everyone, but after sleeping on it realized where he had gone wrong. His constant micromanaging had hidden skill gaps, and there were no real methods of accountability. He went from one small problem to another small problem, and people didn’t sign up for anything, didn’t commit to anything, and he had no way of measuring real progress. Micromanaging actually destroys accountability. With the simple, yet visible system we used, problems related to product development became apparent almost immediately. People signed up for their own commitments, and if they failed to meet them, it was visible.

The team was in crisis, and Dave knew they were in serious trouble. If they didn’t meet this commitment, they would have no revenue growth and would likely go under. However, instead of panicking, he rose to the occasion, as did the experienced senior team members. We managed to recruit a couple of expensive, but skilled consultants to help address the skill gaps, and we got it done. The product was gorgeous looking (we had a fantastic visual designer), but it barely worked. However, the client loved the first version, and it was good enough. There was an enormous amount of refactoring that was required, but it got the job done. Revenue trickled in, board members and angel investors were appeased, and the company lived to fight another day. One of the consultants even stayed on to work full time with the team because they enjoyed the work and technology so much.

Eventually the team were able to go back to the process they had been following in the past, and left the spreadsheets behind and mirrored that functionality in their productivity tools. It was harder for Dave to adjust. He went through a lot of painful personal growth, but came out the other side as a much more solid leader. After the fact, he shared with me just how difficult it was, and how he had to resist his initial instinctive reactions. A couple of board members and trusted advisors answered his call for help and really helped him through some tough times outside of the office. It took a long time for him to regain trust in the people, the team as a whole, and the process. I urged him (and still do) to measure outcomes that demonstrate value, (such as working features, products and services) rather than on tasks. That way, the team can excel at doing what they do best, and he can be involved and completely focused on the incredibly difficult job of CEO. (Yes, he did hire a product manager to delegate to, and project management is shared among senior team members.)

Mike was a product manager who was insecure and unable to go through personal growth to become a good manager. Dave was an outcome-obsessed leader, but he still had to go through painful growth. The Mikes of the world have talents outside of leadership, and that is fine. The Daves are usually fantastic leaders, but need good creative product builders. Mike went back to being a creator rather than a leader, and had much better success. Jenn was a unicorn who could switch between technical and leadership roles – they do exist.

There is a lesson here for all of us: all of us will have elements of dysfunction in our leadership approaches and personalities. When under extraordinary stress, these will become much more apparent. When we feel pressure and the team doesn’t seem to be responding the way we’d like, it is incredibly tempting to micromanage. But remember: IF YOU MICROMANAGE, YOU WILL CAUSE THE OPPOSITE EFFECT THAT YOU INTEND. All of us need to take a cue from Dave from time-to-time and deal with our weaknesses head on, for the good of the team, and most importantly, for our own good.

Note: I first wrote about the micromanager management pattern in this article for Agile Connection.

When Product Management Goes Wrong – Part 3 – the Erratic Driver

In part 3, we will look at the erratic driver product manager. In part 1 of this series, we looked at the underminer. In part 2 we looked at the dinosaur product manager.

The erratic driver is a leader who either can’t make up their mind, can’t stick to a plan, or both. This disrupts the work of others, hurts productivity, and threatens schedules and team commitments. Team members may work on items that are subsequently rejected, or they may spend precious time waiting for decisions that aren’t forthcoming instead of producing key work items.

Track maintenance car image from Wikipedia.

There are usually two types of erratic driver product managers:

  1. A visionary who thinks ahead and sometimes struggles to stay in the present, consistently disrupting the team with new ideas
  2. A manager who lacks confidence in their own decisions as well as others

The first erratic driver tends to be easier to deal with, but both can do a lot of damage due to their behavior. The first place they do damage to is the product itself. When they change their minds a lot, the vision and value proposition of the product gets muddied and lost.

The second area of damage is to productivity, and scheduling goals. Since they change their minds and second guess the work and commitments teams have agreed to take on, there is a lot of duplicate effort, wasted effort, and plain old waiting around for someone to make up their mind.

On one team I worked on, the head of product had a reputation of approaching software development the way 5 year old children approach soccer (or football depending on your locale.) They start off more or less together, and then things quickly fall apart. Sometimes they chase the ball, sometimes they chase each other, sometimes they move the ball down the field, sometimes they try to score, or defend. Sometimes they even try to score on themselves. Many times, the ball is forgotten by all the players when something interesting and shiny appears to distract them. It’s entertaining to watch, but not very effective at reaching goals.

The head of product oversaw several products and services, and fortunately, each of the product managers that reported to him were shippers. They worked hard to get great products out the door consistently and effectively. Each product manager had a good balance of domain knowledge, market knowledge and technical skills. That meant that the teams they worked with were productive and effective and were able to get things done, but when the product lead changed their mind, they would be undermined and foiled. This company was well funded and had a great pool of talent, but there are always limits on people, resources and logistics. However, depending on the whimsy or stress felt by the head of product, priorities would shift. Needed resources and people would be pulled off of one project and assigned to another. Marketing and sales campaigns would be put on hold, with others suddenly requiring strategy and copy. Progress would start on the new initiatives, stop on others, and productivity would shift to other groups projects. Repeat this on a cycle of 2-5 weeks, and you should be able to predict the outcome.

None of the products or services were ready at the times they needed to be. That meant sales suffered, and the credibility of the company suffered with not only existing customers, but also with potential customers. The company eventually gave up their technical leadership credibility in the market as well. They were surpassed by competitors who were better at managing schedules and were able to honor their public commitments.

A bit of investigation revealed that the head of product lacked confidence in their ability to make decisions, and was easily influenced by powerful stakeholders. In fact, they would misinterpret senior management brainstorming ideas or even misinterpret their moods as directives for the project. That meant that decisions were delayed, overdue, and changed frequently. Not only were the technical teams impacted, but marketing and third party commitments with PR and tradeshow vendors were changed. The products would be late, 3rd parties would charge for work that wasn’t required, and everyone suffered. This problem could have been dealt with if the product manager had trusted their teams and listened to their advice, admonitions and warnings, but they didn’t have confidence in them either.

I worked as a project manager on one of their products, and we were able to create a visible process so that when the head of product changed their mind, everyone knew about it. In the past, information would trickle out to different team members at different times, causing a lot of confusion and needless effort. I also asked them to help me create some mechanisms to deal with their erratic behavior. (I was a bit more diplomatic in how I addressed it than written here.) I then set up frequent meetings with senior members of the team to provide the head of product to discuss concerns, and to shield the team from freakouts. We also created a process on decision making, and asked that any change in direction be driven by real evidence. We also assured the head of product that any success or failure was shared by the team, not one individual, and when required, one of us would step up and take responsibility for a tough decision when the head of product felt paralyzed.

This helped a tremendous amount. Unfortunately, since they were coming from a place of fear rather than fast paced visionary thinking, they did a lot to undo the process, even though they saw the value in it. We were constantly undermined, and our senior team members spent a lot of time trying to keep the team protected from freakouts and churn, reviewing decisions and work products over and over with the head of product, and dealing with other team members who were pulled off track. In spite of some success on our project (our project was the only one that shipped on time and on budget that quarter), the head of product’s track record was so poor across their entire portfolio, they were eventually asked to leave the company.

The erratic driver:

  • changes their mind frequently
  • overthinks options to solve problems or what to develop next
  • delays decisions on tough problems as long as possible
  • second guesses and over-rides prior decisions
  • interrupts team members, and sometimes the entire team, pulling people off task by having discussions, or making pronouncements about changing direction
  • disrupts team alignment with regards to product development
  • has trouble differentiating between short term vs. long term goals and ideas
  • confuses the team about timelines and priorities either due to indecision, or by getting excited about something new
  • is unhappy with developed features
  • wants the team to move faster (to keep up with their ideas)

How do you deal with an erratic driver?

  • make decisions visible so everyone knows what is going on
  • make project management visible so that deviations are spotted quickly
  • use a process to manage work to reduce confusion about priorities
  • provide realistic costs to changing a feature, or direction – when faced with the potential impact of change to productivity and schedules, that helps determine if the change is needed now, or is ok to do later
  • make sure there is a product roadmap prior to signing on to a project
  • use roadmaps to manage development priorities and planning to keep things focused and on track
  • create a brainstorming roadmap to use with senior team members only for whimsical ideas or long term ideas with a process for promoting these ideas to the formal roadmap(s)
  • provide a safe place for brainstorming and letting off steam, instead of randomly interrupting team members
  • utilize user experience techniques to help remind us to focus effort towards customers, not by the turmoil in the leader’s mind

On another team, I worked with a visionary erratic driver. (Side note, many, if not most entrepreneurs are erratic drivers at least at some point. Their brains work quickly, they like to entertain a lot of ideas, and they are thinking longer term than where the team is currently at. It’s easy for them to be thinking years in advance, and they get frustrated when labour intensive efforts like software development can’t keep up with them. Learning how to deal with visionary erratic drivers is an important skill for product managers.)

This product manager had a rare gift of being able to identify unaddressed gaps in the market, and quickly come up with technology solutions to match. Once they put their mind to it, they could come up with very polished pitches to stakeholders and get people on board who shared their vision. They could almost effortlessly attract funding and willing team members to work with them. Unfortunately, once the team was settled in and getting productive, they would constantly brainstorm and share ideas for features that would be implemented down the road. They would get excited about these feature ideas, and the team would feel pressure to implement those brainstorm ideas now, instead of when they were intended to be developed. That meant that the evolving product was incoherent, and short-term priorities were often missed.

The product manager also spent a lot of time studying new technology, and would second guess prior technology choices when something new and shiny appeared. We were using JavaScript frameworks, which tend to go in and out of fashion faster than designer jeans. That meant the team was at times bombarded with new framework information, which pulled valuable efforts away from current development. Some team members worked on items agreed to and specified on the roadmap, while others strayed due to confusion and individual direction. As a result, demo days were dreaded because the product manager was always unhappy. “Why did you work on that?” “That isn’t what I wanted at all.” and “I didn’t mean for you to work on that now. were common.

The team was misaligned and frustrated, productivity suffered, and the end result was a product that was disjointed and difficult to use. I sat down with the manager and discussed their behavior and the corresponding team reactions, and asked if we could set up a system to help.

Once I carefully and as non-threateningly as possible went over the manager’s behavior, I suggested some process tweaks. I asked them to work with me on setting up a process for brainstorming whimsical or half baked ideas. The idea was to disrupt the team less, and to have a rule in place to determine whether the team members needed to be interrupted.

To help with team alignment and erratic decisions and work products being developed that weren’t focused, we formalized a product roadmap, with three sections listing efforts and associated priorities:

  1. Current development
  2. Near-term development
  3. Future development

Next, to take technology decision churn out of the picture, we pulled technology out of the product roadmap, aside from high level goals, such as supporting mobile devices and using a modern framework with great user experience. We then tasked the technical team with making the decisions about technology, and helped them create a technology roadmap. The product manager could have input and was consulted, but the technical team were ultimately responsible for picking the right combination of technology to meet product goals.

To make the product manager aware of the cost of changing their mind, we worked with the project management process to make sure work was visible, and effort was accounted for. It was important for them to understand that whenever they change their mind, team members lose productivity and need to refocus before becoming productive again. Also, it was important that they understood the efforts required for new development, and what the trade offs were. If you change now, what are you going to give up? In addition to raw efforts that are required, team members also need to spend some time archiving their current work so it can be picked up later on, researching and getting up to speed on the new work tasks, and then getting productive again.

To help align customer needs with product development, we worked on incorporating field data into the process, so we set up formal weekly meetings with marketing and sales and PR. I helped the UX and graphics design team to come up with a review process for the product manager so they could approve designs prior to implementing them. We also created design documents that outlined style specifications for products such as fonts, colors, logos and other important issues. I then worked with the UX and design team to help them communicate their designs more clearly, and to add their needs and goals to the technical roadmap.

Finally, we set up a formal process for sheltering the team from getting disrupted by new ideas, creativity flashes and self doubt. We started with a weekly meeting among senior team members for brainstorming and sharing half baked ideas. From that, I created a spreadsheet where we would record the ideas the product manager wanted to keep, and we had a promotion rule. Ideas that were really far out were at the bottom of the list. If they were talked about again, they started to move up the list. If they were mentioned frequently enough, I would ask if they should be promoted to long term roadmap commitments. Often, the product manager would say no, but sometimes they would want the idea promoted and added to the near term. Any new changes during development were spelled out with associated effort and cost. That would also help determine if ideas for features or change were serious and needed to be acted on immediately or in the short term. We would review the list periodically, and some ideas from the bottom of the list would be removed.

Visionaries have hunches, and sometimes they need to bypass the process because they have good reason. That meant the product manager also had veto power, since they were ultimately in charge of the product. If they felt very strongly, they could stop work and guide the team in a new direction if they felt strongly enough. At first, they wanted to use this more often if they felt they weren’t getting their way, but once we would pull up the roadmap, discuss current commitments, and associated costs of change, they would back down. Sometimes though, they had a gut feel and felt strongly enough to change and deal with the associated costs. They were almost always right about these changes.

The product manager was uncomfortable with the process at first, but I asked them to respect it for one two week sprint, and see what they thought. After the first sprint demo, they were much happier, but were still concerned about delivering the software when they needed to in 8 weeks time. It wasn’t without hiccups and backsliding and issues. (I would find out about the product manager varying from the process and confront them about it, and we would adjust. Either they would adjust their behavior, or we would tweak the process.) However, we delivered in the time frame that was required, and because of the process, we had a much more focused, usable product that the product manager was happy with. The team met their commitments, and the process was formalized further and later coached and enforced by the product manager instead of me. Surprisingly, the UX and design team were the happiest with the outcomes – they got constructive criticism early, and had far less re-work after sprint demos.

Erratic drivers are incredibly common in visionary roles, and it’s important to learn how to work with them. Visionaries are able to marshal both the required resources and technology together to create new products. They have a rare gift. The downside is that they think quickly and are creative, and when they get excited about new things, they can infect others with that excitement. If it isn’t managed properly, passion and excitement can become distracting and destructive. Many company founders are visionaries, and early stage software startups are full of erratic drivers. While they are most common in new ventures, visionaries with erratic driver tendencies are found in any kind of organization. Good processes and solid communication are important to work on when you encounter the behavior. Some of you who are reading this might have erratic driver tendencies yourselves. If you are a product manager who is an erratic driver, start creating your own process to keep your activities focused on shipping great software, and safeguard against needlessly distracting or holding up work when waffling on decisions. If you ask for help from key team members you trust, they will step up and help keep you honest.

Note: I first wrote about the erratic driver management pattern in this article for Agile Connection.

When Product Management Goes Wrong – Part 2 – the Dinosaur

In part 1 of this series, we looked at the underminer. In part 2 we will look at the dinosaur product manager.

A dinosaur is a product manager who is out of date, and they obstinately refuse to consider anything that is current. They have their model of the world, and they refuse to learn anything new. They might be out of date with any or all of the following: the market, competing products, their customer’s current expectations, pricing, monetization models, marketing and sales approaches, current technology and design trends.


Tyrannosaurus image from Wikipedia.

Of all the product management anti-patterns, the dinosaur is the one that I find to be one of the most painful to witness. As a technical product manager who works with new and sometimes cutting edge technology, I run into the dinosaur quite often. It’s painful to observe because you see all these people working so hard, and the team inertia is moving in a direction, yet one person is getting in the way. It sucks the life out of teams, and it’s also one of the most difficult behaviors to deal with.

Dinosaurs are people who for whatever reason have stopped learning. They have a specific approach and they are frozen there. Often dinosaurs are more experienced people who are fatigued with learning new technology, or they might be jaded after too many campaigns. Software is a tough, demanding business.

I get the learning fatigue. As you have more experience and have learned a lot, it is tiring to learn yet another web framework, a new set of productivity tools and yet another design paradigm. Right now I am learning some new approaches to mobile development, and a whole new templating engine for web applications using responsive design. It isn’t as much fun to learn as when I was new in the industry, and I have to fit that in between engagements and deliverables.

However, I have also met dinosaurs who had very little experience, but they have still chosen an approach and refuse to update their thinking.

Recently, two executives asked me to help them with a difficult problem at their company. They were creating a new product to expand their product line and steal market share from an emerging, lucrative market. Their existing customer base was maturing, and there were strong economic forces at play that they felt threatened current revenue streams. They didn’t want to get caught when an inevitable decline hit the market, so they were looking seriously at other sources of revenue that better fit emerging market conditions. They implemented a “20% time” for technical teams to spend time coming up with product ideas, held facilitated brainstorming workshops, and engaged heavily with their enthusiastic supportive customers and trusted industry contacts.

As usual, the problem they posed to me and the real problem were two different, yet related things. They didn’t say anything about the VP of Product Management, other than mentioning them in passing. In fact, they said the problem was an alignment issue between the experienced people in the company, and a young engineering team. The execs gave me the impression that the engineering team on this project were the problem here – they weren’t respecting the more experienced people in the company. But the execs said they would let me figure out what the problem was. All they wanted was a great minimally viable product they could start introducing to the market.

As I met with more people in the company, alarm bells started to go off. I didn’t meet the VP of Product, and it felt like people wanted to shut them out. Any mention of the VP of Product was met with a silent tension. When I met with the technical team, they seemed depressed and were checked out. They sauntered into the meeting with me, and most of them were late. The product owner was the last to arrive, and while she was pleasant and polite, she spent most of her time with her face buried in their smartphone. The lead engineer on the project took me through an abbreviated walkthrough of their prototype, and aside from some UX and design issues and some unfinished parts here and there, it looked solid. In fact, the fit with the market was obvious, and the technology had a lot of potential. I found it exciting, but the rest of the team were sombre looking and weren’t engaged. I started asking clarifying questions and they slowly started to wake up.

They had stumbled on a very difficult navigation problem, and asked if I had any ideas from my UX experience. I suggested looking at game design, because this sort of problem is well addressed in video games, but often poorly addressed in enterprise applications. After a couple of shocked moments, engagement turned to excitement. We brainstormed, some team members started researching compatible game engines, and looked for examples on the web. At the end of the hour, the team asked if they could extend the meeting further, and most of them were able to stay in the room with me. The frenetic pace of excited brainstorming continued for another 45 minutes, and then we realized we were all tired. The lead engineer wrapped up the meeting, and the product owner took me aside and told me it had been the best meeting they had ever had for that product. In fact, in the two years she had been in the company, it was the best technical meeting she had attended.

Next up was a meeting with the VP of Product. They had been in the industry since the early 1990s, and had seen a lot of past success. You can guess what happened next.

The VP of Product spent the first 15 minutes of the meeting name dropping and telling me all about their accomplishments. When they asked me a question, they interrupted before I could finish answering and began to berate me. This continued on for the remainder of the meeting – any time I spoke I was interrupted and ridiculed. When I changed tack and asked for a demo of their ideas, they showed me a PowerPoint slide deck with an outdated theme, and the product screen examples they had created looked straight out of the 1990s. With a bit of probing I found that they didn’t just treat me with derision and aggression, they were that way with just about everyone. It was obvious that a dinosaur was derailing an important product effort and potential new revenue stream.

I advised the executives of what the problem was, and you guessed it, they already knew. Instead of dealing with the issue, they were trying everything else but having a difficult conversation with the VP. The VP still had a lot to offer the company, but not in product management. They had hoped that a consultant would have some sort of magical solution idea that would get them off the hook, and would somehow get the VP on board.

In two other recent experiences, I have met inexperienced dinosaurs. Both were startup CEOs who had product ideas, and managed to attract friends and family investment to hire technical teams. They didn’t have product managers, and had decided they were going to play that role in their company to save money. They had immediately latched onto the first technology ideas that were presented to them, and refused to learn anything else. Unfortunately, in both cases, they had outsourced development to teams that were inexperienced and placated customers, and made complex, risky development efforts sound simple, quick to implement and inexpensive. Both of them approached me because they had spent a lot of money on solutions that didn’t make it to market.

They were afraid. Yet, in the face of losing their businesses, they refused to listen to contrary advice from people with experience and track records of shipping software. They clung onto their initial ideas and conclusions they had made a year or two ago, and refused to budge. This was likely a controlling dysfunction borne of easy wealth and the arrogance that can come with it. They were intimidated by people who understood technical things, even though they had hired those people precisely because they had technical expertise.

The dinosaur product manager:

  • Believes in “one true way” approaches to marketing, sales, products and process. (This tends to coincide with their way.)
  • Scoffs at new technology or pricing models
  • Scoffs at design trends
  • Makes fun of consumers who buy products or services they consider to be fads
  • Talks more about “the old days” than being productive in the present
  • Dismisses ideas that aren’t their own
  • Makes fun of new technology environments
  • Equates every new design, marketing or technology paradigm with one from the past
  • Blocks efforts to update technology or architecture, even when when it’s needed
  • Underestimate the risks, complexities and efforts of their solution ideas
  • Reacts strongly to people with more technical knowledge, and especially more recent knowledge and skills than they have. They may be antagonistic, belligerent, use ad hominem attacks, or they may be passive aggressive and simply undermine them.

How do you deal with a dinosaur?

One of the most difficult things when dealing with experienced dinosaurs is that they are often right about a lot of things. They often express their ideas poorly, so it is easy to dismiss everything they say. Sometimes what seems like scoffing and denigrating behavior is simply an attitude problem borne out of harsh experience. The trick is to figure out when they are blustering due to fear, obstinance or unwillingness to change or if they are complaining about a valid issue. This requires patience and trial and error.

  • Talk to the person, and ask them what is going on, and point out how their behavior can be damaging and misconstrued if it is well-intended. Ask them to work with you and help the team move towards something successful, even if it means compromising.
  • Training and knowledge gaps are common, particularly with more experienced people. See if you can set up training or online materials to help them get confidence in something new and threatening.
  • Set up a safe place for ranting and complaining about new models, even if they seem to be consumer or process fads.
  • Play to their strengths and experience, and divide labor so that they have input and crucial parts to play in direction, but others are in charge of revenue models, marketing schemes, technology and look & feel.
  • Have them do competitor analysis, and have them perform user experience heuristic evaluations and pricing research of competing products.
  • Make sure they engage with customers who have differing views from their views and preferences
  • Take technology, design and other decisions out of the conversation, and have them provide constructive feedback in a neutral way. Their concerns may be valid, and if so, they will be happy to abstract them and present them differently. If they are not valid, they probably won’t do anything but bluster.
  • Let them win at times. A lost battle on a non-core issue is better than losing the war.
  • Be consistent and patient. It can take a while for them to win respect of other people with new and different ideas, and to get on board with new ideas and approaches.

If the person is coming from a place of fear, most of the above points won’t really help. In that case it will likely require some repositioning of their work and power. Following a process that uses team-based decisions and approaches can really help in this case. In many of these situations, a hardline approach is necessary, because a team member who obstructs can kill productivity and hijack business initiatives of the entire company.

Ask the champion of the new approach to present their approach to the group.

Next, hear out any criticisms of the approach, because there may be valid points. A dissenting opinion presented constructively is incredibly valuable.

Then make it clear, once the decision has been made, that the decision must be supported by the team, and anyone undermining the position will be asked to leave the team. (Also make it clear that undermining behavior will be monitored and will not be tolerated.) Often people who appear to be on board with the decision will undermine by amplifying problems and use that as evidence to criticize the decision. Peter Block calls this “resistance through compliance” and it is insidious and dangerous in organizations.

Here are two dinosaur examples with different outcomes.

An organization had grown from a two-person startup to a thriving company with close to 100 employees. They had created an MVP, tested it in the market and attracted a lot of initial investment. Trouble was, the market changed drastically and suddenly. The product manager became a dinosaur, slavishly sticking to their initial idea. Their product concept and understanding of the market had worked for over a decade, but they couldn’t get on board with the new market reality. There were also a lot of retirements and younger people moving in to replace their existing customers. That meant that during purchasing decisions, younger people (who use a lot of apps on smartphones and are more fashion conscious) were brought in to provide opinions. A middle aged CTO might have a social media marketing person sitting in meetings analyzing the offering from their perspective. Their expectations were much different, but were taken very seriously.

The dinosaur product manager became more entrenched and combative, and taking any criticism (real or imagined) quite badly and personally. They became more isolated, and the rest of the team were realizing they needed some big changes. The dinosaur also hated any usability issues and was quite scoffing of UX practices. “Our customers don’t need something that is usable…” was often their response.

One Monday morning, the product manager came into work a changed man. We didn’t know it at the time, but the CEO, the CTO and a major investor/advisor had taken him out to dinner that Friday night. They asked if he wanted to continue being obstructionist, or if he wanted to work with everyone else to solve the problem? After all, the company and a lot of investor dollars were at stake, and his behavior wasn’t going to help the team. They had decided early on that the core members of the team would agree unanimously on decisions moving forward. To get unanimity meant that if a person was a lone dissenter, they would be asked to leave. The manager told me later on that the discussion hit him really hard, and he spent the weekend mulling over options.

He moved quickly once he made a decision. He immersed himself in new pricing models, spent hours with potential customers doing field research, and hired a UX expert and visual designer to help them create a new product. The results were dramatic. They turned around a failing product into a big seller, and they sold the company to a larger player in the industry for a tidy sum.

In another situation at a large, established company, a dinosaur product manager was stuck in her ways when it came to marketing and sales. That was one thing, but she also refused to allow the technical team to pay off technical debt through refactoring, and would rarely allow them to update tools and infrastructure. She was also, bafflingly, incredibly stubborn about the look and feel of their e-commerce site. It was six years old and really showing its age. Any UX improvement or change, no matter how small, was met with enormous resistance.

This was flat organization with an open environment, and anyone could suggest ideas for improvements or new revenue streams, and field reports were frequent. No matter what anyone said, she would argue against anything she saw as a threat. She would often literally frighten away younger employees who had good ideas based on observations.

Senior managers tried to work around her, then ordered her to help implement an add-on feature to help increase sales. She appeared to be enthusiastic when they were around, and made all the right noises, but she was resisting through compliance.

She didn’t understand SaaS style pricing models, and her views of pricing, marketing and sales were hopelessly out of date. The projected numbers were staggering, but every meeting she was involved with was a painful fight. A marketing designer described a particularly painful “pixel by pixel” review meeting of pre-release marketing designs that took hours. Everything seemed to be painful, took way too long, and people asked to leave the project in droves.

Since the team was moving one way with executive directives, and that didn’t suit her outdated ideas, she actually hijacked efforts to secretly develop the solution the way she wanted. Part of the team at any given time were also working on her competing ideas. We found out because there was an anonymous tip about this from an abused employee to a politically powerful person. Her revenue model was so outdated and wrong, the legal department got involved and sent out a cease and desist warning internally. She continued in her undermining and obstructionist behavior, so she was let go. After she was gone, the teams moved quickly, and after 9 months of fighting, implemented the new feature with a completely new redesign in 3 months.

Avoid Dinosaur Behavior

It’s easy to fall behind in a massive industry that is constantly changing. It will happen to all of us eventually. The important thing to remember is that no one knows it all, and it’s ok to say: “I don’t know.” Very few people will look down on you for not knowing something, and if they do, they aren’t worth paying attention to anyway. Here are some tips:

  • Stay current by reading industry news, a little bit each day
  • Talk to your customers and ask them about problems that haven’t been solved yet, and about other applications they like to use
  • Study User Experience and keep abreast of developments in that field
  • Aim to be a lifelong learner
  • Take online training courses. There are a lot of free and inexpensive courses out there that allow you to work at your own pace
  • Attend conferences, workshops and local events in your community
  • Delegate to people who are more current than you are
  • Check your attitude – are you resisting change, or is your discomfort due to a deeper, important issue that needs to be addressed?

Any new revenue generating, marketing, design or technical change will involve problems and stumbling blocks. There will be fear of the unknown, resistance to change, and there should also be healthy dissent. In fact, any decision without some healthy dissent will likely be a poor one. The trick is to not let the dinosaurs hijack decisions or turn teams away from new initiatives just because they stopped learning and don’t want to help anymore.

When Product Management Goes Wrong – Part 1 – the Underminer

In part 1 of this series, we will look at the undermining product manager. The underminer is a manager who says one thing to your face, and does the opposite behind your back. Underminers may also sow seeds of doubt about your competence to others on the team.


Disney’s “The Incredibles” image from Wikipedia.

When product management goes well, it has a big impact on the success of a project. Product managers help get alignment between technical teams, business teams, and end users. They can help teams deliver a polished product/service instead of a “bucket of features” that are packaged together at the end of a release. Great product managers can help teams build the right product, at the right time, at the right price.

But poor product management can cause a lot of problems. Instead of having a positive impact, they can detract. When product managers persist with unhealthy behavior, they can derail projects, demoralize team members and destroy productivity.

Recently, a colleague approached me because they were having misgivings about a new product manager that had joined the team. The team saw the value in the role, and had hired their first product manager. After the initial adjustment of adding a new team member, they were expecting some positive outcomes, but instead, technical leadership were very concerned. They asked me if the behavior they were seeing was normal for a product manager. What they described might be normal, but it was certainly dysfunctional. I was reminded of an article I wrote a few years ago on management anti-patterns so I decided to revisit that content but with a product management slant.

An underminer is someone who says one thing to your face, but does something else (often the opposite) when you aren’t around. Underminers might be motivated by their own agenda and wish to circumvent current plans and work items. If they want something else worked on other than the current work items, they will go from person to person until they find someone who will agree with them. People will often quietly work on items that aren’t being accounted for at the request of an undermining product manager, which skews team efforts.

The undermining product manager:

  • Doesn’t respect estimates and timelines
  • Doesn’t respect team decisions, particularly with regards to product direction, milestones and priorities
  • Gossips about team members when they aren’t around
  • Second guesses decisions behind other team member’s backs
  • Goes from team member to team member until they find the answer they want
  • Agrees with you or the group, then does something contrary to the shared decision when they think no one is looking
  • Constantly blames other people, other groups (and you when you aren’t around) for any fault, real or imagined
  • Seeks out allies to work on items secretly, and to also engage in all of the above behavior

Underminers are destructive because they ruin productivity, create distrust among team members, and weaken the credibility of the people they disagree with.

In a product management role, they are especially destructive because they ruin team alignment and shared goals, which is an important aspect of team success. Sure, once in a while you have to make an unpopular decision or work with some people in private to get things done, but that work still needs to be transparent and working towards shipping the product. In fact, many times a product manager makes an unpopular decision because it helps with goal alignment and ensures the team stays on track. An underminer doesn’t share the goal of shipping software in the manner the team has agreed to do already. The resulting toxicity caused by an underminer also kills individuals’ intrinsic motivation to work on a project, which is a primary driver for our work.

Underminers are motivated in different ways. Sometimes product managers are directed by powerful stakeholders who feel they aren’t getting their way, and that the technical team aren’t listening to them. Instead of dealing with this head on, they prefer to have a plant or someone on the inside who is doing their bidding secretly. In other situations, a product manager may read (or misread) the political tensions in an organization and feels that if they show some initiative and push the team in a different direction, that will lead to their own success and a promotion or similar reward. Still others are in a position that is beyond their expertise, and they are desperately trying to find some control, or deflect their lack of skill by putting focus on others.

Underminers are horribly toxic for teams (and companies) because they are good at marketing themselves to powerful people in the organization, and are quick to take credit when something goes well. Once they have built up enough credibility, they also shift blame onto other team members who can become vulnerable politically through no fault of their own. This means that the people with the most power are the last to see through the undermining behavior. By then, the damage has already been done. They also cost the team a lot of extra money and lost productivity in frustration and a lack of alignment. A project will need to draw on more reserves than initially budgeted due to their behavior, and many won’t survive.

How do you deal with an underminer?

  • Make your process and decisions visible to all stakeholders. When something subversive is going on, it should be obvious.
  • Utilize project management tools for visibility on individual’s work. Daily standup formats are good for this. If people are working on something other than what they have agreed to work on, it should be visible quickly.
  • Ensure team members approach the rest of the team if someone asks them to do something off the record to get their approval.
  • Make people accountable for not working on what the team has agreed on. Often a little public Q&A is enough to get people to realize what they are doing is inappropriate. If it persists, deal with it as an HR matter.
  • Do not tolerate gossip, blaming or calling people’s work or decisions into question. Foster a culture where people stick up for each other. When undermining starts, it should be obviously different from the norm and discouraged.
  • Bring business and other stakeholders into the process so they feel included, and address their concerns in case they feel the need to subvert. When they do, deal with the issue head on and ask to work on a solution other than someone who will cost the team more money and threaten the success of a project.
  • When you discover an underminer who is unrepentant, fire them when you have enough cause.

The underminer is so deadly, not only will a team miss their shipping targets and go over budget, the team will lose confidence in each other, and the organization. I’ve seen teams start to falter and people start to spend their time looking for a new job after two weeks of an undermining manager appearing on the scene. They are nasty, and it’s important to screen for this sort of thing when hiring.

It’s also important to examine our own work and habits as product managers on a team. While we may not intend to undermine, we may exhibit these behaviors from time to time. It’s a good idea to have personal retrospectives periodically, and when we catch ourselves exhibiting underminer habits to take immediate action to correct them. If we are under stress or feeling frustrated with the progress of the team, we can easily fall into this sort of behavior. All it does is detract, so we need to police ourselves whenever we are tempted.

Designing for Smart Fabrics: Wear It’s At – Part 3

In Part 1 of this series, we looked at defining smart fabrics. In Part 2, we looked at some design ideas. In Part 3 we will explore things that could go wrong with this technology, and offer up two possible futures for products using smartfabric tech.

fashion-300337_640
(image via pixabay)

What are the Potential Drawbacks?

If we can access, visualize and interact with our digital lives with fabric, that brings a whole set of implications to design for (privacy, security, etc.) and the challenges of displaying and interacting with systems.

Imagine the possibilities. We will soon have clothing with:

  • built in displays that can show you information, images and video you would normally see on a PC or smartphone screen.
  • interaction with a system using certain gestures by touching your clothing.
  • powerful, tiny sensors that monitor biological functions.

Pretty cool huh? These technologies are currently being developed, and they could open the door to some fantastic possibilities. They also have a darker side, with potential pitfalls.

The most obvious pitfall is to needlessly annoy the wearer with notifications or prompts to interact with their clothing. Over notifying can over stimulate our senses. If vibration or lighting/color changes are used to get our attention, this might be useful if it is used sparingly. If we get a lot of buzzes against our skin, or our clothing rapidly is changing color or displays or lights are blinking at us too much, smartfabrics products could make people sick.

Accidental interactions can cause unintended results. What if I can control my TV shows with my jeans by gesturing on the fabric, but every time I change positions in my chair, I change the channel? Controlling inputs, determining touch targets and gestures, as well as what to display, and how to notify people of events are difficult to implement well on something that is constantly touching your skin. Over-notify and people will want to destroy their clothing, tickle people and they will go crazy.

Target areas for inputs and outputs are important to consider in clothing design. Inputs and outputs need to be placed very carefully on the body. They could draw unwanted attention to a particular area of the wearer’s body. Even if they aren’t highlighting private parts, they may trigger body image issues if it highlights a perceived flaw in the wearer. It’s also easy to imagine accidental or even purposeful unwanted touching – someone could use the input as an excuse to touch you. If the design encourages interaction, it could be easy for someone to be compelled to touch you when they normally wouldn’t. Inadvertently encouraging unwanted touching in our designs could have very serious implications. Unwanted touching is assault.

On the other hand, in private, intimate environments, that sort of touching can be welcome and fun. Context, as always, is key to understanding interactions with things you can wear.

Beyond unwanted touching, pranksters or “griefers” might think it is funny to reach over and mess with your digital interaction by touching the smartfabric device while you wear it. This could cause your data to become corrupted or trigger unwanted events in a system. (What if you were trying to book a calendar event, your friend reaches over and taps their fingers on your shirtsleeve, and now you have a thousand calendar events?)

We live in public, and smartfabrics might accidentally display personal information that we wouldn’t want others to see. What if a private text or email is displayed to my coworkers in a meeting because it is displayed on my shirt? (You might not want that nude selfie your significant other texts you to be displayed on your suit jacket when you are in a job interview.) What if I work in HR and my boss sends sensitive salary information that is displayed to an entire department I am presenting to? It could also be inappropriate for your dress shirt to display your photostream in church, or if your sombre outfit suddenly played the Benny Hill theme during a funeral. Understanding context and appropriateness of what to display and when, and how much control over who might see it users have is vital to understand and take into account.

Security and privacy is a huge issue with smartfabric devices. Data that is gathered from a user wearing smartfabrics is deeply personal. Any information that is passed to other devices or systems absolutely must be secure. That data should never be intercepted and stolen, it is very personal and could be misused and cause great harm to the user. If data transmitted from clothing or other devices could be intercepted by a 3rd party, that could be very embarrassing and potentially damaging if it is used against them. Also, if servers or cloud-based storage facilities are compromised and smartfabric generated user data is stolen, that could be catastrophic to the people whose data has been collected. The inevitable public backlash could be severe enough to destroy a company. Furthermore, data privacy laws could be broken and an organization could be faced with fines, lawsuits and the resulting bad publicity. Everyone loses if the data generated and used by these devices isn’t kept private and secure.

Private information should not be displayed publicly on my smartfabric device unless I want it to be displayed that way. I need to control what is shown, and when with speed and ease. Other people should not see my current status of what is going on with me and my body unless I want them to.

Smartfabric devices need to have their capabilities completely under the control of the wearer. When a feature isn’t appropriate in a particular context, or if something odd happens, the wearer need to be able to turn it off or mute it. Even active smartfabrics that change their form depending on outside triggers require user control to be able to turn it off.

Under controlled conditions (such as the development lab) you may never see irritating behavior, but in the real world strange things can happen. If your dress changes color depending on light and you are at a dance club, the lighting could cause the dress to rapidly change color. That requires a lot of energy if it happens over and over, so the power source could overheat and cause physical trauma (ie. burning) to the wearer. At best, it might wear your battery down prematurely.

Compatibility with other devices and services will also be difficult to address. What if my smartfabric jeans will only work with Android devices, and I only use Apple devices? What if the clothing that looks good on me and fits my budget is incompatible with my file hosting services I use and depend on? What happens if the smartfabric device manufacturer changes alliances, and my favorite suit company now only supports a platform I hate using?

Reliability is another issue that is difficult with clothing because we have to clean it constantly. How do we create hardware that can survive different weather, food and drink spills, sweat and other bodily fluids, and constant washing and drying? Clothing takes an absolute beating, and we subject it to extremes when we wear it, and especially when we clean it. This is an incredibly difficult environment for electronics to survive in, let alone work reliably in.

Two Possible Futures

The Scary Future

If we design smartfabric experiences poorly, we will distract people from their real world experiences, causing them to live diminished experiences when they wear these products. Instead of using technology to enhance their lives, we could burden them even more than our always connected experiences do already. Also, having more devices reading more and more sensitive and private information creates the potential to track people and make decisions about them based on their movements and biological data. This has incredibly serious, far-reaching implications. If people or organizations use this technology to reward or punish people due to the data that is collected, we could literally have a dystopian future on our hands.

If we aren’t careful, we might just create smartfabric products that are expensive, unreliable, irritating and in some cases, downright dangerous. That will be the kiss of death for the technology. If the solutions aren’t designed with empathy for real people, using them in the real world, not to mention our user’s needs, bodies and state of mind, they will quickly be relegated to the dustbin of history. The good that we could do with this technology would be lost because we did a terrible job with the user experience when we introduced our products to market.

The Awesome Future

Back when I wrote programs to help people on software teams be more productive, we used to joke that we were giving them super powers. They could now get visibility and control within systems that was formerly hidden from them, and use that information to make better decisions, or to diagnose and solve difficult problems. Similarly, even though we have many senses and powerful observation skills, there is a lot about ourselves and our environments that we can’t see. Sometimes this information can be incredibly important to get insight into.

I was delighted when Shannon Hoover (MakeFashion) suggested a similar superpower design theme with smartfabrics. Shannon goes beyond the concept of visibility and control, and he believes smartfabrics will eventually provide us with different superpowers by extending our senses, or replacing those that are injured or defective. Shannon says smartfabrics can help provide “X-Ray vision” by reading and presenting certain kinds of important data that are invisible to us. Just like a radio interprets radio waves and brings sound into a living room, smartfabrics have the potential to show us our current location and alert us where to move if we are travelling and get off track.

There are also applications to help provide us more strength and stability, and while we don’t all have access to a SciFi robotic exoskeleton (at least not yet), they are being developed for commercial and health related applications. Shannon goes further pointing out “spidey sense” activities to sense hidden danger, or important events. If the smartfabric is alerted to something that is important for you to know, it can get your attention to warn you immediately. Smartfabrics can use haptic feedback by interacting with your sense of touch in various ways to get your attention quickly.

Smartfabrics that sense danger and warn the wearer can be incredibly powerful. In particular, if our own senses are impaired due to illness, clothing that can warn us when our bodies are unable to can be life changing. Orpyx have created a vest that notifies people who can’t feel their extremities properly. Diabetic neuropathy sufferers can be warned of too much pressure in their feet by using sensors to vibrate against the wearer’s back to warn them. If your feet are getting injured, but you don’t feel pain, you can cause irreparable damage. Augmenting your body with another system to help prevent damage is an amazing feature to improve the life of people with illness and physical conditions. This also has enormous implications for safety gear and clothing for workers.

Once the wearer gets used to the alternative, haptic feedback, it feels as natural as the normal pain signals your body generates that you no longer feel from damaged areas. The technical term for this is “neuroplasticity”. Smartfabrics have the potential to use this as an “extra sense” to seamlessly interact with us in our environments. Shannon sees a future of products that can provide extra senses even for healthy users, to alert them or aid them as they perform tasks in the world so they are safer, happier and more productive.

Smartfabrics also have more whimsical applications that are also important. Imagine that you are at a holiday party in your new dress, shoes and accessories to match. You’re feeling good about yourself until you spot your nemesis from accounting. “That #$%#! She is wearing the same outfit! Disaster!

What do you do?

Smartfabrics to the rescue! You quickly dart out to the powder room, and with a quick, discrete gesture, you change the color of your dress. Crisis averted! This might seem silly compared to important medical or other applications, but this kind of technology would be incredibly useful for our quality of life.

Conclusion

Enhancing our bodies and our life activities with smartfabrics has the potential to enhance our senses, extend our physical capabilities and greatly inform our knowledge and insight. The choice for what future we want to bring to our users is in our hands. Do we want to enhance the lives of people who will use our products, or do we want to needlessly distract them away from what they should be experiencing?

Once smartfabric technology is reliable and inexpensive enough, we designers have some important work to do and not much time to do it in. Therefore, we need to choose what future we would like our customers to have even before we start designing.

Designing for Smart Fabrics: Wear It’s At – Part 2

In Part 1 of this series, we looked at defining smart fabrics. In Part 2, we will look at designing for them.

sewing-machine-925458_640
(image via pixabay)

Deciding What to Design

Work with a Clothing Designer (someone who works with fabrics)

I can’t stress enough how important it is to work with someone who understands making clothing, and other handicrafts out of fabric and textiles. I spoke with Jen Kot, a professional engineer who makes her own clothing, knits and creates all kinds of interesting objects with textiles. As a technical person, she understands how the underlying technology works. As a crafty person, she deeply understands the application and costs of different textiles, the pros and cons of using different materials, what is easier or more difficult to work with, and what looks good.

Clothing is one of the most powerful tools we have to create and reinforce our image, or how we want the world to perceive us. One of Jen’s criticisms of much of the current wearables such as bracelets, watches and glasses are that they look “nerdy.” To a techie, we might not find this to be important. We may overlook the form for the features, and even find something awkward looking to be appealing. When you are competing in a world where fashion dictates what is available for us to wear in stores, we need to
understand how other people want to be perceived
.

When Jen and I brainstormed uses for smartfabrics, my solution ideas were much more functional. Her ideas were much more whimsical and fun. I kept thinking about how the technology could be applied and impact our lives, while she thought about what would look appealing as well as be engaging and fun.

Shannon Hoover, co-founder of MakeFashion, an organization that brings technologists and designers together to collaborate with wearable tech also reinforced this view. He also understands both the visual and technical worlds that are possible with smartfabrics.

Shannon says that many designers and developers are looking at wearables as a suite of tools (detect with sensor, compute data, send it to something else) but he also believes that isn’t very much fun. It seems very engineering-dominated, where we tend to focus on technology first, then apply it to a problem. Instead, Shannon feels we should also look at wearables from an aesthetic perspective (it looks interesting) and as a vehicle for
human expression. This is an artist and fashion-designer focused perspective.

Shannon goes even further, and says that clothing helps people tell the story about who they are – it is a narrative generator. It also gets people talking to you – it gets their attention and evokes emotions. Clothing is a great conversation starter. So what conversations do we want people to have about what we are wearing?

Using fabrics is complex, you need to understand how something looks on a person, how it feels on the skin, what colors are in fashion and how different cuts and shapes look on people. Fashion changes constantly. To make smartfabrics work, we will need both the technical view (here is how we make the technology work) and the fashion designer perspective (here is how we make the product look great and be appealing to wearers.) As a technology designer, talking to people who design clothing and furniture is exciting and helps generate new ideas. I understand the basics of what they are talking about, but their experience and perspective is completely different. When design materials use combinations of different technologies, our solution ideas are much better when we work together with other disciplines and share expertise and different perspectives.

Beyond Clothing

Making clothing is one way to use smartfabrics, but fabrics are used in a lot more things than clothing. For example, Nomex was used in heat shields for the space shuttle, Gore-Tex is used as a tissue replacement in medical procedures, and Kevlar is used to create high performance vehicle components. In fact, IoT developer and bbotx co-founder Geoff Kratz feels that smart fabrics have even more potential in products other than clothing. For example, he sees using smartfabrics in vehicle upholstery could provide alternatives for inputs and displays and other feedback mechanisms for safety purposes. Geoff also sees furniture as another good candidate. Smartfabrics could integrate with entertainment systems to provide an even more immersive experience. Chairs could sync up with other systems and provide you with reminders or safety information. Carpets could have safety lighting that is triggered by darkness or emergency situations. There is enormous potential for these sorts of ideas as well as interactive, connected art applications for homes, and public areas.

Quilter and chemical technologist (and reviewer of this article) Cindy Johnstone shares Geoff’s views. Since she quilts, she immediately thought of applications for blankets. Cindy says that portrait quilts or family quilts are very popular. She says the resolution of the images would be so much better if digital technology could be incorporated. An active smartfabric quilt that could tighten the batting to make it warmer in the winter and relax the fibres for summer use would be useful. People could use one blanket for different seasons, rather than having more than one blanket. Cindy also sees health care applications where adding in technology into blankets used by patients could provide more insight and control into patient care.

Corporate Innovation

As computing and wireless technology “disappears” into real world devices there is enormous potential to solve more interesting problems. We often look to organizations with well-funded R&D (research & development) programs to set the tone for the rest of us. There will be likely be useful, popular smartfabric products developed by some familiar leaders in the tech sector. The space is also ripe for disruption by some new up and coming organizations we haven’t heard of yet. Due to the combination of physical and virtual worlds, investment in these kinds of products will be more expensive than software alone.

One area that organizations are working on developing smartfabric and similar technology for is the health and wellness sector. Calgary-based Orpyx Technologies is a company that provides a wearable sensor platform for healthcare. In one of their products, they use embedded sensors in footwear to help people with diabetic neuropathy. Those with diabetic neuropathy have nerve damage and often don’t feel their limbs as well as other people do. Because they can’t feel when their feet hurt, they can injure them permanently. In severe cases this leads to amputation. Orpyx have developed a system to warn patients before this happens. A sensor-embedded insert worn inside a patient’s shoe gathers info from the sensors (pressure, etc) and transmits it to a smartwatch which then alerts them to potential problems.

Stephanie Zakala, Marketing and Inside Sales Manager at Orpyx says that they have been watching smartfabrics closely as a next step for some of their solutions. For example, rather than using embedded sensors within shoe inserts, a smartfabric sock would be a fantastic solution. So far though, there are technical limitations with the smartfabrics they have looked at. It is difficult to make socks with sensing capabilities that are comfortable, washable, and reliable over time. Stephanie says that clothing is particularly challenging because it creates hostile environments for electronics. Shoes and under garments are worn in conditions with pressure, high heat and humidity. Also, the high cost of many smartfabrics is currently prohibitive for many mass market consumer applications.

Other organizations are using sensors embedded in clothing to measure heart rate, temperature and other vital signs for healthcare, and athletics.

As smartfabric reliability improves and prices go down, many organizations will find them to be a great alternative technology for some of their current solutions. Beyond that, they will create new products and services by using smartfabrics to solve problems we were unable to address without this technology.

Innovation from Maker Communities

Great ideas don’t just come from companies, they can come from crowdsourcing as well. Craft communities are important crowdsourcing resources where people share interesting ideas for clothing and crafts. In these communities good ideas rise up to prominence because they work and are easy to replicate. Currently, there are knitting and quilting clubs, fashion collectives and maker fairs sprouting up all over, where people support each other socially, teach each other new skills, and most importantly, share patterns and design ideas so that others can make the same item.

As people try different patterns that others have created, they put their own unique spin on things, and improve on the original ideas. With such a large community, many ideas are shared and tested at large scale; far outstripping the resources of most companies R&D budgets and timelines might allow. Failure isn’t tied to profits and loss, so people can experiment without fear, and the best ideas tend to win out by becoming popular and emulated more frequently.

Homebrewing was a hugely vital part of early Personal Computer (PC) development, and this spirit of creativity and doing it yourself is evident virtually in craft communities. Adding technology to traditional materials is a natural step. In fact, while researching this piece, I found more people from craft communities that were interested in smartfabrics than technologists.

One community that reminds me of early PC homebrewing and software clubs is Ravelry. Ravelry is a community for people who knit and crochet, and it has a unique blend of features that allow people to share ideas and patterns. Local real-life knitting clubs have been started as a result of people from the same geographic location meeting virtually on Ravelry, then getting together and helping each other out. Sharing patterns and pictures of finished items is a huge part of the Ravelry experience, and popular patterns that help people create things that look good and work start to emerge.

Crowdsourced ideas from maker communities are often more fashion-conscious and whimsical than their corporate counterparts. Sometimes as technologists we forget that having a product that looks good and is fun is just as important to people as a life-saving device. It just depends on context. In fact, products that look good and are fun have a much larger market appeal. Maker communities are an area to watch because they not only filter the ideas for us, they remind us techies that the world can be a fun, colorful place and we need to incorporate those aspects into our designs.

These communities have access to a wealth of knowledge, and as digital designers, we can learn a tremendous amount from them. Once they have experimented with smartfabrics for a period of time, we can benefit from communities of people figuring out what works best for certain applications. These sorts of organizations are filled with people who like to experiment and create things for themselves and their friends. If you’re wondering where to start, Jen Kot says, make what is interesting and useful to you and then share it. The crowd can create at scale, so the good stuff will get copied and become popular.

Frame Your Design Thinking

Solve a Real Problem

When looking at technology first, and then trying to find useful applications of it, we can mistakenly create products that people don’t like. It’s important that technology solutions are actually useful and will be used by real people. Many wearables are not worn after a few months of use. In 2014, Endeavour Partners surveyed people who use wearables and found that one third of activity tracker users stopped using it after six months. Once people get a sense of the data that is measured and how that is reflected in their activities, they don’t seem to find a lot of value in the wearable information anymore.

It is vital to use technology that actually solves problems for people. Author and thinker Simon Sinek talks about “starting with why” we are doing something. In technology, we work a lot with the “what”. We have access to cutting edge technology, and we need to spend a lot of time learning how to master it and apply it. Many wearable and smartfabric demos seem to reflect this. People talk a lot about the technology and how it works, but they fail to make a compelling case for why it’s useful to me in my life and world right now. Very few people care about technical details, they want something that serves a purpose, looks good and fits their budget.

Think of buying a new pair of blue jeans as an example. When I shop, I look for something that solves my problem (I need clothing, specifically a new pair of jeans), that fits my personal style, that I look good wearing, and that I can afford. Invariably, I am drawn to a stylish visual design and a certain level of quality of materials and workmanship. Unfortunately, that means the jeans I would like to consider buying are expensive. Most importantly, the jeans have to fit my body and look and feel good while wearing them. So I start compromising to see if I can find something that fits my budget. If you are a smartfabric designer, how are you going to convince me to pay more money for something that has electronic capabilities in my jeans? It may just feel like an unnecessary extra. You have to convince me, the buyer, why I absolutely need this new technology in my jeans. Will they fit better? Will they look letter? Will they keep me warmer or drier or more comfortable? Will they provide data or notifications that are incredibly handy, or that I just can’t live without once I have them?

Whenever I design something new with complex technology, I strip the problem down to its essence, and I remove digital technology from the solution ideas at first. If I can use paper, pen, materials readily at hand and perhaps some physical services like mail or parcel delivery, what would I do? If you can fully understand the underlying problem you are solving and provide alternate ways of solving it with different technologies, it’s time to add in the digital technology to form a solution. It’s amazing how your perspective changes, and that pet feature you just loved in the technology doesn’t necessarily translate into an ideal product for the people you are designing for.

An ideal product should be so superior using smartfabrics to other, older technology, the customer will want it and will wonder how they got by without it in the past.

Paul Hanson (bbotx CEO) warns designers for wearables to avoid focusing on technology first, then looking for solutions in people’s lives. Instead, when we design wearables for people, we have to think about the person wearing the device first, what they are doing in their lives and how the technology that the device provides is useful for that person. However, it can’t stop there. Beyond the device itself, the generated data and activities recorded or performed by the wearable are much more useful when you take an entire system (such as your interactions with other people) into account. Gathering a lot of data with a smartfabric wearable and displaying that data on a smartphone has limited usefulness.

What does it mean? What should the wearer do?

With passive wearables, which are usually used to gather data, there is limited value in providing activity data only to the end user. There is infinitely more value if that data can be shared with people who can interpret the data, and have special expertise to help apply that to help you improve your life. In healthcare for example, clothing that monitors heart rate is incredibly useful if care givers or specialists have access to the data to help put context around it and point you towards behaviors that will benefit you. This requires a complex, secure computing system to support not only the wearable and the user, but everyone else who needs to be involved.

Active wearables need to interact with a system too – the immediate real world around us. Imagine a winter jacket that changes form depending on temperature so you are always at optimal comfort, or a shirt that changes color depending on lighting. The data the wearable interprets around them can trigger change in the form or attributes to enhance the experience of the wearer. Ideally, the user should be able to control these changes themselves if they want to override them.

Interfaces and Inputs

In my last article on wearables, I suggested that the real world is your primary user interface. With smartfabrics that can be used as clothing, user interfaces can also be on people’s bodies. Not only do you need to understand where the user is, what they are doing and what the environmental conditions are, you also have to understand where on the user’s body the user interfaces and inputs will take place.

Finally, you have to understand the inputs and outputs and displays themselves. This is incredibly challenging.

On a PC, we are used to input methods (keyboards, pointers, stylus, microphones, fingers, etc.) and output on a screen, from speakers etc. The end user tends to use the PC in more ideal conditions, and we don’t think too much about what else is going on around them. Mobile devices complicate I/O matters, because now we have to think about limited actions, and what else is going on in their world as they use our programs on the move.

Wearables such as smartwatches and activity trackers complicate this further, since they can overly distract from our real world activities, and since we are wearing them on our wrists or clipped on to clothing, we can’t get away from them if they needlessly over stimulate us with notifications and alerts. With smartfabrics used in clothing or furniture, the devices are right up against our skin and have much more opportunity to distract and annoy us. Can you imagine how terrible an experience could be if your clothing was vibrating or lighting up and you couldn’t stop it? It could be embarrassing, irritating, and could even cause injury to the wearer.

Deciding where to provide inputs and outputs on smartfabric is incredibly important for a design. With furniture or objects we interact with, it can be more straight forward, but would still require a lot of user testing with different users to get right. For clothing, it gets much more complicated. What are sensitive areas of the body we would want to avoid for inputs? How about appropriate areas for screens or lights or other outputs? If outputs or inputs they draw attention to private parts of the body, that could be disastrous in public, or just the right thing in private. We do not want to expose our customers to unwanted attention or touching, and they need to be in control of their own bodies and what technology can do to enhance them.

Smartfabric designers need to think of inputs and outputs for smartfabrics:

  1. What is around users in the real world and what activities will be enhanced by the technology
  2. The human body – where and what is useful with regards to inputs and outputs what is and feasible to put on or around our bodies and appropriate given the context of use
  3. The inputs and interface designs themselves

Design for Simple Interactions

On mobile devices, we have learned that we can distract people needlessly and take away from their real-life experiences rather than enhance them. If an app is annoying, people just delete it and move on. As designers, we must understand the context of use, such as the environment around users, and what they want to do at a particular time with the technology. We also know that people have less time and space to interact with mobile devices than they do with larger screens, so we have to develop for quick, economic interactions rather than a long workflow. For example, if I am walking outside with my smartphone, it is much harder to interact with than when I am sitting comfortably at a desk typing on my PC. If I am in a hurry, or I am in bad weather, it is even more difficult.

Now think of clothing you are wearing that is designed with smartfabrics. They are even more difficult to interact with than a small smartphone. What is going on around us and our limited ability to see and interact as we move around are amplified with smartfabrics. Imagine how irritating it would be to not be able to control or turn off notifications on your clothing, or how dangerous it might be if the smartfabric distracts you when you are walking, driving or riding a bicycle. The simple interactions mantra that mobile designers repeat over and over is that much more important to take into account with smartfabrics.

MakeFashion co-founder and UX designer Chelsea Klukas says: “…the most successful mobile products have created experiences that quickly allow customers to continue a task after interruption. With wearables these interactions will become even briefer, and successful experiences will need to be quick with minimal interruption to the user. Interfaces will need to be designed to rely on simple one-tap inputs and voice commands that can be achieved instantly.”

With wearables, the real world should be your primary user interface because that is what holds the most attention for the wearer, not the technology. Wearable technology should be designed to work within that context to complement real-life experiences. Chelsea says: “As wearables gain widespread adoption, we are going to have to be increasingly sensitive to the amount of interruptions and distractions they cause. When used correctly, wearables can be incredibly useful in providing information, wayfinding, or accessibility. When used incorrectly, they can become distracting and provide interruptions to user’s tasks and routines.”

Wayfinding came up a lot when I talked to people about possible applications of smartfabrics. Shannon Hoover suggested that smartfabric clothing that could sync with a map service would be hugely beneficial for tourists and travellers. If clothing provided tactile indications (such as through the use of a vibration motor) and subtle visuals, finding your way in an unfamiliar place could be much more enjoyable than having your face in a smartphone or an old fashioned map. You could focus on your surroundings, and have a richer experience, without worrying about going off your planned route. The clothing would remind and guide you. This could also be safer, you wouldn’t be a target as an obvious tourist to pickpockets or scammers.

Others described ideas using smartfabrics for people operating a vehicle. This technology would not be as visually distracting as looking at a smartphone or GPS map. Motorcyclists and bicycle commuters in particular found this a welcome change. Instead of relying on a hand held or mounted device that would distract their visual attention away from where the vehicle was heading, they could get tactile indications of where to go.

Smartfabrics could provide the ultimate handy interface for quick reference, reminders and interactions on the go, or they could interrupt needlessly and distract away from our real world experiences. Furthermore, since the human body is a secondary user interface, there is really very little difference between touching fabric on your body and touching bare skin. Imagine rubbing your thigh in one spot 100 times a day. How do you think your leg would feel in an hour, in a day, or after a week?

Simplicity is not only necessary for a good user experience, it could be necessary for our health, well being, and our relationships.

In Part 3 we will look at things that could go wrong with this technology, and offer up two possible futures for products using smartfabric tech.

Designing for Smart Fabrics: Wear It’s At – Part 1

Lately, the term “wearables” appears more and more in our conversations. Usually we are describing a smart watch that extends our mobile experience, or a bracelet that tracks physical activity. Sure, those are things we wear, but what about something with computing power that we actually put on as clothing? Now that is something that is really a wearable. This next wave of wearable moves technology beyond accessories to clothing we wear, furniture we use, vehicles we are transported in and art that we enjoy.

This is made possible through smartfabrics. Smartfabrics are textiles with embedded electronics that bring computing power even further from our devices into everyday items. This technology poses new challenges for designers. Not only is the form factor very different from screen devices, it is right up against the user’s skin.

needle-672396_640
(image via pixabay)

This is an interesting topic for me. While I have done design work with smartwatches, wearable integration and for Internet of Things (IoT) devices, I haven’t worked with smartfabrics yet. So I reached out to people in the community who have more insight than I do, and asked for their thoughts to share on the future of this technology. This is more of a forward-looking piece than my usual experience-reports, so I will likely get some of it wrong. However, a lot of you have been asking me to weigh on on this topic. Furthermore, the low impact, high value principles behind designing for this technology are important to take into account as we move forward. We might have a limited window of opportunity to get it right.

In my last article on wearables Designing For Smartwatches And Wearables To Enhance Real-Life Experience, I wrote about designing experiences that integrate smartwatches and activity trackers. I mentioned that we have two futures for technology: in one, we are distracted away from our real-world experiences, increasingly focused on technology and missing out on what is going on around us; in the other, technology enhances our life experiences by providing a needed boost at just the right time. Understanding good distractions as well as unwelcome distractions is vital to consider when you are designing for something that you will have right up against your skin for hours at a time on a daily basis. With smartfabrics, we have even more potential to cause harm by distracting people from their lives, or to bring even more good by using powerful technology to enhance our real-life experiences.

As I spoke with people who design with smartfabrics and similar technology, a common theme emerged: smartfabrics aren’t quite there yet for mass market applications. There are some niche players leading the way, but nothing has captured significant mind share. That’s because it’s difficult to bring computing and electronics, power sources, sensors and wireless connectivity to fabrics without making them bulky, impractical, and expensive. However, a lot of great organizations with brilliant people are working hard to create reliable, cost-effective smartfabric technology, so the day will arrive soon. When it does, those of us who are technology designers will be designing digital experiences that are completely different from the screen experiences we are accustomed to. It’s important to understand that we are designing a digital experience that supplements a user’s real-world experience.

Know Your Design Material

Electronics

One way to think about smartfabrics is that they are Internet of Things (IoT) devices. In his talk Magical UX and the Internet of Things , mobile UX expert Josh Clark defined IoT devices as “Sensors + Smarts + Connectivity”. A “thing” is anything at all that we can put technology into. “Sensors” are what make mobile devices and wearables truly special, they can sense movement, direction, and in some cases even biometric data.

“Smarts” refers to computing power and electronics that makes sense of data, and supports inputs and outputs into the system.

“Connectivity” allows us to get information from the thing onto smartphones
and other devices. It is one thing to have a wearable that measures or allows for inputs and outputs, but if it can only work by itself and not communicate with other computers, it has limited value.

Sensors, smarts and connectivity depend on power sources to operate, which means they need batteries to make them work.

Smartfabrics are textiles with IoT-style technology woven into them. Some technologies added to textiles are sensors, wireless, batteries, location services (such as geo-positioning tech), transducers, bio monitors, lighting and displays. New kinds of fabrics blur lines further with electronics in the development of conductive thread for inputs, and stretchy displays, circuit boards and wiring embedded right into the fibers or printed on the fabric. In some cases you can barely tell the difference between smart fabrics and traditional textiles.

IoT devices provide visibility and control into just about anything we can stuff technology in. Paul Hanson, CEO of IoT technology company bbotx points out that they “help create enhanced situational awareness.” In other words, IoT devices can help us extend our own capabilities by providing visibility and control into our environments, our interactions with other people and systems, and within ourselves. For example, health monitoring with wearable IoT devices can provide constant flows of data so the wearer can make better health decisions. With IoT technology, this insight is also available to health experts. What was once a sporadic activity – that required an appointment, specialized equipment and expertise – can now be an ongoing, continuous activity. These systems provide a degree of insight into a patient’s day to day conditions that was impossible before. Patients get visibility into their current condition at any time, and experts can closely monitor changes and recommend treatment options.

Doug Hagedorn, CEO of Tactalis describes two different kinds of smartfabrics: passive and active. Passive smartfabrics are designed towards monitoring and gathering information to for use within a system. Active smartfabrics react immediately to stimulus in the environment and may change physical aspects such color, shape or their digital behavior. Passive smartfabrics have enormous potential in areas such as health and fitness, while active smartfabrics could reduce the need for multiple articles of clothing that have one particular purpose and design.

Fabrics & Materials

If you are a digital designer who like me who in virtual worlds all the time, integrating software with real world physical objects can be a challenge.

Textiles are commonplace enough to appear simple, but they are subtly complex. From ancient times, we have used animal and plant-based materials to clothe ourselves for protection and warmth. Eventually, we brought in metals and other minerals as materials. (The most obvious example of this is medieval armor such as chainmail.)

As technology advanced further, we moved beyond natural resources and started making synthetic fabrics. Today, textiles are sophisticated combinations natural, synthetic, mineral and other materials. We take them for granted because they are all around us, and the complexity is hidden from us.

The choice of material when designing clothing or other textile goods brings with it different strengths and weaknesses for warmth or cooling, comfort or sturdiness, and care when dirty.

To get more out of a particular fabric, we combine different materials to make it even more useful for a particular purpose. Some interesting examples of technology fused with technology are:

  • Kevlar used in fabrics for protective wear
  • Gore-Tex Water repellant technology to keep us warm and dry
  • Nomex provides flame resistance
  • Spandex provides support for athletic wear and underwear
  • Conductive thread in our mittens and gloves allows us to use our touchscreens in the cold.

When you weave these powerful fibers into fabric for use in clothing, it allows the wearer to do things that were previously difficult or impossible. In most cases, you wouldn’t even know that complex technology is in your clothing unless you looked at the label. Similarly, as electronics become smaller, they become a part of the purpose of the clothing. They fade into the fabric so that we don’t even notice them. Smartfabrics have the potential to allow us to do much more with clothing and other objects than we can with traditional fabrics. The key as a designer is to know exactly what kind of smart fabric you require to solve a problem for your users.

Stay tuned for Part 2, as we look at smartfabric design potential.

Designing a Gamification Productivity Tool

Gamification and Software Testing

I haven’t spoken about this project publicly because we never got to a public release. Software testing tools represent a tiny market, so they are incredibly difficult to fund. Some of you have asked me about gamification tools with testing, so I thought I would share this brain dump.

A few years ago, I was asked to help a development team that had significant regulatory issues, and frequently accrued testing debt. The product owner’s solution was to periodically have “testing sprints” where other team members helped the over burdened test teams catch up. There was just one problem: the developers HATED helping out with 2 weeks of testing, so I was asked to do what I could to help.

A couple of the senior architects at this company were very interested in Session Tester and asked me why I had put game mechanics in a testing tool. I didn’t really realize at the time I had put game mechanics in, I was just trying to make something useful and engaging for people. So I started talking with them more about game design, and they encouraged me to look into MMOs and co-operative games. The team played games together a great deal, so I learned about the games they enjoyed and tried to incorporate mechanics

I set up a game-influenced process to help structure testing for the developers, and taught them the basics of SBTM. They LOVED it, and started having fun little side contests to try to find bugs in each other’s code. In fact, they were enjoying testing so much, they would complain about having to go back to coding to fix bugs. They didn’t want to do it full time, but a two week testing sprint under a gamified, co-operative model with some structure (and no horrible boring test cases) really did the trick.

Eventually, I worked with some of the team members with a side-project, and the team lead proposed creating a tool to capture what I had implemented. This was actually extremely difficult.  We started with what had been done with Session Tester, and went far beyond that, looking at a full stack testing productivity tool. One of the key aspects of our approach that differed from the traditional ET and scripted testing approaches was the test quest. As I was designing this test tool, I stumbled on Jane McGonigal’s work and found it really inspiring. She was also a big proponent of the quest as a model for getting things done in the real world. Also, we were very careful in how we measured testing progress. Bug counts are easily gamed and have a lot of chance. I have worked in departments that measured on bug counts in the past, and they are depressing if you are working on a mature product while your coworkers are working on a buggy version 1.0.

One thing Cem Kaner taught me was to reward testers based on approach rather than easily counted results, because they can’t control how many bugs there may or may not be in a system. So we set up a system around test quests. Also, many people find pure exploratory testing (ET) too free form and it doesn’t provide a sense of completion the way scripted test case management tools do. And when you are in a regulatory environment, you can’t do ET all the time, and test cases are too onerous and narrow focused. We were doing something else that wasn’t pure ET and it wasn’t traditional scripted testing. It turns out test quest was a perfect repository for everything that we needed to be done. Also, you didn’t finish the quest until you cleaned up data, entered bugs and other things people might find unpleasant after a test session or two. There is more here on quests: Test Quests – Gamification Applied to Software Test Execution

As I point out in that post, Chore Wars is interesting, but it was challenging for sustained testing because of different personalities and motivations of different people. So we used some ideas from ARGs to sprinkle within our process rather than use it as a foundation. Certain gamer types are attracted to things like Chore Wars, but others are turned off by them, so you have to be careful with a productivity tool.

We set up a reward system that reminded people to do a more thorough job. Was there a risk assessment? Were there coverage outlines? Session sheets? How were they filled out? Were they complete? What about bug reports? Were they complete and clear?  I fought with the architects over having a leaderboard, but eventually I relented and we reached a compromise. Superstar testers can dominate a system like this, causing others to feel demoralized and not want to try anymore. We decided to overcome that by looking at chance events, which are a huge part of what makes games fun, so no one could stay and dominate the testing leaderboard, they would get knocked to the bottom randomly and would have to work their way back up. Unfortunately, we ran into regulatory issues with the leaderboard – while we forbade the practice of ranking employees based on the tool, this sort of thing can run afoul of labor laws in some countries, so we were working on alternatives but ran out of resources before we could get it completed.

Social aspects of gaming are a massive part of online games in particular, but board games are more fun with more people too. We set up a communication system similar to a company IRC system we had developed in the past. We also designed a way to ask for help and for senior testers to provide mentoring, and like MMOs, we rewarded people who worked together more than if they worked alone. Like developer tools, we set up flags for review to help get more eyes on a problem.

We also set up a voting system so testers could nominate each other for best bug, or best bug report, best bug video, and encouraged sharing bug stories and technical information with each other within the tool.

An important design aspect was interoperability with other tools, so we designed testing products to be easily exported so they could be incorporated with tools people already use. Rather than try to compete or replace, we wanted to complement what testers were already doing in many organizations, and have an alternative to the tired and outdated test case management systems. However, if you had one of those systems, we wanted to work with it, rather than against it.

Unfortunately, we ran out of resources and weren’t able to get the tool off the ground. It had the basics of Session Tester embedded in it, with improvements and a lot of game approaches mixed in with testing fundamentals.

We learned three lessons with all of this:

  1. Co-operative game play works well for productivity over a sustained period of time, while competitive game play can be initially productive, but over time it can be destructive. Competition is something that has to be developed within a co-operative structure with a lot of care. Many people shut down when others get competitive, and rewarding for things like bugs found, or bugs fixed causes people to game the system, rather than focus on value.
  2. Each team is different, and there are different personalities and player types. You have to design accordingly and make implementations customizable and flexible. If you design too narrowly, the software testing game will no longer be relevant. If design is more flexible and customizable from the beginning, the tool has a much better chance of sustained use, even if the early champions move on to other companies. I’ve had people ask me for simple approaches and get disappointed when I don’t have a pat answer on how to gamify their testing team approach without observing and working with them first. There is no simple approach that fits all.
  3. Designing a good productivity tool is very difficult, and game approaches are much more complex than you might anticipate. There were unintended consequences when using certain approaches, and we really had to take different personality and player styles into account. (There are also labour and other game-related laws to explore.) Thin layer gamification (points, badges, leaderboards) had limited value over time and only appealed to a narrow group of people.

 If some of you are looking at gamification and testing productivity, I hope you find some of these ideas useful. If you are interested in some of the approaches we used, these Gamification Inspiration Cards are a good place to start.

Thoughts on product development, management, design, mobile and other topics.