Episode 1: User Centered by Design

Sunrise Labs  0:00  
**Intro Music**

Kelly Catale  0:10  
Hey, everyone, welcome to the first episode of user centered by design podcast where we talk about all things related to user centered design. In this podcast, we focus on topics in the medical device development realm, but the principles we discuss can absolutely be applied to other industries as well. I am Kelly Catale, Principal Human Factors engineer at Sunrise Labs, and I’m a newbie to podcasting.

Alex Therrien  0:44  
I’m Alex Therrien, I’m the director of user centered design at Sunrise Labs. I assure you, we are highly qualified people in our space. But we are brand new at podcasting. So this is gonna be a fun experience where we’re figuring out this this medium as we go. And we’re gonna have a fun time sharing with you what we know and what we’re learning along the way.

Kelly Catale  1:04  
Before we dive in to today’s topic, I think it’s important for us to start by introducing what we mean by user centered design. Do you want to explain a little bit about your perspective, Alex?

Alex Therrien  1:19  
Sure. So when we talk about user centered design, Sunrise Labs, what we really are talking about is three areas of subject matter expertise. You know, there’s the user experience of digital devices, you know, typically we we hear that referred to as UX or UI design. There’s industrial design, which is, you know, the user experience of hardware, and the design of hardware. And then there’s Human Factors engineering, which is about optimizing, and integrating devices with humans, and you know, how they work well together to achieve a goal. Being user centered really means focusing on the needs of the human beings using these products, we’re in the medical device space. But this, this is applicable across the board to any product in your life. And we believe in taking a systems thinking approach to the entire product, and ensuring that the user experience is both safe, effective, and in the end delightful. It’s what makes our clients successful at you know, being able to run a business, selling, making and selling the devices that we’re helping them to create. And, in the end, make the end user successful at managing the health and their own well being using the devices that were producing.

Kelly Catale  2:46  
Very well said, Thank you, when you as a client potentially would reach out to a company, you likely won’t be reaching out to a user center design team, unless you’re reaching out to Sunrise Labs because we have an integrated team. Otherwise, you would see houses that specialize and maybe one or two of these different disciplines. And for us, we see them as a complete package at sunrise,

Alex Therrien  3:12  
completely agree. And we find our clients are typically looking for a specific service like they, they may be looking to shape the user experience of an app or a digital product and looking for UX UI design services. Or if they have a hardware device, they’re looking to, you know, even as simple as getting a new enclosure for it, they’ll be looking for industrial design services. And by combining these three, we feel like we’re more effective for our clients. And that’s really what we want to talk to you about today is how we can help you to be the most get the most value and use your consultants most effectively, when you’re engaging with any of these three aspects of what we call user centered design.

Kelly Catale  3:57  
Awesome. And I think that a lot of companies are excited to engage designers and Human Factors engineers into their their teams work through consulting relationships, and there are some key elements to creating a relationship that really does utilize these kinds of services to the the most value that you can for what you’re paying for. And what Alex is going to do is to us up with the first major topic, and then we’ll get into some of the finer details of what our perspective is on how you can get the most value from us.

Alex Therrien  4:27  
Okay, so we’re gonna have two blocks of discussion today. And let’s let’s start off with the first one. There’s really no Immaculate Conception for a successful product. It doesn’t just occur, you don’t get it right the first time and you have to plan accordingly. How can we be effective as consultants to our clients really depends on how well they understand that process and how to utilize the schedule effectively to allow us to deliver the best product that meets what their needs are and what their end users needs are. So Kelly, when we’re talking about building a schedule, what does that look like for a set of human factors engineering activities, what do you need from a client in order to be successful on their behalf?

Kelly Catale  5:12  
The most effective client that I’ve worked with, in my experience with human factors, engineering, and even most effective projects, I’ve been in house as well. And I’ve seen that the ones that do the best are the ones that make time for human factors activities. And what does that mean, one of the biggest things that a company can do for themselves is to build time into their schedule for prototyping. prototyping enables us to get feedback in a way that doesn’t lock in and design and instead can provide an opportunity or an arena to engage with users early on in the process. And prototypes can take a lot of different forms, you can have really low fidelity prototypes, it could be anything from sketches on paper, it could be cardboard boxes with labels on them could be 3d printed models. From a software standpoint, it might be initial feature development to simulate certain features. From hardware design standpoint, it could be models, as I mentioned, could be certain elements of a model, a subsystem that has certain touch points. And ultimately, what it comes down to is prototypes can provide a lot of value for interaction and being able to enable your potential users to actually provide better feedback. You can solicit better feedback if you have something in front of your user. I think one of the biggest downsides that a lot of people see about prototyping is they say, well, that’s wasted time, because that prototype is a throwaway. And throw is a really dangerous word in my realm, because you can still get a lot of feedback that will impact the final design, even though you might have to start over potentially, or redo something that you already just did. So I know that I’ve worked with software engineer leads who have been concerned about creating software prototypes, because that might require a build that doesn’t actually go into the final software product. But it’s a build that enables us to have something to show users so that we can actually get feedback on a certain feature. Or similarly, for creating more hardware type models, you might see that that you have to build something preliminarily, you’re not your design might veer slightly after that.

Alex Therrien  7:28  
So I love your point about the software engineering and the builds there because the the perception that because it’s a dead branch off the repository, and one of the things that I’ve found is with the right mindset, and as long as we’re working quickly, and the expectation is that it’s not a super durable prototype, engineers learn so much about how to figure out the coding approach to build the intended experience and investing the time to explore and invite that mindset about everybody’s learning along the way. And it doesn’t just have to be in the service of one type of learning, it can be for serving all types of learning and acknowledging that it’s throw away in the right way, make sure that we’re using it to its most impact.

Kelly Catale  8:17  
And I’ll add also that I’ve found in my experience in user testing, that when a prototype or a model, or whatever kind of mock up you have in front of someone looks really, really polished. And you’ve spent lots and lots of time on it, users are actually some sometimes reluctant to give feedback because they’re afraid that there are certain things locked in already, versus if you have a prototype that is maybe a little less polished and a little less refined, and they feel more at ease, giving feedback that might have a potentially bigger impact on the overall design. So I think there’s a lot of consideration to be made for, what kind of feedback your you want to get, and what level of fidelity you want to achieve through your prototypes. And there is a time and a place for really any type of prototype. And it’s important that you do offer that space in your project. And that time is built in dedicated to prototyping. And I welcome what you what you think about that, Alex, and how that your perspective ties in. From a design standpoint.

Alex Therrien  9:21  
Absolutely. A lot of our best thinking is in prototyping. As you all know, I mean, we’ve worked together quite a bit. from a standpoint of consulting with clients, one of the most challenging aspects on a project can be if we’re not taking enough iterations of the design, and really getting the time to look at the product in the hands of the end users. The prototypes are really powerful for communicating the story, the design, but that’s only part of what we need to do any iteration, the client feedback, the internal feedback, all these are extremely valuable. But getting to see the product in use by the end user is the conversation that we need to have when we’re developing the product because you learn so much and they get inspired and in turn give you great feedback, including enough opportunities for research to exist and for a broader segment of the team to really engage and get to observe the end user experiencing that product. The most painful part of any of this that I know we talked about in our team quite a bit is what if we’re designing the wrong product, a lot of the regulation is aimed at designing the product the right way and doing the right steps. But if we’re running too fast and too lean, we may not validate the idea that we’re going after. And the client can certainly do this. And we love that our clients would do well to make the time to allow for that in their own process or in the process with us, because it really helps to avoid the most costly rework of all, which is we built this brilliant thing and the right way, but it doesn’t have any meaning to the end user, and they’re not going to adopt it because there’s too much friction, or there’s a problem.

Kelly Catale  10:58  
I love that word iteration and iterative mindset, I think it’s really, really important to reinforce that. In any schedule, the high level goal should be to fail often and fast. And you should encourage failure in the beginning of a project, put ideas out there in a way that you’re okay, because you know, you’re going to get feedback, and then you’re going to be able to check it again the next time you seek feedback. And the more that you can support an iterative design process. And what I mean by that is creating small cycles, where you can build a prototype or try to experiment or maybe you hypothesize some specific aspect of the experience. And then you go out and try it and experimenting and allowing time to really honor that experimentation will in fact, pay off in the end, because you’ve been able to tweak or make adjustments or restart without a huge investment in the amount of effort that you’ve put into prototype, or a feature set or design in some way. In the end, you’ve got a robust solution that you can feel confident in, you’ve created the thing, right? Meaning that you meet your requirements that you set out your design inputs, but that you’ve also created the right thing, which comes back to what you were saying, Alex about, did we even design something that’s meaningful for the end users?

Alex Therrien  12:23  
I think to kind of play off of what you’re discussing there is, I think there’s this insight for our clients that can help them is not being delicate with the product or the process. And if you can embrace a willingness to kill off what isn’t working and to remove failed experiments and move past them and learn from them and focus on what is working and evolve the product quickly. The approach that we quite often are advising our clients on is embrace failure and look for the other ways of driving efficiency efficiency doesn’t mean getting it right. The first time efficiency means that you design fast experiments, you prototype in the shortest amount of time possible, in the crudest way possible. Just enough fidelity to really prove out what your beliefs are enough to move on to the next round, focus on getting it wrong. And having a lot of ideas by as soon as you have user needs. There’s interpretation there, you should start experimenting with your different interpretations of those user needs, that you can embody what you believe your requirements might look like before you even commit them to paper based on your interpretation of those user needs. And that’s an experiment that you can run and test out. And before you get to signing off on your requirements and locking them in. And it’s a little bit tougher each time that you do that, you have a pretty good picture that everybody agrees with and you’ve gotten some level of validation from the end users, you’re going through it at each level of your requirements stack, you should be looking to experiment like that and to prototype what your beliefs are, or the diversity of ideas that you have to figure out what’s working and what isn’t. And it’s a great way of fleshing out your requirements and your specifications to make sure that you don’t end up down a rabbit hole. And you’re sort of making yourself crazy at the end of the project trying to achieve that same goal that you had envisioned based on the way something’s written.

Unknown Speaker  14:21  
Absolutely. Talk to me

Alex Therrien  14:23  
about how we can leverage the actual study itself. If I wanted to run a study with you, what do you think I should be thinking about with you, and we’re doing this,

Kelly Catale  14:33  
I would say the most important thing, gosh, there’s so many things that someone should think about when running a study. And I could sit here all day and have a whole different podcast related to this. And I do think one of the key things that some people who are naturally type a perfectionist, which I think a lot of engineers who are very detail oriented or other folks who work within a very rule based structure like to think that when they have Have a design, it’s good, you know, we’ve thought through it, we’ve done our homework.

Unknown Speaker  15:03  
It’s very rational,

Kelly Catale  15:04  
exactly. It’s very rational. And I can say this, I am not knocking engineers, I am an engineer, my background is in engineering, and I have a biomedical engineering degree. So I can speak to this. But I might be projecting my own my own things out here. But I would say one of the biggest things to keep in mind when running tests and how to find value in your human factors engineering services, is to expect that your users are going to tell you something you didn’t know, you are going to get feedback in a usability study, you’re going to get feedback when you go and talk to users, if it’s just interviewing them, or sharing initial concepts. If you can truly talk to your users, you can get real honest feedback, have them thinking in a way that gets them to imagine themselves interacting with the product in real life.

Alex Therrien  15:57  
So you’re saying that are probably not going to be able to fix it in the protocol of the research study?

Kelly Catale  16:02  
Probably not. You can’t hide everything. I do know that I’ve had many experiences where the knee jerk reaction when you run your first session, or your second session in a test is to say, Oh, no, we just had this signing, let’s do a protocol deviation. And there’s that initial like, Oh, well, maybe the question we asked wasn’t right, maybe we should have done it a little differently, or presented it on the left side of them instead of the right side of them. And the reality is that you will get findings. And that is my bottom line here is you should always, always expect feedback, you shouldn’t go to a human factors house, you shouldn’t go to a human factors professional, ask them to run a study and expect that you’re going to get a report that is completely clean. It’s unrealistic. And the nice thing is, though, I come to you bearing good news, which is you don’t have to fix everything. If you have findings, you don’t have to then go and address every single finding. There’s a process, you can use a risk based approach to say, Okay, what does this finding really mean? What does it mean for the risk profile of our products, or the use scenario, and then you process those findings in a meaningful way that actually helps tease out what really matters for the end result, the end product for your users. And that risk based decision making can help you stay focused and make those findings that you will inevitably have feel a lot less painful than you might think they could be.

Alex Therrien  17:31  
I really like that. And as we talk about expectations, I think there’s some similar expectations with level of control. Our clients are coming to us with a vision and their baby. And it’s their product. It’s their vision, the hopes and dreams that they’ve been working hard on to see come to fruition, there’s all levels of expectation that you can see. But if you really want to get value out of a user centered design team, and especially the the UX UI design and industrial design sides of that trifecta, you want to come to the table with more of a problem or an opportunity that you want to see solved. There are times where clients, they have something and they just need somebody to execute it, there are certainly those jobs and they’re good jobs to have, it’s good work to do. And I believe it’s great to have the chance to help people see their vision come into the world. But in terms of getting the value of design and sort of going, here’s the cube and put rounded corners on it and make it amazing, there’s a disconnect for the client between what they’re expecting, which is an amazing product experience. But an over constrained problem, which is just fill in the radio on this cube, you’re not going to get the result that you want, which is really where value comes in, to measuring the execution that are that any team is going to do for you. But especially what I know that we’re capable of doing a lot of times, really, that means that we start off integrated early. And we’re contributing to the definition of the architecture through relating it to the experience of the end user and the problems that they’re seeing, and the problems that they’re experiencing. And it really ensures that we’re able to have the technical implementation, the market vision, and the user experience all mature to at the same time in a way that supports each other as opposed to cause late stage conflict and sort of armwrestling over the right approach. Start early start often iterate with a great opportunity or a really hairy problem. And let’s all work it together. Because creativity certainly doesn’t stop at that at the doorstep of a user centered design team or any one of these subject matter expertise areas.

Kelly Catale  19:45  
And I would add that what you’ve already mentioned, though, not using the word explicitly, collaboration is really important. And what we’ve seen is involving everyone in the process from the beginning, and building that trust and creating another environment where people can feel free to say, hey, this feels like it’s off our original vision, what’s going on here, or we are open as the consultant to offer feedback in a way that feels like a safe environment to do so. And I think that when someone comes to the table with an idea, our first step, like you said, is to really understand problem space and ask questions to get to the why. And we always want to know why it drives some people crazy, but that is what our team does. And we ask lots of questions because of that. And once you get to the we’re the difficult time. Why, but why? The truth is, though, when you ask why enough, you can get to the root of the answer, and the person answering the questions feels heard. And I truly believe that is the biggest piece of building trust is when the person who comes to you with something in their mind, if they can feel like you’ve heard them, that’s the best thing that you can offer. And what I can say to a potential listener, client, is that be open to answering those questions be open to, to being that collaborative partner who can provide the insight that your design and Human Factors counterparts are looking for.

Alex Therrien  21:19  
This is actually a really good inflection point in our conversation to sort of transition to the other major topic for today, which is, we start off, how do we set up the project for success? How do we plan and schedule to be successful from the get go, let’s talk about how, once you’re into it, you can help yourself stay on schedule, and on budget.

Kelly Catale  21:39  
One of the key elements to my interactions with our clients is coming right out. And one of the first interactions that I have being transparent about communication and trust and, and offering that almost I don’t want to say vulnerability, I don’t think that’s the right word. But reminding them the mission of sunrise, which is we are a company based in belief in positive intent, and we are on the same team, we all have the same goal. And if there’s something that feels weird, or off, or you are offended by something, I would hope and I encourage, and I state this at the beginning of any interaction with my clients is Tell me, be honest with me, and ask for clarification or more information. And likewise, if there’s something that you do, like Tell me so we can continue doing it, that I would say is how I start to build that trust in it helps to do that upfront, because you show that you are human.

Alex Therrien  22:36  
I love the sunrise cultural touchstone of everybody’s doing their level best to help each other. And things sometimes get muddy or offer weird. And the easiest way to figure it out is to just go like, Hey, I didn’t understand that. And it sort of made me feel uncomfortable or weird. And can you tell me more about that, that moment where you said that thing or when you did that action, because it made me feel bad or awkward. I like that we do try and bring our clients into that cultural experience. And as we talk about scheduling budget, miscommunication is definitely a way that you can lose your track. One of the biggest areas where you can get off cadence with a project is not being strategy focused. And one of the areas that I tend to start out quite a bit with my clients is being focused in strategy to make sure that we’re all anchored on these the areas that are the most important. You know, if we try and be all things to all users, we’re not going to be impactful to any users. It really is based on having a good hypothesis on what is meaningful to the problems that our users having, or what is the opportunity to really show empathy and change lives with the products that we’re designing. And this is really mission based stuff when you’re getting into medical device design. And if we don’t have that hypothesis of strategy, and that understanding of why we can’t be effective on behalf of our clients. And so being very open, being very clear about these elements, helps us to make good decisions and collaborate better and be less frustrating, honestly, if we start heading in the wrong direction, because we didn’t understand the strategy. And it’s just makes us more effective on on behalf of the client. And if the strategy doesn’t exist, we can certainly work with them to help build that. And I know that that’s a key touch point in all three areas of what we do. And building a relationship between that strategy and the work helps us to define the core experience of the design and how we scale the project. And who knows you may run out of budget halfway through and we got to figure out how you can still be successful getting the product out the door, starting off with an MVP that is based on the core strategy and the core experience that we need to deliver. If we get to that first Almost with every delivery of a prototype, you’re almost getting a complete product at the end of it, it may not be polished. But if you had to go out the door tomorrow and be successful without Sunrise helping you, the best approach that I can take for you is to keep trying to build the smallest possible nugget and expand out in iterative deliverables of that experience, like the rings of a tree so that we’re starting with the most important features and trying to build the core product that you can then take out the door. And that really is our best cut at how we scale in the case of emergency or how we scale in the case of pivoting That happens a whole bunch.

Kelly Catale  25:40  
Yeah, I definitely want to talk about scalability. I also want to add that you were talking about having that strategy well defined, I found that when a strategy is well defined, and the team is aware of that strategy actually keeps people focused, right. So you can find that if there’s a lack of focus on a project, or there’s a lack of real defined path, there can be deviations from the path, because there isn’t really a path to follow. And people aren’t working cohesively and collectively to drive to the right answer, right.

Alex Therrien  26:12  
Yeah, I completely agree.

Kelly Catale  26:14  
And I have actually found in interacting with a lot of different engineers, if you have a defined strategy, and goals for the team that are clearly communicated, people often go back to them. If there’s a discussion that could be controversial happening, people say, Okay, let’s take a second, how does this go back to our strategy, and even the most unlikely people will use that tool in their back pocket, because maybe the argument they have supports the strategy more than someone else, and it becomes part of the conversation. And that is really key is once you bring that into the conversation, people are more willing to use it in their daily work.

Alex Therrien  26:52  
It is entirely possible as people who care any one of us, the client, the external consultants, we all want to do the right thing for the patient. viewpoints are diverse on what is the right approach for the patient. If we’re grounded in a strategy that we all agree on, like get go, we can certainly have an easier time with those debates and be more grounded in the decision that we make. And even if it’s if it ends up pushing off a feature that somebody really believes in, or an implementation gets changed to something else, everybody has a lot easier time accepting that internally, externally, and it brings focus, clarity, and focus and clarity brings speed. Mm hmm.

Kelly Catale  27:35  
And what I want to do is now bring it back to you talked about scaling. And I have something I want to share about scaling, which is from a human factors engineering approach. You talk to well seasoned Human Factors engineers, and they’ll tell you that scalability is one of the biggest features of human factors engineering program. And when you’re designing a program, you can use this approach the business strategy, you can start with your business strategy. And then as you dive into the project, and start to understand the technical risks, and the really, when we’re talking about user centered design, we’re talking about use related risks, use your preliminary risks to understand the risk profile of your product, and then actually scale your project your your human factors program and the associated activities to the risk profile. And a lot of people think, oh, human factors, it’s one or zero, you either have it or you don’t have it. And in fact, it’s usually more like, below one, it’s somewhere between 0.1 to point nine, nine, right? There’s

Alex Therrien  28:37  
a big one of the minimum expectations from the FDA.

Kelly Catale  28:41  
Exactly, exactly. And the initial hesitation of including human factors is that it’s this really burdensome process. But with a team who wants to do their due diligence and make sure that they’re meeting expectations from an industry standpoint, the first action when building out your schedule and thinking how can I stay on schedule should not be let’s cut the Human Factors activities. Because there is a minimum, you should make sure that you understand your users and make sure you understand use related risk. And FDA encourages this as well, in your submissions, you have to explain the rationale behind the activities you did complete. And that implies also if you eliminated activities, why? Right?

Alex Therrien  29:24  
So if you were starting off, what would your first step in the process be? If it’s not cutting HIV? What would your first step be then, as a human factors engineer advising your client?

Kelly Catale  29:36  
I would first start with understanding the fundamentals of the project and the product itself, right, that starts with what’s the intended use? Who are the users? What’s the use environment? And those big questions and the answers to those big questions, even if it’s not fully refined, the answers to those will build that relationship between your Use related risk understanding, were the big project risks that we, as folks who have worked in this realm for a long time know that there’s a lot of sensitivity around certain areas. How do those align with your strategy, your business strategy? And where do we believe you should be investing in? Where do you believe you should be investing most of your time. And I think there’s a really nice blend between the big risks from a use related standpoint, and then the vision that you have for your project. And if you can find harmony between those two realms, you’ll actually find that you can scale your project in a way that will help you meet your MVP or minimum viable product that you had mentioned earlier, you can meet that the goal of let’s get to an MVP by understanding what you can do reasonably from a risk standpoint as well. And I think you have to take both of those into account at the same time. And it would be foolish of me to say everything is driven by risk. It’s all risk based, because that is the purest way, the engineering purest way. And we would we would be, we’d be remissed to think that there isn’t some sort of business strategy behind the decision making that goes into designing a program. And so for my standpoint, I would say you have to really start with that strategy piece, understand your strategy, and then understanding the big elements of how do you define that risk profile of your product? And then where can we combine things, what is really essential to making sure we can get out the door with a product that is safe, effective, and then delightful that you mentioned earlier on in the beginning of this podcast?

Alex Therrien  31:37  
Yeah, and one of the first things that I think of when I look at the FDA is expected deliverables, it really is a good process that gets you a good business result. But starting off with a strategic position on what are the business areas of focus, that really differentiate the product and its reason for existence, the user needs that make it relevant to the people and the patients that will be impacted by the products existence. And working in that same area, the regulatory strategy and the human factor strategy are such key pieces to managing the perception of the FDA and what we sent to them. And then also the scale work that we take on, I really believe in that strategy piece for saying, look, we need to invest here. But these other areas, they’re not a concern in this type of device. So we could probably scaled down. And it isn’t just one monolithic scaling of the of the process, it can be tailored throughout each level of specifying what are the activities that we need to do. And you don’t have to address all aspects of the product in the same way. And I love that about the way that you and I have gotten to work together on this kind of strategy piece for our clients. And if anything, I would be hoping that our clients walk away from this podcast learning about the the impact of having a human factors strategy at the start of the product is to give them a sense of control and the ability to have a real voice in the approach that their human factors consultants are taking. And to feel like they’re collaborating and participating to sort of touch on our earlier points about how we work together with them. And I like to shine a light on how we do things to our clients so that they feel equally bought in on the approach. And it again, it comes back to that building trust. Absolutely,

Kelly Catale  33:31  
I would say if we had a final message, it would be the best thing that you can do as a client working with someone in the design or human factors realm is to support a relationship that is founded in trust. 

Alex Therrien  33:43  
Oh, absolutely.

Kelly Catale  33:45  
And that means seeking out a partner that you can feel confident in. But you can’t have trust without that confidence and ability and in capabilities as well. And that doing your research and finding the company that best suits your needs is really the right approach and the cultural fit

Alex Therrien  33:59  
too, because you’re going to spend a lot of hours working together. And if you can’t have trust, if you can’t work together deeply, and share all of the core thinking of the product to reach that point where we’re all acting strategically in the execution of our own areas of expertise. And it’s just setting setting ourselves up for frustration and loss of value, potentially a failure of the program. And we certainly don’t want that for our clients.

Kelly Catale  34:27  
Absolutely. I 100% agree. And I think one thing to note here for us as we wrap up, is what we’ve shared today is really just a small piece of the puzzle. There’s there’s a lot of things that clients can do and then also a lot of things that the consultants can do to create a really healthy working relationship. And we’ve started the ball rolling, we’ll say Well, we’ve got we’ve, I think I just used two different metaphors together. I blend the two of them but we have gotten the ball rolling and It’s a starting point for whoever is thinking about these services and thinking about a way to really bring the most value to their project.

Alex Therrien  35:08  
Absolutely. At the end of the day, if you’re getting involved with a consulting company, to really key points where you want to have the most impact for your success working together at the startup, plan for failure, and plan for prototyping, and testing and iteration so that you make sure that your scaling of the project is focused on how quickly you can learn. And speed is on iteration on timeline. And you can achieve the same goal moving quickly by not being perfectionist, trying to get it right the first time. And the other part is on the back end. By being strategic and staying focused. As soon as any one of us the client, the consultant, anybody in the chain takes their eye off of that area of strategy in that area of focus. And once we all agree that strategy change, and that’s how you end up having scope creep. That’s how you end up having timeline creep. That’s how you end up having budget creep. And no one wants to have that conversation. I don’t want to talk to a client about that. It feels like a personal failure. If I’m if I’m coming to you and going. There’s more here than we knew there’s a ton of problems there. No one wants that. I want to be on time on budget. And I want you to have a great experience. And Kelly, I’m sure you do too.

Kelly Catale  36:26  
Yeah, absolutely.

Alex Therrien  36:27  
Thank you, everybody, for joining us today. This is certainly episode one. We’re already we have some great topics in mind for Episode Two. We’re excited to keep the ball rolling, because we’ve started it so we’re gonna keep that ball rolling. And so we certainly have a lot to share with you all. We know our business well, but this whole podcast thing is going to be fun. And it’s new for us. And thanks for bearing with us as we figure it all out.

Kelly Catale  36:52  
Yeah, thank you and we’ll be back soon with episode number two.

Sunrise Labs  36:56  
**Outtro Music**

Transcribed by https://otter.ai