October 30, 2020
Ep. #66, Studying The Stack with Anthony Campolo
In episode 66 of JAMstack Radio, Brian speaks with Anthony Campolo. They cover topics like tutorial-driven development, the Lambda School ex...
In Episode #10 of Practical Product, Craig and Rimas are joined by Suzie Prince from ThoughtWorks. Suzie explains how as a product manager she had to make the difficult decision to shut down her product, Snap CI.
Suzie describes her learnings from that experience and shares practical tips on managing a product end-of-life such as piecemealing the announcement, gradually removing product functionality and rotating staff who support the product.
About the Guests
Suzie Prince is Head of Product at ThoughtWorks. Suzie has over ten years experience designing, building, and delivering software for large and small organizations in a variety of domains. She has also worked as Product Manager on SnapCI and Mingle.
Rimas Silkaitis: Welcome to another episode of Practical Product. I'm Rimas.
Craig Kerstiens: I'm Craig.
Rimas: And today with us we have Suzie Prince.
Suzie Prince: Hello.
Rimas: So Suzie works at ThoughtWorks Studio, but I'll actually let her introduce herself.
Suzie: Okay. So I'm Suzie Prince. I work at ThoughtWorks, and ThoughtWorks is a global technology consultancy, but we also have a small product division building tools for software development teams, and I am part of that product division.
Rimas: Awesome. Can you give us a sense of what product you work on there?
Suzie: Yeah, we have four different products. Two of them are in the continuous integration and continuous delivery space. One I have been working on more closely is called Snap CI, and the other product is called GoCD. And then we have an agile product management tool and a test automation tool.
Craig: I think that makes a lot of sense. I've seen a lot of consultancies try to spin out their own products. They say "hey, we're going to do consulting here, and then we're going to spin out some products." I think with CI, CD, I imagine you use a lot of those products back for customers on the consulting side and that sort of thing. So could you share a little bit onhow that started? Just kind of curious for some background context.
Suzie: Yeah, I would say that part of it is definitely out of our own needs as consultants. You know, we have product ideas, we're out on the client site and we want to sort of make those into real life and deal with the problems that our clients have. The other part is ThoughtWorks has three pillars, and one of those pillars is about educating and revolutionizing the IT industry, changing how people work. And the product part is really about that influence, how we change other people, how they work outside of the consultancy that we do.
Rimas: So changing gears a little bit, how did you get into product management?
Suzie: I don't have a technology background. I actually was a biological scientist.
Craig: That's not allowed for product managers.
Suzie: So I studied botany, and then I wanted a real job, so I joined ThoughtWorks to do consultancy. So I was a consultant. And one of the things that used to frustrate me a lot was about software being built without really thinking about users. I used to see that a lot in corporate software that we would do. So I sort of moved over to the product side where I felt like I could spent more time with users and building, products that really did help them, rather than just shelfware software.
Rimas: Well, that's the basis of being a product manager, right?
Rimas: Just all about the customer.
Craig: I think that's all helpful context, but I think we have a very different topic we want to drill into a bit today.
Suzie: We do.
Craig: Shifting a little bit, and this is kind of one of my favorite things as a product manager to do. And often not the thing that gets the most credit, and that's talking about, shutting down projects. How do you, how do you kill a feature, how do you kill a product, how do you get rid of something? Because a leaner product is usually much easier to maintain and healthier for the long run. How do you do that from a feature standpoint, a product standpoint? I want to drill into some of the aspects of that today.
Rimas: Well, actually, let's back up just one second there. A little bit more context. What actually was being shut down or deprecated?
Suzie: So the product that I mentioned, Snap CI, it's still in its end of life process. It's a hosted continuous integration tool for developers.
In February we announced the end of life for that product. I was the product manager and I made that decision.
Rimas: That's a whole product to shut down.
Rimas: So I'm sure there's a ton of questions.
Craig: Hang on, we glossed over one thing there. You made that decision. So you just put yourself out of a job?
Suzie: No. I had the lucky fortune that ThoughtWorks is a nice place and we look after good people, so now I get to look after the other products in a head of product role. But yes, I was part of that decision.
Craig: So it is a healthy decision.
Suzie: It's a healthy decision, yes.
Craig: And I think that that often is overlooked when you're killing features, killing products, like, there's still plenty of other work to be done.
It's not like winding down a company. Many times winding down a product can be very healthy.
Suzie: Yes. And I think that that is definitely my outlook on this particular decision. It was the right and correct thing to do for ThoughtWorks and for our little product division that we are.
Craig: So I think there's probably a lot of things to dig into. Maybe start at the beginning. How did you even get to that decision? What was that process? Can you just start to walk us through it?
Suzie: Yeah, so I'll give some context about the product. It's a SaaS based product for software developers, and it's part of two products that we have in a similar space, so continuous integration and continuous delivery. This was a hosted tool for smaller development teams, so teams that don't have big build and release teams. They don't have dev ops teams. And then we have GoCD, which is an open source on-premise tool for much larger organizations.
And they were two different segments, and we wanted to run the two products together. And we really had to focus on those two themes, continuous integration and continuous delivery. And over the first few years of Snap's life cycle, it was doing well, adding people, getting feedback, all the good stuff. We all felt great. And then over the last year, which is actually the year that I was running the product, I actually noticed that that growth was actually becoming a bit more stagnant.
So we would add people every month, but it wasn't, you know, growing in a linear way that it had before. And if we compared that to how Go was doing we saw much more acceleration of growth. When we were looking at our portfolio of products, one of the key things we were really thinking about is where do we want to put our effort in terms of these two different tools? Can we do both? And so that was sort of part of the decision based on what we saw was happening in Snap and then also what could we use our resources for if we're not doing Snap.
Craig: Can you share a bit on the, like, sense of magnitude of how that got stalled. Was it like you were signing up 1000 users a month and that dropped to 100, dropped to 10, like what was that spread like? Was it slow, or was it kind of like there was a sudden big dip? How did, how did you know? How does someone else know that, like, things are slowing, but it's okay, I'm reaching a mature business, right? Which is some cases.
Suzie: It wasn't a drop, for sure. It was still sort of going up slightly. But we were always in sort of hundreds, not thousands. And so I would say, if it was plateauing, it wasn't plateauing at the level that we would want it to have been plateauing at. We did a bunch of user research around what people were looking for and what our messaging should be. We just really didn't think that we could do what we wanted to do with the product and still meet the needs of people in comparison to the sort of acceleration that we saw in the other product.
I think that the key thing for us is not necessarily the revenue, which I think it might be for a lot of people. It's that we wanted to impact lots of people, and we just really weren't impacting as many people as we wanted to.
Rimas: The decision I'm looking at is you could've either kept going with the product or shut it down. Could you have put more product marketing into this, content marketing, and maybe made it happen?
Craig: If it was about the impact could you have dropped prices?
Suzie: I think that we definitely talked about a whole bunch of those decisions. It wasn't a decision that we took lightly. I think that we run products in a very lean way, so we had less than 10 people on this product.
So there definitely was an opportunity. I think we had five developers, a couple of people doing marketing, myself, and some support. So, that's small. We could've pumped a lot more into that.
In terms of all of the resources that we had for all of our products, we had to make a choice, "are we going to put more into this product or more into another product instead?"
And so I think that maybe another organization would've made a different choice if they had different levers they could've moved. But really for us, it was a choice between putting into this product and hoping or putting into the one that we already saw was increasing.
Rimas: Okay, so, you know, the title of the show is Practical Product. I would like to get into some tactical things when it comes down to shutting down a whole product line. Can you kind of give me kind of a timeline. How do you message to customers to say "hey, sorry, this thing's going away?"
Suzie: Yes. So we made a decision in January, and we had to go through some process internally, you know, make sure that all of our leaders felt good about that decision. And transparency is really important, so we wanted to tell our customers as soon as possible. So I think from telling our internal, those 10 people on the team, within a week we had actually told a lot of our customers personally, and then we made an announcement.
So it was very quick between actually really making the decision and, telling our customers. I think that was good, because we wanted to be transparent, but it also was a big shock for them, because we really went from behaving like normal to then suddenly saying, "now it's over." And I think that was tricky. How do you warn them? I mean, you can't warn someone that it's going to happen. But it felt really strange, because for us we're like, "we need to tell you now," and they're like, "whoa, what? You just released a new feature."
Craig: I'm sure you're announcing something, then you're suddenly, "its the opposite." What do you feel like went well in that process? What didn't? It sounds like there's a really quick turnaround. How do you even prep for that in one week?
Suzie: Yeah. I think that the transparency, I do feel good about. I also feel good that we provided a lot of information when we made that announcement, so we provided the timeline that we were going to run for what would happen during that process. So we decided not to continue charging for the product. So we explained all that. I would say the thing that perhaps was a bit too much is it was a lot all at once.
So it was like, "hey, we're making an announcement, and here's all this stuff you need to know." And I think people were like, "oh, hang on." So now we're getting these questions, you know, "oh, can I do this, can I do that?" And we're like, "oh, we did let you know." But I think it's just because at that moment, the shock of the shutdown was all they really read, and they didn't think about the other things that were shared.
Rimas: So would you extend that timeline out?
Suzie: I think that perhaps we could've just made the announcement on that day, and then maybe in the week following provided the rest of the information.
We felt at the time it would be best not to have a void of information, so we gave it all at once. But I think in retrospect I would have piecemealed it out.
So what we've done now is just we're now repeating it on a regular basis so that people can find it.
Craig: Yeah, that's something I've found that's very key, that and especially as you get closer to that date. Like, if you're ashutting something down in six months you tell them six months out, then you tell them three months out. Then you tell them, you know, six weeks, one month, three weeks, twice, you know, two weeks out. And every day that final week.
Suzie: And that's what we've been trying to do, and from a practical point of view,
We gave it six months, but we're actually removing features sort of down that timeline. So in the first three months, nothing's really changed except we're not charging, and then after three months, you can't add new users and you can't add new repositories.
So that people can remember, "oh yeah, I shouldn't be adding new stuff."
Rimas: That's a fascinating tactic, actually.
Craig: Make it a little worse for them to give them the incentive.
Suzie: Yeah. We'll see how it goes, but yeah, that's the idea.
Craig: Maybe as a database, we could introduce intentional downtime and just see if people migrate their data faster.
Suzie: Just accidentally delete something.
Rimas: I can't tell you how many times we've gotten to the shutdown date and customers still have not yet done any migration work. I mean, it is, it is shocking how often that happens.
Craig: So you hit on one point in there. You talked to customers personally. We just kind of flew by that, but I think that's actually another huge one, as well, that a lot of times when you say, hey, I've got 10,000 users, I've gotta send an email. Who did you talk to personally? How did you prioritize that?
Suzie: Yeah, so there are a set of users, that I had more personal relationships with. Either because they've been using the product for a long time or they're our largest customers or they provide the good or the worst feedback. You know, some relationship that I had with them. Then we also had customers who use some of our other products, so we wanted to talk to them personally. So we basically selected amongst myself, people in our support team, and then we do have some sales for some of our other products.
Sasically, who are the people that we don't want, you know, we want to have special handling and make sure they feel comfortable, give them advance warning. Some of them have been with us for a long time. So it was more about we didn't want to lose their trust and just sort of blast them with a blanket email.
Craig: And did you learn anything from those, like, one-on-one conversations that you rolled back into the larger communication, or any kind of takeaways?
Suzie: Yeah, it was a really good. I think it's why we ended up with so much information in the first blast, because it was every question that they asked, we made into an FAQ, and so there it all was. So we did learn a lot. People were curious about why we made the decision, what was going to happen over the timeline.
We actually also provided a timeline that said "in month one, you should be looking at other tools, in month two, you should move your new builds to another tool."
So we provided a timeline. Because a lot of them were like, "oh, how am I going to manage this? We normally do this when we change a project, not in the middle of a project. How am I going to do this? So yeah, we learned a lot from doing that.
Rimas: Now, being a little bit more tactical, did you make any recommendations to other products to move to, and did you provide kind of a migration path for them to do so, and in doing so, does, is there risks of seeing, of being seen as, like, being too favorable?
Craig: And I'll add onto that. Like, did you talk to them ahead of time? Did you coordinate with them to make it easier? Was there any collaboration there? So a few things packed in there.
Suzie: Yeah. That is a really interesting question, and I would say that we went back and forward and probably used some of that feedback from those initial conversations. My gut feeling was that we should provide direct migration to another product, and that of our competitors, because that's what they were before this, we should select one and go have a conversation with them and say, "hey guys, we're going to do this."
And then when we talked to the first sets of customers, their opinions on what they might go to, because that's one of the questions we asked, were so varied. I think we got 10 different hosted CI tools that they wanted to go to, and some of them thought they would go to an on-premise tool. So I was surprised.
Craig: I'm trying to think if I can even count 10. I know there's a lot.
Suzie: There's a surprising amount.
Rimas: I can only imagine the death match. Like, put all 10 in one place and tell them to fight. And whoever comes out, we'll recommend you.
Suzie: Yeah. One of our customers has actually written his own comparison, and I think he has 15 or 16 on that list that he tested as, I think he called himself a Snap refugee. And he said, I'm looking for something. And he tested 16 tools, so I was like, "okay, I have a week to do this. I'm not testing 16 tools and doing this ourselves." So what we decided to do instead is we provided a migration to our other tool, because of course we would do that.
And then we provided a very generic export of the information that they had in Snap so that they would have more, like, a readme for what they have set up that would help them move to another tool. So it's not a direct migration, but it's more like a, it's a YAML file, and it prints everything out, and it should make it a lot easier. And then in the absence of a direct migration, we offer what's basically consultations with people who wanted advice about what types of tools.
So we created a questionnaire, why did you like Snap, what are you looking for, what is important for you, and then provided some recommendations instead, rather than a one to one tool for them.
Craig: So after the announcement and you went down that path did you get the question of, "what should I move to" much?
Suzie: Yeah, I would say not everybody asked us. I think everybody sort of has their second tool or something somebody's recommended. But I would say more than I expected. We did phone calls with people, and we're still getting requests now, "I'm down to the last three. Which one should I pick?" You know, whatever works for you. It's hard, you know, it's a hard choice.
I feel like that worked really well because we care about these people, what choices they make, and we want them to have trust in us, and I felt like having those conversations really helped us end the relationship in a good way.
Craig: So I think a lot of this comes back to core kind of product culture principles. It sounds like picking one and giving them migration would've been a bad choice. It kind of depends on what is the relationship you're trying to build with your customers.
Suzie: Yeah. At first, I thought it would be the right choice, because that would be easier for the customers, right? I've made a very clear choice for you. But then in retrospect, I thought, when we got that feedback, that one choice is not going to be right for everyone. It may be even more work for them to move to that. So instead, just advising them and hoping them can find their place.
Rimas: So the lesson for me I'm taking away here is that even during product shutdowns, go talk to your customers and figure out, like, what the best way to do this is.
Suzie: Yes. We also ran a survey to find out how people reacted, because, not that we intend to shut products down all the time, but you want to know, what impression does that leave for people, how did they feel, what were their feelings about Snap. We had a lot of information making the decision, but part of it was me going like, well, you know, one final chance, was this the right thing to do? So we also did that. I think it's important to keep talking to people.
Craig: Yeah, I think something that's key, too, like, when you shut down a feature within a bigger product, like, the way you do that, customers will notice. And you may not be killing the entire product. And keeping your customers, but you might have to kill a feature, and there's good reasons to do that, and not everyone's going to love it. There are customers to whom you can't say, "hey, 99% of customers didn't use this" to that 1% of the customer, because it's probably not, they're not going to like that too much. But you can give the basis why, do it in the right way, and it goes a long way.
Suzie: Yeah, I would agree.
Rimas: So going back to customer reactions, did you have anybody at the end of this that said, you know, "thank you, I really appreciate everything you put into this?"
Suzie: Yeah, we, I think we got a variety of different feedback, but one of the clear indicators was, you know, "thanks for building this, thanks for doing it, we're really going to miss it." And I think some of that was indicated by them saying, " I really can't find another tool. Please, please help me. Nothing else does exactly what this did." And that's really great. And then we had some people who were like "I might not trust you again for products", which I think for me, you know, it's a little heartbreaking.
But I sort of understand that, because we shut down something that they really found value in, and now they're a little hurt by that. I'm hopeful that in the end, we'll win them over.
I think it's important to acknowledge not everybody is going to feel the same way. Even if you really try to make them feel good, you are taking something away from people that they used every day.
Rimas: So how can you parallel the reactions that you got to shutting down an entire product versus doing something like a product launch? Because, you know, in PM world everybody loves the launch. We do that the most often. You know, is there parallels in the reactions that you got between the shutdown and kind of that product launch scenario?
Suzie: Yeah, I think so. I think being really thoughtful about the impression that you want somebody to have about your product and then your larger brand. One of the things we really wanted to think about is ThoughtWorks as this much bigger company that does a whole bunch of different things. This thing that happens with Snap, we need to think of how this is going to leave an impression about people in ThoughtWorks?
I think that's the same with a launch. Whatever you're doing, you need to be mindful about what impression are you trying to leave in somebody's mind, what are you trying to create there for them, and how does that reflect across your larger organization, or how are you going to build on that feeling that they have about you? So I think that part is probably parallel.
And then for a PM, I feel like, you know, I try to be, it can be a pretty emotional decision, the shutdown, and the launch is an emotional thing, as well. I feel like one of the things I had to do is sort of remove my emotions from it. These are my colleagues, and as you said at the start, my own role, but I need to be sort of removed from that and be really clear about what is this decision. And I think with a launch, you sort of have to avoid the excitement and focus on what we are really trying to achieve here?
Craig: We talked about product launches, and one of my favorite things to do is kind of write down the headlines you want to kind of land. Did you do the same thing with customer reactions to the shutdown, to say "this is how I want a customer to react. This is what I wanted them to walk away saying." Did you create those goals ahead of time so that you knew if you hit that goal?
Suzie: Yeah, we didn't do the headline thing, but we had a very clear persona for the main person that used our product, and we did talk about what did we expect their reactions to be to the news. So then when we did the feedback survey, that was actually one of the things we were looking for is. It was maybe more a test for ourselves. Did we really know this person? We wanted to look like, did they react in the way that, you know, the statements that we had written down that we thought they would say or how they would respond. Did we get that? And I think in the majority of cases, we did, and then we had these, like, extreme cases, as well.
Rimas: Of course. Even in a product launch, there's people that are going to hate on anything that you throw out there. Would you say that this shutdown is a success in some sense of the word?
Suzie: Yeah, I would definitely say it was a success. I mean, I feel like I have to judge it that way, as well. But I feel like, for a couple of reasons, I think we could've carried on doing the product. That was an option for us. And that team was running really lean.
I think they would've got more and more tired, and perhaps more and more demoralized by the fact that growth wasn't increasing.
So I think one thing is the timing of it. I think that was successful, that we didn't wear our colleagues out. And the majority, the vast majority have gone on to other products in our product suite. So we didn't lose people, and that was great in terms of the team. And then externally, I think that the timing also. People would've started to notice, we'd been having these discussions. And it was, maybe tiring on us, or externally, that would've been aware. So I feel like the timing was good, and then the messaging, I think it went as well as it could've done.
Craig: So you announced it about three months ago or so, right?
Suzie: We announced it at the start of February.
Craig: Okay, so a couple months ago. It's not fully shut down yet. There's still some time to go. Is there still some of the team on it? How much is it on life support? What's the balance there right now on the team?
Suzie: Yeah, so we basically have no active new development, obviously, so no new features. But we always have people on support for it, so somebody's maintaining the systems, you know, making sure everything's running, keeping the hosts up, and all of that kind of stuff. And then any major support issues, which are actually minimal at this point because usage is obviously dropping off.
Craig: Is that wearing on the team at all, the people that are kind of still on support and not on the cool new thing? Like, the people that aren't over on Go?
Suzie: Yeah. They're okay.
We actually rotate. So they only have to do it for a week at a time, and then the rest of the time they get to work on cool new stuff.
So I think that, because the products are fairly similar, it's not, like, a whole new thing that they're having to remember. So I think they feel good. I think for them, they wanted it to be a positive experience, as well. You know, they put effort into this, and I'm actually really proud. No one was like, "well, screw that" and walk away. Everyone was like, "we want it to be good for people as they roll off."
Rimas: Is there anything else that you think our listeners should know when it comes to product shutdowns, from a PM perspective, tactically or even strategically?
Suzie: Yeah. I think that a lot of PMs are probably afraid to say, "I think we should shut down this product." And I think for me, when I started to see this trend, and knowing what we were trying to do with the rest of our products, I knew that this is a conversation that we had to have. And I think that product managers are the people who have to say that. This might be their baby, or it might be a founder's baby, or somebody else who really loves this thing.
But if you don't think it's achieving what the organization is trying to achieve, or it's not doing right by its users, or you don't see the future, I think it's part of your core role to be like, "hey, we need to have this discussion." And I don't think it should feel like a failure or a bad thing. I think it's, yeah, actually really paramount. I rarely see product managers talking about, like, "hey, I need to talk to my business about this product." I see a lot of people, like, cranking it out, churning on, keep going, tweaking things, and I feel like it would be much better if we were all just like, "hey, is this doing what we want it to do? No? Okay, let's do a good shutdown."
Rimas: Well, you know, in some cases, though, if you talk about shutting down, it could be for the entire business.
Suzie: Yes. I do have the benefit of there being four products in this much larger organization, so there's obviously a sensitivity around that. But even in this case, you know, it was somebody on my team's idea, this product was, and there were people who've been working on it full-time for a long time. So it was still sensitive. But yeah, I appreciate that. It's not as simple as, like, 10 people moving on to a different thing.
Craig: And I think some people have the same feeling toward features, too. But, like, the overall long-term health is much more sustainable, and thank you for coming on to talk about it. It's a thing we don't talk enough about in product and is super key and useful and valuable, and should be a thing that we value the same way as launching and shipping.
Rimas: To be quite frank, you know, that is actually the distinction I use to separate the product managers that really, you know, have their salts, that have done some really serious work. A shutdown is not something to be taken lightly, and the fact that you've gone through it, you've done it, you've got a bunch of experiences to talk about it, that is a mark of a serious PM and someone that has the broad swath of experience.
Suzie: Yeah, I would agree. Don't shut down all your products. But think about it. Think about your features. Start with features.
Rimas: We are not endorsing you to shut down your products right now, okay? Just keep them going, but just remember that's a tool in your back pocket.
Suzie: Yeah, I really think it is, and not to feel ashamed that you had to do that.
Rimas: All right, thank you, Suzie, for coming on today. We really appreciate it. I learned a lot about shutting down a product. And again, thank you for your time.
Suzie: It's great to be here. Thank you.