Slaying Churn Monsters: 5 ways to reduce churn better than an exit survey

How is churn at your company? How has COVID affected your churn rate?

If you’re like most of the companies and leaders I’ve been talking to *everyone* is feeling it. The only question is how much:

  • The great companies struck oil when COVID hit. Those that help companies transition to remote, support the fight vs. COVID, or do video conferencing are thriving. They’re not reading this post anyways.
  • The good companies are fortunate to be in healthy markets and they’re approaching 70-80% of their original sales targets. Churn is up a bit, but not life-threatening.
  • The struggling companies are in markets where some of their customers were crushed, while others continued along. They’ve seen a spike in churn, deals take longer to close, and pipelines are significantly reduced.
  • The dying companies are in markets that have been crippled by COVID/lockdown. Good luck selling software to sports leagues, travel, in-person entertainment, and hotel industries.

Unfortunately, if your entire customer base evaporated, because the industry no longer exists, there are no churn tactics that will save you. You either hold your breath, hoping to survive until recovery and reopening of the industry you serve, or you have to pivot your business in some major way.

For the rest of us in the middle feeling the sting of churn, and still with chips in the game, today’s post is to show you some of my favorite tactics I’ve learned over the last decade working on SaaS businesses. While there are no silver bullets, there are quite a few things you can do that together add up to make a difference.

churn is a leaky bucket for your business5 Ways to Reduce Churn Better than an Exit Survey

A common behavior I see in SaaS products is to have a multiple choice survey when they cancel. This helps you quantify what was the straw that broke the camel’s back.

But does that tell the full story? No, it does not.

A lesson in the hidden truth of churn

When I ran product at KISSmetrics back in 2013, over a few months our churn started spiking, from the healthy, 3-5% range to suddenly approaching and exceeding 10%.

This was obviously alarming, so we put our attention on trying to figure out why.

The first place we looked was at our cancellation survey that popped up when you clicked to cancel inside our product’s account settings.

churn cancel survey example

An example of a churn survey

Unfortunately, this information didn’t really tell us much. In fact, the data we had was pretty evenly distributed across a number of the many options we presented.

It helped us narrow down the causes, but it didn’t come close to giving us the full picture.

Unfortunately, people cancel long after the initial warning signs occur. Often, the survey answer you get is merely the straw that broke the camel’s back, or a quick rationalize after they’ve already decided to quit.

It wasn’t until I applied the below tactics that we found the real, root cause. I’ve also used these same lessons since to help my own startups and those of some of my friends and mentees significantly reduce churn.

customer support is a huge way to reduce churn

1) Check with your Customer Support / Success Team (or help out!)

I am always amazed by the number of SaaS product managers and founders that don’t interact with their customer support teams or help out with support tickets.

As this great Tweetstorm from Podia founder, Spencer Fry, reminds us, it’s a HUGE part of retention and customer happiness.

Customer Success interactions and support tickets are a GOLD MINE for product teams. It can answer essential questions like:

  • Friction: Where are people getting stuck and confused in the product?
  • Bugs: What bugs keep happening and bothering customers most?
  • Requests: What are customers asking for either explicitly at the start of a support ticket, or during an ongoing conversation?

These are great any time, but especially if you’re fighting churn, you can work together to determine:

  • What support tickets were recently sent by customers who churned this week?
  • What tickets did they seem to push most urgently about or have a high degree of frustration regarding?
  • Did they make the same requests repeatedly? What were they?

This kind of information helps you see where there may have been points of frustration in the past that contributed to them leaving. If you really frustrated me, your support team is likely to take the brunt of that, too.

Their friendliness may win me over and resolve the problem, but if that issue made me look bad to my boss, made a report late, or caused me to start a work-around that makes me less dependent on your software…the clock is now ticking on churning from your product.

2) Do a set of Jobs to Be Done Interviews

Many people have learned about jobs to be done over the last few years. Whether you love the milk shake example from the Clayton Christensen’s talk above, or the proverbial “I want to hang a picture, not put a 3/4 inch hole in the wall” story, you realize that people hire products to accomplish something, not for “features.”

What many fewer people know is you can use this same process to fight churn.

apply jobs to be done to churn too

If you’re not familiar with Jobs to Be Done start here.

Jobs to be done is packed with insights for product teams

The big insight of jobs to be done isn’t just what I’m hiring your product to help me do. It’s also the above timeline to help you understand their journey from “passively looking” to “deciding” to “finished.”

There’s a tremendous amount you can learn as a product manager or founder doing these interviews with new customers (paid you for the first time in the last 45 days).

This can inform your marketing, copywriting, onboarding, and positioning throughout.

It can also help you with churn.

Flip the script. Create a churn timeline.

Just like there is a timeline for buying, there’s a timeline for your customer deciding to cancel.

Mapping it to the above timeline, here’s how it looked when I did this for a KISSmetrics customer all those years ago:

  • First thought: Over lunch, a director of marketing tried to run a report to check a number. It took about 10 minutes for it to complete. It was annoying, but they brushed it off.
  • Actively looking: A month or so later, the marketer tried to run a report when they first got into the office in the morning. Again the report hung. They left the browser open hoping it would finish later. It was still not complete when they left work that day.
  • Deciding: Unable to get a report they needed, and complaining in the middle of the office, a coworker suggested they try another system that had always worked for them. The marketer listened and started trying another product to see if they could get the numbers they needed.
  • Consuming: The alternative product offered them a strong discount, which then made canceling a no-brainer. Meanwhile, our cancel survey for this user cited price, which was only part of the picture.

As it turned out, in this interview, and many others like it, the key cause for our churn was performance related. It’s little surprise that around that time Mixpanel started running brutal adwords against us:

mixpanel vs kissmetrics adwords

Understanding the timeline of your user’s journey to canceling can make all the difference in preventing churn. Jobs to be done is the single best way I know to do it.

You can learn how to do these in my in depth post on jobs to be done interviews here.

cohort analysis can help fight churn

3) Dig into your product analytics

Great product managers know that to truly understand your product requires both qualitative and quantitative data. You need to understand the stories of your customers (qualitative data) and you need to understand the size and scope of things happening (quantitative data).

This of course applies to understanding churn as much as anything else. Look at your churned customers’ product usage and ask questions like:

  • What features were they using vs not, or stopped using?
  • What features are customers with a high retention rate using that those churning are not?
  • Are your customers making it past 90 days of successfully using your product, or are many of your churns happening shortly after subscribing?

Understanding what they couldn’t get done with your product, or never learned to use can be telling. Every company’s churn problems are a little different.

Personally, I would recommend you start with the Jobs To Be Done interviews, so you have a baseline of stories of what’s going wrong for your customers. From there, you can use analytics to tell you:

  • How big and common are the problems I heard in my interviews?
  • Which of the problems is likely to have the biggest impact?

Having a mix of qualitative and quantitative information about what’s happening with churn will help you not only better understand why it’s happening, but also prioritize the many solutions you think could help.

How effective is your analytics setup? Please take 2 minutes to fill out this quick survey and I’ll share the results with participants.

fighting churn in COVID

We made this addition to our help doc on how to cancel when COVID hit

4) Make COVID specific offers

These are unusual times and budgets are tough. Even the most loyal of customers have to cut products that are not life-or-death essential for them when they’re also having to cut staff.

The best thing you can do then is to think long term. Ask yourself how you can create win-win opportunities and build a long term relationship with your customers.

If you help them out in a tough time, they’ll be there for you for the long haul. Never underestimate the loyalty of a customer you went above and beyond for.

So how do you do that? Well, if you’re a product manager, you’ll likely need to get other departments and leadership involved to make any of these calls, but here’s a few for starters that many companies have already implemented:

  • A few months free: Especially if you’re a business that does “land + expand,” the last thing you want to do is lose your “land.” Give your struggling customers a brief reprieve, especially if they are high value or high potential.
  • Discounts for Case Studies: Case studies and testimonials give your company more credibility in a market. Use our present circumstances to ask more companies and customers for testimonials and case studies in exchange for flexibility on pricing and terms.
  • Pause accounts: Rather than immediately deleting data when people cancel, agree to pause their access and to check in at a pre-determined future date to reactivate them.

Whatever you offer, make sure you listen to your customers; they may have questions or concerns about some of your offers, which can help you either provide something different and better they prefer, or clarify your offers to avoid objections.

Remember: it’s easier to get an existing customer to spend more money in the future than it is to acquire a brand new customer. Anything you can do creatively to create win-win scenarios and keep your existing customers around is going to pay dividends for you and your company.

5) Think about Olsen’s Hierarchy of Product Needs

Dan Olsen is one of the original Silicon Valley Product Leaders. He was VP of Product at Facebook predecessor Friendster, and has since become a long time advisor and consultant on all things product management.

One of the great concepts I’ve heard him speak about is translating Maslow’s Hierarchy of Needs  (see picture above) into a version for software products:

Much like Maslow’s hierarchy, Olsen’s hierarchy starts at the bottom and subsequent steps in the pyramid only matter if the ones below are taken care of.

Applying this to churn you can imagine:

  • Uptime: If your product is down (or a key API from a 3rd party), your customers cannot use your product and will churn because they can’t accomplish what they set out to.
  • Page Load Time: If your product is too slow, you’ll frustrate your customer as I learned the hard way at KISSmetrics.
  • Absence of Bugs: When things don’t work as expected, or inconsistently, again you’ll frustrate your customers, which makes them reduce how often they use your product, or stop using it altogether.
  • Features: Are your customers able to accomplish what they set out to do with your product? Whether they don’t know how, need advanced functionality, want a complimentary feature to justify the budget for you, or require a specific integration, listen carefully to them.
  • Usability: If people struggle to find the things they need to do in your product, or don’t understand how to use it, they won’t stick around long term.

If you’ve been doing the early tactics I’ve written today of interviewing customers, talking to customer success, and looking at your product analytics, you should start to see some patterns in where on the hierarchy your company’s biggest problems are.

Then, in addition to mapping and grouping your problems, look to the hierarchy as a guide to the priority of the fixes and improvements you will make.

If your product is bug-filled, slow, or has significant uptime issues, then no amount of usability improvements or feature additions will matter. It starts with a strong foundation.

fight churn with lead bullets

BONUS: More lead bullets for churn

The 5 recommendations above are how to address big churn issues and make a real dent in the problem long term.

While you dig into the hard work of applying the above tactics, here are some quick hacks that can help you and your company with smaller needle movements on your churn rate:

  • Set up Good Dunning Resolution: Expired credit cards and failed charges are the bane of any SaaS business. Pro-actively reach out ahead of time when customer credit cards are expiring, and when a charge fails. Stripe has features you can turn on to automatically help with this.
  • Show Product Momentum: Especially for early stage companies, sending regular product updates help customers feel like you’re continuing to get better, even if you don’t always fix or add what they specifically want.
  • Apologize for Big Mistakes: Your customers know if you messed up. Hiding from it only hurts your credibility, so if you have a major outage or downtime, be transparent about it. You may be surprised how customers may even offer to help! Learn how to send a great product crisis email here.
  • Push for Annual deals: Fun fact – If you pay up front for 12 months, you can’t churn for 12 months ;) Make it a win-win for you and your customers by offering a discount versus paying monthly.
  • Improve Support Response Time: One of the best ways especially early stage startups can stand out is with amazing support. Providing chat support was one of the secrets to Podia‘s high NPS score for a reason.
  • Add a Slipping Away Message: One of the first great innovations Intercom did was to allow you to easily trigger a message after N days to try to recover lost customers. Try setting one up after 25 days of inactivity and tell them about your 3 most popular features.

Each of these tactics alone will not solve your underlying churn issues, but they will help reduce the number bit by bit. Also, as you learn more about your customer base and their motivations, you’ll see smarter ways to apply your insights to engage them and fight churn.

What are your favorite tactics to fight churn? Leave a comment to share what you’ve learned with others.


How are you doing with your analytics? Please take this quick survey and I’ll share the results with participants: https://forms.gle/MkNXA2DVKJuZQQev6

100 Lessons and Spicy Takes on Being a Software Product Manager

It’s hard for me to believe, but I’ve been working in the software tech industry for 10 years now. For the vast majority of that time, I’ve either been a product manager, or a founder with a heavy focus on product.

With the trend on Twitter of 1 like = 1 insight or spicy take, I decided to jump on board the trend and do one on product management. It appears to have resonated:

So 100,000+ impressions later, it seems that it really resonated with people.

With the ephemeral nature of Twitter, I wanted to preserve those takes for easy future reference, so this post represents them.

100 Insights + Spicy Takes on Software Product Management

There’s some great discussion around many of the tweets, so I encourage you to check out all the discussions here.

The trick to tell if there’s a reply to a tweet is to look at the speech bubble in the bottom left corner of each tweet:

look to the number of comments to see if there's a response to that tweet

If the tweet says 1 in that area (like Tweet 2/), then the only reply is my subsequent tweet in the thread. If it’s more (like  Tweet1/) then there are replies to click on and see.

Anyways, let’s get onto the takes:

1/ Being a PM is a job of influence. The best PMs are the mayor of their area of work. You need to be able to build coalitions, and get buy in from a wide group of people.
That doesn’t happen by accident. It takes work.

2/ The best PMs are autodidacts. They’re constantly curious and always learning.If you don’t like learning lots of new skills from sales, to marketing, to negotiation, to EQ, to design, don’t be a PM.

3/ PMs are also like a point guard playing basketball. Done right, they set up many others to look great.A strong collaboration makes your designers create better designs, and the engineers ship a better product faster. Those assists don’t show in the score sheet but matter.

4/ PMs also are limited by their team. If you are missing key players or have weak players at other positions, it will often look like the PM is weak, because they have to cover or fill in gaps.Two of the toughest are PMs w/o good design help or lacking a good tech lead partner

5/ There are many ways to become a PM. You cannot major in product management, so everyone gets their start different ways.If you think you want to be a PM, look into how people you follow did it. You may be surprised how varied it is.

6/ The best ways to become a PM:
A) Excel at a growing company & ask to transition (seen it work great for marketers, customer success, design, & engineers)
B) Do a side project or startup to show you can PM (this eliminates the chicken or egg problem of having never been a PM)

7/ Getting an MBA won’t help you become a good PM.It won’t make you a better PM if you already are one, either.If you want to become a GM at a company, an MBA makes sense, but it doesn’t help product managers.

8/ I’m sure the previous tweet is going to get some replies from a Sloanie, HBS grad, or Stanford MBA.As is always the case on Twitter, exceptions always get mentioned, but do not disprove the general statement. Save $200k if you love PM and don’t get an MBA.

9/ Most of the worst PMs I know or have heard about are either former engineers or MBAs.
– MBAs often bring ego + don’t want to do the real work (talking to customers, iterating, etc)
– Engineers can struggle with the interpersonal & relationship building side of PM’ing.

10/ If the sales team is at war with your product team, or people try to go straight to your engineers for pet requests, those are your fault.The #1 mistake that good PMs make is not building relationships across departments. Fix it with peer 1 on 1s: https://jasonevanish.com/2015/09/24/product-managers-peer-one-on-ones/

11/ The #1 mistake mediocre & bad PMs make is not talking to customers.It’s scary getting outside the building, and they instead choose to be master BS artists.If this is you, change your ways in 2020. I wrote how-to’s I wish I had when I started: https://jasonevanish.com/product/

12/ There are 31 flavors of product managers. An A+ PM at one company would be terrible for another company.If you’re hiring, recognize this could explain a short stint on a resume, and if you’re job hunting, don’t apply to PM jobs that don’t match your skills & strengths.

13/ PMs fit differently based on a variety of factors such as:
– The business model (Ecommerce vs. SaaS vs. Ad tech are dramatically different jobs)
– Company stage (Think public company vs. Series B vs. Seed)
– Company culture (How are decisions made? What do they value?)

14/ The interview process for product management is completely broken. 

15/ There would be no need for a whole market for products to “Master the PM Interview” if the interview process was actually good at most companies.

16/ The best interviews see if you can do the work *you’ll be hired to actually do.*Unfortunately, most PM interviews are veiled in hypotheticals that have nothing to do with the job, and are basically trick questions.Mastering trick ?s has nothing to do w/ being a good PM.

17/ Most product teams don’t check their applicant tracking system nor respond to applicants who apply cold.This is ironic given the trend of calling PMs “Mini-CEOs”, and recruiting is one of a CEO’s most important jobs… 🙄

18/ If you want to get a response on an application, get an intro into someone on the team.Don’t have a network? Search LinkedIn for lower level PMs. No one asks them for help, so they’re more likely to respond & have a call/coffee to discuss the culture, then refer you in.

19/ The first PM hire at startups is almost always a sacrificial lamb at the altar of learning for the founder.Read more why and what to do about it here: https://jasonevanish.com/2019/04/28/second-1st-pm/

20/ The best job if you love startups is to be the *2nd* first PM hire, as you get all the opportunity, equity, and influence…all thanks to the PM that came before you.They died on hills, and helped the company learn what they actually wanted.

21/ Most customers don’t report bugs or give feedback.They just quietly suffer, or churn and then maybe tell you. 

22/ I follow the “Rule of 10:” If 1 customer has an issue, there are probably 10 more that didn’t say anything. 

23/ If you have an issue, get in the habit of sending a note to those affected. It’s good service AND it helps you quantify issues.I’ve had many engineers be surprised when they see that 2-3 tickets is actually affected TONS of users. Getting a list to email helps quantify it.

24/ Customers don’t care how hard (or easy) a feature was.All they care about is if you solve their problem or make it possible for them to do what they want to do.

25/ Quick Wins (aka – simple things you can do to make the product better for your customers) is a great way to let your team recharge and build some momentum after shipping a big feature.Sometimes customers are more excited by this than your big feature.

26/ Product/Market Fit exists for both buyers and end users.You can have one and not the other, and it will cause your business to sputter.

27/ Never become a PM at a company where the founders don’t understand what a PM does. You’ll get no credit for wins + all the blame for any problems.Fateful last words include “that feature went really well, but I have no idea how you contributed” & “Why can’t you just…” 🤦‍♂️

28/ Jeff Bezos was right when he said this:

“The thing I have noticed is when the anecdotes and the data disagree, the anecdotes are usually right. There’s something wrong with the way you are measuring it.”

The problem is most PMs don’t talk to enough customers to tell this is the case.

29/ There’s nothing like doing product management in Silicon Valley. There, PMs are mostly considered vital and valuable parts of the company. This changes who does the job, and how they work.

30/ If you want to be world class at product management, you need to work a few years in Silicon Valley for this reason, and many more.Being around that many product obsessed, super smart people, will level you up rapidly.

31/ A long time product consultant in NYC told me, “NYC product is 20 years behind the Valley.” That feels directionally accurate.I think there are *many* smart, great PMs in town, but it’s structural/cultural issues that undervalue product here: https://medium.com/@Bosefina/how-to-be-a-product-driven-company-in-nyc-342fd689877e

32/ The mascot of NYC PMs would be Eeyore.The amount of self deprecation I’ve seen/heard that really feels like “haha, it’s funny, but I’m actually sad about it” has been one of my biggest surprises.Product is undervalued in many cases here!

33/ One of the hardest remote jobs is being a PM.Collaboration and innovation are where the magic happens, and that’s the greatest weakness of remote work.There are ways around some of it, but it takes a lot of conscious effort. 

34/ If you’re a remote PM, use any flights or face time you get to try to solve your biggest challenges.Nothing remote can compare to the energy of being in the room at a white board with your designer and engineer(s) working on a problem. 

35/ Also document, document, document, and share, share, share.You can’t walk by your pod and tell them about a great customer interview, so you need to find other ways to share what everyone needs to know…in a light weight way they’ll actually read/see.

36/ On the flip side, remote can help bring out some of the best work of your designers and engineers as they can more easily get into deep work and focus.Try doing that in an open office…

37/ The #1 skill to develop to be a better PM is to become a better writer.

38/ Writing touches everything you do as a PM:
– Product specs
– Updates to customers
– Updates to stakeholders
– Note taking in meetings
– Notes and takeaways from customer interviews
– Writing good survey questions
– Communicating to your team

39/ To become a better writer as a PM, write more:
– Blog posts
– Internal documents
– Tweets + Tweetstorms ;)
– Personal notes to collect and organize your thoughts.
– Emails and experiment with templates you use.

40/ The other way to become a better writer is to read more. Read regularly, and you’ll find your vocabulary gets stronger and you always learn.

41/ My favorite books to help you write #1: Tested Advertising Methods amzn.to/2sHa6OH
– Copywriting goes everywhere from the marketing site, to help docs, to inside your product
– You probably have to write some of that
– The lessons apply beyond that
H/t @LarsLofgren

42/ My fav books to help you write #2: Never Split the Difference amzn.to/2Ff5HoL
– You do a lot of negotiating as a PM. This teaches you a better approach whether working with an angry customer, negotiating with another team for resources, or deftly handling your boss.

43/ My favorite books to help you write #3: How to Win Friends & Influence People amzn.to/2ZJOLQG
– PMs are in the people business and this is the gold standard to working well with other people. This applies as much to what you write as what you say.

44/ The best way to earn respect from an engineer is to have data to back up what you tell them. Show them the customer interviews & quotes, or the analytics/data and you’ll engage them much more in what they’re building.This wins many more people over than a batle of opinions.

45/ The easiest trap to fall into as a PM is to ship things and never check the results of your work.Set a reminder for yourself 2 weeks or 2 months (depending on your company stage) later to go back and see what worked or didn’t. 

46/ Setting up analytics and measurement of a new feature is as important as making sure all the buttons are where they should before launching your feature.It should be part of your product spec. (I like @joshelman‘s approach for that https://jasonevanish.com/2014/06/03/how-to-write-a-product-thesis-to-communicate-customer-needs-to-design-and-engineering-teams/

47/ Ship early, ship often.

48/ I follow the “Estimation Rule of 2X:” Any project’s estimate is always off by 2X.
– When it’s 2 vs 1 day, or 2 instead of 1 hour, it’s not a big deal. However, the bigger the project, the more brutal this becomes (4 weeks vs 2 weeks, 4 months vs 2 months is a problem).

49/ PMs should be tool agnostic. Whatever your engineers will actually use and keep up to date is the project management tool you want to use.The tool you love for the burn down and gannt charts is not the hill to die on if all your engineers hate it.

50/ “Your startup either dies, or lives long enough to end up using Jira.”
This saying I used to hear 5 years ago still seems true. 

51/ PMs should be infinitely curious. If you see something you don’t understand you should want to investigate.
– Look into the analytics, ask the engineer to explain why, ask what motivated your designer to go that direction. You’ll learn, and it often sharpens their thinking. 

52/ If you’re a Senior PM or higher, you should be mentoring people inside and out of your company.It’s great to give back AND it will make you a better PM.

53/ Every time I help someone as a mentor, I walk away with a few new ideas and usually a reminder of a few things I know I should do that are slipping.

54/ It’s never been easier to get a mentor. A few ways people have reached me, and I’ve gained help:
– DMs on Twitter
– Well crafted Linkedin messages
– Cold emails after they read my blog and found my email address on there.
– Replies to blog post emails from subscribers.

55/ Creating a bonus structure for PMs is a very risky move*. If your company’s needs to change, you want PMs to be flexible, but that’s hard to convince them if their bonus says otherwise.* Exception = E-commerce it can work since it’s easier to have a consistent target.

56/ Being pedantic is a terrible trait for a PM.Care about the details, but in a tactful way. Know what hills to die on, and how to have both strong opinions, *and* loosely hold them.

57/ The art of knowing where and how to draw the line between high quality and shipping on time is one of the hardest skills to develop as a PM.Those that master it are worth their weight in gold.I like @Wayne‘s essay on this: https://blog.usejournal.com/want-to-build-an-incredible-product-strive-for-the-delta-of-wow-f184b716af18

58/ Being a founder, even if your startup fails, makes you a much better PM.
– You appreciate other roles more as you likely wore their hats
– You learn to ruthlessly focus on the metric that matters most
– You learn to deal with extreme constraints & the creativity that breeds

59/ A good PM is like glue & grease:
– Glue to hold things together and fill in gaps
– Grease to make things run more smoothly and adapt to changes

60/ Feature voting tools are for mediocre PMs.

61/ Show me a feature voting site for a product and I’ll show you a graveyard of unanswered customer requests and a lot of noise.

62/ Show me a product team that relies on data from feature voting, and I’ll show you a team that thinks they know their users a lot better than they actually do.Some day I’ll finally turn this into a blog post it deserves:

63/ Companies that struggle with endless debates about their products and roadmap typically are arguing opinions, which ends up creating lots of politics and the most important person in the room making calls.

64/ Companies focused on their customers settle their debates one of two ways:
1) They ask “What’s best for the customer?”
2) They plan an experiment or table the discussion until they get some data/evidence

65/ Disagree & commit is an essential skill for any PM.You need to do it sometimes, and so does everyone else on your team.The key to avoiding resentment is to measure the results of the decision. Everyone is wrong sometimes, and that’s okay as long as you fix it later.

66/ Great product leaders are unsung heroes: Their teams get all the credit if it works, and if it doesn’t, they are the ones to have to answer.

67/ Getting customers to talk to is hard and interviewing them is time consuming, which is why so many PMs rarely do it.

68/ Getting customers to talk to you is a team effort:
– Get customer success to forward you customers with issues in areas you’re fixing
– Reach out yourself (email, @intercom, etc)
– Partner with marketing on surveys & reach out to interesting answers.
– Talk to sales leads

69/ Joining a company to change their product culture is like signing up to climb Everest in shorts.It may be possible, but there’s a good chance you’ll die trying.

70/ Product managers pre-product/market fit have a 10X harder job than those post-product/market fit.

71/ The stronger the product/market fit, the easier it is for any product manager to look smart and deliver wins.A lot will be obvious, and in many cases, anything you build will work.

72/ Being hired as a PM to help a startup with a solution looking for a problem always leads to failure.The power dynamics and negative inertia are too great. Also, the founders should have been figuring it out, not a hired gun with 0.5-2% of the company.

73/ Some PM jobs are really project management jobs with a power struggle left off of the job description.

74/ Sharing wins and happy customer quotes are great ways to give your team a jolt of energy.We have a Slack channel dedicated to it at Lighthouse called #HappyManagers specifically because of this. Anyone can scroll through to read stories, quotes, and testimonials.

75/ When something is broken, the best way I’ve found to motivate a designer or engineer is to share the customer’s words directly.It’s one thing when you say it, but when they hear a customer say it, it hits their ego differently in a good way so they want to fix.
Side note: My favorite story of exactly this happening was also one of my proudest moments as the PM at KISSmetrics: web.archive.org/web/2012112303…

76/ Beautiful designs aren’t always usable or accessible designs.

77/ The #1 thing I’ve always had to remind designers I’ve work with is “Do you think a 50 year old with bifocals can read that”?

78/ McDonald’s theory is a great way to get your team unstuck:Suggest something you know will be rejected to get you back on the track of what you all do want. medium.com/@jonbell/mcdon…

79/ Harsh truth: The best products don’t always win.Sales & Marketing machines can be just as dominant, if not more so.

80/ In some markets, adding more features to demo & put on your pricing checklist is more valuable and important than any of the features being particularly good or useful.

81/ Tech debt doesn’t matter right until it might kill you.

82/ Adding another feature won’t help your company win if the ones you already have are broken.

83/ Tech debt is rarely talked about publicly, but many well known startups (both successes and failures) have faced major reckonings because of it.

For example:

84/ As a rule of thumb, once you’re onto something charging to or past P/M fit, spend 20% of your time on tech debt.This keeps it from crippling you and halting all progress (or killing you) later.A nice overview is here: https://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt
And the legendary Marty Cagan wrote about it here: https://svpg.com/engineering-wants-to-rewrite/

85/ My favorite way to pay down tech debt is to revisit/iterate on old features. This way you squeeze in a few quick wins (remember tweet #25?) along with fixing a troubled, decaying part of the product.It also helps keep the engineer(s) working on it thinking about customers.

86/ I knew @SlackHQ Channels could help with customer bugs and issues, but I was pleasantly surprised how well it also works to source customer development & product feedback fast.This is an amazing post on the topic from founder/CEO @stewart: https://slackhq.com/shared-channels-growth-innovation

87/ Always be iterating on your processes. What worked for a small team or company will break as you grow.Fortunately, said breaks are predictable: https://getlighthouse.com/blog/company-growth-everything-breaks-25-employees/

88/ The best way to iterate on your process is to make it a habit:
– Post Mortems (even when things go well)
– Peer 1 on 1s to get individual/private perspectives
– Ask for feedback after a ticket is closed (What can I do differently to make that easier/better next time?)

89/ The best way to scale being a customer driven company is to get everyone involved.You can’t be everywhere, but you can teach bits and pieces to others. Teach them how to ask a good followup question over email, or to do some of their own interviews.

90/ You need thick skin as a PM. You will fail and need to find another way. You will take more blame than you probably deserve.I’ve interviewed and been rejected by more companies than you’d ever guess. Lost many deals. Been flaked on by customers over and over. It happens 🤷‍♂️

91/ Focus groups are a disaster. Customer development is *one* customer at a time.You need to hear their individual stories and situations, not group think.

92/ Remember what Steve Jobs said on simplicity:“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end”The best solution is usually not the first idea. Keep pushing to get it right to unlock magic.

93/ Sometimes the best move is to kill a feature, not add another.

94/ My favorite way to learn is to read based on the biggest challenge I’m currently facing.This insures you immediately apply it to your work…and I find also motivates you to finish reading faster.I’ll share some good places to start after #100

95/ The product tours industry feels universally overpriced.None of them show you how to calculate ROI for what they charge, and typically it’s a small part of successful onboarding + educating users.

96/ Onboarding is really hard.- Customers don’t read.
– They skip overviews and tours.
– They quickly get bored of videos…then complain they “don’t get it.”And it’s still your job to help them get to the AHA! moment.

97/ The best way I’ve learned to make onboarding work is to use a lot of “lead bullets” mixed with experimentation.A little bit of everything makes it so there’s something for everyone.Ideally, you’ll simplify & help them focus on 1 thing, but that can be resource intensive.

98/ @intercom is the best product category for startup PMs since the development of modern analytics changed how we measure and made data accessible to everyone.

99/ Some mistakes you can learn from others and avoid. Others end up being learned the hard way.Be nice. What’s obvious to you may be a difficult lesson for others, and vice versa.This is especially true in product given how varied all our backgrounds are.

100/ Time management is a crucial skill as a PM; know where all your hours go every day & make sure you get the important stuff done.This video is a great way to conceptualize that:

Further Reading:

Want to learn more PM skills, my reply here gives a few people to start with:

– Read lots of books. My favorites by category here: jasonevanish.com/bookshelf
– Rafael Balbi: Who are some great PMs you regard from the west coast? I’ve been interested to learn more about these differences.

A few off the top of my head (some aren’t PMs anymore or were pm minded founders but their blog posts and presentations are still gold) @cagan @joshelman @BrianNorgard @rrhoover @jmj @hnshah @Pv @seanrose @Bosefina @cindyalvarez @DesignersGeeks @wfjackson3 @ShaanVP @danolsen

Also would add @kennethn  and his great blog: kennorton.com/newsletter/ and the classic post by @bhorowitz

Search for their blogs and you’ll find gold mines.

I’d also add that part of it is company structure / culture, not a difference in skills. It sets you free to do things that in a different structure and valuing of product that wouldn’t allow or would be serious upstream swimming.

I’ve dedicated the last 5 years of my life to helping people be better managers.

If you have a big team to manage, sign up for a trial to make your 1 on 1s organized, motivating, and accountable, or tell your eng. manager to check us out: getlighthouse.com

Learn something? Give this tweetstorm a Retweet or a Share:

The Two Most Important Words for Product Managers to Use

What does your sales team think of you? Does customer success enjoy their conversations with you? Or do you feel animosity and tension with them?

And what about with customers?

How about the squeaky wheel who sends in feature requests regularly, or the enterprise customer with contractual promises?

Product management is about relationships.

One of the biggest mistakes I see otherwise good product managers make is not managing internal and external stakeholders well.

Rather than building collaborative relationships, where everyone feels like they’re on the same team heading in the same direction, they sow seeds of tension.

As a product manager, any communication issues fall on you. It’s your job to build bridges, even on challenging terrain.

You can do that through a variety of tactics:

  • Product advisory boards, and regular check ins with key customers.
  • Peer 1 on 1s with key sales, customer success, account management, and other department leaders.
  • Regular updates, training, and collaboration on collateral creation for new and updated features.
  • Following the timeless of advice of Dale Carnegie’s How to Win Friends and Influence People.

Throughout those conversations, both internally and externally, there are two words to always remember: “Not yet.”

Let’s dive into the nuance of how 4 letters can make such a big difference…

“Not Yet”: The Two Most Important Words for Product Managers to Use

Remember when you were a little kid and you wanted something and you asked your mom or dad? How did you feel when they said “no”?

Chances are you were pretty unhappy.

We’re not so different when we grow up.

Just say no…to saying, “No.”

As a product manager, when you tell customers and colleagues, “no”, it creates problems for you now and in the future.

No is denying what they want.

No makes them feel unheard.

No is a wall between you and them.

And most importantly, no is the end of a conversation.

Where do you go after you say, “no, we’re not doing that”? You can possibly explain why, but the other person is likely already thinking about how they can either convince you to change your mind or tuning you out in frustration.

The Power of “Not Yet”

Four letters. That’s all that separates “No” and “Not yet”, but in reality it makes all the difference.

Not yet is, “we might do that down the line…”

Not yet is, “I hear you, but…”

Not yet is hope.

And most importantly, not yet is the start of a conversation.

“Not yet” builds empathy

If you’ve ever learned about the power of using “and” instead of “but” in conversation, you know that a simple change in word choice actually leads to a larger transformation.

By changing the word you use, you change the entire nature of your discussion the rest of the way.

When you say, “not yet,” it lends itself to explaining why. This is powerful because it helps them understand the choices you’ve made.

When it’s an internal stakeholder, explaining why can help them see the other priorities. I’ve lost count of the number of times that once I’ve explained what we’re doing right now already they suddenly are willing to wait on their request; you may even be working on something important to them.

Meanwhile, with customers, it’s an opportunity to build excitement and engagement. Maybe you can’t give them what they asked for right away, but you can tell them about some other things in the pipeline.

Often, a couple of the things you’re doing are also important to the customer. You can then offer them the opportunity to provide feedback on the feature as it’s developing, or early access. Either way, it ends up feeling like they’re coming away with something, even if it’s not what they originally asked.

Show your work.

A key part of all of this is that you’re showing your work to others. You don’t need to explain the whole roadmap, but even a small snippet can help people see there’s a solid foundation to the decisions you’ve made.  It also demonstrates the hard work and rigor of the product team:

  • Data driven: Good PMs know their numbers, so you can explain to them how the feature they asked for may have a much smaller impact than the current features you’re working on.
  • Customer focused: Whether you have an enterprise contract with deadlines due in 30 days, or are finally delivering on the #1 most requested feature, showing that what you’re doing is backed by real customer insights shows you’re a PM that listens to customers.
  • Strategic: Great PMs see the big picture, and help others see it, too. Concisely explaining strategy comes with practice, so use these “not yet” conversations to practice clearly explaining how the new API opens up thousands of leads a month, or how the onboarding improvements will drive more revenue to hit key company goals.

When you show some of your cards to your colleagues and customers, you help them understand your decision making process. While they may not always agree, they’ll often respect the decisions you’ve made a lot more than when all they heard was, “No.”

In my experience, when you show you have data, strategy, and customer insights backing up your decisions and bets, your colleagues and customers will trust you. Just like they expect you to trust them to do their jobs well, they’ll see plenty of evidence to believe in you as well.

Save your relationships!

This may seem like a small thing, but I can tell you from experience,  it matters a lot. No may feel like the expedient way to handle requests, but it comes with a long term cost.

Over time, saying “no” leads to resentment and may sour relationships. People you want to partner with to make launches successful and for everyone to hit their numbers suddenly avoid you, except when they want to demand and override your No’s. They may even try to go around you and talk straight to a designer or engineer to get what they want.

And since you represent the product team, it can even lead to inter-departmental drama and rivalries. Rather than engineering and sales being partners, they become enemies, with each side criticizing the other. I’ve seen and heard it too many times, and it’s really the fault of product managers on those teams for it becoming like that.

You can avoid being that kind of cautionary tale by taking the time to regularly communicate with other teams, stakeholders, and key customers. When you meet and talk with them, remember to use “not yet” so those relationships flourish and they understand your decisions.

Never underestimate the power of using the right words.

How to Write Product Updates that Delight Customers & Reduce Churn

If you launch a feature and you don’t tell anyone, did you really launch it?

Okay, maybe the “tree falls in a forest” analogy isn’t perfect, but you probably get the point: you need to tell your customers when you make improvements.

But how do you do it in a way that customers will care?

I’ve seen dozens of ways for people to do product updates over the years, including these common ones:

  • Popping up in app to tell them (think Intercom-style, or a product tour)
  • Posting on your company blog
  • Emailing to everyone who has an account
  • Passing it to sales or account management to tell customers
  • Updating a change log that lists all updates over time
  • Praying they stumble upon the changes

Of all of those, my favorite is the semi-regular email to customers.

I like it for a few reasons:

  1. Flexible medium: I can write and include images and gifs to clearly show what’s new.
  2. Non-interruptive:  Unlike pop ups in app, they can read this when they have time, instead of dismissing it when they’re in the middle of something in your product.
  3. Reminder we exist: People get busy. You are not the center of their universe. An email about product improvements can get people back into your product they haven’t logged into in a while because they see you in their inbox.

For the past nearly 10 years, I’ve been sending product updates at the SaaS companies I’ve worked at and founded. Because of the structure I follow, I’ve seen it help build stronger relationships with customers, reduce churn, and help everyone feel more product momentum.

Today, I’ll show you my process so you can experience those benefits with your customers, too.

 

How to Write Product Updates that Delight Customers & Reduce Churn

First and foremost, credit where credit is due. There is an AWESOME Tweetstorm from Steven Sinofsky on this subject you should go read now:

Okay, so now that you read his 20 tweets, you understand why this is important, and the pitfalls to avoid. Now, let’s talk about how to actually write one.

A few assumptions:

  • You talk to customers: If you talk to customers, all of this is easy to do. If you don’t, not only is this very hard to do, but you are a disgrace to product managers everywhere. Worst of all, your designers and engineers are rolling their eyes at you. Jump here on my blog to reform your ways if you need to start doing so.
  • You’re data informed: Quantitative numbers are not everything, but they’re very important. They help you understand how many people are affected by a problem, the total addressable audience for a feature, and measure the impact of a change. Having these numbers is key for both internal buy in and explaining things to your customers.
  • You have buy-in: The bigger your company, the more stakeholders you need to manage. It’s good to get things done, and it’s also good to keep people in the loop who also interact with customers or care about this. Use your best judgment on who may want to see what you’re doing. If you get resistance, try to get support for an experiment of doing them.

If you’ve done those 3 things, you’re ready to apply these tactics to make an awesome product / feature update.

1) Start with a “Thank You”

Every product update I take the time to write out a list of thank yous to customers that took time to report bugs, share feedback, answer questions, or do customer development interviews.

This costs you *nothing*, but can mean a lot.

First, you’re letting people know you were really listening. It reminds them that their input matters and the time they took out of their day to email you, hop on a call, or beta test a feature was worth it.

It also creates a reinforcing loop:

  • You thank someone for feedback.
  • Others see that you thanked people for feedback and it gets them thinking about giving feedback.
  • Coworkers see their colleague’s name and talk about it, think about using the product more, and consider giving feedback as well.
  • Next month, the list grows, and you have more people to thank.

Immediately after I give thank you shout outs, I also then remind people just how easy it is to give us feedback, so I teach more customers what to do:

Remember: You want a product people LOVE or HATE.

Silence is your enemy.

Make more people care by letting them know you’re listening. The feedback and problems they share help you build a better product, and improve adoption throughout a company or network.

 

2) Tell your story

Every product has a mission and vision. As a product manager, you need to understand and lead that vision. It should impact everything you do, including what you write in your product updates.

The best way to manage expectations with customers is to guide them on the journey of your product.

Ask yourself questions like:

  • Where is our product heading? What is the big picture?
  • Why are we heading in that direction?
  • How does our direction help our customers be more awesome?
  • What won’t we be doing? Why not those things?

As you explain each update and change, you should keep those questions in mind. Make sure what you tell people aligns with that goal.

For example, with Lighthouse, our focus is on making managers great. We know they’re busy, so things like speed and performance in our product is as important as a new, shiny feature. We need to work reliably for them.

That meant that when we had a product outage due to Mandrill failing, we decide to switch providers to Postmark. Here’s how we framed that:

tell a story to your customers

Obviously, this is a very simple version of a story. For new, big features, there’s *a lot* more I would speak to explaining how we think it fits their workflow, why it matters, and how it fits into everything they do.

 

3) Explain your reasoning

While telling your story is important, it’s also helpful to have a rational side to it. What was the motivation for this decision?

If you’re doing product management right, you already wrote a product spec or product thesis that explains to your internal team why you’re choosing to work on this feature next. You should translate that same quantitative and qualitative data to a version that makes sense to share with your customers.

As Sinofsky points out, if you don’t give people a reason, they’ll make one up. So plan to give them a good one.

A feature can be commonly requested, but you don’t build it because it doesn’t fit your vision and mission. A feature can also be less commonly requested, but only because people can’t use your product until you build an integration they would need.

Either way, you would want to explain your decision. Tell people why you chose this of all the things you could do.

Maybe you have a Slack integration, and with all the hype and press around Microsoft Teams, you realize it makes sense to allow MS Teams users to do what you already allow in Slack.

Or maybe your company is moving up market and that means building some permissioning, and security is now more important. Your SMB customers may not be as excited, but if you can help paint the picture that, “one day your business may grow and you’ll want to use these, too” can give them a better feeling about it.  Explaining the upmarket move can then also signal to your handful of current, big customers that you are investing more in what matters to them.

If you just say, “We built some new security features” with a list of bullets, you give your customers no idea why.  Do better than that.

 

4) Paint a picture of the future

Your product update is a snapshot in time. It’s one step in an endless journey towards (or keeping) product-market fit.

As important as it is to explain what you built and launched this time, you also should paint a picture for the future. Help people understand and anticipate what is coming.

The key here is to strike a balance. You do *not* want to publish your whole roadmap; it can change too much, and you want to give yourself some flexibility.

At the same time, if people know how you’re thinking and what you’re working towards, they can help you in a variety of ways:

  • Volunteer to give feedback: If they know you’re building things they’d like, they’re more likely to reach out.
  • Good customers stay: Most people hate switching products. If they feel like you’re heading in the right direction, they’ll give you time to fix problems and get there.
  • Tell their friends/colleagues: When a product “just gets me”, you’re much more likely to rave to friends about it. By telling your story for features and where you’re heading, it builds excitement and anticipation for your best fit customers.

give a teaser of coming attractions

Strike the right balance on what you share

Giving just the right amount of detail on the future is definitely a learned skill. However, as a starting point, I like to do the following:

  • Talk about things under construction: If you’re already committed to and building something it’s pretty safe to hint at it by showing a small snippet, or explaining what it will do.
  • Focus on themes: Rather than listing the 27 things you hope to do (and could change), tell them thematically about your goal or vision. This could be like saying we’re going to “allow you to do key activities on your phone you told us are important when on the go” instead of listing mobile app features.

 

5) Seek feedback and input

You should never send something product related that is “no reply”, and this is especially the case for product updates. If people have something to say about what you built, make it as easy as possible for them to share their thoughts.

You can then use this to also recruit people for future customer development based on the upcoming features you’re going to launch, or to get people to take a survey.

The more you show you’re listening and acting in their interest, the more engaged your customer base becomes.

Creating a virtuous feedback cycle

When I joined KISSmetrics, they were getting about 10 pieces of customer feedback a week from our feedback box in the product. Unfortunately, no one on the team was replying to those for a variety of reasons.

Through being more customer driven, replying to those messages, and sending notes like I’m outlining today, we were able to boost that to getting over 50 pieces of feedback (5X) a week while the customer base grew about 2.5X. This helped us catch and fix bugs faster, and more easily get insights from our customers.

The easier you make it to give feedback, and the more you respond and act on what you receive, the more feedback you’ll get from customers.

Before long, you’ll find it’s really easy to find and recruit customers for new feature feedback and customer development.

 

one size fits none, be specific

Adapt this to fit your business and audience.

With my startup, Lighthouse, we sell to managers. They’re generally in an office and live in email. This makes an email update great.

Once a month is a good cadence for us to send an update out as it’s a couple sprints, and usually enough to fill up a good update.  It also is a frequency that resonates with our audience as they do a lot of their projects in monthly increments.

Your business may be different, so consider changes to what I’ve outlined here like:

  • Message on another platform: Can you tell them in Slack, via a small text, or somewhere else they’re most likely to check?
  • Tweak the frequency: Update your customers as often as you think fits your update cadence and your customers want them. More, shorter updates, or fewer, longer may make sense.
  • Use another format: If you’re a video platform, then video updates probably are better. If your business includes a really popular podcast, maybe a quick audio clip.
  • Show your personality: This is a huge opportunity to build your brand, so put some of your company’s personality into it. If your company is nerdy, be nerdy, if it’s playful or irreverent, be irreverent, and if you’re really formal, then your update should be, too.
  • Involve the right people: Who has the strongest relationship with your customers? They should be in the loop on this. For example, if you have account managers it may be best to have them get the word out, at which point you could draft something they can copy/paste and adapt.

The best way to get to the right format and approach for your customer is to listen and iterate. Get the right people involved in your company and start trying things.

As you build the habit of doing this, you’ll see more of what works and doesn’t so you can work towards getting messages like this from your customers:

 

How do you update your customers about changes and improvements to your product? Share your favorite tactic in the comments so everyone can learn.

Calming the Angry Elephant: How to Communicate with Customers During a Product Crisis

So you have a crisis. Your product went down. Your site or reports froze.

Emails weren’t sent…or maybe they did…100 times instead of once.

Whatever it is, your product didn’t do the job your customers hired it for.

When disaster strikes, you have two choices: Hide from it, or face it down.

Hiding will cost you.

How you react will directly affect your customer churn or renewal rates, what your customers will do (do they tweet about it? Do the offer to help?), and the morale of your team.

That’s why, if you’re the product manager, and there’s an issue with the product you’re in charge of, you need to take the lead to help communicate with your customers about it.

You can’t often do much to help engineering do their jobs, so helping with communication internally and externally can be really valuable to reduce distractions for them and show you’re doing your part.

You also then build a culture of facing problems down directly.

My team knows that if anyone finds a bug or problem, the first question will be, “who is affected?” followed by, “can you get me a list of their names and emails?” (More on this shortly).

Today, I’ll share how you can lessen the long term damage, and even earn some good will in a tough situation with your product.

What PMs should do first in a Product Crisis

Ever had a wave of upset customers mad about your product? I’ve been there.

I first learned about dealing with such issues when I was at KISSmetrics. We ran into some serious tech debt / scaling issues that led to angry tweets, lots of support tickets, and even AdWords run against us by our cutthroat competitor, MixPanel:

While there’s nothing you can say or do that will save you if the problem continues, the right message at the right time can buy you time to address it, and relieve a great deal of tension.

Here’s how to approach it:

1) Communicate internally

This is one of those times all those soft skills of being a product manager come into play:

  • Your customers are stressed: They can’t use your product as intended for the reason(s) they pay you for it.
  • Your product team is stressed: They’re scrambling to understand and resolve the issue.
  • Your company is stressed: Everyone from sales to customer success to executives will hear about a big issue. And they often won’t be able to do anything about except add more pressure to the situation.

As a product manager, you need to step up your game and work to communicate with everyone calmly and effectively.

Be a source of calm…

The first thing you need to do is relax. As leader, it’s important to be calm and under control. Understanding the problem and having a plan should give you reason to be confident when communicating internally, then later externally, about the problem.

Don’t understand the problem? Then, that’s priority one.

Ask the basics:

  • What happened?
  • Who is affected?
  • Why did it happen? (If you can get to the root cause)
  • Is it ongoing or are things back up and running?
  • What is the estimate to a fix?

If you know those basics, you can help your team by starting to communicate with those that need to be in the loop. Those can be people like the sales and customer success teams you interface with, and of course any other key stakeholders.

From there, you can start looking at how to communicate with customers.

2) Use the right level response for the size of the problem, and the size of your company

This advice applies most to small startups and businesses (1-50 employees). As you grow, you’ll likely have a more resilient product, a full marketing team to support you, and set policies to follow.

However, regardless of your company’s size, it’s very beneficial to understand what your plans would be in the event of a crisis. By the time something happens, it’s a lot harder and more stressful to come up with it on the fly.

You also want to scale your response to the size of the problem.

Find out who is affected. Only send a response to them, especially if it’s a small group

I like to send personal emails (or work with account managers/customer reps) for small groups affected. Then, for bigger groups, I’ll ask an engineer for a list of every customer affected with their name and email in CSV. That makes it easy to quickly import that list into your favorite email marketing tool to fire off such a note.

tell your boss about the product crisis

3) Always keep your boss in the loop

Finally, use your best judgment and run any plan like this by your boss.

Whether that’s the CEO, a product leader, or a founder, they’re going to have opinions, thoughts, and concerns as your product crisis unfolds. And if you’re not updating them, they’re going to ask you, or go bug your team for updates.

While we’re focusing today on communicating with your customers, many of these same approaches can also help in managing up with your boss.

As important as it is to update them, it’s also a good idea to get their approval for sending the kind of note we suggest. They can help with a quick proof read of your email before sending, so it fits the desired tone, and make them feel a part of the solution, too.

angry customers

How to Communicate with Customers During a Product Crisis

When reports started getting slow at KISSmetrics, at first we hid from the issue. We assumed it was just some edge cases, and maybe it would go away. (It didn’t.)

Instead, it got worse.

Finally, we decided we needed to say something, so our VP of Product and Engineering wrote an email we sent to customers.

And then we braced.

We didn’t know how customers would react, and so we hoped for the best and prepared for the worst.

Fortunately, the immediate response was incredibly supportive. Suddenly, the elephant in the room was gone, and we could focus on improving things for customers without fear of how they’d react.

Since then I’ve used the same approach, and learned a few key additions that have helped me with products I’ve worked on and a number of my friends do the same.

Here’s a few keys when you need to write the note:

show empathy to your customers and their situation

1) Show empathy

If your product matters, which if people buy it, it must be important to them, then showing you appreciate its importance can help a lot.

Speak to the use cases you know the problem impacts like “your ability to have those numbers for your weekly marketing meeting” or “your ability to properly prepare for your 1 on 1s with your team members.”

If you don’t know how your customers use your product, then it’s time to figure it out. Pay attention to what people are quite possibly screaming to support about that they really need, and speak their language.

When people feel heard and understood, they are more likely to be calm and understanding. When you show empathy to them, they’re more likely to show empathy for you.

Put this early in your note to customers.

self deprecation is an asset here

2) Call yourself every name in the book

This isn’t a joke. You’re showing that you know it’s bad, and you need to do better.

By bravely standing up and admitting a mistake or error happened, you show leadership.

I learned this from Dale Carnegie’s leadership classic, How to Win Friends and Influence People:

“Say about yourself all the derogatory things you know the other person is thinking or wants to say or intends to say – and say them before that person has a chance to say them.

The chances are a hundred to one that a generous, forgiving attitude will be taken and your mistakes will be minimized.”

It may seem counter-intuitive at first, but if you try it, you will be amazed at how well it works.

Caution: You win and lose as a team

Do not throw any team members under the bus. Stick to we’s and group/company wide acceptance of responsibility. Emotions will be running high as your engineering team works hard to fix it, so the last thing you want to do is to pile on more stress or frustration by calling them out.

And even if say a now-fired engineer deleted a database, or someone made a big error, your company still bears the responsibility; your company hired the wrong person, or failed to have effective safeguards to prevent such an incident. Finger pointing gets you nowhere.

Importantly, by calling yourself out, you save your customers from having to. This can prevent many angry tweets, or a large, public outcry.

Best of all, when you do self-deprecate over an issue, as Dale Carnegie teaches, there’s really only one thing left for them to do: be magnanimous and forgive you. “Oh it wasn’t *that* bad. I’ll live.”

we have a plan

3) Talk about what you’re doing about it

This is a great excuse to work with your engineering team to understand the technical side of your product better. When they’re not in full crisis mode, or they take a break, sit down with someone on the team to get a layman’s term explanation of what happened.

From there, you convey however much you and the team are comfortable stating about what happened, and then most importantly, you look to the future on what you’re doing about it.

You see this a lot in the world of engineering products. They’ll actively tweet out about an issue and then even share the post mortem publicly for other engineers to see what they learned.

While that may be overkill or not relevant to your market, explaining what you’re doing to prevent the issue going forward definitely is important.  Doing so builds confidence that this will be an isolated incident, or you can warn them, “We’re making this fix now, and a broader fix will take X weeks, so let us know if you experience issues in the coming days.”

This is the best way to end your note to customers about your product crisis.

 

Putting it all together.

Here’s an example note I sent to customers in 2017 when we accidentally emailed people 7 prep emails in the morning for each of their 1 on 1s that day. For some people that meant a busy day of 1 on 1s caused them to be sent 50+ emails in just a few minutes.

example product apology note

Now, this isn’t the biggest failure ever, but it was an opportunity to set the standard we own up to mistakes they’ll certainly notice.

And the response was exactly as we hoped:

apology note response example 1 apology note response example 1

Our response looked personal, but with a little planning, it was all automated and totally scalable to the size of that issue and others like it.

You can see a similar message here:

 

The bigger the issue, the more the detail you’d put in the note, and the more you’d be self-deprecating. Use your best judgement and fit the culture of your company for how to specifically frame it.

Update! Buffer has a fantastic example of this with a recent issue:

 

 

 

 

I also like a couple things extra they did here:

In addition to covering the basics we outlined in this post, there’s a couple extra things that the note does that are worth calling out:

  1. It’s from the CTO: Showing this issue was given attention all the way to the top of the organization.
  2. They thanked their customers: When someone helps out, it’s always good to thank them for their contribution.
  3. Reinforce behavior you want: By continually setting an example and stating how they like their customers to act, it helps reinforce customers should behave that way. This is why it’s better to say, “Thanks for your patience” instead of “Sorry for bugging you.”

Note: This is not a silver bullet.

In the end, this approach will buy you time and earn some good will. It helps you be a part of the solution with your team and sets a good precedent for communicating with your customer transparently about issues.

However, much like in baseball, “3 strikes you’re out.”

If this happens too often, no amount of well crafted apologies will save you.

You have to fix the issue and do better going forward, and then it will be a distant memory in your customers mind, and you can get back to making more awesome stuff.

How has your product team handle crises? Would love to hear your stories of what’s worked in the comments.

 


>>> Are you passionate about building great products & live in New York City?

I just moved to NY and am looking to connect with other people that love building great products to share tactics, fresh ideas, and cool products.

Interested? Reach out on Twitter (I’m @Evanish) and let’s get coffee.

Not in NY? Follow me on Twitter and let’s keep in touch there.

Why You Want to be the *Second* 1st PM

Wait, what??? What is a “second” first?

If you’ve been a first product manager (PM) at a company before you know what this means. For the rest, let’s take a look.

What is a first PM?

The first product manager (PM) is exactly what it sounds like: it’s the first product manager hired at a company.

Typically, that means you’re taking over for one of the founders who is now too busy to handle the responsibilities.

In other cases, the company has not really had anyone serve as product manager, and finally hits a point where they recognize the team needs stronger product direction and focus than a variety of people can figure out ad hoc.

In both cases, that usually happens somewhere between employee #8 and 20. So the team is small enough to be nimble, but big enough to make some serious progress.

So what’s a *second* first PM?

Joining a company as first PM is a big risk. The company usually has some traction, but not a lot. They’ve likely raised some money (or have substantial revenue), but not tens of millions in the bank.

However, that’s not the greatest risk.

The greatest risk is that the founders that hired you don’t know what they really need.

Unfortunately, the first first PM often ends up being a sacrificial lamb so that the company can figure out what they really need in product leadership.

Today, we take a look at why it happens, and what product people considering being a first PM should think about before taking such a role.

The Unique Challenges of the 1st PM

The first PM is a special job. You’re coming in to bring order to chaos, and disciplined habits to a company with some (or a lot of) traction.

With that comes a lot of challenges starting on Day 1:

1) Metrics: You may or may not have *any* metrics, which makes decision making looking back hard. If there are some analytics implemented, you’ll likely be the first person to seriously look at them regularly and use them to make product decisions.

2) Resources: The team may or may not be fully staffed. Chances are you’ll be working with a mix of junior hustlers who were early and are “figuring it out as they go” and the first executives brought in to bring order and scale. In particular, you may not have a full time designer to work with.

3) Process: Unfortunately, what worked in the “Figure it out” mode of early days, doesn’t work so well with a dozen engineers and a growing roadmap. You have to work hard to get buy in so that a little process can help everyone’s work go more smoothly. Sometimes, founders can be the most resistant to this.

4) Founder Passion: Giving up their baby to let you run product can be really hard. A founder’s vision & gut for what is “right” has gotten them incredibly far, and now you need to work with them to chart the right course forward. There’s a fine line between executing their vision, and being stuck forced to build things they want that you know aren’t the most important thing.

5) Founder experience: If they’ve never worked with a PM before, they may not know what that really means. Given how vague product responsibilities and outputs often are, it’s not uncommon to hear “I like how this project/new feature is going, but I have no idea how you’re contributing to that.” 

Now, these challenges make the job uniquely difficult, but also can generally can be overcome as long as you don’t face too many of the above issues together.

Unfortunately, it’s their combination with the 2 biggest factors below that leads to a first PM’s departure, and a second 1st PM being hired.

Why the *first* 1st PM often ultimately fails

Most 1st PMs are experienced product leaders. Whether they’ve been a product manager for years, or started their own companies, they’re generally very T-shaped employees that know how to deal with a variety of challenges.

Despite this, being the first 1st PM still does not work out in a lot of cases. I’ve seen this firsthand and commiserated with fellow PMs who have been through it.

So what are they unable to overcome? Why do they ultimately fail?

1) The founders don’t know what they really want and need

The earlier a startup is, the more haphazard the hiring process is. At 10-20 employees, they often don’t have a recruiter (or often any HR) on staff, so they’re making it up as they go as they hire people. This means many hires are directly from their network or referrals from there, without a lot of vetting.

With all the problems that have built up leading them to realize it’s finally time to hire a product manager, they start asking around for product people they know.

Eventually, someone gets introduced to them that understands this early stage startup world. In the interview they’ll be able to point out some obvious problems the product or product team has with plausible solutions.

This makes the founder think, “Yes. I need this person to solve these problems!”

Unfortunately, when they hire this person, they later realize that while those problems did need fixed, they weren’t *the most important thing* they needed in a PM.

Instead, these founders slowly discover that the skills of the PM they hired don’t align as well as they hoped:

  • Market: Are they well-suited for the nature of your market? Do they relate well to your target customer?
  • Stage: Are they comfortable with where your business is in finding product/market fit? Pre-P/M fit requires a level of experimentation and exploration some PMs can be very uncomfortable with, and is very different work than post P/M fit.
  • Non-Technical: Is it a very technical product? Then your UX issues may seem glaring now, but won’t matter when you’re trying to make core feature innovations quickly.
  • Too-Technical: Is technology not the most important differentiator in your market? Then, a technical PM may relate well to a technical founder, but not bring the customer empathy or design skills that are more important in your market.
  • Rapport: The PM and the founder they report to have to build a very close relationship. If they think too differently, or clash in personality, it won’t work.
  • Culture: How the company operates often follows the habits of the founders. If they’re disorganized it can be very hard for a process-driven PM to bring in process and get buy in from colleagues if the founder isn’t supportive of those changes.

Hiring a first PM is like the story of Goldilocks; you have to try a few to find the one that’s “just right.”

Unfortunately, first PMs often end up being like Goldilocks’s first bowl of porridge; not quite right.

Given product management comes in many different flavors, it’s easy for founders to choose the wrong one for any of the above reasons, or similar ones.

Note: this post does a great job of grouping and explaining different types of PMs.

2) The company isn’t fully established

The other side of the coin is that this is still an early stage company. Even if at the time you hired them, the PM is the exact right fit technically, market-wise, and culturally, it still may not work.

Why? Because if your company makes a major change, so does the PM you need:

  • B2B vs. B2C: If you take the leap from consumer to being a B2B product, there’s a good chance that your first PM won’t be the right fit on the other side.
  • Moving Up or Down Market: Someone great at building for the enterprise with many stakeholders and permissions leveling may not be good at building for SMBs who are used to free trials, and a self-serve approach.
  • Solution format: If you were a consulting and services heavy business it’s great if they’re from that world as well, right until you want to build a product that stands on its own without any of that.
  • Industry passion: Just because the PM was excited by your original mission and industry does not mean they’ll still be in love with your business if you suddenly have a whole new customer base to work with that’s very different.

On top of all this, as other roles are hired, what the PM needs to do could change, too. For example, if you hire an amazing designer who loves usability research, then a PM strong in that is less important than another unfilled gap.

One person’s trash is another person’s treasure.

Due to all these factors we’ve explored, the first PM ends up being a very expensive learning experience for both the PM and the company.

The company learns all the things they really need in a PM, and the things they really don’t. They can now confidently write a much more specific job description, and will be more precise in how they source, filter, and evaluate candidates.

Meanwhile, the first PM is likely feeling pretty burned out and frustrated. They fought many unwinnable battles, and in the end saw that they were never in a position to succeed. They may have even raised concerns during the interview about issues that ended up being foreshadowing of exactly what would go wrong.

This first PM has a short, challenging stint at a company on their resume, and leaves either saying “What if?” or “Glad I’m outta there.”

The second first PM then reaps all the benefits.

The glory of being the *second* 1st PM

Being the second 1st PM has all the benefits of being the first PM, but few of the drawbacks.

There are many reasons it’s fun and tempting to be that first PM:

  1. Prestige: It’s really cool to be the first product person in the door. You call many of the shots, you get to bring in process *your way*, and put your stamp on a product with some momentum.
  2. Equity: A good first PM can get a sizeable stock grant (0.2 – 1.0%) depending on pedigree and need, so the upside can be high.
  3. Challenge: If you like rolling up your sleeves and making something from (almost) nothing, this is an amazing role, with other awesome, hungry, hard working people to go with it.
  4. Growth: If the company succeeds and grows (which you play a key role in), you get to build a product organization, growing into a management track.

And unlike the *first* 1st PM, you are being hired with a much clearer picture of what they need; they’ll have learned from their mistakes the first time around.

This is why being the second 1st PM is one of the rare times it’s *not* a red flag that you’re applying for a role that is being back-filled.

In fact, it’s better than hearing it’s a brand new role, because you get some extra things that were created thanks to the efforts of the now departed first first PM:

  • Buy in: After what the other PM started, there is more support by the whole team and especially founders to make changes. They likely hired you specifically for skills and changes they now know they need.
  • Momentum: Chances are the first PM laid a foundation that gives the second 1st PM things to work with; they’ll have some analytics tracking set up, some semblance of project management, etc so you have the basic tools you need to do your job from Day 1.
  • Potential: The company is now a bit further along, a bit more traction, a few more key hires. So while you get the title, equity, responsibility, and opportunity, there’s a bit more certainty in the business so you can be confident in the opportunity.

I was a second 1st PM.

I’ve had a few friends go through being the first 1st PM and run into the challenges outlined, and once I heard their stories, I realized how much I benefited in being the *second* 1st PM at KISSmetrics:

  • Foundation: The first 1st PM had gotten us started on a number of key things I could pick up with: processes, customer lists, habits, etc.
  • Buy in: The team was experiencing a bunch of challenges as the 1st PM had left a few months earlier. They knew exactly what they needed this time, and were supportive of what I wanted to do from Day 1.
  • Opportunity: An amazing VP Sales had just come on, the business had hundreds of paying customers, Series A was raised, and it was clear what they needed and that I could run with it. I couldn’t ask for more.

At the time, I didn’t appreciate the battles that had already been won, and the buy in that I inherited.  Now, I do.

To all the first 1st PMs, who often don’t vest any equity, and found a huge difference between promises during recruiting versus reality, we salute you. It’s not a job for the faint of heart, but there’s another PM who greatly benefited from your hard work.

What if I’m interviewing to be a first PM?

If you’re interviewing at a company that is hiring their first product manager, be sure to ask if they’ve already had a 1st PM before.

Their answer will be very revealing, and helps dictate what you do next…

If you’re the second 1st PM

Dig into what the founders learned from the first PM. Find out why they think the other PM didn’t work out.

Look for signs that what they need is what you can do, and that they’re accountable to their side of what went wrong (or you may be set up to fail, too). The more thoughtful and introspective they are, and the more what they describe are things that you’re great at, the better your chance of success.

You also likely would benefit from networking your way to that first 1st PM. They likely know the skeletons in the closet and can give you an alternate perspective on the company. Then, you can work to discern the truth that is somewhere between what they and the founders tell you.

Not all previous PMs will want to talk, so if they decline speaking with you, respect their privacy. Instead, look for other ways to learn about the company like Glassdoor, asking others you may know there, etc.

Meanwhile, if you’re the first 1st PM

Go in with eyes wide open. Proceed with caution!

Unfortunately, no matter your optimism, or pre-existing relationship, there is a high chance you won’t work out.  Make sure it’s the right time in your career for the risk, you’re confident in the founder you’ll report to, and you can work from day 1 to iterate to what they need.

Once you’re there (or if you’re already the first 1st PM) a few things that can help:

1) Understand why you’re there

One of the biggest challenges of the 1st PM is turning a vaguely defined role and need into a clear cut set of goals you can achieve. Spending time with the founders to clarify everything can help you start on the right foot.

How to do it: Take another look at the job description and what you learned while interviewing. Talk with the founders to confirm what they need most, then deliver on those things as best you can.

2) Over-communicate

Building trust and confidence with the founder you report to is essential. You need to calibrate with them so they understand what you do and why, while also understanding their vision and expectations.

How to do it: Use 1 on 1s, weekly emails, get their feedback pre-launch, and give them access to the tools you use so they can see what’s happening.

3) Create a clear plan

Make a 30-60-90 day plan of what you are going to do, why you chose those things, and mutually agreed upon success metrics. This helps them understand how you think, and make sure you’re heading in a direction they agree with.

How to do it: A Google doc with bullet points is often all you need, and allows them to comment and ask questions easily. Then keep updating and reviewing it as you pass those monthly milestones. Quarterly product plans thereafter can work well, too.

There are definitely times where the 1st PM has worked out the first time, so it is possible. However, whatever vetting you typically do for a role, triple it before taking such a role, or even consider consulting as a way to try before you buy if you’re unsure.

Is a 1st PM role right for you?

Being a first PM can be a great way to learn quickly, level up your career, and work with amazing people. It can also turn into a short stint on your resume, cause burnout, and create deep feelings of frustration over what could have been.

If you’re thinking about becoming a first PM, realize it’s very different than just about any other product role you can have. Take your time, talk to others who have been 1st PMs, and make sure it’s what you really want.

There’s much more to the story…

There’s been a lot of interest in the life and challenges of 1st PMs, so to further understand this topic, we have 2 interviews on the Practical Product podcast to help you;

1) Hostos Monegro with the perspective of a 4-time 1st PM (Full show notes here)

2) Pulkit Agrawal with the perspective of a very candid CEO who had a 1st PM not work out (Full show notes here)

What’s Your Story?

Have you been a first PM? Please share your story in the comments, so others can learn from your experience.


>>> Are you looking for help hiring your 1st (or 2nd) PM? Would you like help getting your product processes in order? 

>>> Or are you a 1st PM who wants help navigating these unique career challenges?

Contact me and I can help you: jason at be customer driven dot com or schedule a call here.

Peer 1-1s: The Missing Habit Separating Good and Great Product Managers

There are many skills that go into being a great product manager, and one of the most underrated is communication, as these Silicon Valley product leaders emphasize:

“As a product manager, it is imperative that you understand the company’s overall goals and objectives and exactly how your team fits in to the broader vision.Josh Elman

“We lead by example. We succeed by making others successful. We listen first and make certain that others feel that they’ve been heard. We pursue diverse opinions. We rally our teams behind a vision that yields passion and commitment. We value and foster strong team relationships.” – Satya Patel

“Good product managers communicate crisply to engineering in writing as well as verbally. Good product managers don’t give direction informally. Good product managers gather information informally.”Ben Horowitz

You can be the best former engineer or designer, but if you can’t communicate, not only with your product team, but the broader company, you’ll struggle.

Great Product Managers communicate beyond their teams.

While it’s important to develop great written communication skills, informal, verbal communication skills are just as valuable.

When you are working with other departments to either gather customer insights or share with them a new feature launch, you’re exercising crucial communication skills.

Now, you could just blast off an email, internal survey, or update a wiki page and consider your work done. However, you’re missing out on crucial relationship building and major learning opportunities. Every moment of contact with another team in your company is a leadership and learning opportunity for product managers.

The Secret, Winning Habit of Great PMs

When you’re a product manager you have to influence people, because you have limited power on your own. You need to get buy in to accomplish anything.

And to be a product manager people enjoy working with instead of loathe, you want to be a trusted, respected colleague, not a politician or Machiavellian monster.

And the best way to build that trust and respect? Peer 1 on 1s.

What’s a Peer 1 on 1?

Peer 1 on 1s are a secret weapon for many great companies. They help fellow managers commiserate and support one another, and teams that interact regularly work together better. Usually, these meetings happen every 4-12 weeks, depending on what the two people involved feel is the best frequency.

As a product manager, having semi-regular check-ins with key members of teams you work or interact with can be priceless. It gives you a chance to give and receive feedback, hear new perspectives, gather customer data from new sources, answer product questions, and build rapport with them.

It can also ensure that people understand how you approach product decisions. You may be crushing it as a PM, but that doesn’t mean everyone else sees it that way. Product people have some of the greatest visibility across an organization, which can make it easy to forget that not everyone knows everything you do.

Who should product managers have peer 1 on 1s with?

The culture of your company and the nature of your product can make this vary, so use your best judgment when you apply this to your job.  For me, I was leading product at a 20-30 person SaaS startup, and so I will share what I found worked there based on the advice I received.

1) Your Product Team

Your engineers have an entire engineering org that decides their compensation, job title, and work. All you can do is influence what is worked on next and collaborate with them on making the best (not just good enough) solution. The same goes for designers.

When your team is small, meeting once every month or two with everyone can help ensure you stay on the same page and fix problems. Identifying a bottleneck, something frustrating, or a blind spot can save your team hours, days, or even weeks of lost time from infighting, inefficiency, or poor decisions.

You may also find opportunities to help them understand how you make decisions. This can reduce resistance to changes you propose and open up constructive feedback to communicating with them and their colleagues.

Everyone?!? At first, yes.

When you’re small (7 or fewer designers + engineers), meeting with each person can ensure your processes are working well and ensure everyone feels heard.

As you grow, focusing on the team leads who you work with most can help you scale. They can be a voice for their team. Assuming the design and engineering team leads have one on ones with their teams, they can raise with you any concerns they hear from their teams. (Note: it can help to remind the lead in advance to ask their team before you meet.)

Peer one on ones are a great way to take the temperature of your product team. If when you meet with them, they clam up, refuse the meeting, or seem combative, that’s a major signal you have work to do to improve your teamwork.

Having a good relationship with the product teams you work with is table stakes as a Product Manager. Yet, many PMs mess this up. Good peer one on ones are a good option to improve the relationships no matter your situation with your team.

2) Customer Facing Departments

As a PM, one of your most important jobs is to understand your customer better than anyone. There are only so many hours in the day, so even if you’re awesome and talk to multiple customers every day, you should still look for ways to get additional perspectives. And the best place to get those are others at your company.

Ask yourself: who else regularly interacts with customers?

  1. Customer Success / Support
  2. Sales
  3. Account management

In many orgs those three departments are off in a different area of the company reporting to a different C Level leader than you. They may literally be on a different floor or in an entirely different office. Because of this, it’s easy for sales and product to develop different cultures and even some animosity.

Break down the silos with communication.

Product managers are the perfect people to break down those barriers. You’re probably already working with them more than you realize.

Product people often get pulled into sales calls on the biggest deals, and help launch new features that success teams must document and support. They’re also driving the roadmap that ambitious sales people may use to excite prospects.

When I was running product at KISSmetrics I met with all those groups. And in each case I had two goals:

  1. Find out any lessons I should take back to the product team about customers.
  2. Answer their questions and concerns they have about product today and in the future.

So I set up regular peer 1 on 1s with people from sales, customers success, and account management.

Here’s some of the kinds of questions I’d ask to make the most of the meetings:

Customer Success / Support:

  • What are you sick of answering over and over for customers?
  • What bugs do you find you have to help users work around most often?
  • How can I make your life easier when we launch new features or make changes in the product?

These questions help improve our process around launching new features, updating FAQs, and identifying existing problems in the product we should fix. Few things make success team members stuck on the hamster wheel of never ending tickets feel better than having things that drive them crazy in the product fixed.

Sales:

  • What are common product-related issues that are causing us to lose deals?
  • What features get leads most excited about our product?
  • Are there any areas of the product that are unclear to you that I can help you understand better or fall flat in your demos?

These questions often required me to do a little 5 why’s to dig deeper to really understand and get them out of their sales mindset. Yet, with a little effort, I often found gold when I did. It also helped me better understand how my conversations with customers compared to those by sales. There’s a lot of great customer problem knowledge trapped in your head as a PM. Transferring it to sales team members can drive revenue for your company.

Account Management:

  • What features do you find you have to explain to customers the most? What’s most confusing?
  • Where in onboarding do users tend to get stuck most? How do you help them?
  • What could product do to make your job easier/better?

The people that help customers get activated will know many of the pain points that are affecting your onboarding funnel. Much like Customer Success team members, removing friction they deal with every day can really make their day, and help your customers.

Peer 1 on 1s are a privilege, not a right.

I worked hard to ask lots of questions and be helpful in these meetings. After the first meeting, I expected they would be prepared as well. I only continued meeting with people that truly brought good data, ideas, and/or concrete feedback. Otherwise the 30-60 minutes we would meet could be better spent elsewhere.

This was a challenge, especially in sales. Not all sales people really get to know their customers, but the best ones did. The best could coherently explain why we lost a deal versus just trying to ask me for every feature a competitor had.

The same was sometimes true in success; I didn’t want to know what happened that they remembered today. I wanted numbers so I knew how big a problem it was.

This then helped me make the business case when trying to decide between building something new we could sell and fixing what we had. When you can prove someone that costs $35 per hour is wasting 10 hours a week on something and it affects customers X, Y, and Z, it’s much easier to justify a change.

Build a Customer Driven Culture

When I set out to have these meetings, I was just trying to get more data and feedback to do my job as a PM better. A great byproduct of the meetings ended up being that everyone in the company became more customer driven.

As I met with people more regularly, and they saw me take action on their feedback, it created a positive feedback loop. The more I listened and demonstrated I heard them, the more they wanted to provide more valuable insights and contribute. That led to more discussions about approaches they could use in their job to get me better data and good questions to ask customers.

Patterns converge

What was particularly fascinating to me was that quite often, I would hear similar things from the majority of people I would talk to; often an issue in product would impact everyone in different ways, whether it made a sale harder, increased support tickets, or changed how account managers taught our product.

By empowering all of them to share with me what they were experiencing and teaching them how to best do so, they helped me better triangulate customer needs and calculate fully their impact. With everything else on everyone’s plates, this would never have happened without regularly scheduled meetings to talk about it.

There’s always more work to be done than time for a product manager. Taking the time to have peer 1 on 1s with key members of teams you work with can be an invaluable part of your processes as a product leader.

Want to work with a product person that lives this customer driven approach every day?

If you’re an engineer in San Francisco interested in joining a fast growing, early stage startup, I’d love to talk to you about how my startup, Lighthouse, can be a great opportunity for you. Send me an email at jason at getlighthouse dot com and tell me a bit about yourself.

How to Write a Product Thesis to Communicate Customer Needs to Design and Engineering Teams

Ever been handed a 10 page product spec that no one wants to read? Ever write one yourself? Tired of struggling to communicate what needs built next to your designers and engineers so they really understand the who, what, when, where, why of the next feature you need?

I’ve been using customer development, analytics, and information from my team to learn to build the right thing for years, but I always struggled communicating all the information locked in my head to the rest of the team. They needed to know why we were building it and all the necessary information to build the right thing without endless meetings or a massive spec they won’t read.

Fortunately, when I joined KISSmetrics, Hiten and I got to learn a better way from Josh Elman, who worked on product teams at Twitter, Facebook, and Linkedin.  Josh taught me about the Thesis, which is a lightweight way to communicate all the essential details your product team needs.

Now that I’ve used the Thesis on dozens of projects and tweaked it based on what I found worked best, I’m going to teach you how to write your own thesis for the next feature or product you build.

The Product Spec Alternative: How to Write a Product Thesis

> Know when to write a Product Thesis

The biggest crime product managers can commit against their team and their profession is to make up answers to critical decisions. Don’t be that guy/gal.

If you don’t know the answer to one of the sections in the Thesis, go find out. Dive into your analytics, talk to customers, run a survey, talk to your sales/account management/support teams that interact with customers regularly. You will gain the full respect of your designers and engineers if they know you always have a customer story and/or data to back up everything they may ask you about in the Thesis.

The following are all sections of the Thesis. I literally use these as headings to break up the parts and try to keep each section to 5-10 bullet points or a few concise paragraphs.

1) Why are we working on this next?

Every company, and especially startups, are resource constrained. What you choose to build affects your company’s bottom line, their standing in the market, and what your team thinks of your judgment. Use this area to concisely present your case for why this is the most important thing to work on right now.

I try to have a mix of qualitative and quantitative data here. If a mandate came from the leadership team to focus on this area, or sales needed it for a big customer, I make sure to include that. The more your designers and engineers can understand why this matters, the more interested they will be in working on it. In the end, you’re a team and everyone on the product team wants to be sure they’re building the right thing.

2) What are the use cases for this?

Most products end up having a variety of different users and ways that people use the product. To help your team better design a specific feature for the right part of your customer base, you need to detail who this new feature is for.

Be specific! A use case section that is just something like, “As a marketer, I want a mobile app so I can access my data away from a computer” is total weaksauce. Instead, provide the kind of context and detail that paints a picture of the situation:

  • On their way to work on the subway, content marketers like to check how their blog traffic is doing for items they published that morning or the day before. It helps them get into work and know how they’re doing before they sit down. If a number is low, they may try promoting it extra to try to raise the number. If the number is high, they may share the win with others on the team.

Could you picture that situation in your mind? Can you see Jenn the marketer opening an app on her iPhone while sitting on a subway car? I bet you could. Your team can too and they can also then start thinking about what the perfect (not just good) solution would be for them.

Write out as many use cases as you feel are needed. I often have as many as 4 or 5 detailed cases for a big feature.

3) What Problems do we need to solve?

Features are really solutions to your customer’s problems.  It doesn’t do any good to build a feature that doesn’t actually solve the problem, so it’s important to detail what problems you need to ensure the solution your team creates addresses them.

Problems should either be existing problems your product has (especially if you’re iterating on an existing feature) or the problems related to the use cases you just described above. Some example problems may be:

  • Performance Problem: Customers are experiencing frequent crashes. This feature is critical for customers and they are constantly having to refresh and start over, losing their work in the process.
  • Design Problem: Customers are having issues with the current UI. They can’t find key features that exist that they asked me for (Include a markup of the interface to show these.)
  • New Problem: Customers spend hours manually copying numbers to a spreadsheet and making their own visuals for their VP. If we automatically make those reports, we’ll save them time and can then have the VP see our branded reports frequently.

I usually write out 5-7 problems that a feature addresses in bullet form. If it only applies to some of the use cases I described, I’ll specify that as well.

I also try to rank the problems, so that the most important issues get the most attention.  Top problems may be because it affects the most people or functionality issues like the feature crashing constantly. When it’s time for tradeoffs when building the feature, having these detailed, ranked problems will help you make sure the right things avoid being descoped.

4) What are Future Considerations that must be accounted for?

Products are always evolving. Startups can be unpredictable, but you still know generally the direction you may be heading, especially if you’re driving hard towards product-market fit. Help your team anticipate what’s coming next whenever you can.

Depending on the feature, this could be very short or long section. If there are things you know are not going to make the first version of this feature but expect will be needed to be added later, be sure you tell your team! This section is all about avoiding hearing from engineering, “I wish you had told me that before we built [X]!” 

Balancing the present and the future is a constant struggle for a product. The best thing you can do for your team is give them the key information you know so they can do their best to balance their work against the present and future as well.

5) What is our KPI for this Thesis?

You should ask yourself, “What would make this new feature a success?” A KPI (Key Performance Indicator) is the most common way to determine that success since ideally you will tie the success of the feature to one or more of your company’s key metrics.

It’s okay to have more than one KPI, but keep it simple or there will be too many things to measure. When I’ve had multiple KPIs for a feature they’ve been things like:

  1. Support requests will drop by 90% for this feature after relaunch.
  2. Usage of the app will grow by at least 50% after relaunch.
  3. Because this feature affects the sign up flow, we expect a 5% lift in conversion after this relaunch.

You will fail sometimes, but by forcing yourself to quantify what you expect to happen, you will keep you and your team honest. By setting a number that you must hit you can also know when you should go back and iterate.

6) Further Reading:

Your main document shouldn’t be longer than 2-3 pages, so Further Reading can act as an Appendix for you.  In this section, I include links, screenshots, early mockups of ideas, markup of existing features for UX issues, and anything else that I believe would provide additional, helpful information and inspiration related to the project.

Remember: You want all the detail you can without the fluff and verbosity that makes engineers and designers skip reading it. Further reading is a great place for specific information that didn’t fit in the above sections and may be relevant to specific team members.

How does your team document what features need built next?

 

How to do a Jobs To Be Done Interview

Jobs To Be Done (#JTBD) has gotten a lot of attention as a valuable method for product and marketing teams (if you’re not familiar check out the the famous Milkshake video that started it all).

For the product team, they can better understand the motivations and needs of their users. As a marketer, you can understand the journey a future customer goes through to go from considering finding a solution to their problems to actually choosing your product. This is priceless for your marketing site and copywriting as well.

There’s a lot of great posts coming out on why Jobs To Be Done matters, but I haven’t seen much on how to actually do the interviews. Since I’ve done them a bunch myself, taught a number of my friends, and written previously about how to do customer development interviews, I wanted to share the process I’ve learned and evolved:

How to do a Jobs To Be Done Interview

Getting in the right mindset

These interviews are very different than a traditional customer development interview, usability testing, and other common customer interview practices. It’s a lot more free form than other processes that usually just want to uncover a few problems or learn some basic customer demographics.

For JTBD, you need to think of yourself like a detective interviewing a witness at a crime scene, or a documentary filmmaker trying to tell a story. Believe it or not, there’s a significant process a user goes through to become a customer and it’s often measured in weeks or months. Once you finish this process you’ll be able to fill in a timeline that looks like this:

jtbd-timeline

The key is to get users thinking about their purchasing process and filling in the gaps while they remember the various events along the way. Your users won’t think of them with the words of that timeline, but you’ll see where those things happen.  Fortunately, the questions I’ll show you will help your interviewee remember the various steps.

Here’s a quick cheat sheet of the terms on the timeline with an example of a friend who bought a new car.  Skip down if you already understand the timeline.

1) First Thought: What caused the first thought to think about making the purchase? When was it?

– My friend owned a Prius and it was a few years old. One night when he was driving home from work, he hit a neighbor’s trash can that had rolled onto the road. He looked at the front of the car and saw it was kind of scuffed up, but not enough to take it to the shop. This made him think, “Maybe it’s time I got a new car.”

2) Passively Looking: What did they do while they were passively looking? For how long?

– My friend started thinking about what kind of car he would get next. He knew he wanted a fast car and was focused on luxury brands. He started browsing Audi, BMW and Lexus sites to look at their cars.

3) Event #1: What happened that switched them from passively to actively looking?

– My friend’s wife would need some convincing to agree to a new car. As it turns out, about a month after the trash can incident, her brother mentioned he needed a car. My friend could give his car to his brother in law and kill two birds with one stone.  With permission from his wife, he could now actively look for the car.

4) Actively Looking: What did they do while they were actively looking?

– My friend started looking up reviews of the various cars he was interested in and asked friends that owned the cars for their opinions. He has a long time mentor that he in particular appreciates their taste, and so he asked their opinion.  My friend is an Apple fanboy, so craftsmanship is really important to him as well. Both his mentor and his own research pointed to Audi being the brand best committed to those ideals.

5) Event #2: What was the event that made him decide to make a purchase at a specific day/time?

– My friend had two events that combined to push him to finally make the purchase. He was scheduled to have surgery soon and he wouldn’t be able to drive for awhile after surgery. Christmas was coming soon too.  He wanted to get the car before his surgery so he could enjoy it a bit first and not put off the purchase that much longer and knew he could claim it as a Christmas present to justify the purchase then. (Now those luxury ads about buying cars as gifts make more sense, right?)

6) Deciding: What helped him make the purchase?

– Now that my friend was ready to buy, he went to the dealerships and test drove the cars that were finalists (a BMW and an Audi). He had a great time speeding down the highway in the Audi, so combined with his friends recommendations and his own research, he was finally ready to buy the car.

Unfortunately, the answers don’t come out that cleanly. You will get bits and pieces of the various steps during the discussion, which is why these interviews have to be more exploratory. You should be able to assemble the timeline afterwards though and start to see how you can market to future customers like your interviewee and alter your product to better fit them (like helping them see the most important value sooner).

The Jobs To Be Done Interview Script

Ok. We’re finally here to the script. Remember, the goal of the conversation is to help the person you’re interviewing remember the steps and key moments in the process that led to the switch.

A few rules for the interviews:
  1. Find people who recently purchased. Most people won’t remember well anything more than 60 days ago. The more recently the event happened, the more likely they are to remember all the details you’ll hope to capture in the interview.
  2. Don’t interrogate. You want your conversation to feel like they’re just talking to a friend.
  3. Pauses are ok. The interviewee is likely going to have to think hard to remember details. Give them time and they’ll often remember things so don’t be afraid of 10-20 seconds or more of silence.
  4. Bounce around the topics. Being non-linear in your questions often leads to new discoveries. Circle back to different things you talked about throughout the interview.
  5. The best stuff comes around 20-25 minutes in. Keep digging and listen carefully. You’ll have a real *woah* moment right around then.  For above timeline example, my friend didn’t initially realize the trash cans started his car buying process.
  6. Take notes & record the interviews. There’s lots of gold in these interviews. You don’t want to forget anything, and be able to review and share them with others later.
  7. Work in teams. A pair often can do better at examining all areas of the moments you’re trying to understand and help with taking good notes. While one person is writing a key point, the other can be asking a question.
  8. Talk to more users until they all sound the same. It generally takes 7-10 interviews to get the patterns of everyone. I found out the root cause of churn for a company by interviewing a bunch of their recently canceled customers and it was very different than what people said it was in an exit survey.
  9. Organize your findings with the Timeline and Four Forces. That’s what they’re there for. You can learn about the Four Forces here. And an image is below showing them.
  10. Don’t lead the interviewee. Try very hard not to ask Yes/No questions. Instead leave room for explanation and listen. Ask lots of “why” and “tell me more” questions.
  11. Timing Matters. Try to find out the day/week/month/hour something happened. There’s often patterns to be found in that timing and it can also help them recall other details as they concentrate to remember.
TEI 057: Applying the Jobs-to-be-Done Framework - with Chris Spiek

Jobs To Be Done Questions to Ask:

Unlike other kinds of interviews, you don’t need to always ask every question in the exact same order. These are all just ways to explore the process of their purchase and help them remember their story.

  • When did you first start thinking about your purchase?
    • Was it in the morning or evening? What time was it?
  • Where were you when you made that decision?
  • Was anyone else involved in the purchasing decision?
    • Why?
  • Visualize the environment you were in when you made the decision to purchase…where were you? What was around you?
  • Tell me more about that…(When you hear something interesting/intriguing)
  • Did you consider any competitors? Which ones? Why?
    • Why didn’t you choose them?
  • How did you decide between what you bought and the other options?
  • Why specifically did you buy that day versus any other? Why then? What was unique about that day?
    • What else were you doing that day?
    • Did anyone contribute to sparking the decision that day? Why?
  • What were you using before you had X?
    • Why did you use that? What did you like about it?
    • When did you start using that?
    • What were its shortcomings?
    • What does the new product do that your old solution couldn’t?
  • How do you normally approach choosing a new product?
    • What was your process for this product?
      • Why was it the same/different this time?
  • How do you use the product you’ve purchased?
    • Are there features you use all the time? How?
    • Are there features you never use? Why not?
  • If in doubt, ask them to tell you more about whatever tangential thing they bring up in the discussion.

You’ll notice as you do the interview, certain moments on the timeline will fit what they’re describing. I wouldn’t try to fill in the timeline perfectly until after the interview, but while you’re interviewing you can mark in your notes when it seems like it fits with some part. If a certain area isn’t seeming to be filled in, probe more around that part in their process.

To help make this more real for you, here’s a live interview from my Practical Product podcast showing the example of someone choosing to buy a mattress:

But will this work in my situation? It’s special/hard/unique.

If you can get the interviewee on the phone or to meet in person, then this will work in your situation. I have seen this work for all of the following cases:

  • Buying a car
  • Buying a scanner
  • Buying steaks online
  • Upgrading to Evernote Premium
  • Buying analytics for their business
  • Getting a gym membership for the first time in their life
  • Understanding why customers churned a SaaS product
  • Buying a 2nd iPad for a family with children
  • Buying a milkshake from a fast food chain

Even if multiple people are involved in the decision making process, any one person in the process is likely able to recall most of the key moments.

Want to be the first to hear about new episodes of the Practical Product podcast, and blog posts I write about Product Management? Sign up here:

What the Stratasys patent suit of Afinia means for the 3D Printing Industry

Q: What is Stratasys thankful for this Thanksgiving?

A: Patents and a large corporate legal department. 

That may be a little harsh, but after the press release and filed suit against Afinia made public this week you can see that Stratasys is going to start flexing their IP muscles in this increasingly competitive market. Given that Stratasys is asking for an injunction to stop all sales of the Afinia H Series, this is a lot more than a shot across the bow. Stratasys is aggressively staking their claim to the 3D printing market.

Why Now?

The Afinia has been on the market since August 2012 and has done quite well during that time. They’ve won multiple awards from Make Magazine including “Best overall experience” and have been a mainstay at virtually every Maker Faire around the country. They also have signed distribution deals to start selling their printers at BestBuy.com and Staples Canada‘s online sites. They’re an increasingly strong competitor that is flexing their retail muscles thanks to their parent company’s experience in retail.

Q3 numbers for Makerbot was not as strong as some would expect in a growing market like consumer 3D Printers. Selling likely less than 5,000 printers had to raise some flags internally, which has led to a number of actions by Makerbot to try to grow their bottom line:

  1. A new partnership with Donor’s Choose to sell more Makerbots to schools.
  2. A change to the website to make Makercare opt-out (a $300+ cost) to try to increase LTV per customer.
  3. Opening of stores in New York City, Boston and Greenwich, Connecticut.
  4. This lawsuit against a major competitor.

Big partnerships and storefront bets are the kinds of big plays you can make to throw your weight around when you’re the biggest company in an industry. Lawsuits leveraging your patent portfolio also happen to be a powerful weapon, which when you aren’t capturing as much of the market as you like, become more appealing to use against stiff competition.

Given Stratasys has been a sleeping giant for a number of years, it appears they’re making it very clear they are awake and are ready for a fight.

The Stratasys Attitude

This quote from the press release really stood out to me:

“IP infringement discourages companies from investing in innovation”     – Stratasys CEO David Ries.

This claim is absurd. If anything, having additional competition that you can’t shut down due to patents means you have to innovate faster; in an open market, new innovations are more prevalent as companies have to push hard to stay ahead. Brand loyalty, customer service and marketing become more important as well.

Everyone is at Risk

There’s an awesome discussion of the infringement, the patent claims and possible work arounds on the RepRap form worth checking out. From the forum, these are the patents mentioned:

  • August 5, 1997, U.S. Patent No 5,653,925 (the 925 patent) METHOD FOR CONTROLLED POROSITY THREE DIMENSIONAL MODELING
  • February 2, 1999, U.S. Patent No. 5,866,058 (the 058 patent) METHOD FOR RAPID PROTOTYPING OF SOLID MODELS
  • December 21, 1999, U.S. Patent No. 6,004,124 (the 124 patent) THIN WALL TUBE LIQUIFIER
  • January 8, 2013, U.S. Patent No. 8,349,239 (the 239 patent) SEAM CONCEALMENT FOR THREE DIMENSIONAL MODELS

Most of these patents could apply to any consumer FDM 3D printing company selling a fully assembled printer and do not expire for at least 4-6 years. Stratasys went after the biggest threat that just so happened to be getting competitive distribution deals. If Afinia loses the lawsuit, it puts every other startup 3D printing company at risk of a similar suit.

The Big Picture

This is just the beginning. As CNBC has reported, over 6,800 3D printing related patents have been filed in the last decade and the rate of filing is increasing. It’s clear that Stratasys intends to enforce their patents aggressively as the CEO states:

“The entry barrier for infringers is modest, especially as technology improves and prices fall… As a result, we should anticipate that this will be a growing challenge for right holders and law enforcement.”                     – Stratasys CEO David Ries.

While Stratasys and 3D Systems aggressively try to capture a consumer market that doesn’t yet know why they need to get a 3D printer, I expect other low cost printers to start to capture value at the low end of the industrial market. Whether by helping make molds for sand casting or just being a low cost alternative to the more expensive printers, textbook disruption is happening. This disruption will take decades and given our current trajectory, will include quite the blood bath for both big and small companies on their balance sheets and in the court room. Yesterday’s patent suit announcement is a key point in history and another of the many likely battles in the court room between challengers and incumbents in the 3D printing market.

Want more analysis and news on 3D printing in your inbox?

Sign up for my bi-monthly newsletter at http://bit.ly/Observe3D