The newsletter is about tech product management, though many of the topics I post about will be relevant to PM’s outside of tech and other job types. This is what I focus on:

1. Product management career development
2. Product management skills, tools, and techniques
3. Product planning and roadmaps
4. PM people management
5. Tips for being a better communicator

Check out a couple of my recent posts:

3 Ways to Avoid a Job Change Misstep

What distinguishes the Top 1% of product managers from the Top 10%? [2022 Edition]

I’d love to hear from you on Twitter at @ianmcall or follow me on LinkedIn. Feel free to share feedback or suggestions for topics you’d like me to cover.

After twelve and a half years at Amazon total, I’ve moved on — for good this time. People keep asking me why, so I thought I’d write it down. This is a brief history of my time at Amazon, a company that I’ve loved with a leader that I respect, but that is no longer the right place for me.

I joined Amazon in 2006, when almost all Amazon corporate staff worked in one building, the 16-story art-deco Pacific Medical Center (“PacMed”), now rebranded as the Pacific Tower. In the PacMed cafeteria line Jeff told me his packing table story. On the top floor, you could easily hear Jeff’s big booming laugh no matter which conference room he was in, even with all the doors closed! I joined as a two-pizza team lead (2PTL) running the Lists & Guides business (automated merchandising of user-generated content). I led a team of ten, including nine engineers and one TPPM (technical product and program manager). It was a talented team, but the business hadn’t been well-led previously (i.e. a turnaround), so it was a great opportunity to make a big impact — quickly. I LOVED IT!

There were two aspects of Amazon’s two-pizza team org structure that made it magical:

1. End-to-end Ownership. As a 2PTL, I managed all functions of the business. I decided what the roadmap would be, I had consistent access to my own engineering resources, and I was responsible for the success of the business.
2. Decoupled/Decentralized. We managed our own technology stack and website placements on search and detail pages. We could ship new features on our own schedule, without talking to other teams. There were no gatekeepers.

A third factor that had a huge impact on my initial satisfaction and success at Amazon was my manager, Russell Dicker. Russell exhibited the best of Amazon. High intellectual horsepower, high standards, and all the other Amazon leadership principles. He empowered me to make decisions and never became a blocker. He was a fantastic role model for me during my first four years at Amazon.

Because of these three factors, our team moved very fast. In July 2006 when I joined, the Lists & Guides business wasn’t growing — literally 0% growth year over year. When Amazon is growing 30+% YoY and your small business within Amazon isn’t growing, things are not good. It was on this team that I implemented the first version of my simple turnaround strategy: 1) Wipe the roadmap clean and put everything that was on the roadmap in a parking lot off to the side, 2) Determine the highest impact projects with maximum leverage, 3) Chunk up those projects into the most valuable pieces (the 20% of each project that produces 80% of the benefit), 4) Ship, rinse, repeat. Some of the projects that were on the original roadmap earned their way onto the new one, but most didn’t. This strategy moved the metrics and righted the ship. I actually saw Jeff’s eyebrows go up in my first S-team review in March of 2007 when I showed the hockey-stick growth line starting late 2006 and a business that was now growing 133% YoY.

When Facebook platform launched in May of 2007, I pivoted my team’s focus and started Amazon’s Social Applications team. I created Amazon’s Twitter account and Facebook page, and the team tested the social waters by building apps for Facebook and LinkedIn. In my first Social Applications review with Jeff he kicked off the meeting by asking, “So, do we have a Top 10 app yet?” When I told him no, he looked at the appendix of top Facebook apps and said, “I don’t think we’re cool enough to have a top 10 Facebook app. We don’t have any exclamation points in our name!” and belted out a big laugh. In my doc, I shared my point of view that Social was unlikely to be a big factor for Amazon, given the size of our business. Jeff agreed. Twelve years later, it still isn’t.

In 2008, Russell asked me to take over the Gifting business (wish list, wedding registry, baby registry, etc.). This was a much bigger business than I’d previously managed, and another turnaround. The team was solid and experienced, but leadership of the team was fragmented and there was no real roadmap. Sprints were a random collection of projects, but not in service of any real plan. The team had a poor reputation and it showed in their morale. I reorganized the team to create sub-teams with clear ownership, and implemented V2 of the turnaround strategy above. It worked. The business started growing and the team’s reputation and morale improved. At the beginning of 2011 the roadmap was set for the year, the team was healthy with great product and engineering leads in place, and the engineering teams were built out and stable. I was ready for something new.

I decided to move to the Traffic team (now called Consumer Marketing). I took over the Deals business and built out an Events team who managed holiday and other seasonal events, but my real mission in Traffic was to come up with a brand new program. As much as I had loved my previous time working for Russell and leading businesses in the Community org, my years in Traffic working for Steve Shure (another high-integrity Amazon leader) were the best years of my Amazon career.

Throughout 2011, I used Amazon’s working backwards process to build out a variety of new program ideas. I would meet with Jeff Bezos, Jeff Wilke (my skip-level, at the time), and a handful of other leaders to review and talk over the concepts. I’m amazed at how much time JeffB made available for these reviews. I had the perfect amount of support from both Jeffs. They were willing to share their time and feedback, but they didn’t try to PM or control the project. I still had the same sense of ownership that I’d loved throughout my time at Amazon. At the end of each meeting, JeffB would stand, put his hands on the back of his chair, and give me words of encouragement. In one meeting he paraphrased Winston Churchill and said, “Never … ever … ever … ever … ever … give up!” (followed by his booming laugh). In another he said, “Remember, this process doesn’t have to be efficient. A prerequisite for efficiency is knowing where you’re going.”

In early 2012, I pitched what became AmazonSmile, Amazon’s first significant charitable program. JeffB greenlit the project and from there I started building out the team. The biggest factors for the program’s success were the product, marketing, engineering, and design leads I was able to attract to this mission-driven program, followed by the support of Steve, both Jeffs, and other leaders across the company who went out of their way to support the program. It was an amazing experience for me taking a program all the way from an idea, to launch, to scale over several years. By the time I moved on, the program was donating to over 100K charities every quarter. Every time someone tells me they use AmazonSmile, I love asking them which charity they support and learning why.

Throughout my first decade at Amazon, I’d never seriously considered leaving the company, but in late 2015 I decided to join Airbnb to lead their customer support technology platform. It was a great experience overall, but the one big lesson I learned is that commuting to San Francisco and Portland for 2–3 days each week is a grind. After 18 months of that commute, I decided to head back to Seattle, and to Amazon.

I reached out to Toni Reid, another Amazon leader I greatly respect, to see if she had a role for me in Alexa. She brought me on to lead Alexa International. This was very much a scaling leader role — different from the single-threaded leader roles I’d previously held at Amazon. When I joined, we had a team of 16 and Alexa was live in the UK and Germany. A year later, the team was well over a hundred across ten countries with multiple new country launches behind us and several more in progress. This role was more like a Director of Program Management vs. Product, and success was more about running and scaling processes (managing across the Alexa organization) vs. building and scaling a product. It was an important skillset to build, but not as personally satisfying to me as building a product. I recognized that I wasn’t passionate about the role any longer, and that I need that passion to do my best work.

I moved from Alexa to my last role at Amazon as Director for Delivery Experience (DEX), within the Operations org. In DEX, I led a number of programs (non-Prime delivery experience, ship pricing, cost saving programs, scheduled delivery, marketing, international, benchmarking) but channeled much of my attention into one particular program, Amazon Day. I’m proud of that team and their accomplishments, launching and scaling Amazon Day extremely fast compared to other Amazon programs. Despite those achievements, I recognized late last year that the three factors that made my first ten years at Amazon very satisfying just weren’t there any more for me. I still didn’t have that passion.

In February, 2020, I transitioned off of my role in DEX with a plan to take several months off to decide on my next role. I wanted to take some time to see if I could find another role at Amazon that I wasn’t confident would rekindle my passion, but acknowledging that maybe it was time to leave for good. Short story — I didn’t find anything at Amazon I thought I could fall in love with. During that time, I also started spending time advising an early-stage startup called Vendr that saves companies money on their SaaS spend. Even in a part-time advisory role, I found that passion coming back. The speed of decision-making and execution is exhilarating! I love the quick feedback loop. My experience with Vendr gave me the conviction that it really was time to move on from Amazon, and that I needed to move to a smaller company where the speed of execution is faster.

In April, I pulled the plug and left Amazon officially (yes, in the middle of a global pandemic). I’m taking my time and trying to be very intentional in finding the next role. I want the next role to be perfect for me — a role and company I can be passionate about and stay at for a long, long time. That’s my high-level criteria. After reflecting about what defines me as a product leader, I realized that the product challenges I love solving are ones where distribution, acquisition, and engagement strategy are interwoven with product strategy, vs. building product in isolation.

Lastly, I recognize how fortunate I am to have spent twelve years at Amazon in the first place and to also have the luxury of taking time off before taking another role. I wouldn’t have had either opportunity without a good education, something many are denied. My wife Sara and I support a range of charities, but two specific organizations that we’re channeling more support to recently are the Thurgood Marshall College Fund and Year Up. I invite you to consider supporting these charities and help make a difference in the lives of tomorrow’s leaders.

A gap analysis is a tool that you and your manager can use to come to aligned expectations on what it’s going to take for you to be promoted to the next level. I’ve walked several employees through this process in the past few weeks (and I need to walk through the rest). While it’s fresh in my mind, I thought I’d share it. I’m going to walk you through what a gap analysis is (in a career development/promotion context), how to use it, what it’s good for, and what it’s not.

Rather than just describe the process in my usual somnambulant prose, I thought I’d create a dialogue that’s pretty close to the actual conversations I’ve had with team members who were keen to get promoted and had the bias for action to bring up the topic with me. The manager in this story is yours truly. The heroine is Sara, a rising star on the team who is on a trajectory to get to the next level, but not there yet.

INT. OFFICE - DAY

Sara enters Ian’s office for a 1:1 meeting. This isn’t one of their regular bi-weekly 1:1’s. It’s a one-off meeting she requested yesterday.

Ian: Hey Sara, how’s it going?

Sara: Thanks for making some time. I’ve been on the team six months now. I feel like I’ve been delivering a lot and wanted to talk to you about getting to the next level. I’m wondering how long do you think it will be before I get promoted and what I need to do to make sure that happens?

Ian: You have been delivering a lot since joining the team — thank you. It’s a great topic to discuss and I’m sorry we haven’t spent more time discussing before now. Here’s the process I like to use. It’s called a gap analysis.

Ian stands up and walks to the whiteboard. The whiteboard is immaculately clean because he’s not really a whiteboard kind of guy. He draws a table on the whiteboard while he continues explaining.

Ian: A gap analysis is a tool you and I can use to see how much progress you’ve made towards getting to the next level, where the gaps are, and what you can do to close the gaps. At Acme Company, we have objective guidelines for each job family, and a list of competencies for each level in that job family. Have you seen the guidelines for the Product Manager job family?

Sara: Yes, I have them.

Ian: Great! You want to get to level 7, so the first step is to list all of the L7 Product Manager competencies here. The next step is for you to do a self-assessment of whether you think you’ve already met that competency, either since joining our team or on your previous team. Just mark it Green, Yellow, or Red. Green means you’ve got it covered. You’ve already demonstrated the competency. Yellow means you’ve got some of it. You’ve sort of got it covered, but probably not all of it. Red means you really haven’t done this yet.

Sara is alert (as usual), taking notes on her laptop. She’s surprised that the conversation is going somewhere, because her last manager only gave her platitudes when it came to career development discussions, never anything concrete. She eventually stopped bringing it up and just switched teams.

Ian: Okay, next go through each competency that you’ve marked Green or Yellow and add details in the Evidence column for why you feel you’re Green or Yellow. Name specific projects and say how your work on those projects demonstrated the competency. Make sense?

Sara: Yep, how much should I write?

Ian: Not a lot - just enough to make your case. A few sentences on each is fine. How long do you think you’ll need to go through and do that self assessment.

Sara: Not long, I should have that done by Friday.

Ian: Great! When you’re done, email it to me. Then I’ll go through and do my assessment. I’ll mark each competency Green, Yellow, or Red as well based on how I evaluate the competency. Where your status and mine are different, I’ll add notes on why. Then we’ll meet and go over each of the competencies. For the ones that we both mark Green, we’re good. You’ve already got those covered. For the ones where you’ve marked Green and I’ve marked Yellow or Red (or you’ve marked Yellow and I’ve marked Red), we’ll talk through why our assessments differed. That discussion should give you a better sense for what Green means.

Sara: Do all of them have to be Green for me to get promoted?

Ian: Good question. Not all of them have to be Green, but most of them do with maybe a few Yellows or an odd Red. Sometimes the competency isn’t really relevant for a specific product manager role, in which case Red is okay. The goal is that when we promote someone to an L7 Product Manager role that we have confidence that they can succeed in any L7 PM role in the company. The competencies are how we calibrate objectively.

Sara: Okay, what happens afterwards if there are ones that are Yellow or Red?

Ian: That’s where we make an action plan. For items that are Yellow, we talk about the difference between Yellow and Green and look through the projects that you’re already working on. Hopefully there are projects that should turn those competencies Green just by completing them, or at least by giving a little extra focus to one aspect of them. For competencies that are Red, we might have to get a little more creative. We’ll talk about upcoming projects that might fit the bill. If there’s nothing that looks like it will, we’ll talk about ways to extend existing work or potential new projects you could kick off that would help you close that gap. At the end of the process, you’ll have a plan.

Sara: How long do you think it will take before I can complete all of that and get promoted?

Ian: It depends. We have to go through the process and see what the gaps and the action plan looks like. The action plan determines the timeframe. The good news is you accomplished a lot on your previous team. That work should close a few of the gaps. Your work on the X and Y projects on our team should close a few more.

Sara: Okay, thanks! This is a lot more concrete than I expected. I’ll email you my part by Friday.

Sara closes her laptop and stands up. Ian stands up.

Ian: Great. Once I get that I’ll schedule some time for next week to go over my assessment.

Sara: Sounds good, bye.

That’s the first part of the gap analysis process. The follow-up discussion depends on the specific competencies. If anyone wants a follow-up post on how those conversations or development of action plans go, LMK.

Here’s why I like the gap analysis process:

1. It can be initiated by the employee or the manager.
2. Employees and managers are both part of the process. Engagement by one leads to engagement by the other.
3. It prompts frank conversations and the discussion helps both people align on definition of the gaps, what it takes to close the gap, and action plans for each gap.
4. It is an objective way to reset (sometimes) unrealistic expectations by the employee on how fast they can be promoted.
5. It is concrete and actionable.

If your company doesn’t have objective guidelines for each job family and level, you can still use the process. It just requires some extra work by the manager to list out the competencies they feel the job requires at the next level.

Give it a try and let me know how it works out. When you get promoted, you may be tempted to thank your boss for promoting you, but what should really be happening is your boss should be thanking you, because promotions are a lagging indicator of performance and hard work.

Years ago I created a document called “The Book of Ian” (juvenile title, I know) and shared it with my team. The document contained objective guidelines for communication about data, dates and deliverables. My goal in sharing it was to codify the (high) standards I wanted my team to meet, and that I would try to meet myself. I decided to dust off and update the document, and also renamed it in the process. I present, for your review and discussion, the Operator’s Manual, 2014 edition. - @ianmcall

On Communication:

• Answer the question
• Answer first, then explain
• Be concrete
• When questions should be answered by a date
• Who questions should be answered by a name
• How much/many questions should be answered by a number. Dates, dollars, percentages. Define your units.
• Avoid weasel words (should, could, might, etc.)
• Own your problems. Don’t be defensive. “Yes; my mistake. Won’t happen again.” “I don’t know. I should know. I will have that information for you by Friday.”

On Data:

• Assume the best answer to any question is data. Data first, interpretation second.
• Be precise. Define metrics precisely. Make sure data ties together precisely. Root out error.
• Provide absolute and percentage values.
• Specify the time range.
• If the data you need is not available, make it available. 1) Define what data you need, 2) Create a backlog item, 3) Agitate to get it prioritized appropriately.
• Snapshots (i.e. data points) bad, metrics good. In doing the work to get a data point you’ve done 50% of the work to create a metric. Create the metric once so you don’t have to keep creating snapshots.
• If it is difficult to determine if the data shows something is good or bad, look for comparative benchmarks elsewhere in the company.

On Deliverables:

• Ask for clarification if you are unclear on expectations (due date, format, content).
• If asked for a deliverable by a certain due date, send the document by that date or schedule a meeting to occur by that date and bring any requested documents for review.
• If asked to schedule a meeting to review a deliverable, you are expected to schedule the meeting.

On Dates:

• Be conservative when providing dates and expect to be held accountable.
• I don’t like pushing dates back. Given the choice, I will always prefer to move them up.
• Assume that every date you give me will be relayed to our CEO with your name and the deliverable attached to it.
• COB = Close of Business (5:00 pm)
• EOD = End of Day (midnight)
• EOW = End of Week (Friday, 5:00 pm)

P.S. Standard disclaimer: This post contains my personal opinions, not my company’s.

Operator’s Manual was originally published in Be Yourself on Medium, where people are continuing the conversation by highlighting and responding to this story.