Dawn Delatte a Designer and Managing Director at thoughtbot who leads the Ignite team, where they focus primarily on validating and launching early-stage products through design-thinking, business and product strategy, and iterative design and development. Dawn works collaboratively with designers and developers to ensure they add value to the people and products thoughtbot works with every day.
- Follow Dawn on Twitter or LinkedIn.
- Visit her website at dawndelatte.com.
- thoughtbot's Ignite team
- Follow thoughtbot on Twitter or LinkedIn
Become a Sponsor of Giant Robots!
Transcript:
CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Dawn Delatte, Managing Director of the thoughtbot Ignite team. Dawn, thanks for joining me.
DAWN: Hi, thanks for having me.
CHAD: Ignite is one of the examples I always use when I talk about why we split up into teams the way that we did and what the benefits are, Dawn. So why don't you tell people what Ignite actually does?
DAWN: Cool. So the Ignite team we work with entrepreneurs, and non-technical startup founders, in some cases, experienced startup founders, as well as innovation teams within existing organizations. And we work with them to validate their product ideas and deliver very initial versions of their products to continue that validation process. We provide all kinds of services around that from a validation perspective. We use product sprint methodology to understand the opportunity, understand the market, the problem, come up with solutions, all those things to arrive at some ideas and some solutions that we can then quickly prototype and then test with target users depending on who we've decided their customer is or who they've decided their customer is. And that's very high level. I'm happy to get into more detail about what our discovery sprints are like.
But after that, then we would go into, like I said, continued validation but through actual product launches. So sometimes that looks like proof of concepts, sometimes that's first MVPs. But either way, we focus on a set of goals, and that could be a certain number of users onboarded to the platform. It could be getting that next round of investment funding. But it's pretty straightforward, not a whole lot of complexity, and focused on getting a product and company to that next best stage.
CHAD: One of the reasons why I use Ignite is that it's on one end of the spectrum. It's at the extreme end of the spectrum. Last week, I talked to Josh, who's on the other end of Boost, where we're working on existing products with existing teams. And Ignite is all the way on the other side, which is sometimes we are not even writing any code at all; we're just validating an idea.
The work that Ignite does has always been a very important part of what thoughtbot does. But it's a big challenge to go from a product where maybe you have hundreds of thousands or millions of users and a large team, and you're doing development as a developer or designer, maybe it's healthcare or something super complex, and then to the next week where you're working on something that is going to get into market very quickly, maybe is totally unproven. The things you need to do in that environment and the way that you need to work can be a little bit different.
And so allowing the thoughtbot designers and developers to focus on the particular needs of the Ignite-type clients I think we have seen, and I think we'll continue to see it as people even get more used to it, it has a direct benefit to our clients as well The best thing might not always be to write a Rails app. But if you take a developer who was on a Rails app on Friday or Thursday, and then they start on a new project on Monday, chances are they're expecting to write a Rails app.
DAWN: That's a really important observation and distinction about what our developers do compared to other developers at thoughtbot. I've always said that selling any kind of project or working with new clients with any type of project, whether it's very early stage or that enterprise client that we all wear our product consulting hats, or we're product consultants first, and then we have our toolkit. But I think that is the most true, at least from my experience, in the Ignite team.
And we've even talked about and, in some cases, have been able to blur the lines even more between designers and developers because first and foremost, you're coming to the problems thinking about it exactly how you're talking about. Like, what is it going to take to make this product launch successful? It might not involve writing very much code. And we might not discover that until after we've been working together for a couple of weeks and started to validate some of the ideas we have. And so, being able to have that adaptability and really focus on the consulting and strategy aspect of things is super important.
CHAD: So if there is a typical or Ignite client that we're working with, what does it look like?
DAWN: I would say a typical...so who we've engaged the most with are non-technical founders and entrepreneurs. And I say non-technical but what I really mean is they haven't had the experience of launching a product and going through that process.
CHAD: A digital product.
DAWN: Yeah, a digital product. So for lack of a better way to describe them, non-technical because there's a lot of work involved in helping them understand product strategy and technical architecting and everything that happens in between. So that's who we've been able to work with primarily while we've also worked with other types of clients.
CHAD: What is typically the first step with clients? At what stage are they at, and what is the first step that we're taking them through?
DAWN: The sales process is a little bit different. We're not talking about requirements. And we're not exactly talking about what the end product looks like. If the conversation is going that way, we're usually trying to bring it back a little bit and keep things more high level just to make sure that we have a really good sense of what it is that we should try to do.
So the sales process is we're already starting to dig into validation processes and making sure that our clients are able to define their customers and define the problem, and have started to think about their value proposition from a business perspective, and have made other considerations that through all of our experience, all the years that we have experience with shipping products, make sure that the client understands at least at a very high level what the big components for success are going to be. And if they haven't started to make decisions about those things, that they know that we can help them do that.
So that conversation is already starting in the sales process, which is great because we can get the team involved, and everybody starts wrapping their head around the problem. And by the time that we actually kick off the project, we're really excited because we all are ready, and we have ideas for what we can do together.
But the first stage is usually always what we call a discovery sprint. So we've been doing Product Design Sprints for a long time at thoughtbot. And we've always been iterative with everything we do. But with Product Design Sprints, especially because every single one of them is unique, you have to figure out either what exercises you're going to do that make the most sense for this client in this project.
We had, I guess a bigger iteration of the Product Design Sprint as a whole. And we've moved into this concept of a discovery sprint or a discovery phase. And it allows us to do a couple of things. So the Product Design Sprint was largely modeled after the Google Ventures Sprint, which is this intensive five-day process where you quickly understand the problem, come up with some solutions together, prototype, and test within five days. We've elongated that process a little bit. So we definitely do two weeks, sometimes four if there's a lot to uncover and make sure we understand about the market before we start writing code or before we start doing the next phase of work together.
And we kick off with a lot of the same processes. So like I keep saying, making sure you understand the problem, making sure you've defined the customer, the opportunities. In some cases, at least with our clients, we're actually doing lean model canvas work because our clients haven't always thought through how they're going to make money off of this product and what their competitive landscape looks like and things like that. We incorporate a lot of that business strategy into the product strategy work that we're doing during this phase.
But yeah, the first week of a discovery sprint is usually those kinds of exercises, working together through all this institutional knowledge that the client might have. Because usually, they're experiencing this problem or they've been in this industry,and they know what the problems of their customers have, and so they can talk a lot about it. And then, we move into some of the more traditional Product Design Sprint phases, so diverge exercises, converge exercises that help us to come up with a bunch of ideas for what the product should be or should do. And then decide as a group which ones are the strongest so that we can move into prototyping.
We prototype. We test with either existing customers in this space, or we get anonymous users based on certain demographics that are important to validate the concept with, and then we test. And then, we do that iteratively throughout the process to make sure that we're capturing as much data as we can to feel confident about how validation is going. Or, in some cases, it might make sense for us to think about the next phase of validation actually being more like a proof of concept. And so we can jump into that really quickly depending on how validation is going.
A lot of times, at the end of discovery spreads, we've incorporated some technical planning and architecting into the process. Sometimes we have to validate that the launch approach is going to work from a technical perspective. And so that's the kind of research that our developer would be doing in this process. And by the end of this phase, we have a presentation of our findings, an architectural diagram if that's where we're leaning or where we would recommend the next stage go. We would present all that information and make a decision. Sometimes we invalidate. We largely invalidate some of the ideas that we came up with, and we have to go back to the drawing board.
CHAD: Have we worked with any clients recently that had a major invalidation where they really needed to go back to the drawing board based on what we learned with the whole concept?
DAWN: We did have a client that we worked with this year that we didn't invalidate things during the sprint but not far into the product build, we realized that we were going to need some other infrastructure in place in order for that product to be successful. So we actually did a more traditional Product Design Sprint with this client. Part of the reasoning was…, and this product idea was in the real estate space. [chuckles] The idea was to open up the market a little bit by...I don't want to say eliminating, but I guess, in a way eliminating certain aspects of what a realtor might do in the process of buying and selling real estate.
It is possible to knock on somebody's door and ask them if you can buy their house, and then the transaction is facilitated through a realtor. But this would open up the possibility of this happening digitally through a product. So there’s certain data that you can pull from real estate sites out there that let you know certain things about a property. And this is public information; anybody can find it.
And the concept was to have homeowners who might potentially be interested in selling their properties be on the platform and have their homes be available to anybody that might be looking or vice versa. Like, someone who's buying could get on the platform and see what kind of homes are in their area; maybe they have a particular area that they want to buy in and essentially cut out the realtor in that they could go directly to the property owner and inquire about their home or see if they might be interested in selling it. So that was, at a high level, the product idea.
We did a more traditional sprint with them because the client was obviously very familiar with this space and really understood the opportunity well. And there are not a lot of competitors in this space in the U.S., at least. Our goal was ultimately to get to a plan for MVP. And so we spent time validating the user experience and at a high level, making sure that we were confident and moving forward with everything. And we felt like we got validation for that.
And we got started on the project, and we realized there's actually a lot to this space. It's very heavily...if not regulated, there are all sorts of processes in place that require very specific people and roles to accomplish different things and facilitate the process. It's also because of the role that a realtor has played for so long. People aren't very educated on what this process could be like, buying and selling homes, especially with a direct transaction. And so there was way more to uncover and to understand and to work through on the business side than we had initially anticipated. And so we decided to quickly bring in somebody to focus on product strategy while we were also iteratively working through an MVP launch.
So we decided to test as often as we can and constantly be working through on a weekly basis what it was that we were building, making sure that that aligned with what we were learning in real-time, essentially. The product strategist came on and started to continue some of the competitor research that we had started in the Product Design Sprints really try to understand the market and try to work very directly with the clients who were both in real estate to quickly make decisions about the direction that we were going in while we were also iterating on this product idea.
About halfway through, which is standard to Ignite a 12 to 16-week MVP launch, so about halfway through at about six weeks in, we decided that we needed to continue validating with a working prototype as opposed to continuing to chug along until we got to MVP launch and just see what happened. That was feeling too risky as we were learning more and more about the market. So I wouldn't say we invalidated anything, but as we continued to validate and as we started to build iteratively realized that we needed to spend a lot more time on validating the product idea and that it made sense to do that with a working product. And so, we pivoted in that way once we had started building.
CHAD: Yeah, that's cool. I often say that it's fairly rare that we completely invalidate the core of someone's idea. But it's not at all rare that it changes based on what everyone is learning along the way, whether that be in a Product Design Sprint or discovery sprint. And I think that's one of the things that not only does it make products more successful because you're reducing risk and you're changing them based on the things that you'll learn, but I also think it leads to the working environment that I want to be a part of where it's very collaborative; everyone's building off of each other's ideas. We're changing based on what we learn rapidly. I really love doing that.
DAWN: Yeah.
AD: I wanted to tell you all about something I’ve been working on quietly for the past year or so, and that’s AgencyU.
AgencyU is a membership-based program where I work one on one with a small group of Agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more, and many of the AgencyU members are now working on client projects together and referring work to each other.
Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I’ve seen and learned from a lot of different situations, and I’d be happy to work with you.
Learn more and sign up at thoughtbot.com/agencyu
DAWN: And it's funny what you just said about learning versus invalidating. I literally just got off of a call with somebody right before I joined this, and we touched on that exact same thing. They've been building a prototype and going through their own validation phases. And this person pointed out that they didn't want to call the work that they had been doing validation that they wanted to call it learning. And I just thought that was very poignant. I feel like I call it continued validation when I'm talking about delivering a proof of concept or initial MVP because, really, that's what it is. But I think a better way to say it is just learning. You're learning from the process and from your market, and it's all at the same time. It's very agile in that way.
CHAD: One of the meta reasons why I like that from a thoughtbot perspective is that oftentimes, founders, in particular, can be very precious about their ideas or not want to give up. And so this idea of oh, it could potentially be invalidated is almost like a confrontational tension or something that even when they are shown something they might not be willing to adjust because it's not their original idea. And the word learning subtly de-escalates that a little bit. It's like, what have we learned? [laughs] Have we learned something that we can take into play? It's not invalidating the idea.
DAWN: Yeah, I find that using the term like de-risking does a similar thing. Because whether or not you're an investor, that's a term that I think everybody can understand. Like, let's try to learn from and lower the risk of us not being successful with each step we take. The ultimate goal is product success and business success, and we want to get people there. But we want to make sure we do it the right way. And we want to make sure that all the decisions that we're making early on have positive, long-term effects. So yeah, de-risking and learning. I think I'm going to change the way I talk about validation now. [laughter]
CHAD: So what else is Ignite working towards now? I know that you have...everywhere at thoughtbot, we've got a bunch of open positions open. So you're actively hiring, right?
DAWN: Yeah. So going back to what you were saying and what we were talking about earlier, a lot of what we've been thinking through on the development side is what skills are really necessary and important for our developers to have for the types of projects and the type of work that we're doing. We made an assumption and have been working through learning [laughter] whether or not that assumption is true that we don't necessarily need a ton of back-end Rails expertise to be able to deliver products in the way that we're thinking. Rails has always been really good with MVPs, really good for MVPs and speed to market and things like that. But I think that we are thinking through how we can be even more agile and iterative with product delivery.
So we're leaning towards skill sets that focus on the front end, so delivering that really great consumer or user experience on the front end because MVP and startup space is incredibly competitive nowadays. We have to be thinking through, I think, more than what we did maybe ten years ago when we were delivering MVPs for startups. So we're focusing more on the front end. We're focusing more on the user experience. And we're thinking through how we can utilize existing tooling on the back end to support the products that we're building, which we assume is going to require a lot less particular expertise and a back-end language like Rails and a lot more openness to making decisions that make the most sense for that product idea in particular so whether that's pulling together existing tools on the back end.
CHAD: Well, I find it useful to think about...or one way to articulate this is mobile apps in particular because some people might not get the distinction with a web app the difference between the front end and the back end. I think it's maybe a little bit more obvious with things like React and that kind of thing. But if you take a mobile app, for example, in order to actually build and launch a mobile app, we typically need to build the mobile app, and then that mobile app needs to talk to servers on the backside.
And put quite plainly, if we have a Rails developer on the project and a mobile developer on the project, that's two people. And if instead, we can have a mobile developer who is putting together some back-end services from companies like Google or Twilio or those kinds of things, to get to the next stage of the company, it's going to be a lot cheaper and potentially faster for the stage that that company is at if it makes sense then. That doesn't mean that they won't ever need a back end of their own, right?
DAWN: Yeah. Well, and I'm learning more and more too that making those kinds of decisions now doesn't necessarily mean that I can't scale, even with the services that we pull together for the back end at that time when we do the initial launch. AWS, for instance, has a ton of capability for initial launches and for scaling. So there are a lot of options. That's what's become more important to us when we think through the development expertise on our team is not only experience with delivering early-stage products, because you're in that mindset, but openness to working with different technologies that would allow you to, like you're saying, plug into these different tools and servers and systems that already working for a particular industry, for instance.
I mean, e-commerce is one that you think of where we definitely don't want to be reinventing any wheels there. [laughs] From a conceptual perspective, yes, and from a competitive perspective, yes. But from a back-end development and architectural perspective, there's so much that we can utilize that already exists. So yeah, we are hiring. [laughter] I think that was your original question. And we have open developer positions, which is why I was focused on that.
Our development focuses less around what you've historically seen at thoughtbot, which is we need Rails developers. We need full-stack developers who can for sure stand up a custom back end. And we've shifted to...we definitely need to focus on the front end. We need that expertise. And we need some adaptability around back-end tooling and being able to pull stuff together that way.
CHAD: So you were the Managing Director of the Austin studio. And now you're the Managing Director of the Ignite team. Before that, you were a designer. How has this transition compared to prior transitions that you've been a part of?
DAWN: I think the biggest difference, and this has been just as challenging as it has been rewarding, and I think positive for our business, is the fact that I can focus on expanding our services and expanding our expertise in this one area. Before, we had the local studios, and we could work across the entire product lifecycle. And from a sales and business development perspective, that both gave me varied experience. And it gave me a lot of levers to pull, especially with the teams and making sure that we were all working on different things and able to cycle through different types of projects. But that's hard to do, and it's a lot of work. [laughs] And being able to focus on one stage of the product lifecycle and a set of clients, and expand our expertise in that area has been really challenging and really rewarding.
We've been able to sink our teeth in and imagine what possibilities are here and explore markets that we haven't before and actually think through how we can build partnerships with people and really become experts in this space in a way that we haven't been able to in the past because there hasn't been dedicated time and dedicated effort in particular. So the transition has been really great in that way. I'm really excited about it.
CHAD: Well, that's good. [laughter] You were out on parental leave for a fair amount of time. How long was it in total?
DAWN: About four months.
CHAD: Welcome back, by the way.
DAWN: Thank you.
CHAD: I'm curious on your perspective either with Ignite or maybe even more so thoughtbot overall. How was it being away, and what surprised you when you came back?
DAWN: So a couple of things, we were a smaller team in the beginning of this year. We knew that we were going to have to be iterative with our approach to refining our positioning as a team and understanding all these things that we're talking about, like our clients and our customers, and who we're going to work with, how we're going to work with them, how we're going to deliver value. We knew that we were going to have to be iterative. So we went through some phases this year. We were experimental and applied our validation processes to Ignite as a business. And we learned a ton of stuff. And we're going in a great direction. And then I was out for four months [laughter], and so there was a gap. And I tried very hard not to check my email. I mostly did a good job of it.
And so I was telling Diana, our CEO, earlier that I feel a little bit like we're going into 2022 with a fresh start even though we have this whole year behind us that we learned from. We got to a point where we're going in a particular direction now. And we validated enough and felt strongly enough about the direction that we're going in that we're hitting the ground running now going into next year. And I don't know what I assumed; maybe I assumed that we would have established a little bit more this year in the direction that we initially intended. And it's not like a far departure. It's just that it's certainly evolved beyond what I was imagining initially from the technical perspective, for instance.
CHAD: Well, even in Ignite, which is pretty short client cycles, we're not so huge. [chuckles] Ignite might do 12 projects in a year, and that might be a lot. So we get a lot of opportunities to try new things. And the cycle time isn't that long, but it's not super-fast pace, and it's not super high volume. So it does take some time to refine things based on what we learn, even in Ignite, which is typically faster cycles.
DAWN: Yeah, that's true. If you think of it that way, a lot of our projects if we're doing an MVP launch, for instance, it's about a quarter along. And if we only do a couple of those every quarter, it takes those whole cycles to be able to look at things in retrospect. I agree; it takes a little bit longer to learn overall.
I like the way that you put it, too, like when you really look back and think of it, even though we do a lot of what you would consider rapid projects, it's still going to take some time to learn. And I think overall, and I think this is true for all of our teams and our whole company, the year has been so positive. And we've learned so much. And everyone is feeling really strong, I think, in their positioning in going forward into the next year. Again, it's been good. It's been certainly challenging [laughs] but good.
CHAD: I think there have been certain things about this year that have been challenging, and we've talked about it on previous episodes, some of them. But just in general, I think I got the sense that we transitioned from being tired of the current pandemic situation and working situation to actually being upset and angry about it, which was a really weird transition. And I think it just made work in general challenging sometimes.
We also had the challenges of fairly high turnover this year at the company like a lot of companies have had. The reasons why it happens at thoughtbot might be different than other companies, but it's something that people in general have. And sometimes that can make it hard to get ahead, but because we were having such a positive year overall, it was this weird dichotomy of general success and positive change and all that stuff. But at the same time, people were still leaving the company, and that can make it challenging.
The silver lining is for a team like Ignite, even though that can be super challenging, you're in your early days, and now you're getting the opportunity to...the new people being added to the team are doing it with different expectations, and you're able to shape the team into what it needs to be today.
DAWN: Yeah. There has been an interesting...it seems like there was an influx this year and excitement and readiness to get back into building products and working on their ideas from a client perspective, but our teams were just coming off of a very hard year. People were coming off of a very hard year. So a lot of exhausted people trying to show up and be positive and work through all this excitement and movement in the industry. So it's kind of like parental leave. [laughter] Totally exhausted, but you're showing up, so it's good.
CHAD: Well, Dawn, thanks for stopping by the show, and joining me, and talking to me about Ignite and beyond. I really appreciate it.
DAWN: Yeah, this has been really fun.
CHAD: If folks want to get in touch with you or follow along with you, where are the different places that they can do that?
DAWN: Let's see. Well, I have an email address that is dawn@thoughtbot.com. I have a Twitter. I'm pretty sure that my handle is @dawndig. [laughter] Why I don't know this off the top of my head. I haven't looked at my handle in a very long time. Yeah, @dawndig, so D-A-W-N-D-I-G. LinkedIn is just my name, and it's pronounced Delatte.
CHAD: And you can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.
Support Giant Robots Smashing Into Other Giant Robots