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 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 Goldilock’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%) 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:

  • 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.
  • 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.
  • 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.

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.

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


>>> 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.

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) is getting a lot of attention lately as a valuable, new method for product and marketing teams (if you’re not familiar check out the podcast and the 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-timelineThe 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.
  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.
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.

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.

What have you used Jobs To Be Done for? What are your favorite JTBD interview questions?

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

The Rise of the 3rd Party Manufacturer in 3D Printing

There’s a lot to be learned about the present and future of 3D Printing by studying the rise of the Personal Computer. Today we have hundreds of companies building supply chains from scratch to sell 3D Printers out of garages, co-working spaces and tech shops, not unlike Steve Jobs’s garage and the motel in Albuquerque that spawned Microsoft. However, this part of the journey did not last forever.

As the market and individual companies matured, 3rd parties began supplying various components to the PC makers as they built more sophisticated manufacturing processes. The PC makers welcomed this so that each one of them did not have to reinvent the wheel for each component as well as get better prices from suppliers who could gain volume advantages by selling to many of those PC makers.

Today, we’re seeing the very beginning of such opportunities emerging with a handful of really interesting companies becoming the first 3rd Party Manufacturers (also known as OEMs). Here’s a few I’ve been tracking:

The Rise of the OEM

Extruders:

1) DGlass3D: You may remember these brothers from previous blog posts and the 2nd edition of my newsletter, when they were on Kickstarter. While they did not fund successfully, they were able to connect with companies interested in their technology. Given the challenges of dual extrusion caused by the decreased build area, added weight for the stepper motors and quality of prints when switching back and forth between heated materials in each extruder, I expect more than a few companies may be interested in the technology to shortcut adding this pivotal feature.

Why this matters: Many use cases open up when you add the second extruder including printing your support structures in a water soluble material, multi-colored printing and printing in multiple materials with complimentary properties (like part hard, part soft or part conductive, part insulated).

2) The Prusa Nozzle: Josef Prusa is one of the most prolific contributors to the RepRap movement, which includes the Prusa Mendel, one of the most popular RepRap printers. Recently, he unveiled the Prusa Nozzle, which allows you to print at up to 300 C and is a much easier to use, single piece. See more about the Prusa nozzle in edition #4 of my newsletter.

Why this matters: Printing at temperatures as high as 300 C allows additional materials to be printed like polycarbonite (bullet-proof glass) and food-safe stainless steel materials are better than the past use of brass.

Materials:

1) Proto Pasta: Another new Kickstarter entrant, these guys are working on reliable, high quality filament for your FDM printers. On their Kickstarter, you’ll find a carbon fiber reinforced PLA, high-temperature PLA and an experimental polycarbonate material. They’re testing and certifying their materials, which is rare in the current materials market.

Why this matters: Stronger, more reliable materials allows users to print for more applications. Combine this with dual extrusion (ie- multiple materials in one print) and it really gets exciting.

2) MadeSolid: This Oakland-based materials manufacturer recently completed a successful Indiegogo campaign which expands the color options for FormLabs printers from gray and yellow to the full rainbow. They’re working to make quality resins and filaments to make higher quality prints. They have some very cool technology in their pipeline I’ve seen some parts (hint: the days of PLA and ABS may be numbered).

Why this matters: Component makers have not fared as well as many 3D Printer companies on crowdfunding campaigns. It’s good validation that people are hungry for new, better materials that MadeSolid hit their goal. It also means that they do not need the distribution channel of any printer manufacturer to be successful, which provides huge negotiating leverage should they talk distribution with one.

Build Plates:

1) BuildTak: If you spend much time printing, you quickly run into issues with your printed material sticking well to your build plate and also being easy to remove after the print finishes without damaging the print. BuildTak works with both ABS and PLA and is more durable than kapton tape, which has a habit of tearing as you remove objects. This company is just starting out but is already being evaluated by some 3D printing companies.

Why this matters: Reliability is one of the most important aspects still needing dramatic improvement in the 3D Printing space especially for novice users. If this works as promised, it could address one of the major causes of failed prints: poor adhesion to the print surface.

2) Automated Build Plates: Unfortunately, this technology doesn’t exist…yet. Makerbot tried and failed in the past to create this system for automatically removing parts. For those looking to print items in a queue, they currently have to manually remove every object upon completion. That’s why Hack a day put a call out for work on such a project recently.

Why this matters: The development of a process for removing prints would be very valuable for any organization sharing a printer with multiple users and wanting to leave prints unattended and still have multiple items printed. Of course, the printers need to be used enough for that to be a key pain, which is only an issue for a small percentage of users right now.

Even a company with a large engineering team and an unlimited budget would struggle to keep all this innovation in house. It is only a question of when, not if, 3D Printer manufacturing companies at the low end of the industry move from an integrated solution to a more modular approach*.  This opens up many opportunities for individual OEMs to emerge to produce key components that supply many of those companies. (* Note: Patent-heavy, unique processes will keep the industrial printers closed for the foreseeable future).

What other great OEMs have you seen emerging? Leave a note in the comments.

[Ed Note: A version of this post originally appeared in my bi-monthly Observations in 3D Newsletter. Sign up now to get more in depth analysis like this at http://bit.ly/Observe3D]

Why the Mayday button is another genius move by Bezos and Amazon

Amazon recently launched the Mayday feature with a television ad campaign showing a one button press for help from a live person who can control and guide you through the use of your Kindle Fire HDX. If you haven’t seen the ads, here are a few of them:

At first my techie self said “why would anyone want that?!?” Then I realized Bezos’s genius.

Mayday isn’t for you.

If you’re reading this, you probably work in startups or technology. Since we are already well served by the iPad and various full-Android tablets, Bezos is targeting the technology laggards of the tablet adoption curve. These are people that want a proven product and only buy once the market is commoditized and discounted. They don’t care about the millions of apps that Apple has as they will only use it for a handful of key applications. They also don’t see the need to pay the Apple premium price either, so a sub-$300 Kindle Fire fits well.

Instead, these users are more like some of my older relatives who use their tablets for email, Facebook, browsing the web and watching videos, often as a second screen. These users sometimes struggle learning new technology and can be sensitive to asking for help as they are worried about feeling dumb.

Mayday is the perfect name.

Do you know what “Mayday” means? If you’re under 25 I wouldn’t expect you to. Anyone in the Baby Boomer or older generation will distinctly recognize it and understand its meaning as a universal call for help. It’s also way catchier than just another “Help” button and probably even trademark-able. Given the target of helping those less tech savvy who have likely not adopted a technology yet, it should immediately click with them.

Amazon isn’t in the tablet business.

I wondered: how could Amazon afford to do this on such a commoditized device where their margins must be slim? Then I remember this is Amazon. They’re not in the tablet business; they’re in the e-commerce business.

We know that e-reader Kindle owners dramatically increase their purchasing with Amazon (50-100%). I bet by now they know the LTV of Fire owners and realized they could afford the support because of all the ancillary spending they would get from those owners and opportunities to redirect users to Amazon solutions when they ask questions. Add to this the data they get on Fire owners knowing all of their activity and the optional ads special offers people can accept, and there’s a lot of value in getting a new Fire owner.

Amazon had to shake things up.

Amazon’s tablet market share is reportedly down significantly (21% in July 2012 vs 10% in July 2013). They needed to use a Blue Ocean Strategy to differentiate and find a unique part of the market they could win. Combining the Mayday button (to attract the hard to attract laggards) with some very obvious use cases (the family accounts with ability to limit access and a child’s time spent on the device) very specifically tries to carve out a strong niche for Amazon. If it works, the difference in cost structure for Amazon, the e-commerce company, versus other tablet makers will make it hard for others to duplicate the Mayday button.

Bezos continues to show he is one of the best strategist CEOs on the planet. Mayday is just one more move to capture value from an under served group and move them into the world of Amazon purchases.