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.

Waterfall Effects of Agile

Agile is known to improve software development, but there are huge benefits to using Agile that impact your team and customers.

Good practices lead to better products, happier employees, more engaged users, and better growth. It’s a waterfall-like trickle down effect if you will.

But unlike Waterfall development models, Agile has quick turnaround times and leaves room for innovation.

Create Time Savings

Agile encourages constant feedback and communication between programmers, customers, and users. It helps companies operate and produce results more quickly and efficiently.

It smoothly accommodates change requests, meaning essential changes can be implemented in a timely manner.

This is unlike the Waterfall model, which struggles to cope with any required changes during a project.

More feedback means:

  • less time wasted building useless things

  • more time spent building the right thing

  • the right thing gets delivered on time

Improve Team Morale

Agile helps maintain a sustainable work pace, which keeps your team’s’ morale high:

  • Agile lets every project team member become empowered to make decisions and move forward with development.

  • Agile breaks work into short development cycles, letting you quickly achieve results. Products ship faster. But with Waterfall and other similar methods, product iterations can take weeks or months. It feels like a comparative lifetime of waiting.

  • Developers love shipping code. Agile lets them ship more often.

If employees aren’t straining to meet unreasonable deadlines, they’ll be happier. Happy employees stick around. Happy employees also result in happy customers.

Increase Customer/User Engagement

Agile works best with constant communication with customers and users. It keeps products on track and makes sure the products address actual customer needs.

Combine communication with regular usability testing. Not only are you building something the end-user wants, but you’re checking throughout the development process that it actually works!

XP Agile’s frequent releases increase customer visibility too. Every time your customer sees an update and progress, they’ll feel engaged and happier.

I don’t know about you, but I prefer happy customers.

Talking with users and customers early on and throughout the development process to understand their needs will guide your choices. You’ll develop a user-focused product, and hopefully a product the user loves.

Satisfy Customers

XP Agile advocates continuous testing throughout development cycles. Through paired programming and test-driven development, code stays clean. Clean code keeps the bugs out.

I’d rather catch bugs during early test iterations while I can still correct and, consequently, still deliver on time to my clients. Plus, users hate bugs. If you can minimize bugs on the front end, your customers will have fewer opportunities for aggravation.

A Model Engineered for Success

I’m not exaggerating when I tell you: Agile development leads to more growth, happier employees, and happy customers.

It’s the best of all worlds. You deliver a product on time that meets your users needs (with minimal bugs) while keeping your employees happy.

Why I won’t learn to code, and you shouldn’t either

Technical literacy !=Learning to code

Note: != is the operator in many coding languages for “not equal to”. (starting with b, then c, c+, java, js, ruby, and many more) I looked it up and then asked some developers which languages utilized it.

What’s the problem?

Over the past few years, I feel like I can’t go a week without hearing someone say, “everyone should learn to code”. And in practically every first conversation I have with an aspiring product manager, I am asked “how technical do I need to be?”

Anyone who’s been around when I’m approached with this topic knows my stance.

I do not think all product managers should learn to code, but I do think we all should be technically literate.

Everyone agrees that quality communication skills are key to being a good product manager [1]. We explain the product vision with all members the team and often translate between the business and engineering worlds. The communication is not unidirectional; we must understand what our colleagues are saying back to us as well.

Many people make what appears to be a logical leap at this point and think that if product people bridge the gap between business and software development teams that they must have a background in coding. How else could one have a quality conversation with a developer about what is being built?

When did learning to code become the silver bullet to having productive exchanges with engineers?

I cannot code, and do not plan on acquiring that skill anytime soon, but I can have an intelligent conversation with software developers about what they are working on. That’s because what is important is technical literacy, not having the specific proficiency in writing code.

What does it mean to be technically literate?

Simply defined it’s the ability to discuss the relevant technology for your product. This means that you can understand and speak with the people deeply engaged in the tech, at least on a basic level. The distinction is that you are not fluent; if you were, you’d be an engineer.

It’s the technical equivalent of ordering lunch and asking for directions to the bathroom in Japan, but not being able to cut perfect sashimi. You can talk about where you’re trying to go, but you leave the details on how to get there to the locals.

Why is being technically literate important to PMs?

Like anything else, depth of knowledge is dependent on the goal. The primary objective of a product manager is to explain the vision and requirements for what should be built so that others can make it a reality. Before we set a product roadmap, we go through multiple prioritization exercises to establish it.

In order to choose the priority for what is developed, a PM weighs user value against the technical complexity. Without understanding both, we cannot make well-informed decisions. Therefore, talking with engineers about the goals for the user and considering their opinions is key to properly deciding which features to build. Often they’ll provide opportunities to reduce effort by changing the order in which items are developed.

Beyond the ability to work with diverse teams, technical literacy also can reduce project risks.

It’s the product manager’s responsibility to prevent time wasted building the wrong things. As my former manager, Graham Siener [2], explained, “development is the most expensive part of your process, optimize for it.” If the conversation about technical complexity is productive, a product manager can ascertain not only what to prioritize but also change the product design to minimize the risk of over-investment in development.

What does technical literacy look like for a product manager?

The things you should know vary depending on the technology involved in your product. But, on a fundamental level, you should know enough to ask questions.

When I took a business law class in college, my professor explained to us that her goal wasn’t to make us lawyers, but instead to give us a good gut for when a red flag should go off in our brains. I think the same about the amount of technical knowledge a PM should have; know when something doesn’t seem right and respectfully challenge your peers until you’re satisfied with the answers.

Julie Babb [3] remarks when we “ask questions, developers are excited to share their knowledge. You just have to ask.” This knowledge adds to our technical literacy for our products. If it’s an unfamiliar product, team, or technology, the questions will seem rudimentary at first. Over time, as we learn more, the questions will become more insightful.

Ellen Chisa, who has an engineering background, recently wrote [4] that what matters is “how curious you are about the technical things.” The curiosity she describes leads to asking questions, which in turn allows us to learn more about the technology behind a product.

Through asking many many questions I’ve learned some essential things I think all PMs working on modern software should know about. These include in no specific order:

I’m sure others would add more things to the list, but to me everything else is built on top of the understanding of these items. Over time, a product manager will gain more technical knowledge and become more confident in their ability to understand the details of each product they work on.

Why not just learn to code?

I ask in return, “What would you learn to code? Ruby? Objective C? C#? Python? Something else???” Then I poke a little more, “will you keep up with your craft and continue to advance your knowledge about coding in the future?”

The reason I ask these questions is to point out that if a person isn’t going to dedicate some serious time to becoming proficient in a coding language, that maybe the initial investment in “learning to code” isn’t the right way to spend that time. Even then, I wonder if in the future whether they will only work on products written in that language? Probably not.

When we interface with other teams (design, legal, finance, sales, etc.), we often ask questions centered on “the why” of things not often the “how”. This is because a product manager’s role is to understand the different pieces enough to make decisions but not enough to do the other people’s jobs.

Therefore, no one says that a product manager should go to design or law school. To paraphrase outcast, “what makes code the exception?”

I think we should take a similar approach to software development. As Lesley Kg says[5] “you need to understand structures, logic, and how to solve problems; these are skills you have in common with your engineers.” She adds that “at the end of the day, they’re the ones building it, not you.” Know how to do your job, not theirs.

My perspective is that if a product manager isn’t trying to transition into a more technical role, why learn to write code? Software development is a specialized skill, and saying that everyone should learn it is no different than saying everyone should learn to change the car’s oil or to speak Spanish.

On that note, I believe learning to code is like learning a foreign language. It has a specialized lexicon, is unforgiving to bad syntax, and has many dialects. Some people are great at picking up other languages, others are less adept. Though being bilingual is nice, no one feels inadequate if they aren’t.

Personally, I’m an auditory learner and I’m good at learning to say important phrases in the lingua franca of countries I visit, but I’m horrible at absorbing written languages. Because coding is equal to learning a complicated foreign language that is available purely in written form, it’s something I’d have to invest a lot of time in learning. The effort in obtaining the skill isn’t worth it to me when there’s so much else I can be doing to improve my own craft.

What should I be learning about instead of coding?

Matt Wallaert, behavioral scientist at Microsoft, emphasizes that coding isn’t the only skill needed in tech. As product managers our role is to understand, prioritize, and explain. Why not work on the related specialized talents [8] instead of trying to master the craft of our peers?

When Rohini Vibha [7] lists the top qualities of a good product manager, she emphasizes that these skills are non-technical. Bo Ren relates them to a liberal arts education, not an engineering one and futher explains [6] that product people have “empathy for teams and users” which is what differentiates us from simply having “enough technical acumen to communicate credibly with engineers”.

Let’s focus our energy on gaining competence in the areas that set product managers apart.

Some ideas on how to sharpen those skill sets:

  • Take a public speaking or improve course and learn to improve your demos

  • Sign up for a facilitator workshop to run meetings more effectively

  • Attend a Meetup to hear from other product and design folks

  • Teach a class about product management and see what questions come up

  • Learn about market shifts in your product’s industry

  • Get better at asking open ended questions when interviewing people

  • Sketch and prototype something and get some feedback on it

Like this post? Click the heart below and consider signing up for my Product Management for Startup Founders email course or bring me into your organization to lead a workshop.

What will you do to up your PM game?

This post would not have been possible without some great peers and thoughtful PMs across the globe like:

[1] Ben Horowitz — Good Product Manager, Bad Product Manager

http://a16z.files.wordpress.com/2014/08/good-product-manager.pdf

[2] Graham Siener — How Technical Should A Pm Be?

https://speakerdeck.com/gsiener/how-technical-should-a-pm-be

[3] Julie Babb — Confessions Of A Non-Technical Pm
https://medium.com/@awkward_hug/confessions-of-a-non-technical-product-manager-1d91f54e15f1

[4] Ellen Chisa — Do I Need To Be Technical To Be A Pm?

http://blog.ellenchisa.com/2014/10/04/need-technical-pm/

[5] Lesley Kg — The Myth Of The Technical Pm

http://lesleykg.tumblr.com/post/103221856417/the-myth-of-the-technical-product-manager

[6] Why You Should Learn Product Management Instead of Coding

http://www.fastcompany.com/3033050/why-you-should-learn-product-management-instead-of-coding

[7] Rohini Vibha — So You Want To Manage A Product?

https://medium.com/@rohinivibha/so-you-want-to-manage-a-product-c664ba7e5138

[8] Bo Ren — This Is Water

https://medium.com/@bosefina/this-is-water-give-the-liberal-arts-majors-a-chance-38acd7635cd