A Product Pivot
22:24 Share

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 Hansen. 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 a 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?

Yeah, so initially we began looking into using the keyboard to navigate between new emails. So normally you get a bunch of new emails, you look at one and you want to go to the next one. Before with Hay 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 to go to the next one. Or like maybe you could just do that and hit next, next, next, next, next, you know, on the keyboard or whatever.

And we got into that and there's some technical issues why like that would work in some places, but not at other places. And we're like, well, maybe that's okay. And as we got into it and started using it, like, it's not really okay. That's 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. And so we stepped back and got back to like, 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 like power through them. Like you want to get through them, you want to power through them. And so we had an alternate idea. We stepped back and said like, we're not, 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 email's

and stack them open on a single screen. 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 because 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.

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 features.

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

It's trying to tell you something. It's trying to tell you that the design you had in mind was actually not as thought through as you thought it was. 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 because you're 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? No, not really. What we really wanted to do was, oh, man, I have 12 new emails.

I don't want it 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 grainedly up front, you close yourself up.

to these kinds of opportunities where you've, 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. If we had had like 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 have 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 PowerThru 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. PowerThru 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 kind of 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. So I was reviewing this. I hadn't seen it yet.

And I was reviewing it with Brian and Michelle, not the power through because 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, all right, let's just figure out how to deal with this or let's just like put up with it just for a second. And then I get this like prickly feeling. It's like, no, I don't like this. This is not right.

This is something's wrong here. And that's when we step back and go, okay, what are we trying to do here? Like, that's what I always go to. That's my go to is like, what are we trying to do here? And that question often opens up the space, this problem space. And then I basically said, like, I just want to power through my new emails. That's what I said. How else can we power through your emails? And then that opened up the space to think about like, 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 and you could read them 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 any thing 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. It really made sense. But

you have to be receptive for this sort of like prickly, uncomfortable feeling. And sometimes you're going to power through that feeling and be like, well, let's just solve the problem as, as we thought we could. But sometimes,

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 like put the whole thing on the shelf and like 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 of days. And we looked at it again and go, yeah, yeah, this is it. Here's some tweaks though. We're missing a couple of things.

Before we had a couple of buttons on the left and a couple of buttons on the right. Let's just stack them all together. And you kind of hone it in and fine tune it. And then like, 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. 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've 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. 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. There is this pendulum swing in the narrative about –

Is the 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, no, screw all of that. Let's get into the actual nitty gritty of it. I

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 said, I'll get that prickly feeling. No.

This is not beautiful. And usually when it's not beautiful, that's a smell. There's something wrong in it. Just like Jason says, this is not consistent. It's not coherent. 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 just haven't found yet and 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, you guys are trying to solve a big problem. How to navigate any type of email in any space anywhere. I don't care about any of that. I use Hay as much as anyone who pays to use Hay. And all I want to do

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.

Can I add one more thing, Kimberly? Sorry. No, no, no, you're good. 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 like 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, on the street, but it's actually like, yeah, this works in some places, but not other places. It only works in this case, but not 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.

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 have 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. Like, how do you figure out when is the right time, Jason, to inject yourself into the process to make those kind of decisions? Is earlier always better?

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 is 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, the end of the day. Like you don't want to do that. So I think we were like at week, I don't know, four. I don't know when it was, but we had time. We

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. So there's probably another version of this where we could have been even more sophisticated in some way, but that would have blown through the appetite. So we start 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

Had to really change this at the last minute, or it wasn't quite the last minute, but a week or a week and a half prior, we need an extra few days. It would have been fine. But there is a point where it's not fine.

And you're like, well, this is just not going to happen. Like 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. We weren't really satisfied with it. And we just like blew it and it didn't happen. That can happen too. You 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. Like you had to click an avatar and then hit this thing versus like actually having the 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. I think, though, what often comes up in a retrospective of something like this is,

Oh, if only we would have thought harder. If only we would have been smarter. If only we would have 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 sort of 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. 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. And 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, oh, 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 a little better. Let's rewrite it again. And then you will continuously learn something. At some point, you've got to decide that, well,

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 just, we're looking to ship good software. The first version, this wasn't good. It wasn't even good enough, but...

But we didn't need to make some super Chrome version. It's funny because when I think Michelle posted the announcement of this, I was so excited because 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. Well, it wasn't that obvious when a bunch of smart people sat down and tried to crack this knot 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. 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 shipped 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 like type this up. You're just a typist. 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 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.

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. I used it twice today. Literally. I cannot remember the last time I introduced the new feature to Hey where I was like just using it multiple times a day because 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 DMs,

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. 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 because I could do it all with my hotkeys, 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 and you 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 them. I did all of it. My inbox is now clean again. Marvelous.

Well, you can check out Power Through New, our latest product pivot with a free trial at hey.com. It's good for

for 30 days. You can check it out yourself. Rework is a production of 37 Signals. You can find show notes and transcripts on our website at 37signals.com slash 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, leave us a voicemail at 708-628-7850. You can also text that number or send us an email to rework at 37signals.com.