It is my pleasure to share the wisdom of Elyssa Stewart today! We are talking about her experiences as a Director of Product at Chili Piper and now at Airspeed.
Oftentimes, the execution of a project is like a blackbox to stakeholders. We invite them to a kick-off and announce the launch. But what if you’ve already built something and then you show it to stakeholders and they’re like “yeah…this isn’t going to work”? Elyssa shares some great advice around this. Enjoy!
✅ Involve key stakeholders early and often: Ensure that all relevant internal teams, especially those in customer-facing roles, are involved in the product development process to gather diverse perspectives and align on goals.
✅ Balance inclusivity with efficiency: While it's important to include various stakeholders in discussions, find a balance to avoid overwhelming certain team members, such as engineers, with meetings that may not be directly relevant to their work.
✅ Feedback loops are critical: Establish a process for regular feedback at various stages of product development to ensure the product meets user needs and internal expectations.
✅ Iterative collaboration improves outcomes: Working in small, focused groups or "pods" that include a cross-section of roles can lead to more efficient decision-making and better product alignment with customer needs.
✅ Transparency fosters alignment: Keeping communication channels open and documentation accessible helps maintain clarity and context for all involved, reducing the need for rework and increasing speed to market.
Elyssa (00:00)
Hi, I'm Elyssa I am the current director of product at Airspeed. Previously when we met, I was the director of product at Chili Piper. So yeah.
Jack (00:13)
Cool. And I imagine lots of interesting experiences, both at airspeed, but also Chili Piper and going through a fast growing, or going through the experience of being in a fast growing organization, always an interesting one. I know from my times at N26, that was a little bit of a roller coaster and some things going smoothly and some things going not so smoothly.
But tell us maybe more than not so smoothly, the part as well, but tell us a little bit about an experience you've had where maybe, you know, kind of product communication didn't work so well and what sort of happened there.
Elyssa (00:47)
Yeah, so, well, I'm new to Airspeed, so I'll skip that one for now, but I'll talk about my experience at Chili Piper because I started there when we were 17 employees. I was a customer success manager when we started and then grew into product and ultimately ended up leading the team.
And as you go through any sort of major growth stage, there's I think a key thing that sometimes we forget is all of our internal stakeholders that product touches. I know we're like literally a catalyst for so much change, which is all good, but you definitely don't want to leave people feeling growth stage, we were adding more engineers, adding more designers.
Specifically, we added, we grew so quickly on the customer facing rep side in terms of like our customer success managers and account managers that we, you know, we were putting the wings on as we were flying. And so we ended up finding that there was a lack of communication between when the idea was like started, because we, we shared all documents, decision memos, briefs at like the inception of, Hey, this is the path we're going to go down.
And then there was a broken piece in the funnel when we were getting to the point of, hey, we're building this now, actually, we're launching this now. Here you go. And like people didn't see anything in between those steps. And especially on the engineering side, they, you know, weren't seeing something until it was like we were already saying, hey, this is exactly what we want to build. And it caused us to slow down a lot because we had to like, get everyone up to speed, provide context and understanding and all that stuff. So,
Yeah, what more do you want me to dig into there?
Jack (03:04)
Yeah, interesting. So that was then, I mean talk us through that process, right? That was then, was that you and the designer kind of going and like putting your heads together we've got this problem, this is how we want to solve it and then you spend six months in a room and out the end you have these perfect finalized flows and you show them to engineering or how did that look?
Elyssa (03:22)
Yeah, we, I met with, I mean, it depended on the speed that we needed to produce a design app, but we met with the designers, depending on the pod, at least once a week, if not more. And there was a lot of async work with Loom, with Slack and all of that. But basically, yes, we were saying, hey, we're going to go down this path.
The engineers would know about it, the company would know about it because everything was public in that way, but then no one would hear about it or see anything or be able to say that's not possible, that's not going to work until it was you know in final design flow state and specs were getting written. And so we quickly learned that that, well I don't know if it was quick enough, but we quickly tried to course correct on that and also in the process get more people that maybe in this case, we were getting CSMs and account managers and AEs involved in the design once it was almost ready to kind of see if it was hitting the mark or not. So I can speak more about that specifically if it would be helpful.
Jack (04:38)
Yeah, I think that's an interesting point because I mean kind of I think common Common advice right is that you get engineering involved earlier as well And you're trying to kind of co-create of course with the caveat that you don't want to distract people right and if every engineer Is in every user research call then of course they're not doing any sort of building work but I guess in your case it was a little bit different because you also wanted to really get these account managers and CS people involved early.
Like what was the right cadence there? How did you approach that? Because of course you want them to, they're your users, but you also, they're ultimately gonna be selling the product. Like what was the right way of kind of packaging that to them?
Elyssa (05:21)
Yeah, so what we ended up doing is we tried having engineers in every UX call, at least the engineering manager and whoever was going to be the tech point on, we tried that and it didn't work so it was just way too many meetings. Engineers don't want to be in that many meetings. And it also wasn't valuable.
Like they were seeing like us being nitty gritty about the verbiage on the page and what toggle we were using, that isn't something that engineers, I mean, some of them do care about it, but it's not something that they all wanna get into the weeds on. And then on the other side with the CSMs, we were just providing them with the documentation once it was ready to launch and there was a lot of mixed context. So what we ended up doing is creating these little pods of, depending on the product that we were working on at Chili Piper, we created pods with either a CSM and account manager and account executive people that were seeing the entire, you know, life cycle of our customer.
They also were the persona sometimes that we were trying to serve with the particular feature and the engineering manager. And once we felt we being the designer and the product manager felt that the design was ready, like in theory, the next step would be to at that stage, we would actually book a meeting with those other people that I mentioned and see is it really ready?
So they would provide feedback and say like, that's not what our customers are asking for, that makes no sense, this is the right thing, definitely they've been asking for that a lot. And getting at the end of the meeting, if we got a yes, this is on the right path. Awesome if we got a, that is exactly the right thing, also awesome, but if we got, that is absolute crap, that is not what we need right now at all. That was also a huge win because it saved us, well, engineering time, and it also just made everyone feel like they were involved.
Again, we were a larger company, so, or mid-market, I guess, so it wasn't like we were hearing every voice of every CSM, it was select, one AE and then the engineering manager but it still saved us so much time and really got we got the insight that we needed because we're not on the calls with the customers and the prospects out day in day out.
Jack (08:07)
Interesting. Yeah, I mean, it's essentially de-risking it, right? Like if you involve engineering early, you're wondering or you're asking that question of like, can we build this? Is this feasible to do it? Is there an easier way? And in this case, you're more de-risking it from the kind of viability or like desirability perspective where you're saying like, should we build this? Like, you know, is this something that people want? And I think that's so fascinating. It's essentially doing the same thing, but just like involving people earlier in the process. But like the right people at the right time is not always easy to do, I think, and finding that balance is for sure imperfect.
But it reminds me of a project that we were doing at N26. I think we were always leaving customer service people way too late in the process. Here's this thing, it's going live tomorrow, here's 20 pages of documentation, and naturally the feeling wasn't that good, and I think that they weren't in a good position to train people on how stuff worked, or to answer like deeper questions about why we did A rather than B, or when certain extensions to the logic would come. I think it helped so much when it was finally having those people in the room, also just for the kind of philosophy and the feeling that they got of actually being involved in this process. And their input was so valuable as well.
Elyssa (09:15)
Yeah, definitely. I think that's it. You want, well, your internal ups, you want them to feel like they have a seat at the table and they can share the feedback and understand. So that was also a huge win for sure.
.webp)
.webp)
