Category Archives: product management

When Product Management Goes Wrong – Part 6 – Frozen

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 part 5, we discussed the Dread Pirate Roberts. In this post, we will explore the frozen product manager.

I thought I had finished this series with my last post, but I realized there was an obvious omission, so I am adding this post to the series. Originally this post was all about fear, but I realized that wasn’t accurate. Fear is a driver of the frozen product manager, but not the only one.

The frozen product manager delays decisions and derails product development due to their own fears, insecurities, biases, and their reaction to political dynamics.

They miss opportunity windows in the market due to delayed decisions, or not making decisions at all.

The Frozen Product Manager:

  • Procrastinates excessively
  • Doesn’t make product decisions until the last minute, or is forced to.
  • Hijacks strategic work and brainstorming in favour of mundane project tasks and busy work.
  • Allows problems to fester until they become damaging to the product and team.
  • Uses processes, tools and other forms of busy work to redirect and consume productive efforts that would be put towards improving the product and innovating.
  • Attacks and thwarts visionary product or feature planning. To excuse their behaviour, they cite scope management, budget, technology or other limitations.
  • Is resistant of any change, no matter how minor.
  • Claims to be in favour of innovation, yet secretly undermines any efforts to do something new and creative.
  • Refuses to acknowledge the elephant(s) in the room. ie. Ignores obvious problems or issues that require attention.
  • Lashes out at suggestions for improvement, new technology observations or at creative solution ideas. This can be overt or covert.
  • Undermines efforts to improve, innovate or grow the product
  • Also undermines the people who point out and try to solve problems that involve hard work, innovation and difficult decisions. Overtly by arguing and escalating conflict, or covertly through endless arguments and discussions that derail any real progress or decision making.
  • Attacks people who highlight any problems on the project (ie. kills the messenger) and demands that any problem brought forward must be accompanied by a solution.

Fear

Fear is normal for a product manager, but  dysfunction sets in when we have unhealthy reactions to it. When fear prevents you from moving forward with new ideas that will improve the product and the experience of your users, then it is getting in the way.  Fear can cause you to freeze up and stagnate, or it can be channelled into something positive.

No matter how confident you are and well informed you are in your decisions, things can go wrong. Fear can be a good indicator that you are on the right path because you are out of your comfort zone, and you are taking a risk with the product. For example, needing to pivot a marketing campaign due to current events can have some healthy fear:

“Oh no! Is our messaging wrong for the current state of the market, or due to world events?”

That is reasonable fear that the direction you are going is the wrong one, and you fear the results of being perceived to be tone deaf. A healthy and productive way to deal with this fear is to research and check before proceeding, and adapt as needed. An unhealthy reaction is to freeze up and scuttle the new direction altogether. (Unless it is so inappropriate it needs to go.)

You may also have fear about changing direction quickly to adapt. “What will the marketing people think? Will they agree or will they see me as indecisive or over reacting?” Once you set that fear aside, you may also have some fear about whether they have availability to adjust to better suit the product and environment.

Finally, once you have pivoted to better match the current environment, there will be fear about that new campaign and whether it will work or flop.

This is all normal. Most times, when you confront that initial fear and adapt, your product is now placed to reflect the current reality, even if your campaign isn’t perfect. Your competitors who do not adapt are left behind and need to play catch up.

This scenario plays out in various ways in a product, from marketing, feature development, technology choice and others. When a force causes you to worry about what you are doing, and you are able to pivot and adapt, there will be fear. Addressing the fear will help improve your product. Being ruled by the fear will have negative effects. When you are afraid to deal with problems or opportunities, the product and the team will suffer.

Personality and habits

Some of us are conflict averse, others thrive on it. However, too much in one direction or the other can cause frozen outcomes.

Some of us are decisive, while others indecisive. Making decisions too quickly without enough information can put a product on the wrong trajectory, while indecision leads to paralysis.

Some of us are procrastinators, while others get things done efficiently. Sometimes procrastination pays off when a solution arrives due to time researching and thinking, but too much can lead to zero productivity.

It’s important to be aware of what your preferences and habits are, and to counter them when they become an impediment. Each of us has a mix of skills and preferences, and while it can be uncomfortable, it is important to have personal tactics to counter them when they get in our way. Experience will help you learn and grow as a person, and to know when to indulge or reject what is comfortable or habitual.

Biases and stereotypes

Our own biases and negative beliefs can also cause frozen behaviour. A product manager may dislike certain technologies and have deeply held beliefs that are based on hearsay or folklore. I worked with a product manager who hated JavaScript and did everything they could to prevent the technical team from using any JavaScript in their projects. When pressed for reasons, they would just repeat flimsy arguments that they had read online that were often outdated, or bordered on conspiracy theories. When pressed and shown that their negative opinions were unfounded, they would respond with anger, shutting down the debate.

They may stereotype other people and groups, such as marketing being out of touch with technical needs, or the technical team being clueless about user experience. If communication with others
is driven by stereotypes, it will create tension and destroy cross functional collaboration.

Idealistic philosophies

A lot of people love to subscribe to a particular management approach or philosophy. Frozen managers can be impacted by a blind, zealous adherence to one approach that they will stick to no matter what the outcome. Management styles that focus on building consensus and democratic team decisions can be especially susceptible to frozen behavior.

Product decisions are difficult, and it is extremely hard to get consensus between individuals and teams. I have to make decisions that anger one group or another, because the big picture for the product needs to win out.

When I start working with a new team, I tell different groups that at some point during the project, their group will be upset with me. In fact, when it seems I am getting along well with one group, another is likely upset because of a decision I had to make. Sometimes, everyone is mad at me.

When working with a new startup,  I explained this to marketing, sales, business stakeholders and the technical team. For whatever reason, when I was resolving conflict between marketing and the technical team, I tended to side with marketing. The techies were upset, but they were good natured and understood that the decisions helped move the project forward. One day though, the dev manager came to me with a serious problem related to a technical decision. I understood immediately that they needed to change course, but the business stakeholders, marketing and sales, and others were against it. They felt that the tech team were making a capricious decision towards new and shiny tech because they had already settled on a different solution.

We had an emergency meeting, and I sided with the tech team. While it seemed like a distraction, it was necessary due to unforeseen tech limitations that had emerged. It would add an extra couple of weeks to the schedule, but it meant we could actually ship with critical features. The tech team was shocked, and came to talk to me afterwards, thanking me. I reminded them that I had told them that some days they would be angry, other days they would be happy with my decisions. They laughed, and we gained mutual trust.

It isn’t fun to have people and groups be upset with you. However, it is part of the role as a product manager to find a path through competing views on how to move forward. A lot of my work is to step in to help companies when the product manager role is frozen with indecision. Consensus builders struggle when there isn’t a compromise, such as the tech issue described above. You can’t go half way with a tech change mid-project. In that case, the conflict averse product manager will side with the most politically powerful. That might be good for self preservation in an organization, at least in the short term, but it means the product itself will suffer.

The idealism of everyone getting along and building consensus can be a difficult one to maintain, especially when there are time and market pressures. Making a decision and disappointing some for the good of the whole is difficult, but necessary at times.

Politics

Often, there are political forces at play, and a product manager may be pressured by others in the organization who wield influence and power over them in various ways. In some cases, the product manager perceives pressure and undue influence when there is none. Their insecurities get the best of them and they start imagining how other groups would prefer they behave, rather than the obvious and positive value creation activities.

“But our team doesn’t have politics” people say. That is false. When an individual starts a project and transitions from a sole hustler to growing a team, the politics start as soon as you add a second person. The team of two may appear to be in complete agreement, even when there is conflict and decisions are finally agreed to, but add a third person and the rough edges appear immediately.

It is tough and scary to go against the politically powerful. If you can demonstrate the good of the product, and do it with respect and kindness, you will usually win them over. If you don’t, their own ego and insecurities will prevent product success. If they force you out, it was meant to be because you are attached to a losing proposition.

Intimidated by Others

When you’re good at something technical, it requires a lot of effort and a certain amount of special skills. Techies are often elevated by others who lack those skills, and to be honest, it can feel good to be put on a pedestal. It can be easy for our egos to get out of control when people compliment us all the time, and we are known for solving certain kinds of problems better than those around us. The problem with too much of this is that it gets comfortable and we start to let it get to our heads. An unfortunate outcome is to feel superior to others, and then be excessively threatened when someone else comes along who can do some things better than you can.

Technical teams can be full of people who are intimidated by others who have different perspectives, different skills, and different strengths and weaknesses. Often this fear results in mediocre teams full of people who are all the same. (Sadly, tech teams of white males is extremely common in North America at the time of writing this.) Beyond the visible similarities, those with political power often hire people who have the same level or lesser skills than they do. That way they never feel uncomfortable, and are reinforcing their position and ego. Sadly, this fear always results in an inferior product (not to mention the organizational and societal problems that are created and reinforced. Diversity of people, skills, ideas and strengths always results in better products, even though it can be scary when you aren’t the smartest person in the room anymore.

What do you do instead?

  • Try to make a decision, any decision, when you are scared and frozen. A poor decision is much better than no decision.
  • Ignore your biases and stereotypes. Give people and groups the chance to meet or exceed expectations. If you treat them a particular way and expect them to behave in a particular way, they will likely meet those expectations, be they poor or good.
  • Have courage and follow your instincts. You can always fix a poor decision if you are honest and forthright. You can’t fix something you hide from everyone, and you can’t fix being frozen and doing nothing. The market and your customers will move on.
  • Be careful of letting the political environment dictate your product decisions. When the product suffers, the people you are sucking up to politically will lose respect for you, and your credibility will suffer.
  • Get advice from key, trusted people. You can’t know everything, and their perspectives are valuable when informing you. Once in a while, the ideal solution will appear from another source.
  • Build a team of people who are better at you at things. Don’t be intimidated because they excel in areas you are weaker at, be drawn to them and use their expertise and ideas to help the team and product succeed.
  • Research, research, research. Stay on top of market forces, customer needs, technology solutions and current events. If you get stuck in your ways and always do the same thing because it feels safe, you will miss out and your product will suffer.
  • Do the opposite of what feels comfortable. When you are frozen with indecision, look at the source of your feelings. What do you wish was different to make things easier? How would you react if things were ideal? Now, look at how this situation is preventing you from doing what is comfortable, and do the opposite of what feels comfortable. For example, if you always push for consensus no matter how long it takes, but you re unable to get agreement from others, make a snap decision to break the logjam.

Frozen Startup Founders

One of the most common frozen situations I run into is with startups that don’t have an official product manager. The founder tends to play that role in addition to everything else they do. This feels natural because the company exists because they had a great software idea. They were able to identify the need, spin the right narrative about it, sell it to investors and potential customers, and attract and motivate a technical team around them to deliver.

However, they have a lot riding on success or failure of the project. They have huge financial interests and may be so extended financially that they face personal financial ruin if the project fails. There are also reputation and personal dynamics at play as well.

Startup founders fear the failure of their product and their personal ramifications so much that they are extremely motivated to succeed. To investors, this is ideal. They feel that this person is so motivated, they will succeed no matter what. Sadly, this is often a false impression. The fear can paralyze the person when it comes to making decisions about the product that they are uncomfortable with.

Startup founders that get frozen are often gifted at finding a market niche, addressing that with a product idea, raising money and assembling a team. However, those skills are not necessarily transferable to product management. Here is why:

  • They may not be up on the latest market trends or recent changes with regards to technology or preferences of people they aren’t used to dealing with. (eg. older founders refusing to learn about  younger people and social media marketing effectiveness)
  • They may insist on using technology that they are familiar with, but it might be outdated or unsuited to the current environment. (eg. refusing to create a mobile app for their solution because they can access a website on any device.)
  • They may be held hostage by the technical team. It is incredibly hard to attract tech talent to startups. Startups are risky and don’t pay very much, so it is tempting to make sacrifices to provide them with alternatives. They may grant people with senior titles and roles they don’t have the experience for. They might attract desperate people who have mediocre tech skills who are willing to take on the risk and lower pay. They may supplement pay by providing stock in the company, but that is dangerous because it provides techies with a huge amount of power, especially if they are voting shares.
  • They may be held hostage by investors, many of whom are not current with market, tech and other forces, and will have undue influence on the company because they want to see a return on investment.
  • They may have a massive ego that prevents them from learning about new things, listening to others, and respecting talent and skills that they lack.

When startup founders are feeling extreme fear, they often do the following:

  • Double down on what they have already been doing, even though it isn’t working. (The market is rejecting their idea, or the technology isn’t well suited at the time, etc.)
  • Make a desperate move. When this comes from a place of extreme fear, it is usually foolhardy. I have seen startup founders fire people unnecessarily, pull funding from successful efforts, take out massive personal loans, lie, cheat and steal.

Contrary to what pop culture likes to portray and business folklore loves to perpetuate, desperate last minute moves in the face of certain failure do not tend to pay off. Instead, calm, rational, informed decisions can help save the day.

One of the most difficult parts of my job is helping frozen founders. Their fear of failing can be so paralyzing and difficult, and requires them to not only cope with their startup and all of those pressures, but to work on trust and personal growth.

A good product manager will provide sober second view of the founder’s dream, while owning that dream of a successful product themselves. Since they don’t have the weight of the world on their shoulders, they can move forward with a lot less fear than the founder is usually capable of.

Product managers are either vital in helping address the paralyzing fear that presents product success, or they contribute to it and doom the product to mediocrity or even failure. 

As the song says, sometimes the best thing you can do when you and your product is frozen is to let it go.

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.

What I’ve Been Up To Lately

Some of you have noticed that I have dropped off the conference circuit and I haven’t been very active publicly for a while. Here’s what I’ve been working on lately.

In December 2013, I left the testing field and started working full time as a product manager and a software/user experience (UX) designer. My consulting work had evolved so that I was doing a lot of product management and design anyway, and it was time to make a complete transition. It has been quite the ride. I have worked on products and services for web, mobile, smartwatches, wearables and the Internet of Things (IoT) in several industries.

What is a product manager anyway?

Sometimes product managers are called “the CEO of the product” or “mini-CEOs” which means you have responsibility to package a product and/or service into something that can be marketed, sold and solves a real problem for real people. You try to help the organization determine the right thing to build, at the right time, at the right price, using just the right technology.

The product manager doesn’t do this alone, and when we get it right, the team gets the credit. When we get it wrong, the product manager has ultimate responsibility for the product or service, just as a CEO has ultimate responsibility for the organization.

It’s not an easy job, and one of my mentors told me that if I didn’t experience times when it seemed like everyone in the organization was angry with me, I should worry I was doing something wrong.

In the book The Art of Product Management, p. XIV, Rich Mironov describes:

… the product manager is responsible for the long-term development and health of a product, and is constantly faced with co-workers (or customers or partners or company executives) who want short cuts to good results.

The role requires a lot of diplomacy as well as a willingness to make difficult decisions to help do the right thing for the product, the customers and the organization. It’s enormously challenging, but hugely rewarding.

What do you do all day?

Product management varies a lot from organization to organization, and from person to person. It can be as unique as the person in the role, and different people have different aptitudes, interests and strengths. Some of my colleagues do more work on the business and marketing side, and some of them are more big picture strategists with a lot of team members doing the hands on work. Others have more of a role in day to day project management. I tend to focus more on UX and design as well as typical product management activities.

Todd Birzer from Kevolve describes four areas where product managers work:

  1. Market Intelligence
  2. Product Strategy
  3. Product Development
  4. Lifecycle Management

When I am doing work in market intelligence, I may be doing market research, customer research, competitor analysis, technology analysis and I am constantly keeping up with media and trends.

Product strategy work involves product/service idea validation, determining differentiators for a product/service, developing a monetization strategy and financial analysis. At this point I am also helping find the right technology fit and validating technical, legal and business requirements are all in alignment. Usually I start to create initial product roadmaps at this point to help us determine a focus on what we would like to deliver when. Sometimes we prototype or build a proof of concept, and I may do the initial app designs and UX work here as well. A lot of work at this stage involves making sure there is an entire product from a marketing, sales, support, pricing and technical implementation. It is really easy to end up with a “bucket of features” at the end of a release rather than a real, quantifiable product. A bucket of features is incredibly difficult to sell because it is vague, and doesn’t have a clear differentiator from the competition.

There are a lot of business and sales areas to explore here as well as the technical implementation. Analyzing financials and forecasting by testing out revenue models is important. In an early stage startup, I am actively involved in business model validation and helping with business plans, investor pitches and other funding applications.

During product development, I often do hands-on activities such as business analysis (requirements work, modeling, etc.), planning, setting up a project management practice, but mostly I do a lot in UX, design and gamification. In some cases I oversee others doing the work, and on smaller projects, I am heavily involved. I also assist product owners on Agile teams, helping them write stories and epics, figure out testable requirements and quality criteria, and make sure they have support from other areas of the business and enough to do.

Lifecycle management involves analyzing metrics and financials and helping stakeholders make decisions about products/services that are out in the market. You combine your market intelligence and product strategy and customer experiences with metrics to determine enhancements, bug fixes, what features to add, what features to cut, etc. You also look at the lifecycle of the product in the long term and plan for obsolescence. Ongoing funding and cost vs. revenue analysis is also important here as well as measuring ongoing customer engagement. The information we provide is helpful for teams as they plan out future development and other activities.

Why don’t we see you at conferences anymore?

When I decided to make a career transition, I tried at first to work in both worlds. For a couple of years I spent some of my time doing work in testing training and consulting, and the rest of my time doing product management things. The transition got stuck so I cut out testing and made the leap to full time product management. Previously, most of my public appearances were for testing topics, or for conferences heavily associated with quality and testing. Now I speak exclusively about product management, design, UX or gamification. So you won’t see me at the same conferences I used to attend.

On a personal level, I have had some health challenges that have been slow to heal which have made frequent travel difficult, and my wife and I welcomed our son (our first child) into the world. Not travelling very much meant we were able to start a family and I can spend more time with them. It is amazing to be around to see our little guy grow and change before our eyes. Cutting travel down significantly is also much healthier for me overall.

I also started feeling strongly about building more locally. Supporting local organizations can be better for the community we live in, for the people we see around us in our daily lives, not to mention the environment. I have been working with companies in Western Canada, and started a local meetup for Calgary-based software product managers.

What’s next?

One of the most difficult things about a career transition like this is that I don’t see most of you face-to-face anymore. I am now exploring options for more remote work so I can collaborate with more of you and share ideas and learn from working with different people and teams.

I am writing more based on what I have learned, so you will see more from me on topics that I described above. I wrote an article on designing for wearables for Smashing Magazine: Designing For Smartwatches And Wearables To Enhance Real-Life Experience and I have more to come in this space.

I will also slowly begin to explore opportunities for more public events, but sorry, no more testing conferences.

If you would like to keep in touch, feel free to contact me. I always enjoy hearing from anyone who I have met in the past, or people who have read my work and want to chat about it or to just say hi.

“Don’t Freak Out!” Product Management & Emotion Management

As a product manager, some days it seems like half of my time is spent calming down team members who are freaking out about the project. And on those days, most of the other half seems to be spent re-establishing and maintaining team alignment on a product release. (Usually this is because the people who need to calm down have spread their uncertainty around to others.)

ache-19005_640
(image via pixabay)

I used to feel side tracked because I felt that I should be spending my time on market research, helping with monetization plans, supporting sales and marketing, planning and prioritizing features and helping make a decision on a UX improvement or to help the team re-prioritize a feature because of some unforeseen event. I didn’t expect to spend so much time helping keep people calm, and repeating the product vision, priorities and keeping the team on track. I’m a collaborative person, so I always have buy-in before proceeding. Why then, do some days seem like most of what I do is listen, talk, repeat myself, listen, talk and repeat myself some more? Didn’t we all agree on this stuff? What’s going on?

At first, when someone freaked out over something we had settled on and agreed to as a team, it was tempting to just point them the product vision statement written in huge letters and posted above our development board. Or opening a product roadmap, and pointing at it as the person ranting to me insisted we should be doing something else. What happened to the agreement that we had as a team, and more importantly, your agreement and endorsement? What happened?

What I learned is, a lot of times people are just freaking out. Some people freak out more than others, and we all freak out in different ways. As a product manager, I am often the first person they come to when they are freaking out. And, an important part of my job is to deal with freak outs. If I can keep people calm, focused and productive, that helps us reach our shipping targets.

The truth is, we are all emotional creatures and software development projects are incredibly difficult. We all freak out a bit on projects from time to time if we look at the big picture and think of all the work we have to do in such a short time. At any point in time during a software development project, it can be overwhelming if you think about it too much. However, people sometimes also freak out for good reasons.

Techies may get worried that we can’t meet commitments, or implementing a new technology isn’t going as well as planned. Or we may just get bored of the technology, learn about something new, and feel that there is a better way to move ahead than our current roadmap and plan. As business people, we get all kinds of tantalizing offers from potential customers, and we are very swayed by the people who are willing to spend money. It can take what seems like forever for a technical team to deliver a release (because it is so labour intensive), so we may get distracted away from the current release, and start talking about an idea for some time down the road. To be honest, I get freaked out a bit too. Here are some recent minor freakouts:

  • Did we pick the correct web framework? What if it doesn’t support the browser that our first client uses in their organization!??
  • Did I do enough research with our monetization model? What if my research and recommendations and my interpretations of consultations with experts are wrong?
  • Did I misinterpret the usage statistics and engagement metrics from our apps which could potentially mess up our priorities for the next release? At worst, what if we change something that the majority of people are using and annoy our best customers?

See? I can be as neurotic as the next person. I deal with my own freakouts by having my own personal support network. Sometimes I just need to vent to someone else who isn’t directly involved with the team. Other times, I need to bounce ideas off of senior team members to re-evaluate our current path. What if I am missing something important? I also research any freakouts when others agree. And sometimes, we just have to find out and adjust accordingly when we release. If I guided us towards the wrong monetization model and the wrong priorities, we just need to be on top of it and adjust based on market feedback.

Once in a while, someone is right to freak out and disrupt our current path. They had some doubts, researched and realized we are off track and we need to change now. How do I tell the difference between someone who is freaking out and needs a bit of reassurance, and a real issue we need to deal with right now?

Usually, we get unsettled due to reasons that we can’t explain. Some people say our subconscious or our intuition are at work here. When someone brings up an issue but they can’t provide you with a clear explanation of what is wrong, let alone an alternate solution, it is important not to dismiss it. So I always ask for proof driven by research. Can you spend some time looking into the problem to see if it’s a real issue, or just a minor freakout? If we need to change, why? What is the business case? Where is the evidence I could use to show stakeholders we are off track? Once a team member starts to make their freak out defensible, two things usually happen:

  1. once they start to research, they realize their freak out is unfounded, and they calm down by looking at evidence that supports that we are on the right track)
  2. as they gather evidence, they are able to reinforce their misgivings by forming a better idea of what the problem is, and are able to communicate it much more convincingly

In the first case, we just let it go and move forward. In the second case, the freakout turns into a strategic business or technical decision.

Sometimes, freakouts are symptoms of communication problems, poor tools (or poor use of tools) or other issues unrelated to the project itself. These are important to watch for too, because even simple issues can cause people to spend time freaking out instead of working because something is wrong.

As my colleague Aaron West points out, it’s important to provide a safe environment and provide permission for people to freak out. If I am the person they feel safe freaking out to, and we can deal with their feelings in a healthy way, that minimizes them having to go to others and sidetracking them. If the environment is repressive, and there aren’t healthy outlets, people will undermine the mission of the project by releasing that tension in other ways.

When I presented for the first time at a large international software development conference, I was really nervous. The facilitator could tell, and tried to calm me down with a little pep talk. She told me about her office, how outnumbered the technical IT members were, and how they had insane deadlines with multimillion dollar projects all the time. The projects were heavily publicized, so any delay brought embarrassment to the company, as well as the potential to lose money. It sounded like a very stressful environment to work in, but she said she had learned to thrive there. It was a really easy place to get freaked out in, and a small team could waste time and effort if they got freaked out over the wrong things. So, she printed out a huge poster that said DON’T FREAK OUT! and hung it in the development team bullpen. That didn’t stop people from freaking out, but it helped calm people down, and reduced the freakouts over trivial issues. If someone came to her freaking out, they were freaking out for the right reasons. The message was that I really didn’t need to freak out about presenting my talk, there are a lot more important things in life to freak out over than public speaking.

Sometimes I have to tell myself not to freak out and I remember that pep talk and that DON’T FREAK OUT! poster. Is it really worth freaking out, or am I just stressed and worried? Late at night on a stressful project, all kinds of problems seem large and insurmountable. I have to ask myself, is this worth being freaked out over? Do I need to ask for another opinion? When others come to me freaking out, I need to help them either channel that energy into something productive, or decide that they are freaking out about something important, and we do need to change what we are doing.

Different projects have different levels of freak outs, and they occur during more stressful times on a project. I have to remember that helping people navigate freak outs is just as important as the cool tasks in my job description.

Lessons Learned When Designing Products for Smartwatches & Wearables

Lately, I have been doing a bit of work designing products for smartwatches and wearables. It’s a challenge, but it is also a lot of fun. I’m just getting started, but I’ll try to describe what I have learned so far.

Designing for these devices has required a shift in my thinking. Here’s why: we have a long and rich history in User Experience (UX) and User Interface (UI) design for programs written for computers with screens. When we made the leap from a command line interface to graphical interface, this movement exploded. For years we have benefitted from the UX community. Whenever I am faced with a design problem when I’m working on a program or web site, I have tons of material to reach for to help design a great user interface.

That isn’t the case with wearables because they are fundamentally different when it comes to user interaction. For example, a smartwatch may have a small, low-fidelity screen, while an exercise bracelet may have no screen at all. It might just have a vibration motor inside and a blinking light on the outside to provide live feedback to the end user.

So where do you start when you are designing software experiences that integrate with wearables? The first thing I did was look at APIs for popular wearables, and for their guidance on how to interact with end users. I did what I always do, I tried to find similarities with computers or mobile devices and designed the experiences the way I would with them.

Trouble was, when we tested these software experiences on real devices, in the real world, they were sometimes really annoying. There were unintended consequences with the devices vibrating, blinking, and interrupting real world activities.
“AHHHH! Turn it off! TURN IT OFF!!”

Ok, back to the drawing board. What did we miss?

One insight I learned from this experience sounds simple, but it required a big adjustment in my design approach. I have been working on software systems that tried to make a virtual experience on a computer relatable to a real-world experience. With wearables devices that we literally embed into our physical lives, that model reverses. It can mess with your mind a bit, but it is actually very obvious once it clicks in your brain.

Simply put, when I don’t have a UI on a device, the world becomes my UI.

Let me expand on my emerging wearable design approach to help explain why.

Understand the Core Value Proposition of Your Product

If you’ve been developing software for computers and mobile devices already, this may sound simple, but it can actually be a difficult concept to nail down.

One approach I take is to reduce the current features. If we cut this feature, does the app still work? Does it prevent the end user from solving problems or being entertained? If we can cut it, it might be a supporting feature, not a core feature. Remember, wearables have less power and screen real estate, so we’ll have to reduce. When I had a group of core features remaining, now it is time to summarize. Can we describe what these features do together to create value and a great experience for users?

Another approach I use is to abstract our application away from computing technology altogether. I map out common user goals and workflows and try to repeat them away from the PC with a paper and pen. With an enterprise productivity application that involved a lot of sharing and collaboration, I was able to do this with different coloured paper (to represent different classes of information), folders (to represent private or shared files), post-its and different coloured pens for labelling, personalization.

In a video game context, I did this by reducing the game and mechanics down to a paper, pen, rule book and dice. I then started adding technology back until I had enough for the wearable design.

Now, how do you describe how you are different? Have you researched other players in this market? Who are your competitors, or who has an offering that is quite similar? How are you different? What sets you apart in a sea of apps and devices? This is vital to understand and express clearly.

How do I know if I am done, or close enough? As a team, we should be able to express what our product is and what it does in a sentence or two. Then, that should be relatable to people outside of our team, preferably people we know who aren’t technologists. If they understand the core offering, and express interest with a level of excitement, then we are on our way.
If you are starting out new, this can be a little simpler since it is often easier to create something new than to change what is established. However, even with a fresh, new product, it is easy to bloat it up with unneeded features, so have the courage to be ruthless about keeping things simple, at least at first.

Research and Understand the Device

With wearables and mobile devices in general, the technology is very different than what we are used to with PCs. I call them “sensor-based devices” since the sensors are a core differentiator from PCs and enable them to be so powerful and engaging to users. The technical capabilities of these devices are incredibly important to understand because it helps frame our world of possibilities when we decide what features to implement on wearables and smart watches. Some people prefer to do blue-sky feature generation without these restrictions in place, but I prefer to work with what is actually appropriate and possible with the technology. Also, if you understand the technology and what it was designed for, you can exploit its strengths rather than try to get it to do something it can’t do, or does very poorly.

This is what I do when I am researching a new device:

  • Read any media reviews I can find. PR firms will send out prototypes or early designs, so even if the device hasn’t been released yet, there are often some information and impressions out there already.
  • Read or at least skim the API documentation. Development teams work very hard to create app development or integration ecosystems for their devices. If you aren’t technical, get a friendly neighbourhood developer on your team to study it and summarize the device capabilities and how it is composed. You need to understand what sensors it has, how they are used, and any wireless integration that it uses to communicate to other devices and systems.
  • If they have provide it, thoroughly read the device’s design/UX/HCI guidelines. If they don’t, read others that are offering similar. For example, Pebble smart watches have a simple but useful Pebble UX Guide for UI development. It also refers to the Android and Apple design guidelines and talks about their design philosophy. Pebble currently emphasize a minimalist design, and recommend creating apps for monitoring, notifications and remote control. That is incredibly helpful for narrowing your focus.
  • Search the web – look for dev forums, etc. for information about what people are doing. You can pick up on chatter about popular features or affordances, common problems, and other ideas that are useful to digest. Dev forums are also full of announcements and advice from the technical teams delivering the devices as well, which is useful to review.

Determine Key Features by Creating an Impact Story

Now we can put together our core value proposition and the device’s capabilities. However, it’s important to understand our target market of users, and where they will use these devices, and why. I’ve been calling these types of stories different things over the years: technical fables, usage narratives, expanded scenarios and others, but nothing felt quite right. Then I took the course User Experience Done Right by Jasvir Shukla and Meghan Armstrong and I was delighted to find out that they use this approach as well. They had a better name: impact stories, so that is what I have adopted as well.

What I do is create an impact story that describe situations where this sort of technology might help. However, I frame them according to people going about their regular everyday lives. Remember that stories have a beginning, middle and end, and they have a scene, protagonists, antagonists, and things don’t always go well. I add in pressures and bad weather conditions that make the user uncomfortable, making sure they are things that actually occur in life, trying to create as realistic situations as I can. Ideally, I have already created some personas on the project and I can use them as the main characters.

Most people aren’t technology-driven – they have goals and tasks and ideas that they want to explore in their everyday lives and technology needs to enable them. I try to leave the technology we are developing out of the picture for the first story. Instead, I describe something related to what our technology might solve, and I explore the positives, negatives, pressures, harmonies and conflicts that inevitably arise. From this story, we can then look at gaps that our technology might fill. Remember that core value proposition we figured out above? Now we use this to figure out how we can use our technology platforms to address any needs or gaps in the story.

Next, we filter those ideas through the technical capabilities of the device(s) we are targeting for development. This is how we can start to generate useful features.

Once we get an idea on some core features, I then write three more short stories: a happy ending story (what we aspire to), a bad ending story (the technology fails them, and we want to make sure we avoid that) and a story that ends unresolved (to help us brainstorm about good and bad user experience outcomes.)

Impact stories and personas are great tools for creating and maintaining alignment with both business and technical stakeholders on teams. Stories have great hooks, they are memorable, and they are relatable. With experienced people, they remind them of good and bad project outcomes in the past, which help spur on the motivation for a great user experience. No one wants their solution to be as crappy as the mobile app that let you down last night at the restaurant and cost you a parking ticket.

Use the Real World as Your User Interface

UX experts will tell you that concrete imagery and wording works better than abstract concepts. That means if you have a virtual folder, create an icon that looks like a folder to represent what it is by using a cue from the physical world. What do we do if we have no user interface on a device to put any imagery on it at all? Or maybe it is just very small and limited, what then? It turns out the physical world around us is full of concrete imagery, so with a bit of awareness of a user’s context, we can use the real world as our UI, and enhance those experiences with a wearable device.

Alternate Reality Games (ARGs) are a great source of inspiration and ideas for this sort of approach. For a game development project I was working on, I also looked at Geocaching mechanics. Looking to older cellular or location-based technology and how they solved problems with less powerful devices is an enormous source of information when you are looking at new devices that share some similarities.

I talked to a couple of friends who used to build location-based games for cell phones in the pre-smartphone era, and they told me that one trick with this approach pick things that are universal (roads, trees, bodies of water, etc.) and add a virtual significance to them in your app experience. If I am using an exercise wearable, my exercise path and items in my path that I pass by might trigger events or significance to the data I am creating. If you run past significant points of interest on a path, information notifications to help cheer you on can be incredibly rewarding and engaging.

Enhance situational activities

One thing that bugs me about my smartphone is that it rarely has situational awareness. I have to stop what I am doing and inform it of the context I am in and go through all these steps to get what I want at that moment. I want it to just know. Yesterday I was on my way to a meeting in a part of town I am bit unfamiliar with. I had the destination on my smartphone map, without turn by turn directions turned on. I had to take a detour because of construction, so I needed to start a trip and get turn-by turn directions from the detoured area I was on. I pulled over to the side of the road, pulled out my smartphone, and I spent far too long trying to get it to plan out a trip. I had to re-enter the destination address, get the current location I was at and mess around with it before I could activate it. A better experience would be a maps app that would help and suggest once it senses you have stopped, and allow you to quickly get an adjusted trip going. While you have a an active trip, these devices are quite good at adjusting on the fly, but it would be even better if they knew what I was doing and suggested things that would make sense for me right now, in that particular situation.

It is easy to get irritating and over suggest and bug people to death about inconsequential things, but imagine you are walking past your favorite local restaurant, and a social app tells you your friends are there. Or on the day you usually stop in after work, your smartwatch or wearable alerts you to today’s special. If I leave my doctor’s office and walk to the front counter, a summary of my calendar might be a useful thing to have displayed for me. There are many ways that devices can use sensors and location services to help enhance an existing situation, and I see a massive amount of opportunity for this. Most of the experience takes place in real life, away from a machine, but the machine pops up briefly to help enhance the real life experience.

Rely on the Brain and the Imagination of Your User

If we create or extend a narrative that can make real world activities also have virtual meaning, that can be a powerful engagement tool. One mobile app I like is a jogging app that creates a zombie game overlay on your exercise routine. Zombies, Run! is a fantastic example of framing one activity into a context of another. This app can make my exercise more interesting, and gets your brain involved to help focus on what might become a mundane activity.

With a wearable, we can do this too! You just extend the narrative of what you created on your job and delay telling you what happened until you are complete, and have logged in to your account on a PC or smartphone/tablet. You have to reinforce the imagery and narrative a bit more on the supporting apps on devices with a screen.

ARGs really got me thinking about persisting a narrative. It is one thing to apply virtual significance to real-world objects, but what happens if we have no user interface at all? What are we left with? The most powerful tool we have access to is our human brains, so why not use those too? Sometimes as software designers I think we forget about how powerful this can be, and we almost talk down to our users. We dumb everything down and over praise them rather than respecting that they might have different interpretations or alternative ways of creating value for themselves with our software. Just because we didn’t think of it doesn’t mean it has no merit. It does require a shift towards encouraging overall experiences rather than a set of steps that have to be followed, which can be challenging at first.

Wearable Integration – Data Conversion

If you are working with a wearable that doesn’t have a screen or UI, and is essentially a measuring device, one option to tie in your app experience is to think of converting the data from one context into another. This can be done by tying into APIs for popular wearables. You don’t have an app on the device, but your device ties into the data that is gathered by it and used for something else. For example, convert effort from an exercise wearable into something else in your app. One example of this is Virgin Pulse, an employee engagement application that has a wearable that tracks exercise. Exercise with the wearable can be converted into various rewards within their system. The opportunities for this sort of conversion of data that is measured for one purpose to another experience altogether are endless.

One app I designed extended data generation activities to a narrative in an app. We extended the our app concepts to the physical activity and tapped into the creative minds and vivid imaginations of the humans using the devices with a few well placed cues. This was initially the most difficult app for me to design, but it turned out that this was the overwhelming favourite from a “fun to use” perspective. The delay between generating the data out in the real world, and then coming home and using your PC or tablet to discover what your data measured by the wearable had created in our app was powerful. Anticipation is a powerful thing.

However, be careful when you do this. Here are a couple of things to be aware of:

  • Make sure the conversion rules are completely transparent and communicated to the users. Users need to feel like the system is fair, and if they feel taken advantage of, they will stop using your app. Furthermore, many consumer protection groups and laws could be broken in different jurisdictions if you don’t publish it, and change it without user consent.
  • Study currency conversion for ideas on how to do this well. Many games use the US dollar as a baseline for virtual currencies in-game, mirroring the real world markets. These are sophisticated systems with a long history, so you don’t have to re-invent the wheel, you can build on knowledge and systems that are already there.
  • Add Variability Design Mechanics to Combat Boredom

    It can be really boring to use a device that just does the same things over and over. Eventually, it can just fade into the background and users don’t notice it anymore, which causes you to lose them. If they are filtering out your app, they won’t engage with it. Now, this is a tricky area to address because the last thing you want to do is harass people or irritate them. I get angry if an app nags me too much to use it like some needy ex, or try hard salesman. However, a bit of design work here can help add some interest without being bothersome, and in many cases, add to the positive experience.

    Here are some simple ideas on adding variation:

  • Easter Eggs: add in navigation time savers that will be discovered by more savvy users and shared with friends to surprise and delight
  • Variable Results: don’t do the same thing every time. Add in different screen designs for slightly different events. One trick is to use time and seasons as cues to update a screen with themes that fit daytime, night time, and seasons. Another is to use the current context of use to change the application behaviour or look. There are lots of things you can do here.
  • Game Mechanics: levelling and progression can help people feel a sense of progress and accomplishment, and if there are rewards or features that get unlocked at different levels, it can be a powerful motivator. It also adds dimensions to something repetitive that changes the user’s perspective and keeps it from getting stale.

Provide for User Control and Error Correction

As we learned when designing notifications for a smartwatch, it can be incredibly irritating if it is going off all the time and buzzing on your wrist. Since wearables are integrated with our clothing, or worn directly next to our bodies, it is incredibly important to provide options and control for users. If your app is irritating, people will stop using it. However, one person’s irritating is another person’s delight, so be sure to allow for notifications and vibrations and similar affordances in your product to be turned on and off.

Conclusion

This is one of the most fun areas for me right now in my work, and I hope you find my initial brain dump of ideas on the topic helpful. Sensor-based devices are gaining in popularity, and all indications show that some combination of them will become much more popular in the future.