Earlier this year, we launched our Status Pages product. In this episode, we chat with one of the product engineers on that project, Dimitra, about how that launch went. We discuss:
- What it was like working on such a big project
- What the team learned
- What it was like collaborating cross-functionally
...and more
The transcript below may not match the audio exactly.
Luis: So let's start off with a pretty basic question. What exactly are Status Pages and what were we hoping to solve with them?
Dimitra: A status page is actually not a novel concept in tech. It's very likely that if you are a consumer of a big software platform that you've actually landed on a status page before. Let's say you're looking to see if your internet is down or whether it's the software service that is down. You might have gone onto their status page and looked to see if they were reporting any outages.
So that's pretty much what a status page is. It's a website that you can go onto, to communicate with your customers about if there's scheduled maintenances, if there are any outages that are impacting the system and give them an overview of the status of your system.
Luis: Gotcha. So I'd love for you to talk to me about some of the challenges that you and the team faced when building Status Pages. So obviously like this was our first big product launch in a few months and there were a lot of variables from design, engineering, marketing. So I can imagine that it was quite challenging. Could you talk me through that?
Dimitra: Challenging for sure. I think in an exciting way because it was the first time that we were expanding our product. So before this, for context, we were one large engineering team, all working together. And when we split up into the Status Pages team. I think there were about four of us at the beginning.
So just from a purely practical point of view. We had to figure out what our stand ups were going to look like, what our various rituals were going to look like and how that was going to be different from the main engineering team. We also had never built an entirely new product before. And the audience of this product was also going to be entirely different from our original audience, which is our customers.
Status Pages are actually targeted at our customers, customers. So there are definitely a few variables and factors to think about. But I think that was quite interesting of a challenge for sure. And it's something that we just had to keep iterating on. So figuring out what was going right and what was going on having lots of feedback sessions and retrospectives and basically carving the path as we went on.
Luis: Yeah, because that was actually going to be one of the questions that I had. How do you plan for something that you've never done before? It's uncharted territory. Typically when you're creating a plan, you have a sense of how things are going to play out and you work around that. But yeah, just just curious about how you create a plan when there's no roadmap.
Dimitra: So we were pretty certain that Status Pages was something that we wanted to bet on. Obviously Status Pages as a product is something that's quite important and most people are going to need a status page at some point. And given that we come from this unique point of view where we actually know a lot about your incident and what's happening when you're in an incident, it feels like kind of an obvious next step to move into how we help you communicate not only internally but also externally with your audiences. So it was definitely something that we were very positive we wanted to branch out into. So I think that helps knowing that. This is a product that we want to do and this is a space that we want to branch out into.
And then basically just being flexible and agile and moving quickly. Getting something down very quickly and relying on our clients, our design partners to give us feedback and input as we went along to figure out if what we were working on made sense and was useful to them. I think that's one really important thing.
The other important thing is not over planning. So having a good idea of what we wanted to build for our minimum viable product, our MVP. But also being flexible to changing that as we went along and de-scoping what needed to be de-scoped or pivoting quickly if needed. And I think that's just one of the things that we tend to do quite well at Incident is just being pragmatic about those decisions and moving quickly to prove value.
Luis: When Status Pages was coming together, I know that we only had one in-house designer. How did that work?
Dimitra: That was very interesting. We, in fact, only had one designer, James. He's our very first designer. And at the time, as I said before, we were one large engineering team. And so relying on James for everything was obviously not going to be possible because he was quite stretched thin already as is.
But for Status Pages, just given the new audience and given the level of polish that we did want to achieve with this product, we definitely knew that we had to lean on design more than we have had to in the past. So I think going back to earlier, a lot of it was about not over planning, but having an idea of when we'd want to pull James in and when we'd want to give things a good stab ourselves.
And just given that incident.io hires product engineers, we do expect a level of, 'Hey, we can make something look pretty decent and we can figure out what works from a product point of view,' but achieving that really high level of polish is quite a different story. So I think again, just being pragmatic about decision making what could use our input versus what could use James input and working with him on deadlines to make sure that we were all up to date about our launch and MVP dates.
Luis: So did the team already have a vision in mind for what the product was going to look like? Or was there a lot of back and forth?
Dimitra: Yeah. So, as I said before, Status Pages are definitely a well known concept. I think if we completely subverted that, it would be quite an uncomfortable experience for everyone involved. So there's definitely expectations as to what you want to see when you go on a status page, but that definitely didn't mean that there weren't huge improvements that we could make from a user experience point of view. Whether that was for responders who are making updates to the status page during an incident or for the consumers of the status page itself. So we, as users of status page products, and as engineers, we had ideas of what we would have wanted to see in a status page product.
But leaning on design partners and what they wanted from a product was super important, too. So we weren't just completely relying on our own assumptions or going blind. We had other input, and I think we were really good at iterating constantly on that and making sure that using the product and making sure it fit.
So we didn't have everything planned out to a T for sure, and a lot of that was back and forth between us and James and implementing something and then figuring out if it made sense, going back to the drawing board if not, and a lot of synchronous and asynchronous collaboration to figure out what would make sense along the way.
Luis: Yeah. One of the things that has come up a few times during the course of this conversation is just like the themes of input and collaboration, just like feedback in general. And one of the points that you made in your article is about the importance of making sure that criticism and feedback isn't personal.
So throughout your career, has there, has this been a challenge for you when collaborating with design or other teams and like what was different this time around?
Dimitra: Yeah, great question. I think in general, it's always going to be a thing if you're working on a team. So regardless of whatever industry you're working in. You have to be open to receiving feedback and giving feedback as well. It's a really important skill. I think it's easy to take things personally, especially depending on your personality traits and your level of sensitivity.
But I think something that we do well, another thing that we do well at incident.io is the idea of feedback that isn't directed at a person necessarily. It's very much a collaborative effort on 'Let's look at this product or this feature that we've just released, go through it together and work out if it feels good from a product point of view.'
And if not like, what what can we do to improve on it? And it's very much a group effort. It doesn't feel like an individual who is calling all of the shots. The team is working together and in general, we're pretty much aligned on what we'd expect just given from the beginning when we were doing initial planning.
We built up this alignment and we set out a list of goals that we wanted to achieve by the end of the product. So all being on the same page from that point of view is really helpful because when you're making decisions or when you're receiving feedback, it kind of adds up and it's like, 'okay, it's in line with these values that we set up from the beginning and how can we improve it?'
So I think if you're in the headspace of what I'm working on could always be better and how could that be better? Constantly learning or trying to make the experience better for the user. That's a very positive, healthy mindset to be in. But again, it's always going to be hard when you're working on something for a very long period of time, and especially if you're working on it alone. It's your baby and it's hard to receive feedback on it, especially if you think it's perfect.
But I think, especially in those cases, if you haven't been receiving outside input. So it's very likely that you have blind spots. So it's actually super important to get external perspective on it. And again, I think giving and receiving feedback is a skill and it's something that my colleagues do extremely well.
So learning from them and just knowing that we're trying to put out a really, really good product. So nothing is really personal from that point of view.
Luis: know that one of the forums that we have for gathering feedback are Something we call Polish Parties. Can you explain what those are to us?
Dimitra: Yeah, love a good polish party. In terms of Polish Parties, this is a type of ceremony. That sounds a bit official. It's not really as official/ Essentially towards the end of a project, we get into a room and we figure out a key flow that we want to dig into. So for example, let's say we had finished the creation flow of status pages or updating a status page, we'll get into a room the team who's been working on it, but also people who have never seen it before, especially if they don't have context on it, That's super valuable. If we want this to be easy to use, we want people who haven't been as close to the product to look at it and give us their first impressions and thoughts.
So the idea of a Polish Party is running through one of these flows and nitpicking at it, seeing what can improve in terms of copy, and user experience. And then hopefully there's nothing, glaringly obvious, because at that point we've been iterating and talking to design partners.
So fundamentally the product should be there. But it's small flows or user experience items that we can improve on. And that's the goal of the Polish Party. So once we go through all of that, we'll write down a list of notes and suggestions for how we can improve on them. And then we'll take a day or two at the end of the project just to tackle all of those little nits and make sure that it feels really polished and really good.
Luis: So given the weight of Status Pages, did the Polish Parties for that project look any different than just your other, any old standard Polish Party?
Dimitra: Yeah, great question. I want to say no just because we were very conscious about the fact that this was a big project, and we did try and split it out into much more manageable chunks, so we held loads of Polish Parties. It wasn't just one at the very end of like three months of developing this.
It was like lots of Polish parties after every feature that we implemented so it felt manageable and it didn't feel overwhelming, which I think is really important. You don't want to go away from a Polish Party feeling overwhelmed or bugged on in work. You kind of want to go out feeling like, 'Okay, this was good.'
And now it's really, really good because we figured out a few ways that, you know, given outside perspective, how we can improve and make this a lot better than it was before.
Luis: Gotcha. So reflect back on the Status Pages project with me. How do you think the project went overall? Were there any learnings for future projects? Just like curious about your high level thoughts.
Dimitra: Yeah, I think I'm probably a bit biased. I think it went great, honestly. In terms of adoption, we've been seeing a lot of adoption and that feels really good. it's always great when something that you've actively worked on and put a lot of effort into is being used by customers and you're getting positive feedback.
I think that just puts you on the right track. And in general, it's a good, it's a good mindset to be working on something that you believe actually has impact. So that felt really good. And there was, you know, and just in terms of marketing, it was a big launch. So we're working towards something. I think of course, like throughout the whole project, there was definitely things that we learned and improved on during the way. Definitely the collaboration with design was something that was quite unique, as I said before, is something we hadn't really tackled before, just because we leaned on design a lot more for this project than usual.
And so figuring out the best way to work with James and use his time effectively, I think, was what we learned. So when to have synchronous meetings and all just sit down in a room and go through something together versus asynchronous collaboration on Figma or Slack or whatever it is. And the balance between that, because there is such a time where, let's say, a month into the project and everyone sits down at the first Polish Party. And we're like, 'Oh no, actually we think X, Y, Z component has to completely change.' That's quite late and not a good time to be changing fundamental things about the product. I think what we learned was just a lot of async collaboration on Slack and a lot of hands on collaboration from everyone on the team, whether that was engineers product managers, C-suite everyone got involved.
And James came up with some really, really stunning designs. And I think we did a great job and we're all very happy with the outcome.
