Last week on Build, we shared why it instead of rebuilding or redesigning an existing product, it might make sense to build a brand new product, and we walked you through how some folks on the Pivotal Tracker team arrived at their decision.
When you start building a new product, you have the best of intentions to revise old processes and move away from bad habits. But it’s easier said than done. So this week we’re going to share some best practices for keeping a new product on track!
And to help us out Lisa Doan and Vera Reynolds are back! You’ll recall Lisa is a product manager at Pivotal Tracker, and Vera is a software engineer at Pivotal Tracker.
As you listen to today’s episode you’ll learn the following:
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
## 5 Best Practices For Keeping A New Product On Track Transcript
Poornima Vijayashanker: In the last episode of *Build*, we talked about why, instead of doing a rebuild, or a redesign, it may make sense to build a brand new product for your company. If you missed that episode, I've included a link to it below this video.
In today's episode, we're gonna dive into some of the best practices for keeping that new product on track. 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 debunk a number of myths and misconceptions, related to building the products, companies, and your career in tech.
In today's episode, we're gonna be sharing a number of best practices to keep a new product on track, as you're building it, and to help us out, I've invited Lisa Doan, who is a Product Manager at Pivotal Tracker, as well as, Vera Reynolds, who is a Software Engineer.
Thanks for coming back on the show, Ladies.
Lisa Doan: Thanks. Happy to be here.
Poornima Vijayashanker: Yeah. Let's do a quick recap from the last episode on why you decided, instead of doing a rebuild or a redesign, to build a new product.
Vera Reynolds: Yeah. So, initially we thought we were just gonna rebuild Tracker, and when we went out in to the world, we realized that the problem space was just way too big and that net was cast too wide and so we need to follow the pain and find what were the most effective things we solve for our users. You have to understand that Tracker does what it does well. They are other competitors, absolutely, I'm not here to toot my own horn but it's a pretty good product. And so we found that there are other problem spaces that we could talk that are adjacent to Tracker that could complement it in a nice way and so that's we ended up where we are.
Poornima Vijayashanker: OK, so whenever we have the chance to build something brand new we want to start with the best practices, new best practices. I'm sure you've both experience this as well as you were assembling your team. What were some best practices and how did you go about learning them.
Lisa Doan: So on the product side we had to adopt a lot of new practices. So when Tracker was built back in 2006, product was less of a thing but since then, things like lean startup have emerged, lean product, user centered design and we needed to catch up on those things. And so we brought in an innovation coach who helped us learn how to do experiments and really think about product in a lean fashion. And so we've been doing a lot of practices around that.
Poornima Vijayashanker: And I remember in the last episode you talked about how your innovation coach also helped you with a mission and a vision
Lisa Doan: Yeah.
Best Practice #1: Set a Mission And Vision For Your Product
Poornima Vijayashanker: So how did that come about or what did that look like?
Lisa Doan: Sure, so when she arrived we had been doing endless research and so she recognized that we were paralyzed and that the first thing we needed to do was pick a direction and that's what the mission and vision were tools to help us do. Where they came from is, the designer and myself had done plenty of research in the years prior about what the major problems our users were facing on Tracker. And so we had a couple ideas of what we wanted to address with the new tool and so those were incorporated during a workshop where everybody on the team was throwing out their ideas and what they wanted this new tool to be, how they wanted to solve problems for users. And after, I think a whole morning of just workshopping it over and over we finally arrived at a mission that everybody could really agree on.
Poornima Vijayashanker: So what was the mission that came out of this?
Vera Reynolds: I'm gonna paraphrase it a little bit. Our missions to empower individual contributors on a team to align around shared goals.
Best Practice #2: What Being User-Centric Really Looks Like
Poornima Vijayashanker: So I've heard you through around user centric a lot. It seems like it's a new direction that you're going in. How is this different from what you were doing before with agile.
Lisa Doan: Tracker was born by engineers for engineers and for the majority of our span as a team, we've been a very engineering centered. A lot of our leadership is former engineers who worked on the project. All of our product manager back in the day were extremely technical. I was the least technical PM and I have a degree in computer science. And so we always had this mindset of doing the best engineering possible but we were less focused than we should have been on what our user needs were and that's been a huge cultural shift that we've tried to instigate with our new team, which is, let’s think about the user first. Let's always question why we would build something before we build and that's a muscle that we've really had to really grow and exercise a lot is, rather than just coming up with an idea and just immediately building it is, let's go make sure this solves the user problems, validate that the user actually has this problem. And just really having a discipline around that.
Poornima Vijayashanker: Is that because the user is different so maybe you're not dogfooding it as much as a builder.
Vera Reynolds: We do actually dog food our current product. So that was one of the first, we were our own first user and I do think that helps with keeping that front of mind, but as an engineer, I've always been getting used to getting candid stories, not so much asking about why we were doing it. It may have been my experience but from what we've learned from our users, that's not unique and there's not necessarily anything wrong with that, however we feel like a balanced team where everybody is involved and has is user centric to pull it up again, provides the better product.
Best Practice #3: How To Create A Balanced Team And Have Members Weigh In On Decisions During Planning Meetings
Poornima Vijayashanker: So let's talk about those balanced teams next 'cause I think that's the thing that's new to right, in your approach. What's a balanced team.
Lisa Doan: So we like to think about it in terms of three spheres of influence, and so you have a sphere that's very concerned with the user, and so typically that falls to a designer. And then we have the sphere that's concerned with the business and so typically the product manager has been responsible for that. And then we have the engineering side, who's concerned about, usability, who's concerned about building, using the best patterns. And so balanced team isn't about specific roles and filling them but it's that, at any given time someone can weigh in for each of those spheres. And so at some point, whenever you're making a key decision, someone should be able to represent the user, someone should be able to represent the business and someone should be able to think about technical fusibility and the engineering impact of that.
Poornima Vijayashanker: Got it. So as you're moving forward and building this product, you have each of those spheres weighing in on the decision.
Lisa Doan: Sure, an example of that is when we go to IPM stories, and we're-
Poornima Vijayashanker: What's IPM?
Lisa Doan: Iteration planning meeting.
Poornima Vijayashanker: OK.
Lisa Doan: And so as a team will go through the stories that are coming up next and talk about any concerns that we might have. A good example of that now is, sometimes I'll bring a story to the team, and the engineers are capable of challenging me and saying OK, what is the evidence that we should actually build this. Whereas before the engineers were like, "OK, we'll build it." But there wasn't that conversation about what is this actually doing for the user. So it has great impact that we see.
Best Practice #4: How To Hold Yourself And Your Team Accountable Inside A Larger Organization
Poornima Vijayashanker: Yeah. So while you are a new team you have assembled, you're still operating in a bigger organization. But I know your goal was to stay more startupy and the best startups are always keeping an eye on time as well as money. So how did you hold yourselves accountable?
Lisa Doan: When we first started we...this was a huge challenge for us. We went out and started to do research, but it became this endless research thing and there was no one asking us...well people were asking us when are you gonna build, but we couldn't tell them. We had no idea. Everything was just so vague and open at that point and so we introduced a concept, which I believe comes from the lean startup of metered funding. And so in the startup world, you're only alive as long as the money is there and so you're always trying to convince your investors that they should continue to give you funding. In the enterprise world that doesn't really exist. You have a team, there is funding for you already, and so you just continue using that and there isn't anyone whose making sure that you're making good on it. And so we introduced what we call a growth board. And so we have some stakeholders within Pivotal across different business organizations who will meet with us every six weeks and will hold us accountable to our learning. And so every six weeks we show up and we say this is what we learned and that's how it's affecting our direction. And they make the decision on whether we should pivot, persevere or kill the product.
How To Remind People Of Best Practices
Poornima Vijayashanker: So it's great that you're following this framework of pivot, persevere and kill, but let's get real here. I'm sure there was a time where you felt like, "Is there ever gonna be a light at the end of the tunnel?" And if so how did you reinforce or remind people of these best practices?
Vera Reynolds: Oh yes, there were times. And I haven't been with the team for as long as Lisa has so I'm sure she has even more times that she can conjure up, but for me there were definitely moments where I questioned what we were doing, I questioned why we were doing it and that's where that balanced team really shone because it wasn't just me from my engineering perspective. It was having those question, I think having designers, PMs and testers with us was really...we were up lifting each other and helping each other move along and get through those tough spots.
Poornima Vijayashanker: Lisa, anything you wanna add to that?
Lisa Doan: Yeah, there were definitely a lot of times where we were just really
concerned about, is this even the right direction? What are we doing? There was so much ambiguity and that's an extremely uncomfortable place for many of use. The place we came from is, we thought of features and then we built them and there was this security in it. And the new world we were in is, let's go find problems, let's validate those problems. And the practices were new, it was a huge cultural shift. You're asking people to do things that are outside of their role. And so there was a lot of just stress for the early months and just trying to figure out, is this even viable? Are we even doing the right thing? Was this all just a mistake?
Poornima Vijayashanker: And so how did you put that team together?
Lisa Doan: Well like Vera said, we had great people on our team and we still do and we hold each other accountable to our learnings. And so fortunately having all these different perspectives can bring a lot of light. And so sometimes as a PM, if I'm very down about something then the engineers can bring a point like, "Oh but the user said this in this one user interview." Which is something we never had before.
Poornima Vijayashanker: Oh, cool.
Lisa Doan: But now they're involved and they can bring up just as much evidence as I can and it's extremely helpful when times get difficult.
Poornima Vijayashanker: Yeah. So it's having another, basically set of eyes and ears to pinpoint things that might have gotten overlooked. That's awesome. I know you're currently in beta, but let's switch gears and talk about some of the positive outcomes that have resulted from doing this new product.
Lisa Doan: Absolutely. We've seen a tremendous cultural shift, not just in our team but across the broader Tracker team as well. And so as I mentioned, we came from a veery engineering centric place and so we started to see the other teams start to adopt a lot of lean practices as well. Another huge benefit is, as soon as people started to see us start to get momentum they saw that it was directly related to having a vision and mission. And so now those teams have also gone out and established their own vision and mission which is helping to drive their futures forward and their work forward as well.
How To Keep Stakeholders Involved
Poornima Vijayashanker: And last time we talked about stakeholders. So coming full circle, how do they feel about this?
Lisa Doan: They're really excited. Our growth board is really enthusiastic and supportive of us. They're also able to connect us to different parts of the organization, and so we've seen tremendous outreach from different parts of Pivotal that are very interested in what we're doing and very excited to join and help us. And so that's been a wonderful outcome of ours so far.
Vera Reynolds: They still keep us on our toes.
Lisa Doan: Yeah.
Vera Reynolds: It's good to have that positive energy.
Best Practice #5: How To Go About Testing A Brand New Product
Poornima Vijayashanker: I know you're in a beta phase right now. How are you going about testing?
Lisa Doan: One example I can give, is just last week an engineer and I, we walked over to someone on a different team and we asked them to use our tool, and we sat there and we observed them going through the various steps, and just cringing as they get to steps that are like, "Ooh we gotta clean that up, we gotta fix that." But also seeing that it helped them in their day to day jobs and that was really exciting.
Poornima Vijayashanker: Yeah, so doing some usability testing.
Lisa Doan: Yeah.
Poornima Vijayashanker: OK. Anything else?
Lisa Doan: We're continuing to do evaluative research and so that's making sure that they're not just on our very specific persona, but we're validation that the problem exists beyond just that persona and how we can potentially solve for various scenarios.
Poornima Vijayashanker: I know we've covered a lot and there's probably a lot more we can talk about when it comes to new products and staying on track. What's one thing you would love our audience to just always remember.
Vera Reynolds: I would just say if you're engineers, question what you're building and question your PMs.
Poornima Vijayashanker: No that's great. Alright well thank you both, Lisa and Vera for coming on the show and sharing some of these awesome best practices.
Lisa Doan: Thanks for having us.
Vera Reynolds: Thank you.
Poornima Vijayashanker: You’re welcome.
Well that's it for today's episode of *Build*. Be sure to share this episode with your friends, your teammates, and your boss and subscribe to our YouTube channel to receive more episodes of *Build*. Ciao for now!
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:
--
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!