How Teaching Tech Can Make You a Better Innovator and Leader

Screenshot 2015-10-23 17.47.20*https://www.flickr.com/photos/ryantylersmith/

This past summer I decided to teach a part-time course at General Assembly.

I love mentoring and coaching others, and public speaking, so I wasn’t surprised to realize how rewarding and fun teaching can be.

But what I didn’t expect was how much this new experience would teach me about leadership and innovation.

Being Prepared Really Helps

When I first started teaching, I thought I could quickly throw together my lesson plans the day before class.

Boy, was I wrong.

I needed three to four hours to prepare for each class, even though I already knew the content. I had to develop the primary lesson content, supporting personal stories, plus extra alternative points in case the other content didn’t land well.

Takeaway: This preparation style is equally useful for training and teaching your team outside the classroom.

Now when I prepare a meeting or workshop with my team, I think about:

  • weaving a story that team members can connect and relate to
  • knowing alternative paths ahead of time
  • having facts and personal stories on hand as examples

My favorite feedback from my students was when they told me: “Michael seems so well prepared to help us understand each lesson.”

You should strive to have your team feel that way about you as a leader.

Check for Understanding to Avoid Mistakes

You can give hours of lectures with supporting examples, but there is no guarantee that your listeners have understood and absorbed the information given to them.

The students at General Assembly had to comprehend each topic if they were going to have a shot at completing their projects.

I learned to check for that comprehension.

The best way to do this was to frequently ask questions during my lectures, get students to verbally fill in the blanks, and just outright ask if anyone needs further clarification on a topic.

Takeaway: To effectively and efficiently convey information when training or instructing your team, you have to make sure your team members understand what you are asking them to do by actively confirming that understanding.

When I’m training my team, here’s what I do:

  • regularly ask questions to see whether what I’m saying makes sense to them
  • use prepared alternative points to back up and reinforce content if there is a lack of understanding
  • make sure they get the nuances of the topic

Investing this time up front will save you more time and avoid mistakes in the long run.

Teaching by Example: Clarify Expectations

One way I teach students is through the “I Do, We Do, You Do” framework.

The idea is:

  • You (the teacher) show the students how to perform a specific task
  • You perform that same task with the students’ participation
  • You ask the students to perform the task on their own

I’ve found this method works brilliantly for both simple and complex topics in the classroom – like our lesson on calculating the Lifetime Value (LTV) of a customer.

Takeaway: This is an effective way to teach new concepts, processes, or frameworks to your team. It ensures team members know exactly what you expect of them.

To make this model work at ThinkingPhones, I encourage all of the managers on my team, myself included, to routinely “get into the trenches” and do the work our product managers do – build a competitive deck, write PRDs, or do market analysis.

This gives all our managers the tools and skills to use the I, We, You model, so we can train and get new product managers up to speed.

How This Applies to Innovation

Overall, teaching reinforces the importance of communicating effectively to your team through:

  • being more prepared than you think you need to be
  • actively checking to make sure your team members understand what they need to do
  • demonstrating tasks so your team members know what is expected of them

Do this well and less time will be spend on re-explaining concepts, or rectifying problems.

Then, when your team is performing their jobs efficiently, and without mistakes, you’ll have more room and time for innovation.

A Product Manager Should Be The Most Curious Person In The Room

the_riddler_vector_by_tauntaunwampa-d59vg56

image (C) Tauntaunwampa

I was talking earlier this week with a new product manager on my team. It was our 1:1 and we were discussing his latest project. It’s the first big product area that this PM has taken on and it’s very important for our next release, so we were using our conversation to make sure everything was on-track. I was peppering him with questions after he shared his update:

“How do you feel the project is going?”
“What challenges have you hit working with your feature team?”
“Is the spec ready for review?”
“Okay, can you show me the diagram for the main use case that you’re stuck on?”
“What about this part of the lookup, can we also double-back with the phone number?”
“I just thought of these two uses cases, have you considered them?”
“What’s left between now and the spec review?”

Later that same day I was in a feature team meeting discussing the status of a new product offering. The lead developer was sharing his detailed update, which included a few specific areas that had risk and ambiguity.

“Why did you choose that implementation path?”
“Will this scale if we 10x the amount of users in a year?”
“Is there a faster way to do it?”
“What if we added more resources?”
“What are the biggest remaining risks?”

Folks who have worked with me before know that I love to ask questions. A lot of questions. 🙂 The questions I asked during the 1:1 with my PM (and their resulting answers) helped me quickly understand the status of the project and where he was blocked. It also set the stage for the type of information I’d want to hear in the next update I get about the project. He and I then spent a few minutes talking about questions, curiosity, and why they’re both so important for Product Managers to be effective in their careers.

Awesome Product Managers have an unrelenting sense of curiosity. They’re equally curious about the latest competitive apps, their own project statuses, industry news, how a piece of backend technology works, the reason a bug occurred, or why a partner team is late on delivering. A great PM should use precision questioning to drill into every conversation and problem to understand what is really going on and what they can do to move things forward. This can reveal gaps in use cases, technical knowledge, or even a partnership agreement that need to be addressed.

Checking for curiosity is critically important when evaluating a PM for a role on your team. Many parts of my PM interview process, from the “What’s your favorite app?” question all the way through the product design case study, are used to see how curious the candidate is. Do they start out the case study by immediately jumping into a solution on the whiteboard based on something they know, or do they open with a set of questions back to me to help understand what they don’t know.

Ultimately your use of precision questioning as a PM must be balanced with the amount of investigation and discovery you do on your own. You will also gain a lot of experience over time simply from being in more and more product cycles.

The simplest way I can frame this advice? Don’t wait if you’re curious about why something is. Get curious and ask the question.

Eat Your Dogfood

sleeping-rottweiler-puppy

“Employees should use the products and services produced by the companies that employ them. They should be emphatic fans of their company’s products. Nothing less.”

— “How to Get People to Eat Dog Food” by Ethan Mayers at AlleyWatch.

I remember when I first heard the question “Are you dogfooding?” shortly after arriving at Microsoft in 2004. I was puzzled for a second about why anyone would not use their own company’s products, especially when they were on the product team that was building them.

Fast forward a few months to the mid-point of the Outlook and Exchange 2007 release. Our dogfood email environment would periodically go completely down for days at a time and we would resort to using IMs and our bug reporting system to exchange important messages. I remember that some of our execs were not in the dogfood environment, but when they heard about the issues we were having they asked to be moved in their with us. They wanted to see for themselves what was going on and to give us a little pressure by having their dogfooding right next to us. Want a quick way to get your day-to-day product stability in shape? Inject a few executives and put their real email on the line and you’ll get blunt feedback, ‘fo sure.

My point here is not that we were in terrible shape in early Office 2007 engineering (we weren’t), nor that we weren’t dogfooding (we all were), or that execs are the best way to do Q/A (they’re not). My point is that as a product manager it’s easy to get stuck staring at the trees and to forget about the forest when working on a specific feature in a larger product. It’s something that can happen more frequently as startup teams get bigger and product managers get more specialized.

In another example from that team, I remember being heads down working on a specific and critical issue in Instant Search in Outlook (one of my features), and I assumed that someone else was seeing the reliability issues I was having with sending email in this specific configuration. I remember bringing up one of those reliability issues to the team that owned Mail Transport, and they determined that it was the specific way that I setup Outlook that was causing the issue (it was having multiple POP accounts loaded into a profile while searching across profiles), and no one else on the team was seeing it because it was setup- and timing-related. It was a critical bug because many of our customers would eventually have a setup similar to mine and therefore could have been susceptible to the issue once we rolled out the new feature.

As teams get bigger and more specialized it’s critically important that product managers dogfood their specific feature or product. It’s equally important, if not more so, to make sure you are always dogfooding end-to-end experiences outside of your feature ownership and across the entire breadth of products you build. You should also look for unique ways to get a fresh perspective while dogfooding. For example, we found that by adding the execs in at a time of difficult product stability during Outlook 2007 development, we were able to inject some “new eyes” into our day-to-day work and get some great objective feedback. This also helped us get dogfood coverage on features like Delegate Access, a setup that only happens when someone else manages your inbox and calendar in Outlook (a setup very unique to VP-level and higher users). In another case, we asked the entire product team to unplug their mouse for an hour to try and use Outlook via the keyboard only, helping us find a bunch of good bugs in our accessibility code.

Here on the Contactive team at ThinkingPhones, as our products get more complex and our team grows, we continue to dogfood every day and constantly come up with new ways to get those fresh perspectives. One of our favorites are weekly team-wide dogfood bashes to help get fresh eyes on new areas of our code. One of our product managers puts up a whiteboard, cranks the music (usually 80’s workout montages from Spotify), and everyone writes the bugs they find up on the board. We sometimes award “most interesting bug” and other fun prizes. You’d be amazed by what you can find with that kind of intense focus. We also have a “Bugs” email alias that gets traffic at all hours of the day, as we have all adopted the habit of sending screenshots and bug reports the minute we see them. We find that these types of efforts help increase the focus of the whole team on the quality of our products.

Our goal at ThinkingPhones is to be proud of our products and deliver amazing experiences to our customers. We believe pride comes from quality, and quality comes from eating your own dogfood.

Yum.  🙂