Episode 78: Why Build A Brand New Product Instead Of Rebuilding Or Redesigning One

Happy November!   November is one of my favorite months mostly because I love Thanksgiving. Last year I had a wonderful time celebrating it with Meghan Burgain, Femgineer’s Community Manager in Bordeaux, France. We had a Frenchgiving, and had the opportunity to share how Meghan works remotely.   This November we’re going to be tackling a new theme on Build: building a brand new product.   If you’ve been building a product for a while, you know it’s natural to start accruing tech debt and product debt. And there comes a point where it becomes really hard to add new features without paying down the debt through rebuilding or redesigning the product.   However, there may come a point where neither of those makes sense, and you may be evaluating building a brand new product.   The Pivotal Tracker team recently did this. In today’s episode, Lisa Doan, who is a product manager for Pivotal Tracker and Vera Reynolds, who is a software engineer for Pivotal Tracker, are going to walk you through how they came to the decision to build a brand new product.   As you listen to today’s episode you’ll learn:   What spurred the conversation to consider building a new product Why the team chose not to redesign or rebuild the existing product What the team did to identify the problem it was solved with the new product Why the team held off on coding and building and what they did instead Why software engineers benefit from being involved in the research phase of a brand new product How to recruit new teammates to help build, and identify knowledge gaps -- Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. -- ## Why Build A Brand New Product Instead Of Rebuilding Or Redesigning One Transcript   Poornima Vijayashanker: It can be really tempting to want to redesign or rebuild a product that's been around for a while. But often, it's much more of an undertaking to do that redesign and rebuild, and it can be easier to instead build a brand new product. The Pivotal Tracker team had to do this recently and in today's episode. they're going to share how they evaluated building a brand new product. So, stay tuned.                           Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debug a number of myths and misconceptions related to building products, companies and your career in tech. When you've been building a product for a while, it's natural that you start to see tech debt and product debt accrue to a point where it backs you into a corner and it's really hard to add new features without rebuilding or redesigning it.                           But at some point, it may not make sense to keep adding to that product and instead, you may want to build a brand new product. In today's episode, we're going to dive into why you may decide to build a brand new product instead of redesigning or rebuilding your existing one. To help us out, I've invited two lovely ladies from the Pivotal Tracker team. Lisa Doan, who is a product manager for Pivotal Tracker as well as Vera Reynolds who is a software engineer on their team. Thanks for coming on the show you two.   Vera Reynolds: Thank you for having us.   Lisa Doan: Yeah, thank you so much.   Poornima Vijayashanker: I know that Pivotal Tracker now has been around for over 10 years, has over 100,000 active users and there's just been a lot of features, and a lot that you've accomplished in the past 12 years. And so, adding to it might have been a challenge and that's why you decided to go a slightly different direction.   What Spurred The Desire To Re-Evaluate The Product                           But before we even go and talk about that new direction, let's talk about what even caused this to happen. Let's get in a time machine, go back in time. What spurred the change for a different direction?   Lisa Doan:  It was really a confluence of a lot of different things happening all at once. On the product side as a team, we were frustrated because we weren't able to really deliver major features that our customers had asked for. On the engineering side there was a lot of tech debt, and a lot of frustration working in the code base. And on the customer side, there was also a lot of frustration that we hadn't really put out major features in a long time and our product had somewhat stagnated.                           All of that led to us realizing that we needed to do something big, but there were so many things in our way that we wanted to deal with. That's kind of what led to the origin of our project.   Poornima Vijayashanker: Can you give us a timeline, like roughly when did that start?   Lisa Doan:  I think as a team we started to recognize about a year ago that something big needed to happen. It's just been a gradual process since then.   Signs That The Product Needs To Change   Poornima Vijayashanker: Looking back, can you point to maybe a cause or several causes that led to the product starting to decline?   Lisa Doan:  Sure. The product was actually born out of an internal team. Pivotal itself started as a consultancy. Back in 2006, there wasn't a great backlog management tool, and so the engineers built one that suited their needs. But because of that, Tracker was always a bit of an accidental product. We built it for our own needs. But, clients would then ask to take it home after engagements and then it just grew virally there.                           Because of this, we never really had a clear mission or vision. It was just something that we built that we had a problem and then we solved for. That over time became a problem because we added all these different customers, but they had varying problems and we didn't have anything to pin our work too. We didn't have a strong opinion on which direction we should take the product so that led to lots of different features that were kind of scattered in how they addressed user problem.   Why Choose NOT To Redesign Or Rebuild A Product   Poornima Vijayashanker: I know in the next episode we're going to talk a lot about how you changed your engineering and your product team's whole process, so we'll pause on that. What I want to talk about now is why you decided against redesigning and rebuilding Pivotal Tracker.   Lisa Doan:  In maybe October of last year, as a group we had finally realized that we were at this point that we needed to make a big call on something and the initial thought was like, yeah, let's just rebuild. it's just so much easier, the code base is so challenging. No one wants to work in it anymore. Because it was an accidental product, there was never a strong architectural vision so it was all sorts of different tech stacks everywhere.                           So, we decided that we were going to have this team go out and they would re-envision Tracker. We even called it Tracker, but Better. Really quickly we realized that wasn't such a great idea. Tracker was built for a specific problem, which is backlog management. That was the problem in 2006.                           But here in 2018, the problems are different. There are lots of different backlog management tools that any team can choose and tailored to their specific needs, and Tracker has kind of falling behind on some of those things. At the same time, the problem that all of our customers have is around knowing what to build.                           Teams now know how to build software pretty well and there are lots of tools they can choose from, but how do they choose the right product to build? Tracker doesn't solve for that in any way at all.   Two Paths: Maintaining The Existing Product And Building A Brand New One   Poornima Vijayashanker: So, you make the decision that you're going to build a new product, and the Pivotal Tracker team is going to continue building that because there are two different needs, kind of two different missions and visions. Let's dive into what happens next with the new product.   Lisa Doan:  One of the goals for our team was to go back and reconnect and realign with a larger organization. Tracker kind of had its own destiny within Pivotal, and we wanted to make sure that both Tracker and whatever initiative we started with our team were more aligned with Pivotal. One thing we did is, we went back and talked to our leadership and we talk to other users within the organization to make sure that we were following their pain and solving the right problems for them, whether it's within Tracker or within your products.   Poornima Vijayashanker: You're at a point now where Tracker is continuing to be built by a team. You form a new team to discover what this new product is going to have in it.   Lisa Doan:  Sure.   Identifying THE Problem To Solve   Poornima Vijayashanker: So, what are some next steps?   Lisa Doan:  From Tracker, we knew there was a big space of problems that our users were dealing with, and so we wanted to really dig into that. Another goal that we had was bringing our team closer to the Pivotal Organization. Overtime, Tracker had sort of become a silo on its own, so part of our team's goal was to reconnect with the broader organization and make sure our product is aligned with that.                           So we went out and talked to various stakeholders. We talked to the CEO, we talked to the leadership in cloud and R&D and understood where they think the business is going and how we could support that. We had to rebuild a lot of those bridges, but it's been extremely valuable because they provide us input that we didn't have previously that helps guide us in terms of the decisions we make when we're building this new product.   Poornima Vijayashanker: What became the focus of this new product?   Vera Reynolds: To get a little meta, we've been using Tracker to develop Tracker. It's a great tool, and it allows teams to go fast. However, what it doesn't help with his direction. One thing we've noticed is that we as a larger Tracker team have been going fast for a while, but we've been struggling with direction. That's the problem space we're trying to solve with the new product, east to compliment Tracker in a way that allows you to find that direction and continue on it.   Poornima Vijayashanker: Got It. So you're now in a new problem space. Then, did you start getting your hands dirty? Did you start writing code? What's the next thing that you did after that after you defined the problem space?   What To Do Before Coding And Building A Brand New Product   Vera Reynolds: We did a lot of research. I say that kind of tongue in cheek a little bit...   Poornima Vijayashanker: How many months?   Vera Reynolds: I'm an engineer, so it was a learning experience to put it mildly.   Poornima Vijayashanker: How many months of research do you think you did?   Vera Reynolds: We did about four months. Is that right?   Lisa Doan:  Yeah.   How To Experiment Before Building And Coding   Poornima Vijayashanker: A lot of the time that you were doing these, were you also running experiments or something else?   Vera Reynolds: Yeah. We actually had a Lean startup coach that worked with us for some time. She really helped us understand those practices because there was a lot of paralysis early on. As we started exploring this new problem space, there was just so much that we, not hadn't thought of, but we hadn't seen eye to eye for a while. There was a lot of things we could solve, and you get a little bit distracted like a dog and a pavilion of squirrels or something.                           So, our coach really helped us develop a practice where we create experiments, like you said, we talked to users and we had really a defined assumption so we're trying to debunk, or prove. We did about 30, I think, experiments before we started building. So, we took it really serious.   Poornima Vijayashanker: Wow, 30 experiments. What did these look like?   Lisa Doan:  There's a huge range. We did a lot of generative interviews where we just sit down and talk with customers. We've also generated prototypes, put those in front of customers and see how they interact with them. We've also done fun things like feature fakes and experiments with the existing products to get a feel for what our customers are really looking for.   How A Feature Fake Can Help   Poornima Vijayashanker: What's a feature fake?   Lisa Doan:  A feature fake is where you build the facade of a feature and you present it to your users as if it's a real thing, and then see how they interact with it. If they like it; and then you gather feedback around that to see whether or not they had a positive experience or if that's something they might be interested in before you actually do any of the work to build it for real.   Poornima Vijayashanker: After 30 experiments, I'm sure you uncovered a lot. How do you decide to whittle things down?   Vera Reynolds: Some of the things we've done came from Pivotal Labs like discovery, framing and inception, those are early stage meetings that help you scope your work and decide what you're going to build. You have to remember, we were still in that phase of research and we were always trying to keep each other accountable about not building things prematurely and not building too much. We use those practices and we had a meeting where we wrote just the bare minimum stories we needed to accomplish in order to have an MVP and started there.   How To Pare Down Customer Insights And Scope A Prototype   Poornima Vijayashanker: After 30 experiments, I'm sure you've got a lot of customer insight. How do you whittle that down?   Vera Reynolds: As part of every experiment, we wanted to end on a headline or major learnings and pain points that our users needed to be fixed. That kind of gave us a list that we could start with. We started there and wrote down features. We actually aren't continuing experimenting as we're building. We're validating prototypes and making sure we're only building the minimum things and only building what we need.   How To Handle Knowledge Gaps On The Team   Poornima Vijayashanker: Got It. Did you ever run into knowledge gaps where people on your team didn't know?   Vera Reynolds: Yes, yes we did.   Lisa Doan:  So many knowledge gaps.   Vera Reynolds: Pivotal Tracker is a very engineer-centric team. For better or worse, and I think there are strong engineer practices, but I've never had done user research until this team so there was a lot of knowledge gaps there for sure. For me as an engineer, and I'm sure Lisa can agree as well with Lean practices and experimenting fast and focused learning, things like that.   How To Assemble A Team To Build A New Product   Poornima Vijayashanker: Got It. How did you go about assembling your team together because I know like you said, you had your Tracker team and then there was a new team together. How did that come about?   Lisa Doan:  Where we were in the beginning of the years is, we were still believing that we were going to rebuild Tracker at the time. And so, moving forward with a new product we knew we needed people on the team who were willing to step out of their roles a little bit. We knew we had to step into this big body of research. We also had so many engineers on the Tracker team that we also wanted to keep involved in and teach some of the practices.                           So, we added engineers on our team in addition to myself and a designer. Engineers who are very empathetic, who care a lot about building features that users care about and love. That was something we definitely look for when we were adding people to our team.   Poornima Vijayashanker: Let's talk about how you assembled your team because you mentioned there was the Tracker team and now you have a new team for a new product.   Characteristics To Look For In Teammates   Lisa Doan:  We were pulling from the original a Tracker team. But going into the new product, we knew there was a huge body of research that had to be undertaken. So when we were assembling the team, we were looking for people who are extremely empathetic and could really dig into...Would be willing to adopt some of the skills that we were lacking on the team. Things like user research, talking to customers. So, we looked for engineers, testers, designers and PMs who were very focused on understanding the user's problems and then trying to iterate our way towards a product for those people.   Poornima Vijayashanker: To recap, you have a conversation at the beginning of last year or some point last year where you decide you're going to build a new product, you go out dialing to stakeholders, and then from there you decided, OK, we're going to assemble a team, fill in knowledge gaps. What happens after all of that? You start building?   Vera Reynolds: Eventually. Like I said, it took about 30 experiments to get to the point where we started building, but it was a happy day. It was a happy day on the team. We started building around June, and we have just recently began rolling out our MVP. So, it's a pretty exciting time.   The Importance Of Having A Mission And Vision   Lisa Doan:  One major thing that we haven't talked about yet that was critical to our success so far is that we had to come up with a mission and vision. Prior to having that, we were just sent out into the world with this idea of we're going to re-envision Tracker, but that's so broad. That's such a huge space. Tracker has 100,000 users and they're all across the board. They could be just a small startup team, it could be multiple enterprise teams that are using this product.                           So, it was extremely difficult to know where to start. And because of that, we ended up in a place of paralysis because it's like, do we attack this problem, that problem? Who knows? We ended up spinning for a while, so when our innovation coach arrived, that's the first thing she noticed. The first thing she went about doing is getting us to agree on a mission and vision.                           That was really a huge turning point for us because whenever we can make a decision, we would bounce it against that and ask, is this in service of our mission? If not, then we would have to readdress it, otherwise we felt comfortable moving forward. That really started the ball rolling, is just having something to point at and agree on that this is what we're choosing to focus on.   Why Software  Engineers Need To Be Involved In Tasks Aside From Coding   Poornima Vijayashanker: Was there anything else that you you needed to do before you could start actually coding?   Vera Reynolds: I think the important part was to not head down into coding and not come up for air. We are trying to keep engineers involved in research, continue to spin a that track and not go off and just build. I think that's the most important thing to remember for us now.   Poornima Vijayashanker: Is there anything else that you did before you dug into building and writing code?   Vera Reynolds: Not really, that was about it. However, we were all trying to remind each other to be mindful of not go on the rails of building and start going fast as we did previously on Tracker, and really be mindful of that user-centric value.   Poornima Vijayashanker: I know we're going to share a lot of these best practices in the next episode, so I'm going to end it here. Thank you both for coming and sharing how you decided to go and build this new product instead of doing a rebuild or redesign.   Vera Reynolds: Thanks for having us.   Lisa Doan:  Yeah, thank you.   Poornima Vijayashanker: Now I want to know, are you thinking about doing a rebuild, redesign, or maybe building a brand new product? If so, what's been your approach? Let me know in the comments below this video. That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode where we're going to go into more detail around how to keep a new product on track. Ciao for now!