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.

4 Things Every Product Person Should Do

Image by Flickr user 42614915@N00

Image by Flickr user 42614915@N00

It would be a shame if growing in your career took you further away from having an up-to-date perspective of what’s happening with your product.

You can quickly forget what life is like in the trenches. If you want to be an effective product manager, you need to actually work on the product. Some people estimate you should spend 30% of your time with hands-on work in engineering roles.

I would suggest that it’s paramount for product managers of all levels to be do-ers.

It’s crucial for managers in the Product space to:

  • Get out of meetings
  • Walk away from product roadmaps and strategy
  • And lead by example by consistently getting into the weeds

How to get your hands dirty

Write a Spec

Product Requirement Documents drive the efforts of the entire product team. Its hard to come by a more important, higher leverage piece of work for a company. Every quarter I make sure to take one project or feature and write the entire PRD and spec for it.

This includes writing up wireframes, mockups, business case, scenarios, technical discussion, and timeline. I also put it through the same process  my PM’s need to go through: review, iterations, sign-off, etc.

Teardown a Competitor

When I see a competitor that seems interesting or a technology that could be useful to our products, I will spend an hour on a Friday performing a teardown.

A good teardown will involve – where possible – getting hands on time with the tech or product in question, taking relevant screenshots, and writing up evaluative feedback. I then provide some ideas about how we can either beat the competitor or, failing that, integrate with them. I post these ideas into our wiki and share with the team. 

Triage Bugs

About once a week I will jump into JIRA, pick a product, and review the Priority 1 and 2 bugs. Do they match my expectation of priority? Great. If there are any questions, I will sit down with the individual PM and ask them about it.

Attend Individual Scrums

There are too many projects on my team to go to every scrum, so instead I pick one day each week to attend a different product’s meeting. I usually sit and listen quietly, then afterward will use my one-on-one with that PM to ask questions about what I heard. Theres a lot you can tell about a team just by occasionally showing up to their daily standup.

Why would you do this?

Respect

Students in my Product Management class at General Assembly this semester heard me start every lesson with some form of “This stuff is so cool! I love building products.” One of the first things I look for when hiring PM’s is their raw passion for wanting to build cool stuff.

Doing individual work like this shows your team, your peers, and your management that you are fired up about building products. You’ll earn their respect, which can be especially helpful when onboarding into a new team.

Improved efficiency

The first time you write a spec as a newly promoted manager (especially if you haven’t written one in a while), youll instantly discover what in the spec process needs improvement. Fixing these issues will make your entire team more efficient.

On our team, I realized that we had four different flavors of PRDs. I worked with Alex (one of our Directors of Product Management) to unify them into a single format. We then came up with a template for the new PRDs and put it into our wiki. That’s the spec process we use on all of our products today.

A Dose of Realism

It’s easy to think projects and products will execute extraordinarily well. As a manager in the Product organization, your goal is to balance your optimism for completing a project against your pessimism, your previous experience telling you how complex it is going to be.

Periodically writing a spec, attending a scrum, and triaging bugs can help you stay much closer to what’s actually happening inside your products and code.

Spend your time wisely.

Which will be more expensive: time spent on non-managerial work, or the risk of failure stemming from a knowledge gap between strategy and execution?