Lindsey and Chad talk about product roadmaps. Are they dead? Lindsey and Chad think they just smell.
We also say an emotional goodbye to Lindsey as she moves on to new adventures. We miss you!
Become a Sponsor of Giant Robots!
Transcript:
LINDSEY: This is the Giant Robots Smashing Into Other Giant Robots Podcast where we explore the design, development, and business of great products. I'm your host, Lindsey Christensen.
CHAD: And I'm your other host, Chad Pytel.
LINDSEY: And today we're going to talk about product roadmaps.
CHAD: Product roadmaps. [laughs]
LINDSEY: Whoa. This is the topic. I feel like recently I've seen some thought pieces that product roadmaps are dead. So I'm curious if you think product roadmaps are dead.
CHAD: No, I don't think that they're dead, but I want to make the distinction too. I've never believed in a public product roadmap because I think that sets you up for just disappointing everyone involved, your customer, yourselves. And I think that there's a balance to be struck there. Saying that product roadmaps don't have a place, to me, in my mind, is like saying planning, having plans doesn't have a place and that just doesn't ring true to me. I think you should plan out what you're going to be working on. But I'm sure we'll get more into it. I also believe things about not having big backlogs and not doing too much planning and that kind of thing. So it depends on what you mean by a product roadmap.
LINDSEY: Well, yeah. I think that therein lies the issue. You can do it well, and you can also [laughs] run it into the ground. But you mentioned having it public and that being a bad idea. And I think at the core of product roadmaps is communication and alignment and getting all of your stakeholders on the same page about what you're building and why. So to me, I would think those stakeholders are the leadership team of the company, if this is a product company and product is the main business driver, the leadership of the company, the product team, of course, and engineering, sales, and marketing as well. Am I missing others? Clients, customers.
CHAD: Right. Customers.
LINDSEY: How do you feel about it? Does that count as the externally facing do not reveal?
CHAD: Oh yeah, it does for me. So we've all seen the companies that say that they're going to do something and then in a best-case scenario, that becomes a deadline which was arbitrarily made in the first place that everyone is stressing out over, that sales is potentially making promises that are either going to need to be broken or are going to need to be super stressed over. And then in a worst-case scenario, you end up not delivering on that roadmap as you essentially promised. And you actually end up with disappointed customers.
LINDSEY: So you would recommend not telling the customers about future features.
CHAD: Yeah. I think there's a balance to be struck there. So certainly, if you know that you're working on something now like actively working on something and a customer were to ask you about that thing directly, I might say, "Yeah, we're working on that now, and we're excited about getting it out to you." But I have only [chuckles] ever been a part of when a team is saying, "Q3 of next year, six months, nine months down the road, this specific feature is going to make it to customers." That's a real recipe, in my experience, a real recipe for lots of people being either really disappointed in that not happening or really working unsustainably in order to hit that in the first place. It's really hard to plan software that far in advance.
We just had the CEO of Dragon Innovation on the podcast. And I think that even then, you have to be careful with hardware, but at least with hardware or other kinds of businesses, it's a little bit easier to say, "Our goal is to have this incorporated in the product, or whatever, in the next revision of the hardware. And we expect to do that two years from now," or something like that. That's a little bit easier to put a bow around, I think.
LINDSEY: Yeah. I was a part of a software company that got acquired by a hardware company. And all of a sudden, we were wrapped into these 5 to 10-year product roadmaps that were blowing all of our minds [laughs] and a very different fit than how we were used to working.
CHAD: Yeah. It's worth noting that there are some companies that essentially go so far as to publish a Trello board of their roadmap. I don't know which ones they are. [chuckles] I have to find them. But even then, they're not necessarily making hard promises. And if you're committed to being transparent and publishing some roadmap to the public, the ways that I've seen it done best are working in themes. So you say, "Two quarters from now, our focus is going to be on reporting," or something like that. That is a little bit...because you're not making specific promises. You're just establishing a theme of what your focus is going to be on for that time. You can imagine you can still get yourself into a position where customers are putting all their hopes and dreams on what that's going to look like, and maybe your support staff or salespeople or whatever start to make promises about what's going to be delivered in that time. And then again, a bunch of people end up disappointed.
LINDSEY: Yeah. I've also seen what I think to be the most successful roadmaps be based around themes. And I think it’s also…again, going back to that, the fact that it's, in addition, to actually delivering product and delivering good product, it's helping align your internal team around what you're doing. So to rally your whole team or your whole company around reporting is the next big thing that we're working on, and this is why. This is what we've heard from users, from our research. And this is the direction we're going in and then actually getting everyone working towards reporting in their own ways. Marketing can be working on content around reporting. Hopefully, sales is seeding the idea of maybe not promising around reporting as well.
And that also really appeals to me as a marketer and as someone who's thinking often about how do we get folks moving in the same direction, speaking the same language and creating some momentum around something that can differentiate us, get people excited about what we're doing? Then hopefully, it's also strategically valuable to the company adding a new feature or entirely a new product. You're expanding your offering and maybe even your market reach. Who do you think are the most important folks within the company to be driving the product roadmap? Who owns the product roadmap?
CHAD: Well, [laughs] so if you have a company that has a roadmap...I'm getting distracted by the premise here. Let's just come back to that a bit. Momentum is key. You used the word momentum. And if you're feeling the need to plan things out or to gain a sense of clarity on your team about what's going to be done, and what's important, and you need to do a long-term roadmap in order to do that, that to me does point to it's sort of a smell. That's what we do when there's a code problem. We say it's a code smell. It points to if you had a team that was continually delivering value to your customers, to your users, and that you had a team where when sales, or marketing, or someone learned something about what will be valuable to customers and it's validated that it's valuable, and it gets put into the design and development process, and it comes out relatively soon, there's no need for a product roadmap.
Or I should say people don't feel the need for a product roadmap as much because they have high confidence that user needs are going to be met in a tight feedback cycle and that there's not a loss of momentum. And things going into the system are coming out in a week, two weeks, three weeks. Even four weeks, you can maintain that sense of momentum of we understood that this was important. We validated that it was. It went into the system, and it came out the other side, and it's in the hands of users. It's only when that starts to break down that stakeholders start to say, "We need to plan. We need a roadmap," because they lack the confidence that putting things into the system they're going to see them come out the other side in a way that maintains momentum.
LINDSEY: Does that depend on the size of the company?
CHAD: Well, ideally, even companies of large size are able to do that, but we all know that that's difficult. It may be that most companies just can't do that. And when that's the case, you have that breakdown. You have that lack of confidence. You have a system where you aren't putting things in and quickly seeing them come out the other side. And so that's where something like a product roadmap you start to say we need that in place. And I think that that's why it often happens as teams get bigger and as companies get more complex.
LINDSEY: Interesting. So product roadmaps are not dead, but roadmap can be a smell.
CHAD: Yes. [chuckles] Yeah, that's what I would say. That's my opinion.
LINDSEY: Who owns that smell?
CHAD: So now to get back to who owns the product roadmap, if your customers aren't the ones driving what's on the roadmap, then something is fundamentally broken. At the end of the day, the real owners of the product roadmap, even though they probably shouldn't see it, are the users, the customers. But I don't think that's the question you were asking. Who decides what's on the roadmap? It's got to be the people who are closest to hearing customers and who have the vision for what the product is supposed to be. So that will often be the company leadership, the CEO, the chief product officer, something like that combined with people who are talking with customers.
LINDSEY: So on the opposite end of the spectrum, if it's a big company, maybe it's a little bit harder to operate without the roadmap. If you're a really small and young company, let's say, and you already have a roadmap, is that too much?
CHAD: Well, this is a podcast, so we can have opinions. I would say [laughs] growth opinion, high-level position, yeah, you should probably not have that roadmap. Now the devil is in the details. What is the roadmap? Is it high-level themes? Is it I'm building this idea, and I'm a visionary about what this product is going to be, and I've laid out in broad strokes...we've done an initial version, a minimum viable product, and we have a vision for where we're going over the next year or two? There's a way to do that which doesn't then convert into this rigid product roadmap. And I think that that's what people who say product roadmaps are dead and you shouldn't be doing them; that’s what they're pushing against is that really rigid expectation setting system where promises get made and then broken.
LINDSEY: Right and promising especially deadlines far out into the future.
CHAD: And they also understand or believe that if you have a product roadmap, it potentially puts you in a position where you stop listening to customers because you say, "In six months, this is the thing that we're going to be working on." And then you get there, and you just work on it, and you deliver it without having learned along the way that the next most important thing might be something completely different. And so that's another risk with product roadmaps is you start working to the roadmap instead of working to what your users are telling you. So at that company, I'm not surprised to hear that it was a 5-year, 10-year thing, and then it's based off of a thing, Was it really concrete, or was it more sort of vision stuff?
LINDSEY: It was very concrete, I would say.
CHAD: Yeah. [laughs]
LINDSEY: And it's interesting because a lot of it was around trying to be first to market with cutting edge technologies. And on the hardware side, there was also R&D and multiple scientific teams working on specific things. And actually, to get more concrete, I think I can share without giving specifics. So it was 3D printing, and there's like an arms race in 3D printing to be able to print with new materials. So there are multiple teams working on trying to figure out how to print with new materials. And then we had these really long-term product roadmaps that were like by this year; we’re going to have gone to market with it and using that as a way to stay ahead of the competition basically.
CHAD: I can imagine that from a business perspective, you're looking at that situation, and you say...and this is true both in science and in software. But from a business perspective, it's saying, "If we don't have this deadline in place, then we have a research project that's just going to go on. We need this timeline, this deadline to hold everyone accountable to what a goal is and to make sure that we're bringing new products to market in that timeframe." And then the scientists are probably saying, "We have no idea. It's completely arbitrary. We think that we could do this, but what happens when we don't? What happens when we don't have something?"
A lot of times, I make an analogy between science and even software development and art because it is a creative process. It's all in our heads, and we're just coming up with it. You can say, "I need to have the book," or "I need to have this painting finished by this time." But it's very difficult to then ensure that that is actually going to happen at the creative level of saying, "I'm proud of this work, or it's good." It's hard to do that.
LINDSEY: Yeah, and I think there was an element too of either we will figure it out, or we will acquire whoever figures it out. And then there's a separate team that's off trying to suss out who's figuring it out and what are they willing to be bought for? [laughs]
CHAD: Right. And maybe from a business perspective, a lot of that makes sense. And you have to balance all of those things in order to try to be successful from a business perspective.
LINDSEY: Yeah. It's interesting on the hardware side, too, especially as you do get closer to actually launching. It can be very waterfall-esque working towards launch because there are so many dependencies in order to get the thing built and shipped and launched on time.
CHAD: I found a Quora thread about companies that have made their roadmap public.
LINDSEY: Did any do it successfully?
CHAD: [laughs]
LINDSEY: I've only seen nightmare stories. Like, let this be a lesson. Here's a company that made their roadmap public, and within weeks they were disappointing people. [laughs]
CHAD: I think that it's tempting, you know, and I think we should just do it. Part of the benefit of not having a roadmap that people say is that it allows not only the flexibility for what you're going to do to change based on what you learn. But the other is it offers you the opportunity to surprise and delight customers. And it allows you not to say, "This thing is six months away," but to say, "Here it is now." And one of the best examples of that that I think we're all familiar with is Apple. Apple doesn't typically pre-announce products that far in advance. And they're even a hardware company. They're clearly working on things years in the making. But they don't talk about them publicly until it's like, you can order this today, or you can order this on Wednesday. And the excitement and momentum that Apple builds around that is like the Charlie and the Chocolate Factory, Willy Wonka kind of secretive thing. It's super exciting to customers, and they're super successful doing it.
And last year, we had a really public thing where...actually, it was I guess two years ago that the saga started when Apple unusually announced AirPower, which is a charging mat that could charge both of your phone and your watch and everything all at the same time. They announced that far in advance. And then it actually ended up never shipping, and they eventually canceled the product. And they had to do all of that publicly, which is very, very different from Apple. I imagine that there are tons of products that Apple thinks that they're going to eventually release, and they don't work out, and they have to kill the projects. And all of that happens behind closed doors.
LINDSEY: So we don't know of anyone who does it successfully. What does Quora say?
CHAD: Quora doesn't know. A lot of the companies are not even in business anymore. [laughter]
LINDSEY: There you go.
CHAD: Buffer has apparently...Buffer has a transparent product roadmap. And I guess if there's any company that does transparency pretty well that I could point to, it would be Buffer. So we can link to that in the show notes. How does this board work? We've made this to give you a clear view into what we're working on, what we're about to work on, and what we're thinking about working on. We hope you enjoy the peek behind the scenes. They have four lanes: potential, next up, in progress, and done. They have voting enabled on their Trello board so their customers can vote on the different things that they have going on.
LINDSEY: Are you in the actual board?
CHAD: I am on the actual board, yeah.
LINDSEY: How many votes? What kind of numbers are we talking?
CHAD: So the in-progress thing that they are currently working on is a better way to manage campaigns in Buffer, and it has four votes.
LINDSEY: Oh.
CHAD: [laughs] So it doesn't seem like there's tons of engagement. There's another one, the best time to post to maximize your reach. It has seven votes.
LINDSEY: Okay, so a pretty low number.
CHAD: Pretty low. Oh, here's one, flexible pricing for Buffer has 67 votes. So I think you can get a little sense of the engagement that's on there. But I like that there's no description on these cards. It's just a better way to manage campaigns in Buffer. So they're not saying what they're going to be doing. There are no timelines on any of these cards. It was only moved to in progress. And they're not saying anything on these cards from what I can see about when it's going to be done or what is actually going to be entailed in it. I encourage people to look at this. It's pretty good in terms of potentially ways to make a public roadmap work for you and your customers.
LINDSEY: And what about thoughtbot? We also heavily gravitate towards the Trello management.
CHAD: Yeah. This is clearly not their actual Trello board. It's a specific board created for a transparent roadmap.
LINDSEY: It’s a distraction.
CHAD: [laughs] Yeah. If we were going to do something like this…
LINDSEY: I guess I meant as far as tools; what are the things that you have seen work with…? My guess would be Trello because we use that a lot for managing projects.
CHAD: Yeah, we use it for managing pretty much every project. And longtime followers of thoughtbot will know that we used to use a tool called Pivotal Tracker. And then, we created our own tool called Trajectory, which doesn't exist anymore. But the big thing about that was it was really meant to address the flow between coming up with ideas and the design thinking that goes into evolving a product idea and then breaking it down into stories and doing the stories from there.
And we switched to Trello in part because of the flexibility of Trello. Trello is not specific to any one product or any one workflow. And so, the nature of software development is again a reason why product roadmaps can be troublesome because things change constantly. You're constantly learning. You should be meeting on a regular feedback cycle of not only how is our product working for people and what should we do differently, but how is our process of developing that product working, and what should we be doing differently? That's one of the great things about Trello is that because it's so flexible, you can say, "Yeah, we're having this problem with our process. Let's change it." And you can usually find a way to embrace that flexibility in Trello.
LINDSEY: And how do you know that your product roadmap is on the right track? Or what are some smells that you're going in the wrong direction? We talk about customers being happy. What does that actually mean, and what does that look like?
CHAD: If the things that are going into what you're doing on your product are coming from users, and then they're going back to them, and they're receiving usage, that's a really good sign. And a lot of teams look at and measure cycle time, so the total time for something that goes into the process to come out the other side and get in the hands of users. And a lot of teams really high functioning teams will be working to make that as short as possible. And one of the reasons why is because that gives a sense to your customers that your product is continually moving forward in a way that comes from their needs. And that's a really good place to be in. You know what I mean?
LINDSEY: Yeah, that makes sense.
CHAD: Do you use any products where you feel like they've got that flow working really well?
LINDSEY: As far as asking for feedback and then incorporating it into the product?
CHAD: Yeah, or even just that you use the product and you're maybe not even giving them feedback directly, but you have a vague sense of how your need might not be met. And they're releasing features and that kind of thing on a semi-regular basis where you say, "I didn't even realize I needed that, but now that I have it, it makes me happy." Or "Boy, that really solved this problem that I was facing."
LINDSEY: I think the one that comes to mind immediately is Slack, actually. I feel like their product releases often speak to something I was feeling. Like, I think especially they seem attuned to the fact that it can create a lot of noise. And so providing or increasing the different ways that you can personalize your own experience so that you can mute things or have certain kinds of notifications or be able to set hours that you're away and unavailable. Those releases, I think, feel especially personal when I see those come through.
CHAD: I think you're right. Slack is one where that would be the case. And it's worth noting that Slack does publish a roadmap, and they've been doing it for a couple of years. Particularly, it seems like, from the outside, a big part of what drove that and what's in their marketing around it is better setting expectations with their enterprise customers and that sort of thing rather than necessarily not meeting the needs of actual users.
LINDSEY: They also seem especially responsive and helpful out in the world too. I've seen multiple instances of folks I know tweeting about a bug or something in Slack, and very quickly, the Slack account is responding with how to fix it or notifying that it's been logged in, and they'll be following up, that kind of thing.
CHAD: So I'm looking at the Slack one a little bit more, and it seems like the roadmap is centered primarily around what they call the platform roadmap. So it's more like APIs and system-level things that they're going to be focusing on or adding rather than user-facing features. So it's more serving the needs of people who are building on top of the Slack platform versus saying that their product is going to have a specific feature at this time that's user-facing.
LINDSEY: That's interesting.
CHAD: Which makes sense because people building on top of the Slack platform who are really dependent for their business needs on the Slack platform are going to have high expectations for knowing what's coming and knowing that their needs are being addressed at some point in the future.
LINDSEY: Right. And on the enterprise side, as they're getting more enterprise customers, I imagine that could come into play as well where enterprise companies are going to have some dependencies or requirements that maybe the Slack team hasn't had to deal with before, which could be integrations. It could be certain kinds of security measures, which if they're definitely working on those or creating the necessary partnerships, it can also make sense to say, "We have in our sites this integration or the security measure coming by the end of the year," kind of thing.
CHAD: Yeah. So one that I have...and it's interesting because I think they've been doing a good job lately, but they went through a real period of time where I felt like they weren't doing as good a job with it, and it’s GitHub. So GitHub lately has done a much better job of, for me as a developer, as a user of GitHub every day, delivering features where it's like, yeah, this is awesome, and it fills a need or a pain that I was really having. Or I didn't even realize that I was going to need this feature, and now that it's here, I can't imagine it being any different.
And they do that, as far as I know, there's not a public roadmap for GitHub. And GitHub, I could be completely wrong on this; they do a conference. They do shows. And what they're doing at that is they're announcing things. So they're more on the sliding scale towards Apple, where they're announcing general availability or beta availability of new features at their events as opposed to saying, "Here's what the roadmap for the next year looks like."
LINDSEY: Which does create a forcing function of having things ready enough, maybe not launchable but ready enough that you can at least talk about it and talk about the timeline.
CHAD: Yeah. And we had the product manager of the payments that GitHub announced on a previous episode. Her name's Devon. And that's one of the things she talked about was working towards that deadline of that presentation and how stressful it was and making sure that they manage scope within that.
LINDSEY: So, do you think GitHub has been doing a better job since they were acquired?
CHAD: It doesn't so much match since when they've been acquired, but there was a period of time where...and maybe it could be that there's nothing GitHub-specific about this, but there's probably a period in every product's time where you go from this is a new thing, and so there are so many new features that are low hanging fruit. And you can quickly roll them out, bang, bang, bang for a long period of time. Your roadmap is just sitting there in front of you, waiting for you to do it. You don't need to worry too much about it. That's, depending on the product, probably six months, a year, two years, maybe even five years. But then you're going to work your way through that list and the things that you do next, particularly if you reach a growth stage, which means that your core customers may be different than your original core customers…where you can enter a lull. And you need to take some time to figure out what the next phase of your product looks like. It's possible that it happened with GitHub.
I tend to think that it's more that internally GitHub had real challenges. And we know it had some issues with sexual harassment and workplace issues like that. I think that really got in the way of GitHub functioning well. That's my theory. But again, I'm totally on the outside. But I do know that they went through some significant restructuring and addressing a lot of those issues and creating what is hopefully a more inclusive workplace where people can do their best work. And then good work started to come out again.
LINDSEY: As far as launching products or new features, it's always interesting and challenging I think with SaaS products where you're continuously releasing improvements and how you think about…again, from the marketing fun of it too a little bit, is like how you think about when is something like a new launch? When is something a significant enough new feature? Is this actually a separate product from what we've been offering? And sometimes, that can be really obvious. Going back to the reporting example, that's a nice kind of shiny new toy in your platform that you're going to have, like a dashboard. The difficult ones are performance improvements. But I was curious if you have any takes on that too.
CHAD: Yeah. What I've always done on the products that I've worked on...and thoughtbot has created several products that have been fairly successful not only for our clients but for ourselves as well. I've always favored not underestimating people's ability to absorb significant product changes as long as they're coming from a place of you know that they are needed. And that if you're shipping regular new things on a basis, not all of your customers know about that right away, and so you can take a marketing touchpoint for those changes. And even though you have a sense of urgency about communicating them right away, you do have some time to do that.
I think I said earlier when I was starting out, "Underestimate people." What I think I meant was overestimate. We, as people who are very close to the product, assume that the minute we deploy a new feature or a change that everyone in the world is going to know about it. And that's just not the reality of what it's going to be. So when rolling out new features, you have to communicate them to the people who are touching them and are who are hitting them.
But there are almost multiple layers of marketing and communication for any new feature that's going out, communicating with immediate customers that are touching a new feature, and then making sure that everything that's going out is flowing through marketing and is coordinated with marketing around what those touchpoints are going to be. And the general guideline that I've always used is at least once a month; there should be a major round-up or communication about a significant change that has been made. And I've always felt really good about the products that I was working on if we were in that cycle like we're continually delivering new things. But then, on a monthly basis, there's at least one new either individually significant thing that we can talk about. Or absent of that, doing a roundup of a theme of changes or just here are three major improvements we've made in the last month.
LINDSEY: Yeah, I totally agree. It's great to have those opportunities to engage with customers and keep them invested in the product, and looking forward to those regular updates as well.
CHAD: Right. So when we think back to Trello boards or roadmaps and that kind of thing, I don't think marketing should be…after that fact, marketing shouldn't be saying like, "What was just released? Can we know?" and then responding to it. Marketing should have insight into what's in the backlog, what's the next things that are going into production. What are the things we're planning now? And they should be contributing to that process because, in a lot of companies, marketing is going to be on the front lines of interacting with customers. So you're going to hear things, and you're going to see things and that should contribute to the process.
LINDSEY: Right. Ideally, the marketing team is also customer-facing and providing those insights as well and tapped into what folks are having challenges with or looking forward to as well as what else they have their eye on that others are offering or trying out that are your competition.
CHAD: So that's the cadence that when I'm in charge of a product, I've tried to achieve. It's easier to do in the early days of a product when, like I was saying, you don't even need the roadmap. There's so much low-hanging fruit, and everything is valuable, and the priorities are relatively clear. It's harder to maintain that pace far into your product's future not only because what you're doing is less clear and maybe less valuable to all of your customers but also that daily, weekly, monthly pace can be difficult to keep up indefinitely just from a sustainability standpoint.
LINDSEY: Yeah. I feel like sometimes I even see products incorporating content in those later stages as ways to keep folks engaged and updated and have that be a feature of the product, whether it's community-based or the company itself actually producing new content and incorporating that into the product.
CHAD: Yeah. So a really good example of that is (Boy, we've had a lot of good people on the podcast.) the folks at Wistia, which is a local company to Boston. And they're continually evolving what their product is offering. And they're launching new features. They're doing new things. But a big part of what you see publicly from them is also new content that helps people be better creators. So they are a good example that comes to mind of a company that does that pretty well.
LINDSEY: So, we're going to be talking to three other startups of different stages in different industries about how they approach their product roadmap. Any sense for what might be consistent versus what is different? I imagine you also have insight from seeing a ton of client projects. Are certain areas of product roadmap more consistent than others?
CHAD: I suspect what we're going to hear from the early-stage companies is that they actually have what...They're probably either going to say, "We have no idea. We're just flying by the seat of our pants." But actually, I think it wouldn't be surprising to me if there's just so much low-hanging fruit in front of us that that gives them a sense of a clear product roadmap. And they say, "Yeah, we do know. We do have a sense of what we're going to be doing next week and the week after." But they're going to not be so worried about what six months from now looks like.
And I think a common trend of later-stage companies is I wouldn't be surprised to hear that they're very focused on partnerships and external relationships in a way that early companies aren't. And that is one of the factors which we haven't really touched on is, anytime you start involving external people the same way with Slack; it’s like people who are depending on you for their own business needs outside of your users creates more pressure for you to set expectations with them and to introduce roadmaps. So companies that are really focused on that who have channels and partnerships and that kind of thing are going to have more desire or pressure to introduce some form of roadmap.
LINDSEY: Yeah. And in a way, that's the later stage companies' low-hanging fruit. When you bring in a partner, or you make an acquisition and immediately fill in a need that you've identified or an opportunity that you've identified, instead of taking your existing team to build it, or hire a team, or work with someone like thoughtbot.
CHAD: Yeah. And it could be that that is actually totally the right thing. Because if you give everybody the benefit of the doubt and you say, "This product has been well-managed and user-centric to meet the needs of the users, then you're going to get that cycle." In the early days, we know what we should be doing, and our users are telling us. And we've got a lot of things to introduce into the product to fully meet the needs of those customers. And you're going to do that, and it's going to serve you for a really long time for delivering new things to them.
But at some point, again, giving the benefit of the doubt, assuming you've done that and things have gone well, there is a point at which you say, "We've delivered all of that. And we have a product which is meeting the needs of our users. It's fulfilling the job to be done of those users." You say, "Okay, great." So we're either bringing new people in who might have different needs and different jobs to be done. Or we are exploring other business opportunities like bringing on partners and opening up new channels which have their own needs that are driving your product roadmap, or they're bringing in customers who have a different job to be done.
LINDSEY: And honestly, it's an easy way for early-stage companies too to add a partner and gain access to their audience. But it's not likely that they're going to want to partner with you [laughs] because you're not bringing anything to the table, so you got to do that building first.
CHAD: Yeah. So we'll see what they say. I'm looking forward to the conversations. So, Linsdey, you have some personal news.
LINDSEY: Yes. With mixed emotions, I'll be moving on from thoughtbot and the podcast.
CHAD: This comes as a complete surprise to me. You're just springing this to me on the podcast.
LINDSEY: I know. I know I told you I wanted you to join five minutes earlier. And it's inappropriate.
CHAD: [chuckles]
LINDSEY: No, that's not true. I used all the proper channels. I read the handbook. But yeah, end of an era, moving on. But dang, it's been a lot of fun, hasn't it?
CHAD: It has been fun. It's been great working with you. The impact that you've had on thoughtbot will be long-lasting. It was significant and long-lasting. I think that you joined at a really interesting time. Pandemic and all that stuff aside, completely separate from that, we were going through important transitions, and I think you're an important part of this. I remember commenting to you not long after you joined when you gave the first company-wide presentation that you were the first person I think who had ever done a full company-wide presentation like that, besides me.
LINDSEY: Yeah. Wow. This feels like so long ago.
CHAD: And you're just so fun to work with and collaborate with and just be a team member with that you're definitely going to be missed. So thank you for everything.
LINDSEY: Thank you. I am definitely not tearing up. So no one has to worry about that. It's hard to look back without getting choked up. It's been a really great experience. [laughter]
CHAD: I'm glad to hear that. You brought so much to the table. We learned a lot along the way, and it wasn't always easy. We had a marketing team working in a certain way, which went through a big change. I think we learned a lot about how the next phase of thoughtbot needs to work, and I think you're an important part of getting there. So thanks again.
LINDSEY: Thanks for having me. Thanks to all of you for listening. And I'm now available as a guest, which is the great news.
CHAD: [laughs]
LINDSEY: And I almost know how to set up all my recording settings, so that's half the battle. But it's been real, and thank you for the opportunity from the experience.
CHAD: So we will be back in a little while with new episodes of the show. You can subscribe to the show and find notes for this episode at giantrobots.fm.
If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel.
This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. And for all you listeners out there, I'll talk to you next time. Bye.
Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.
Support Giant Robots Smashing Into Other Giant Robots