It is always great to catch up with Brad. He’s been supporting us at Spoke.ai for a while now and we’re delighted to have him on the Product Comms Series!
Today, he shares his experiences and sheds some light on communication challenges he faced throughout his career as an entrepreneur as well as in his current role at Snowflake. Enjoy the bits of wisdom.
✅ Early Engineering Involvement: Including engineering in the product ideation process helps ensure feasibility and aligns expectations, avoiding late-stage surprises.
✅ Clear Communication Across Teams: Maintaining open lines of communication between product and engineering teams is crucial for mutual understanding and trust.
✅ Focus on Customer and Product: Regularly engaging with the product and keeping customer needs in focus helps align strategic goals and operational tasks.
✅ Manage Scale Challenges: At larger companies like Snowflake, keeping track of multiple initiatives and maintaining alignment requires concerted efforts in reviewing milestones and strategic goals.
✅ Continuous Collaboration: A continuous, rather than linear, collaboration process between product, design, and engineering helps refine visions and outcomes effectively.
Brad
Yeah, absolutely. So I'm a sort of founder to have been multiple times, most recently founded a company in the data visualization space called, we were called Reflect. There's been lots of companies called Reflect since then, but our version of Reflect, our Reflect was, yeah, data visualization as a service company that we started in around 2014, sold it around 2018 and to a company called Puppet and we made it possible for you to sort of build sort of interactive data experiences on top of the data you already have with the goal of embedding them directly in your product and sharing them with your users.
So think like, you know, why should I have to build an analytics team? Why can't I just sort of buy something off the shelf and, you know, embed it in the product? Interestingly enough, it was kind of our buyer was typically, you know, product managers who wanted to execute on their analytics roadmap without having to deal with engineering. So very appropriate topic, I think.
Jack
Nice. And now, obviously you've moved on from there. Tell us a little bit about how your, your kind of current role looks as an engineering manager.
Brad
Yeah, absolutely. So these days I've been working at Snowflake for the past couple years. You know, as an engineer, my background has always been in sort of analytics and data visualization and data warehousing. So Snowflake was a pretty obvious, obvious place for me to land. In particular, you know, you and I both live in Berlin. I was looking to move to Berlin and was kind of networking from the west coast of the US, where I'm from originally, and was networking out here kind of found this role and here I am now.
But anyway, at Snowflake, we work, my team works on the sort of part of the core engine of Snowflake, in particular, the control plane, how it kind of scales out and scales in, or how Snowflake scales out and scales in. And we own some features in the actual read write path as well, like how queries get scheduled and all sorts of stuff like that. Yeah, lots of interesting distributed systems topics now.
Jack
Cool. Super interesting. And obviously being someone who's been involved with building products for a while, you'll have had a lot of interaction, both with, with PMs, but also obviously other engineers, designers, data folks. What I'd love to focus on today is that interaction specifically between product and engineering. I'm sure you've seen countless situations where it hasn't worked. And obviously those where it has worked, but tell us a little bit of a story about a situation or an experience you've had where it was less than perfect.
Brad
Yeah, absolutely. So I'm thinking in particular about a time, you know, when we were sort of going through the acquisition, we were kind of brought in as sort of like the new products team inside of Inside Puppet. In particular, they wanted to use our product to build a new product. They wanted to build like an analytics product. They called it Puppet Insights.
You could probably go find some videos about it on youtube still today actually very interestingly uh... but uh... we kind of built like a little bit of a mock-up of the product and sold it to the CEO and you know give it to the sales force and they kind of sold it to some key accounts and they and everyone's like this is awesome let's build this let's go for it you know uh... and uh... the uh... sort of ideation for the product and everything was done a little bit in a vacuum between me and you might you know my co-founder who, or former co-founder now sort of had a product that I was working with.
And once we sort of started actually trying to go implement the thing, we realized, man, the thing that we are trying to build is like absolutely insane, actually. The amount of data that we would need from all the, from various data sources was going to be really complicated to acquire and sort of manage the, all the data sources that we found that the customer base was actually going to use or was actually using, you know, it was super diverse and everything was shaped a little bit differently. There wasn't sort of a common way to normalize things across all these different products. Like it was just generally going to be super expensive to build in the end.
And the issue like kind of fundamentally was that like the product that, you know, the product org, you know, myself to a certain degree sort of ideated and what we brought to engineering to actually work on, like, were two sort of different things. We could have needed to have a lot more sort of engineering buy-in throughout the process, or they needed, not really buy-in, but they needed to be sort of part of the process, right? To not just talk about sort of what's possible, but also like what's sort of, even like what's realistic to begin with, you know?
And I think this is really common. This is just like one example of like a problem that I see like, you know, really product focused people struggle with honestly is like, what can, what can engineering actually execute on? And what's realistic to work on? Yeah.
Jack
Yeah, fascinating story. I've definitely seen, seen that situation as well, where you get it, you deliver it to someone and then they go, I actually think this is, you know, this is not feasible or whatever, and you think actually it could have been great to get those answers much earlier in the process. Was that the, was that the issue in your case then that it needed sort of a bit more of a feasibility check earlier on?
BradYeah, I mean, feasibility. I mean, I think the way that I structure, like building new product these days as kind of a result of this is like having, making sure that engineering is kind of part of the process from the beginning. And that's not just sort of like in the corporate sense of like, Oh, make sure that they're brought into bought into the processor, like you write down, you know, everything, you know, so that's digestible by them, but like actually finding product focused engineers that can be part of the process of sort of discovering what the product should do, how it should behave, et cetera.
Like another way to describe the problem is that like, product comes to us with a very specific vision about what they want and there's no room to move on that vision from a feasibility perspective, you know? Like if product and engineering are working together to sort of develop that vision, you end up in a place that's much more sort of realistic or like.
Not just realistic from a feature functionality perspective, but oftentimes bring other world views to the table that helps enrich the process or enrich the product. Yeah.
Jack
Yeah, super interesting. I think that makes a lot of sense. Um, I'd be, I'd be interested to get your opinion on, on a certain thing that I often struggle with, which is sometimes it feels like if you bring engineering in and every kind of bit of discovery, you know, every user research call or whatever, it's, it's super distracting, but I mean, the classical kind of principle is this trio, right? Product design, engineering, working together.
And through that, you know, coming up with the idea and validating and et cetera. How do you see that kind of trade-off there of being involved early versus obviously saving time? How do you kind of find the right balance there?
Brad
Yeah, great question. I don't think it's the case that like everyone has to be there all the time. There should be some division of labor that's part of the process, you know, and it's less, I think, like overall the process is less linear, right, and more continuous, or more of like a sort of a spiraling in on what the right answer is. And it sort of takes time. Like everyone, you know, kind of you meet, ideate, and then everyone kind of goes off, finds the relevant data, and then brings it back to the table.
And discusses and that you kind of refine your refine the relevant vision over time, right? It's, and so it's not just like one sort of, you know, waterfall process. Like we talk about in like product development broadly. And, um, it's a bit more con more continuous, but yeah, you're right. That like, you don't want all your engineers sitting in all of the customer meetings or whatever, but it is helpful sometimes to bring them in to like actually have them see, you know, realistically, this is what we're actually hearing, or this is like what people are actually talking about and how they're talking about it and all of those things can be, you know, valuable.
Jack
Mm-hmm.
Yeah, absolutely. I think otherwise product ends up being this has to be this messenger as well. And then they have to pass on all of that information. That's just, uh, usually, uh, you know, a big time drain and also something I'm not necessarily very good at always.
Brad
Yeah, absolutely. And especially like, you know, engineers who can be engineers can be a little bit cynical sometimes, you know, and so if you have to, you know, backtrack on some Like Some hypothesis that you had perhaps or something like that, then, you know, people engineers might start, you know, not trusting product to a certain degree. Right. And so actually hearing it from them.
Jack
more than they already do.
Brad
Yeah, exactly. Hearing it from customers is kind of a helpful way to dispel that.
Jack
sure. And that's obviously a story, you know, from your experience founding. How about moving forward to Snowflake now? Is that a situation that you've experienced? Moving forward to Snowflake now, is there a situation you've experienced where, you know, the communication hasn't gone quite rightly, maybe a slightly different context?
Brad
Yeah, what's interesting about Snowflake is like the scale that we work at both in terms of, you know, the just like, you know, amount of data that we have under management and the, you know, the customers that we work at work with, but also like the ambitions of the organization, you know, there are tons and tons of initiatives going on all the time at Snowflake or going on at any given time inside Snowflake, right?
And so if you're working at a relatively high level like I am, then there's a lot of sort of like things to keep track of, lots of different things to keep track of, right? And so I think it gets really easy to kind of lose sight of like what the original vision for a given product or a given initiative was in that context, right? Especially like deep in the bowels of engineering. And so connecting those dots, like across these like really large gaps can be really difficult in keeping people aligned, can be really difficult, right?
And we try to do that with, you know, making sure that we're sort of regularly reviewing the relevant milestones and all of that stuff, but it's just, it's complicated. You know, it's a lot of the same problems that we deal with in startups, just like with, you know, an order of magnitude or maybe two orders of magnitude, more people involved realistically.
Jack
Yeah, it's so hard to keep that overview of all of those initiatives and why they're happening and the status of them. I mean, I think status tracking is obviously a big thing in organization, right? It's like, when will this thing go live? But I think it's very easy to lose the, what is it actually, and how does it connect to those other pieces, right?
You do dependency mapping, but dependency mapping is like a very sort of project focused exercise, but it doesn't really connect the the strategic role of different pieces together. Is there anything you've seen that's kind of worked better in that respect?
Brad
Yeah, absolutely.
Yeah, with regard to kind of connecting the strategic dots a little bit more, I think just being, you have to be very focused on the product realistically, you know, and with on the, you know, on the customer as well. But like, you know, spend making sure that you're like using the product, interacting with the product as often as possible, like making sure that you keep the relevant use cases in mind. This is something we do a lot. Actually, we have like
even test automation that captures specific workflows that we want to make sure are well supported by the product or whatever. And we use that as a way of communicating how well we're meeting the needs of the goals of the customer. I mean, for Snowflake, it's pretty easy because it's a programmatic product, right? And so you can automate a lot of those things. It's a little bit more complicated for something more interactive, perhaps. But...
Yeah, just staying focused on the product and like staying close to the product is a really good way. Like it's kind of how you avoid getting lost in the technology, I think.
Jack
Super interesting, yeah. Very fascinating to hear how you guys have solved that because that was definitely a problem that we experienced a lot. Yeah, go and write a book about it now. It's a, but yeah, it sounds like a work in progress, but nevertheless. Brad, this was super interesting. Thanks so much for your time. Really appreciate it.
Brad
Well, I wouldn't say we've solved it, but we're working on it. Yeah.
Absolutely.
.webp)
.webp)
