Category Archives: product management

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.