Today, our very own Kat Liu joined me in the discussion around communication challenges in product teams. Kat talks about something that we face every day in tech teams: the perceived dichotomy of moving fast vs. planning thoroughly.
Often, we think that to deliver faster, we need to jump in and work it out on the way: that time spent planning could already be spent building.
Opposed to the agile development we’ve all studied and learned about, she proposes another way that actually makes the delivery faster. From N26, Klar, Spotify, and now at Spoke, she’s learned from hundreds of projects.
It’s a 1-page document (linked below) that does three things incredibly well:
✅ Define a clear scope by answering key questions up front
✅ Align everyone around what you’re trying to achieve
✅ Create estimates that are actually reliable
Kat
Yeah, so I'm Kat. I am currently a staff product engineer at Spoke. Been there for, been here for, yeah, I guess coming out to eight months now. Worked a lot of different companies of all kind of shapes and sizes. So was previously at Spotify and then also another FinTech startup and then also N26.
Jack
So you've worked with a lot of PMs, I guess, over the years and had lots of experiences of that kind of product engineering interaction and how that works. Tell me a bit of a story or an experience that you've had where the communication didn't work so well, where it wasn't so smooth. Tell me a bit about that.
Kat
So I mean, one that comes readily to mind is actually one that happened at Spoke, which it just goes to show you that communication issues kind of arise from companies of all shapes and sizes.
Yeah, there was a feature that we were launching on our team, and I guess the implementation was dragging along a little bit. I would say, yeah, it was originally scoped as kind of a small improvement.
And that was kind of the operating assumption that the engineering team kind of was going off of. But it really turns out that a lot of the things that we had built was not really usable. We had done a refactor in the meantime. And so, you know, it was something that we all thought, okay, it's just like a little bit more, a little bit more, a little bit more. But turned out that, you know, actually it should have been kind of started off as an entirely new feature.
I would say another thing was, and again, this is obviously no one's fault, but there were some language misunderstandings. We work with a lot of Slack data, and in Slack we have conversations, but also in Spoke we have the notion of a conversation as kind of a just the small little detail that we kind of left out, is it a Slack conversation or a Spoke conversation. That kind of completely changed the scope and, yeah, that was also an issue that we had.
Jack
Yeah, great point. And we definitely don't do it perfectly in here. So there's, I'm sure there's many communication issues going on and learnings to benefit from. I think this is a great example as well. Tell us a little bit what you think kind of went wrong along the way, because with this project, it was something that existed a bit before, right? But then there was some stuff needed to be rebuilt, but that wasn't quite clear. Tell us a little bit more about that.
Kat
Yeah, I mean there's always, with most features, there's always a little bit of like, there's something existing, and then there's something that we need to rebuild. And I mean this particular issue was search, which it did exist before, but search when you're searching entirely new tables or entirely new entities is actually quite a technically heavy operation.
And it really needs to be thought about, especially if you're working at Spoke, and we deal with a lot of Slack data coming in from a lot of different sources.
I guess to also add to the complexity here, it was over the holidays and I'm actually back at my parents' place, which is in the Pacific time zone and it's a nine hour time difference. So despite starting my day at like 5 a.m., it's 2 p.m. in Berlin, and so a lot of things happen that I'm not there for synchronously.
I do believe that in this day and age, time zone issues are prevalent everywhere and we should be able to work around them, but the technology is not quite there yet, so there has to be a little bit more discipline on the personal side.
The ticket itself was kind of assigned to a particular person on the team. And so again, the visibility of like the progress of it was not quite there. So it was quite a few small issues that overall just kind of compounded into something that dragged on for a little bit too long.
Jack
Mm-hmm. Great point. I think it often happens, right? That like something isn't down to one, you know, big issue, but actually the aggregation of lots of small things. Um, but it sounds like then of course, there was also just that in transparency of, you know, what existed. So I think from maybe the product and design side, it was like, oh, we had the search before we're just bringing search back, you know, it's like a, it's a switch that you flick. But from the engineering side, it was obviously much more complicated than that. If we revisited the whole thing now, how would you have approached it differently?
Kat
So I am a big fan of doing a bit of a discovery slash design phase of a new feature up front. And so I would have been a little bit more clear about that. Probably would have assigned that to the team lead. Probably would have assigned that to the lead first, not directly to any... No, I don't like that either.
Jack
Maybe you could say something like, you know, we could have worked together on the design.
Kat
Yeah. Yes, yeah. So looking back, I probably would have done something like worked together on design before we kind of did any work on any of the ticket breakdowns. And then also been a little bit more disciplined to know exactly what all the team members were doing right when I started the day. And so kind of bring that visibility up to the forefront.
Jack
Yeah, that's a great point. I think it's also, yeah, really getting everyone on the same page with these things, right? So everyone really has this shared understanding. Because otherwise, I think it's so often the case that engineering has a different understanding to product or, you know, the amount of refactoring on something that exists already, there's so much that has to be changed there.
Kat
So I think there's like this fail, there's like this misconception, I think there's a misconception around Agile and like sprints and that okay you know we just kind of know what we're doing for the next two weeks or like however long the sprint cycle is and then just figure things out there from there. And I don't really believe that is the most, I guess, globally efficient.
So I'm actually quite a fan of looking at the entire feature as a whole, breaking it down into tickets and having knowing at least, you know, at what point in the knowing, having an overall overarching view of, uh, what the future is supposed to look like before we start it. Um, and then from there, you can still kind of organize the tickets in a way that you're still constantly delivering value every cycle, every two weeks. Um, it's not that you're still going from zero to nothing. You just take a little bit more time to actually plan out the feature, and then the implementation of it becomes much faster.
Jack
Totally. I think reflecting back, I always had this feeling of like, you know, let's get into it. Let's start. It will be faster. We'll work it out along the way. But I increasingly have this kind of feeling of like measure twice, cut once, you know, and it actually that time that you spend planning that is this, especially when you're trying to move really fast, you feel like, oh, we should just jump into it. It will be faster. We'll get it out. And actually, what often happens is, is the less planned stuff takes much longer because there's so much back and forth. There's like different interpretations, you know, an endpoint doesn't have the same schema or the expected schema or, you know, an acceptance criteria is missed or as you said, this language thing around what a conversation is in one context versus something else. Those things end up getting all confused and actually the thing goes on and on, and on. So actually that benefit of really planning it properly earlier actually really comes through.
Kat
For sure. Things come up in the middle of projects and that's supposed to be expected. There's no amount of planning that you're going to completely remove any amount of surprises. But if you're able to have it all thought out and then it falls into a certain category, then the impact is much smaller. Everything just becomes much more predictable because you've already thought about it.
Jack
And final question, you have a pretty robust kind of planning process, like a document and a procedure that you go through. Maybe you can say a few words about how that works and like why that approach.
Kat
It's just like kind of a consistent structure in which to, in how to think about complex problems in sections that actually make sense.
So the first thing is just kind of like a background, or an abstract actually, because like a lot of people read a lot of documents. Like how do I know that this document is actually relevant for me? A little bit of background information, which also includes what currently exists. A lot of people don't take a lot of time to see what currently is there.
Then a requirement section, and this is done in isolation also because the requirements don't actually depend on the current implementation or what you think the new implementation should be.
And then interfaces, because these are also very important to unblock other teams also, like frontend can code against an interface, back-end code, back-end data. No one actually depends on anything being done when the interface is very defined.
And then from there, if it's a very complicated algorithm, then I also just like to have a little activity diagram of all the steps that should be done to implement each kind of component. So from there, it's actually, after you get your components and steps, it becomes very easy to write out tickets and predict the order that you're supposed to do things in.
Jack
Super interesting. Yeah, I think it's already been cool seeing how that document comes to life. And I think then we get better at writing them and we get better at reading them because you know the bits to look at and you create kind of a much more consistent approach because all of the documents look the same. So you know how to, you know, what you're looking for essentially.
Kat
Yeah, that's also a super good point. And yeah, it takes practice. Everyone's terrible at it in the beginning, but over time, it definitely improves the process, I would say.
Kat has put together a Notion doc for you to use as a template.
.webp)
.webp)
