For the last several months I’ve been working on OkayWinston, an AI automation service for small businesses. Think of it like having a tech-savvy operations person on retainer who knows how to wire together the right tools and AI workflows to save your business real time and money - without requiring you to become a software expert.

OkayWinston is for the capable but non-technical small business owner that uas urgent, repetitive work keeping them from the strategic work that would actually grow their business.

A typical OkayWinston customer runs a service business where they’re also the receptionist, billing department, and follow-up person - all rolled into one. A chiropractor responding to leads, taking pre-payment, scheduling treatments. A restaurant owner manually handling staff scheduling or private event inquiries. A contractor whose leads go cold because they’re too busy doing the actual work to respond quickly.

OkayWinston starts with an AI audit - we map business's manual workflows, find the bottlenecks, and hand over a prioritized build plan. From there, the starter package sets customers up with a pre-configured automation server and walks them through building their first agents in live, guided sessions.

The goal isn't to make them dependent on us - it's to give them the tools, the knowledge, and the confidence to keep building themself. Think of it as a small business AI on-ramp, not a dev shop. Ongoing monthly support is optional but available when customers need troubleshooting, agent templates, or someone to think through the next build.

I’m sharing this here not because I think most of you are running a small business yourself (though if you are, let’s talk). I’m sharing it because people who work in tech often have a friend, family member, or former colleague who owns a small business and is quietly overwhelmed by administrative work they can’t afford to hire for.

If that person comes to mind as you’re reading this - the restaurant-owner friend, the dentist cousin, the yoga studio owner you know from the neighborhood - I’d genuinely appreciate an introduction. Just forward them this post with a quick note, or point them to okaywinston.com.

Early stage, Seattle-focused for now, but happy to work with folks anywhere.

To say thanks, I’ll do a 30-minute mentoring call with any of you who refer a small business owner who becomes an OkayWinston customer. We can use that session for anything you like - career decisions, interview prep, working with stakeholders, PM strategy and tactics - whatever!

Thanks for reading - and for any introductions you can make.

- Ian

I do now.

I’m making the corporate>startup transition in two stages. The first stage is supporting my wife Sara and helping her launch her own startup successfully. The startup is allister, a new restaurant and craft cocktail bar that is opening in downtown Mercer Island in a few weeks. I’ve been working full-time this month as the resident IT guy and all-around gopher - doing whatever is necessary to help us get closer to launch. Did you know that our restaurant has about 30 connected devices (POS devices, ticket printers, VOIP phones, security cameras)?

The security cameras and network video recorder at our restaurant are the inspiration for the new startup I’m founding, Airloom AI. There are millions of businesses in the United States alone that have networked security camera systems, yet that video is wasted. Operators look at their video in response to specific events and save off clips, but otherwise the data is wasted and typically gets deleted after thirty days. I believe there is tremendous value in that data that, if harnessed effectively, can help real-world businesses become more successful. That’s the thesis.

I have a clear view of the customers we’ll serve, their problems and opportunities, a sketch of the solution, the competitive environment, and a go-to-market approach. Now, it’s time to build. I’m ramping down my work at allister and ramping up in my new full-time role as Founder.

That’s all I’m sharing for now. Subscribe to the Airloom AI substack if you’d like to follow our progress or learn about ML Engineering roles that will be opening in the coming months.

Sign up for the live session

As a product manager, your job is to create effective user experiences and drive awareness and discovery of your products. You likely lean on designers and product marketers and defer to their judgment... maybe too much. In this session, you'll learn practical tools and frameworks to raise the bar on the user experiences you create.

Sign up to join the session live. It’s free! If you can’t make it, keep an eye out for a recording of the session and a post outlining the concepts I covered.

Try to solve problems and get unblocked yourself by working directly with whoever is blocking you. Do your best, but when it’s clear you’re getting nowhere, it’s time to escalate. I applaud the drive in my PMs who choose to escalate (appropriately) because escalation is forward progress. It’s far better to escalate and risk ruffling some feathers than letting a project stall out.

Here’s how to leverage your leader effectively when it’s time to escalate:

1. Provide background. Give (only) your manager a crisp written summary of the issue that you’re blocked on and what you’ve already done to try to get unblocked. It’s fine to raise the issue verbally in a 1:1, but give them the background in writing so they can audit your actions up to that point and can ask questions when they need more detail.

2. Make your ask. Don’t make your leader figure out what needs to happen. Tell them EXACTLY what you want them to do. That takes work off their plate. if they think a different course of action is the right one, they’ll say so.

3. Tee up your ask. Write the email you want them to send, tell them who you think it should be sent to. You’ve saved them even more work! It’s easier for them to revise the email to adapt to their style or add additional detail (leveraging the background you already gave them) than to write a fresh email.

4. Be open to course correction. Sometimes your leader will point out different things YOU need to do to get unblocked, or build a stronger case for escalation. Don’t just take the feedback - act on it quickly and learn from it.

Leaders can feel exposed when asked to escalate an issue. They don’t want to get called out because the real blocking issue is on their own team. If they feel exposed, they escalate less frequently and more slowly. The steps above minimize or eliminate that exposure and lead them to act.

The Polite Escalation

My favorite escalation technique is what I call the “Polite Escalation”. It’s a gentle technique that doesn’t trigger the scariness of a real escalation but is surprisingly effective. My team and I use it when another team is slow or wavering on following through on a previous commitment - soft blockers. A polite escalation starts with the same steps above. There’s usually an existing email chain. The polite escalation is executed by the PM replying back on the thread with a message as simple as, “Jeremy, just checking back on this. Do you have an update?“ If I’m not already on the thread, my PM just CC’s me in and may tack on, “Adding Ian for vis.” That tees things up.

My reply is super polite, along the lines of, “Jeremy, thanks so much for helping us on [project name]. I’m super excited about this project and it is going to be a big win for [customer segment]. I’d love to get up to speed on the timeline for your team’s pieces and get confidence this project is on track. Thanks, in advance.”

Often, this is enough to get the other PM engaged and results in a prompt, satisfying reply. A nudge from a senior leader can magically move replying or moving forward a project up their priority list. It’s simple human nature.

If the reply is unsatisfying, it at least gets the project moving and brings to light the real blocker (e.g. “we had some attrition on the team”, “several engineers got moved to [other hi-pri project]”, “My manager doesn’t think this is the right approach”, etc.). Once we know the real blocker we can figure out the next technique to employ, which is often getting into a room.

The polite escalation doesn’t solve all problems, but it is almost always helpful and is often a productive, trust-earning stepping stone to more significant escalations. Try it out and drop a comment to let me know how it worked!

P.S. My teams are hiring for multiple PM roles across Seattle, San Francisco, New York City, and Bangalore. To learn more, make sure to subscribe and keep an eye out for a post with details on the roles and how to take action on any you’re interested in.

Craft Your Highlight Reel

For tech jobs, your highlight reel should be:

1. Elevator Pitch. Three (maximum) crisp sentences that describe your overall tech experience. The sentences quickly identify your job function and level, the industries you have experience in, and what separates you from others (in a good way).

2. Proof Points. About 6-8 bullet points listing your most impressive professional accomplishments. Brag (but don’t lie) about the work you’ve done that will be the most significant and relevant to hiring managers, and that you’re proudest of.

Write it down. It should take up about half a screen when someone looks at it on their phone. This highlight reel is going to be the teaser that enables your network to work for you, and that gets a hiring manager to glance at your résumé or consider talking to you.

Identify Your Target Companies

During good times when you have a comfortable job and companies are aggressively hiring, you can reach out to one target company at a time. In bad times or when you’re out of a job, you need to build a large upper funnel of target companies. A large upper funnel means 30 companies, not 3. Create a list of all the companies you’d consider working for and then go ahead and add the tier 2 companies that you should also probably consider but wouldn’t choose in favor of a tier 1 company.

Grab and copy my Job Search Target Companies Template to organize this info on the Companies sheet.

For each target company:

1. Review your LinkedIn contacts and list the current employees and former employees, along with their titles.

2. List the 2nd degree contacts in your network who have the best (i.e. most senior or relevant) connections currently at the company.

Scan Job Postings - But Don’t Apply Directly!

For each company (using the Jobs sheet of your copy of my Job Search Target Companies Template):

1. Go through the company’s jobs site and list open roles (if any) at the company that you think you’re qualified for and would be worth pursuing.

2. Rank the jobs for each company, so you can easily spot the 1-3 jobs that are the best fits.

MOST IMPORTANTLY: Do not, under any circumstances, apply directly for these jobs directly through the jobs site unless you’ve tried and failed to get traction through your network (see below).

Use Your Network

It’s go time! For each target company (whether you found open roles or not):

1. Identify your most senior/best employee contact and pick your best contact method (corporate email address > personal email address > LinkedIn message > Twitter DM or Messenger PM).

2. Contact them to communicate you’re interested in pursuing a role at their company and list the 1-3 roles you think are the best fit. Ask them if they’d be willing to connect you to the hiring managers and/or refer you for the roles.

3. If you didn’t find any open roles at the company, ask them to forward your info to hiring managers who might have open roles in the future.

4. Include your highlight reel and attach your résumé.

5. If you don’t hear back from your primary contact, try your secondary contact and keep working your way down the list. If you leverage an alumni connection or a 2nd degree connection not at the company, tell them the name of the current employee in their network you’d like them to connect you to.

Pursue this network outreach with most or all of your target companies, shotgun-style. Don’t start with 1-2, wait for weeks, and then contact a couple more, unless you already planned to take a year off from working.

Why not apply directly first or also? When you apply directly, you’ll be lumped in with all the other applications that will eventually get reviewed by a junior sourcer. You’re not using your network to your advantage. If an employee at the company finds out that you’ve already applied, then they will conclude you are already in the system and won’t likely take any other action to help you. They’ll also be ineligible to get any type of referral bonus if you get hired, so you’re giving up a potentially powerful incentive for them to help.

Triage Leads

Don’t be picky at this early stage. Engage with any leads you get back and get some practice selling yourself or doing phone screens/interviews. If you find yourself swamped with good leads, then you can triage or slow-roll some leads so you can prioritize your top prospects.

Thoroughly Prep for Your Interview

I developed a method to thoroughly prepare to interview at a specific company. My wife and brother-in-law were my first guinea pigs. Both successfully landed product management jobs at Amazon and have since been promoted and progressed to more senior roles there. Later, I used the method myself and I’m now the happiest I’ve ever been in my career in my role as Senior Director of Product for Vehicles at Uber.

This company-specific interview prep method includes first preparing to communicate how your past experience is relevant and valuable to the company by:

• Researching your target company’s core values or leadership principles.

• Identifying the best case studies from your past experience that best demonstrate each core value.

• Prepping talking points for each of your career case studies.

• Prepping for specific questions about each company core value, including the cast study and question-specific talking points you want to cover in your answer.

Grab and copy my Interview Prep Template which has full instructions on the first page. Drop comments on the template if you have suggestions for ways to improve it!

If you follow this interview prep method, you’ll be more prepared. You’ll also feel more prepared and less anxious when interview day comes. Even if you don’t get asked the exact questions you prepped for, this method enables you to recall and communicate a great answer quickly and crisply.

The second part of company-specific interview prep involves a range of research and analysis specific to the company’s products, services, or position in the market. I’ll save that for a future post.

Good luck on your job search and your interview! I’m rooting for you. :)

P.S. Dont’s

Here’s a quick checklist of what not to do when going out and getting your next job:

• Don’t lie. Emphasize things in your experience and draw attention to the good stuff, but don’t say anything that’s objectively false in your highlight reel, résumé, or interview. If your job title was program manager, don’t say you were a product manager. As a hiring manager, if I find out a candidate has lied about their experience it’s a deal-breaker. If they were willing to lie to get a job, they’ll lie once they get the job.

• Don’t play hard to get. If you’re reaching out to someone because you want a job at their company or want them to connect you with someone in their network, just say so. Don’t beat around the bush or try to get them to make the first move. Get to the point.

• Don’t make your network do more work than they have to. Do as much as possible to make it easy for your network or the person you reach out to to help you. Make your email and the highlight reel something they can simply forward rather than writing from scratch. Send them links to the jobs at their company you want. Don’t expect them to scour their brain or their company’s job site and figure out what’s a fit.

• Don’t apply directly via company’s job site without using your network first. See above, just repeating since it happens so often.

• Don’t lie. Repeating again since I also see this happen often.

"Sales grew at a rapid pace in Q2."

or

"Sales in Q2 were $12.5M, an increase of $2M (19%) over Q1 and $4.5M (56%) over Q2 of the previous year."

Also, get in the habit of providing absolute values as well as percentages. Don't make the reader whip out the calculator app on their iPhone and figure it out for themselves. Finally, if you're communicating the change in a percentage value (e.g. conversion, attrition), give the change in basis points (bps), not another percentage.

"Gross margin grew by 10 bps, from 3.2% in Q1 to 3.3% in Q2."

is easier to parse than:

"Gross margin grew by 3.1.%, from 3.2% in Q1 to 3.3% in Q2."

10. Use TK's for Flow
While you're writing the doc, don't stop to dig into your Excel spreadsheet or plow through your email archive to find that specific number you need. Use "TK" (short for "to come") in place of the number, or highlight it, or add a comment to the doc and fill it in later. If you're on a roll and in the flow state writing the doc the last thing you want to do is context switch. Exception: If the value should impact the outline or the story you're trying to tell in the doc then find it out ahead of time.

11. Avoid Weasel Words
Replace "may", "might", "plan to", "possibly", "close to" with words like "will" or other replacements that add accountability. Which statement builds confidence more?

"We expect to complete project X early in the year, which may generate hundreds of thousands of new customers."

or

"Project X will be completed in April and generate 340K new customers through the end of 2010."

12. Review for Inconsistencies
After you've written the doc, review it for inconsistencies. Did you say that your themes for the year were going to be improving the product and then ramping up customer acquisition, but your roadmap has the big SEM spend at the beginning of the year and your hard-core prod dev work at the end? Do you say that fixing UX potholes is a priority for the year but have no specific projects or resources allocated to this area? Finding the inconsistencies in a doc is a skill that comes with experience. The people reviewing your doc probably have that experience.

13. Double-check Numbers
Explicitly double-check all the numbers in your doc again, backwards and forwards. Recalculate absolutes and percentages in both directions. Cross-check them against a different set of values. If your doc states that your cost for customer acquisition is $5 and you plan to add 100K new customers next quarter, does your financial forecast later in the doc have a line item of $500K for customer acquisition? If not, explain why the numbers don't add up or fix them.

Factual errors and wrong numbers in a doc can completely erode confidence in the doc and its author. People remember them.

14. Proofread for Spelling and Grammar
Duh. These make you look stupid and/or lazy. If your doc is littered with misspellings then it gives the impression you didn't put a lot of thought or effort into the doc, which can also erode confidence.

15. Put Details in the Appendix
Don't add a ton of graphs, charts, source data, or explanations to the main document body. Put the key stuff in the main doc and the supporting data in the appendix. If you find yourself putting content in the main body that changes the rhythm of the doc, then ask yourself if it is really necessary to achieve the doc's goal. If not, appendix.

16. Find a Friendly Reviewer
It's not cheating to have one or more people review your doc before prime time. Find someone who is really good at writing docs (especially for your intended audience) and ask them if they wouldn't mind reviewing your doc. Make sure to give them adequate time to review it (at least 3 days). Don't send them a half-baked doc. Don't have them review it multiple times. Don't ask them to keep reviewing your docs if you haven't incorporated feedback from their previous reviews. If you pick the right person, then the pre-review can flush out key questions you didn't answer and inconsistencies that you're too close to see.


I hope these 16 tips are useful. Did I miss any?

Creating useful goals requires identifying the right metric, setting a goal value that is appropriate, and drafting the goal in a format that is clear and can be objectively evaluated. This process is pretty straightforward once you get some goal-setting experience under your belt, but it’s not that intuitive.

In this post, assembled my key learnings about goal formats, goal types, example goals, and goal-related best practices. My goal is to provide a resource that someone new to goal setting could use to create a solid set of goals for the first time. Here goes…

Goal Format

Before you start writing specific goals, decide on a goal format. My favorite format is the SMART goal. It works in 95% of circumstances and should work for you. SMART stands for Specific, Measurable, Achievable, Relevant, and Time-Bound. There are a ton of resources about SMART goals on the web, so I won’t repeat them here.

These are some SMART goal templates that I continually reuse and teach:
(note: Italicized terms including “TK” are placeholders)

• Increase [metric name] by TK%, from TK in [previous time period] to TK in [goal time period]

• Increase [metric name] by TK bps, from TK% in [previous time period] to TK% in [goal time period]

  • bps stands for basis points. There are 100 basis points in each percentage point. When you compare two percentages, use basis points instead of another percentage to avoid ambiguity.

• Launch [product name] to [deployment stage] in [region(s)] by [date]

  • Stage could be “live in production at 100%” or “to all customers”, or something short of that such as “in beta” or “in experiment to at least 10% of customers”

  • Region could be WW (worldwide), specific regions (e.g. NA - North America), countries, cities, or zip codes.

I’ve listed the launch goal template last because it’s my least favorite. They’re appropriate for a major product or a key initiative (e.g. launching a marketplace, launching in a new country), but they’re too prescriptive for many other circumstances and provide no value measuring the actual outcome you’re trying to achieve with a launch. You shouldn’t claim success launching a feature by a certain date. Set a metric-based goal on the impact the feature is supposed to achieve. Metric-based goals are durable and give you the flexibility to meet a goal in different ways including launching a different feature or simply fixing something that is broken.

Goal Types and Examples

Topline/Scale Goals. These are the headline goals that measure your product’s impact on the overall business, and the overall scale of your product They can either be in absolute terms, or you can measure a KPI for a sub-segment of a business as a % of the overall business.

• Increase Revenue by 35%, from $10MM in FY 2021 to $13.5MM in FY 2022

• Increase Gross Margin by 40 bps, from 27.1% in Q2 2022 to 27.5% in Q3 2022

• Increase ProductX % of Overall Revenue by 460 bps, from 35.4% in FY 2021 to 40% in FY 2022

• Increase Gross Bookings by 22%, from $50MM for TTM ending Q2 2021 to $61MM for TTM ending Q2 2022

• Increase 12-month Active Customers by 18%, from 30MM at the end of 2021 to 35.4MM at the end of 2022

Health Goals. These are measures of well your business or product is working, and key inputs or levers that generate the impact shown by the topline goals above.

• Increase New Customer Conversion Rate by 80 bps, from 3.2% in FY 2021 to 4% in FY 2022

• Reduce 3-month Customer Churn Rate by 150 bps, from 18.5% in Q2 2022 to 17% in Q3 2022

• Increase Average Order Value by 15%, from $132.00 in Q2 2022 to $151.80 in Q3 2022

• Increase Percentage of Products with At Least One Customer Video by 1,000 bps, from 40% at the end of Q2 2022 to 50% at the end of Q3 2022

Customer Experience Goals. Conversion and scale metrics cover some of the positive measures of a good customer experience. You can supplement with goals in other inputs into a positive customer experience. It’s also helpful to measure the frequency or degree of things that negatively impact customers.

• Increase Customer Support Contact Satisfaction Rate by 800 bps, from 70% in Q1 2022 to 78% in Q2 2022

• Increase Average Star Rating by 8.1%, from 3.7 in FY 2021 to 4.0 in FY 2022

• Decrease 30-day Return Rate by 30 bps, from 6.7% in Q2 2022 to 6.4% in Q3 2022

• Decrease Customer Contacts per Order by 60 bps, from 4.2% in Q1 2022 to 3.6% in Q3 2022

• Decrease Late Delivery Rate by 220 bps, from 9.5% in Q4 2021 to 7.3% in Q4 2022

Growth/Marketing. There are many ways to evaluate the effectiveness of growth/marketing efforts. This is a sampling of goals that measure growth inputs, efficiency, and outputs.

• Decrease Marketing Expense as Percentage of Revenue by 250 bps, from 8.2% in FY 2021 to 6.7% in FY 2022

• Increase Direct Traffic Percentage of Weekly Visitors by 600 bps, from 18% in Q2 2022 to 24% in Q3 2022

• Increase Average Weekly Unique Visitors by 20%, from 35K in Q2 2022 to 42K in Q3 2022

• Decrease Customer Acquisition Cost (CAC) by 33% from $60 in FY 2021 to $50 in FY 2022

• Increase 12-Month Customer Long-Term Value (LTV) by 30%, from $200 in FY 2021 to $260 in FY 2022

• Increase 90-Day Free Trial to Paid Conversion Rate by 1,000 bps, from 60% in Q2 2022 to 70% in Q3 2022

Technical Goals. These are a few technical goals that have a direct impact on the customer experience. The three at bottom are key components of Google’s Core Web Vitals. “at tp75” means that 75% or more of page loads achieve the goal.

• Decrease Fatals as a Percentage of Page Loads by 10 bps, from 0.82% in Q2 2022 to 0.72% in Q3 2022

• Decrease Largest Contentful Paint (LCP) at tp75 by 10.7%, from 2,800 msec in Q2 2022 to 2,500 in Q3 2022

• Decrease First Input Delay (FID) at tp75 by 42%, from 142 msec in Q2 2022 to 100 msec in Q3 2022

• Decrease Cumulative Layout Shift (CLS) at tp75 by 20%, from 0.12 in Q2 2022 to 0.1 in Q3 2022

Goal Best Practices and Gotchas

Setting a goal on a brand new metric. If you’ve never managed to a metric over a period of time you don’t understand its sensitivity or how easy it is to move it. The newer the metric and the more complex it is, the greater the risk you’re going to have “the reddest of red” goals come evaluation time, as Amazon SVP Diego Piacentini once remarked about a goal I set on a new metric I didn’t fully understand. Lesson learned.

Understand your metric’s headwinds or tailwinds. Many metrics may have headwinds or tailwinds external to your company or within your company but external to your product. Before you set a goal value, dive deep on the metric and try to understand any factors (macro trends in customer behavior, changes to home page real estate to support another product, navigation changes, pricing changes) that had a meaningful impact on it during the previous period or may in the goal period. Estimate that impact and then set the goal value accordingly and be prepared to explain the difference between the organic value and the incremental impact you’re signing up for.

Reference the prior value. Don’t make people guess or do math. A goal like “Reach 1MM active users by the end of 2022” doesn’t give any indication of where you’re starting from or what impact you had. Make it easy on them to see the impact by providing the previous value as well as the difference between the previous and goal value.

Be precise about dates and time periods. It’s okay to use an end of period value (e.g. “by the end of 2022”) for metrics that are monotonically increasing or decreasing. A better practice is usually to use a metric that is averaged/weighted over the entire goal period.

Avoid QoQ/MoM for metrics with seasonality. Many metrics are impacted by seasonal factors Those patterns are easy to see in any e-commerce business by day of week and especially due to spikes around individual holidays and the Nov-Dec period. For any metric that has seasonality a quarter-over-quarter (QoQ) or month-over-month (MoM) comparison may tell the wrong story because you can’t tell the difference between impact of seasonal headwinds or tailwinds from the incremental impact you and your team achieved.

Keep metrics stable. If you change the definition of a metric during the goal period and use it only for the goal period value, you invalidate the goal and may lose trust when the change is found out. Your options are to (a) continue to use the original metric definition when evaluating the goal, or (b) restate the prior and goal values using the new metric definition. Beware though, (b) often makes the goal harder or easier to achieve. Call it out if it made it easier so you don’t get called out.

Don’t compare time periods of different lengths. It’s okay to compare time periods that are of slightly different lengths (e.g. 31-day months against 30-day months), but don’t confuse people by comparing significantly different time periods (e.g. comparing Q3 vs. Jan-June).

I hope these examples and tips are helpful to you. Drop a comment about any best practices I missed!

Over the last few months, I’ve had dozens of mentoring conversations with junior product managers, senior PM’s, and product leaders. They are all working hard to have an impact in their day job, but in parallel many are thinking about a job change. It’s not a topic they can talk about freely at work, so they ask for my advice about how to think about a change and how to avoid making the wrong one. This is the framework I share with them, a framework I’ve forged from my own missteps and successes.

1. Don’t jump at the first company that tries to recruit you

There are many triggers for a job change, but a common one is simply that another interesting company reached out and showed interest in you. It’s flattering. Talk to them and be open to a conversation with a recruiter or hiring manager, but don’t put on the blinders and don’t plunge full speed ahead with that company without going through the other steps of this framework.

The risk of going too far, too fast with one company is you may get an offer before you’ve had the chance to explore other companies and get a sense for what’s out there. You’re faced with the tough choice of either accepting a potentially sub-optimal offer at a sub-optimal company vs. missing out on what might be the right opportunity because you want more time to play the field.

Slow your roll and leave time for other companies to catch up. Your best outcome, and best negotiating position, will come from having multiple compelling opportunities you can evaluate at the same time. Note: I am not advocating for a shotgun approach where you interview with a bunch of companies at the same time purely to get competing offers you can leverage against each other.

2. Decide what you’re optimizing for

For a moment, forget about the company that reached out and the industry they’re in. Put them out of your mind. Ask yourself, “What do I want to optimize for in my next job?” Write down a ranked, numbered list of what is most important for you in your next job - maybe the top 3-5 things. Doing this narrows down the decision space and makes evaluating companies and opportunities much easier.

If the company recruiting you or the role they’re recruiting you for doesn’t meet your #1 criteria, it’s not the right place. If it only partially meets your #1 criteria, you need to try to find a job that meets it fully and best. If you join a company that doesn’t meet the top criteria you’re optimizing for, you only have yourself to blame.

These are some of the things you may be optimizing for, and ways to evaluate whether a company might meet them.

Learning PM Skills. This is a GREAT thing to optimize for if you’re a junior PM early in your career, or if you’ve been a PM for years but never worked for or with PM’s you’d consider great role models. Reading blog posts, joining Lenny’s Community, and watching Gib’s talks should all be mandatory for PM’s, but they’re no substitute for working with and for great PM’s and seeing how they operate first-hand.

Here, the advantage goes to working for a larger organization (e.g. Amazon, Meta, Google) with many PM’s. These companies are crucibles that forged the PM leaders that advanced within them. At a big tech company you can learn from PM’s around you, see which PM leaders are the strongest, and look for opportunities to work and learn directly from them. Having a top big company name on your resume also gives you a tailwind when you go to make your next move.

You may learn good PM skills at a small company, but you’ll be learning primarily by doing and your learnings will primarily be from your own work. You won’t get the development and you won’t get the benefit of learning from many other PM’s at a larger company.

Working Directly with Software Engineers. If you don’t work directly with software engineers, the single biggest thing you can do to make yourself a more valuable product manager is take a role that embeds you with engineers. A builder role. Scratch and claw to find this, and once you have it, be wary of moving into a role without it unless you’re doing so intentionally to round out other aspects of your product experience…

Rounding Out Your Product Experience. I’ve spent 22 years in the e-commerce space and been somewhat intentional in my path. I started as a software engineer at a startup that got squashed by the dot-com boom, moved into e-commerce and started to get some product and management experience at a mid-sized company, moved into a PM role at Microsoft, and levered that up to the GM-type role that started my 12-years at Amazon. At Amazon, I led organizations in retail customer experience/conversion, social, direct traffic/loyalty (AmazonSmile), devices (leading Alexa International), and finally in Operations where bits meet bytes.

When I talk to companies now, either about full-time exec roles or consulting work, there is no customer-facing aspect of e-commerce that I don’t have direct leadership experience in or at least strong working knowledge of. This is no accident. I have more inroads into a target company than someone who is typecast because they’ve spent 10-15 years working on the same thing. You can figure out what domain experience could make you more well-rounded and more valuable, and go get it.

Breaking Into an Industry. Targeting a specific industry and charting a path to break into it is a mature thing to optimize for. A different industry may be growing faster, align with your passions better, pay better, or serve other career goals. If you can’t join the top company in an industry right away, play the long game and join a tier-2 company in that industry, then gain the domain experience that you can use to ladder up to a tier-1 company next.

Product Wins. Banking a big product win feels great. What’s even better about a win you can put your name on is all the other opportunities it can open up for you. There’s a HUGE difference between saying “I worked on X” vs. saying “I created X from nothing” or, even better, “I came up with the idea for X, built out the team, launched it, scaled it, and had XX large impact for the company!”

Choosing your next job to optimize for a big product win is 100% valid, but tricky. Here, the advantage goes to smaller companies. At a very small startup you’ll have the ownership to lay claim to the win - if it happens - but there is inherent risk in the company itself and the scale of any win may not be that impressive to larger companies.

A medium-sized company can be a good place to bank product wins. They have the size and scale to provide some security and may have some name recognition. Just make sure that you are in a role that can create and lay claim to a win (e.g. Product Lead for X, PM owner for X). At a large company, you’re more likely to be layered and own a part of X, until you move to more senior roles and get a chance to lead/own a product.

Management Experience. Moving from an individual contributor (IC) PM at one company into a management role at another may seem like a great jump to make, but it’s a risky one. You have to learn how to operate at a new company, how your product works, and how to be a manager all at the same time, while earning trust with your team and figuring out how to hire.

You want to have some amount of stretch in any new role, but too much increases the risk that you’re not successful and have to bounce out quickly. Large companies may offer developmental support for new managers. At small companies it’s sink or swim.

Team Size. If you already manage PM’s, then it’s valid to want to manage the same number or more PM’s at your next role, and to try to level up your team size. Smaller, well-funded companies can grow quickly, and give the opportunity to manage more people even if you don’t start with many or any. At large companies, teams don’t always grow rapidly, but if you’re successful you’ll get the opportunity to take on additional scope and grow your team or org size that way. Team size shouldn’t be the #1 thing you optimize for, but it may be #2 or #3, or serve as a tiebreaker.

Compensation. This is on everyone’s list. It makes a good tiebreaker, but hopefully isn’t the thing you optimize for above all else. Large, public companies will always offer more near-term comp - useful when you want to buy cars, get a mortgage, or take vacations now. A small percentage of startups will make you f-you money over the long term, a meaningful percentage will net out even or significantly positive over the long term, and a similar percentage will leave you out of the money with options that are worth nothing. Is it more important to take nice vacations, or maybe buy a vacation house?

Good Boss or Team. If you’ve never worked with your prospective boss, you don’t really have any way to know how good they actually are. It’s a crapshoot. If you have, don’t bank on working for them long-term. They may leave the company or change roles, or you might get layered under someone else. Working for someone you know and respect and admire is a plus but be wary of optimizing for it alone.

More Senior Title. This is one of the worst things to optimize for in a job change, but also one of the most frequent. Don’t make it your #1.

3. Ask yourself, “How could this job change turn out to be wrong?”

As you walk down the path with one or more companies, they’re selling you, and you’re drinking the Kool-Aid. It’s fun to dream about dominating an industry, running a big team, and having options worth millions. Pause. Reset. Ask yourself, “How could this job change turn out to be the wrong one?” Write down a list of things that, if they turned out to be true, could make this the wrong choice. For some, you have no way to know, but for many, you can do research or ask questions of your prospective new boss now to de-risk them. Here are a few.

You Don’t Have Access to Engineers. To be a great product manager you need to ship, learn, and repeat many times. If you don’t have consistent access to engineers, you can’t ship and learn. Ask how engineers are allocated on your new team and how many will be dedicated to the product area you own. Answers: “None yet, but …” = red flag. “1-2” = red flag as you’ll be under-utilized, and your impact will be limited. “X on the team, shared by you and 2 other product managers” = yellow flag as your projects might be lower priority and keep getting bumped. “2 butts in seat, with 2 open headcount” = yellow flag as those heads may disappear. “4+ butts in seats dedicated to the product you won” = green flag.

The Role is Program Management, not Product Management. Many companies and hiring manager don’t know the difference. Product is the "what” and the “why”. Program is the “how” and the “when”. Product builds. Program runs and keeps multiple teams connected. Product manager is a sexier title and at companies that have both role types, tends to pay better. Hiring managers have an incentive to call a role product manager because that title is more attractive to candidates, especially those in program who would love to switch to product. Unless you’re intentionally trying to gain program management experience, do everything possible to ensure your shiny new product management role isn’t really program. Scrutinize the list of job responsibilities. If the role entails a lot of glue connecting different teams, is heavily focused on repetitive processes (status reports, sync meetings, running sprints), or doesn’t have access to engineers (i.e. builders), then it’s probably program.

You Don’t Actually Get to Manage PM’s. You’re an IC at your current company and been promised the opportunity to lead other PM’s at the new company. Ask how many PM’s will report to you on day one. Answers: “None…” = red flag. “None, but the role has open headcount” = yellow flag. “1” = yellow flag because any type of re-org could leave you with none. “2+” = green flag.

Your Team is Smaller than Promised. You’re a PM manager who’s been promised a team of X size. Ask how many butts in seats (BIS) are there now. Answers: “None” = bright red flag. “<50% of X” = red flag. “50%-80% of X” = yellow flag. “80%+ of X” = green flag.

You Don’t Get to Work for that Specific Boss. Your great, former boss at company X recruited you to new company Y, then recruited you. What happens if that boss leaves the new company three months after you join? If that would suck, then maybe it’s the wrong move. Don’t let your decision be guided by or your success depend on riding a specific person’s coattails. It should meet your other criteria and that’s just a perk. If you get a year working for that great boss at the new company, consider yourself lucky.

You Don’t Get to Own that Special Project. You’ve been told you’ll be the lead for a cool project at the new company. It’s going to be your big product win. Ask how committed the company is to that initiative and listen for signs of its importance (e.g. “X engineers moved onto it”, “related to one of the companies top 3 priorities this year”). If you’re not convinced, be aware that it might get cut or deprioritized. Ask if you will be the sole product owner. If the answer indicates that other PM’s are working on the project, then you’re not the owner. Ask if you may end up being layered under a more senior PM or manager? A firm, “No” means that’s unlikely to happen in the next year, giving you time to prove yourself and earn the role. Anything less means you may not get the chance.

Your New Company Gets Squashed. I was a software engineer back in 2000 and saw the entire dot-com industry get squashed. There was no avoiding it. Today, tech is too big to get squashed as a whole, but big companies are freezing hiring, medium companies are doing layoffs, and there’s going to be a steady drumbeat of down rounds, acqui-hires, and companies closing up shop over the summer and fall. For startups, ask your prospective boss how much runway the company has and then divide that in half, because their current calculation is based on positive revenue growth which may not happen. Ask yourself, “If this company has to layoff 25% of staff next month, would I be one of the first to go?” For big companies, get the offer in writing and signed. Don’t tell your colleagues or your boss about the new job based on an agreed to verbal offer.

Your Comp Doesn’t Grow as Promised. Make the decision based on the comp in the offer letter, without giving much weight to bonus plans based on company goals or targets. They’ll tell you that X%+ of the bonus has been paid out in each of the last four years. It probably won’t this year. They’ll tell you that your comp is likely to go up and hit your target range next year. Don’t bank on it. Try to negotiate for it now because your leverage disappears once you join.

You need to fill in the blanks for other reasons the job change might turn out to be wrong. Do the work, then ask the hard questions. Weigh the risks and either pass or take the new job with open eyes.

If you liked this post, please share it and make sure to subscribe to my free Day 1 Product Management Newsletter.

Share

Subscribe now

Ten years ago, almost to the day, I wrote an answer to the question above on Quora. Since then, it has been viewed almost half a million times. To this day, many product managers know me either from that post, or another on Working Backwards, Amazon’s product development process.

Back in 2012, I’d managed a handful of product managers at Amazon. Since then, I’ve managed almost a hundred product managers at Amazon, Airbnb, and startups as well as senior managers and directors of product management. My sample size has grown. Now seems like a good time to think about what I may have missed or got wrong ten years ago and refresh my Top 1% product manager post.

These are the competencies in my original post - the ones that top 10% product managers excel at a few of and top 1% most or all. I’ve added some additional commentary in square brackets.

• Think big - A 1% PM's thinking won't be constrained by the resources available to them today or today's market environment. They'll describe large disruptive opportunities, and develop concrete plans for how to take advantage of them. [They’ll avoid chasing after small opportunities, recognizing they need to hunt for bigger elephants.]

• Communicate - A 1% PM can make a case that is impossible to refute or ignore. They'll use data appropriately, when available, but they'll also tap into other biases, beliefs, and triggers that can convince the powers that be to part with headcount, money, or other resources and then get out of the way.

• Simplify - A 1% PM knows how to get 80% of the value out of any feature or project with 20% of the effort. They do so repeatedly, launching more and achieving compounding effects for the product or business. [They can recognize when designers or engineers are trying to build more than is necessary, and persuade them to simplify also.]

• Prioritize - A 1% PM knows how to sequence projects. They balance quick wins vs. platform investments appropriately. They balance offense and defense projects appropriately. Offense projects are ones that grow the business. Defense projects are ones that protect and remove drag on the business (operations, reducing technical debt, fixing bugs, etc.).

• Forecast and measure - A 1% PM is able to forecast the approximate benefit of a project, and can do so efficiently by applying past experience and leveraging comparable benchmarks. They also measure benefit once projects are launched, and factor those learnings into their future prioritization and forecasts. [They know that key metrics are part of the P0 product requirements, not an afterthought that can be gradually added after launch.]

• Execute - A 1% PM grinds it out. They do whatever is necessary to ship. They recognize no specific bounds to the scope of their role. As necessary, they recruit, they produce buttons, they do bizdev, they escalate, they tussle with internal counsel, they *. [They are the master of the last mile, and don’t lose steam after a project gets approved and underway.]

• Understand technical trade-offs - A 1% PM does not need to have a CS degree. They do need to be able to roughly understand the technical complexity of the features they put on the backlog, without any costing input from devs. They should partner with devs to make the right technical trade-offs (i.e. compromise).

• Understand good design - A 1% PM doesn't have to be a designer, but they should appreciate great design and be able to distinguish it from good design. They should also be able to articulate the difference to their design counterparts, or at least articulate directions to pursue to go from good to great.

• Write effective copy - A 1% PM should be able to write concise copy that gets the job done. They should understand that each additional word they write dilutes the value of the previous ones. They should spend time and energy trying to find the perfect words for key copy (button labels, nav, calls-to-action, etc.), not just words that will suffice.

Looking at these, I’m still pretty satisfied. They stand the test of time. I did miss out on a few though. Below are some additional competencies I’ve come to respect and recognize the importance of over the last decade:

• Earn trust - A 1% PM understands people, and that the way to earn trust with one person may be completely different than for another. They figure out what makes an executive, peer, or important stakeholder tick and what their third rails are. They do what is necessary to earn each person’s trust and turn them into an ally, instead of just a colleague.

• Dig for data - A 1% PM figures out the data they need, and goes and gets it. They don’t file a ticket and wait weeks or months for a BIE or analyst to produce it. Along with customer insights, data is the lifeblood of a 1% PM and they let nothing get in the way of getting the data they need to make the optimal decision.

• Push back effectively - A 10% PM knows how to push back. A 1% PM knows how to push back and win, especially when they’re pushing back on someone whose opinion carries much more weight than their own. Winning requires putting more effort into their case, getting the right data that will be persuasive, and finding the right pressure points to open back up a decision and get it pointed the other way.

• Adapt to change - A 1% PM isn’t destabilized by every change in leadership, strategy, resources, or every decision that doesn’t go their way. They don’t waste energy or get caught up in the drama. They assess how the change impacts them or their product, adapt, and get back to work.

• Driven by impact, not promotion - A 1% PM wakes up each day thinking about how to maximize their impact for the good of the product and the company. Promotion isn’t the fuel that powers them and guides their decisions every day. They don’t do things “for visibility”. Their impact ends up generating the visibility and leads to promotion.

What competencies did I miss? I’ll have to fold those into another refresh in 2032.

If you liked this post, please share it on your socials and subscribe to the Day 1 Product Management newsletter so you don’t miss future posts.

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.

On data, dates, and deliverables

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.