SEASON 2 - EPISODE 134 - DECEMBER 4, 2024

A Product Pivot

Before introducing a new product feature, it’s essential to first understand the problem you’re trying to fix. In this episode of The REWORK Podcast, 37signals’ co-founders Jason Fried and David Heinemeier Hansson share a recent experience designing a new feature in HEY. During the process, the team pivoted and changed direction, resulting in a better design.

Watch the full video episode on YouTube

Key Takeaways

00:44 - The original product design plan and what changed along the way
02:31 - The difference between specifying the outcome and diagnosing the actual problem
06:27 - The design meeting where the team got to the root of the problem
08:32 - Why executive involvement early in the process adds value
13:39 - Pivoting on an original idea while maintaining the original appetite
16:04 - Creativity often comes when you’ve hit a roadblock
20:07 - The power of Power Through New

Links & Resources

Transcript

Kimberly (00:00): Welcome to Rework, a podcast by 37signals about the better way to work and run your business. I’m Kimberly Rhodes from the 37signals team, joined by the co-founders, Jason Fried and David Heinemeier Hansson. We recently released a new feature in HEY, our email product called Power Through New. It helps you get through your new emails faster and how that product actually shipped and how it started were two different things. So I thought this week we would talk a little bit about the power of pivoting, knowing when you need to change direction and how that looks for us as company. So Jason, do you want to start maybe telling us what we started with, with that feature, what the initial idea was, and then how we made that transition?

Jason (00:44): Yeah, so initially we began looking into using the keyboard to navigate between new emails. So normally you have a bunch of new emails, you look at one and you want to go to the next one. Before with HEY and most email tools, you kind of go back to the inbox after you’ve responded to one and then you click the next one, you go to the next one. We’re like, maybe you could just do that and hit next on the keyboard, whatever. And we get into that and there’s some technical issues why that would work in some places but at other places or, well, maybe that’s okay and as we get into it and you start using it, it’s not really okay that this is unpredictable. I don’t like hidden rules and things where it’s like, well, sometimes it works, sometimes it doesn’t. We can tell people why, but that’s not a good answer actually.

(01:24): And so we stepped back and got back to what are we actually trying to do here? We’re trying to let you move through your new emails in a sort of more linear fashion and power through them. You want to get through them, you want to power through them. And so we had an alternate idea. We stepped back and said, let’s not get attached to the solution of the keyboard. That was sort of what we went in with, but that was just a solution. It wasn’t the problem. The problem wasn’t you couldn’t use the keyboard. The problem was that it was harder to move through your new emails basically and sort of attack them one after the other essentially. So we thought about it some more and came up with this new idea called Power Through New, which is actually based on an existing feature we had called Read together or Reply together, where we kind of open up all your emails and stack them open on a single screen.

(02:07): You can scroll through them and then deal with them. And so we went back to that idea, modified it a bit to make it work with this new concept. There was a few different changes to it and it turned out to be a much better solution in the end. So the idea really is that you don’t want to go in attached to a solution. You want to sort of understand the problem and then as you’re using this thing that you’re building, you might come up with a better solution to solve that problem. That’s ultimately what we did here.

David (02:31): I think it’s a great example of taking an implementation that did exist in some other competing products where you can navigate with your keyboard back and forth without thinking really that deeply about what we’re trying to solve. And it’s one of those issues where, when we’re sitting at the betting table and deciding which features to work on, it’s a fine line between specifying the outcome, specifying how we want things to work and trying to diagnose the problem itself. Because in this case, we could have saved ourselves a lot of time if we had somehow just have this magical foresight that the Power Through feature was what we really wanted, but to get there required actually seeing some of the difficulties of the technical implementation of doing it and then also realizing, why is this hard? This is one of the things I love about hitting a tough spot in the implementation part of a project because it forces you to stop and go like, wait a second, we’re trying to do something here that’s difficult for some reason. Oftentimes it’s difficult because the product is trying to tell you something, is trying to tell you that the design you had in mind was actually not as thought through as you thought it was.

(03:45): The example Jason referred to where we have the inconsistency was if you set up the view a single email screen to have navigational buttons and go back and forth, you’re going to expect that if you jump into say a tag or a folder or the paper trail or any other space where there’s a collection of emails, that feature is going to be there. ‘Cause you are just going to have it in your head that that’s what an email looks like. It has back and forth, but what does back and forth actually mean? If you’re coming to that email from a permalink, it could be in a tag, it could be in the inbox, it could be in the Paper Trail, it could be a bunch of different places. And I think that was where we really hit that point of like, oh, we just haven’t thought about the problem deeply enough and oh, is that really what we’re trying to optimize for, navigating with a keyboard between emails inside, say the Paper Trail?

(04:38): No, not really. What we really wanted to do was, oh man, I have 12 new emails. I don’t want to keep stacking up. I don’t want to come back and now it’s 24 and then come back and now it’s 50. I just want to get through all of them. But this is the magic that happens when you actually try to get into it. This is why when you try to detail the solution, very fine, grainy upfront, you close yourself up to these kinds of opportunities, where we’ve actually gotten quite far down and we’ve invested, I think Jason probably a couple of weeks into the old solution, we’d solved some of the harder technical issues. We’d actually made the implementation rather nice. There was a stumbling block on that path as well where we didn’t like how it looked and then we got it really nice and then we realized, ah, it’s not quite doing the thing.

(05:28): If we had had a spec that said this is what it’s going to do, we were going to ship that. We were going to ship the spec and we would’ve missed this opportunity of shipping something far more interesting. And I think this is really, I think why we’re talking about this, the reception to Power Through was on a completely different level than, oh, you can move back and forth between emails. People would not have gotten excited about that because that feels like a table stake of things. Power Through New feels like something new. It feels like a novel concept that combines the best parts of what HEY can do. It combines the magic of Reply Later with this idea of you can scroll through email as a feed, and we wouldn’t have gotten that unless we had stayed open to the idea that running into problems during the implementation phase is okay, and you can change your mind and you can still sort of kinda fit within the appetite that we had set forward. Maybe we went a little over with this one, but not like we’re going to spend another whole cycle on it.

Jason (06:27): So I was reviewing this, I hadn’t seen it yet, and I was reviewing it with Brian and Michelle. Not the Power Through, we didn’t have that idea yet that happened on this call, but I was looking through this and I was learning about these limitations and my instinct initially was to be like, alright, let’s just figure out how to deal with this or let’s just put up with it just for a second. And then I get this like prickly feeling this, no, I don’t like this. This is not right. Something’s wrong here. And that’s when we step back and go, okay, what are we trying to do here? That’s what I always go to. That’s my go-to is like, wait, what are we trying to do here? And that question often opens up this space, this problem space, and then I basically said, I just want to power through my new emails.

(07:06): That’s what I said. How else can we power through your emails? And then that opened up the space to think about what could we do here? It’s like, well, we already had these other views. We have this read, in fact, we already had a view on the New For You area called Read Together. There’s a button called Read Together and you could click that button, you could read ‘em together, but you couldn’t act on them. It’s like, well, we’re partially there because we can read them together, which is a great way to sort of power through them intellectually, but then I’m like, I don’t have anything to do that I want to do. And so then we thought about adding these buttons and then adding some more buttons as we started using it and it really made sense. But you have to be receptive for this sort of prickly uncomfortable feeling and sometimes you’re going to power through that feeling and be like, well, let’s just solve the problem as we thought we could.

(07:52): But other times you got to go, this is actually a moment to stop here and see if we can solve this a better way. So for people who are curious, we didn’t go back to the drawing board. We didn’t put the whole thing on the shelf and wait three weeks over 60 minutes over a phone call, we just revamped the whole damn thing and came up with this new idea. And then the team kind of prototyped it pretty quickly over the next couple days and we looked at it again and go, yeah, this is it. Here’s some tweaks though. We’re missing a couple things. Before we had a couple buttons on the left and a couple of buttons on the right. Let’s just stack ‘em all together and you kind of hone it in and fine tune it. And then I think it was maybe 10 days after that call or something we shipped the actual thing. But that’s how the process works actually.

David (08:32): I think though what’s also key to this process is that Jason, you were in the loop, because these kinds of pivots where you take something you’d set out to do, you’d invested actually a few weeks into it. You’re feeling a little tension about like, aren’t we supposed to be shipping now? Our appetite is almost running out. We’re supposed to produce, has a tendency to tunnel vision and the magic that can happen when the product owner, Jason in this case, can step in and go like, let’s question the premise again. I know we’re already far down the road. I know we built a bunch of stuff. I know it feels like we could just power through that to releasing something, but this isn’t right. And I think that’s one of the key benefits of having the people who run the business, be in the business, be in the product because injecting that level of both risk, we’re going to pivot this and maybe the pivot doesn’t work either, and now it looks like we doubled down on dumb and we have nothing to show for it.

(09:39): We could have spent that time on something else. There’s a permission in it when the person where the buck stops with them actually steps in and engages with the project, engages with the team and goes, you know what? No, this is good. Let’s sign off on this. Let’s go with it. And if that flow , if that information loop is too long, if Jason never sees anything until the end of a cycle, that’s never going to happen. Those opportunities are just going to evaporate. They’re just going to bubble through. Sometimes maybe the team will grab them themselves and other times they won’t. And for what, to save Jason a one hour call where this stuff gets hashed through? No, that’s really dumb. And I think this is what’s really interesting I think about the general discourse about Brian Chesky’s ideas from AirBnb about founder mode, about being a micromanager, about being in the product itself.

(10:38): There is this pendulum swing in the narrative about, is a CEO supposed to be above all of it, just sit down and do the master strategic long-term planning and meet with a team every three months or six months and be very removed from it? That’s certainly one view of how to be an executive. And then there’s a different view, which is like now screw all of that. Let’s get into the actual nitty gritty of it. I find the same thing on the technical side. Oftentimes I’ll look at something from afar and I go like, yeah, that seems reasonable. And then I’ll dive into it and actually go through the code line by line and I go like, no, as Jason says, I’ll get that prickly feeling. This is not beautiful. And usually when it’s not beautiful, that’s a smell. There’s something wrong in it. Just like what Jason says, this is not consistent, it’s not coherent.

(11:29): If I go this other place, then the feature doesn’t work and maybe we could explain it, but any explanation is ugly. I feel the same way about code. Whenever I have to write a piece of, a comment explaining why a piece of code works the way it does, I usually go like, do you know what? I’ve just not thought about this problem hard enough. There’s a clear other angle here that I haven’t found yet and if I stick to it a little longer. I will. And those insights and that questioning of the premise does not come unless you engage with the nitty gritty, unless your fingers are really in it and unless you actually want to use it and unless you actually want to care. I halfway observed this discussion about Power Through because I was trying to inject some of that before Jason showed up with a much better idea, which was essentially our guys are trying to solve a big problem, how to navigate any type of email in any space anywhere.

(12:21): I don’t care about any of that. I use HEY as much as anyone who pays to use HEY, and all I want to do is, I didn’t use those words, but power through my inbox, power through my incoming email. I don’t actually need this feature anywhere else. I’m not missing it anywhere else. So I think just this is essentially an example of the benefit of being in it as a decision maker, as an executive, as an owner, as a CEO being in the product and enabling the team to actually follow those ideas as they pop up.

Jason (12:52): Can I add one more thing, Kimberly, sorry.

Kimberly (12:53): Yeah, no, no, no, you’re good.

Jason (12:55): Whenever I’m in these sort of situations where there’s some thing that sort of works sometimes and not other times in a product, I always fall back to thinking about those terrible, we’ve all seen them like parking signs where it’s like between four and six, you can’t park here, but on the weekends you can except on every other Saturday. It’s like if we had that sign in our product, we’d be like, no. And that’s actually what you have, but you have to look out for the sign. And the sign is not as obvious in a product as it is on the street, but it’s actually like, yeah, this works in some places, but in other places it only works in this case, but not in other cases. Bad. That’s like, I don’t want that. It looks bad in the street and it looks bad in the product, but you’ve got to find those signs. You’ve got to read between the lines essentially to find them in software because they’re not as obvious.

Kimberly (13:39): That’s a great example. Okay, so we started talking a little bit about appetites. So I’m curious because in this particular situation, it sounded like the team pivoted, the feature pivoted and there was still time in the cycle left to move forward. Tell me this because had it been a few weeks later when that decision was made, it would’ve messed the cycle up. If it had been earlier in the process, they might not have gotten to the nitty gritty of what the problem was. How do you figure out when is the right time, Jason to inject yourself into the process to make those kinds of decisions? Is earlier always better?

Jason (14:17): I don’t know in this case. I was brought into the situation, so I was asked to review, to look at something. I wasn’t really aware of the issue until I looked at it and then I saw it. Sometimes the issue’s not there yet. If it’s too early and it’s not built yet in a way, then you wouldn’t have seen the problem in the first place. What you don’t want to do is you don’t want to do this Friday afternoon. If it’s due Friday, at the end of the day, you don’t want to do that. So I think we were at like week, I don’t know, four, I don’t know when it was, but we had time. We still had time left. And as part of that, you find out how much time left do we have and then you still work the solution out within that scope, within that timeframe or that appetite for the most part.

(14:52): So there’s probably another version of this where we could have been even more sophisticated in some way, but that would’ve blown through the appetite. So we still are working mostly within the timeframe here. We always have a little bit of buffer space between cycles. There’s usually two weeks between cycles. So if we had to really change this at the last minute, or it wasn’t quite the last minute, but a week, a week and a half prior we needed an extra few days, it would’ve been fine. But there is a point where it’s not fine and you’re like, well, this is just not going to happen. We’ve run into that before. We’ve talked about this before with this My Side feature in Basecamp, which was this idea we were exploring. We just couldn’t quite get there. We felt like we had some ideas, we couldn’t quite get there.

(15:29): We weren’t really satisfied with it and we just like blew it and it didn’t happen. That can happen too. We just don’t want that to happen all the time. But in this case, we knew we had enough, primarily because we were already basing this feature off prior art essentially. We already had kind of a layout that could do this stuff and many of the things that we were doing were already possible, but they were just sort of obtuse. You had to click an avatar and then hit this thing versus actually having buttons pulled out. So we knew it was all possible and it wasn’t like a radical new invention. It was like a branch off something we already kind of had. So it all felt like it was doable and it was.

David (16:04): I think though what often comes up in a retrospective of something like this is, oh, if only we would’ve thought harder. If only we would’ve been smarter. If only we would’ve been more creative on day one. And you look back and then you beat yourself up a little bit about that, which is a complete misnomer. The creativity to come up with Power Through New was not going to happen on day one. It was not going to happen without the gift of difficulty in the implementation. And it’s funny when you think about it that the greatest gift for this specific feature was that we did not find a clean way to do it technically. Now, maybe there wasn’t a clean way to do it technically because conceptually it was just muddy. This idea that an email can live in multiple spaces and what does back and forth mean when it can live in multiple spaces, that’s a conceptual nut that perhaps we just hadn’t cracked.

(16:56): But I also think you have to accept that that’s part of product development, that you can’t hold the entire problem space in your head and foresee all the permutations that you’re able to get to. Therefore you need to leave it open to this. You need to leave it open to the opportunity that halfway through you’re going to find that your initial idea is a dead end and then you can change direction. And not only is that fine, it’s good. It’s wonderful. It’s part of the process. The appetite is what scopes that process. I think that is key because what I have seen in other scenarios is that people run into a problem and then they go like, it’s not quite right. I can rewrite it, I can come up with a better way. And then they rewrite and they think, ah, there’s something I could make it little better.

(17:45): Let’s rewrite it again. And then you will continuously learn something and at some point you got to decide that good is better than perfect because perfect is never going to ship, and perfect is always going to delay everything. It’s going to push everything else out of the way and we’re looking to ship good software. The first version this wasn’t good, wasn’t even good enough, but we did need to make some super chrome version. It’s funny because when I think Michelle posted the announcement of this, I was so excited. I initially I started using it and I could see why the pivot happened so decisively because as soon as you see it, it just clicks. You go like, oh yeah, of course, of course. This is how most great design is by the way. You look at it and you go, of course this is obvious.

(18:33): Well, it wasn’t that obvious when a bunch of smart people sat down and tried to crack this out on day one, but it became obvious because the solution was just that good. And then I went like, ooh, I wish it also had this thing and that thing. That was chasing that perfect, right? I’m like, do you know what? Okay, fine. You’re right, Michelle. Actually I still could do those things. I maybe only need some of the time. The fundamental solution is good and it’s good software and shipped and ship within mostly the appetite we had for it and we should be thankful that these are the winding ways. I also find though, this is what keeps it interesting. This is partly what’s interesting for the team working on it. For anyone working on anything that you’re not just handed a final solution and type this up, you’re just a typist.

(19:21): Can you just program this up? Can you just cut out these designs and make them pretty? No, you’re actually involved in trying to solve the problem. That’s a much more engaging, motivating, empowering feeling. Even if it includes along the way a little bit of discomfort with like, oh, we’re kind of running out of time. We don’t have the full solution. That’s when creativity appears. You can’t manufacture that. It has to happen within the constraint that like time is running out. We have something that’s not quite good enough. What can click? What can we see? Can we see it from another angle? Step back two seconds. What are we trying to do here again? One more time. What’s the premise? Oh, here it is. Power Through.

Kimberly (20:07): Well, this is one of my favorite HEY features. It’s like the feature you didn’t know you needed until you have it. David, to your point like yes, of course.

David (20:15): I used it twice today.

(20:16): Literally. I cannot remember the last time we introduced a new feature in HEY where I was just using it multiple times a day. I like when I do email best. I don’t actually, I’m not in it all the time. I’ll come back to it a few times during the day and I get a lot of emails, so I’ll come back and there’s like 12 of them. And the instinct, and this I think is actually the magic of Power Through. The magic of Power Through is that it pulls you into dealing with the whole lot in one go.

(20:44): Before Power Through. It’s much too easy to look at that summary and go like, ah, man, I don’t know, let me just leave it for a little later, a little later. Power Through sucks you into let’s just get it done. And when you’re sucked into, let’s just get it done, and especially what I really like about Power Through is the reply field is so small. So you go to an email, you have like seven of them and you hit reply and you’ll get this reply field on the desktop next to the email, and it’s not very big. It’ll expand, but it looks small. It invites a short reply. Those are the best kind of emails anyway. A lot of my emails, maybe 20% is one emoji and it’s so satisfying. I could do it all with my hot keys, right? So I’ll enter the emoji and then a control return that’ll send that email out and collapse it down and you get the satisfaction of racking up completions. So again, you have seven emails in your Power Through. It’ll leave a line for each of them just when you use Reply Later. So you end up with all of it like, oh, I just did seven of ‘em, I did all of it. My inbox is now clean again. Marvelous.

Kimberly (21:52): Well, you can check out Power Through New, our latest product pivot with a free trial at hey.com. This is good for 30 days so you can check it out yourself. Rework is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. Full video episodes are on YouTube, and if you have a question for Jason or David about a better way to work and run your business, give us a voicemail at 7 0 8 6 2 8 7 8 5 0. You can also text that number or send us an email to rework@37signals.com.