Notifications Are Killing Your Productivity. Kill Notifications Instead.

Have you ever picked up your phone to perform a task (send an email, reply an SMS, e.t.c), but found yourself struggling to remember what this task was as soon as you actually opened your phone?
This happens to me all the time, and while there may be other reasons for my strange, forgetful behavior, the key culprit I have found so far are the notifications pushed to me by my favorite apps such as Facebook, WhatsApp, and LinkedIn (I love LinkedIn ūüôā )

Notifications are helpful since they let you know where to hunt for your next media high. A notification from Facebook might mean that your friend has liked your post, created her own post, or replied to a post that you commented on. Lots of possibilities for connection and sharing! However, despite their usefulness, notifications can and do hurt your productivity in significant ways. Here’s two ways notifications kill productivity:

1. Notifications Increase Your Rate of Context Switching: Like Pavlov’s dogs which always salivated at the sound of a bell, we all have learnt to prioritize responding to our notifications in order to quickly receive the variety and pleasure that they promise. The fact that notifications now sit at (or close to) the top of the list of things clamoring for our attention means that we are constantly switching between them and everything else going on in our lives.
What is the cost of all this context switching? An article published by Inc. states that it takes us about 25 minutes to resume a task after being interrupted. Notifications constantly interrupt us, which means that they add lots of 25-minute resumption times to our already overflowing schedules.

2. They Distract You Whether You Respond To Them or Not: Your phone buzzes while you are in a meeting, and you resist the urge to pull it out of your pocket to see what’s up. Congratulations! But guess what? You spend the rest of that meeting wondering what type of media goodness is waiting for you once you leave the room. Whether you respond to them or not, notifications reduce your ability to stay be fully engaged during interactions with others, or to carve out time to do deep, meaningful work.

Taking Charge of Your Notifications
From my personal experience, and the experiences of others, I can think of two options for dealing with notifications and the threat they pose to our productivity:

1. Turn Them Off: Last week, I turned off notifications on all my favorite apps. This turned out to be the most productive thing I did all week as it significantly reduced my rate of context switching. Turning off all notifications can bring about a serious case of FOMO (Fear of Missing Out). However, my experience so far has been that other internal triggers such as boredom and curiosity keep you going back to your favorite apps with the frequency required for you to not really miss out on anything important.
Also, to remain accessible to close friends and family, I chose to keep receiving notifications from one chat app that almost no ones uses these days (don’t ask me which one ;)). You too can create your own secret communications channel!

2. Find An App For That: As with everything else, apps have started springing up to solve the notifications problem. I haven’t really tested any one of them so I can’t provide any feedback, but according to Trello, examples of apps trying to solve the notifications problem are Offtime, Flipd, and Moment.

Any other thoughts around how to manage notifications effectively?

I Want To Use Data To Improve My Product. Where Do I Start?

Most technology professionals will probably agree that data-driven business and product decisions deliver better outcomes than simply going with your gut, or worse: with the HiPPO. However, an important challenge remains for product teams trying to become data-driven: where do they start?

Below is a series of steps for navigating the path to data-driven product management. These steps could be applied to an entire product, or to a feature existing within a larger product. Also, while it is focused more on technology products, I believe parts of it could be applied outside the technology industry as well. Here goes:

1. Does your product work?:¬†An awesome app that crashes every single time it’s opened is a worthless app. Therefore, the first set of data and metrics to be collected and analyzed should revolve around product health and operational intelligence. This will help you answer questions like how many hours in a day your product is available, what your crash rate is, and what your product’s performance is like during peak times.
Examples of publicly available product health and operational intelligence tools include Splunk and the elastic stack, or ELK.

2. Is it popular?:¬†Once you get going with analyzing your product’s health, the next step is product and user analytics. This means collecting the data and developing the metrics needed to figure out how many people are using your product, and whether that number is trending up, or down. You also want to analyze your user base to identify your product’s user segments, and to begin understanding which segments are valuable, and what the valuable segments care about so you can tailor your product roadmap and marketing programs accordingly. This is not easy stuff, but getting it right pays huge dividends.
Publicly available tools for enabling product and user analytics include Localytics, Mixpanel, and Amplitude.

3. Are product updates changing key metrics?:¬†Every update made to your product that results in no change in any of the metrics that you care about is probably a worthless update. On the other hand, increases or decreases in your business and product metrics may be as a result of external factors such as the weather or U.S elections. ūüôā One way to improve your certainty around what effects your updates are having on your key metrics is by running experiments. In very simple terms, this involves releasing product updates to a subset of your product’s user base, and then comparing the subsequent behavior of the users who ¬†received the update with those who didn’t receive any product updates.
Publicly available tools for enabling experimentation include Optimizely and Unbounce.

4. Is your product Intelligent?: Artificial intelligence (AI) is all the rage today, as it promises to unleash a new wave of tech-enabled productivity on consumers and businesses. However, a critical ingredient for enabling AI scenarios is data. For example, the reason why Amazon can tell you that people who bought item X also bought item Y is because it has huge amounts of transaction data on both items. For your product to be able to support such intelligent scenarios, you need to collect and organize the relevant data sets, and then employ the right algorithms.
The process of enabling AI scenarios within a product usually involves custom development by software engineers. However, publicly available tools that can facilitate this process include Amazon ML and Azure ML.

Image by www.qubole.com

A Year in Product Management: What I’ve Learned

A few weeks ago, I celebrated my first year as a product manager. Much to my disappointment, I didn’t get a whole lot of congratulatory messages. Only LinkedIn remembered (thanks LinkedIn!).

Self reflection is something that I truly value, so I decided to take some time to think about what I’ve learned about the product management discipline during the past year. I came up with three key findings:

1. Wearing Multiple Hats is the Name of the Game
Before I became a product manager, my thoughts about the role can be summed up in this beautiful Venn diagram from the pm heels blog:

pm-ven-diagram

Now that I have a year’s worth of product management experience, I’ve modified this diagram to become something like this:

 

2. It is Important to Always be Working on the Most Important Things

From my product management Venn diagram, you¬†can see¬†that there is an infinite number of tasks that a product manager can be involved in. Yes those tasks can have UX, business, or ¬†technology components. However, they can also involve random stuff like getting pizza for engineers who are working late (I haven’t had to do this yet but I happily will).

This brings us to the problem of prioritization. Since no one can do everything, product managers have to¬†constantly check to ensure that whatever they’re working on has a higher chance of improving their product’s success metrics compared to other things that they could be doing. In case you’re wondering, there most definitely are some cases where the most important thing a product manager can do is get pizza for¬†engineers who are working late. ūüôā

3. Relationships Matter

I once heard someone describe product management as “the grease and the glue of product development”. It’s up to us to rally our stakeholders around a common goal, and to ensure overall progress towards the achievement of that goal. This means that we have to constantly¬†influence our¬†peers in design, development, and marketing. As none of these people work for us, it really comes down to influencing without authority.

What I’ve learned in the past year (and from folks like Robert Caldini) is that people who like and respect you are more likely to listen to and understand your ideas. In the same vein, you are more likely to listen to and understand the ideas of people that you like and respect. This insight has led me to always try to¬†make relationship investments up front, before they were needed; by then it was usually too late.

How Jeff Bezos Decides When to Give Up on an Idea

Jeff Bezos, founder and CEO of Amazon.com, who usually doesn’t give a lot of interviews, gave one at this year’s CodeConference. The whole interview can be found here, and if you can find 80 minutes to see it, I highly recommend it.

The part of Bezos’ interview that stood out for me the most was when he talked about how he decides when to give up on idea. You can view that specific part of the interview by clicking on this link. Paraphrasing loosely, he said:
The most important things we’ve ever done have always seemed dumb to industry experts at the beginning.¬†You can’t listen to people in the beginning when they say it won’t work, but you have to be stubborn on the vision, and flexible on the details.¬†Now at some point, you may have to give up on the vision. How do you know when that is? I think it is when the last high judgement champion folds his or her cards.

I learned two things from Bezos’ insight which I believe I can apply in my personal and professional life:

  1. I need to intentionally schedule time to evaluate my goals. Just like in the world of business, a time may come when I may need to give up on some of my existing goals in order to move on to new things. The only way to arrive at that decision is by stepping back and evaluating things. Now it’s important to mention that one doesn’t evaluate too frequently, as that may become a distraction in and off itself. Instead,¬†evaluations should be adequately spaced to enable the proper exploration of goals and opportunities.
  2. I need to have high judgement champions in my life; people interested in my growth and development whom I respect and admire, and whose judgement I trust. When things because unclear to me, or when I’m trying to decide if I should persevere or give up on a significant life goal, I can lean on these people for insight and advice. Some people also refer to this as having a personal board of directors.

Any other thoughts or ideas on how to decide when to persevere and when to quit?

 

Five Agile Practices That Scale

Since the creation of the agile manifesto in 2001, agile practices like extreme programming (XP) and scrum have grown in popularity with startups, but haven’t done so well in large companies. Some argue that the reason for this is that agile methodologies were actually created for small teams in the same physical location, and therefore isn’t as relevant in the highly distributed product development teams that can be found in most large enterprises.

While agile does work best for small, collocated teams, I recently came across a book titled Scaling Software Agility: Best Practices for Large Enterprises, which argued that there are seven agile practices that can be successfully applied across organizations of any size. I thought of sharing all seven, but decided for the sake of brevity to discuss my top five :). They include:

  1. The Define/Build/Test Component Team: Instead of having the database team, the mid-tier team and the web/mobile team come together to deliver a feature, create a feature team made up of database, mid-tier and front-end engineers, as well as other team members (designers, product managers, e.t.c) needed to define, build, test, and deliver value to the customer. Amazon’s “two pizza” teams are a great example of this practice at scale.
  2. Smaller & More Frequent Releases: Move away from the “big bang” release that is done once a year to smaller and more frequent releases. This enables your product teams to respond faster¬†to customer and competitive dynamics. Facebook is a good example of this practice, with its “move fast, break things” mantra.
  3. Concurrent Testing: All code should be tested code. Test cases should be written up before actual coding is done, and checked-in code should be subjected to a barrage of automated tests. Not sure about which big company is a good example here ūüôā
  4. Continuous Integration: The product team is not allowed to say coding is done until the code is in a releasable state. This means that it can quickly and easily be deployed to a production-like environment, using a deployment pipeline that subjects it to a series of automated tests. Google seems to have been doing this for a while now.
  5. Regular Reflection and Adaptation:¬†A company that isn’t learning is a company that is dying. Very regularly, product and business teams need to reflect on what’s working and what needs to be improved, and take steps to implement the needed changes. Our fearless CEO is definitely helping us lead this charge at Microsoft! ūüôā

These five practices are mostly self evident, and aren’t really a silver bullet. Teams and companies (especially large ones) that adopt them will still face all kinds of challenges as they try to innovate and deliver value to their customers. Notwithstanding, embracing these agile practices will probably lead to faster product development cycles, with less waste (building stuff that no one wants), and empowered teams. Which company doesn’t want that?

Image by info.110consulting.com

How Organizations Fail to Think

I recently came across a TED video by Margaret Heffernan, an international business leader and writer. In her speech, Margaret shared an insight which I felt was pretty radical: most organizations don’t think.

If like me, you work at an organization that requires you to do a decent amount of thinking on a daily basis, you might be wondering what this woman is talking about. According to Margaret, a critical component of organizational thinking is constructive conflict, and most of us do our very best to avoid conflict at work. The reasons for conflict avoidance are many, but some of the top reasons include:

  1. Conflicts can be messy and personal.
  2.  Conflicts are highly unpredictable, and it may be impossible to effectively manage the conflict once it has begun.
  3. People who start conflicts at work are usually labelled as not being a team player, or a whistle blower, and no one likes these kinds of people.

Despite the risks associated with engaging in conflict at work, the fact that the great tragedies of organizations and humanity happened in the open, and succeeded because people failed to speak up against the status quo, challenges us all to go beyond our comfort zones, and engage in the constructive conflict needed to develop creative solutions to our world’s problems.

So how do we do this? Margaret’s talk provided me with three good tips:

  1. Resist the neuro-biological urge to only associate with people who are like you. Instead, develop the patience and trust needed to engage with people with a wide variety of backgrounds and interests.
  2. Realize that speaking up in disagreement is not an end in itself, but is only the beginning of the path to a creative solution.
  3. When you have a question or concern about your organization’s product, service, or business process, it is very likely that others secretly share the same concern. The only way to find out is to speak up.

Any other ideas on how to effectively manage organizational conflict?

 

Why Google Gave Android Away for Free: The Business Case for Open Source Software

In 2007, Google unveiled the Android mobile operating system under an open source license. This meant that Original Equipment Manufacturers (OEMs) such as LG, HTC and Dell could access the Android source code, and modify it to suit their specific needs, without paying a penny to Google. Why did Google choose this open source approach, when it could have made a decent chunk of money from selling Android?

While I don’t work for Google, I’ve spent some time researching and thinking about the business case for open source software. I believe that from a business perspective, an open source model might make sense for the following reasons:

  1. Monetization of Proprietary Add-Ons: Open source software is likely to gain market share faster than commercial software as its growth is not restricted by the friction of financial transactions. This rapid growth can then be monetized through the creation of proprietary add-ons. For example, Android now has about 65% market share in the US, and Google monetizes this growth through proprietary apps such as Google Search, Google Maps and the Google Play Store, which power its sprawling advertising business.
  2. Reducing Development Costs: Android’s open source license allows any developer around the globe to improve the Android source code for his/her benefit. These improvements are also available to Google for free, and while Google may not necessarily need the free development effort, it ultimately create a positive feedback loop where Android gets better faster, which leads to more users and growth which Google can then monetize.
  3. Attracting and Retaining Talent: Today’s software developers want to do more than write code that earns them a paycheck; they want to change the world. One way to do this is by contributing to cool open source projects that are used by millions of people around the world. Therefore, a company that releases and contributes to open source software projects is likely to be more attractive to talented developers.