Insights and lessons from some of the best people in product

When we kickstarted our podcast in Summer 2015, the job was to supplement this with a set of new, mostly outside voices – many of who taught us a thing or two on our own product-building journey – and create a long-form platform to share their equally valuable lessons. Intercom, after all, is about conversations.

The program started as an experiment with a Macbook Air, clunky USB mic, fluorescently lit, claustrophobic call room and a curiosity as to whether readers would actually become listeners. Fast forward 18 months, and we’ve two in-house studios (Dublin and San Francisco), a weekly publishing cadence, and more than 26 hours of content from leading thinkers in the areas of product management, design, marketing, support and the business of startups.

Together these conversations tell the full story of a product lifecycle. So to mark our 50th episode, we pulled a collection of our favorite lessons and insights to illustrate that.

You’ll hear from:

• Bob Moesta, President of the ReWired Group and Jobs-to-be-Done architect
• Julie Zhuo, VP of Product Design at Facebook
• Michael Pryor, CEO at Trello
• Matt Hodges, Senior Director of Marketing at Intercom
• Samuel Hulick, Founder of UserOnboard
• Sarah Hatter, Founder of CoSupport
• And Jason Fried, CEO at Basecamp

Each shares their take on a particular aspect of product, from pinpointing the Job-to-be-Done to creating successful users and deciding when to rebuild. If you like what you hear, check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed.

Bob Moesta on identifying the job of a future product

Des Traynor: How do you apply Jobs-To-Be-Done when your product does not yet exist?

Bob Moesta: There’s actually no new consumption. They’re already getting the job done one way or another through a different category. We help people find the analogous categories, products, or situations where people are trying to make progress, but they can’t. That’s where your technology would fit into it.

Part of that is figuring out what other industries to look at. We did some work for somebody who was doing a home health care product that doesn’t exist. At the end it was like, “Why did somebody buy First Alert? Why did somebody rent a home health care person to come in and see their parents?”

There’s actually no new consumption.

If we understood those contexts, because they’re trying to fit into those kinds of situations, the context wrapped around that progress is literally the same. We can then say, “Based on our technology now, what are the trade offs we’re willing to make?”

Des: When you say there’s no new consumption, how does that gel with the idea of something like Snapchat? Are you implying people always switch from something?

Bob: They always switch from something. If I mapped the day of a kid five years ago before Snapchat, it was either Facebook or Twitter. They were doing something else.

The reality is that there’s no more time in the world. You can’t create time, and so now they’re choosing to do Snapchat and not do something else. That’s what you have to be able to understand. The part of Jobs is to understand what they are firing. What did they stop doing? Did they want to stop doing it, or do they miss it?

Des: When you hear about emerging industries, a popular one at the moment in the Valley is this idea of customer success. Are people also switching to customer success from something else they thought did the same job?

Bob: They’re switching platforms. There’s a great book called How To Fly A Horse, and it talks about the evolution of innovation, and that innovation is really about creation and creating things. It’s the hard work and the fact that all things are really just evolutions of another. Though the business might call it a new category and the industry might call it a new category because of investment, most categories are created because the returns are different and the investment criteria are different. The reality from the consumer’s side is it doesn’t work that way.

Julie Zhuo on why users use a product

Adam Risman: At Intercom we talk a lot about the Jobs-to-be-Done theory and believe that people primarily use products to get a job done. They make a switch because another product will do something better, easier, faster, etc. You’ve said that in the future you think products will be used because because of style and how it makes someone feel, not because of necessarily utility. Could you explain that?

Julie Zhuo: I do think that the Holy Grail of good design is experience that’s useful, easy to use and accessible and enjoyable. To consider something really well-designed, it’s going to check all of those boxes. There is this hierarchy. I don’t think people use stuff even if it’s easy to use and enjoyable unless it’s useful to them. A lot of times when you have multiple products or services that fulfill that useful need, then the next thing you look at is, “Which one is easier or more accessible to me? Which one’s cheaper? Can it get this thing that I needed to do (finished) faster?” Then if that’s all equal, what people start to look at is like, “I’ve got all these products, they all fulfill this use case, they’re all quite accessible and easy, and now how do I differentiate?”

Julie’s “Ambition Hierarchy for Designers”. See her full post on Medium.

The way people then differentiate is through how it makes them feel. Look at clothing. Thousands of years ago, we looked at clothing simply as a function of usefulness. I need fur to keep me warm in the winter. As time passed, it’s like, “Great, now I’ve got lots of things that keep me warm in the winter.” What’s easier for me to access? Is it cotton? What’s cheaper? You get to this market where how most people pick their fashion is usually a factor of cost and then style. We spend a lot of time thinking about all of these different brands and it’s like, “If I wear this, how is that going to make me feel? How is that going to make me look?”

The competition is around that highest rung. It’s less and less about, “I have to get this thing because it’s the only thing that is going to make me feel warm and fulfill its functionality”. As products evolve and our technologies become better and it’s just easier to have more competitive products in the marketplace, the competition just moves higher and higher up in that pyramid.

Michael Pryor on how to build a pricing model that scales

Des Traynor: Our advice came from Jason Fried. He basically said, “Rule 1: start charging something for the damn product.” We started at $50 per month. You could be Adidas or you could be two people in a shed having just started your first company. We were charging you 50 bucks. What that did do genuinely was cut a lot of the “never going to pay anyway” type of customers. It gave us a bit of clarity. What did you see in your own similar experience?

Michael Pryor: We were solely focused on the product at that time. We were trying to build out the product we were making, taking the profits from FogBugz. Trello was still inside Fog Creek. We were investing in ourselves – you can think of it as we did the seed round.

We weren’t too worried about the monetization. We knew that that was going to come, but we started to see people were afraid to use Trello because they were like, “There’s no way to pay for it. They’re just going to shut down.” We were like, “We’re not charging people and that’s friction? Okay. We need to put down a dirt road for people to see how this is going to happen and we can go pave it later.”

We then started arguing about the pricing. It’s a collaboration tool. Can you charge per user? That inhibits the growth (at that time). We went around and around. Joel finally said, “It doesn’t matter. We just need to pick something, so we should do this flat rate because people will pay for it.” He was right.

It was a good solution for that moment in time. We left it for way too long before coming back to it. That was the problem.

You want to align your pricing with the value that you give people.

We settled on per-user pricing eventually because that was just understood by a lot of people. We weren’t going to invent a funky pricing scheme based on the number of boards or lists or cards. You want to align your pricing with the value that you give people. Bigger companies pay more and smaller companies pay less.

That’s one axis that we have, and we have different plans. If you’re just a solo user you can use Trello Gold, which is for superfans of Trello. For business-type use we have Business Class. For large organizations we have an enterprise version of Trello that has enterprise-type features.

In the future I could see a world in which you’re basically solving a very specific use case with a board by turning on a couple Power-Ups and essentially turning Trello into a lightweight CRM, or maybe a lightweight applicant tracking system. There would be a Power-Up that does that and maybe you pay extra for that. There are a lot of different axes that we can do. We’re expanding with that and learning.

Des: Would you consider specific revenue share with Power-Up developers?

Michael: I’m open to that. There’s already people building tools on top of Trello and charging for those tools. We don’t collect the money. People go to the other website and sign up for that. I already see a market for that kind of thing.

Des: If you could roll back and have this pricing pattern from the start, would yo do it?

Michael: I don’t know that I would’ve done the flat rate thing. I would’ve skipped that. We’ve raised our price a couple times and learned things. We also did a thing that Slack did – we call it smart billing they call it fair billing – where if you’re not using the product, we stop charging you for the person automatically.

We did that a year ago, and it’s been a burden. It just makes our recurring revenue look really weird. People get all these 4 cent charges or credits. It creates a lot of confusion. It turns out that most people don’t really care too much about this.

Des: I’ve always thought it’s clever to have smart billing or fair billing. It’s a marketing solution to a participation tax problem.

Michael: That was the idea, that if you say this to people then they’ll just add everyone in their company and not think about it. It turns out that I don’t see that actually happening in the numbers that much. We’re seeing a lot more cost associated with it instead of the perceived benefit.

Des: I can imagine there’s all sorts of messy complexity in your billing logic there, where you’re charging people for partial prorated months, because they logged in and clicked a link or something.

Michael: Yeah, it’s very confusing to them, and it’s confusing to us. If I went back in time that’s another thing I probably would do differently.

Matt Hodges on telling your product’s story

Matt Hodges: There’s a very powerful quote that I like from Simon Sinek. “People don’t buy what you do. They buy why you do it.” It’s really important to focus on the why. What are you delivering to the customers? That comes through storytelling. People don’t typically come and buy a product just because of its features. They buy a product because of the value it delivers, so it’s really important to think about the end-to-end story you need to tell.

It’s important to start with that at the very beginning because it’s going to guide the solution you build. You should obviously focus on building a solution that solves the problems of your customers and the Job Stories that your product team has outlined, but if you can’t tell a cohesive, compelling story, it’s going to be very hard to sell that to people when you actually do take it to market.

Des Traynor: Is that because it just won’t resonate? What makes it hard to sell?

Matt: It definitely depends on the magnitude of the thing you’re taking to market or announcing. There are simple features that don’t require you to tell a story. There are things that people know that they need. A good example might be automatically assigning conversations to a particular team or teammate. People know that they need that. You don’t really need to tell a story around it. You can benefit from telling a story, but people know that they need that particular feature.

When you ship new inventions or a completely new take on solving a problem that people have, you do need to tell a story to help people understand why they need it and why your solution is a better approach.

Des: In the case of those features where people basically want them and you’re not necessarily changing behavior, then you don’t need to tell a new story in a sense. It’s like, “Hey, that thing you thought we’d have, we now have it,” or, “Hey, that thing you thought would work, now works.” Whereas when you’re actually looking to change customer behavior, that’s when you need something stronger.

Matt: Exactly. You need to convince people why they should invest the time changing their behavior. As we know, changing people’s behavior is incredibly hard. You need to convince them that the way they’ve been doing things is either wrong or is actually not the best way the could be doing it. That’s why storytelling is important to capture their attention and encourage them to invest time in learning more.

Des: How does it work when you have a concept of a story and you’re trying to keep that consistent while also developing the product? Product development isn’t linear. You learn new information, you adapt, you change things, you scope in more stuff, you scope out some stuff. Are you constantly rewriting the press release?

Matt: It’s important to define what we mean by the story, and there are two different stories in my mind. There’s the story that the media and the press are going to latch onto – a particular or narrative that they’re going to find interesting and they’re going to want to write about. Then there’s the story that you’re actually going to tell the people who are going to buy this thing, and that’s what you should be focused on from the very beginning.

At Intercom, we’re fortunate to have a pretty good process in place for building product, and everything that we build starts with what we call an Intermission, which is our quirky name for a project brief. Its goal is to give the product team and, in our case, the marketing team, a shared understanding of what we’re building and why.

Download Intermission template in Word or PDF format

More recently, we’ve started to inject marketing into that process. In that Intermission we have a section that talks about the story that we want to tell once we have built a solution. The reason for that is that we want to have alignment between the product team and the marketing team such that throughout the development process, we can constantly check as we’re designing the solution and making decisions around scope about what stays in and what needs to get dropped in order to meet a specific deadline. We can revisit and make sure that we’re not breaking the story that we want to tell.

It’s important to separate the press angle from the actual story that you want to tell to your customers and your prospective customers. In order to get there, it’s important that you have a really strong understanding of the competitive landscape. Before you can even write your story, you need to have a strong understanding of what problem you’re solving and why, and our product team does a great job at understanding that by talking to our customers. You also want to look at other solutions that might solve that problem or might have a product that could be hired for that particular job that needs to get done. You’ll want to go ahead and conduct a really in-depth competitive analysis. Based on who you know you’re competing against, you want to look at who else has it, how they describe it, how they position it, and how it works.

From that, you can start to form opinions on where you win and where you lose. From that analysis, you’re going to walk away with a set of unique selling points, which are going to help you formulate that story and that pitch for when you do take it to market.

Samuel Hulick on finding onboarding inspiration outside of software

Samuel Hulick: A lot of times what you’re creating when you’re creating software is less of a tool and more of an environment for accomplishment or activity. Any time you design an environment it’s going to have a natural getting started process where people are figuring out what it is they need to be doing and how.

One of the best IRL onboarding examples is when I get out of town and rent a cabin on Airbnb. When I arrive maybe I’ll have phone service or maybe not. How easy is it to find where the key is or the key code is located? If I do get in, can I find how to turn on the lights and the heat? Do I know how to access the internet? If it comes with a sauna do I know how to turn that on or not?

A lot of times you’ll find that the hosts have clearly anticipated all of the questions someone might have upon entering the environment of their house, and everything is laid out right where someone would most intuitively encounter it. Other times it’s a complete nightmare. You have to find this one scrap of paper that’s hidden underneath a shelf.

It’s a very similar process where you’re looking to transition people into the mode of life that they were hoping to receive when they decided to pull the trigger on (a purchase). Sometimes you can do that really reliably, and sometimes, if you don’t pay a lot of attention, it becomes painfully obvious.

Geoffrey Keating: That’s probably the challenge for some of these on-demand companies – some of the variables are out of your control. It’s a two-sided marketplace. How do companies like Uber, Lyft and Airbnb design around that?

Samuel: The design responsibility is as local as the control is. If a host wants to get good ratings and get more people to come and have more positive reviews they can approach it in a conscious, considerate and hospitality-oriented way. If they don’t decide to do that then they will suffer whatever types of consequences the marketplace determines based off that. I can imagine that being a concern for Uber or Lyft or Airbnb, but at the same time what they’re creating is a larger system that hopefully has some self-regulation to it.

Geoffrey: What can we learn from industries outside of software? Slot machines and video games are two industries well adapted to user onboarding and retention.

Samuel: In both cases those have been very influential in my study of onboarding and the research that I have done in my own life. Video games have arguably been around longer than software, at least in the mainstream, and in a lot of ways the getting started experience is a little bit more mature and articulated in that medium. There are things like first-level design and tutorials that are part of games and things like that. I’ve been able to draw from a really rich pool there in terms of insights and inspiration.

Natasha Dow Schull explains how casinos onboard their customersYou mentioned slot machines. There’s an amazing book written (about this) by Natasha Dow Schull, Addiction by Design. If you look at casino floor layouts, their climate control, lack of clocks, things like slot machines and even free-to-play games like Candy Crush, they have really gotten people’s brain chemistry figured out and turned addiction to a science. It’s regrettable in a lot of ways, as far as the predatory and Machiavellian practices they employ, but at the same time what they’re learning can just as easily be used in service of helping people become successful.
Ignorance is not something to your benefit, so learning the tools that people who maybe have more questionable ethics are using can be helpful, as long as you’re following your own Hippocratic oath.

Sarah Hatter on how great support improves product

Sabrina Gordon: There’s a line I love in CoSupport’s Manifesto that says “Feature requests aren’t annoying, they prove someone likes what you built and they want to use it more. Stop being so defensive.” Could you expand on the whole idea of how the support team can help improve your product?

Sarah Hatter: Startup founders and mid-market, mid-level companies are my favorite audience because they really get it. Startup founders, provided they haven’t taken a bazillion dollars in funding and someone else is running the ship, they have the most risk. They have the most on the line if something doesn’t work out. They are the ones who are trying to figure out, “how do we create the best experience possible to gain those loyal customers who will continue to pay us money?” Especially software services – someone’s going to pay me $49 every month; how am I going to convince them to keep doing that?

We got a lot of really bad advice when apps were launching, when people were doing software as a service 10-15 years ago for the first time, there was a lot of the designer’s rights. If someone wants this feature, we’re going to say, “no, we don’t like that feature, so we’re not doing it, you don’t need it. We’re going to retrain people how to work based on the constraints of our product.” And for a good five years everyone got really, “Yeah! The engineer’s right, the designer’s right!” All these companies started failing, and they’re not failing because they said no to a feature request or didn’t improve based on user insights. They failed because their core belief was that the customer insight of experience didn’t matter as much as what the designer wanted to matter.

When I speak at conferences, I’m primarily speaking to people in that startup founder, micropreneur stage and I’m convincing them, you get someone on the front lines who’s empathetic, who’s understanding, who’s really intuitive about people’s needs, and they’re keeping track of every single request, words that are being used, and the tone that’s coming across from customers. They’re keeping track of every bug report and every feature request. This especially is a big thing a lot of people tend to ignore. They don’t think it’s relevant in early-stage life, but I think it is. If you have the right person on the front lines, they’re triaging up to your product people, “this is a trajectory for us to acquire more users and make more money.”

At the end of the day, that’s all it is. It’s not feature bloat. People are very scared when they hear, “listen to feature requests,” They’re like, “well then we’re just promising that we’re going to build everything, and then we have feature bloat!” That’s my cartoon boardroom version of a startup founder’s voice right now.

Building a product with empathy of the customer in mind really does matter.

I don’t think that’s what that means. If you’re pruning to people, your experience with this matters, your experience using every single button that you click becomes a habitual part of your day. This isn’t just a transactional experience that we have, like the Mitch Hedburg joke with the doughnut: I don’t need a receipt for a doughnut. You give me the doughnut, I give you the money, end of transaction. That’s not what we want to build. If you want to build it that way, then you can go work for Samsung or whomever, but if you really want to build a company and a brand and a product that lasts and impacts people’s lives, makes their lives easier, and makes them loyal to you for 10-plus years, you have to come at this idea that building a product with empathy of the customer in mind really does matter. The endgame is we make more money. That’s what it is. I’ve never ever ever told somebody to listen to people and kindly reference and track feature requests and talk about it with product, who said, “I went bankrupt because of that.” That’s never happened.

I talk a lot about hiring people who have that intuition, because I’m really anti-phone support. It’s too emotionally charged, it costs way too much money, and companies end up offshoring it because it’s so expensive, so people end up getting this bad experience.

I always say, “Why do people want phone support? Why do they want a telephone number to call?” It’s not because they want to stay on hold for fifteen minutes, it’s not because they want to get accidentally cut off, it’s not because they want to repeat their problem to four middle-managers before they get someone to give them a coupon code. They want to trust you, they want to know that you’re a human being who can help them. They want immediate help to an immediate need or to fix something. What is the root cause of someone saying, “Can you add another checkbox here, or a dropdown here, or can I add another user here?” What’s the use case? Why do you need that? And we may find that’s not what we need to build for this person. We need to build a whole other scenario that fits around this subset of users who we could acquire if we just had this extra feature with this extra scaling capacity.

Jason Fried on when a successful product calls for overhaul

Des Traynor: One thing that’s really interesting to me is how your release patterns have changed. You now seem to release a new ground-up version of the product every few years while still maintaining the previous ones. Why are you doing that?

Jason Fried: It’s averaged out to about every four years we do a major new release, ground-up. We do that because at a certain point, you achieve the “local maximum.” Think about it like a car. Cars have generations. You have the Porsche 911, which has been around for 50 years. You have the Honda Accord, which has been around for 40 years. But every 5, 6, 7 years, there’s a new chassis, a new engine, a new idea. They start over from scratch, but it still follows the same pattern.

Clockwise from top-left: Basecamp 1, Basecamp 2, and Basecamp 3.

You can’t optimize certain things beyond a certain point. If you want to bring brand new ideas to bear, if you want to try something radically new, you can’t optimize or iterate your way there. At some point you need to start over. Then you’re able to do things you couldn’t do before. Products carry legacy, just like companies carry legacy. At a certain point, it’s very, very hard to shed legacy, so you have to jettison it and start over.

What we do, which is different from most companies, is we don’t force our customers to upgrade to the newest major version. We’re, of course, releasing iterations for years as we go on the existing version, but we freeze the previous one in place. We continue to support it forever, but don’t force people to upgrade.

Our schedule is not our customers’ schedule. The kind of work people do at Basecamp is very critical to their business. It’s project work, it’s client work, it’s internal, important initiative work. For us to change the furniture on people on our schedule, make everything different, is unfair. We prefer to say, “Hey, look, whenever you’re ready, if you’re ever ready, come on over.” If you’re comfortable with the way things work and you like the way things are, you can stay with that forever. The initial version of Basecamp that came out in 2004, which we call Basecamp 1 now, still has a good number of customers on that who will probably be on that for the next 10 years because they’re used to it. It does what they need, they’ve grown up with it, and they understand it. That’s fine with us too.

Des: That’s pretty impressive. I love the phrase, “Until the End of the Internet,” which is a good way to indicate your commitment. What is the decision or the idea that triggers you to start thinking about the next Basecamp versus the one you’re currently on?

Jason: We typically need enough new ideas that are stacked up. Imagine a scale of justice. You’ve got things on both sides. The current version is going to be heavier than this new idea until the new idea becomes heavier than the current version. When it starts to flip, that’s when you realize, “We’ve got enough new stuff here.” A new perspective, new ideas, new points of view, new insights. There’s enough of a pile of new things to evaluate whether we make any of those things or bring any of those things to the existing version. If we say no to too many of those – it would be too complicated, it would be too divisive, it would throw off the balance of the project – then it’s time to think about a new version.

The first one was eight years. Then we did four, then we did three and a half. It’s roughly, altogether now, 12 years, three versions. When we come up with something that feels like a collection of new enough ideas that we can’t retrofit or don’t want to retrofit, then it’s time.