Big Data to Help Overcome Unconscious Bias — thanks SAP!

Yesterday, SAP, one of the world’s largest software companies, announced that it intends to build technology to tackle the issue of unconscious bias in the workforce. This manifests in many forms but starting with a focus on gender, they plan to introduce text mining and machine learning to help companies review job descriptions, performance reviews and similar ‘people processes’ for potential bias — and suggest changes to directly impact equality in the workplace.

Tech reducing unconscious bias: That’s a whole new way to target workplace inequity.

The tech community is already starting to find ways to counter the diversity challenge. Companies such as Power to Fly and Entelo are collecting information on social networks to find and target diverse candidates. Gmail plugins such as Cyrus Innovation’s JustNotSorry help people communicate with more confidence and be more conscious of undermining text in their emails (190,000 users and counting). Text.io aims at removing unconscious gender bias from job posting verbiage.

But companies like SAP have the power to significantly escalate the speed at which tech can impact this problem. A mind blowing 74% of the world’s revenue touches an SAP system. That’s a lot of people using their software: Which means a lot of people would be impacted and a lot of gender bias potentially corrected.

When trying to fix a problem, the starting point for any company is an analysis of their current position. The goal is to use analytics and reports to identify and track where biases exist in talent acquisition and management processes (recruiting, compensation, succession planning, etc) coupled with guidance on actions to take to address those biases.

That’s the really important part: ACTIONS. Many companies have made great strides in creating the right measures to illustrate where problems exist, such as women leaving their organisation at certain levels due to child care costs or responsibilities — or pointing to the lack of women in the talent pipeline.

The percentage of women in positions of leadership definitely doesn’t mirror the percentage of women in the workforce in most countries. In fact in some industries or jobs, particularly those in STEM, the numbers are going backwards. So whilst collecting and sharing data on diversity is very powerful, knowing about a problem clearly doesn’t necessarily result in creating and executing a solution.

One reason why fixing the gender bias issue is so challenging is the extent to which this bias is unintentional. Think of Just Not Sorry and Text.io as mirrors, placed squarely in front of those people who need to be made aware of their behavior every time it needs correcting.

Imagine a world where technology influences recruitment and decision making around talent and who gets hired. What if we used tech to mitigate gender bias in that process? Software is the tool HR uses to manage the workforce — and the tool the workforce use to manage their day jobs and how they interact with people. Making that tool conscious of favoritism, aware of language that repels women and able to influence who gets hired and promoted based on merit and performance (as opposed to bias)…. That is an example of how HR software can truly make the world a better, more efficient place.

Why? Because research shows that enabling women in the workforce to fully contribute results in increased revenue and increased innovation.

This is just the sort of programming that pioneering females such as Ada Lovelace (oft referred to as the first female programmer), Margaret Hamilton (the engineer who put Apollo on the Moon), and Grace Hopper (a US Navy computer scientist born in 1906 to whom the term ‘computer bug’ can be attributed) would be proud of: It addresses real inefficiencies with massive impact.

A company and its employees can have the best intentions, products and strategy in the world but if it doesn’t enable them with tech and data, it will ultimately fail. Tech cannot solve the world’s behavioral issues but sustainable, long term investment to help push this agenda forward is visionary — and SAPs intention to optimise the working environment and address the issue of unconscious bias head on will surely shift the needle in to create more inclusive and diverse workforces.

Product Managers Can Make Great CEOs

Product managers describe themselves as a “mini-CEO” or “CEO of the product” so often that there’s a growing backlash against these names. I also never really agreed with the comparison, as product managers lack the authority to make it a meaningful description.

The notion of a product manager calling themselves a mini-CEO has gotten so prevalent that some say it could alienate teammates and affect a candidate’s chances during an interview. One product manager wants to ban this unofficial title outright for being both inaccurate and braggadocious.

Despite the opposition to the CEO description for product managers, I learned that it’s spot-on in some ways. I transitioned from a product management role to that of CEO and noticed there were far more similarities than I thought. The skills that good product managers have can make them great CEOs.

Prioritization is Everything

Communication and prioritization are two fundamental skills needed to be successful in product management. These skills are just as important for CEOs, if not more so. Product Managers often lack the time to get to every task they’d like to handle and that’s doubly true for the CEO. There’s never enough time to handle everything, so prioritization of the most important tasks is key.

With that lack of time, communication is essential. Product managers need to have clear communications with just a handful of other departments, and that’s a good stepping stone to what a CEO does. Instead of just a couple departments, CEOs communicate with a large of amount of clients and staff about a broad range of company issues.

Setting (and Reaching) Goals

People in product are always working towards a vision for their product. They share this vision with the cross-functional teams that can help them accomplish this goal. That’s what I was always doing in my product management days.

CEOs do this on a much larger scale. They have a vision for how to solve problems, build brands, and capture market share. To reach those goals, they inspire the people who can make this vision a reality.

Seeking Feedback

If there’s one thing product managers are good at, it’s testing. Great product managers always A/B test their ideas to learn what users really need. Futures decisions are made based on the results.

In a similar way, good CEOs work with employees and clients before making serious changes. The most effective CEOs aren’t stuck in their ways and are open to making adjustments if any flaws arise. They utilize data to guide next steps, not only their gut.

Accepting Imperfection

In an ideal world, product managers would have all the time in the world to put together a perfect product. In reality, we have to learn to launch flawed minimum viable products on deadline and learn from the results.

CEOs know that, due to time and budget constraints, making a decision is more important than making the perfect decision. The latter is an unrealistic luxury. CEOs make hundreds of decisions weekly and the rest of the team can’t sit around waiting. Instead, they have to make the best possible decision with the information available.. Being open to criticism in the process, meanwhile, helps earn respect.

In Defense of the Mini-CEO

Maybe the “mini-CEO” and “CEO of product” descriptions for product managers are a little over the top. What I’ve learned is that there is definitely some truth to the comparisons. Product managers don’t experience some of the important things that CEOs have to deal with when it comes to leadership and profit/loss. However, some of the key attributes of good product managers are easily transferrable to the CEO position so it’s a great stepping stone.

Got an opinion on this? I’d love to hear it.

10 Things To Consider Before Building Your Next App

Deciding to build an app is easy. Doing it? That’s when things get difficult.

We’ve built our fair share of apps, and we’ve hit stumbling blocks. But that doesn’t mean you should too. That’s why we’ve put together this list of things that you need to think about before you start development.

Let’s take a look at a few different scenarios.

Lessons for New Apps

You’ve decided to build an app, great! Please pause and do a little research before building.

1. Survey your competitors.

Have they built an app solving a similar problem? Examine it. What works and what doesn’t? Why? Form your opinions, and then check out app reviews. As a rule of thumb, the customer is king, listen to them.

Let your competitor’s app inform your choices.

2. Find similar business models.

Don’t limit your research to direct competitors. Broaden it.

Are you building an on-demand app? It doesn’t matter that your app doesn’t hail cars; you should still look at Uber for best practices. Other companies have solved your problems. Don’t reinvent the wheel.

Lessons for Companies with Web Apps

You already have a web app; now you’re translating to mobile. You’ve got to think through a few different challenges.

3. Understand your value add.

Why do your users need the mobile app? What will it do that your web app isn’t doing? Or what will it enhance?

Look at your existing software and be sure that your new mobile app is solving the right problem. It’s possible your app will add no value and you’ll regret building it.

4. Make them your apps play nice.

Your users are accustomed to the web app. It’s familiar. Your mobile app needs to complement that experience. It can’t exist in a silo.

If your customer can’t seamlessly use both the web and mobile apps, you’ve done something wrong.

Lessons for Everyone

Other best practices apply no matter where your company is in its lifecycle.

5. Decide mobile responsive or mobile app.

Do you expect customers to use your service daily on the go? Do you use push notifications? Do you need to connect your software to other services? Do you want to rely on connectivity?

These are the questions you need to consider. If you don’t need to build an app, don’t. Save yourself time and money.

6. Mobile needs or mobile wants?

Don’t build everything that your user wants. Get lean. Understand what they need in a great mobile experience and build that. A mobile app built for everyone is actually built for no one. Focus on your core mobile customer’s needs, not all of the “nice to haves” users request.

7. Create a habit.

Don’t waste your time by building an app that no one uses.

You want users to engage with your app regularly. It’s why you didn’t build a mobile responsive website. How are you going to drive that sticky behavior? What habit will your app tie into that keeps your users coming back day after day?

8. Understand the drivers to download.

You can’t build sticky user behavior if you don’t get people to download your app.

Are you going to offer incentives, maybe a free credit? What’s your marketing campaign? Do you want to build a referral mechanism into the product? Establish a clear plan and execute on it.

9. Decide on a platform.

Where are your users? Are they on Android? Then don’t build for iOS. Are they the last Blackberry users?

There’s no sense in building an app for an operating system if your customers aren’t there. If your target users are split between Android and iOS, consider a multi-platform strategy.

10. Plan for maintenance.

Mobile app development isn’t a one-time deal. Mobile platforms and trends change quickly and you need to be ready to change with them. Make sure your plan incorporates updates and additional developer expenses in the future.

If you read these ten things and it helped you develop a roadmap, great. We’re excited to try out your app when it’s released.

But if reading this list made you anxious, shoot us a message. DefMethod specializes in building apps (specifically, multiplatform apps). They’ll remove all the headache and deliver an app that’s easily maintainable by your developers.

Disrupt Yourself (or Disrupting Myself)

I don’t read many books. I’m partially dyslexic and that means that I more often listen to them. But even that is a rarity given my job responsibilities and active NYC social life. Therefore, I even more rarely recommend a book. Today that changes.

I recently was encouraged to read Disrupt Yourself by famed author Whitney Johnson. As a matter of truth, it was Whitney who encouraged me to read it; she and I were emailing about Just Not Sorry and she asked if I had bought the book yet. I hadn’t, but I’m sure glad I did after than conversation.

Originally, I thought it was a typical self-help book geared towards women who needed to start “Leaning In”. I don’t need any encouragement to be more vocal with my opinions and the book didn’t interest me.

Once I started reading it, I realized that I was DEAD WRONG.

Disrupt Yourself is a self-help book for TYPE A personalities just like me. The book focuses on helping over achievers realize that life doesn’t always result in getting a top grade on an exam. Whitney shares how everyday people miss opportunities because they are afraid of failure and how those who’s names you know seize similar challenges.

As I read on, the stories and advice reminded me of the speeches I had been giving around the world about “Being a Scientist”. I had been preaching the importance of experiments and learning from mistakes, but I hadn’t fully internalized my own message.

This book reminded me that each adventure I’ve embarked on has led to lessons learned, that every “mistake” or “misstep” I’ve made has had rewards, and that in order to keep leading an extraordinary life that I had to continue taking risks.

In the same way I encourage anyone I manage or coach to try out new things, I needed to emphasize “what’s the worst that can happen?” in my own life.

So, I encourage you to buy or download the book, you never know what you’ll learn or how it will impact your outlook and your life.

Lean Case Study: Just Not Sorry

This was a guest post I wrote for the Validately blog about the app they built called Just Not Sorry which was an instant internet success. We love how Tami and her team developed and launched their app using solid Lean practices and are excited to share their story with our followers.

We launched JustNotSorry a few weeks ago and oh what a journey this has been! In a matter of days, we have had tens of thousands of installs of this application. We’re pretty sure that if the app worked on more than the combination of Gmail + Chrome that the usage would be even higher. (We have the dozens of emails and tweets requesting it to work on Outlook as proof.)

How does an app or anything else go viral? The instant success of JustNotSorry is a testament to a number of things.

First, this app is FREE! JustNotSorry is a Gmail plug-in that helps you be a better communicator. If you are trying to get ahead in your professional life, downloading this app provides some of those “smart is simple” moments where it is essentially a no brainer. [Just Not Sorry underlines words that tend to detract from a reader’s confidence in your message such as “just”, “sorry”, and “I think”.]

Second, it was a slow news week when we launched and hundreds of blogs, radio shows, and even some TV shows picked up the story because there wasn’t much competition. I’ve learned to never underestimate the power of press and good PR to spread the word.

Third, and potentially most importantly, we designed the app using Lean/Agile principles. Here are the steps we took that are based on solid Lean and Agile practices that led to the successful launch:

• Quick idea validation : When we first thought of the idea, we told a dozen people about it. Everyone said they loved it, but only when Kara Silverman offered free PR services from her company for the app did we know we were on to something. As Steven Cohn(the Founder of Validately) said at LeanUX15, unless someone is willing to provide you their time, money, or social capital, they don’t really love your product. Kara was willing to give us all three. As we shared the app with some beta users, the most common response was “when can I share this with my whole team?”. That’s pretty strong validation.

• Know your ideal user : Can Just Not Sorry be used by anyone? Sure! Did we build it for everyone? Absolutely not! The key to any MVP is knowing your ideal customer and building something to meet their specific need. Our product design centers on a 25–35 year old woman, working to advance her career but weak communication is getting in the way. She wants to change, and we built a tool that nudges her to be more mindful about word choice in email. Knowing our target user also led to very focused marketing for the launch. (Possibly too narrow as it created a backlash against us for policing women’s speech when that wasn’t our intention… but that’s a story for another blog post.) We tailored the messaging and the outreach to women in this age range and encouraged them to spread the word to their friends. Some of the emails we sent were opened over 400 times thanks to key people forwarding them.

• Build small : The app only works on Gmail on a Chrome browser. Could we have built it for a variety of email clients and browsers? Of course! But, why would we invest that time and money unless we were sure it would take off? When people complain that Outlook isn’t supported, we show them that we’ve open sourced the code for anyone to leverage and build it if they want. If there’s a real need for the product, others will make it a priority to help. I’ve often said an MVP should be able to be made within 6 weeks, Just Not Sorry took only 4 days before it was ready for beta testers.

• MVPs aren’t perfect : As Lauren Gilchrist preached at Lean Startup Conf in 2014, “Be a scientist, not an expert, and ship imperfect products. We knew that there were some conflicts with other gmail plug-ins that would cause the app not to work all the time. Rather than try to fix all of the issues ourselves. We shipped it anyway, knowing only a small percentage of people would be impacted and that they’d help us diagnose the issues if we were responsive.

• Test with actual users : Every step along the way we spoke with potential users about their thoughts on the app. We gathered feedback from our target market to ensure we were headed in the right direction. A “short” list of some of the things we tested:

• The name — It was originally “Don’t Say That”, can you imagine the hashtag or the backlash that would have created?

• The look and feel — We switched from highlighting to underlining the trigger words so that it looked like spell check. We were having difficulty explaining that the highlight wouldn’t be visible once the email sent, it wasn’t intuitive. By using a familiar element, we took away the need to explain. We received not a single question about this.

Marketing e-mail subject — If you were part of the 10k people we emailed on day 1, you saw “We’re Just Not Sorry” in your inbox. Our tests that led up to that had longer subject lines that mentioned Gmail, they didn’t create as much intrigue or as high of an open rate. Many of my friends reported opening the email simply because they wanted to know what I was sorry for.

• Landing page content — At launch there were three versions of www.justnotsorry.com built on Instapage each with different copy but identical layouts. Within a day, one of the variations was a clear loser so we paused it. After the press picked it up, we added references to the press coverage and created two one more variations: one with logos and one without. The option with no logos performed 1.3% better for conversion, but we decided to keep the logos anyway.

• Iterate often : The app went through 3 iterations during the 7 days we built it. Aside from the highlight to underline switch above, big changes included the addition of helpful hints when you hover. This came from the realization that most people who use the phrases at the inappropriate time don’t realize why it’s a problem. One week after launch, based on feedback we’ve received, we changed the color of the underline to make it more distinct from spell check and added “trying” as a trigger word.

• Tie into human behavior : The promotions we did for JustNotSorry are attractive to the top of Maslow’s hierarchy of needs; people want to feel part of something bigger than themselves (esteem and self-actualization). One of our advisors suggested that we make this a New Year’s resolution, part of someone’s annual routine. Similarly, we noticed that more shares happen on Twitter and Facebook when there’s a common goal, so we created a target of 10,000 signatures by NYE. Hooks, such as these, attach people to a greater purpose and often creates virality.

• Guide people : Good user experience design is all about getting a person to take the right action without instruction. When the first visitors on our site didn’t do anything more than provide their email, we moved the download link to action #1 and providing email to second place. Similarly, rather than only encouraging tweeting, the redirect after providing your email goes to a ClickToTweet pre-formed, “lazy” tweet, which takes only a split send to post.

Measure the important stuff : We spent over a day adding Google Analytics so we could track the number of installs. It was really important to be able to know that, not only for ourselves but for the marketing campaign around getting a certain number of signatures by New Year’s Eve. Instapage tracked pledge signatures, but only Google Analytics could track all of the downloads from all sources. By keeping track of these figures and promoting them, we were able to get users and the press pretty excited and our app virally spread across the world, 200 countries and counting!

JustNotSorry has been a huge success. We’ve been covered everywhere from the BBC to the Today show, every women’s magazine, and even some newspapers in print. We had tens of thousands of downloads in a matter of 2 weeks for something that only a portion of the population can even use. We attribute our success to building a smart simple product and using the Lean methodologies of validating, testing, and iterating. Could we have been wrong? Absolutely! But we only spent a week or two working on it, so there wasn’t much to lose.

Lean & Agile — Tied at the hip

Reposted from Pivotal P.O.V.

Agile and Lean have been around for decades. Their marriage for software development has a long history as well. Yet, there is still a lot of confusion around what the difference is between them and how they work together.

I’m by no means the world’s expert on either topic, but I’m often part of a conversation with clients or PM friends where the confusion around the terms is discussed. It came up three times this week, so I figured it was time for a post about my views on what each term means.

AGILE: A development process that emphasizes short iterations and focuses on delivery of functional software.

Flavors of Agile may include continuous deployment/integration, test driven development, pairing, scrums, sprints, or many other facets that are too long to list here.

LEAN: A process framework where there is an attempt to minimize risk and waste while maximizing customer value.

It is often achieved through a tight feedback cycle with minimal investment between loops. Lean protocols have been employed to optimize manufacturing, construction, and pretty much any business process you can think of.

LEAN AGILE: The marriage of Agile development iterations with Lean validation practices.

Here’s how this works:

• Establish a hypothesis

• Figure out the smallest thing needed to test it

• Build that thing in an iterative way

• Always be working towards functional software

• Repeat for each feature, epic, and product

As mentioned earlier, I’m not an expert on this, and would love people’s feedback on how what I’ve written should be adjusted.