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.

Just Not Sorry! (the backstory)

The Problem:

A few weeks ago, I was at brunch for the League of Extraordinary Women organized by Sarit Wishnevski. After watching some Amy Schumer clips, the group was discussing how we all shared the same bad tendencies to use “just” and “sorry” when we knew that we shouldn’t.

The article about famous quotes said in “woman in a meeting” language was brought up. There was a collective “UGH” about how true it was and how we wished that it wasn’t.

I had been part of similar conversations before. One recently at a SheWorx breakfast where Adam Quinton encouraged the attendees to stop using “we think” or “we hope to…” in investor pitches.

The women in these rooms were all softening their speech in situations that called for directness and leadership. We had all inadvertently fallen prey to a cultural communication pattern that undermined our ideas. As entrepreneurial women, we run businesses and lead teams — why aren’t we writing with the confidence of their positions?

There was the desire to change, but there wasn’t a tool to help.

Eureka!

I turned to Gillian Morris and said “If we made a gmail plug-in that highlighted these trigger words, would you use it?”

She emphatically responded, “LOVE IT! Yes!”

I polled the other ladies in attendance, and everyone said they would use it and spread the word. Kara Silverman even offered some pro bono promotional support from her firm, Small Girls PR.

This is my bitmoji… it has a striking resemblance

The Tool:

Just Not Sorry is a Google Chrome plug-in that underlines words that undermine your message. It takes 3 seconds to download and then every email you write is reviewed for trigger words.

It looks like you’ve misspelled them (slight color difference between standard Gmail spellcheck)

Message with trigger words underlined by Just Not Sorry

Because our brains are trained to see that as an error, you immediately go back to edit them. But they are spelled correctly! At which point, you realize it’s because the word is hurting our message.

If you aren’t sure why a particular word or phrase is underlined, hover over it for a quick education hint. We used content from Tara Sophia Mohr who calls these words “Shrinkers”; Lydia Dishman who explains how these phrases are useless; Syliva Ann Hewlett who emphasizes that women need to stop apologizing; and Yao Xiao who shows us how “thank you” is more effective than sorry.

We’re found in our beta tests that not only does this reduce the use of these terms in email, but it builds mindfulness to avoid them in all written and verbal communication.

Why this is important:

When someone uses one of these qualifiers, it minimizes others confidence in their ideas. Whether you’re persuading an investor to provide funding, announcing a change in direction to your colleagues, or promoting your services to a client, you are building their confidence in you.

Qualifiers hint to the reader that you don’t have faith in what you’re saying. The last thing you need is to seem unsure of yourself. We want to make it easy to kick the habit by making it obvious when these qualifiers are holding us back.

What’s Next:

Our friend Emma Sinclair suggested that Just Not Sorry should be women’s New Year’s resolution for 2016. We created www.justnotsorry.com to help people publicize their desire to change.

Our goal is to have 10,000 women sign the pledge and have more effective email communication be their New Year’s resolution for 2016. We hope you’ll sign the pledge today and share with your friends.

Finally, we know that this is only the beginning, so we open sourced the code so that other people can build similar tools or add functionality to Just Not Sorry.