Carl Vellotti is a Senior PM at GoodRx, where they support Americans with their healthcare challenges, and I was lucky enough to catch him for an exciting discussion around communicating with various stakeholders.
He shares insights of particular projects that did not go as expected and what he learned from it. It was a pleasure having that talk and I am excited to share it with you!
✅ Early Stakeholder Engagement: Engage stakeholders early with honest evaluations of project challenges to facilitate timely decision-making.
✅ Prototype and Test Early: Prototype and test key features early to identify potential usability issues, ensuring a seamless user experience.
✅ Evaluate Platform Choices: Carefully evaluate the choice of development platforms (native vs. web view) for critical app features, considering long-term scalability and performance.
✅ Transparent Communication: Maintain transparent communication between product managers and engineers to understand technical challenges and constraints fully.
✅ Consider Future Implications: Understand the long-term implications of architectural decisions, especially for core components, to avoid future development bottlenecks.
Jack (00:01)
Cool, Carl, thanks for joining me.
Carl Vellotti (00:03)
Glad to be here. I'm Carl Vallotti. I'm a Senior Product Manager at GooderX and I'm a Product Manager and Content Creator.
Jack (00:05)Nice.
Tell us a little bit about the company and your role there actually.
Carl Vellotti (00:15
)Yeah, so Go to Rex helps make prescriptions more affordable for Americans. And we do that basically by making relationships with all different types of partners in the pharmaceutical industry to bring discounts to people so they can just go to GoToRex .com, get a coupon, and then go to the pharmacy and get a cheaper prescription. My team specifically, we build things that help people besides just getting that coupon and paying for your prescription, all of the things that you need to do to manage your prescription besides just paying for it.
So remembering to take it on time, remembering when you have refills coming up, checking for side effects, things like that. And so mainly my team builds what's called the medicine cabinet feature in our mobile apps.
Jack (00:55)
I love the description of the feature, the medicine cabinet feature. That sounds so cool. Nice. Yeah, Carl, I want to jump in straight away. And we're talking about product communication here and real experiences that people have had where it hasn't worked quite so well. Tell us a little bit about an experience you've had where it didn't work so well. We can kind of unpack of that a little bit.
Carl Vellotti (01:21)
Yeah, so we had this project a couple of years ago where we were taking our main home screen on the app and we were across the company. There was this whole initiative for us to basically rebuild a lot of the native pieces of our app and build them in a way in what's something called a web view so that you can basically build it in like a web page displayed in the app. And then the benefit of that is that you only have to build it one time on web.
And then you can deploy it on web. You can deploy on Android. You can deploy on iOS. You don't have to do it individually across all these different platforms. And so it sounded great in theory. And my team was the really the first team that was going to do like the first, like really we had done some web viewed experiences throughout the product at the time, but nothing sort of as, uh, as meaningful or as sort of, uh, as many interactions as the home tab. And so we're rebuilding it. And it's this, it's this pretty long project where it involves, you know, product and design and engineering.
There's a lot of interest from stakeholders. And as we were going through this project, there was just a lot of small things that should have been like warning signs that maybe this wasn't the best approach of how we should be building the screen. And so there was just a lot of small things. So for example, when you build on a native, when you build on an app, you get a lot of like nice things for free. So for example, if you want to have a carousel, you know, there's, there's like predefined patterns for how you build a carousel.
And then once you implement it, it'll be kind of nice where you can just scroll left and right and it'll do certain things where it like slows down. And if you're scrolling left and right, it will make it so you can't also like move up and down on the screen. But when you're building these things from scratch on web, you basically don't get any of that. And so it wasn't, everyone was kind of doing the right thing in the sense that design was taking the mobile components and building them on web. So they looked correct. And then engineering was building them in a way where it looked like the designs.
But then when we would go to test the product, it was just like really janky and it didn't feel right. And instead of maybe pausing and for any of us, like, you know, there was a lot of pressure to build this instead of kind of like pausing and saying, there's a lot of extra work that we're having to do here. And this was really only at the time the home screen was like very basic and there was all these other things that we wanted to do.
We didn't really pause and think, are we going to be able to do all these other things, like all these much more complicated interactions on this platform we haven't really built out? And we kind of kept going through this and we kept struggling. And it got to the point where we were finally supposed to launch this feature and it was still had some jankiness and it really, we realized it really wasn't going to support some of our upcoming goals. And so we'd been giving all these updates to stakeholders, but finally, one of the leaders at a company asked just sort of straight up, do you think we should ship this feature?
And I think at that point, that was kind of where my team really, when we stepped back and we really thought about how hard it had been to build this and where we wanted to go next, the answer was probably that we shouldn't ship the feature. We ended up not shipping it. And we just kind of reverted all the way back to, we're just going to build these separately on native and we're not going to worry about building them out on web. But this kind of accumulated to end up being like four or five months of work where we probably could have made the decision a lot earlier, but we were so determined just to make it work that we got so far along in the project before we really stepped back and thought about what we were doing.
Jack (04:44)
Fascinating story. I have a similar experience with web views as well. I was at N26 for a few years. So it's like Chime, but here in Europe. And yeah, we would often try and do things with a web view if it needed to be done really quickly, right? Because you could just have the web view in there. You could push to the app store already, and then we'd know we could do the rest of it kind of on the fly.
There were so many, I mean, janky is the word, right? We had so many experiences that just didn't deliver smoothly and that process of like jumping over from iOS or Android into the web view. Like that transition is not smooth at all. And yeah, it definitely promised so much. It was like, oh, we can do it in half the time. We don't need to do it with both iOS and Android, but definitely, yeah, definitely had some, some tough experiences. I guess the difference was probably not doing it at the heart of the experience like you guys were. You mentioned obviously getting kind of five months in and thinking, all right, you know, it's not ready to go or we need to rethink it. How would you have approached it differently if you could have sort of started that again?
Carl Vellotti (05:58)
Yeah, I think the main thing, I think now just having gone through this one time, raising it to stakeholders like much earlier on that we were having these problems and not being afraid to just say, hey, like this is the goal and this is what we're trying to do, but this is an honest evaluation of how it's been going for us so far and what it seems like this will take to really complete.
And I think instead of doing that, we kind of just, we kept wanting to say that we were hitting these deadlines and that we were gonna ship on time. But I think if we had raised these issues sooner, it would have helped ask that question. Should we actually ship this much earlier than when we actually got to the point of it technically being ready?
Jack (06:40)
Yeah, totally. I think an old manager of mine used to say things as well. Like he would say, like, give other people the decision -making power. Like you can say, you know, would you rather go in, you know, in this timeframe and we can do it in this way, but these will be the trade -offs or we can do it in the, you know, let's say quote unquote proper way. But it will take longer. And, you know, those are the trade -offs there and you let them kind of decide.
But I think as PMs, we often feel like we have to do that ourselves and we have to make those decisions. And then the stakeholder will say like, oh, why didn't you just, why didn't you say before we definitely could have done it the other way. And I think that's super hard knowing where to stop or where to expose those decisions to other people. Cause we want to also come across as super decisive, right? And on top of our shit. So I think that's kind of a challenge.
Carl Vellotti (07:35)
Yeah, yeah, exactly. And I think the other one was, you know, that was kind of like for me escalating up, but I think there was also an opportunity. It took me a long time to kind of understand from like an engineering standpoint what the issues actually really were. And so kind of even some of the things I talked about earlier where you don't really get anything for free. I think that was something that it was hard because from like one side you had like the company direction was like, this is supposed to be easy. This is a better way to do it. And then the actual experience of the engineers was this was really hard.
And there was like not really a lot of clear guidance for this. And like the company hadn't invested a lot in making sure that this was a good process. And so I think earlier on it was kind of like, hey, you're fulfilling the requirements, but this really doesn't work. We need to like, aren't you testing your own features? We need to go back and like make sure it works these ways. But just talking to them more and being like kind of asking like, you know, why does this carousel go up and down while I'm scrolling left and right? Is that just like not pre -built? And there was just a lot of examples where...
I think going down and kind of asking the engineers what their actual problems with trying to implement it like iOS. Because once you started asking those questions, they kind of knew. They had like a pretty good sense of, you you don't get any of this stuff for free. There's all this calculation and things that are built into those native platforms that you don't get. So I think if I had had those discussions earlier, it would have been a lot easier to make this decision sooner too.
Jack (08:58)
Totally. And I think you mentioned something earlier, which I think is super interesting, which is about building other stuff on top of that, right? Like this, it sounded like it was going to be a pretty core component of the experience. And, you know, maybe you can ship one project that works like that, especially if it's buried in a corner of the app where maybe, you know, N26, we did that. I remember we had to get something out for like a, a screen or a flow where you would add your tax ID number. And it was like, someone's going to do this once.
They're never going to come back. It's hidden away, you know, down like seven, seven steps. It was like UX is not that important. We can stick it there, but we weren't having to build stuff on top of it. And I think that's, that's a really fundamental point is like, sometimes we think of projects as one offs, but like so much, if it's a core component, like, and you're really relying on it from the front end, from the backend, whatever it's from, you've got to make sure that that's something that you do invest the time in. And I think.
Many stakeholders, they obviously want to move as fast as possible. But if you give them the trade off of like, yeah, we can build this really quickly, but then it's going to slow every single project afterwards down by, by 30, 40, whatever percent, then the trade off is actually pretty straightforward.
Carl Vellotti (10:11)
Yeah, and I think that's maybe one of the biggest takeaways too is exactly to your point, the things that we'd built before that where they were like settings pages or like really basic things where a user may only need to go to like one time and it was really helpful to have it. Just the web thing could be the same as the iOS, but there was really nothing you were gonna build on top of it. Whereas I think to your point, you have to live with these decisions. Like once you ship something and it's in the product, there's this concept of like one way and two ways doors.
If you're going through a one -way door and then you really can't ever go back and now you have to live with that decision forever and everything's gonna be harder, it's not just about shipping that particular feature or project, it's about where you're gonna go from here. And yeah, in our instance, that was really, I think if we had just, we did get that particular feature to parity with iOS and so it would have been like fine, like it eventually did look good.
but then we just knew that anything we were gonna continue to build on top of it, we'd have to go through all of this again. Yeah, that was the reason is that you have to live with this now and maybe it's not worth shipping if it's gonna be this much pain going forward.
Jack (11:17)
Yeah, totally good learnings for sure. Carl, thanks for joining me today. That was super interesting.
Carl Vellotti (11:23)
Yeah, thank you so much.
.webp)
.webp)
